fragmented packet challenge
Before signing off for the day and handing the helm over to Chris, I got one more diary for you.
This one is a challenge. Michael sent us this packet earlier today. He is seeing a lot of these hitting his mail server, all from the same source. I got some ideas about whats going on, but nothing "definite". So let me just show you the packet and see what you can come up with. I will post my opinion (and a summary of what you submit sometime late tomorrow.
The short summary of the packet:
- its the last fragment (MF is cleared, offset is 1472
- there are 8 bytes worth of payload
- the protocol is TCP
I obfuscated pieces that would help identify the submitter.
Update
This one is a challenge. Michael sent us this packet earlier today. He is seeing a lot of these hitting his mail server, all from the same source. I got some ideas about whats going on, but nothing "definite". So let me just show you the packet and see what you can come up with. I will post my opinion (and a summary of what you submit sometime late tomorrow.
The short summary of the packet:
- its the last fragment (MF is cleared, offset is 1472
- there are 8 bytes worth of payload
- the protocol is TCP
I obfuscated pieces that would help identify the submitter.
Update
I received a couple or interesting responses to this "challenge". Couple people noted that the offset + packet length is 1480, which would be in line with a regular ethernet MTU of 1500 bytes.
Alex had a couple of interesting insights: He noted that the 8 bytes of data are consistent with Base64 encoded data. While there is not enough data here to reconstruct any content, he suggests it may be one of the many "spam images" going around these days.
Also, he menioned that 1472 is a common MTU for PPPoE DSL connections.
So a likely reason for the fragment is that the host is connected to a local ethernet network which is using a DSL uplink.
The reason the first fragment is missing is likely some kind of packet filtering device. Given that only the first fragment will include the port number, the packet filter allows the second fragment to pass.
Lessons learned:
- If you are using a DSL modem with PPPoE, take a look at what MTU it supports. Your internet experience may improve if you reduce your MTU to match the DSL modems MTU.
- Check how your border device deals with fragments. I typically like to put some kind of statefull firewall at my border that will reassemble fragments. Most of the home-devices (NAT routers) typically do a good job at that. Its a bit more challenging to find one that can deal with large loads (in particular if you have a lot of connections. The bandwidth is sometimes not as critical here as the number of connections you are trying to support.
Thanks to everyone who responded!
Alex had a couple of interesting insights: He noted that the 8 bytes of data are consistent with Base64 encoded data. While there is not enough data here to reconstruct any content, he suggests it may be one of the many "spam images" going around these days.
Also, he menioned that 1472 is a common MTU for PPPoE DSL connections.
So a likely reason for the fragment is that the host is connected to a local ethernet network which is using a DSL uplink.
The reason the first fragment is missing is likely some kind of packet filtering device. Given that only the first fragment will include the port number, the packet filter allows the second fragment to pass.
Lessons learned:
- If you are using a DSL modem with PPPoE, take a look at what MTU it supports. Your internet experience may improve if you reduce your MTU to match the DSL modems MTU.
- Check how your border device deals with fragments. I typically like to put some kind of statefull firewall at my border that will reassemble fragments. Most of the home-devices (NAT routers) typically do a good job at that. Its a bit more challenging to find one that can deal with large loads (in particular if you have a lot of connections. The bandwidth is sometimes not as critical here as the number of connections you are trying to support.
Thanks to everyone who responded!
Frame 1 (60 bytes on wire, 60 bytes captured)
Arrival Time: Nov 8, 2006 10:46:21.288548000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 60 bytes
Capture Length: 60 bytes
Protocols in frame: eth:ip:data
Ethernet II, Src: (xx:xx:xx:xx:xx:xx), Dst: (xx:xx:xx:xx:xx:xx)
Type: IP (0x0800)
Trailer: 000000000000000000000000000000000000
Internet Protocol, Src: xxx.yyy.171.21 Dst: aaa.bbb.181.18
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 28
Identification: 0xdf49 (57161)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 1472
Time to live: 112
Protocol: TCP (0x06)
Header checksum: 0xXXXX [correct]
Good: True
Bad : False
Source: xxx.yyy.171.21
Destination: aaa.bbb.181.18
Data (8 bytes)
0000 75 37 68 4c 52 65 2b 4d u7hLRe+M
Keywords:
0 comment(s)
Microsoft Security Bulletin Advanced Notification
Thanks Juha-Matti, Bryan and all the others for letting us know that the monthly Microsoft Security Bulletin Advanced Notification is out.
If you don't receive the e-mail from Microsoft, or you have not yet looked at it, here is a quick summary courtesy of Bryan.
If you don't receive the e-mail from Microsoft, or you have not yet looked at it, here is a quick summary courtesy of Bryan.
- 1 patch affecting "XML Core Services", rated "critical", will require a reboot
- 5 patches affecting Windows, maximum rating "critical", some of these will require a reboot
- New "Malicious Software Removal Tool"
- 2 additional "non-security high-priority updates" will be released, but only on Microsoft Update and WSUS
Keywords:
0 comment(s)
MSXML 4.0 exploit in the wild
We've received a report of the MSXML 0-day exploit being used in the wild. This is the exploit Johannes wrote a couple of days ago (http://isc.sans.org/diary.php?storyid=1825).
The exploit does not seem to be in wide use just yet, but that can, of course (and we expect it to), change very quickly.
For the exploit to work it *needs* Microsoft XML Core Services to be installed. Microsoft XML Core Services are not installed by default on Windows XP, but there seems to be a lot of packages using it, Visual Studio appears to be one common one. You can check in the Add or Remove Programs applet if you have it installed.
The exploit works in both IE6 and IE7, which makes sense since it's exploiting a vulnerability in an ActiveX object, not in the browser itself.
When executed the exploit creates an MSXML 4.0 ActiveX object (88d969c5-f192-11d4-a65f-0040963251e5). It then uses multiple setRequestHeader() method calls to execute shellcode which is included with the exploit.
Once executed the shellcode (of course) first downloads the first stage downloader. At the moment it's a file called tester.dat:
16ac9982d177a47a20c4717183493e95 tester.dat
This downloader then downloads subsequent files (yet to be analysed).
It looks like some AV vendors are beggining to detect the exploit. At this moment it is being detected by McAfee as Exploit-XMLCoreSrvcs and Symantec as Bloodhound.Exploit.96. Microsoft also detects it as Exploit:HTML/Xmlreq.A.
The best protection, is to prevent the XMLHTTP 4.0 ActiveX Control from running in Internet Explorer, as stated in Microsoft's advisory: http://www.microsoft.com/technet/security/advisory/927892.mspx.
Update: Snort Rule: 8727 and 8728
The exploit does not seem to be in wide use just yet, but that can, of course (and we expect it to), change very quickly.
For the exploit to work it *needs* Microsoft XML Core Services to be installed. Microsoft XML Core Services are not installed by default on Windows XP, but there seems to be a lot of packages using it, Visual Studio appears to be one common one. You can check in the Add or Remove Programs applet if you have it installed.
The exploit works in both IE6 and IE7, which makes sense since it's exploiting a vulnerability in an ActiveX object, not in the browser itself.
When executed the exploit creates an MSXML 4.0 ActiveX object (88d969c5-f192-11d4-a65f-0040963251e5). It then uses multiple setRequestHeader() method calls to execute shellcode which is included with the exploit.
Once executed the shellcode (of course) first downloads the first stage downloader. At the moment it's a file called tester.dat:
16ac9982d177a47a20c4717183493e95 tester.dat
This downloader then downloads subsequent files (yet to be analysed).
It looks like some AV vendors are beggining to detect the exploit. At this moment it is being detected by McAfee as Exploit-XMLCoreSrvcs and Symantec as Bloodhound.Exploit.96. Microsoft also detects it as Exploit:HTML/Xmlreq.A.
The best protection, is to prevent the XMLHTTP 4.0 ActiveX Control from running in Internet Explorer, as stated in Microsoft's advisory: http://www.microsoft.com/technet/security/advisory/927892.mspx.
Update: Snort Rule: 8727 and 8728
Keywords:
0 comment(s)
Windows WMIObjectBroker (Visual Studio 2005) 0-Day Exploit
Rohit from Tippingpoint adviced us that he is seeing a large number of attacks from Russia using an un-patched vulnerability in the WMIObjectBroker ActiveX control (CVE-2006-4704). He is seeing it used as part of a drive-by download. Typically, the Trojan "Galopoper.A" is load.
There is no patch available at this point. Tippingpoint and the Bleedingthreats projects have signatures available to detect this attack. Rohit mentioned that there is a metasploit module for this vulnerability.
The WMIObjectBroker ActiveX compontent is part of Visual Studio 2005 and associated with the WmiScriptUtils.dll . So you are only vulnerable if you find WmiScriptUtil.dll on your system. Also, by default this ActiveX component is not activated by default. For more details about this vulnerability see http://www.microsoft.com/technet/security/advisory/927709.mspx
Update: Snort rules: 8369 and 8370.
There is no patch available at this point. Tippingpoint and the Bleedingthreats projects have signatures available to detect this attack. Rohit mentioned that there is a metasploit module for this vulnerability.
The WMIObjectBroker ActiveX compontent is part of Visual Studio 2005 and associated with the WmiScriptUtils.dll . So you are only vulnerable if you find WmiScriptUtil.dll on your system. Also, by default this ActiveX component is not activated by default. For more details about this vulnerability see http://www.microsoft.com/technet/security/advisory/927709.mspx
Update: Snort rules: 8369 and 8370.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments