---------------------------------------------------------------------------



Section 01



The Browser



---------------------------------------------------------------------------



01-1. What is "unsafe" about my browser?



There are two main areas regarding security around a browser -- reading

your private files and manipulating you into a compromising situation.



A few files provide a lot of information about yourself. These include cache

files, the history file, and your bookmarks. By examining someone's cache,

history, and bookmarks you can learn a lot about a person. Usually if you

are a typical home user running Windows, this is not a problem. But if you

are storing your Netscape directory on a server, the server could be 

compromised and then anything in cache and history is in the hands of

someone else. Every access. Submitted forms, including those to change

passwords on servers whose service you are paying for.



Being manipulated the other hot area. You can be tricked into supplying

user IDs and passwords, reveiling personal information like SS# and credit

card information, or even be presented with misinformation to cause you to

act in a way to cause a vulnerability to arise. If your browser supports

HTML 3.0 extensions and Java, your history file, cache, and other files be

plucked from your hard drive. Your machine could be used as a mechanism to

attack other resources behind your firewall, sending critical info to an

offsite hacker.



---------------------------------------------------------------------------



01-2. What is vulnerable about history, bookmark, and cache files?



We'll cover all three. First the history file.



The default color for a clickable link is blue. Once you've clicked on it

and visited the link, it's purple. While the colors may be different 

depending on what is specified in the HTML, the way your browser keeps track 

of this information is via the history file.



Since the default is 30 days to expire a link, typically you can see the last 

30 days worth of web surfing by examining the history file. "Hmm, Fred keeps

looking at a particular set of stocks, does he know something I don't? Hey,

Martha keeps looking at lesbian sites, what would her homophobic boss say

about that?" Get the idea?



Here's an example -



è1http://altavista.digital.com/cgi-bin/query?pg=q&what=web&fmt=.&q=

%2B+%2Bmicrosoft+%2Bstock+%2Bprice+%2B+takeover+%2Brumor+%2Bapple ,

è1http://altavista.digital.com/cgi-bin/query?pg=q&what=web&stq=10&

fmt=.&q=%2bapple+%2bmacintosh+%2bhack {è1http://altavista.digital.

com/cgi-bin/query?pg=q&what=web&fmt=.&q=%2Baudit+%2Btrail+%2Bhide



If this was from the history file of someone at Microsoft, this might

be quite interesting, even valuable.



Bookmarks are a problem for the same reason the history file is a problem.

It shows what sites you are regularly looking at. If you are bookmarking

sites which require passwords to enter, a quick look in the cache will

possibly reveil that password, or at least the account ID.



The info gained from here can also be used for social engineering purposes,

and can be quite useful. For example, you could determine the user was

interested in aquariums and rare fish. This information could be used to

assist in guessing a password.



The cache is your browser's way of making things a little easier on your

access time, the server your accessing, and the network in general. What 

happens is that when you access a web page, a copy of the page and any 

graphics used on that page are stored locally. That way when you access the

page again, your browser can pull up the local copy instead of always

accessing the network. This saves time and bandwidth. When you reload, your

browser compares the cached local file to the one on the server you are

accessing and pulls down the latest one. Most browsers will also cache 

queries and form submittals as well.



If you are looking for dirt on someone, looking for credit card information,

or just want to find out what someone's been up to, check their cache. Every

query to a search site like AltaVista is stored in cache. Typically every 

form submittal including accesses to pages requiring an ID and password will

be there, unless a site has tagged an HTML document NOT to be cached.



The cache is typically located in a subdirectory underneath the browser's 

working directory called "cache" or possibly ".netscape-cache", depending

on your OS and browser version. Otherwise it may be stored in a temporary

directory. For example, IBM's Web Explorer for OS/2 will store it's cached

files in c:\tcpip\tmp, and is flushed before each run of the program.



Here is an example from the cache's index file on a Unix workstation, with

names changed to protect the innocent ;-)



n   b   http://altavista.digital.com/cgi-bin/query?pg=q&what=web&stq=

10&fmt=.&q=%2bhack+%2bnt+%2bserver     ü          ÉEá1    È       

   00/cache31DF458002EC693.cgi                                 

   t

ext/html          È                                                 

	   4   (   http://www.nt.target.com/user/register.cgi     ©  

        rEá1              10/cache31DF457002CC693.html          

		       

   text/html                               

				 .   "   http://www.nt.target.com/use

r/welcome.html     ç          Ùá1    J          14/cache31DF18940

27C693.html                                 

   text/html          J

    



Very interesting. Here are three entries. The first this user is trying

to get NT hacking info from AltaVista, the second this user is trying to

get signed onto a site called www.nt.target.com, and finally the user

looks like they got in. The three cache files are:



	31DF458002EC693.cgi

	31DF457002CC693.html

	31DF1894027C693.html



You could view these files with a browser, as they are local copies of

the web pages. If 31DF457002CC693.html had a password in it and it was

unreadable, you could still do the following -



- Access the site yourself and try to login.

- Check your own cache and replace your cached file with the

31DF457002CC693.html file, renaming it to what YOUR cache file was.

- Resubmit the form. If the site isn't doing any other security than a

password, you might get in.

- If you still don't get in, try substituting the cookie file as well

(see next section).



SSL (see section 02-9 for info on SSL) documents are stored in cache, 

depending on browser version and settings. In Netscape 3.0 and later this

problem is resolved. But still it exists as a problem in Microsoft 

Explorer 3.0. The files are located in \WINDOWS\Temporary Internet Files. 

For more details on this, see http://www.iol.ie/~fod/sslpaper/mscache.htm.



---------------------------------------------------------------------------



01-3. What other browser files are important?



The cookie file (typically cookie.txt, only found on Netscape and Internet

Explorer) is a file used to store information about your browser and Web

server connection. Since the hit is "connectionless" -- a one time hit

until you click on a link or submit a form -- the cookie file is used to

track information about your session with a server. This way a server can

track info about you during your visit, by giving you a cookie. The cookie

would typically track info such as which page you've been to or how you

answered a question on a previous form, and due to the connectionless

state it keeps the cookie on the client.



No this doesn't seem like a problem, except that since JavaScript can

write info to this cookie before it is sent back to the server, limited

info can be gathered about a user -- typically the email address. So

occassionally the cookie.txt file will contain interesting info, usually

not.



An example of how this cookie file could be used is illustrated here:



    - A user loads a page.

    - It checks for its cookie in the cookie.txt file.

    - If the cookie is there, the state the user left the page in last

      visit is restored (and we can jump to the last step).

    - If no cookie is present, it is assumed the cookie is expired or

      it's the first visit.

    - A default page is built for the user.

    - The user clicks and selects stuff on the page.

    - The user leaves the page (perhaps we track it with an Unload call).

    - The cookie is updated with the changes made to the page.



The other important file is that pull-down in Netscape that showed the 

last 10 or so sites you've visited. This is typically located in the

netscape.ini file in the [URL History] section. A clever Java applet 

could grab this info and ship it offsite, or if you've compromised a

server where everyone has their config files in user directories, you

can get to this information.



A couple of other directories that contain interesting files are the

MAIL and NEWS subdirectories for Netscape. The MAIL directory will of

course contain not only your inbox if you're using Netscape as your

email app, but log every email sent out from your browser whether you

are using Netscape for email or not. The file is typically called Sent, 

and is turned on for logging by default.



It is interesting to note that while it is trivial to send fakemail via

Netscape (simply make the changes to the return address and send), the

outgoing message is stored in that MAIL directory by default in most

browsers. While fakemail is still pretty easy to track down, having a

copy of the message on your machine that you don't know about is pretty

damning evidence in my book.



---------------------------------------------------------------------------



01-4. Can you tell me more about the "cookie" file?



As stated in the previous section, the cookie file, "cookie.txt", is a 

file used to store information about your browser and Web server 

connection. 



You find cookies in the Netscape environment. The limits are as follows -

you can only have 300 cookies total, each cookie has a limit of 4KB

(which works out to about 1.2MB), a single site can only have a max of

20 cookies in your cookie.txt file, and a web server can only access a

user's cookie if that cookie.txt entry contains the web server's domain.



A cookie entry has the following in it -



NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure



The name is the name of the cookie, and the value is the value of the

cookie itself. The expires date, if present, is when the cookie expires.

If there is no expiration date then the cookie is only kept on the client

during the current session. The path and domain indicate which URLs can 

access certain cookies, and the secure keyword is used when a cookie needs

to be sent over a secure link.



So how do we access this info? Using Java (these examples will not work

alone, call from your own Java program).



First let's retrieve a cookie by name:



// This function is used by the GetCookie function...

function getCookieVal (offset) {

 var endstr=document.cookie.indexOf(";", offset);

 if (endstr==-1)

  endstr=document.cookie.length;

 return unescape(document.cookie.substring(offset, endstr));

}

// ...and this function returns the requested cookie.

function GetCookie (name) {

 var arg = name + "=";

 var alen = arg.length;

 var clen = document.cookie.length;

 var i = 0;

 while (i < clen) {

  var j = i + alen;

  if (document.cookie.substring(i, j) == arg)

   return getCookieVal (j);

  i = document.cookie.indexOf(" ", i) + 1;

 }

 return null; // return null if no cookie by that name

}



Now to set cookie information with this function:



// The first 2 args are used, the rest are optional. If you skip an

// arg give it a null value. 

function SetCookie (name;value) {

 var argv = SetCookie.arguments;

 var argc = SetCookie.arguments.length;

 var expires = (argc > 2) ? argv[2] : null;

 var path = (argc > 3) ? argv[3] : null;

 var domain = (argc > 4) ? argv[4] : null;

 var secure = (argc > 5) ? argv[5] : false;

 document.cookie = name + "=" + escape (value) + 

  ((expires == null) ? "" : ("; expires=" + expires.toGMTString())) +

  ((path == null) ? "" : ("; path=" + path)) +

  ((domain == null) ? "" : ("; domain=" + domain)) +

  ((secure == true) ? "" : "; secure" + "");

}



Finally let's delete a cookie by name:



// This funxtion uses the GetCookie function above.

function DeleteCookie (name) {

 var exp = new Date();

 exp.setTime (exp.getTime() -1); // set cookie to expire and browser will

                                 // remove it at end of session

 var cval = GetCookie (name);

 document.cookie = name + "=" + cval + "; expires=" + exp.toGMTString();

}



---------------------------------------------------------------------------



01-5. How can I protect my browser files?



Well, you could disable cache (or set its size to zero) but that would

certainly hurt performance. Usually flushing your cache at the end of a 

session or before visiting a site that's unknown would be good. Setting

your history file preference to zero or wiping the file at the end of the

session is also okay.



Don't put stupid stuff in your bookmark file ;-)



You can edit your cookie.txt file, removing any cookies and then using

your local operating system make the cookie.txt file read only.



Disable the logging of outgoing email messages, unless you don't have a 

problem with anyone reading them.



A site can learn a lot about you, even without Netscape or Java. Take a

look at http://www.anonymizer.com/cgi-bin/snoop.pl. With extra logging 

options a site can log your OS, browser, e-mail address, hostname, and 

last site visited. This is NOT using JavaScript either. Some companies 

use this info to build mailing lists, and track all of this info. To 

prevent this use http://www.anonymizer.com's site as a "proxy" to surf

anonymously. Instructions are at the anonymizer site, and it is currently

a free service.



If most of this is Greek to you, and you simply read this FAQ because you 

are afraid of computer bad guys, go to http://www.shareware.com and look

in the Privacy section for a product called NSClean. This product allows

you to clean up any or all of these files, and is fairly easy to use (I

am assuming a Windows client here).



---------------------------------------------------------------------------



01-6. Are there any default browser holes?



Mosaic 2.2, and all previous version of the NCSA Mosaic for the X Window 

System had a serious security hole that would allow telnet URLs to execute

an arbitrary UNIX command. In Mosaic 2.3 this bug was fixed. 



There is a way (involving reconfiguration of both client and server) to 

have Mosaic execute any arbitrary shell script that is passed over the 

network. This is a documented feature that cannot be activated 

accidentally. It must be configured.



An entry is placed in the user or system mailcap that looks like this: 



             application/x-csh; csh -f %s



The client then accesses a document on a local or remote HTTP server that

is typed application/x-csh.



Obviously, csh -f will be used as the "viewer" for the document, which 

means the shell script will be executed on the client's host. 



Since Mosaic is not shipped with support for application/x-csh or anything

similar in the default settings, this is not a security hole unless you 

specifically modify your config files to make it so. The same goes for

Netscape. You can alter the netscape.ini file and match up certain file

types to certain applications, including csh.



I will not go into details regarding what entries should be in the shell

script, although mailing the passwd file does seem to be the obvious.



---------------------------------------------------------------------------



01-7. What about Internet Explorer?



Okay, first off, IE v3 had a problem with .LNK and .URL files. These

extensions on web pages can cause commands to be issued on your local 

workstation by viewing the pages. LNK is the extension used for shortcuts

in Windows 95, and URL is used in both 95 and NT.



These extensions, coupled with Server Side Includes on the evil page's home

server, could allow for a customized attack against Windows platforms. For

details, do a web search for the "cybersnot" IE bug.



Another similiar bug was discovered that allows remote program execution

for IE 3.0, by using a directory as a part of a <IFRAME> tag, a Windows

Explorer window sized small enough to look like an icon can be double

clicked on that can run a remote program. But even more interesting was the

IE 3.0 ISP bug, reported at http://web.mit.edu/crioux/www/ie/index.html.




All of these bugs have been patched with the latest patches.


---------------------------------------------------------------------------

