Browsing Websites at your own risk from L33tdawg
                      
By: obscure

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 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