Update: Call for Packets - Unassigned TCP Options

Published: 2011-03-07
Last Updated: 2011-03-14 19:12:41 UTC
by Lorna Hutcheson (Version: 2)
7 comment(s)

We had a user over the weekend send us some interesting traffic primarily destined to port 80.  The TCP option used is in an option kind that appears to be in unassigned range, the sequence numbers are not changing, but the source IPs are.  They also throw in a packet here and there to destination ports other than 80 such as ports 21, 22 and 1.   If anyone is seeing something similar and has logs or preferably packets, please send them to us.  


UPDATE:   I want to thank those who have submitted traffic and logs.  There is still no answer for this traffic, but I wanted to share with everyone what we have received so far.   Here is an example of a capture:    xxx.xxx.xxx.xxx    TCP    33338 > 80 [SYN] Seq=846930886 Win=61690 Len=0 MSS=1460 WS=4

0000   00 00 ff ff 00 00 00 00 00 00 00 00 00 00 08 00           ................
0010   45 00 00 3c 45 67 40 00 e9 06 a7 30 72 86 53 8d      E..<Eg@....0r.S.
0020   xx xx xx xx 82 3a 00 50 32 7b 23 c6 69 98 3c 64            >K...:.P2{#.i.<d
0030   a0 02 f0 fa 97 d4 00 00 02 04 05 b4 01 01 04 02         ................
0040   b2 08 f0 47 00 00 00 00 01 03 03 04                              ...G........


Items of interest across three captures sent to us:

Source IPs:  Various

Initial Sequence Number is identical :  846930886

ACK Flag is NOT set, but the ACK field contains data which is identical in all 3 captures:  69 98 3c 64

Window Scale is the same and set to 4: 

Unassigned TCP option:  b2 08 f0 47 00 00 00 00


If you have any ideas or your seeing this traffic similar to this with unassigned TCP options, please let us know.



7 comment(s)

Hey, what is with all the Government and Private Industry sharing wrt cybersecurity?

Published: 2011-03-07
Last Updated: 2011-03-10 22:21:11 UTC
by donald smith (Version: 1)
2 comment(s)

Seriously, its a good trend and should be encouraged.
Here are two efforts that recently came to my attention.

DOD is launching a program that will send members of their IT teams to industry to improve the government's IT expertise particularly in cyber security.

Estonia is building a Cyber Defense League with private sector cyber defense experts and government agencies.

I have been involved in several similar efforts in the past and while not all produced the desired results IMO such sharing benefits the parties involved. Private industry has people that, as part of their day to day job, watch for cyber security threats and trends. Government agencies have personal with the similar responsibilities and similar abilities.

Both have different views into various portions of "cyber land" and may see different things at different times but eventually will probably see whatever the other is seeing. Sharing that type of information just makes sense. The "bad guys" share. If the good guys don't we will always be one step behind them.

Other Government and private industry cyber security sharing forums in no particular order include but are NOT limited to:

nsp-security, ops-trust, infragard, NCFTA, ICASI, ISACS,  and many others.


"Since 1997, the NCFTA, a non-profit corporation, evolved from one of the nation’s first High Tech Task Forces and has established an expansive alliance between subject matter experts (SMEs) in the public and private sectors (more than 500 worldwide) with the goal of addressing complex and often internationally-spawned cyber crimes. These SMEs, from industry, academia and government, each bring specific talents and experiences to the partnership. Through a steady cycling of such cross-sector national and international resources, both embedded at the NCFTA and through initiative-specific intelligence channels, the NCFTA is well positioned to adapt and regularly reinvent itself to better address today’s evolving threat landscape."


"The nsp-security [NSP-SEC] forum is a volunteer incident response mailing list, which coordinates the interaction between ISPs and NSPs in near real-time and tracks exploits and compromised systems as well as mitigates the effects of those exploits on ISP networks. The list has helped mitigate attacks and will continue to do so."


"OPSEC-Trust (or "ops-trust") is a highly vetted community of security professionals focusing on the operational robustness, integrity, and security of the Internet. The community promotes mindful action against malicious behavior vs observation/analysis/research. OPSEC Trust carefully expands membership pulling from talent in many other security forums looking for strong vetting with in three areas ; sphere of trust, sphere of action, and the ability to maintain a "need to know" confidentiality. OPSEC-Trust (or "ops-trust") members are in a position to directly affect Internet security operations in some meaningful way. The community's members span the breath of the industry including service providers, equipment vendors, financial institutions, mail admins, DNS admins, and DNS registrars, content hosting providers, law enforcement organizations/agencies, CSIRT Teams, and third party organizations that provide security-related services for public benefit (e.g. monitoring or filtering service providers). The breadth of membership, along with a an action/trust vetting approach provides creates a community which would be in a position to apply focused attention on the malfeasant behaviors which threaten the Internet."


InfraGard is an information sharing and analysis effort serving the interests and combining the knowledge base of a wide range of members. At its most basic level, InfraGard is a partnership between the Federal Bureau of Investigation and the private sector. InfraGard is an association of businesses, academic institutions, state and local law enforcement agencies, and other participants dedicated to sharing information and intelligence to prevent hostile acts against the United States.


The Industry Consortium for Advancement of Security on the Internet (ICASI) is a forum of trust through which IT industry leaders address multi-product security challenges to better protect the IT infrastructures that support the world’s enterprises, governments, and citizens.


A few articles about Government and private sector sharing wrt cybersecurity intel:






If you know of any other good sharing being done feel free to add comments to this diary to educate everyone.

2 comment(s)

Oracle padding attacks (Codegate crypto 400 writeup)

Published: 2011-03-07
Last Updated: 2011-03-07 19:31:35 UTC
by Bojan Zdrnja (Version: 1)
1 comment(s)

The Codegate CTF last weekend was finally an event that I was able to spend some time playing with – it was unfortunately only couple of hours but it was fun nevertheless!

As I haven’t seen any writeups about the crypto 400 – here go hell come (bonus question – guess the E! channel's host name who likes exploiting this :).
So, we are presented with a log file (mirror available at http://repo.shell-storm.org/CTF/CodeGate-2011/Crypto/400/2404656D5DA22F5DBA41CDD7AA1C1F7B) that has 2468 HTTP requests coming from a single host. An excerpt is shown below:

Log excerpt

We can see a valid request (HTTP status code 200) and then a series of 500 requests, as well as a single 403 request. If you were paying attention last year you almost certainly heard about oracle padding attacks that were demonstrated at BlackHat Europe – these attacks allow an attacker to decrypt certain data (and encrypt, depending on some other circumstances) when CBC encryption is used. An excellent description of how these attacks work is available at http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/.

Knowing how oracle padding attacks work, we can analyze the logs of our (Codegate) server. The URLs shown in the picture are base64 URLSafe encoded – after decoding we are left with 32 bytes. Since the attacker started changing the 16-th byte, this means that the block size here is 16 bytes too.

The 500 server errors were clearly caused by an incorrect padding sequence. However, we can see one 403 error (forbidden) – it means that the attacker guessed a correct padding sequence. The attacker simply cycles from byte 0x00 to 0xFF, until the response is something different than 500. When the first value has been guessed, the attacker has to XOR it with 0x01 to get the intermediate value (read more at the link shown above). Now the attacker needs to find the second byte of the intermediate value, so the padding needs to be 0x02 – the value that has been already found is first XORed with 0x02 and the second byte is again cycled from 0x00 to 0xFF until a valid sequence has been found. And the process repeats for 0x03 … to 0x10.

This can all be seen in the log file as there are 16 requests that resulted in HTTP status code 403 (among thousands of other requests).
The challenge here was to guess what the attacker retrieved with the first (200) request. In order to decypher this we need to find all the intermediate values by following the process described above. Then we need to XOR the intermediate values with the initialization vector (IV) of the 200 request – the IV are first 16 bytes of the request.

In order to solve this I wrote a simple perl program that does this:

Decoding program

Now we just need to feed the 16 403 requests as STDIN and the program will solve the challenge for us:


This was a fun challenge (my team ended up as #24, but we were too casual ;-).

Anyway, in case you haven’t checked your servers/web applications for oracle padding please do so (there are lots of resources describing how to protect from such attacks). The attacks are real, they work and there are dozens of tools out exploiting this vulnerability.


1 comment(s)

Outbound SSH Traffic from HP Virtual Connect Blades

Published: 2011-03-07
Last Updated: 2011-03-07 17:48:15 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

We had some readers (kuddos for watching your traffic closely!) report outbound traffic from HP Virtual Connect Blades to on port 22.

No response is received from this IP address, and we guess it is a bug. Interestingly (I think Daniel noted it first), 49, 48, 46, 53 happens to be the ASCII code for 1, 0, . , 5 . So we suspect some buggy code trying to use an IP address starting with "10.5" (in this case, the blade's IP address started with "10.5").

To confirm this guess: If you have an HP Virtual Connect Blade, do you see similar traffic? Is it directed at a different IP address? Does the ASCII rule still apply for you?

This workaround helped some users affected by this problem:


Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: HP ssh
2 comment(s)


Diary Archives