In This Issue:
Virus News
No new outstanding viruses to report this month; just the usual increase in (mostly) macro viruses for Microsoft Word.
The anti-virus folks, Dr. Solomon’s, announced they are now monitoring newsgroups. Here are excerpts from their announcement:
- Internet VirusPatrol is a unique service provided by Dr. Solomon’s to protect users of newsgroups from virus infections. This free service is scanning some 70 usenet newsgroups 24 hours a day 365 days a year.
- Internet VirusPatrol scans all attached executable files and documents for both known and unknown viruses using Advanced Heuristic Analysis, a technique of scanning files for suspicious code and algorithms. When a virus is found Internet VirusPatrol issues an alert to the newsgroup warning other readers not to download the infected file.
General Security
Most people browsing the web don’t realize that underneath the calm exterior there are a number of security concerns. Many are the concern of service providers but others should be the concern of web site managers and even individuals. Indeed, under the right circumstances and if you are just a bit paranoid you can project a method using cookies that determines when you might be out of town and your home is free for robbing.
The press has mentioned some of the attacks ISPs must counter (e.g., SYN flood, DNS hijacking, Ping o’ Death, IP spoofing, and CGI PHF attacks). What we’d like to discuss this month is something web users might encounter: web spoofing.
A full description of web spoofing can be found at:
http://www.cs.princeton.edu/sip/
In summary, web spoofing allows a single site to “emulate” the entire web as far as you are concerned. If you were to link to a spoofing site (call it “www.spoof.net” here) then www.spoof.net would fully control all further net activities in your current session. It does this by redirecting all page requests through www.spoof.net and then feeding those pages to you from www.spoof.net. In the process, any requests or information you send out can be intercepted (and changed) by www.spoof.net; and, any information coming back to you through www.spoof.net can likewise be intercepted and/or modified before you see it. So, www.spoof.net doesn’t have to have a copy of the entire web; it only needs to control access to the web and make changes as necessary for its (bad?) purposes.
You should know that this type of redirection is not new. Several sites advertising anonymous surfing have been using this technique for some time now. The difference is that now the bad guys are thinking about using the technique for less than honorable purposes.
But, can’t you just see that the link you are about to click on is going to direct you to http://www.spoof.net/http://www.microsoft.com/ instead of just http://www.microsoft.com? Yes, if you are looking at the link information in your browser and some Javascript script has not taken over that part of the browser screen and is displaying the “real” URL. This is rather easy to do by adding an onmouseover command to your link. Javascript can also mask the URL display in other areas of the screen. Web spoofing can even take place when you’ve selected a secure link and you see the little key icon indicating such a link is in place; you have a secure link to www.spoof.net!
So, what can you do? As much as it grates to keep throwing the baby out with the bathwater, there are only two protections you can use right now: (1) Select the options in your browser to turn Javescript, Java, and ActiveX OFF, and (2) Watch the destination URL for every link you plan to take and make certain they are accurate (e.g., they are not of the form http://www.spoof.net/http://destination.com or http://www.micr0s0ft.com where in the latter case a zero has replaced the oh and you are therefore directed to a place you might not like). When you arrive at a site you trust and that uses Javascript, Java, or ActiveX you can always turn them on and reload that particular page. It’s not a satisfying solution, but the only other solution is to just remain vulnerable.
In another security story, there is a possibility that when ordering from a secure web site you could, potentially, have your credit card and other info passed to a second web site in an unsecured manner. This is true with either Internet Explorer or Netscape as it is a web problem, not a browser problem.
When you fill out a form on a web page and press the submit button the information is first encrypted (if you have a secure connection) and then sent. But, it still remains in a local cache in unencrypted form. If the submit button has been linked to an HTML GET command then it is possible for that information to be automatically sent to the next site you link to from the ordering page in unencrypted form. It would not be sent in a form that would be immediately useful but would reside in that site’s server logs. The problem here is that the server log files are usually not well protected.
The immediate solution would be to have all web page authors use the HTML POST command instead of GET. The information is handled in a different manner and not subject to the above problem.
Fortunately, most authors do use the POST command; but GET is available and it’s not known how many authors have used it.
To be safe, after sending in an order via a secure net connection either don’t link to another site from the secure page or, if you do, manually type in the site location instead of taking an automatic link. This is a minor inconvenience; but best to be safe rather than sorry.
