Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Cyber Security Awareness Tip #1: Penetrating the This Does Not Apply To Me Attitude

Published: 2007-10-01
Last Updated: 2007-10-01 22:51:12 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)

As you are hopefully aware, October is the Cyber Security Awareness month. We will focus on one security awareness subject per day. Marc published the agenda at so let’s start with the first tip.

What are your tips for system administrators and others trying to get the word out to user? How did you get past the “This Does Not Apply To Me” attitude? Submit your ideas and stories here.

You might have heard this from your managers and CEOs multiple times – that they are not the target and that certain vulnerabilities don’t apply to them. An example of security not taking personally hit the news couple of days ago when Francis Ford Coppola’s laptop got stolen ( The laptop’s value in the whole story is negligible – the main issue here is that it contained the script for his upcoming movie and that there was no backup (at least it appears like so since Coppola pleaded for the return of the laptop).

Alan M. sent us another real story:

“I was called to help remove a phishing site from an ISP's apache server. It was not an easy offsite fix as the hacker was no script-kiddie and very actively fought from many countries' ips to retain "his" server.
One digi-macho guy let the hacker have a major advantage over me...
I setup a new linux machine offline to replace the bad server then put it online on an unused address of the ISP. I ssh'ed into it. While I was working, I noticed something odd in an lsattr directory listing. I ran "who" and found another me on the machine as root. Time from my login until hacked  <10 minutes. The hacker was playing man in the middle.
I fired up Nesus and ran a scan on the ISP staff machines and found one was infected. I went to that computer and its user and found the ANTIVIRUS program removed from the machine. I asked why? The reply, "I don't keep anything important on this machine. It doesn't need to be Fort Knox. I can reformat it if it gets infected."
I had to explain to him that his machine wasn't "Fort Knox" but the hacker had stolen his machine and used it as a bulldozer to break into the ISP.
"Well I didn't know that could happen. I thought the viruses just sent spam."



Couple of submissions we got from our readers – thanks everyone who sent their stories.

Carol C. sent a “more user friendly” version of Alan’s story, that is easier to understand for non technical users – thanks Carol:

“One user at an Internet service provider (ISP) had uninstalled the antivirus software on their computer. This user decided that as the computer was not an "important" computer, they did not need antivirus software. However the computer was, like most computers part of a network, a hacker managed to take control of it and was using it to attack and corrupt all the websites at the ISP.

Morals of this story:
Don't blindly trust "professionals": they are human and can be careless, tired or (in this case) stupid.
All computers are on networks and everything you do on your computer can affect all the computers on the network.”


Norman Y. asks his users: “Today's malware can not only destroy data and files on your PC, but it can steal your personal information such as passwords, income tax, credit card or banking information and also let intruders use your PC for illegal or criminal activities.   Experts (ISC) tell us that on average an unprotected Windows PC will not survive 20 minutes on the Internet before it gets infected.  So what should you do to keep your PC secure?”


Stay tuned for more tips this month.


0 comment(s)

Anti Virus industry and VBScript/JavaScript detection

Published: 2007-10-01
Last Updated: 2007-10-01 00:56:26 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

As almost all of our regular readers are aware, browser exploits are lately delivered heavily obfuscated. The main reason for this is, of course, to evade AV or IDS detection.

As the Anti Virus industry moved a step forward and improved detection of obfuscated exploits, the attackers started a trend of creating obfuscated exploits on the fly. I wrote about this before when I encountered dynamic JavaScript obfuscation (see – every time a client requested the web page containing exploits, the server side PHP script picked random variable names that, in this case, caused the whole function to be different since it was using the infamous arguments.callee() method so it depended on the function body.

This time I stumbled upon dynamic VBScript obfuscation. The exploit wasn’t interesting at all (it was the old MS06-014 Internet Explorer (MDAC) Remote Code Execution exploit), but the server side script that was generating the VBScript code was indeed interesting.

The server side script basically did two things:

  • Randomly change all variable names
  • Randomly split strings into multiple concatenated smaller strings

Below you can see two results of this obfuscation:

      set ugdd = CreateObject(rub & "." & jleptfo)
      gljxbkx = "G" & "E" & "T"
      dsoswt = ugdd.Open(gljxbkx,nmqqa,0)
      On Error Resume Next
      lpuvkay = ugdd.responseBody


      set jbg = CreateObject(lwyfqe & "." & pnqf)
      qcr = "G" & "E" & "T"
      rjtp = jbg.Open(qcr,osjypz,0)
      On Error Resume Next
      gwwtvo = jbg.responseBody


As this caught my attention, I decided to spend more time on this and see how AV programs are doing against this simple obfuscation.

First of all, detection of such exploits still seems to be only in the early phases. Only 5 out of 32 AV programs represented on VirusTotal were able to detect this file as malicious (and of those 5 some share scanning engines so the number is even lower!).

To be fair to the AV vendors, properly detecting VBScript and JavaScript obfuscated exploits is not a trivial thing. Since there are multiple obfuscation ways they can rely on signatures only for basic detection. So, to detect things like string splitting they would have to implement some kind of an interpreter (or optimizer) that will detect things like this and create proper strings. This is one of the reasons why I was interested in how good they will cope with this obfuscation so I did a little test.

I retrieved 100 samples of the same script (directly from the compromised server so this is how it happens in the wild) and confirmed that all of them are functionally same, but have different variable names and that string obfuscation was used. And I was pleasantly surprised – all 5 programs detected 99 samples (only 1 was missed by 2 products that share the same scanning engine).

From this little test it seemed like the AV vendors have good interpreters or found a reliable signature. Unfortunately, my pleasant surprise didn’t last long. About 5 minutes later I found out that the signature wasn’t that reliable at all (except for this particular exploit) – by modifying the exploit slightly (and I really mean slightly – the details will be sent only to the AV vendors if they request them) I was able to easily evade all 5 AV programs while the exploit functionality remained the same.

So, the conclusion after this test (which is really small and not representative of any AV program’s abilities) is that the cat and the mouse game will continue for quite some time. As we are seeing more client side exploits I hope that the AV vendors are working on improving their detection in the background and that we’ll see some progress there soon.



0 comment(s)
Diary Archives