Websites at your own risk.
- Hiding behind your web browser
- Obscure^ firstname.lastname@example.org
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
-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,
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.9;
Windows NT 7.0)
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
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
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
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.
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
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
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
(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.
to retrieve the client's web browser properties.
Internet Explorer, we have support for ActiveX
technology. Any evil ideas yet ?
(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.
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
and ActiveX problems as well.
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
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 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
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,
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.
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!
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
I guess this proposed technology
could also be applied to statefull inspection
(i.e. advanced) firewalls utilizing packet filtering
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.