Wednesday, May 28, 2008

What to make of "Hacker Eliminator"

Greetings - I've been traveling a significant amount lately so it's harder and harder to find time to sit down and write something more than meandering thoughts - but I've been putting this together in my head for a while and now it's time to write it down and hit the Publish Post button.

As many of you may already have figured out I tend to be hard on companies that are, how shall I put it, fraudulent in their "security" services. "Hacker Eliminator" quickly rises to the top of this list like spoiled milk in my latte... quite obvious, yet still oddly intriguing. A little digging revealed the following:

Company Name: LockDown Corp.
Product Name: "Hacker Eliminator"
Product Motto: "Picks up where antivirus programs and firewalls leave off"
Home Page: http://hacker-eliminator.com/
Current verion: 1.2

First off, allow me to say that *anyone* who puts the following on their site/product invites people to outright make fun of you... "Hacker Proof Guarantee: You will not become infected with a remote access Trojan without getting a warning. This is why" Impressive! They offer 3 layers of protection - scanning files, detecting startup methods, and detection of Internet servers/processes. Again, very impressive... I think every virus scanner on the planet does this... in 2001.

Below is a quick paste of the quote from "LockDown Corp."... wow - they have 6 years of experience! That's almost as many as I have they must be good!
About LockDown Corp.
LockDown is an established security Company. Our staff has been servicing end users, Fortune Five Hundred Companies, State and Federal Government Agencies as well as Military Branches, with data and Internet security / training for over six years.
Anyway... I just had to click on the "Buy Now" page, which by the way is some 3rd party payment company called "Onesecond-128.bitencryption.net". From their SSL certificate they installed the cert in June of 2003, and set it to not expire - a great security (I mean, usability) feature. The issuer, obviously a trustworthy company, is as follows:
E = system@lockdowncorp.com
CN = *.bit-encryption.net
OU = 44-P Dover Point Office
O = LockDown Corp
L = Dover
ST = New Hampshire
C = US
YIKES. Something else interesting on this page, where you'd "buy" the Hacker Eliminator product - notice some of the other awesome products for purchase? Also, look at the bottom of the page, interesting enough the Copyright date and browser compatibility as here:
Copyright 2002 One Second Online Services: Email:sales@lockdowncorp.com
Site best viewed with IE v5.0 or above

So let's recap, so far everything looks and smells like Fisherman's Warf on a sunny morning... It gets better folks, it just gets better. Check this page out. They're using SubSeven 2.1.4 (how old is that again?) and NT 4.0 as the screen shots - are you kidding me?! Wow - I'm convinced, sign me up, where do I send my check?

At least let's look at LockDown Corp's crack team of researchers and see what sorts of things they've uncovered lately. Click here, and here, but be prepared for some serious 0-day stuff. Be careful of those "Hacker Tricks"... Hopefully their privacy policy is at least responsible.... oops!

Alrighty, so by now you're asking yourself - "Self, is this even a real company? Are they for real?" I'm thinking that myself, and while I download and dissect their EXEs I offer you the chance to decide for your own damn self. Oh, and in case you want to look them up, their DnB number is #15-483-9976 and their Tax ID # is 02-0509165 (right off their pages).

Oh, one last thing... They're running Apache 1.3.27, which is from back in... oh, 2002 I think?

EDIT: So I went back to the "Wayback Machine" and dug up their site, wow... their last update was Aug. 18, 2007 and since 2002 when the site first went up the site has been changed a whopping 13 times. Go Hacker-Eliminator and LockDown Corp!

Monday, May 19, 2008

AMEX password policy - "a daily WTF"

This, as my good buddy Russ points out - belongs on the daily WTF. I was registering my account on the AMEX (American Express) site and came across this mind-boggling "feature". Apparently, AMEX has a policy, as follows, for their login and password that I would whole-heartedly disagree with. To be fair, there are many schools of thought that would dictate that password policy is irrelevant on a website, and that security shouldn't be based on password strength alone - but I don't necessarily think that this means that you should forgo logic on password policy either.

With that being said - here's a lovely screen-shot, complete with auto-pop-up from AmericanExpress.com.



I would absolutely LOVE to hear the community's feedback to this. Am I nuts to think this is a little low on the security totem?

User ID Policy:
  • 5-20 characters
  • At least one letter (not case sensitive)
  • No spaces or special characters (&, >, *, $, @)
Password Policy:
  • 6 to 8 characters
  • At least one letter and one number (not case sensitive)
  • No spaces or special characters (&, >, *, $, @)
  • Different than UserID

Hey - wait a minute, what about PCI Compliance you ask? Well, the PCI DSS says the following about password(s) and password strength:
  • 8.5.10 Require a minimum password length of at least seven characters
  • 8.5.11 Use passwords containing both numeric and alphabetic characters
While technically, AmEx conforms to the PCI Standards I would argue their "compliance" is half-hearted (letter of the law, rather than the spirit). PCI DSS says your password has to be at least 7 characters long - but what if it's no more than 8 characters long? So... wow - way to go American Express. Leading the way in security and customer protection once again.

Proof positive folks, compliance does not equal security. Just because you're "PCI Compliant" doesn't mean you even begin to comprehend security policy creation and security strategy in general. Obviously...

Yikes. Shame on AmEx.

Tuesday, May 13, 2008

Sidetracked: Windows XP SP3... d'oh!

Hi folks - as a sidetrack today I went and tested XP SP3 on one of my less important VMware images today. It was interesting to see it blow up during installation... much as I expected.

--> First thing I noticed as it was "running processes after install" - it gave me an interesting "Failed to Hook" error, like so:


--> Next, as I kept clicking OK dozens of times... I started getting these errors, which clearly point to a Media Player issue (I think?)



I don't know - but in the end the process HUNG, so I had to restart my Virtual Machine, and go back to a snapshot. I Googled around for a while, but couldn't find a hint as to what those errors are, or where they were coming from much less how to fix 'em. Oh well... I gave up. Good think I prepared for disaster ahead of time - guess I'll be waiting a few more weeks before SP3 is "ready for prime time"...

Monday, May 12, 2008

Great minds think alike?

Amazing... so since I've picked up Russ McRee on my crusade against stupidity (a la "Hacker Safe" and "Hacker Proof" seals) now we have another, slightly more prominent crusader.

Nate McFeters over at ZDNet has written an article on this stupidity...linking yours truly.

__Thanks for the nod Nate.

McAfee security for the web!

I can't take it anymore... I've been laughing so hard since my pal Russ McRee sent me this link today. I need to share this with you fine folks out there.
Apparently, McAfee is building upon the fine reputation they have as a security company and are announcing that they will be adding a feature to your search. Starting this summer, if you're using their toolbar (and who isn't...) you'll get an extra feature that will tell you whether a site is safe to go clicking on and additional whether it's "safe from hackers". Check this quote out:

"Within search results, consumers will see McAfee SiteAdvisor's green, yellow and red ratings that clearly indicate whether a site is safe, if the consumer needs to exercise caution, or if it's risky. They will also see McAfee Secure sites-those that have passed stringent tests that help to ensure they are safe from external hackers."
Great! So it sounds like they're building upon the very successful "Hacker Safe" program (which oddly enough they don't mention here...) to tell you that they've "stringently tested a web site" and that's free for (err... of rather) hackers. Seriously... are they simply re-branding the failed "HackerSafe" program?

I can't wait to sign up.

EDIT (5/12/08 @ 1:08pm CDT)
I just had to post this too... here's the link to their PR site (http://www.mcafee.com/us/enterprise/products/trustmark.html) where they now boast their PCI Certification service using... ScanAlert! Here's the quote... if you're eating/drinking swallow so it doesn't end up on the screen...

McAfee PCI Compliance Service helps ecommerce sites that accept payment cards meet Payment Card Industry Data Security Standard (PCI DDS) compliance. PCI DSS was originally established by major credit card companies as a way to help merchants protect card and payment information. With McAfee’s PCI Compliance Service, ebusinesses have wizards, interactive tools, and automated procedures that make it fast and easy to meet PCI DSS Security Standards.

With the integration of Hacker Safe and other ScanAlert products and the partnership with Yahoo!, McAfee positions itself as a leader in the Secure Internet arena.
----- Oh will the hilarity never stop?

Wednesday, May 7, 2008

Are firewalls dead in the Web 2.0/Web Service world?

I've been working in "extremely large enterprises" for at least 5 years, going on forever, and I can see where the idea that "the perimeter is a myth" can be perceived. While I understand how you may think that, the thought is still wrong.

Let's take as fact that malicious activity as a whole has evolved over the past 10 years in a manner that makes "network access control" an order of magnitude less important. Since just about everyone can agree on that, I'll take my argument from that beachhead and move on, addressing specific points.

1) The perimeter is "dead"
First, let me say that I disagree that the perimeter is a thing of the past. While the perimeter has certainly become "blurry" in some cases, this generality isn't a case where it happened by necessity, rather, by accident. I've been through enough integrations where the border between "us" and "them" has all but dissolved to know that this isn't by design. It just happens sometimes when we architect carelessly, or just let things happen. I will argue that this is a bad thing, and should be addressed by a proper review from your enterprise architecture group, involving your security folks, obviously. The perimeter, while it has become fuzzy in some places needs to be maintained for the overall health of a business. Access to resources should be limited, and controlled, and without firewalls in the enterprise this becomes more disparate and difficult. The problem most architects see with firewalls is that they are effectively the bouncer at the door to the bar, and this assumes the bar has only one entrance/exit - or that all entrances/exits (egress/ingress points) have a bouncer (or firewall in this case) at those points. The problem comes in places like highly meshed networks where access into a segment happens from many places, or "network segments" are virtual rather than physical entities. While technology and today's business tends to drive us in IT to dissolve borders in the name of productivity and usability - it doesn't mean we should be giving in to those drivers in exchange for our own common sense.

2) WAFs (although mis-named) are useless
Web Application Firewalls (although I personally feel they should be called Web Application Gateways) are wonderful when implemented properly. While they definitely do NOT substitute for good coding practice (I can talk about this point all night long) it still helps you filter out those high-probability, easy-to-execute attacks classified as "low hanging fruit". There are at least 2 WAF vendors that I have personally reviewed and can talk about at length if anyone's interested, although I don't want to promote any particular vendor here. WAFs should do the following two things: 1) understand the application flow & parameters and 2) filter out "bad" things (signature/regexp based detection). A combination of the two will certainly help eliminate a good portion of the web vulnerabilities out there. Having reviewed over 500 applications in my time, I can honestly say that the 80/20 principle applies. 20% of the vulnerabilities cause 80% of the damage. Those, I strongly feel, are the things that we can as security professionals identify and remediate via automated methods and tools. The other 80% of vulnerabilities are the ones that are logic-flaw based, requiring the attacker to really understand things like process flow, business logic in order to cause issues. Unfortunately, those vulnerabilities will never be detected by any automated tool - simply because it requires the power of the human mind and the understanding of a warm body to identify those attacks. The problem with those attacks is that they typically take extensive time to identify and exploit - thus the reason why attackers opt for scanners and automated tools like SQL injectors to find and exploit the easy holes. I go back to one of my favorite cartoons in IT... there is a bear chasing 2 hikers and one of them stops to tie his shoe. The other hiker is screaming at him that the bear will catch him, and that they must outrun the bear... the hiker tying his show smiles and says "I don't have to outrun the bear, I just have to outrun you!" This is the world of business folks - the low hanging fruit is what will be exploited. If you don't understand the ideas of acceptable risk, and "good enough" - you're in trouble. So sliding back to my point... while WAFs may not be the magic silver bullet, and conceding that there are a lot of really dumb implementations out there (CheckPoint's AI, and many others) WAFs are useful and should be used in conjunction with secure code development practices and tools. Does this mean that the "firewall" is dead, no. It means that while a firewall has its place, it's clearly not at the application layer, and doesn't serve much more purpose at the higher-level points in OSI mode.

3) Web Services somehow makes everything "different"
I swear if I hear one more person tell me that "Web Services has fundamentally changed everything" I'm going to scream. This simply isn't the case. We've had web services for years, but we've simply not called it that before. How many of us have had to deal with headless applications which act as data-processing engines via HTTP? I know I have. Web services hitting the market simply tells us that we have to look at our architectures and re-evaluate some of the things we've been doing, and apply those lessons-learned from serving pages to the "Web" to yet another slightly different method of doing so. Let me admit that fundamentally, web services are slightly different than a web server, in that there are re-usable components, an ESB, and lots of things all happening in the same "security zone". This doesn't fundamentally change the game, though, in my humble view. A firewall outside at the perimeter can still keep the usual barrage of crap from consuming your valuable resources on the Web Service. That being said, if you have a web service that's open to the world - a firewall isn't really going to help THAT web service be more protected, outside of keeping the rest of the ports on that machine (real or virtual) from being accessed from the outside or hostile world. Firewalls have their uses in every aspect of our businesses, keeping segments separate and acting as the big-mesh screen that pulls out the obvious and the unwelcome at a ip/port/protocol layer. But just like with web servers, once you've figured out that some web server is vulnerable on port 80 to an attack, the firewall will let you poke at that defect all day long without the use of a more intelligent device behind the firewall.

In summary - firewalls are far from dead and useless, the perimeter is alive and well (or at least it should be) and if you're arguing otherwise I say to you - "You've given in to the pressures that the business has put on IT to "just make it happen, worry about the security later".

This is my opinion, and I'm sticking to it.

Cheers all.

Tuesday, May 6, 2008

Fun with Microsoft Live! Mail...

I love my job... my day-job I mean. I've been traveling all over God's creating demonstrating to people that the web applications they have are hopelessly vulnerable to all sorts of exploits. Once the shock wears off, and the people who fainted have been given the smelling salts and are awake again - it's time then time to offer up strategies and methods for fixing this situation.

I was doing a demo the other day and someone asked me why in the world they would want to validate header variables such as "user-agent". I quickly went to the registry, modified my browser settings (this is IE) as so:





I then went to Windows Live! Hotmail just to demonstrate a point. Immediately, my browser had a bit of an issue, as Microsoft reported...

Oh neat....

if I change my "Platform" back to something Microsoft is aware of... everything looks fine again. Point made.

Static Code Analysis - Recipe for Failure

I've been thinking and talking to a large pool of folks over the past 2 weeks about "Static Code Analysis" or "Whitebox Analysis" of web-based applications and have come up with an analysis of why I think this is a flawed approach.

Feel free to hop over to my other blog and give it a read, and comment away. I'm always interested in your viewpoints.

Read all about it here: http://portal.spidynamics.com/blogs/rafal/

...Happy thinking.

Sunday, May 4, 2008

Airport Security: Should This Worry Me?

Hey folks - just another airport (in)security note, as I travel and criss-cross this great land of ours. I'm always on the lookout for silly security snafus that would seek to compromise the high standards DHS has set forth for maintaining airline security. Given what I know about the state of DHS and more specifically the TSA organization - I keep extra care when I go through the "security screening" process at the airports.
I was going through O'Hare's Terminal 1 this afternoon, and just happened to be wearing my Nike AirMax 180's again (these are the ones with the Apple "pod" in the mid-foot of one of the shoes). I went through security, took my shoes off, put them through the x-ray machine and watched the two very ... "conversationally engaged" girls as the shoes went through. One of them looked down for a split-second as my shoes went through, then continued her conversation about a party that she went to last night that was "off the hook".
So two things immediately hit me that were very wrong with this picture.
  1. Neither of the ladies who were supposed to be monitoring the screen looked down at it for more than maybe a half-second, as my laptop, laptop bag, shoes, cell phone and "gadgets" all went through on separate trays. That's 3 trays that went through that got barely a look. Now, maybe today's screening machines are *so* advanced that they require almost no human action... but still - is this cause for concern?
  2. The little "pod" in my shoes attracted *zero* attention. OK, maybe that's not such a big deal, but they are screening shoes now, right? I would guess that if I was sitting there, and saw an athletic shoe go through with a metal/electronic gizmo in it, tucked away in the sole of the shoe - I might just be concerned. Maybe I'm wrong - but then this all probably boils down to the system used to screen.. .I hope.

Something else caught my attention. When I asked Mr. Luis M. the question "Why do we need to put our shoes into the screening machine...?" his answer was (I swear, word for word he said...) "Because we need to check for some stuff". This is the sort of high-quality, educated and intelligent answer I would except from today's TSA agents, honestly. I'm not knocking all TSA agents because some actually have a greater than High School education, but this is just appalling! I'm not asking for a national secret, so he should be able to tell me. I'm also not asking a terribly complex technical question, am I?

Anyway - I'm about to board a flight out to San Francisco... hopefully on my flight home someone notices my shoes :)

-- Fly safe!

Friday, May 2, 2008

Unintended Consequences

This past week I spoke at the Systems and Software Technology Conference on the topic of Understanding Web Application Security in a "Web 2.0" world, and hung around to hear a few other people speak on topics that I thought were interesting.

Of note, is Paul Anderson's talk on his group's advances in the technology of binary code tracing and code obfuscation tools which his company GrammaTech sells. The first part on dis-assembly and analyis of binary code for vulnerabilities was fascinating - but I think the second portion of his talk was what peaked my attention. Essentially - his company has a suite of tools that will "transform" your code and make it nearly impossible to disassemble (he demonstrated screen shots using IDA Pro). His example was taking cat.exe, a tool we are all familiar with and taking two IDA Pro screen-shots of the binary executable. The first was just the .exe file on its own, showing all the innards and components of the binary. The second was of the same file after Paul's tools had "obfuscated" the code. IDA Pro had no idea what to do with this new binary... it found one function (the main one) and mis-labeled where it was stored (it "found" it in :data)... so this leads me to an interesting concern - so I asked the question ...


If you're now building a toolkit (or rather, perfecting it, since I'm fairly confident stuff like this exists in large quantities anyway already) and it gets into the hands of the people writing the malware (and it will) are we looking at another major set-back for signature based malware detection?

You can see this two ways, or so I think. You can look at it and say "well, this technology will change how we detect viruses and such; when it gets into the "wrong hands" it will set the good guys back pretty bad. The second way to really look at this is a two-pronged though. We're already finding code that's polymorphic and self-changing to evade detection, these tools will only further the cause and give that process enterprise-level assistance. Next - signature-based malware detection is a fairly dying and outdated method anyway...right?

So now I guess the ante has been raised in the perpetual arms race between the white-hats and black-hats. With more and more tools coming out to assist in DRM, PI security (through binary code obfuscation) are we really wasting efforts? Naturally you can guess I have my own opinion - but I'd like you to think about it for yourself.
Google+