Security archive
How to proceed if you were a victim in the attack against DreamHost
2007-06-07 13:46
Like about 3500 other people, me, my site and my accounts fell victim to the massive account attack against DreamHost (see here and here for a few other people burnt by it).
The anatomy of my attack was somewhat different from what Dave Shea experienced, as I saw that all files whose names matched the regular expression .*index.* got replaced with a 130-byte file with the following content (URLs deliberately removed).
<!-- ~ --><iframe src='[URL REMOVED]' width=1 height=1 style='visibility: hidden;'></iframe><!-- ~ -->As I was in the process of mailing DreamHost support, changing my passwords and cleaning up, the attack was still ongoing, and the contents of these files changed again:
<!-- ~ --><iframe src='[URL REMOVED]' width=1 height=1 style='visibility: hidden;'></iframe><!-- ~ -->
<iframe src="[DIFFERENT URL REMOVED]" width=1 height=1></iframe>
What hides behind the removed URLs?
Well, suffice it to say that I believe organized crime is behind it. Upon inspecting the removed domain, I Googled for the domain, and was met with this search result
Yes, that’s Google’s malware warning service for search results.
Upon snooping around on the site where iframe injected, I discovered a zip file of about four megabytes. A cursory glance at the file reveals that the zip file contains what seems to be keylogs, contained within about 1000 files, as from the output of find . | wc -l. I have not conducted a deeper analysis of the contents of the file, since it’s not my business discovering user’s passwords and personal information. However, I urge any relevant authorities to do just that.
What to do first?
Here is what you do, regardless of you having seen infection or not:
- Change all of your affected DreamHost passwords! For all of your users! This is extremely crucial.
If you have seen infection:
- Inform DreamHost of your situation using the support wizard;
- Read to the end of this blog post. Seriously.
If you’ve gotten an e-mail from DreamHost informing you that any of your accounts may be at risk:
- Read to the end of this blog post. Seriously.
How to locate infected files?
In the case of my attack, all of the infected files had the unique marker — which means that I could locate all of the files by ssh’ing into my account, and search for all files containing this string (replace USERNAME with your own login name):
$ find . -user USERNAME -exec grep -l "<\!-- ~ -->" \{\} \; > result.txtIf the anatomy of the attack against you is different, you may instead try searching for all files that have been modified within a given time interval:
$ find . -mtime 3 -user USERNAME > result.txtHow to restore infected files?
DreamHost has a self-service backup, called Automated domain snapshots contained in a directory named .snapshot, containing the following directories: hourly.0, hourly.1, nightly.0, nightly.1, weekly.0 and weekly.1. If any of your files are infected, go to that directory’s snapshot, locate an unaltered file and restore it. For instance, let’s assume the folder “myharmedfolder” contains an infected index.html that has been altered.
$ cd myharmedfolder/.snapshot/weekly.1
$ rm ../../index.html && cp index.html ../../Note that just copying the file over may not work, because the cp command will just claim that the files are one and the same, so you need to remove the infected copy first.
I’ve changed all my passwords, cleaned any infected files, been declared healthy by DreamHost. Is there anything more I need to do?
Indeed, there is, and I really should not need to say this, but I will: Call your bank, and block any credit card you have used with DreamHost!
Upon discovering what had happened to my account, had changed passwords, cleaned up, and was back to normal, I called my bank. They told me to call Visa Norway to ask for further advice. What Visa’s security department told me was this: Even if DreamHost, as they stated in the e-mail they sent to affected customers, has no reason to believe that credit card information was lost, you should, regardless of DreamHost’s statement, block any cards that you have used with DreamHost. There is a very simple reason to do this: If DreamHost are right, and your CC info is safe, you have lost nothing but the time it took you to block the account, and any amount it may cost you to get a new account opened. If DreamHost on the other hand are wrong, and your CC info has leaked, your old account is unusable to the criminals who performed the break-in. Further, if you knew about the attack, and don’t change your card as adviced by Visa in such cases, you may yourself be liable to costs incurred (this might depend on jurisdiction, but this is the case, at least in Norway). If you are deemed liable, you usually have to cover all the costs yourself. The moment you block your card, your liability goes away. Simple as that. If you were among the attacked, go ahead and block your credit(debit) card now.
Sony, Rootkits and Digital Rights Management Gone Too Far
2005-11-01 10:06
Link: Sony, Rootkits and Digital Rights Management Gone Too Far
Mark Russinovich of Sysinternals has a very detailed breakdown of how Sony installs a rootkit when you use some of their “Audio” CDs. His writeup is very enlightening, detailed, and not to say the least: Shocking.
Personally, I think it’s time that the record labels got sued over their increasingly intrusive DRM schemes. What Sony are doing now, is in effect no better than what crackers get prosecuted over. I actually think DRM is worse, since it prohibits people of legally using media they paid for and bought. DRM is all about punishing the wrong crowd: Those who do want to copy, and don’t ever want to pay, will still get what they want.
MT Blacklist to mod_security
2005-02-27 23:01
Link: MT Blacklist to mod_security
blacklist_to_modsec.pl will allow you to export MT Blacklist URLs to mod_security rules. Quite handy for dealing with a lot of spam related problems.
Stop using Internet Explorer! Now!
2005-01-09 17:42
Secunia is, again, reporting multiple vulnerabilities in Internet Explorer
Now is the time to get rid of Internet Explorer. It is a product which is defective and insecure by design. It is a dangerous product.
JavaScript execution in Thunderbird
2004-12-20 01:33
Link: JavaScript execution in Thunderbird
Thunderbird executes JavaScript in text/html mail when mail is printed, or when print preview is invoked. Temporary solution: Print mail only from trusted sources.
Internet Explorer is the problem
2004-02-20 19:26 – Six comments
Why Internet Explorer poses both a security threat and an economic threat to webhosts in particular, and everyone on the Internet in general.
Opera 7.20 beta 1 vulnerability
2003-07-23 00:49 – Leave a comment
A vulnerability in M2, the mail client in Opera 7.20 beta 1 allows malicious users to use mail bugs.
Opera vulnerabilities
2003-02-05 00:19 – Leave a comment
Five security holes discovered in Opera. 19 unpatched holes in Internet Explorer