Update Firefox to 1.5.0.1, the exploit is out
Exploit code for the recently announced Mozilla Firefox 1.5 QueryInterface() Remote Code Execution has been released as a part of the metasploit framework. Get yours today, firefox update to 1.5.0.1 that is (No links to exploits here, sorry) .
See http://isc.sans.org/diary.php?storyid=1091 for more details.
In addition, Thunderbird is vulnerable if Javascript is enabled. It is not by default. There is no update for Thunderbird available at this time.
See http://isc.sans.org/diary.php?storyid=1091 for more details.
In addition, Thunderbird is vulnerable if Javascript is enabled. It is not by default. There is no update for Thunderbird available at this time.
Keywords:
0 comment(s)
Old Cisco exploit tries to make a return:
Patrick Harper reported seeing attempts to access the http server in cisco routers with an old exploit (reported and fix in 2001) using level 16 to bypass authentication like this:
GET /level/16/exec/-///pwd HTTP/1.0
He reported seeing this traffic from many sources.
This has been fixed in IOS some time ago. However someone thinks they can get lucky and find some out of date routers.
Handler Don Smith advises: "Reporting this to the ISPs is a good idea.
They are often interested in anyone who is trying to break into a router:)"
One interesting property of this traffic is that it is not spoofed, a TCP 3-way handshake must be completed with the target before sending HTTP data such as a GET. That is true of all TCP based scans. TCPDUMP shows a P for PUSH so both ends are really talking. In a spoofed scan you never get farther than SYN. The SYN-ACK is sent back to the spoofed source who drops it most likely.
AAA.BBB.CCC.DDD.1873 > WWW.XXX.YYY.ZZZ.http: P [tcp sum ok] 99999
13645:1403813683(38) ack 221455884 win 64860 (DF) (ttl 107, id 46390, len 78)
2. The exploit is an old one, so why is it in circulation again?
Here is the original advisory form Cisco:
http://www.cisco.com/warp/public/707/IOS-httplevel-pub.html
Best practices dictate turning off all unused services on a host. So go to your border router and if it does now have
"no ip http server"
in the configuration add it now. This will prevent this or any new http exploit from working on your router.
Some old tricks keep coming back, and Patrick thanks for sharing.
GET /level/16/exec/-///pwd HTTP/1.0
He reported seeing this traffic from many sources.
This has been fixed in IOS some time ago. However someone thinks they can get lucky and find some out of date routers.
Handler Don Smith advises: "Reporting this to the ISPs is a good idea.
They are often interested in anyone who is trying to break into a router:)"
One interesting property of this traffic is that it is not spoofed, a TCP 3-way handshake must be completed with the target before sending HTTP data such as a GET. That is true of all TCP based scans. TCPDUMP shows a P for PUSH so both ends are really talking. In a spoofed scan you never get farther than SYN. The SYN-ACK is sent back to the spoofed source who drops it most likely.
AAA.BBB.CCC.DDD.1873 > WWW.XXX.YYY.ZZZ.http: P [tcp sum ok] 99999
13645:1403813683(38) ack 221455884 win 64860 (DF) (ttl 107, id 46390, len 78)
2. The exploit is an old one, so why is it in circulation again?
Here is the original advisory form Cisco:
http://www.cisco.com/warp/public/707/IOS-httplevel-pub.html
Best practices dictate turning off all unused services on a host. So go to your border router and if it does now have
"no ip http server"
in the configuration add it now. This will prevent this or any new http exploit from working on your router.
Some old tricks keep coming back, and Patrick thanks for sharing.
Keywords:
0 comment(s)
A Bump in the Wire
Watching the ports, there is a bit of activity on two that are of interest to us. Take a look at your local flows and see if you are detecting increases on tcp/7212 and tcp/32768. If you have any packet captures or analysis, please send it to us via our contact form. Thanks!
Update
We got quite a number of responses regarding the TCP 7212 traffic. Jose Nazario si reporitng that he traced the scans to a proxy called "Ghostsurf". This proxy is frequently left open allowing others to hide behind it.
A netcat listener recorded traffic that supports this idea:
Update
We got quite a number of responses regarding the TCP 7212 traffic. Jose Nazario si reporitng that he traced the scans to a proxy called "Ghostsurf". This proxy is frequently left open allowing others to hide behind it.
A netcat listener recorded traffic that supports this idea:
GET http://umsky.com/prx.php?p=p1234 HTTP/1.0
Accept: */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Host: umsky.com
Connection: Keep-Alive
Only a small set of sources is currently scanning for this port.
Keywords:
0 comment(s)
Corrupted Nyxems
The news about Nyxem (CME-24) are slowly ending, but the number of infected messages which are sent around still seems to be pretty high. Besides "normal" e-mails with Nyxem, we had couple of submissions (and noted this on couple of servers as well) about corrupted attachments.
Message bodies in these samples are completely the same as those being sent with working attachments, and the only difference seems to be in corrupted attachments.
If you remember, in some cases Nyxem will send MIME attachments; this was probably an attempt by the author to circumvent various filtering engines which may not expect an uuencoded file embedded in a base64 encoded MIME message part.
Beginning of those encoded files is almost always OK, and after couple of lines it gets corrupted.
The corrupted part will look similar to the one below (first line is from the good version, second from corrupted):
M3%!T;T10``!#;U1A<VM-96U&<F5E````1V5T1$,`````````!X;<,@````#V
M3%!T;T10``!#;U1A<VM-96U&<F5E````1V5T1$,`````````````````
The letter 'M' at the start of each line indicate the unencoded line length, which in this case should be 60 (77d - 32d = 45d = M; 45 characters were encoded to 60). You can see that the line length in the second example is less than 60, so it is clear that the encoding is damaged.
If you now try to decode this (for example, uudecode will try to decode this and will complain about an error), you'll get a corrupted executable. This file still has a valid header, so if you policy dictates blocking of executables on the e-mail gateway, this will be blocked.
Majority of AV vendors doesn't detect this. Of course, the file is harmless so theoretically there is no reason why they should detect this, but it would probably be nice to add definitions for these corrupted attachments, just so they don't confuse end users.
We've received submission from one of our readers that McAfee detects this as Generic Malware.a!zip.
Thanks to Mark Ackermans for a nice analysis of what's going on with the corrupted attachments.
Message bodies in these samples are completely the same as those being sent with working attachments, and the only difference seems to be in corrupted attachments.
If you remember, in some cases Nyxem will send MIME attachments; this was probably an attempt by the author to circumvent various filtering engines which may not expect an uuencoded file embedded in a base64 encoded MIME message part.
Beginning of those encoded files is almost always OK, and after couple of lines it gets corrupted.
The corrupted part will look similar to the one below (first line is from the good version, second from corrupted):
M3%!T;T10``!#;U1A<VM-96U&<F5E````1V5T1$,`````````!X;<,@````#V
M3%!T;T10``!#;U1A<VM-96U&<F5E````1V5T1$,`````````````````
The letter 'M' at the start of each line indicate the unencoded line length, which in this case should be 60 (77d - 32d = 45d = M; 45 characters were encoded to 60). You can see that the line length in the second example is less than 60, so it is clear that the encoding is damaged.
If you now try to decode this (for example, uudecode will try to decode this and will complain about an error), you'll get a corrupted executable. This file still has a valid header, so if you policy dictates blocking of executables on the e-mail gateway, this will be blocked.
Majority of AV vendors doesn't detect this. Of course, the file is harmless so theoretically there is no reason why they should detect this, but it would probably be nice to add definitions for these corrupted attachments, just so they don't confuse end users.
We've received submission from one of our readers that McAfee detects this as Generic Malware.a!zip.
Thanks to Mark Ackermans for a nice analysis of what's going on with the corrupted attachments.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments