Massive list of compromised sites
Our first e-mail this morning was from Dave, who informed us about a compromised site ( hxxp://lawfuel. com /show-release.asp?ID=12419 ). Lorna took the lead on investigating the malware on this site, and in the process ended up with two massive lists of other compromised sites.
We haven't checked them all yet (and probably never will...) but I figure its good to push out a list of these sites before its too late on Friday.
For a list of URLs referenced see http://isc.sans.org/diaryimages/hosts20070601.txt
We haven't checked them all yet (and probably never will...) but I figure its good to push out a list of these sites before its too late on Friday.
For a list of URLs referenced see http://isc.sans.org/diaryimages/hosts20070601.txt
Keywords:
0 comment(s)
Attributing Attacks
Our reader Dean sent us a screen shot from wireshark, showing a scan for VNC servers from 213.176.81.229 (mail.tehran.agri-jahad.ir). Indeed, this system appears to be a mail server in Iran
220 mail.tehran.agri-jahad.ir Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Fri, 1 Jun 2007 20:54:41 +0330
With all the news about "Russia attacking Estonia", this nicely illustrates the problem in attributing attacks like this. Is the mail server in Iran compromised (my guess)? Who is launching the scan? Is it a random script kiddie, some bot herder, some government? If it is a government, which one?
The packets look the same and there is no way to tell the motivation. Only once your system is compromised, you may be able to figure out why they did it (and I rather skip that step). Honeypots can help, but a more sophisticated attacker would likely realized whats going on. On the other hand, a sophisticated attacker may actually use some simple "script kiddie" tools first, in order to hide out in the noise of bot probes.
One way to figure out what's going on is to check how many others are being "hit" by this same IP address. DShield is your tool to do just that. See http://www.dshield.org/ipinfo.html?ip=213.176.81.229 and you will find a few thousand other targets got hit by the same IP address. And port 5900 (VNC) appears to be the main attack method used!
(NB: rather then wireshark screen shots, we prefer raw packet captures)
220 mail.tehran.agri-jahad.ir Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Fri, 1 Jun 2007 20:54:41 +0330
With all the news about "Russia attacking Estonia", this nicely illustrates the problem in attributing attacks like this. Is the mail server in Iran compromised (my guess)? Who is launching the scan? Is it a random script kiddie, some bot herder, some government? If it is a government, which one?
The packets look the same and there is no way to tell the motivation. Only once your system is compromised, you may be able to figure out why they did it (and I rather skip that step). Honeypots can help, but a more sophisticated attacker would likely realized whats going on. On the other hand, a sophisticated attacker may actually use some simple "script kiddie" tools first, in order to hide out in the noise of bot probes.
One way to figure out what's going on is to check how many others are being "hit" by this same IP address. DShield is your tool to do just that. See http://www.dshield.org/ipinfo.html?ip=213.176.81.229 and you will find a few thousand other targets got hit by the same IP address. And port 5900 (VNC) appears to be the main attack method used!
(NB: rather then wireshark screen shots, we prefer raw packet captures)
Keywords:
0 comment(s)
Stupid XSS mistake, and why its so hard to write good code
Stefan Esser (www.hardened-php.net) wrote in earlier to let me know about a XSS issue with the search function for the ISC website. Of course, while I respect his opinion and skills very much, I was first a bit sceptically (after all, I am not exactly suffering from low self esteem). However, he was helpful enough to provide a sample URL showing the problem.
So what happened and why? After all, I keep always saying that a web sites search function is the first spot to look for XSS.
Its pretty simple (and stupid). I pre-fill the search box with the last term a user searched for. This string is pulled from the users session, and the string is stored on the server. So I figured, I don't need to validate it. However, what I missed was that I didn't validate (Actually "escape" is better) right in the first place :-(.
The interesting part is that this issue hadn't been found before. The part that saved me was probably a generic validation for '<script>' tags that is performed on all user input. So defense in depth did work.
I do typically use a "safe_print" function, which is essentially just "print(htmlentities($string))". But well, I didn't use it in the header as some pages do not include the necessary library (you may call that another mistake. It saves a few CPU cycles and disk reads... but hurts you down the road).
Personally, I find that good code review is probably the hardest problem when it comes to these problems. You just can't review your own code (at least I can't). If you want to help: much of the ISC code is available via Sourceforge (look for the "DShield" project).
So what happened and why? After all, I keep always saying that a web sites search function is the first spot to look for XSS.
Its pretty simple (and stupid). I pre-fill the search box with the last term a user searched for. This string is pulled from the users session, and the string is stored on the server. So I figured, I don't need to validate it. However, what I missed was that I didn't validate (Actually "escape" is better) right in the first place :-(.
The interesting part is that this issue hadn't been found before. The part that saved me was probably a generic validation for '<script>' tags that is performed on all user input. So defense in depth did work.
I do typically use a "safe_print" function, which is essentially just "print(htmlentities($string))". But well, I didn't use it in the header as some pages do not include the necessary library (you may call that another mistake. It saves a few CPU cycles and disk reads... but hurts you down the road).
Personally, I find that good code review is probably the hardest problem when it comes to these problems. You just can't review your own code (at least I can't). If you want to help: much of the ISC code is available via Sourceforge (look for the "DShield" project).
Keywords:
0 comment(s)
PHP 5.2.3 released
PHP released PHP version 5.2.3.
From the release notes following security improvements have been made:
- Fixed an integer overflow inside chunk_split() (CVE-2007-2872)
- Fixed possible infinite loop in imagecreatefrompng. (CVE-2007-2756)
- Fixed ext/filter Email Validation Vulnerability (CVE-2007-1900)
- Fixed bug #41492 (open_basedir/safe_mode bypass inside realpath ())
- Improved fix for CVE-2007-1887 to work with non-bundled sqlite2 lib.
- Added mysql_set_charset() to allow runtime altering of connection encoding.
Take care with the fixes not listed as security related as there seem to be at least a few of them that are interesting from either a security application point of view, or just from an availability point of view. E.g.:
- Fixed bug #41353 (crash in openssl_pkcs12_read() on invalid input)
- Fixed bug #41347 (checkdnsrr() segfaults on empty hostname)
If you are on the 5.2 branch best to upgrade ASAP to 5.2.3 .
While recompiling and testing PHP, consider adding in Suhosin from the hardened PHP project, it'll improve your security stance.
--
Swa Frantzen -- NET2S
Keywords:
0 comment(s)
×
Diary Archives
Comments