smtp relay check
mailserver:
e-mail:
more info
translate to ...
language:
 
[1] . [2] . [3] . [4] . [5] . [6] . [7] . [8]
EyeonSecurity
Nekromantic
EyeonSecurity Forums
Ob5cureDotCom
elfqrin swg help net security
frame4 security hacker gurus computerglitch
gotr00t b0iler hackinthebox
nekromantic.com astalavista.net wand products
security-protocols
adv-knowledge rootshell wbglinks
security.nnov.ru
 
Copyright © 2001,2002 eyeonsecurity Inc., All Rights Reserved. No portions of eyeonsecurity may be used without express, written permission
 
Browsing Websites at your own risk.
- Hiding behind your web browser
- Obscure^ obscure@eyeonsecurity.org

-Intro


Feeling secure just because you're behind a firewall, have the latest virus signatures and running a top of the range IDS? You shouldn't, at least not unless you unplugg your modem, NIC or whatever, especially if you're browsing the 'net (i.e. websites) using your favorite browsers.

In this article I'll be describing some of the ways your browser, may it be MsIE, Netscape or whatever, gives out far too much information about you, or worse gives everyone full access to your machine. I won't be going into the philosophy and reasons behind anonymity, since I guess everyone has his own reasons. However I'll be focusing mainly on Ms Internet Explorer and Netscape, with reference to E-mail clients, most of which inherit the problems found in the Web Browser technologies.

I will not be covering why you should (or maybe shouldn't), be concerned about your privacy, anonymity and security of your "personal" computer. I guess everyone out their has their own reasons, may they be legal or otherwise, justified or evil.

-HTTP Protocol & Anonymity


The HTTP Protocol wasn't designed with anonymity in mind. The idea was to share information in more presentable format. An HTTP request (from Internet Explorer) looks like this:

GET /test.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Referer: http://www.yahoo.com/blablabla.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.9; Windows NT 7.0)
Host: 211.53.127.33:8011
Connection: Keep-Alive

Once a a TCP/IP connection the the webserver is achieved, the IP address of the client is logged and the HTTP request sent. Any or all of the above information the request be logged as well. Therefore OS and browser type and version are easily given out. The pointing web page URL is also sent via the referer option.

Your IP address is always given out (unless you prevent that) to the webserver since it needs to know who to send data to (as with all TCP/IP protocols).

That is where "anonymous" proxies come in. By bouncing through these anonymous proxies (may be anything, HTTP proxy like squid, socks v.4, or telnet session) should in theory block your IP address from showing up in the log files. This is obviously not true (see the javascript section), since there are other ways to get your IP address, apart from other info.

A referer is the webpage that actually pointed to the site you're requesting. This spells trouble for obvious reasons (passwords embed URLs, internal websites, administrative services running HTTP etc.). Same as above I would suggest using an Anonymous Proxy that do not send this information in the HTTP request. Much of the same goes for the rest of the HTTP request options.

Basic HTTP Authentication is the standard authentication method used over the HTTP protocol. It passes Usernames, Passwords and Realms in clear text. This means that anyone sniffing your connection or successfully executing a man in the middle attack (using hunt for example) can easily gain access to whatever you can gain access to.

The solution to this problem is to use SSL over HTTP instead of the standard unencrypted HTTP method for Authentication. This is actually not a generic Web Browser problem, but rather a security problem in the HTTP protocol.

-External Viewers


Browsers are usually configured by applications (like MsOffice, and Adobe Acrobat Reader) to start up the given app as soon as the document is downloaded. This poses a security issue for certain formats which allow scripting (AKA macros), like Ms.Office documents. Therefore a refresh meta tag or a javascript open() function pointing to a file type that executes commands should be enough for a malicious user to gain access to your mis-configured client (or E-mail Client).

-Javascript and similar Embedded scripting technologies


Javascript allows the web author to execute certain functions not available in HTML, i.e. scripts embedded within tags. This is cool for producing dynamic websites rather than static boring HTML only stuff. Obviously, once scripting functionality is enabled, anonymity and security issues crop up as usual. Javascript and other scripting languages (that is, mainly Microsoft's VBscript), allow the web author to execute code within a certain limit. This means that in theory, a malicious web author should not be able to read, modify or delete any files on the victim's machine.

Javascript has built in functions to retrieve the client's web browser properties. Integrated into Javascript and VBscript, in MS Internet Explorer, we have support for ActiveX technology. Any evil ideas yet ?

Besides that Javascript has been (and still is for some services) used for exploiting Web Mail services such as Hotmail and Yahoo mail, to allow an attacker gain access to the mailbox by redirecting a target to his site, posing as being the Web Mail service and ask for the password.

Exploits for Javascript have been cropping up since it was first implemented. Public exploits for previous and current versions allow a malicious user to read local files on a remote machine visiting his website or by sending html e-mail (through Outlook for example). Besides that as hinted two paragraphs ago, embedded scripts like javascript are usually used to exploit Java and ActiveX problems as well.

-Java problems


Those familiar with Java are aware that Java technology relies on a Virtual Machine, which must be installed on the machine which is trying to run the code. This means that Java is, unlike most other programming languages, not OS-dependent. This portability has been also applied to popular Web Browsers, first Netscape, and then Internet Explorer. Just like javascript and embedded technologies, Java is constrained to certain functions. However bugs and security "features" do exist, and from time to time new Java problems keep cropping up. For example Ms Internet Explorer 5.5 can be tricked into thinking that it is executing a local Java, as described by Georgi Guninski.

In another exploit involving Java, dubbed as Brown Orifice, Netscape could ironically be set up to act as a Web Server, and Ms Internet Explorer as a Proxy Server!

-Cookies


Cookies have generated a lot of anonymity alerts, along with some security problems as well. Cookie technology allows a Web Master to store some information on the client's hard disk. This does not mean that the Web Master has full read/write access to any cookie enabled client browsing his site. All cookie information stored on the hard disk is given a specific location, and must either be specified by the user himself or the HTTP client (that is Internet Explorer or Netscape).

Most problems around cookies arise when a Malicious web master is able to read other sites' cookies. Therefore websites should never store sensitive information in cookies such as credit card numbers, passwords etc., and users should change default settings to only allow the originating domain read/write to their cookie.

There was also a security flaw within Netscape related to cookies that allows malicious users to embed javascript code to cookies to read html files on the victim's hard disk.

-ActiveX Insecure Technologies


These vulnerabilities effect Ms related products. ActiveX Technology allows applications to be embedded within an HTML file via the <object> tag, javascript or VBscript. Various problems exist which allow malicious users to execute/read/write files on the victim's hard disk.

The main problem lies in executing ActiveX components marked as safe that allow scripting or access to local hard disk, i.e. access to functions not usually allowed to Web Browsers.

An exploit for Ms Internet Explorer 5.01 in conjunction with MS Office 2000 and 97 uncovered a major security flaw which allowed a malicious user to execute the exploit even if the security settings were set to disable ActiveX.

ActiveX technology allows remote virus scanners to scan your hard disk. Therefore no downloading time etc. This obviously means giving them access to your hard disk. This relies on certificates and asks the user if he wants to download and execute the ActiveX content.

-Other Possibilities

As in any other application, there is always the possibility of a generic attack such as buffer overflows. A buffer overflow vulnerability in Netscape 4.x exists in viewing Image files.

Apart from that, both novice and advanced users could be tricked in supplying personal information which could easily lead to spamming to access to local machine. One such obvious problem which is usually overlooked is the use of password. An old exploit consists of a malicious user (com)promising/providing a service which requires a password such as free e-mail accounts. Next time the victim tries to log on to his e-mail account he finds that his old password doesn't work and tries all his known passwords in hope that he used them instead. Old, but most of the time, it works!

-Solutions


I think one of the solutions would be to deploy a proxy server which allows you to filter out (search and replace) incoming and outgoing data. It could also allow you you to bounce through multiple proxies to further minimize IP tracking if you're really concerned about giving out your IP address. Outgoing data which should be filtered should include your personal information, like you name, passwords etc., browser and OS information. This proxy implementation should probably check for all data sent via the POST request method, cookie information, and the data after the ? in GET requests and probably list them in a log file for future reference.

As well as filtering what you're sending, it is also very important to filter what coming in. Therefore the proxy should check for ActiveX objects, embed media files, embed script tags, javascript commands inside images etc.

I guess this proposed technology could also be applied to statefull inspection (i.e. advanced) firewalls utilizing packet filtering technologies.

Keeping up to date with the latest patches for your HTTP client helps as well, since no solution is able to give you full security against these type of attacks.As HTTP technology continues to become more interactive, and obviously more scriptable, we'll continue to see more flaws to endanger our stay on the 'net.

-Reference

http://www.w3.org/Security/Faq/wwwsf7.html
http://www.securityfocus.com/data/library/rfc/1999/2617.txt
http://www.guninski.com/browsers.html
http://packetstorm.securify.com/9904-exploits/anonymizers+java+javascript.txt
http://packetstorm.securify.com/0001-exploits/javascript.hotmail.txt
http://www.securityfocus.com/bid/1120