The Security Skeptic

Russ McRee published a really interesting article in the June ISSA Journal on cross-site scripting attacks. Written in the 1^st person perspective of the attacker, Russ does a really fine job of breaking down the elements that comprise an attack. He begins with an impossibly arcane URL, shows how that URL accepts parameters for a script, and describes how an attacker exploits a vulnerable parameters to "own" the bank's login page.

Russ has posted his article at HolisticInfoSec.org.

Archived at http://www.securityskeptic.com/arc20080701.htm#BlogID697 by Dave Piscitello  

Beyond studying web logs for security purposes, my web log analysis needs are modest. I want to periodically look at hits, determine page and hence topic popularity, and identify errors. At-a-glance graphics are nice but not entirely necessary. I want a simple UI, the ability to upload a zip file of log files and feed these into analysis software I'm running on a system other than my web server. I'm certain most web log analysis software vendors shudder to think of a marketplace full of folks like me.

I recently tried and really like WebExpert Log Analyzer Lite Version. It's free. The UI is intuitive and with only four buttons to choose, about as basic as you can ask. You create or open an existing profile, a configuration file for a web site, you save, and you click "Analyze". WebExpert analyzes an individual or zip archive full of Apache or IIS logs, launches your default browser, and displays a set of reports and graphics that you can navigate using a Windows Explorer style interface.

Many companies frustrate would-be users by crippling free versions but the folks at WebLog Expert have done a nice jump of creating a useful subset for the Lite Version. The Lite Version provides a summary report, daily and hourly reports, access reports (page, file, image, directory and entry page), a visitor and browser report, and several referrer reports (sites, URLs, search engines and phrases). It also summarizes errors by error code. A Standard and Profession version offer much more, at relatively modest prices, affording me an upgrade path should I ever need more than the features in the Lite edition (compare the versions here).

You won't find this software enormously useful for studying web application and server security issues, but it will serve a small shop well as a basic analysis and *first look* tool. Works under Windows 95/98/Me/NT/2000/XP/2003/Vista operating systems.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID618 by Dave Piscitello  

I've been experimenting with using content inspection at an http proxy as an added layer of defense against different forms of malware for a while now. Because certain spyware use archives and executables to install ActiveX controls, I added a proxy action to block CAB. ZIP, Java byte encoded strings, EXE and DLL file types. I applied this policy to content offered from all external servers, as a test for an article. I kept the policy in place to see what affect it would have on blocking malware at my perimeter.

Examining my logs for nearly a month, I confirmed that my policy was effectively blocking unintentional downloads. However, my blanket policy is too aggressive and blocks a few legitimate - and important - downloads. I've had to create exception policies for external sites I must trust. For example, I now have an exception policy to accommodate Windows updates (CAB files) and select open source sites (compressed archive files). Troubleshooting was easy for the open source problem: these were obvious because they were initiated from browsers. Troubleshooting Windows Update was not as obvious since I rely on Automated Updates.

Heidegger would be proud: I only realized Windows Update was not operating correctly by the "obtrusive" absence of silent installations and popups demanding I restart my PC;-)

Over the same period, I've configured my http proxy with a white list of approved http headers. My initial policy white listed header fields defined in the http standards. Adjusting this white list requires more attention, but it's not a huge burden. In most cases, browsers and http applications work even when header fields that do not comply with my policy are stripped. Again, Windows Update required an addition to the white list for the header X-AspNet-Version.

The biggest problem I've encountered thus far are sites that do not list content types in http headers. This is simply poor programming and it creates problem scenarios for security administrators who are trying to keep their trusted networks free of malware. A recent example I've encountered is the Stamps.com online store. I can use every other feature bundled in the Stamps.com client except the store, because my firewall blocks server responses where content type is missing.

An admin should ask, "what could be more suspicious than an http header that doesn't identify the content-types in the message?" But should admins create exception rules each time a web application developer elects or forgets to identify content type?

I don't think so.

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID523 by Dave Piscitello  

As I investigated various ways to block ad-serving cookies and spy/adware, I discovered two Firefox extensions that do an incredible job of blocking annoying and potentially harmful cookies. Like Eric Howes' IE-SPYAD for Internet Explorer, the Firefox extensions, when used in tandem, not only block cookie installs, but ad delivery as well. I wrote WatchGuard Wire item describing these safe surfing features. Visit Block ad-serving cookies in both IE and Firefox.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID513 by Dave Piscitello  

What lovely timing. Less then 48 hours after I describe how phishers might use SSL certificates to make a bogus web site appear more credible (see blogID #473), Bill Brenner reports that self-signed SSL certificates are the Phisher's latest hook. Apparently, phishers don't need to bother purchasing a server certificate from a trusted authority to create a sufficiently convincing lure to extract customer account information from their victims.

I clearly overreached by suggesting phishers actually spend money to enhance their deception. At the very least, I underestimated the probability that users will click and dismiss dialog box a browser or operating system might offer without regard for what the warning actually says.

A vintage New Yorker Magazine cartoon depicts a dog at a computer, talking to a fellow dog. The caption reads, "On the Internet, no one knows you're a dog." (page 61 of July 5, 1993 issue, Volume 69)

The modern day caption might read, "On the Internet, Phishers are certain they'll meet millions of lemmings."

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID474 by Dave Piscitello  

More precisely, has your bank made it impossible for you to do so? After reading Adam Shostack's blog item at Emergent Chaos, How not to train users, and following the thread begun by Peter Gutmann on the Cryptography mailing list, US Banks: Training the next generation of phishing victims, I wonder once again why we always sacrifice security for performance.

According to Gutmann's post and ensuing thread, many U.S. banks do not use SSL encryption on their home page. Of these, many home page host a customer login form. An SSL session is created when a visitor attempts to access an account from this form, but often to a different server, e.g., onlineservices.yourbanknamehere.com . This practice, ostensibly to boost performance for all visitors, creates an issue of trust. Without confirming the server SSL certificate for your banking institution, how can customers trust they have really visited your bank's home page and not that of a phisher?

I decided to investigate further. Using Ethereal LAN analyzer, I captured a session to my bank's home page, a.k.a., whatbankareyou.com. The home page is not SSL-protected, but customer login proceeds as I described above. This seems like a small matter, until you think about the ways that we are educating Internet users to detect and avoid phishing, e.g., "look for the padlock denoting 'secure site', your information is protected". Visiting online banking home pages no longer offers this simple but effective cue for unsophisticated users. I'll claim that it can be much worse. A phisher can compose a phishing email with a bogus URL - one that displays htttp://www.whatbankareyou.com but connects to a bogus site. At that site, the victim sees the account login form, but no reassuring padlock. Unfortunately, the customer's visited the bank before, so he's accustomed to the padlock being absent, and blithely enters his account information. Even if the customer is savvy enough to know that the bank diverts customer login to an SSL-protected page, a phisher can invest in a cheap SSL certificate, and recreate the redirect sequence to his own variant of "onlineservices.phishingsite.com". How many visitors will actually read beyond "onlineservices..." if the hyperlink is extremely long? (BTW, browser hijacking spyware and DNS cache poisoning are other vectors for this kind of attack, e.g., both could make a PC visit a different IP address than the one actually associated with www.whatbankareyou.com.)

I contacted my bank through customer service. The reply from my customer representative was only partially comforting:

I understand your concern regarding the security measures taken by whatbankareyou to ensure the safety of the Online Banking service for customers.

whatbankareyou has internal teams that work closely with law enforcement to continuously monitor and investigate fraudulent email and website scams that invoke any whatbankareyou brand. If there is the potential for significant impact to our customers, we have teams dedicated to alerting customers that may include reaching out directly to a customer, posting alert information on our website, or sending correspondence.

whatbankareyou is piloting a vendor anti-fraud/anti-phishing solution and evaluating multiple other vendor solutions to help in the upfront validation of online account access and the identification of newly launched attacks, or imminent attacks.

whatbankareyou is a member of DigitalPhishNet, a joint enforcement initiative between industry and law enforcement aimed at discovering the disabling phishing scams.

whatbankareyou is in the process of implementing a more robust message center that will provide customers with the confidence they need in their electronic communications with whatbankareyou.

I'm actually very pleased that whatbankareyou is aware of the phishing threat and is actively engaged in antiphishing activities. Overall, I'm a satisfied customer, with (now) a single exception.

I would be more than willing to wait a few seconds for my home page to load to be confident I've actually connected with whatbankareyou when I visit www.whatbankareyou.com...

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID473 by Dave Piscitello  

I'm participating in a multi-city security tour for Network World. Today, in Boston, attendees submitted so many questions about security that we could not answer all of them during the Q & A session. I promised to answer "some" on my blog, and will do so over the next few days.

How secure is IIS 6 on a Windows 2003 server with the Lockdown tool? Are other precautions necessary?

I wrote about IIS lockdown in a Watchguard Live Advisory column, How to Harden Your Microsoft Web Server. At the time, my web server was Win2K, but I've since experimented with and concluded Lockdown and URLscan are just as effective on W2K3. Properly configured for the types of content users can get from and post to your web site, it's a useful tool.

Other precautions, however, are necessary. How much time, talent and budget you invest on configuration ("hardening"), security hardware and host IDS of course depends on the type of service you run from your web.

If I had answered this in "real time", I'd have mentioned this subset of precautions:

• Begin by hardening your server OS and filesystem according to industry best practices (my column has some useful references, and you'll find more at MSDN and other sites dedicated to Windows server and IIS.
• Review any scripts you use to confirm they are not exploitable.

• Consider file system integrity software and commercial host intrusion detection software, if budget permits.

• Restrict management access.

• Audit not only your web traffic, but events related to web site administration as well.

• Investigate how 3^rd party advertising (e.g., Google AdSense), search, info feeds, and web site statistics sites operate, and (important!) what information they collect from visitors before you include such features on your site, and make certain these are reflected in your privacy policy.

Web sites that perform financial and merchant transactions and host regulated content (medical records) have substantially different risk profiles than a "free content" site like mine, and of course merit considerably more attention with respect to protecting (transaction) data integrity and unauthorized disclosure.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID454 by Dave Piscitello  

Secunia recently reported that a long-known, exploitable feature... um, flaw... uh, flawed feature... was reintroduced into Firefox 1.0.4. The flawed feature allows a web page to load content into the frame of another page. An attacker could use this to substitute a bogus authentication prompt and capture passwords from an Extranet, online banking portal, etc. Secunia has published an online demonstration of this exploit.

Try the demo, it's very interesting.

Some time ago, I wrote that the "which is better, Open or Proprietary?" is silly. Quality of design, quality of developers, and quality assurance aren't guaranteed from either community, and will differ over time and project (application). You'll find good and shoddy software wherever you shop. Shop wisely.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID415 by Dave Piscitello  

A new Firefox extension piqued my curiosity. HeaderMonitor displays the HTTP response header returned by a web server on the Status Bar panel. Response-header fields provide information about the web server type and version, cache, meta and connection information.

At first, HeaderMonitor seems like it's just a geek tweak. With HeaderMonitor installed, my Status bar now reveals that the Mozilla/Firefox extensions page runs on Red Hat and Apache, and that Microsoft uses IIS-6.0. But you can also use HeaderMonitor as a web developer diagnostic tool.

I explained how (and why) a web admin might modify what Microsoft IIS returns in HTTP response headers in IIS Server Camouflage. In that article, I mention that you can use sites like Domain Dossier to check what your web server returns in HTTP responses. HeaderMonitor displays some of this information (and saves you a visit). So if you are visiting my site, for example, you'd see "Welcome to Snoopy, behave!" in your status bar instead of OS and web server type and version. [You can probe with web fingerprinting tools (or read earlier blog entries) to learn what web server I'm running.]

Archived at http://www.securityskeptic.com/arc20050401.htm#BlogID391 by Dave Piscitello  

Investigating the referrer spam in my web log files further, I came across a seemingly benign entry, www dot adminshop dot com. I'm curious who is referring folks to my site, so I visit this URL (don't bother), which turns out to be a vendor of what is call Mass Referrer Marketing software. I won't give the company any air time by revealing the name.

This referrer spammer promotes its own software, a "windows-based tool that enables anyone to send whatever website address(es) they wish to hundreds of thousands of sites as a referrer string, quickly and without any manual work" that comes with a "pregenerated URL list of 11,909 unique blog websites to get you started" - in other words, they sell you the software, and sell you sites most likely to be duped into referring to your site when you spam them, or as the marketing collateral argues, "Instant and high volume traffic to your site(s) from both webmasters checking their referrer statistics and surfers on sites that display their referrer statistics publicly."

They are entirely open about what they do. No conscience, no sense of community, just folks out to make money the old-fashioned way: scam it.

One amusing note. The contact email at this site is typed using name (at) domain instead of name@domain. The webmaster is apparently concerned that the company might be the target of SPAM.

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID372 by Dave Piscitello  

I've had my first encounter with referrer spam at my web site. Referrer spam is a good example of how automated publishing can be exploited. Referrer spam exploits the basic browser operation of passing along the URL of a web page to the next page visited. So if you visit www.securityskeptic.com, and then go to www corecom.com, the HTTP request will contain www.securityskeptic.com as the referrer.

And so will a log record of this event.

Spammers can coopt this normal process rather easily, by submitting requests to a site with a the referrer field populated with a site they want you to notice. The result is that web logs of sites spammed in this manner have incorrect and misleading statistics. Aside from creating statistical anomalies, how is this exploitable?

A common purpose of spam is to call your attention or draw you to a spammer's affiliate web site. It seems that enough blogging and web sites are overly zealous to demonstrate their site is visit-worthy, so they process logs, analyze referrers, and post the top visitors and referring links. The process is automated, so referrer spam can covertly bias the analysis, and blog and web sites include links to sites that host porn, phishing, and bogus products. So much for automation, eh?

Mike Healan's written a very good article about referrer spam at spwareinfo.com. He makes some interesting recommendations on how to block referrer spam. Unfortunately, the techniques rely on blacklisting: as your web server processes HTTP requests, detect and rewrite the bogus referrers to a benign site. Several referrer spam blacklists exist to help you jumpstart.

The problem here is the same as blacklisting spam or adware. You enter an arms race with spammers: you update the list, they use a different domain name. What then? When blacklisting begins to fail, are we going to buy security products that visit referring links and scan content?

Perhaps reconsider whether you really need to cater to your testosterone by showing everyone how popular your site is.

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID371 by Dave Piscitello  

I use a very useful freeware web log analyzer, Analog. The program generates all manner of interesting web statistics. Unfortunately, many of the report graphics are very basic.

Report Magic generates more interesting graphical representations of web log statistics, from Analog's output. Like Analog, ReportMagic is freeeware. Combined, the two programs provide as good a set of web analysis tools as many of the SMB commercial software I've tried. If you run a modest web server environment, on Apache or IIS, give this duo a try.

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID366 by Dave Piscitello  

After two weeks of using the Firefox browser and a variety of extensions and themes, I'm ready to join the ranks of those convinced that IE has a legitimate contender. Firefox appears to render pages faster, occupies a modest amount of memory, and has a ton of features you will quickly find you're unable to do without.

Tabbed windows are a singularly convenient feature. Several themes and extensions make the interface even simpler and more intuitive than the "comes with" version, (itself simple enough for anyone who understands CTL-T). The customizable, multi-engine search box is better than most of those you'd plug-in to IE, and you won't run the risk of spyware infestation when doing so. All the common plug-ins (Flash, music players, Acrobat) work with Firefox as well.

The developer community has come up with several excellent extensions. The Sage RSS reader is just plain slick; it's presentation is crisp, and the interface is way better than the (IMO) klunky Live Bookmarks. FireFTP is a promising FTP client. Qute is a really nice (my PC browser looks like a Mac) theme. My time at my computer is better because they exist:-)

Don't expect an entirely bump-free ride. A number of sites running IIS do enough Microsoft-specific web programming that sites just don't present well under Firefox. I've visited sites to do online banking where a single javascript among dozens won't work (and of course, it's the "pay bill now" script). On an intranet site, a flash presentation presents in an entirely different frame size and orientation than it does with IE. FireFTP doesn't recognize a Windows folder shortcut so I can't drag and drop a file onto a shortcut on a web server. Over time, I expect these minor inconveniences to disappear, and I expect Firefox to be very successful.

Firefox isn't susceptible to BHO-based attacks, so will reduce spyware infestations. Remember, though, that BHOs are but one of many spyware infestation vectors, so (a) don't conclude you can forego antispyware software, and (b) don't imagine for a second that the ad- and spyware developers won't seek alternative ways to infest your computer if you're a Firefox user. Like spammers, spyware developers will continue to annoy us because there's a profit to be had in doing so.

Much of the attention Firefox is receiving comes from the growing community who are frustrated by IE's many security vulnerabilities. I'm looking forward to seeing how Firefox compares to IE as its user population grows to a number worthy of the attention IE receives from code crackers. I'm not demeaning Firefox in any way here, merely pointing out that exploiting code running on tens of millions of PCs running IE is currently the greater glory. I earnestly hope Firefox remains as successful and (within reason) free of exploitable code when its user base rivals IE's.

Quite honestly, I don't care who wins the browser war; I just want to browse more safely and efficiently. For now, Firefox looks like it meets these criteria.

Archived at http://www.securityskeptic.com/arc20050101.htm#BlogID356 by Dave Piscitello  

You visit a web site. You complete a form, providing name, address, phone number, job title, and more. How familiar is this? But do you know what the site operator does with your personal data? If you're not checking site privacy policies before you submit personal data, you may be implicitly permitting sites to share what you submit to the *third parties*, a web uphemism for anyone who'll buy and abuse it.

What you need is P3P. More...

Archived at http://www.securityskeptic.com/arc20040901.htm#BlogID306 by Dave Piscitello  

Secure web site administration has become increasingly challenging and labor intensive. IT organizations rarely have adequate time to review web application code and server configuration changes before they are put into production. The result is predictable: web sites are vulnerable to numerous attacks. But being proactive is a tricky proposition for many organizations. Web application protection and vulnerability assessment technologies are enterprise-grade and typically come with a hefty price tag.

I've written articles before describing how small and medium businesses can build a web server vulnerability assessment toolkit. After completing an evaluation and running a number of tests, I recommend you consider Syhunt's Sandcat Suite of web application security tools. Read my evaluation here.

Archived at http://www.securityskeptic.com/arc20040601.htm#BlogID264 by Dave Piscitello  

During the information gathering phase of a web application attack, a would-be intruder will study HTTP headers returned in basic request operations. One useful bit of information - the server's IP address - can be gleaned from the "200 OK" response.

By default, IIS (4.0 and 5.0) will insert the server's IP address in the HTTP Content-location header of a 200 OK message. Why (when) is this undesirable? If you are NATing servers behind a firewall, Content-location will return the server's private IP address. This tells the would-be attacker something about your topology. With a offline browser (WebZip), the attacker can collect all your web pages, and study these to determine whether you are running a single or many servers, and from this, where web (and other) content, CGIs and applications reside.