Sunday, July 27, 2008

Reflections on the DNS Vulnerability

Is anyone else really, really sick of hearing about this "new" DNS vulnerability? I am.

I've been reading about it, the exploits, the infighting between some of our own, the disclosure, the massive coordinated effort to create patches, and DJBDNS's "ha ha". I'm over it.

The first really refreshing blog post/article on this topic that I've seen in weeks came when I hit Errate Security's page and read Robert Graham's article, "The DNS is Falling". Robert seemed to hit all the important points, and quite honestly it's about time. The "big picture", "missing the forest for the trees"... whatever cliche you want to use - we [the security industry] have done it.

Here's my point. As I commented on Robert's blog, the part that should worry everyone who's followed this issue isn't that there is a major new security defect in the way that DNS could be manipulated by evil hax0rs... it's that we have known about this type of attack against DNS for many, many, many years yet have chosen to sit on our hands. It's absolutely mind-boggling to me that with all the talented and brilliant minds that I've met or read about out there in IT Security we have, in 2008, a rediculously gaping design flaw in the underpinnings [nay, the foundation] of the Internet. ... we're so focused on sexy new technologies that we've completely swept this bugger under the rug and hoped no one would ever notice.

That, my friends, demonstrates to me that we have a much bigger problem in our industry.

Tuesday, July 22, 2008

Linus Torvalds on Security

Linus Torvalds doesn't get it... or does he?

What?... Linus Torvalds (yes, the guy that "invented Linux") has this post off the gmane.linux.kernel newsgroup, which appears to be a rant against security people and the bugs which keep us employed and the world a darker place. Read that article again, and then take it into context - he's writing about kernel issues here.

Fortify (although I don't always agree with their tools and methods) is out there saying that caution should be undertaken before deploying Open-Source tools in the enterprise, and this guy is out there saying that security is no more important than a random crash. I admit, the first time I read that I was furious, and really wanted to tear him a new one for being so idiotic... but then I thought about it more.

Since Linus is speaking in the context of kernel development it has to be assumed he's talking about catastrophic crashes that can take down a *business* potentially when random evil things happen in an enterprise installation of Linux. I understand that a non-security bug can cause very serious damage to a business too... but come on, are you seriously comparing it to a major flaw in the code which can pwn a server, a database, or an entire enterprise?

Obviously. Let me further expand.

Linus - I honestly don't know what to think after this statement... as I don't think the security profession "encourages the wrong behavior"...
" reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior."
While I don't agree that security people aren't "heroes" ... I can see how ordinary bug-hunters that aren't security bugs are just as important and should receive just as much notariety, so the following quote annoys me a little.
"It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important."
Yes, every bug is important - but the ones that are security bugs can cause (and here's the key) stealthy financial losses to the tune of billions. If a server crashes, odds are you or your business will notice immediately, if it's important enough. If a server is hacked and funds or transactions are being ciphened off... you'll likely never know because of the nature of a security bug. Before you even reach for the comment button - yes - I do accept that there are things like rounding bugs or errors in code that would otherwise silently pilfer money in an indirect way such as performance bugs or calculation bugs... but that's much less likely (by my calculations and experience, anyway). Let's move on.
"In fact, all the boring normal bugs are _way_ more important, just because here's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking."
OK - now he's just talking out his behind. I couldn't possibly disagree more, and not just because I've dedicated my career to security.

What strikes true here with me, and it's something that I've been saying for a long time, is the following quote. Read and re-read it... see if it catches you the same way it caught me.
"Security people are often the black-and-white kind of people that I can't stand."
Fascinating. I actually agree with Linus here, partially. I say partially because there is a large wave of us that are working our tails off helping to strike a balance between the "security" and "business" aspects of what we do. We're working very hard to eliminate this notion that we see in black and white - but maybe we're not doing enough or the message isn't getting out there fast enough. This is perhaps the one thing in this post from Linus that makes me think that we as security practitioners have a long way to go before we're fully accepted into the IT/business world without yelling about the sky falling.

As a final note, Linus drops this nugget of his wisdom which I have been thinking about, but unfortunately still can't find a way to agree with.
"To me, security is important. But it's no less important than everything *else* that is also important!"
I suspect it's because of the slant I have being from this industry, or maybe something else in me... but security is and should be at the top of the list. Now... granted that without "functionality" being good all the security in the world is stupid.

As I've always said... "If it don't work, what's there to secure?"

Monday, July 21, 2008

c99MadShell tool on the loose

Quick! Pop "c99madshell" into Google.
You'll get a TON of results, odds are the first one you'll hit is this one:, so I'll give you a quick hint as to what you're looking at.
As people awake to find their web-servers hacked up, this little gem is repeatedly there and found to be running in place of the expected web pages... interesting! So you may ask - what exactly is c99madshell?

Apparently this gem is being used to hack into WordPress blogs and inject pages upon pages of SPAM which then becomes indexed or simply pointed to for mass-mail spam. Interesting!

Reading along, I found a post that a person wrote up which describes the attack in some detail, here. A great write-up - but still doesn't quite explain the vulnerability which lead to the injection of the trojan code. Digging a little deeper I found a post on Derek Fountain's blog which very nicely details the attack with some of the code behind c99MadShell analyzed. To quote Derek... "You have to remember as you read this that PHP is a full featured scripting language which provides access to files, sockets, databases and all other system level resources." Right on. So making use of this little gem requires 2 things: first, you have to be able to upload a file to where you can call it with a browser, second - your target has to have PHP installed and working. After that, you're relying on lax directory permissions, and common poor configuration to make things fun.

Derek's write-up gives a resounding "configure your servers correctly" echo... much like we've all heard forever now - but with a slight twist. Let's outline some things that can protect you from attack scripts like this taking over your box and making nasties run all over your system:
  1. Don't allow arbitrary file uploads (hello, McFly?)
  2. Run your web-server process as "nobody" or some other un-priviliged user
  3. Run PHP in SAFE MODE if using PHP version <6.0.0!
  4. Ensure proper file, directory permissions rwx?
There you have it, c99madshell is being used all over the place, and it's really not all that sophisticated of an attack (the script is pure genius though...). Simply upload file, point a browser to it, and pwn a box.

Turkish Hackers Gone Wild

What's up with Turkey lately? There have been reports of Turkish hackers/crackers all over the news the last several days/weeks and I, for one, am wondering what's up? This is a group we normally don't hear much from.

The last time I recall Turkish hackers rampaged the Internet was back in ... 2006, with a link to George Ou's column in ZDNet, here. Since then, as I can recall, they've been relatively quiet.

They've hacked the EU Commission's website, DNS hijacked the PhotoBucket site, and even given some pwn@g3 to ICANN recently. These hackers even went after a teacher's union website in Seattle, US... which is weird. They've even hacked Kaspersky's site in Malaysia - but not to destroy it or inject code... but to put up a [semi] nationalist message. ICANN is an interesting target, not because it's high-visibility but because these folks are the keepers of the Internet, literally. They are supposed to control the address-to-name (DNS) system which runs the Internet, and if they're getting hacked and broken... who knows what else is possible?

We've been preaching that hackers are malicious, evil people who are only out to make personal gains, steal, and create organized crime ... but you have to start to wonder whether the days of just getting down and hacking something "for [insert cause here]" are coming back? Are these self-proclaimed nationalists going after companies, countries and entities that slight Turkey? Could this be something of a cyber-retalliation?

The Croatian Press reported that during the Euro2008 playoffs, on June 21st 9pm local time, once the game between Croatia and Turkey kicked off the Croatian Ministry page was attacked, hacked, and quickly replaced with a Turkish flag and props to their friends.

I found an interesting article here, although obviously not natively in English, I think it's worth a read as it has some vital information in it. In what I can only comment as "a clear act of [digital] espionage" these same hackers went after a "secret report"...

"...on June 13 AyYildiz Team entered to the closed section of EU foreign policy and security commissioner Xavier Solana’s web-site, which contains secret documents, and loaded own program codes there. However the hackers couldn’t get secret information and had to stop virtual attack because experts of the European Commission continually update the Solana’s page."
So... there are at least two teams that I can name from all these news stories, of the hackers from Turkey. There is the "AyYildiz Team" and the "NeTdevilz" which appear to be playing the nationlism card when hacking opposing nations' sites, companies and other entities online. I'm digging into what the issues behind their hacks are... what makes them tick, their aspirations and motivations. Stay tuned.

"Spring" into framework vulnerabilities

Hey folks - I've been thinking about security defects frameworks such as Spring for a bit since someone asked me if because they use one of these major frameworks, are they safe a week or so ago. I couldn't find any valid reason to panic about using a framework to introduce new security vulnerabilities until I saw this post - which seems to have slipped under the radar of most of us bloggers/readers of security events.

Back on the 16th of July ZDNet writer Paula Rooney published this post, which aggregates some of the details around the Spring MVC framework issues. Reading the write-up I feel like there are some complex issues at work here, and patching isn't just simply done to remediate these.

What I do find interesting is that Ryan Berg from Ounce Labs doesn't see these issues as "vulnerabilities", but rather features that are "insecure by design". To quote the article further...
"SpringSource plans to release in the near future an update in one of its MVC demo templates to show app developers how to avoid this vulnerability. Ounce maintains that the vulnerability is not a security flaw in the framework itself but an application development issue. Many Java applications and business processes built on Spring are insecure by default and should be fixed – even if it means breaking existing applications, Berg said."
How interesting. I wonder if this is limited to Java? What about the Microsoft .Net frameworks... and what about all the extensive AJAX frameworks? I wonder if we're building-in security defects simply by using some of these new frameworks?

More to come, as I try and learn a little more about how frameworks can introduce vulnerabilities into code and development.

Saturday, July 19, 2008

Cross-Site Scripting - the Gateway Drug

Remember when you were younger (or for some of you that's now...) and your parents told you that pot was a "gateway drug"? The whole message was that once you got into smoking the reefer, you would be much more exposed to other dangerous drugs and therefore would fall victim more easily.

Let's put that into the web app security context. I know, I know... it's not exactly the same thing but hear me out. If you're open to XSS, or script injection of some kind... it's only a matter of time before someone moves on to bigger and better attacks on your site. CSRF, SQLi to name the things you'll be getting hit with next, and it's all about where you start. Sure, Cross-Site Scripting is relatively simple to detect, and requires you to trick a user into doing something... to exploit themselves - but if you're open to script attacks it means you're not validating and sanitizing input or output... this leads to possible CSRF if you're a transactional application - or worse... SQL injection! If Cross-Site Scripting is pot's equal... SQL injection has to be like... crystal meth or something. Dangerous to the point where it'll kill you and potentially blow up the whole place.

... and my parents said I never paid attention to them. Ha!

Tuesday, July 15, 2008

419 Scams New Angle- US Soldiers in Iraq

We've hit an all-time new low folks. Those 419 scammers are now using US Soldiers in Iraq as the "source" for their scamming activities. They are preying upon the actions in Iraq to make their scams sound legitimate and of course, hoping that human greed takes over and you'll fall for these scams.

Here's the latest one I've gotten, haven't seen this reported yet so I figured I'd do it...

"CAN I TRUST YOU? (Assistance Needed From Iraq)
I hope my email meets you well. I am in need of your assistance. My name is SGT JOEY JONES.I am a military attache with the Engineering unit here in Ba'qubah Iraq for the united states, we have about $20 Million American dollars here which is in our possesion and we are ready to move out of the country.
My partners and I need a good partner someone we can trust to actualize this venture.The money is from oil proceeds and legal.But we are moving it through diplomatic means to your house directly or a safe and secured location of your choice using diplomatic courier services.
But can we trust you? Once the funds get to you, you take your 30% out and keep our own 70%. Your own part of this deal is to find a safe place where the funds can be sent to. Our own part is sending it to you.
If you are interested I will furnish you with more details.
Awaiting your urgent response.
Your Buddy.
Header Info:
X-Message-Delivery: Vj0zLjQuMDt1cz0wO2w9MDthPTA=
X-Message-Status: n:0
X-Message-Info: R00BdL5giqozMkaXg1EgzSz4aOURDSSSsdVXN2U2M+EHFR5kwi1AO7U766046vZapUswEWCFJBqPUuCVXV50Q//LLjGjCxHj
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.2444);
Tue, 15 Jul 2008 08:06:24 -0700
Received: from sccqwbc02 ([])
by (sccmmhc91) with SMTP
id <20080715150552m91003hckpe>; Tue, 15 Jul 2008 15:06:23 +0000
Received: from [] by sccqwbc02;
Tue, 15 Jul 2008 15:05:51 +0000
Subject: CAN I TRUST YOU?(Assistance Needed From Iraq)
Date: Tue, 15 Jul 2008 15:05:51 +0000
Message-Id: <>
X-Mailer: AT&T Message Center Version 1 (Oct 30 2007)
X-Authenticated-Sender: bWFpbDA5MEBtY2hzaS5jb20=
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_479_1216134351_0"
X-OriginalArrivalTime: 15 Jul 2008 15:06:24.0382 (UTC) FILETIME=[590BE1E0:01C8E68C]

Content-Type: text/plain
Content-Transfer-Encoding: 8bit

For the love of God and Country... let's fight these bastards!

Sunday, July 13, 2008

The battle over unlocking cell phones - carrier vs. carrier

Apparently this is a big phenomenon. I wasn't aware of this going on until I caught this story on, and it held my attention. Unlocking mobile phones from one carrier to be used on any network is technically not illegal - or not illegal in any documents that I've been able to find - but TracFone is winning law suits against people who buy hundreds or maybe even thousands of its phones, unlock them, then send them overseas to be used elsewhere.

The problem TracFone has is that it sells the phones cheap... below cost often times, only to turn a profit when people buy minutes at rediculously expensive premiums. This is how cell phone companies get you - we all know that already, so when someone unlocks a TracFone phone and doesn't buy minutes from them it's "taking money out of TracFone's pocket" their attorneys argue.

What I found interesting is that there could be a huge clash coming in the courts - as MetroPCS (another cell phone company similar to TracFone) is offering to unlock competitor's phones as long as they're the same technology (CDMA) and give them a month's worth of calling for $30. From a July 8th article in
Under the offer's terms, MetroPCS will tinker with phones originally sold by Verizon Wireless, Sprint Nextel (S), Alltel, or any other carrier whose network is based on CDMA [code division multiple access], the technology MetroPCS uses. MetroPCS will unlock the phone and provide a month's worth of calling -- all for $30.
Whoa. So here's TracFone suing companies that unlock their phones and send them overseas to be used, when MetroPCS is doing it as part of a legal commercial promotion! I can't wait for these two forces to collide. I can see it now, TracFone filing suit against San Antonio-based Houdinisoft and MetroPCS. MetroPCS filing suit back... this could make it all the way up to the Supreme Court!

This should be fun. I feel like in the end, the customer should be the winner, but we'll still end up getting screwed (early termination fees, anyone?). Either way, I want ring-side seats for this one and a big tub of popcorn so I can watch the fur fly.

Schools Beware: You're in the bullseye

Have you noticed the rising number of data breaches involving schools lately?
Have you noticed the number of schools who have had break-ins, data stolen on students?
Have you taken a moment to think about why?

I'm sure I won't be the first person to say that personal records (enough to steal an identity) of students and adolescents are desirable because they will likely not be used for quite some time - and therefore don't have credit monitoring or protection against them. Interesting concept huh? Stealing an identity which hasn't even opened a credit card before... no credit history to go against for triggering anomaly detection systems (in credit files) and the record is likely rarely monitored by the person (or his or her family). This is the perfect mix of ingredients for identity thieves to salivate.

I may be stating the obvious here - but schools really, really need to be on their guard because the identities of students is in the cross-hairs of criminals and would-be identity thieves as you read this.

Here are some recent data breaches in education:

Saturday, July 12, 2008

It's All About the Lifecycle

Happy Saturday everybody. We're closing up on Black Hat, and I wanted to share something I found that should interest you if you live in the world of web application security.

Dennis Hurst - a colleague of mine over at SPI Dynamics (now HP) - has started a conference which follows BlackHat called "LifeCycle Security". Application Security is a problem that everyone faces today - and I think we need to start thinking about it more than just tactical solutions. We're all so focused on PCI and compliance in general, and all the silly tactical things that go around with it that we're often missing the forest for the trees.

I'd like to take a moment to applaud Dennis's efforts in creating awareness around the Web App SDLC, and the fact that we really need to think "bigger picture". I encourage you (if you're still allowed to travel due to the economic "toughness" out there) to extend your stay long enough to come out and check the conference out. I think it'll be well-worth your time, and you can bring back some take-aways which managers like to have their employees come back with. This conference Dennis is hosting will definitely be less about hacking web apps, and more about how to think long-term when securing them.

More details, and registration here:

Thursday, July 10, 2008

Supreme Court Justice's Identity on P2P

Identity theft is prevalent, no one will argue that.
There are many different ways to get your identity stolen.
Whether it's from a SQLi (SQL Injection) hack of a web application, phishing scam, or some other digital or non-digital method identities are stolen every day, all day 24 x 7 x 365.

What you wouldn't expect is to fire up LimeWire (for searching through non-copyrighted material, of course) and finding the personal information (including birthdate and SSN) for a US Supreme Court Justice. Justice Breyer had his information shared via LimeWire to anyone on the Internet who wished to download it for a very, very long time (~6-7 months, according to an article up on Fox News). Making this situation worse there were approximately 2,000 high-profile clients of Wagner Resource Group, a McLean, VA investment firm exposed via LimeWire.

I'm not sure what's more shocking: the fact that this information was available on the Internet, or that an investment firm didn't have controls to prevent some moron from using LimeWire on their desktop.

Maybe I'm just old-school or whatever... but if you're an investment firm catering to the country's elite... you should have some basic security controls in place. One of those controls should have been to disallow people from installing P2P software on work computers... hello? McFly?

In this analyst's humble opinion, there are some very basic, non-spend-type, of things that could have been done to make this incicent a non-starter:
  1. Put out a basic HR policy that states that you can be terminated for installing P2P software on company hardware. There is never a good reason to install file-sharing software on work computers.
  2. Lock down business-owner hardware to prevent users from installing software without perimission (this omits licensing violations, software/DRM infringement, and legal problems of all kinds)
  3. Put up a basic network filter that blocks P2P traffic (LimeWire is pretty easy to block at the gateway)
There you have it - simple measures that would have avoided a potentially catstrophic self-inflicted wound.

Shame on you Wagner Resource Group - my hope is that you get sued, and lose the majority of your clients and learn the hard knocks lesson of data security.

Sony - say it ain't so

IDG Norway is reporting that Sony's US Playstation site has been hacked.

This isn't news, right? Everyone's been getting hacked lately. The big news comes with the how, or the hacking. The site was yet another victim of the SQLi automated tool that blackhats have been using to inject malicious code into .Net -based web sites, and display a fake "anti-virus scan" window that then tells the user that their machine is "virus-ridden" and (get this) offers them a [fake] virus program for a fee. Not only will the payload .exe file infect your machine with malware, you're going to pay for it! That's truly mean-spirited. You, the end user, is paying for the privilige of having your machine pwn3d. That hurts.

This is my favorite quote from the entire article... boils it down quite simply folks. Developers - heed the warning... VALIDATE YOUR INPUTS!

"They're not doing input validation," he [Brian Bourne, president of Toronto-based security analyst firm CMS Consulting Inc.] explains. "They're not looking at it and saying 'hey, this is not regular user input' -- that's the simple version."
The whole story on IDG's Norway site is here.

Wednesday, July 9, 2008

Finally after all these years of talk - Domain Keys

Dancho Danchev over at ZDNet posted up a story today which I thought warranted more attention and discussion from a slightly different angle.

First though, if you don't know what Domain Keys is, as it applies to email, here's the definition:
An e-mail authentication method that computes a digital signature which is added to the message header. The receiving mail server obtains the sender's public key from the DNS system to validate the signature. In 2004, Yahoo! began to sign all outgoing mail with DomainKeys headers.

Yahoo! and Cisco = DomainKeys Identified Mail
Yahoo!'s DomainKeys was combined with Cisco's Identified Internet Mail system, which maintains signature consistency, to become DomainKeys Identified Mail (DKIM). DKIM is backward compatible with the DomainKeys system. See e-mail authentication and digital signature.
Now... in the face of this large-scale implementation from Google, eBay and PayPal (the most phished brands on the Internet) it would almost seem obvious that this system should have been put in place years ago - at it is clearly proving to be worth the effort. False-positive rates are zero (is it even possible to fake a digital signature?), email SPAM/Phishing traffic is cut by a large chunk - so we ask ourselves... why isn't everyone doing it?

Much like DNSSEC (DNS Secured) it's simply a matter of implementation on a large scale, and the added overhead from the security verification operations. But I would say this to those who are thinking about implementation... there are two sides to this operation. The side that signs it (the verified sender) and the side that reads it and throws away/rejects the non-signed emails (receiver/email host). Obviously, in order to make this all happen large-scale email hosting providers (such as ComCast, Verizon, SBC/AT&T, and the like) would have to turn on filtering for messages that are non-signed. Interesting.

Here's how this works in real-life...
  1. Company A decides it's sick of its users being phished, and implements DomainKeys/DK
  2. Company A then has to contact all email hosting providers that their users primarily use (that it's practical to reach) and alerts them to only accept signed (authenticated) emails
  3. Email hosts start to filter and throw away phishing/spam email
The magic step of course is #2... you can't just implement Domain Keys and expect phishing for your domain to "go away"... so this is a solution for the large mail providers - and not the masses. I agree it's definitely a step in the right direction, and it would be wonderful if we could just make DomainKeys a mail standard (no Domain Keys, no email transport/relay) but that's just not practical.

So while we try and solve the SPAM/phishing debacle, DomainKeys (and GMail and Yahoo! Mail) take us one step closer...


Monday, July 7, 2008

A Rose By Any Other Name - DNS Hijacking

My buddy Russ McRee over at Holistic Infosec, had sent me this [ICANN Preliminary Report on DNS Response Modification, 17 pgs.] and I thought about it for a while, read the [overly lengthy] paper and have some thoughts.

First off, it's ridiculous that we, in 2008, still have a DNS system that's so susceptible to breakage either by grayhat marketing types, or blackhats. I've seen papers, proposals, organizations and consortiums, hacking info, and other crap being kicked around for more secure DNS systems , or a revamp of the existing infrastructure for the last 10 years or so - and to date nothing has happened. With all the talk you figure someone would have done something about it by now! What continues to astonish me is that we're adding more lipstick to an already ugly pig (DNS is an ancient protocol, before security was a real issue) but nothing has been said that Google has been able to show me that indicates that anyone out there is serious about restructuring the underpinnings of the ailing DNS infrastructure.

Second, do we really need such a LENGTHY paper to describe what essentially amounts to DNS hijack? I understand there are different terms for it, and you can write for volumes about the different scenarios in which a hijack can happen - but who out there doens't understand the logistics behind it yet?

I can't help but to think that ICANN should be doing something about this, spearheading an effort to remediate this obvious security, stability, and legality issue.

To quote an old UnderDog episode - "Is there no one out there who can save us?"

btw... thanks Russ, for getting me going on a Monday morning.

Saturday, July 5, 2008


You know... I learned some things this 4th of July...

When someone yells "Hey, help me carry this this over there and light it off!"... odds are it isn't going to be a small bang.

Then when that same person remarks "Holy sh**, that wick is 4 feet long! I wonder why?!" - you can certainly put some money down on a big boom, and cops showing up.

But when that very same person yells (in a panicked voice) "RUN! I accidentally lit it!!!"... it's not going to end well.

After the mortars had stopped firing in all directions because the box wasn't properly secured and fell over, and people stopped screaming and dogs stopped barking - there was but one lesson to be learned: "You should always read the box, and it if it says 'DANGER: NON-CONSUMER-GRADE FIREWORKS' ... odds are you shouldn't set it off 50' from a large crowd at your 4th of July cookout. [Dang I wish I had a camera...]