Tuesday, June 19, 2007

IT Security Market Consolidation...

It's time again. It's that time when the market starts to consolidate. We've seen several "cool" technologies over the past 5 or so years, and many good, stable companies have been built upon them. Web Application Security is one of those niches, to be sure.
As we've seen over the last couple of months, WatchFire has been bought by IBM (who also bought ISS - what were they thinking?), and now HP has bought up SPIDynamics.

What does this mean. Let's analyze. In fact, let's take this beyond the scope of the Application Security niche, let's analyze acquisitions of security companies by the "gorillas" in the broader context of the Security space.

Acquisitions happen for any number of reasons, I will talk about some of them here, and the pros/cons of each:
  • Entry into a new market space (immature niche): This specific case is probably the most compelling. A company buys another small, emerging company because they have some new technology the bigger acquiring company thinks will "revolutionize the market". This happens often quickly and before the smaller, newer company can really even make too big of a splash.
    • Pros: Acquired company often makes a killing on buy-outs
    • Pros: Acquiring company typically gets entry (with their massive resources) into a product space they didn't have to R&D to get into
    • Cons: More often than not, the technologist geniuses who built the emerging company leave, you know what happens next (see NetworkICE acquired by ISS)
    • Cons: The acquiring company doesn't always reap the benefits of the acquisition, and the "hot new technology" fails to impress
  • Entry into a market space (mature niche): This often happens when a large company that has a stagnant pool of products is desperate to find some new tech space to get into. The thought is that by acquiring some new technology, or some new product that through integration a new surge in demand for their products will occur. Sadly, as with CheckPoint buying Zone Labs, and Symantec buying... well, name most any of their recent acquisitions, this rarely turns out well. Entering a mature niche is much like trying to build a hockey team in Nevada. The market is mature (hockey teams all over the place) and it's a commodity that has enough players already. Just because you've bought one of the players in that space doesn't guarantee you a seed in the playoffs, and unfortunately, in the world of business - if you're not in the playoffs you disappear into obscurity.
    • Pros: Infusion of (hopefully) large revenue and new customer base into existing company from acquisition of mature technology
    • Pros: Infusion of product into existing suite; integration is key here if properly executed
    • Cons: New product brought into existing suite, if improperly executed it becomes a nightmare
    • Cons: I'll say it again, you're trying to get into a market that is already mature by buying one of the players - not necessarily a power move.
  • Acquisition of competitor: This type of acquisition is always interesting to watch. You have one company buying another one out to (most likely) "rub out the competition" to use some mobster slang. It's interesting to see how acquisitions affect the customer base of both the acquiring and acquired company. Buying some company (like Microsoft does - GIANT, Teleo, etc).
    • Pros: Competition is gone - typically this frees the acquiring company from having to 'compete' with this competitor and infuses a significant number of user base, or percentage of the market-space.
    • Pros: Market consolidation is generally good for the market-space - makes the market potentially stronger and more mature
    • Cons: Market consolidation eliminates competition, price wars, and sometimes limits innovation (see Antii-Virus space)
    • Cons: Just because your vendor was acquired by its competition does not mean your product will get better... often this is a negative experience for the end-users as one product line inevitably disappears
I'm sure there are many more possibilities - but these are the 3 main ones I've noticed over the past several months, to years. Of course, we have to ask ourselves as consumers of IT Security technology... "What does this mean for me?" Let me give you my opinions here.
  • Market consolidation is going to make more companies more bloated (see Microsoft, IBM, Symantec) and much less useful. What I mean is this - Symantec acquires Sygate (excellent technology, by the way) and is currently absolutely failing to integrate the product(s). I've seen previews of the "integration" which is bad to say the least at this point, and have heard their sales people pitch to me that SAV 11 will have full integration - but no one can tell me what it'll look like, or exactly what that'll mean, or even what features will be kept, or other specification details. It's a failed integration in my opinion, and now Symantec is yet another company with a product line that forks and doesn't integrate very well. Supporting multiple "companies" inside their own shell is like having differing strands of DNA inside a living organism - they'll fight each other for resources and dollars until the host shell is destroyed or falls apart.
  • Market consolidation is also bad because it produces companies which try to do "All-In-One" products - which are historically "decent" at everything, but don't do any one piece well. Again, I don't mean to pick on the same vendors but ISS has had this problem as well - their Proventia appliances have tried to do too many things at once (firewall, anti-SPAM, IPS, etc) and I would argue they don't do any of those things as "best of breed".
  • On the flipside of that coin - consolidation in market-space does sometimes produce gems! When complimentary technologies are integrated well, the users and implementors benefit! I hate to say it - but Microsoft has done a pretty good job of integrating GIANT into their product line, and into OneCare (which isn't very good if you read my previous blog on anti-malware vendor rankings).
  • Acquisition of a security company by a non-security company is bad- period. Cisco buying tons of security companies doesn't make them any more of a security vendor. PIX is still an ACL router, it's barely a firewall. Their IDS is still pretty bad, but... it's integrated into the backplane of the switching core so that makes it all that more valuable. When Cisco bought Okena (the behavior-based host agent for workstations, desktops) and called it Cisco Security Agent the product quality (talking to some of their current/past customers) went downhill. IBM buying ISS and now WatchFire, and HP buying SPIDynamics ... again, a non-security company buying security interests. I am going to have to keep my eye on this as I work for a company who is a customer of many of the products/vendors listed above.
What will this mean? How will the industry take these latest acquisitions? What happens with the products, services, and support of the products which were acquired and not (attemptively) integrated? Only time will tell.

I welcome your feedback.

Monday, June 11, 2007

Chilling ruling in TorrentSpy.com case...

Over at ZDNet news, there is a story has an interesting effect not just on those of us who use BitTorrent (via search engines such as TorrentSpy.com) but for anyone who's browser happens to land on a web server's page. This new ruling makes it possible [in eDiscovery procedures] to allow a plaintiff to force a defendant to create new evidence in assisting with a case against that defendant. That's likely to have a wider reaching effect than the judge who issued the ruling anticipates.

The EFF is still reviewing the ruling, but so far it's not looking good for John Q. Public. What sorts of effects could this have? Let's think of some scenarios...
  1. A legitimate case: RIAA/MPAA/etc sues an (alleged) file-sharing [enabling] site. This ruling enables the plaintiff to try and force the defendant to log all connections and use of the (alleged) illegal activity (whether it's illegal or not) and turn it over to the plaintiff!
  2. A fishing expedition: RIAA/MPAA/etc can't prove that anyone is doing anything illegal, files law suit against some site. This site now can be made to log all activity to/from it, and disclose this information to the plaintiff - which can then enable the plaintiff to find potentially illegal activities which were previously unfounded allegations.
  3. Worse yet...: A company/individual is unhappy with a blog [or other digital expression medium] which has potentially negative information on it (it doesn't really matter what it is, insider information, negative postings, whatever). Company files suit against the blog/news/information site and forces host to log all activity into/out of the site. Company now has information on who visits the site, reads the information, posts, etc. This is REALLY CHILLING.
Here are some more links to other media outlets carrying this story:
  • DigitalMediaWire story
  • TorrentFreak.com article
    • An interesting insight from the TorrentFreak article..."One way or another, it seems that the MPAA is determined to obtain information about TorrentSpy and its users. A complaint issued by TorrentSpy suggests the MPAA paid a hacker $15,000 to steal e-mail correspondence and trade secrets. The hacker admitted that this was true."
  • TheRegister.co.uk coverage

Belgian Voting Machine source code ... available?

Here it is - someone (John Smith) posted it to the Full Disclosure mailing list - but here is the link to the source code for the Belgian voting machines that were used this past weekend in the election.

Taking a peek at the files inside the ZIPfile, we can gleam that most of the code was written in this century - but within the last few years even. They are re-using a number of very very old (particularly in the archive piece) functions which date back as far as 1993... I suppose there's no need to re-invent a perfectly good wheel? I think it's interesting for a number of reasons:
  1. The government actually published the source code - shows they have nothing to hide (no further comment made there...)
  2. Full Disclosure of source code can help make this system overall more secure
I've copied some of the headers, and some of the more interesting pieces of the files here for your viewing pleasure:
  • This is interesting... Generated by MS Access 97?!
File : URNMSG.H

Author : (Generated from MsAccess97)

  • Interesting... written in 1993 and re-used here
Revision History
################

01/06/93: revision history starting date
07/09/93: Previous_Message handling changed, we now use the Prev_M index
as global variable
Fixed : the Prev_M was never incremented in Display_Messages
11/10/93: Display_Strings_URN was adapted so the names of the MASTER and BACKUP
disks are set dynamically in the messages, to allow multiple
BACKUP disks.
17/11/93: The password is converted to uppercase either than lowercase,
due to a change in the Bell's programs.

There's a lot more of this stuff too... feel free to peruse and enjoy. If you're a real code-freak... try and figure out if there are any interesting ways to bypass/crash/hack this baby!

Here is the link to the Belgian Site hosting the code.

.

Friday, June 8, 2007

How does your Virus Scanner stack up?

If you ask me, virus detection the way it's traditionally done (via pattern, or signature detection) is a losing battle the same way IDS is. If you think it through it makes sense. You first have a threat emerge, ravage a significant amount of systems before someone isolates the threat, finds a pattern and writes a signature to detect it. Once the threat changes slightly (heaven forbit we encounter a polymorphic threat) - our detection is crap and the whole cycle starts over.

That being said, it's always interesting to see how virus scanners stack up against today's threats of viruses, malware, spyware, and other 'non-wanted' things on your system which are potentially malicious. The problem is that we have so many blended threats now, from drive-by installs to viruses which can trigger no anomalous activity and act as root-kits.

There is a place on the web that does nothing but compare anti-virus vendors and their ability to protect you. If you're interested in the AC-Comparatives results, you can check them out at this link HERE.

Allow me to summarize what's in the most recent report. The latest report published on May 2007 investigated Proactive/Retrospective testing of on-demand detection of viruses and malware. They also included the False-positive testing and some tests for scanning speed determination. Here are some notes from the test report:
  • A total of 17 products tested (including every one I've ever heard of and then some)
  • Only 1 product earned the prestigious Advanced+ certification (NOD32 Anti-Virus)
  • Microsoft's OneCare is no longer the bottom-feeder (dead last) as it was on the last report - it got a "Standard" rating this time
  • AVG AntiVirus is dead last in detection (ouch)
  • The highest A/V scanner detected just about 84% of new backdoors, trojans and other yet-unidentified malware (AVG scored 10%... ouch)
  • The highest detection rate of "all new samples" was AVIRA & Fortinet at 71%, AVG got 8%
  • Fortinet rules the false-positive arena with >1,000+ false positives (the best was Symantec with zero), the next highest was Dr. Web with 36fp's
  • The fastest scanner was AVIRA, at around 7.49MB/sec, the slowest was TrustPort at 1.21MB/sec

[ Please read the full report for more details, etc that I've omitted in summarizing ]

So - what does this all tell us? For me, it tells me all virus scanners are crap, and the A/V companies are lying through their teeth to get us to buy their products. Next time you see a virus scanner claiming to detect 100% of the known and unknown threats... LAUGH, then cry a little.

Thursday, June 7, 2007

SQL Injection for Dummies

I was browsing my usual places and came across this gem. Pretty cool tool! To give credit where credit is due, I originally found it on the "Darknet - The Darkside" blog, but hey it's good stuff so I'll pass it along.

Here is the write-up from the author's site:

SQLBrute is a tool for brute forcing data out of databases using blind SQL injection vulnerabilities. It supports time based and error based exploit types on Microsoft SQL Server, and error based exploit on Oracle. It is written in Python, uses multi-threading, and doesn’t require non-standard libraries (there is some code in there for pycurl, but it is disabled because it isn’t finished).

Enough said! Here's the link to go get it yourself, and experiment. Remember, this is for educational and experimental purposes only. Please don't use it on appliations/servers you don't own and have rights to!

Link to the SQLBrute tool.

Is top banks' security any better after FFIEC?

CSO Magazine, for those of you who read it, has an interesting column by Sarah Scalet, named "Alarmed". This month, she takes a look at some of the biggest online banking institutions out there, namely Chase, Citi, and BofA, and gives a report card on how they're doing.

Given that you can't really call up a bank and ask them to give you their security measures, because that would be the biggest insecurity of all, it's fair to call a call center and see what the CSRs can tell you. Sarah called each of the banks call centers and asked about online security, and how she could be sure her account was secure and protected. The results are startling - but not really shocking to this writer - since I've been seeing much of this same type of attitute all over.
If you don't want to read the full article, here's a quick summary from http://www.csoonline.com/alarmed/?source=nlt_csoupdate:
  • Citibank: Call-center rep did not seem to understand my questions and tried to refer me to the website for answers.
  • Chase: Call-center rep didn't offer clear explanations but kept trying to get me to sign up anyway.
  • Bank of America: Call-center rep understood my questions, explained customer-facing security mechanisms and offered advice about how I could protect myself.

I am looking for something deeper here though. Let me for one second talk about the FFIEC guideline, and what it really means. Allow me to take a stroll down FFIEC memory lane.

  • August 8th, 2001 - FFIEC releases guideline that says in a nutshell "Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks." This would seem to indicate that banks are free to use their own risk-assessment models; but that overall, multi-factor authentication should be at the forefront of banks' security agencies. This was, after all, a general guideline released in 2001!
  • October 12, 2005 [large gap?] - FFIEC releasees second guideline on online banking authentication. This time, the report makes clear what it finds as inadqeuate - "The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties."

So today is June 7th, 2007. Where are we, with these guidelines? If you read the article in CSO Magazine above, you'll see that we're not really there. Sure, many banks are using the RSA/Passmark system which profiles the machine, gives the user a pretty picture which they selected to "authenticate the site to the user", and we even have 3 challenge questions in case you go to a computer you've never used before. Let's review though - is this "multi-factor authentication" as the FFIEC states in their guideline? I would argue no.

Allow me to explain why I am saying that RSA/Passmark and other derivitives of that solution are not multi-factor authentication. Multi-factor or "strong authentication" is comprised of three things:

  • Something you have - for example - a token, a scratch card, anything you possess
  • Something you are - for example - your fingerprint, retinal image, or voiceprint, etc
  • Something you know - for example - a password, pin, or other "known" item

The technologies banks are employing today technically do involve at least 2 of these things, so that makes them multi-factor, right? What I'm saying is that we're just using an over-glorified multi-password system here. The whole premise of the current solutions hinges on the fact that your computer is "profiled" and a cookie or flash object or something is set there so that next time that you login, the system can say that you're coming to it from a known good source. Is this really true? I'll address that in a second, but first let me hit the idea of these multiple questions. If implemented properly, they are questions you can't google for - which is good. Except that you have to allow the user some degree of leniency - right? If you asked me my favorite ice cream flavor, and I initially typed in "Mint Chocolate Chip" and later when challenged I typed "chocolate chip" is that good enough? These "secret questions" combined with the local token on the machine make this a multi-factor solution but it can be broken.

Broken? How can I claim this? Well, how many trojan horse malware things have we heard of that steal cookies? And how easily can one adapt one of these malwares to steal just the right "token" from a computer so that BofA's site things I'm coming from a trusted source? The answer: simple code changes.

My point folks - what Banks have done is adhere to the letter of the law, and now the spirit. Are we any safer today than we were before Chase, Citi, and Bank of America implemented these solutions, when I used my username/password to get into their sites? Sadly the answer is no.

Wednesday, June 6, 2007

Yahoo! Messenger - Big vulnerabilities?

eEye is reporting that there are "multiple flaws" within Yahoo! Messenger 8.x - which are apparently critical. Remote code execution IS POSSIBLE, so ... watch yourselves.

I can't find any reports of a patch - or upgrade. More if I find it before you do.

Here's the link over to eEye's Advisory - with very little information.

EDIT:
As promised, here's more from the Full-Disclosure list... there may still be more!

WebCam Exploit (Run Remote Code!): http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/063817.html
ActiveX Exploit (Yahoo! Viewer):
http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/063819.html


06/08/07 EDIT
Apparently - these are "super-critical" vulnerabilities, and should be patched immediately if you are using Yahoo! Messenger.

Here's a link to the TechWorld.com story.

Losing the battle in e-Commerce authentication

Spending many years in the financial sector, and having a strong inclination into the Web Application Security component of e-Business, I have carefully watched the evolution of "secured authentication". I will briefly give an overview here, and then dive into why I feel we're losing the battle.

Over time, authentication on eCommerce/eBanking web sites/applications has become more complex. This increase in complexity (although perceived as necessary) has not necessarily been paralleled with an increase in security. Over time we have been trending towards more complex passwords - which unfortunately has often resulted in users forgetting more often, not changing their passwords, and even writing them down on post-it notes!

Password complexity failing, we have turned to other ways of authenticating users into our web-based systems. The issues have continued to hound and compound though, even as we've gone into scratch-cards, chip + pin smart cards, one-time-password tokens (like the RSA product, now famous), biometrics and all sorts of interesting combinations thereof.

I will make a statement that all these have failed us. We are very simply losing the battle against the 'evil hackers' because no matter how good of a mousetrap we build, the mouse always outsmarts us. Quite simply, the evildoers build better mice just as fast as we can build better traps. This is a race condition we cannot win.

Let's take for example, this specific little article on NetCraft.com. It describes how one genius idea (a Barclay's Bank "strong authentication" component was broken by the use of a targeted Trojan horse attack. This type of sophisticated screen-capture Trojan (called "Purchase confirmation") and documented at Codefish Spamwatch (currently down) is indicative of the lengths that attackers will go to in order to steal valuable account information. It's even worse-sounding if you consider that the article was posted on Apr 17, 2004! That's incredible!

What lengths are attackers going to in order to get your personal bank data? What types of attacks are next? Just what is the answer here?

I think these questions are best addressed by a line from P.T. Barnum - "There's a sucker born every minute". Yes - a good percentage of phishing and password-stealing attacks are very difficult to distinguish from legitimate sites and applications - but the majority of them, if given proper user education and carefulness - are detectable (at least today)!

Forget passwords, and their ever-increasing complexity. Yes we need to reach a level where we are comfortable with the fact that our front-door security (authentication) is "good enough" - but there has to be more to it. We must do the following, or we will continue losing battles:
  • Educate our users - There is no easier way to combat crime than to educate the user population on what they should and should not do in the digital world.
  • Establish baseline standards - Find what is "good enough" (read: enough mitigated risk) to be reasonably secure that the level of effort to keep people out isn't keeping out legitimate users. Remember, the balance is harder to obtain than we think.
  • Perform back-end analytics - check for anomalous activity such as a user logging in from two very different geographical regions (via IP address tracking) such as California and China within minutes of each other. There are some basic things we can do here...
    • Profile the user : What pages are visited, when, how long
    • Profile the source (machine being used to connect) : Basic machine-level checking (such as headers, some basic JavaScript, etc)
    • Profile the behavioral patterns of the user(s) on the system : What do general users do, and track patterns of behavior (i.e., people always log in on Friday mornings to pay bills after direct-deposits have gone through)
So to tie this all up...back to my point - why are we losing the battle against the evil criminals? We're banking on passwords, and authentication complexity to save us. We should have realized that approach wouldn't have worked long ago - when the ship first started taking on water, but now we're so invested in these password-based technologies that it's going to be a hard road to recover.

Let's hope we can change our perspective, and make better decisions.
Google+