The Security Skeptic

In the lastest episode of LiveSecurity's monthly podcast, Radio Free Security, host Scott Pinzon and discuss I how operators of illegal web sites use an evasion technique known as Fast Flux to avoid being located and shut down by law enforcement agencies. During the podcast, we share the insights into these attacks obtained through extensive analysis by organizations like Spamhaus and the Honeynets Project, look at some of the countermeasures that are being used to combat fast flux today, and consider future, additional countermeasures that might frustrate fast fluxers as much as they frustrate security practitioners, LEAs, registrars, and end users today.

The entire Radio Free Security podcast is available for download from iTunes.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID635 by Dave Piscitello  

An InfoWorld security columnist posted the following to the BugTraq list at securityfocus.com:

I'm tired of the 0-day argument. I say forget the confusing acronym and use something else, like: unpatched exploit or previously undisclosed vulnerability or something like that.

It's unusual and somewhat gratifying to find a member of the 4^th Estate who takes issue with creating clever labels to distinguish among the indistinguishable, with the net result adding to the F.U.D.

When 0-day first appeared in print, I struggled to understand exactly how the term helped to characterize the type of attacks so labeled. Specifically, exactly what aspect(s) of an attack did 0-day describe?

Did it take an attacker zero days to write the exploit?
Did the exploit take zero days to propagate?
Did the exploit take zero days to infect, infest, or compromise a target?
Did it take zero days for countermeasures to be identified?
Did it take zero days for the countermeasure to be made available to the community?
Did it take the community zero days to implement the countermeasure and mitigate the exploit?

Depending on the amount of time represented by zero days, I can answer YES or NO to some or all these questions save the last. Why not the last? I doubt very many attacks, 0-day or otherwise labeled, are entirely mitigated in zero years much less days.

The InfoWorld columnist is absolutely right. Terms like 0-day have place in the vernacular of Internet security. They belong in marketing collateral. Yes, let's exile 0-day to marketing collateral and read it there.

On second thought, let's not read the marketing collateral. It is a silly place.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID634 by Dave Piscitello  

The Honeynets Project & Research Alliance has released a paper on fast flux attacks. Fast flux is an evasion technique that is used to thwart attempts to locate and shut down illegal web site operators (folks who host and profit from identity theft, pornography, illegal pharmaceutal sites, etc.). he paper, KYE: Fast-Flux Service Networks explains the complex network architecture supports these malicious activities and offers advice to service provider networks who seek to detect and mitigate these threats.

I've been studying fast flux attacks with colleagues in my SSAC committee and the Spamhaus organization. One flavor of fast flux attack (double-flux) uses DNS server information in domain name registrations to enhance evasion. This creates some very interesting problems that may best be dealt with at the domain name registration level, by the registrar. I hope to have more to say on this soon. Meanwhile, I strongly recommend that you read the Honeynet paper.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID632 by Dave Piscitello  

I coughed up five dollars, purchased a PayPal Security Key™ and now use it for my eBay and PayPal transactions. I'm very curious to see how this added security measure by a major online merchant with a diverse customer base will play out. A considerable number of PayPal and eBay's customers are non-technical, so what percentage of PayPal users will adopt Security Key™? How well has PayPal anticipated the helpdesk and loss-replacement costs? Will the *realized* reduction in fraudulent bids, sales, impersonation, identity thefts, and online payments justify the investment?

Whether Security Key™ succeeds or fails, I believe this initiative has the potential to be a landmark event. Multi-factor authentication is decades-old technology, yet its penetration remains small relative to password-only authentication. Imagine if, one year hence, the PayPal/eBay experiment has demonstrated that deployment can scale to a user population that's at least an order of magnitude greater than the enterprises that commonly adopt tokens, that users finally acknowledge that stronger authentication than passwords is beneficial and will *voluntarily* adopt and comply with multi-factor authentication, and that the companies are able to report a marked reduction in impersonation-based attacks and a corresponding reduction in losses associated with such attacks. Such results would be hard to ignore, and perhaps, finally, we'd seen the beginning of the end of password-based authentication.

"To sleep, perchance to dream- ay, there's the rub." - Hamlet (III, i, 65-68)

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID633 by Dave Piscitello  

Shortly after 911, airline passengers were expected to provide positive identification at a security checkpoint before proceeding to a departure gate. At the gate, passengers again showed positive identification at the departure gate before boarding the aircraft. Today, travelers are rarely asked to show IDs at departure gates. Most travelers would agree that this is a small blessing, one less inconvenience to cope with while tolerating air travel (I use tolerate intentionally because I know of no one who enjoys flying these days).

Let's consider the risk that authenticating only at the perimeter introduces to air travel security. Two individuals, Bob and Dick, depart from the same originating city with different destinations After showing positive identification and proceeding through the security checkpoint, Bob and Dick meet and exchange boarding passes. The probability that Bob or Dick will be challenged for identification is small, so Bob can now traveling to Dick's destination and Dick to Bob's. Under the current implementation, proving one's identity at a security perimeter makes it trivial to evade an important authorization policy; specifically, individuals are expected to travel according to their itinerary.

As my partner Lisa Phifer observed when I shared this observation, the boarding pass is treated as a very primitive form of security token, one that is weakly bound to an identity. My problem is that, weak or no, this token nonetheless provides the holder with an authorization to board an aircraft without proof of identity. Specifically, it can be exploited to allow an impersonator board any flight for which he can obtain (without incident) and credibly spoof the party identified by a boarding pass, and this seems pretty easy.

The airline identification policy is an example of perimeter authentication. We find examples of a similarly exploitable Internet security policies among organizations that connect remote offices to a main office using an IPsec site to site tunnel via security gateways (firewalls). In many configurations, the remote and main office security gateways perform mutual authentication using IKE. The IPsec security associations used to accommodate remote office access often base allow/deny policies traffic from remote sites on the IP addresses used at the remote site. An IP address is easily spoofed by an attacker who gains access to a LAN or WLAN at a remote office. That attacker now has the equivalent of an identity authenticated at the perimeter (the remote office security gateway) and a boarding pass (the spoofed IP address), and can thus connect to a server that the IPsec SA allows from the spoofed IP address.

Absent user level authentication that is additionally performed at the individual servers, this is an inherently weak and exploitable policy and should be avoided.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID631 by Dave Piscitello  

I subscribe to a number of security mailing lists. I receive hundreds of posts per day to some of these lists. Like any mail list, some posts are relevant and informative while others don't meet these criteria. To optimize my mail list time, I identify the practitioners whose posts almost always prove to be relevant and informative. Paul Melson is one of the handful of folks whose posts to the firewall-wizards mail list rarely disappoint. One recent post caught my attention because it was succinct, informative, and sound advice for anyone who was attempting to implement a host intrusion detection system on a server.

With Paul's permission, I've copied the body of his message here in my guest corner.

...here is my advice in rolling out HIPS, especially on servers.

1. Benchmark performance on the servers. For Windows, using System Monitor is fine. Use the following Perf Objects:
   • Processor / % Processor Time
   • Memory / Pages/sec
   • Memory / Available Mbytes
   • Physical Disk / % Disk Time

   Compare performance with and without HIPS. Note where servers need more hardware to accomidate HIPS. Also keep an eye out for performance conflicts. HIPS is invasive and can screw things up. This can be especially true of vendor A's HIPS product trying to cohabitate with vendor B's AV product.

2. Plan time for deployment and plan 4x that time for initial tuning. One thing Entercept did shortly before McAfee acquired them was to create a kind of step-up policy configuration. From deployment you can turn on their high level events and then medium, and low and so on. And you can do this in a way that keeps you from being deluged with events from the time you turn on the agent. Of course, I think this probably also leads to most deployments never stepping up to more detailed detection. Plan to step up and expect to spend lots of time tuning. If your HIPS vendor doesn't have a tiered protection/logging policy like Entercept does, well, make that 6x as much time.

3. When creating policy, logically group and deploy by application and function, not by OS version. A Win2K3 server running WebSphere is more like a Win2K server running Jboss than it is like a Win2K3 domain controller. Group them together because their policy and tuning should be similar. (Of course, a Solaris server running J2EE should not be tuned the same as a Win2K server running Jboss.)

If you like Paul's perspective and want to read more, visit his blog at blogspot.com. I will:-)

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID630 by Dave Piscitello  

Colleague and friend Marcus Ranum wrote a really interesting article and review of executable control software for Windows XP. The article, Execution Control: Death to Antivirus, documents Marcus' long struggle to deal with malware on Windows XP. In typical Ranum fashion, Marcus delivers one scathing criticism and condemnation of vested self interest after another as he explains why he punted Norton AV from his security software inventory, how he began hunting for a "default deny" approach to managing executables on his personal computers, how the honeymoons with two commercial products ended in divorce, and how he finally found a freeware soul mate in the form of ExeLockdown from Horizon Data Sys, Inc..

Unfortunately, while Marcus has found a security soul mate, the rest of us won't be so fortunate. I visited Horizon DataSys to download a copy of the freeware and it's no longer available. I used the real time chat to ask a company rep why it was no longer available and he explained that "we are creating a better version that will work in enterprise environments as well as Vista. The old version was offered as freeware and was more of a support issue without any revenue."

While I can't blame a company for wanting to earn a profit and focus support on for fee products, it's hard to understand why they can't leave the freeware available for users sophisticated enough to use it without support. I also can't fathom how any company that has the good fortune to get as respected an authority as Marcus Ranum to write something positive about its product would "leave the money on the table" by taking the product out of circulation. Isn't it possible that the cachet a company earns from word of mouth like, "oh, yeah, that's the company that has that neat execution control program Marcus wrote about" is worth a token support effort for a freeware program? Some day, someone will explain marketing to me.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID629 by Dave Piscitello  

In the February 2003 issue of BCR, I co-authored an article entitled The Sad and Increasingly Deplorable State of Internet Security where we claimed that, "overall, Internet security really is in horrible shape." We were convinced by computer crime statistics, incident reports and our collective experience that the security technology deployed to date had not proven effective. In fact, incident frequency and cost were increasing at an alarming rate, despite the fact that most organizations were claiming to have deployed state-of-theart security defenses.We predicted that security would worsen before it improved.

Four years later, BCR invited us to comment on the state of Internet security. Read Sad and Deplorable State of Internet Security, Revisited to learn if things have changed for the better or worse.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID628 by Dave Piscitello  

While combing my local archives, I located two additional articles I published at SecurityPipeline:

• Add "Protect Your Domain Name" to your security check list

• Security Freeware: More or Less than you paid for?.

  I'm confident these are the versions originally published.

  Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID627 by Dave Piscitello  

While updating my antispyware resources pages, I discovered that the hyperlinks to articles I'd written for SecurityPipeline were redirected to DarkReading.com. I contacted the editors, who explained that Security Pipeline's content was not carried over to the new

publishing platform when Dark Reading was created. Dark Reading's editor, Tim Wilson, did grant me permission to publish these articles at Core Competence's site, and you can now find the following articles here at the Security Skeptic:

• When It Comes To Anti-Spyware Tools, Accuracy Is Key

• Legislation Won't Stop the Spyware Juggernaut

• How to Keep Spyware Off Your Enterprise Network

• Blocking Spyware at the Network Gateway

I also took the opportunity to update the Spyware resources pages and have added several recent articles, reviews and recommendations for antispyware freeware.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID626 by Dave Piscitello