The Security Skeptic

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  

A recent thread on pen-test list at SecurityFocus.com exchanged favorite password lists for use in bruteforce attacks against weakly authenticated user accounts. Brute force password cracking tools like John The Ripper and numerous password recovery tools employ such lists.

Some of the posts offered interesting resources. To save you the bother of finding the thread, I've copied the hyperlinks to those resources that I found interesting:

• The Openwall Project offers a for-purchase CD of wordlists and common passwords in over twenty languages, along with trial versions password cracking software.

• Phenoelit provides a fairly exhaustive (3Com to xyplex) list of manufacturer default accounts and passwords.

• reversing.org presents a very interesting article describing the process of generating word lists for bruteforce cracking.

• Cotse.net has dozens of word lists, categorized in various ways: abbreviations, language-specific word lists, language-specific surnames, comic and cartoon characters, famous people, music genre, actors, myths and legends, etc.

The lists I mention give you enormous dictionaries against which to test the kinds of passwords users are composing. Since these lists are mostly common language words, the lists are quickly negated when you impose password length and complexity criteria on users (e.g., through a group security policy pushed to managed client PCs via Windows Active Directory). Good brute force password cracking and recovery tools of course factor such criteria into their processing.

There are also various "short" lists of common passwords that might be used in stealthy penetration testing. A claim was made by the poster that words from this list match a password in use on a network 80% of the time are "interesting". Here's a copy for your convenience (the hyperlink provided in the email was a cached Google page and will likely be blocked by many anti-fraud and phishing utilities)

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

Today's question from the NWW Security Tour 2005 is

Our college has a limited budget for security. With threats at so many levels, would it be prudent to focus on one specific vector (i.e., email, apps, web, firewall/IDS/IPS)?

To answer this question in a qualified manner, I asked colleagues who run IT departments at universities and colleges where they focus their time and attention.

The first reply I received suggested honeypots. At first, I was surprised, but reconsidering, I realize that this is actually a very practical security activity at a college, where talent is plentiful, the cost to acquire it is low, and where legal recourse for perpetrators isn't limited to civil and criminal prosecution (the University, for example, can dismiss the student).

Admission control appears to be security activity of equally high priority to universities and colleges as it is to enterprises. Keep infected and poorly maintained client devices off your network and you'll reduce the vectors for malicious code.

Improving security of wireless LANs is also mentioned. Broader adoption of IEEE 802.1x is consistent with admission control initiatives.

My $.02. Leverage the availability of the talent that surrounds you. Convince the young, easily-influenced, enthusiastic minds that counter-hacking and forensics is much sexier than attacking, and that involvement in University security activities will look terrific on resumés. Involve them in all those "arms and legs" activities that undermanned IT staffs everywhere struggle with. You'll not only earn a brilliant ROI for your institution, but you'll be "paying it forward" by increasing the number of security white hats.

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

Many places I visit remain WiFi challenged. Recently, while at San Jose airport, I needed to send an email and attachment to a colleague. No wireless service was available. With nothing to lose but time and battery, I experimented with a lighter shade of wireless: my Bluetooth enabled T-Mobile cell phone and an iPass dialup account.

Using the built-in Bluetooth personal area network adapter, I "paired" laptop with my cellular phone, started my iPass client, chose a local number and dialed. After the obligatory modem negotiation, I established a 9600 bps analog connection.

At this baud rate, email works fine (email worked fine at 300 bps in the eighties, and probably works fine at less). When I closed my connection and boarded the plane, I paused a moment to recall the last time I actually relied on 9600 bps: 1988. I had a dialup connection to WorldLink, a service run by Internet provider PSI. I had a Hayes compatible modem, and telnet, ftp, pop and smtp were my killer apps. I think I paid $19.95 per month but it may have been $29.95.

Today, while at one of the several Starbuck's in my neck of the woods that doesn't have WiFi, I again use Bluetooth modem facilitated dialup. This time I needed some information from the Web. It wasn't DREADFUL.

When I purchased my first cup of coffee, I asked the folks in Starbuck's if they knew when T-Mobile might install WiFi and they said they weren't certain but they didn't think it would happen any time soon. So when I booted my laptop, I disabled my WiFi adapter and turned on Bluetooth to extend battery life. As I wrapped up my session, I disabled Bluetooth and enabled WiFi. Windows Zero Configuration immediately notified me that wireless networks were available. Curious, I found a secured WLAN (yes, some small businesses are actually using encryption!) and an open network. Thinking that the Starbuck's staff was mistaken, I connected and was directed via a Colubris AP to a secure login page for public WiFi access.

The irony? The service wasn't T-Mobile, but wireless broadband offered by Hargray Communications, the independent LEC that serves the Low Country SC area.

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

Gather folks together to discuss application and data security and you will invariably find at least one cynic. The Network World Security Tour 2005 in Seattle had several cynics (imagine...). One asked,

Can you convince me that holes are not left intentionally to "create" business for system security vendors"?

I can't provide convincing evidence that such behavior is non-existent in the industry. I can't provide any concrete evidence of instances where bugs have been intentionally planted, either. But given the sad state of software development, I can't really imagine that anyone would bother. There are *so* many lines of code written daily, with little or no review for security flaws, and the barest of efforts at quality assurance, *contriving* bugs strikes me as about as pointless as importing sand to Saudi Arabia.

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

This question from a NWW Security Tour 2005 Q & session was interesting because it illustrates how assumptions can lead us astray. The first assumption here is, "encryption will become ubiquitous." Let's assume that this is true. The fact that encryption is ubiquitous does not guarantee that it will be end-to-end, from client-to-application, in all cases, nor does it imply that it will be applied at the same protocol level. Organizations may use SSL from client-to-proxy over external (e.g., Internet) connections. The same organization may use site to site IPsec to connect its many locations, and WPA over wireless LAN segments in trusted internal networks. I envision these solutions as all comprising a typical deployment in the future.

Where an organization deploys IDS/IPS should be influenced by the kinds of attacks it wishes to detect and block. An organization concerned about denial of service attacks benefits from a firewall with DOS IPS capabilities protecting its internal networks at or near Internet access circuits. If the Internet-facing firewall terminates IPsec tunnels and the worry is DOS and other network attacks vectored through these tunnels, then place IDS/IPS between the Internet firewall and internal networks. Firewall/IPS appliances will (eventually) provide DOS protection, VPN termination, and IPS for network as well as application level attacks; using best of breed appliances and software (proxies) will always be an alternative to multi-purpose security systems.

Similarly, organizations using SSL for remote access can inspect user traffic for application level attacks at or behind the SSL VPN appliance, using application proxies (my choice) or deep inspection IPS solutions. Organizations that use SSL/HTTPS to protect traffic from client to application can use host-based IDS/IPS on individual servers, or terminate SSL at a switch/firewall that protects the server farm/data center, using a switch that is IPS-enabled.

IDS/IPS aren't obsoleted when encryption becomes ubiquitous. The considerations for where to implement IDS/IPS in a network merely change.

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

Spyware was a hot topic at the NWW Security Tour 2005 Q & A sessions. One attendee asked for opinions on running multiple spyware solutions on the desktop. It's pretty common for anti-spyware specialists to recommend that you run more than one antispyware solution in posts to antispyware forums like SpywareInfo.com. The most common recommendation is to run both a reputable commercial solution (Aluria, WebRoot, SunBelt CA eTrust...) alongside a freeware product (typically Spybot Search & Destroy), and complement this with a reputable antivirus solution.

One oft-cited upside of running multiple solutions is to increase breadth of detection: one solution may detect spyware that the other overlooks (or does not yet have a definition to distribute). Another upside is that one solution may perform a more complete removal of a spyware package (i.e., running a 2^nd removal tool immediately following the first may result in the detection of a Registry setting that should have been removed for completeness by the 1^st tool but had not). The downside is that the products somehow interfere with each other, or even the antivirus solution.

The humorous side, as I mentioned in this SecurityPipeline article, is that "some products point accusing fingers at each other".

Given the number and combinations of antimalware software you could install, I can't absolutely guarantee you'll have no adverse effects by installing more than one antispyware solution. I can only tell you that I've installed combinations of commercial antispyware software alongside Spybot S & D, SpywareBlaster and SpywareGuard on every PC and laptop in my office and have not experienced any ill effects.

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

Christopher T. Beers has performed a fairly comprehensive review of seven antispyware products for SecurityPipeline.com. In Review: Spyware Detectors, Beers reviews products from CA eTrust, F-Secure, McAfee, Trend Micro, Lavasoft, Sunbelt, and Webroot. The analysis is very thorough. A really clever and useful feature of this review is that it lets the reader adjust the product feature weighing factors. You fire up a Java applet, adjust weight of factors you are most interested in, and the Report Card recalculates the product scores. I've always complained that weighing factors selected in comparative tests weren't useful, and now the tuner's in my hands - cool!

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

The folks at NSASoft, LLC offer a number of auditing tools from their Network Security Audit Software package as individual freeware applications. Several of these are useful tools for exploring your PC and browser for signs of spyware:

• Registry Auditor scans the Windows Registry and identifies entries that it suspects are adware, malware or spyware. For each suspicious registry entry, Regauditor identifies the Registry Path and value, the location of the file referenced by the entry, and (most importantly), a URL where you can read about the offending item.

• BHO Scanner enumerates browser helper objects installed on your PC, and again distinguishes useful BHOs from parasites and trojans. One feature that I find unique to this application is the ability to scan remote PCs for which you have remote registry access rights and administrator privileges.

• IE Cache Explorer displays cookies, history and temporary Internet files and allows you to delete them. True, there's nothing earth shattering about this utility, but the detailed analysis of cookie information (URL, hit rate, use count, etc) can be helpful in identifying ad cookies, and you can use the URL to customize your blocked sites list in IE or at your firewall or content filtering proxy.

Many other network auditing utilities - finger, dns and whois clients, port and network scanners, traffic generators - are also available. The for-purchase NSAuditor incorporates all these utilities into a convenient single UI with more advanced features. Kudos to these folks for offering truly free and useful utilities to complement a useful and nicely priced commercial product.

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

In January 2003, I published an article, Blocking Public Instant Messaging. Today, I received a email from TechTarget's SearchSecurity.com inviting me to read Mike Chapple's similar security tip entitled How to block IM applications in the enterprise. I read Mike's tip to learn if admins had learned any new tricks in blocking IM. Along with the recommendations I published in 2003, Mike's added an interesting one: use the Software Restriction Policies in Windows Local Security policy (secpol.msc) to block the installation of IM applications.

This is indeed a good idea, and I'd add that enterprise IT admins can perform the task by create a Group Security Policy to restrict IM application installations using Active Directory and can push the policy to all managed desktops.

Even though Mike adds a caveat to this approach, saying, "You'll need to do this for every version of IM software released by all of the major providers – AIM, Yahoo!, MSN and ICQ", he overlooks the popularity and availability of multi-protocol IM clients, and thus underestimates the scope of the solution. I did a cursory search and found over a dozen IM clients, including GAIM, Trillian, Miranda, Psi, ICQ, Odigo, WWIM, &RQ, Beenut, myJabber, and Instan-T. And of course most P2P software (Skype, pulver.communicator, GoogleTalk, shinkuro...) support messaging. .

Basically, blocking IMs remains a formidable task. In 2003, I suggested admins combine firewall, routing, and name server measures with monitoring tools. Mike adds, "combine these techniques with strong desktop management policies and you'll have the best chance of keeping your network free of IM activity."

"Free of IM activity" is probably a bit optimistic. New clients and messaging protocols may simply appear too frequently and, like Skype, may become too elusive to isolate and block.

It's no wonder that a related link from the page with Mike's column discusses an increase in IM threats. Could there be a greener field for attackers than ever growing set of consumer grade, firewall-evading client applications that encourage promiscuous file sharing and in many cases, were developed without the benefit of the specifications of the multiple IM protocols they try to support?

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

Following the second leg of the NWW Security Tour, I have even more questions to answer. Trying to knock off easy and popular ones quickly, I chose,

Where is the best place to put IPS in a network?

Where you place IPS (or IDS) is largely affected by the types of attacks you seek to block and the vectors you believe attackers will use. If you are worried about network level denial of service attacks from origins outside your trusted networks, you might use IPS at an Internet-facing firewall, but if you are worried about DOS attacks emanating from trusted network segments - WLANs, home office broadband and business partner networks connected to your trusted networks using IPsec VPNs - then you might place defenses against DDOS closer to server farm(s), or even on individual servers, in the form of host intrusion detection and protection. The closer you place IDS/IPS to actual assets, the more you are able to defend against both external and "insider" threats.

IPS can also block application level attacks. The same stipulations apply. I wrote about application protection in some detail here.

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

I ranted about my issues with Adobe Acrobat Standard in blog #453. Creating pdf isn't very satisfying, either. I coerced into creating pdf files by my Office-hating colleagues, many of whom are entirely naive to the poor social skills Acrobat Standard and Windows XP exhibit when they occupy the same sandbox I call my PC.

Today's chronology of events is typical of most of my Adobe punishment, I mean, publishing experience. I launch Acrobat Standard, select "Create PDF" and open a powerpoint file. I'm immediately greeted with

Unable to find Adobe PDF resource files. Do you want to run the installer in repair mode?

I'm not really interested in this, do I have a choice? Adobe Acrobat 6.0 installer begins, and of course, stops because (you bet),

Adobe Acrobat 6.0 must be closed before continuing the installation.

I close the application. Installer begins, but I immediately am confronted with a dialog box explaining that

The feature you are trying to use is on a CD-ROM or other removable disk that is not available.

This is undoubtedly true, since I've *downloaded* this software. Clinging onto a faint glimmer of hope offered from the dialog box, I browse and search for ACROSTAN.MSI. Sorry, XP informs me,

Search is complete. There are no results to display.

I cancel the operation. Not content to set me free, Acrobat 6.0 tosses one last grenade into my lap, the nefarious

Error 1706. No valid source could be found for product Adobe Acrobat 6.0 Standard.

I study this sentence for a while. I can't argue the logic. There certainly seems to be no valid source for Adobe Acrobat 6.0 Standard that consistently works on *my* Windows PCs.

I'll convert the presentation into html. Let them eat gifs.

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

Some time ago, the question, "What do those of you in large environments do to manage your rulesets in terms of removing access that is no longer required?" was raised on the firewall wizards mail list. I failed to copy the mail list when responding to the question, so I'll post it here.

Let's assume your organization is policy-driven, and access adheres to authorization policies developed during the course of routine risk assessment. In situations where an organization's needs for application access are reflected in your policy - i.e., policy as of 7/17/2005 says SKYPE is permitted outbound from our trusted networks - then stakeholders who agreed to allow this application must also agree when that application is no longer needed or appropriate before IT can change the firewall policy. To handle *application deprecation* in this fashion, organizations institute a regular review cycle, and the excellent among these trim application "fat" whenever stakeholders conclude an application is no longer required.

Just as policy-before-access empowers IT administrators with the means to deny spontaneous and random introduction of applications with no (obvious) business purpose, it can also prevent applications from hanging around beyond their useful lifetime. How is this beneficial? In situations where an application simply piggybacks on an existing firewall policy, e.g., allowed port http/80 outbound, and assuming you'll always need http outbound, I'll admit it's not obvious. But consider a situation where your organization is not only allowing a defunct SNA application (yes, it's still around!), but rate-limiting traffic from other applications as well because of the bandwidth and latency you once reserved for tunneled APPC/LU6.2 sessions.

What if your organization isn't policy driven? If you log allowed traffic, you can use traffic logs to identify whether an application is still in use. If you also enforce user (and group) based access controls, you can identify who's using it. In the first case, if you see d=little or no activity, you can simply deny access and wait for the phone to ring. In the latter case, if you see diminishing to little traffic, you can inquire whether a business need still exists among the dwindling user constituency; if none is justified, you close the access. (Note: if http/80 is your organization's outbound ANY port, read blog #419.)

How far can you take firewall policy life cycle management? Some organizations are plain ruthless, and shut down access if little or no activity is seen as a matter of policy. This can be tricky, as some business critical applications may only be used sparingly, e.g., an application related to quarterly reporting (earnings, accounting, inventory...). Whether you are policy driven or not (but especially if your organization practices policy life cycle extremism) always document when you deny access and save the exact rule you modify in your firewall configuration. You'll be ready to restore service in the event a deprecated application is resurrected without a moment's (or day's) hesitation.

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