Tuesday, November 30, 2010

Web Based E-mail (Hotmail Yahoo Gmail) Hack/Hacking with JavaScript

From here on in you walk alone. Neither little_v OR Black Sun Research Facility AND its members will be responsible for what you do with the information presented here. Do not use this information to impress your “l33t0_b0rit0″ friends. Do not operate in shower. Objects in article may be closer than they appear.
Note: If you see (x), where x is a number, it means that this term is defined at (x) at the bottom of this article.
The purpose of this article is NOT, I repeat, NOT to teach someone how to “hack an email account”. It’s true purpose is actually MUCH more devious. The purpose of this and all other articles in the “An Exploit Explained: ” series is to teach readers about various webtechnologies, and the basics of security and exploiting. I will try to give you a hands-on, learn as you go type of education in computer security. Sound good??? Then let’s get in to it!!
On Wednesday, Sept. 22 1999, yet another bleary day in the life of little v, the following message was sent to my inbox:
To: BugTraq
Subject: Yet another major Hotmail security hole -
injecting JavaScript using "javasCript:"
Date: Wed Sep 22 1999 10:48:04
Author: Georgi Guninski
Message-ID: <37E8D004.EF848F34@nat.bg> 

Yet another major Hotmail security hole - injecting
JavaScript using "javasCript:"

There is a major security flaw in Hotmail which allows
injecting and executing JavaScript code in an email
message using the javascript protocol. This exploit
works both on Internet Explorer 5.0 (guess IE 4.x)
and Netscape Communicator 4.x. Hotmail filters the
"javascript:" protocol for security reasons. But it
does not filter properly the following case:
"javasCript:" where "C" is the ASCII code of "C".

So the following HTML is executed <IMG
SRC="javasCript:alert('JavaScript is executed');">
if the user has enabled automatically loading of
images (most users have).

Probably this may be used in other HTML tags.

Executing JavaScript when the user opens Hotmail
email message allows for example displaying a fake
login screen where the user enters his password
which is then stolen. I don't want to make a scary
demonstration, but I am sure it is also possible to
read user's messages, to send messages from user's
name and doing other mischief. Hotmail deliberately
escapes all JavaScript (it can escape) to prevent such
attacks, but obviously there are holes. It is much
easier to exploit this vulnerability if the user uses
Internet Explorer 5.0. AFAIK this is not a browser
problem, it is Hotmail's problem.

Workaround: Disable JavaScript

The code is:
<IMG SRC="javasCript:alert('JavaScript is executed');a=window.open(document.links[2]);setTimeout('alert(\'The first message in your Inbox is from : \'+a.document.links[26].text)',20000)"> .... <snip> .... Regards, Georgi Guninski http://www.securityfocus.com/external/http://www.nat.bg/~joro
Ok, don’t puke, I’m going to explain what just happened in a fashion that even your dog can understand.
What is this all about?
This important part of this posting to the Bugtraq(1) (http://www.securityfocus.com) mailing list is the actual exploit(2).
The exploit would be:
<IMG SRC=”javasCript:alert(‘JavaScript is
first message in your Inbox is from :
What does it do?
As this exploit, when put into an email message sent to a hotmail user, opens a little box using the “alert()”(3) function in javascript(4), and is also supposed to read who the first message in your inbox is from. However, this code does not work on its own. You see, the email also says that you need to use the ASCII(5) code for “C” in the message. If I get out my handy HTML reference book, I can see that the ASCII code is C. If we substitute this into our little exploit, minus the “read who the first message in your inbox” part, we get this:
<IMG SRC=”javasCript:alert(‘JavaScript is executed’)”>
How does it work?
Finding out how an exploit works is always the part that makes people a bit spindizzy. If we look at that gibberish we call code one more time we can see that it uses an <IMG> tag, which all you who took my HTML tutorial would know is to display an image onto the page. Because hotmail tries to be the “top dog” webmail provider, they allow you to set autoloading of images, so the image just shows up on the same page as the mail. When you open a new hotmail account, this option is already set (hurray!). The conflict happens because your normal browser allows you to put javascript tags into your IMG tags. Because JavaScript is a strong little language, and allows just about full control over someone’s browser, if the conditions are right. Naturally, people like you and me started exploiting hotmail’s allowing of javascript. Soon, the <SCRIPT> tag (the normal way to add javascript to a page) was banned from use in hotmail messages by way of filtering(6) (boo! hiss!). So normal guys like you and me had to “inject”, or put into other html tags, our javascript exploits. The IMG tag is perfect for this, when combined with it’s autoloading capabilities. This discovery led to the filtering, yet again, of javascript injected into IMG tags. Of course, hackers ALWAYS find a way, and today we combine IMG-injecting with ASCII tags to give you the current exploit.
What else can I do with this hole in Hotmail’s Security?
As is the case with many exploits, the sky is the limit. If you know javascript, you can pretty much have a field day with this exploit. If you don’t, here’s a few more snippets of code to get you started:
This code opens a window with Darknet’s main page in it when the hotmail user opens your mail:
<IMG SRC=”javasCript:window.open(‘http:://www.darknet.org.uk’)”>
Note that the above code could point to any page at all (even one that simulates hotmail’s “you have been logged out” screen. *wink* *wink* HINT HINT ;-) )
This code opens 100 windows with Darknet’s main page in it (tee hee! self promotion is good!):
<IMG SRC=”javasCript:for(var i = 0; i < 100; i++) window.open(‘http:://www.darknet.org.uk’);”>
The rest is up to you, my friend. By the way, if Hotmail finds a way to make this exploit null and void, please don’t mail me, as I probably already know. Just keep looking for the next big exploit, and then when you’ve found it, you may tell me.
Terms Defined
(1) Bugtraq – A mailing list where people publicize holes and exploits in various softwares. I highly suggest that you subscribe at http://www.securityfocus.com.
(2) Exploit – Webster’s dictionary sez: ” exploit (eks’ploit’) – an act remarkable for brilliance or daring; bold deed”. Wow. Think of that the next time you steal someone’s ICQ password.
(3) alert() function – A function built into the Javascript language that brings up a rectangle box with the message passed to the alert() function in it. Note: alert(‘message goes here’)
(4) Javascript – A scripting language built into most popular browsers that gives much greater control over web page content than HTML alone (chicks dig pages with javascript 2 to 1 over standard HTML!).
(5) ASCII – A standard for characters on and beyond the normal keyboard.
(6) Filtering – A way to ‘catch and detain’ certain text or commands. Hotmail, for example, filters for the “javascript” text.
Some URLs
(1) http://www.htmlgoodies.com – they have some javascript tutorials if you wanna learn javascript.
(2) http://come.to/the-lamer – they have some fake hotmail pages that will make you think you were logged out for some reason and ask you to input your password. They also have some tutorials on how to use these pages, etc’ etc’ etc’.
From Blacksun 

Different Types of Computer Viruses

Different Types of Computer Viruses

There are Different Types of Computer Viruses could be classified in (origin, techniques, types of files they infect, where they hide, the kind of damage they cause, the type of operating system or platform they attack) etc. Let us have a look at them…

Computer Virus is a kind of malicious software written intentionally to enter a computer without the user’s permission or knowledge, with an ability to replicate itself, thus continuing to spread. Some viruses do little but replicate others can cause severe harm or adversely effect program and performance of the system. A virus should never be assumed harmless and left on a system. Most common types of viruses are mentioned below:

Resident Viruses
This type of virus is a permanent which dwells in the RAM memory. From there it can overcome and interrupt all of the operations executed by the system: corrupting files and programs that are opened, closed, copied, renamed etc.

Examples include: Randex, CMJ, Meve, and MrKlunky.

Direct Action Viruses
The main purpose of this virus is to replicate and take action when it is executed. When a specific condition is met, the virus will go into action and infect files in the directory or folder that it is in and in directories that are specified in the AUTOEXEC.BAT file PATH. This batch file is always located in the root directory of the hard disk and carries out certain operations when the computer is booted.

Overwrite Viruses
Virus of this kind is characterized by the fact that it deletes the information contained in the files that it infects, rendering them partially or totally useless once they have been infected.

The only way to clean a file infected by an overwrite virus is to delete the file completely, thus losing the original content.

Examples of this virus include: Way, Trj.Reboot, Trivial.88.D.

Boot Virus
This type of virus affects the boot sector of a floppy or hard disk. This is a crucial part of a disk, in which information on the disk itself is stored together with a program that makes it possible to boot (start) the computer from the disk.

The best way of avoiding boot viruses is to ensure that floppy disks are write-protected and never start your computer with an unknown floppy disk in the disk drive.

Examples of boot viruses include: Polyboot.B, AntiEXE.

Macro Virus
Macro viruses infect files that are created using certain applications or programs that contain macros. These mini-programs make it possible to automate series of operations so that they are performed as a single action, thereby saving the user from having to carry them out one by one.

Examples of macro viruses: Relax, Melissa.A, Bablas, O97M/Y2K.

Directory Virus
Directory viruses change the paths that indicate the location of a file. By executing a program (file with the extension .EXE or .COM) which has been infected by a virus, you are unknowingly running the virus program, while the original file and program have been previously moved by the virus.

Once infected it becomes impossible to locate the original files.

Polymorphic Virus
Polymorphic viruses encrypt or encode themselves in a different way (using different algorithms and encryption keys) every time they infect a system.

This makes it impossible for anti-viruses to find them using string or signature searches (because they are different in each encryption) and also enables them to create a large number of copies of themselves.

Examples include: Elkern, Marburg, Satan Bug, and Tuareg.

File Infectors
This type of virus infects programs or executable files (files with an .EXE or .COM extension). When one of these programs is run, directly or indirectly, the virus is activated, producing the damaging effects it is programmed to carry out. The majority of existing viruses belong to this category, and can be classified depending on the actions that they carry out.

Companion Viruses
Companion viruses can be considered file infector viruses like resident or direct action types. They are known as companion viruses because once they get into the system they "accompany" the other files that already exist. In other words, in order to carry out their infection routines, companion viruses can wait in memory until a program is run (resident viruses) or act immediately by making copies of themselves (direct action viruses).

Some examples include: Stator, Asimov.1539, and Terrax.1069

FAT Virus
The file allocation table or FAT is the part of a disk used to connect information and is a vital part of the normal functioning of the computer.
This type of virus attack can be especially dangerous, by preventing access to certain sections of the disk where important files are stored. Damage caused can result in information losses from individual files or even entire directories.

A worm is a program very similar to a virus; it has the ability to self-replicate, and can lead to negative effects on your system and most importantly they are detected and eliminated by antiviruses.

Examples of worms include: PSWBugbear.B, Lovgate.F, Trile.C, Sobig.D, Mapson.

Trojans or Trojan Horses
Another unsavory breed of malicious code are Trojans or Trojan horses, which unlike viruses do not reproduce by infecting other files, nor do they self-replicate like worms.

Logic Bombs
They are not considered viruses because they do not replicate. They are not even programs in their own right but rather camouflaged segments of other programs.

Their objective is to destroy data on the computer once certain conditions have been met. Logic bombs go undetected until launched, and the results can be destructive.

Monday, November 29, 2010

AJAX: Is your application secure enough?

We see it all around us, recently. Web applications get niftier by the day by utilising the various new techniques recently introduced in a few web-browsers, like I.E. and Firefox. One of those new techniques involves using Javascript. More specifically, the XmlHttpRequest-class, or object.
Webmail applications use it to quickly update the list of messages in your Inbox, while other applications use the technology to suggest various search-queries in real-time. All this without reloading the main, sometimes image- and banner- ridden, page. (That said, it will most probably be used by some of those ads as well.)
Before we go into possible weaknesses and things to keep in mind when implementing an AJAX enabled application, first a brief description of how this technology works.
The Basics
Asynchronous Javascript and XML, dubbed AJAX is basically doing this. Let me illustrate with an example, an email application. You are looking at your Inbox and want to delete a message. Normally, in plain HTML applications, the POST or GET request would perform the action, and re-locate to the Inbox, effectively reloading it.
With the XmlHttpRequest-object, however, this request can be done while the main page is still being shown.
In the background a call is made which performs the actual action on the server, and optionally responds with new data. (Note that this request can only be made to the web-site that the script is hosted on: it would leave massive DoS possibilities if I can create an HTML page that, using Javascript, can request thousands of concurrent web-pages from a web-site. You can guess what happens if a lot of people would visit that page.)
The Question
Some web-enabled applications, such as for email, do have pretty destructive functionality that could possibly be abused. The question is — will the average AJAX-enabled web-application be able to tell the difference between a real and a faked XmlHttpRequest?
Do you know if your recently developed AJAX-enabled or enhanced application is able to do this? And if so — does it do this adequately?
Do you even check referrers or some trivial token such as the user-agent? Chances are you do not even know. Chances are that other people, by now, do.
To be sure that the system you have implemented — or one you are interested in using — is properly secured, thus trustworthy, one has to ‘sniff around’.
Incidentally, the first time I discovered such a thing was in a lame preview function for a lame ringtone-site. Basically, the XmlHttpRequest URI’s ‘len’ parameter specified the length of the preview to generate and it seemed like it was loading the original file. Entering this URI in a browser (well, actually, ‘curl‘), specifying a very large value, one could easily grab all the files.
This is a fatal mistake: implement an AJAX interface accepting GET requests. GET requests are the easiest to fake. More on this later.
The question is — can we perform an action while somebody is logged in somewhere else. It is basically XSS/CSS (Cross Site Scripting) but then again, it isn’t.
My Prediction
Some popular applications I checked are hardened in such a way that they use some form of random sequence numbering: the server tells it, encoded, what the application should use as a sequence number when sending the next command. This is mostly obscured by Javascript and a pain in the ass to dissect — but not impossible.
And as you may have already noted: if there is improper authentication on the location called by the XmlHttpRequest-object, this would leave a possibility for malicious purpose. This is exactly where we can expect weaknesses and holes to arise.There should be proper authentication in place. At all times.
As all these systems are built by men, chances are this isn’t done properly.
HTTP traffic analysis
Analysing HTTP traffic analysis with tools like ethereal (yeh I like GUIs so sue me) surely comes in handy to figure out whether applications you use are actually safe from exploitation. This application allows one to easily filter and follow TCP streams so one can properly analyse what is happening there.
If you want to investigate your own application, the use of a sniffer isn’t even necessary but I would suggest you let a colleague that hasn’t implemented it, play around with your app and a sniffer in an attempt to ‘break’ through it.
Cookies are our friend when it comes to exploiting, I mean researching any vulnerabilities in AJAX implementations.
If the XmlHttp-interface is merely protected by cookies, exploiting this is all the easier: the moment you get the browser to make a request to that website, your browser is happily sending any cookies along with it.
Back to my earlier remark about a GET-requests being a pretty lame implementation: from a developers point of view, I can imagine one temporary accepts GET requests to be able to easily debug stuff without having to constantly enter irritating HTTP data using telnet. But when you are done with it you really should disable it immediately!
I could shove a GET request hidden in an image link. Sure the browser doesn’t understand the returned data which might not even be an image. But my browser does happily send any authenticating cookies, and the web-application on the other end will have performed some operation.
Using GET is a major mistake-a-to-make. POST is a lot better, as it harder to fake. The XmlHttpRequest can easily do a POST. But I cannot get a script, for instance I could have embedded one in this article, to do a POST request to another website because of the earlier noted restriction: you can only request to the same web-site the web-application is on.
One can modify its own browser, to make request to other websites, but it would be hard to get the browser on somebody elses machine to do this.
Or would it?
If proper authentication, or rather credential verification, still sucks, I can still set up a web-site that does the exact POST method that the AJAX interface expects. That will be accepted and the operation will be performed. Incidentally I have found a popular site that, so far, does not seem to have proper checks in place. More on that one in another article.
Merely using cookies is again a bad idea.
One should also check the User-Agent and possibly a Referrer (the XmlHttpRequest nicely allows one to send any additional headers so you could just put some other token in the Referrer-field). Sure these can still be faked — but it may fend off some investigating skiddiots.
Sequence Numbering, kinda…
A possible way of securing one’s application is using some form of ‘sequence-numbering’-like scheme.
Roughly, this boils down to this.
One should let the page, or some include javascript, generated on the server side, include some token that the performs some operation on which gives a result which is used in any consecutive request to the webserver. The webserver should not allow any request with another ‘sequence number’, so to speak.
The servers’ ‘challenge-string‘ should be as random as possible in order to make it non-predictable: if one could guess what the next sequence number will be, it is again wide open for abuse.
There are properly other ways of hardening interfaces like this, but they all basically come down to getting some fixed information from the webserver as far away from the end-users reach as possible.
You can implement this as complex as you want but can be implemented very basic as well.
For instance when I, as a logged-in user of a web-enabled email-application get assigned aSession-ID and stuff, the page that my browser receives includes a variable iSeq which contains an non-predictable number. When I click “Delete This Message”, this number is transmitted with the rest of the parameters. The server can then respond with new data and, hidden in the cookies or other HTTP Requests field, pass the next sequence number that the web-server will accept as a valid request, only.
As far as I know, these seems the only way of securing it. This can still be abused if spyware sniffs HTTP communications — which they recently started doing.
Javascript Insertion
On a side note I wanted to throw in a remark on Javascript Insertion. This is an old security violation and not really restricted to AJAX, and not an attack on AJAX. Rather, it is an attackutilising the XmlHttpRequest object for malice.
If I would be able to insert Javascript in the web-application I am currently looking at in my other browser window, I would be able to easily delete any post the site allows me to delete. Now that doesn’t seem all that destructive as it only affects that user? Wrong, any user visiting will have its own posts deleted. Ouch.
Javascript insertion has been a nasty one for years and it still is when people throw their home-brew stuff into production.
On a weak implemented forum or web-journal, one could even post new messages — including the Javascript so that any visitor — with the proper permission — would re-post the message keeping the flood of spam coming.
As these technologies keep developing — and lazy website developers do not update their websites to keep up with these changes.
The recent ‘AJAX enhancements’ that some sites got recently might have been improperly implemented. This year might be a good time to check all those old web-applications for any possible Javascript insertion tricks.
If you didn’t mind the cookies getting caught — the sudden deletion of random items and/or public embarrassment might be something to entice you to verify your the code.