Deformed TCP Options - Got Packets?
UPDATE
A number of readers have submitted packets which allowed us to correlate some information. John has also been able to provide some additional information.
According to RFC 731 "TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing; a suggested procedure is to reset the connection and log the reason." we have to keep this in mind when looking at the rest of the information available.
Typically this is what we see:
Source:http > target1:1205 Syn, ACK
target1:1205 > source:http RST,ACK xxxxxxxxxx
(ACK is not always evident and where xxxxxxx are changing parameters, depending on the stack)
Generally the source ports are 80, 6667, 6666, and 443. However there are also a number of packets with random source ports between 1024 and about 1300. Ports 1024-1300 are also used as the target port. Looking at the Dshield data for ports 6666 and 6667 there was a small peak for these ports as source ports on the 27/28 Feb.
So we are seeing multiple hosts sending SYN,ACK with truncated option to targets (sometimes both scan the same IP) from known ports. The response is typically a RST, or RST,ACK. The window size is also often changed in the response.
What it looks like is a mapping/fingerprinting exercise using the target stacks' response to bad options. But at this stage the end goal is unclear. We have a few theories on the boil, but to confirm we'll need more info. If you have packets let us know, we are currently especially interested in the RST responses.
MH
We had a reader named John who sent us an email about some unusual traffic they are seeing. I'm curious if this is isolated or widespread. Here is a copy of his email for what they are seeing and an example of 5 packets all destined for different hosts. If you are seeing this, please let us know and if you can send us a packet capture of the traffic. Thanks!!
07:11:45.781421 IP (tos 0x0, ttl 113, id 9433, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1256 > www.xxx.yyy.zzz.1229: S, cksum 0x5ed4 (correct), 2627126762:2627126762(0) ack 257795
6091 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 24d9 4000 7106 4944 81fa 8015 E..0$.@.q.ID....
0x0010: wwxx XXYY 04e8 04cd 9c96 c5ea 99a8 7cfb ...{..........|.
0x0020: 7012 05b4 5ed4 0000 0204 05b4 0102 0403 p...^...........
07:11:51.517325 IP (tos 0x0, ttl 113, id 21659, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1252 > www.xxx.yyy.zzz.1070: S, cksum 0xa40c (correct), 1381904945:1381904945(0) ack 2301
854615 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 549b 4000 7106 764c 81fa 8015 E..0T.@.q.vL....
0x0010: wwxx XXYY 04e4 042e 525e 3231 8933 8397 ........R^21.3..
0x0020: 7012 05b4 a40c 0000 0204 05b4 0102 0403 p...............
07:12:06.816985 IP (tos 0x0, ttl 113, id 5274, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1054 > www.xxx.yyy.zzz.1132: S, cksum 0x90a5 (correct), 404326101:404326101(0) ack 122769195
4 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 149a 4000 7106 10d2 81fa 8015 E..0..@.q.......
0x0010: wwxx XXYY 041e 046c 1819 86d5 492d 17b2 ..b,...l....I-..
0x0020: 7012 05b4 90a5 0000 0204 05b4 0102 0403 p...............
07:12:12.670863 IP (tos 0x0, ttl 113, id 38039, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1088 > www.xxx.yyy.zzz.1204: S, cksum 0x0701 (correct), 269829739:269829739(0) ack 3374363
152 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 9497 4000 7106 d97d 81fa 8015 E..0..@.q..}....
0x0010: wwxx XXYY 0440 04b4 1015 466b c920 b210 .....@....Fk....
0x0020: 7012 05b4 0701 0000 0204 05b4 0102 0403 p...............
07:12:22.675579 IP (tos 0x0, ttl 113, id 29721, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1033 > www.xxx.yyy.zzz.1067: S, cksum 0x2919 (correct), 1872427362:1872427362(0) ack 69068
0305 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 7419 4000 7106 cdbb 81fa 8015 E..0t.@.q.......
0x0010: wwxx XXYY 0409 042b 6f9a f962 292a f1f1 ..E....+o..b)*..
0x0020: 7012 05b4 2919 0000 0204 05b4 0102 0403 p...)...........
A number of readers have submitted packets which allowed us to correlate some information. John has also been able to provide some additional information.
According to RFC 731 "TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing; a suggested procedure is to reset the connection and log the reason." we have to keep this in mind when looking at the rest of the information available.
Typically this is what we see:
Source:http > target1:1205 Syn, ACK
target1:1205 > source:http RST,ACK xxxxxxxxxx
(ACK is not always evident and where xxxxxxx are changing parameters, depending on the stack)
Generally the source ports are 80, 6667, 6666, and 443. However there are also a number of packets with random source ports between 1024 and about 1300. Ports 1024-1300 are also used as the target port. Looking at the Dshield data for ports 6666 and 6667 there was a small peak for these ports as source ports on the 27/28 Feb.
So we are seeing multiple hosts sending SYN,ACK with truncated option to targets (sometimes both scan the same IP) from known ports. The response is typically a RST, or RST,ACK. The window size is also often changed in the response.
What it looks like is a mapping/fingerprinting exercise using the target stacks' response to bad options. But at this stage the end goal is unclear. We have a few theories on the boil, but to confirm we'll need more info. If you have packets let us know, we are currently especially interested in the RST responses.
MH
We had a reader named John who sent us an email about some unusual traffic they are seeing. I'm curious if this is isolated or widespread. Here is a copy of his email for what they are seeing and an example of 5 packets all destined for different hosts. If you are seeing this, please let us know and if you can send us a packet capture of the traffic. Thanks!!
Over the past few weeks we have seen an increase in the number of snort alerts we have been receiving for "Truncated TCP options." Looking at the packets, they appear to be crafted. At first it was one host scanning one of our /16 blocks, then it was another a week later, then one more a couple days later and then a couple every day. some of the times these scans are sourced from random ports, but some times they are sourced from common ports like 80, 443 and 6667. They have come across as syn packets, ack packets (for which there was no initiating syns), or syn/acks (again there were no initiating syns). The destination ports are always within the lowest ephemeral ports (1024-1300), and there is no consistency in the OS of the hosts that do respond. Because so few host do respond to these packets, I believe that one of the objectives of this scan may be to probe firewall configurations (we have a standing policy requiring host based firewalls), but it seems the level of crafting involved would be overkill.
When looking at some of the packets what we see is that the tcp option for mss is called twice, with the second one running past the end of the packet. When I counted the headers based upon the data in the IP and TCP header fields, it appears these packets are the correct length.
07:11:45.781421 IP (tos 0x0, ttl 113, id 9433, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1256 > www.xxx.yyy.zzz.1229: S, cksum 0x5ed4 (correct), 2627126762:2627126762(0) ack 257795
6091 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 24d9 4000 7106 4944 81fa 8015 E..0$.@.q.ID....
0x0010: wwxx XXYY 04e8 04cd 9c96 c5ea 99a8 7cfb ...{..........|.
0x0020: 7012 05b4 5ed4 0000 0204 05b4 0102 0403 p...^...........
07:11:51.517325 IP (tos 0x0, ttl 113, id 21659, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1252 > www.xxx.yyy.zzz.1070: S, cksum 0xa40c (correct), 1381904945:1381904945(0) ack 2301
854615 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 549b 4000 7106 764c 81fa 8015 E..0T.@.q.vL....
0x0010: wwxx XXYY 04e4 042e 525e 3231 8933 8397 ........R^21.3..
0x0020: 7012 05b4 a40c 0000 0204 05b4 0102 0403 p...............
07:12:06.816985 IP (tos 0x0, ttl 113, id 5274, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1054 > www.xxx.yyy.zzz.1132: S, cksum 0x90a5 (correct), 404326101:404326101(0) ack 122769195
4 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 149a 4000 7106 10d2 81fa 8015 E..0..@.q.......
0x0010: wwxx XXYY 041e 046c 1819 86d5 492d 17b2 ..b,...l....I-..
0x0020: 7012 05b4 90a5 0000 0204 05b4 0102 0403 p...............
07:12:12.670863 IP (tos 0x0, ttl 113, id 38039, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1088 > www.xxx.yyy.zzz.1204: S, cksum 0x0701 (correct), 269829739:269829739(0) ack 3374363
152 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 9497 4000 7106 d97d 81fa 8015 E..0..@.q..}....
0x0010: wwxx XXYY 0440 04b4 1015 466b c920 b210 .....@....Fk....
0x0020: 7012 05b4 0701 0000 0204 05b4 0102 0403 p...............
07:12:22.675579 IP (tos 0x0, ttl 113, id 29721, offset 0, flags [DF], proto: TCP (6), length: 48) 129.250.128.21.1033 > www.xxx.yyy.zzz.1067: S, cksum 0x2919 (correct), 1872427362:1872427362(0) ack 69068
0305 win 1460 <mss 1460,nop,[bad opt]>
0x0000: 4500 0030 7419 4000 7106 cdbb 81fa 8015 E..0t.@.q.......
0x0010: wwxx XXYY 0409 042b 6f9a f962 292a f1f1 ..E....+o..b)*..
0x0020: 7012 05b4 2919 0000 0204 05b4 0102 0403 p...)...........
Keywords:
0 comment(s)
Weekend grab bag
After a somewhat slow day at the Storm Center, I wanted to mention a few issues that we've heard about, but not written about in the last few days.
- Joanna Rutkowska was supposed to give a talk on Wednesday at BlackHat DC on a method that could be used to subvert hardware memory access (so rootkits could hide from live response memory captures). I haven't yet seen any details, but it looks like it could be another fascinating/scary development. The Dark Reading article is here.
- David Litchfield of NGSSoftware.com has released a paper that explains that contrary to Oracle's assertions in the past that CREATE PROCEDURE privs were required for many SQL injection attacks to succeed, it turns out that merely the ability to connect to the database (CREATE SESSION privilege) is sufficient. All the more reason to limit the ability to connect to the database, encrypt the connections, and make sure you are using strong authentication.
- The continuing saga of A/V software vulnerable to DoS while attempting to unpack crafted files (previously Symantec, ClamAV and Trend had problems with UPX and Kaspersky with PE) hit Kaspersky again (UPX this time). Apparently, they actually fixed the problem a month ago, but publicly acknowledged it today, see the posting to the vulnwatch list.
- There are a couple of interesting articles this week by folks who have managed to pull browser history without Javascript. We've often recommended the NoScript extension to Firefox, but even that isn't enough anymore. Check out the stories here, here, here, and the "original" one here.
Keywords:
0 comment(s)
Recent Threat/Vulnerability Developments
There have been a few recent minor developments that I think warrant a mention.
There have been a handful of viruses recently that specifically target USB removable media, Win32.Agent,wj and VBS.Solow.E just two mention two. This harks back to the old days of floppy-disk boot-sector viruses. This is not the only old-school re-visitation I've seen in malicious code trends, there have also been a few destructive viruses recently reported.
A vulnerability in Adobe Acrobat that allows a malicious PDF file to call arbitrary file:// URLs was announced last night.
Things to keep an eye on over the weekend:
This Year of MOXB continues with PHP. Something interesting is bound to turn up out of that.
The College Basketball championship begins in the US. I would be surprised to not see any "March Madness" related schemes develop.
There have been a handful of viruses recently that specifically target USB removable media, Win32.Agent,wj and VBS.Solow.E just two mention two. This harks back to the old days of floppy-disk boot-sector viruses. This is not the only old-school re-visitation I've seen in malicious code trends, there have also been a few destructive viruses recently reported.
A vulnerability in Adobe Acrobat that allows a malicious PDF file to call arbitrary file:// URLs was announced last night.
Things to keep an eye on over the weekend:
This Year of MOXB continues with PHP. Something interesting is bound to turn up out of that.
The College Basketball championship begins in the US. I would be surprised to not see any "March Madness" related schemes develop.
Keywords:
0 comment(s)
Total Lunar Eclipse
I realize this has absolutely nothing to do with infosec....but on Saturday March 3rd there will be a really cool total lunar eclipse. NASA has the details on their web site. For most of Asia and the Americas you will see it at moonset or moonrise respectively, Europe and Africa will enjoy it at night. For our mates in eastern Australia and New Zealand you'll just have to watch it on TV.
So if your systems go haywire this weekend you'll have a good story to blame it on. "Boss, there was a full moon, a total lunar eclipse, and for all I know sunspots were acting up....." Your management will have no choice but to believe you.
Marcus H. Sachs
Director, SANS Internet Storm Center
So if your systems go haywire this weekend you'll have a good story to blame it on. "Boss, there was a full moon, a total lunar eclipse, and for all I know sunspots were acting up....." Your management will have no choice but to believe you.
Marcus H. Sachs
Director, SANS Internet Storm Center
Keywords:
0 comment(s)
Manager/Media Impact
Did you day start off something like this?
Boss-type-person rushes into room waving a print out of New computer virus threatens biz net and demanding to know "what you're doing about it."
Hopefully, you were able to tell them that you'd already deployed the patch for the vulnerability back in November 2006, that your perimeter doesn't allow inbound TCP/2967 nor TCP/2968, and that your AV signatures were up-to-date. Then you should have been able to lean back, put your feet up on the desk and say: "see, this is why you pay me the big bucks-- so you don't appear CNN articles."
If your day didn't go as smoothly, you have my sympathies. I spent more time today on conference calls, impromptu hallway meetings, and writing up briefings for what should have (and so far has actually been) a non-event for our environment.
This is not the first time that I've been impacted by non-event events. It's why I have to monitor eWeek, so I have a heads up on what the suits are going be asking about that morning.
I didn't keep careful track, but one of the many repeated phrases of the day was "Money dot CNN is not going to produce a computer security scoop." It's possible, just not probable.
I'm proposing we update our impact models expanding them from Confidentiality, Integrity, and Availability to include Management. I'm joking, but only slightly. More realistically, I will update our criteria of releasing internal communications to include media/manager impact. This has happened enough that it needs to become part of my process.
Boss-type-person rushes into room waving a print out of New computer virus threatens biz net and demanding to know "what you're doing about it."
Hopefully, you were able to tell them that you'd already deployed the patch for the vulnerability back in November 2006, that your perimeter doesn't allow inbound TCP/2967 nor TCP/2968, and that your AV signatures were up-to-date. Then you should have been able to lean back, put your feet up on the desk and say: "see, this is why you pay me the big bucks-- so you don't appear CNN articles."
If your day didn't go as smoothly, you have my sympathies. I spent more time today on conference calls, impromptu hallway meetings, and writing up briefings for what should have (and so far has actually been) a non-event for our environment.
This is not the first time that I've been impacted by non-event events. It's why I have to monitor eWeek, so I have a heads up on what the suits are going be asking about that morning.
I didn't keep careful track, but one of the many repeated phrases of the day was "Money dot CNN is not going to produce a computer security scoop." It's possible, just not probable.
I'm proposing we update our impact models expanding them from Confidentiality, Integrity, and Availability to include Management. I'm joking, but only slightly. More realistically, I will update our criteria of releasing internal communications to include media/manager impact. This has happened enough that it needs to become part of my process.
Keywords:
0 comment(s)
Its been a malware kind of Day
Well, when it rains it pours and today it seems it has been raining malware. Although, I can't say I'm sad since I enjoy playing with malware so much. We have been busy doing to analysis on three different pieces of malware that had been submitted to us. Due to space constraints, I'm only going to post information on one of them below that was the most interesting. We also looked at malware that appeared to be a more targeted attack on a group and the latest RINBOT/DELBOT or whatever you want to call that bot variant.
One of the is the first things I'd like to highlight is the recent news media attention to that has been generated over the latest version of RINBOT/DELBOT/SDBOT (depending on the AV folks your talking to). I only bring this up since we've had many people writing in and wanting to know if we were going to post a diary on this. I'm only going to post a few thoughts and then move on. We already covered this malware in a previous diary entry. The only that that seems to have changed is maybe an update to the vulnerabilities it can use to spread and the latest rant at whoever the author is mad at now. In this case, Symantec seems to be the target now. With that in mind, its surprising that its getting so much publicity when its just another bot variant. It is sad, but bots are very common place on the internet today.
Now, on to some other interesting pieces of malware that are new. We received an email from a reader named Chris who had a user report their system attempted to connect to a remote network. The firewall alert ed the user to the outbound traffic. The file that requested the outbound traffic was a file called ~.exe. A few of us looked at the file, but saw nothing malicious about the file itself. It opened a message box with a title of OK. No outbound traffic occurred. After a few more email exchanges, we got some more critical information:
Nice, now we have a good starting point. Several of us did some analysis on how the site was doing the exploit. I would like to post the results from fellow handler Bojan Zdrnja who did an outstanding job with this, especially the de-obfuscation of the javascript. For those wanting to try their hand at it, Bojan used the SpiderMonkey technique described here. Now for his analysis of what was found:
So, check your logs. And remember its not a very nice site if you decide to play:>)
One of the is the first things I'd like to highlight is the recent news media attention to that has been generated over the latest version of RINBOT/DELBOT/SDBOT (depending on the AV folks your talking to). I only bring this up since we've had many people writing in and wanting to know if we were going to post a diary on this. I'm only going to post a few thoughts and then move on. We already covered this malware in a previous diary entry. The only that that seems to have changed is maybe an update to the vulnerabilities it can use to spread and the latest rant at whoever the author is mad at now. In this case, Symantec seems to be the target now. With that in mind, its surprising that its getting so much publicity when its just another bot variant. It is sad, but bots are very common place on the internet today.
Now, on to some other interesting pieces of malware that are new. We received an email from a reader named Chris who had a user report their system attempted to connect to a remote network. The firewall alert ed the user to the outbound traffic. The file that requested the outbound traffic was a file called ~.exe. A few of us looked at the file, but saw nothing malicious about the file itself. It opened a message box with a title of OK. No outbound traffic occurred. After a few more email exchanges, we got some more critical information:
"The user states that their Firewall (COMODO Firewall Pro) alerted to it after visiting hxxp://www.owned.com/Owned_Pictures - they checked the site again and NOD32
alerted to the webpage containing an unknown PE virus."
Nice, now we have a good starting point. Several of us did some analysis on how the site was doing the exploit. I would like to post the results from fellow handler Bojan Zdrnja who did an outstanding job with this, especially the de-obfuscation of the javascript. For those wanting to try their hand at it, Bojan used the SpiderMonkey technique described here. Now for his analysis of what was found:
The initial infection site is definitely http:// www [dot]
owned.com/Owned_Pictures (oh irony, looks like they've been owned).
On that web page there is an iframe which points to http://www [dot]
trudomain.com/hello.html. That is an obfuscated JavaScript which isn't
completely trivial to deobfuscate.
However, once you manage to do that, you will see that it is just
another iframe that will send your browser to http://www [dot]
porcosnet.com/cgi-bin/e/neo/neosploit?p=alert.
This page contains a bigger obfuscated JavaScript which attempts to
exploit a bunch of vulnerabilities. Among the usual MSXML2 and
ADODB.Stream exploits, it also contains exploit for the
WebViewFolderIcon vulnerability, for the WinZIP vulnerability and for
a QuickTime vulnerability.
Finally, if the exploit ran successfully, it will download an
executable from the same sie (www [dot] porcosnet.com). I haven't seen
the ~.exe file, but this is definitely malicious so I would suggest
that you thoroughly check the infected machine (and rebuild, if
possible).
So, check your logs. And remember its not a very nice site if you decide to play:>)
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments