Thanks to Nate from CF-Talk I have a copy of the malicious VBS script that is doing the damage. If you are being victimized by this attack and you need to see the script for whatever purpose, let me know and I will make sure you get a copy. I now it goes without saying, but just don't run it :).

Meanwhile there is some consensus, given the root access of this code, that an infected server cannot be trusted even after a thorough cleaning. Dave Watts and Tom Chiverton both gave such advice. While it's not always possible and it's a huge hassle, it might be the best solution to bite the bullet and do it.

For those of you who have been following the Iframe injection attack saga (see Iframe Insertion on Index.* Home pages) I have an update. I would like to thank one of my readers named Kumar for referring me to this excellent article (a PDF File) on Black Hat. The article seems to pinpoint the origin and nature of the attack. The document describes an attack in depth with multiple steps (just as we had speculated). The first step was an SQLi attempt. But failing that the attacker compromised the server in a rather ingenious fashion.

• Using an image upload capability he uploaded a file to the server that "looked" like an image but was not.
• The file (containing executable code) was then hit with GET and POST requests.
• The payload of the get and post requests was able to set up scheduled tasks to append the JS code to "index.*" files on a timed basis.

This file that was uploaded was a CDX file. On a properly configured IIS server this attack would fail to succeed. Here's why.

[More]

There's a hack that's beginning to be active that targets pages named "index.*". Actually it sounds rather like an old hack that is resurfacing. Since many ColdFusion sites use this convention for the home page this attack tends to hit quite a few ColdFusion sites that are vulnerable. The attack appends a script like this one to the bottom of each "index.*" page:

Please note that I have not included the actual url of this attack. The domain includes the string "said7". I am only making sure I mention said7 so that folks searching for info on this attack can find this specific post and possibly be helped. I have no wish to benefit the said7 effort and I hope they all get dysentery and spend the weekend in the latrine.

As you can see the script itself is pretty simple. It writes out an invisible Iframe to the bottom of the page. The target of the Iframe attempts to download a trojan or malware to the users machine. This attack is insidious and I have yet to discover the origin. But I do know a few things about it - and how to prevent it from continuing. One important thing to note, if you have this problem and Google indexes your sites and sees these pages they will flag your site. Browsers like Firefox use the Google service to throw up a big "malware" warning.

The following article details the attack and the notes I've gathered about it. Some day soon I hope to post a more definitive who, what, when and why post about it. To gather the following notes I'm indebted to the folks on the CF-Talk List (this thread), Nathan, Nick, Jason, Scott, Don and probably a few others I am forgetting. I can't give away too much info here - but please accept my thanks.

[More]

I promised some information from the seminar on application security by Shlomy Gantz. This post is the first of what I hope is 3 or 4 posts unveiling some little thought about security issues when you are doing application programming. Of course we all know about cross site scripting (XSS), SQL injection attack (SIA) and acronym overload seizure (AOS). If you don't, you can find examples of the first two in part IV of my series on the Security Pyramid. In this article I'd like to explore what Shlomy called "HTML Injection". Now I knew that this little gem existed but mostly I thought of it as a XSS attack - where a user is able to place JavaScript designed to steal information from other unsuspecting users into a page (as in my cookie example). What Shlomy did was much harder to detect.

[More]

This is the fourth and final episode in the series, "the security pyramid". This entry covers the topic of "Personal Health", securing your application code. We cover cross site scripting, SQL injection attacks and a number of other topics. This podcast is nearly half an hour long. The examples I talk about in the podcast are covered in the original post. Posts from the other 4 parts of the series are listed below. Thanks for listening!

Listen Here

• Intro
• Part I
• Part II
• Part III
• Part IV

This is the third in a series of 4 podcasts (I know, it was supposed to be 3) on the subject of "the security pyramid". This one covers the topic of "the neighborhood" where your application lives. The topic covers security issues related to your server configuration, coldfusion, and integration with external resources. All of the material covered in the podcasts is also covered in the 5 posts listed below, although the podcasts often include items that are not in the posts. Click on Part III below for the written vresion of this particular podcast. Thanks for listening!

Listen Here

• Intro
• Part I
• Part II
• Part III
• Part IV

This is the second of 3 podcasts on the subject of "the security pyramid". This one covers the topic of "internal network policy". All of the material covered in the podcasts is also covered in the 5 posts listed below, although the podcasts often include items that are not in the posts. Thanks for listening!

Listen Here

• Intro
• Part I
• Part II
• Part III
• Part IV

This podcasts covers the first 2 sections of my recent series on the security pyramid, the introduction and the border patrol. The podcasts often include items that are not in the posts. Thanks for listening!

Listen Here

• Intro
• Part I
• Part II
• Part III
• Part IV

Is your site vulnerable to SQL Injection Attack? How about Cross Site Scripting? Are you even sure you know enough about those 2 vulnerabiities to protect against them?

This post is a continuation of a 5 part series on security called "The Application Security Pyramid". The introduction introduced a new metaphor for dealing with security that loosely mimics Maslow's heirarchy of self-actualization. In Part I I discussed the importance of "border patrol" technology to safeguard your network. In part II I discussed internal Policing and People Policy. In Part III I discussed the importance of managing the security framework of your actual application and how it relates to it's specific environment. In this, our final post in the series, we will discuss securing your application code itself.

• Intro
• Part I
• Part II
• Part III

[More]

This post is a continuation of a 5 part series on security called "The Application Security Pyramid". The introduction introduced a new metaphor for dealing with security that loosely mimics Maslow's heirarchy of self-actualization. In Part I I discussed the importance of "border patrol" technology to safeguard your network. In part II I discussed internal Policing and People Policy. In this post we will deal with the importance of maintinaing a secure "environment" for your application.

• Intro
• Part I
• Part II
• Part IV

[More]

This post is a continuation of a 5 part series on security called "The Application Security Pyramid". The introduction introduced a new metaphor for dealing with security that loosely mimics Maslow's heirarchy of self-actualization. In Part I I discussed the importance of "border patrol" technology to safeguard your network. This post will deal with internal Policing and People Policy.

It's not enough to have effective border agents to feel safe. We also have to have effective policing inside our borders. After all, there are people here who are forced to work for the post office and they need watching. A system of policing and civil services keep us operating in safety and harmony with one another. This is the next two blocks on our pyramid - internal policing and people policy.

• Intro
• Part I
• Part III
• Part IV

[More]

In my Previous Post I introduced a new metaphor for thinking about security. The purpose of this metaphor is to give us a framework for discussing the topic with stakeholders who have a cavalier attitude toward security, or who have fallen into the habit of relying on mere network security to keep them safe. We discussed how current metaphors that are physical in nature don't do enough to encompass the whole realm of security when it comes to addressing a specific application. A new metaphor is needed. I came up with a model based on Maslow's hierarchy of self-actualization (it sounds pompous but hey - it works for me). If you want to know more, read on.

• Intro
• Part II
• Part III
• Part IV

[More]

My first piece of advice is to never ever direct a non-geek to an open source project. You might as well be directing them to a site broadcasting Shakespeare in Hellenistic greek. Open source projects have a wealth of information, but the information usually isn't written very good... er... well (although I found this owasp.org site to be ok). Geeks use acronyms like Samuel L Jackson uses the F-bomb - often and gratuitously. Of course you can try to summarize what you learned - and it sounds like that is what you did. The owasp.org site starts at the application code level however, and is going to be difficult for any non-programmer to grasp - at least without some groundwork. Even though you are trying to get them beyond that "first level" of security in your discussion, you may still need to address it. So let's lay some groundwork.

• Part I
• Part II
• Part III
• Part IV

[More]

Well this is a huge can of worms. In early 2004 (if memory serves) Visa required all its merchants above a certain threshold that sell on-line to be "certified" as "CISP" (Cardholder Info Security Program) compliant. Non-Categorized merchants - which may be defined as merchants with less than 6,000 transactions a year, no "hack" attempts (pretty vague) and who are not on Visa's radar - have avoided the cost of auditing by keeping a low profile while visa has other fish to fry - but the free pass may be coming to an end. Since "level 1" merchants are anyone that Visa says they are, they can require you to submit to an audit (at your expense) in order to continue processing Visa transactions. Wait.. it gets suckier....

[More]