Saturday, January 31, 2009

SweetIM: All About Fun [and parasites]

Every once in a while, I like to click on those links that messaging clients advertise for smilies, emoticons, and other useless crap, just to see what it is these client-based parasitic applications want in return for the extra content they're slipping into your instant messaging program.

SweetIM is just another one of these parasitic zero-purpose applications. SweetIM is made up of 2 separate components, an instant-messaging add-on, and a browser plug-in (toolbar) that modifies your search provider and homepage. A quick peek at their EULA ( you find the usual dribble... and it's interesting too.
"In order to receive the benefits provided by the SweetIM Software, you hereby grant permission for the SweetIM Software to (i) utilize the processor and bandwidth of your computer, only in order to provide you with the Services"

and then there's this little gem under the 4. Risks section
If you choose to use the SweetIM Software or the Services, you may be exposed to a variety of risks such as : (i) unauthorized invasion of your privacy during, or as a result of, your or another's use of the Service (ii) unauthorized exposure of information and material posted by you or others on or through the Services. (iii) potential exposure to objectionable material and/or parties, such as content and messages that may offend and which may contain contaminated files., (iv) spoofing, eavesdropping, sniffing, spamming, breaking passwords, harassment, fraud, forgery, "imposturing", electronic trespassing, tampering, hacking, nuking, system contamination including without limitation use of viruses, worms and Trojan horses causing unauthorized, damaging or harmful access and/or retrieval of information and data on your computer and other forms of activity that may even be illegal.

That's some interesting EULA components, right? How many other pieces of software have you ever downloaded or installed that came with that sort of disclaimer?

Then in a later paragraph we get a hint on how SweetIM uses your computer, and makes its money, in the Installation, Operation and Removal section.
"SweetIM for Internet Explorer can be minimized by right clicking the
toolbar and selecting it. In addition, you will receive SweetIM Search
Assistance feature which provides you with relevant search results when you
place a search query in the browser address bar (as described above under Search

So as most of the other free parasitic softwares out there, these guys get paid by giving you adds when you do legit searches, and essentially hijacking your search capabilities with their paid adviertisers, no doubt.

This next section is my favorite part.
"When a user uses one of SweetIM search feature to search the Web, the query
reaches our servers. As all standard Web pages, besides the keyword query, it
includes information such as IP address, default language setting, browser type,
and an anonymous unique ID. SweetIM uses this information in order to
appropriately process your search request and to serve you relevant and better
search results.
The SweetIM toolbar sends a configuration request when you
start your browser. This request includes only data such as IP address&
browser type. In addition, occasionally SweetIM for Messenger & SweetIM
toolbar may send a request to our servers to check for new version releases.
All of the collected information is kept strictly anonymous, is
non-personally identifiable, and is used only for purposes of delivering better
search services and content in accordance with your preferences. "

Hey, at least they look out for your privacy :)

Seriously people, stop installing these things.

Friday, January 30, 2009

Trojans for Pirates

Malware sucks.
... correction - malware sucks when the target it someone legitimate.

Hypothetically, if you were going to steal a car, whom would you steal it from? Someone legitimate that you know? Some stranger minding their own business? How about a criminal? That's the premise behind an interesting trend I've been tracking lately.

After doing some research into malware trends and the source of the really nasty stuff that's next-t0-impossible to detect I've come to the conclusion that the malware authors much prefer pirates over legitimate users. Could it be that malware (adware | spyware | crapware) have developed a conscience? I seriously doubt it. I think I have a much more reasonable explanation: it makes sense to target someone who's already doing something illegal. Right? Who's a software pirate going to complain to? Can you imagine someone downloading a copy of PhotoShop (ISO+crack) and getting a little more than they bargained for? I can just imagine that phone call to tech support...
[Technician] "So sir, what was the last thing you did before you noticed this abnormal activity on your computer?"
[User] "Well, I was downloading a cracked/pirated copy of [insert software title here] from LimeWire, then when I tried the crack my machine went crazy!"
[Technician] " ? "
Can you picture it? Is this not the ultimate target? What's also a little strange is that people who are doing illegal activity such as pirating software have a much diminished suspicion of what they're clicking on. They know that what they've just downloaded is illegal, so they figure [obviously wrongly] that the crack/serial-key generator is going to do nothing bad to their computer. Morons.

Over the past 12 months I've interviewed one of these such malware jockeys... and his take is that he can make much more money slipping adware into hacked binaries, because people who search for and download pirated software are just not as careful as everyone else. Weird. I've also downloaded [for research purposes only] a good representative sample of pirated content from music, movies and expensive software... and a huge percentage of it has had malware bundled. Some of that has been rather obvious, some of it was well-hidden.

The moral of the story is - don't download pirated software, obviously; but really... keep your guard up! Let the pirates turn on each other.

[I will be publishing more details on the research I'm conducting soon... it's taking a significant effort to map some of these P2P distribution networks... so if you're interested in helping me do some research I recommend you have a working throw-away VMWare image, some good binary analysis and machine-analysis tools, and a willingness to poke around - Let me know! I'd love some help.]

Thursday, January 29, 2009

Give Up on Network Security Already!

The title is on half-farse... obviously I don't think network security is dying, or going away - but I bet I made you think for just a half-second!

I've been at a few "security vendor events" in the past few months and have noticed a disturbing trend towards peddling the same old you need to secure your network line which has me scratching my head. I've heard the folks from a number of different vendors (who shall go un-named) talk about how enterprises and SMBs alike need to protect their users and their assets at the network layer and buy better IPSes. Again, I'm scratching my head.

One of two things is true, either those vendors haven't noticed the mass of break-ins into the web applications that are online, or they simply don't have an answer and have decided to step up their campaign to get more money securing the wire.

Interestingly enough, with the HPS breach being malware-based... I wonder how many of these same vendors will extoll the wonders of an IPS and how it would have prevented this Heartland Payment Systems breach... although we all know IDS/IPS is like AntiVirus... you can only write signatures for things you know exist... so you're chasing old ghosts at best.

There's food for thought on a Thursday afternoon.

Wednesday, January 28, 2009

Heartland Payment Systems - Getting Sued...

You had to have seen this coming. C|Net is reporting that Heartland Payment Systems is being sued by one of the victims of "the most massive data breach in US history"; after her card was one of those involved in the breach. The case is seeking class-action status.


So... what do you suppose a class-action suit like this is worth? $1Bn? $2Bn? Does it even matter since HPS likely won't survive this calamity?

[Pic] Building Security Fail

23rd Floor of the "Jeweler's Building"
35 E. Wacker Dr.
Chicago, IL

Security's Crux: Real Problems vs Point Solutions

Security has a serious problem.

There are more problems than we currently have solutions for, and the solutions that are being presented are ill-conceived, poorly though-out, and don't actually solve the whole problem thus perpetuating the problem in the long run. Recently American Express learned that if your website has cross-site scripting (XSS) issues an effort must be made to sanitize all input rather than mitigating a single attack vector someone has demonstrated to you. This sort of problem is pervasive, unfortunately and extends out into vendors as well (more on that in a minute).

For some reason, few people are interested in solving actual problems and are instead focused on either selling products or simply solving a point-in-time singularity such as American Express did. I'm not picking on AmEx specifically but their example simply underscores my point. Why is this trend ticking upward faster than previously?

In an analysis of the issue, we can can blame a failing economic climate and therefore falling budgets, or short-sighted CIOs, or worse, security "professionals" with little vision. The fact is all of those factors have been around since long before this problem became so pervasive, and therefore we have to look to alternative reasons for such a collapse in strategic judgement. Nae, I think the problem revolves around the need to stay relevant. Allow me to explain.

Haven't you worked with (or for) someone who refuses to automate a process or teach others simply because he or she feels like they will be made obsolete? You know how flat-out stupid that sounds because it is those people who in the end create an unpleasant end for themselves, instead drowning in their self-created hell. I think the security industry is headed in much the same direction...

I keep reading Giorgio's posts on the Internet Explorer 8 BETA1 release and "ClickJacking" protections offered therein (here and here), yes he's the guy who does NoScript, and it's all of the sudden become clear to me. Once again, Microsoft has solved an industry-wide problem by perpetuating their own proprietary technologies and then marketing them as ground-breaking. NoScript addresses the UI Redress attack (more commonly known as ClickJacking), but since IE is so proprietary and closed... they have to re-invent the wheel to self-serve. This perpetuates the need for Microsoft to "save the masses"... since most people that don't know better are hooked on Microsoft's IE technology like crack.

There is an excellent paragraph I think everyone should read:
"As I had anticipated, IE8’s “clickjacking protection” is just an alternate scriptless way to perform frame busting, a well known and simple technique to prevent a page from being “framed” in another page and therefore becoming an easy UI Redressing target. Microsoft had to follow its own special path because the traditional JavaScript implementation can be easily circumvented on IE, e.g. by loading the targeted page inside an {IFRAME SECURITY=restricted} element. But the other major browsers are equally “protected” (if we can call “browser protection” something relying on the good will and education of web authors) by “standard” frame busting. Therefore, slogans like “the first browser to counter this type of threat” (James Pratt, Microsoft senior product manager) were marketspeak at its best. Furthermore, this approach is useless against Clickjacking in its original “historical” meaning, i.e. those attacks involving Flash applets and other kinds of plugin embeddings which led Robert “RSnake” Hansen and Jeremiah Grossman to invent the successful buzzword."

This IE8 anti-ClickJacking feature is by far not the only incident of self-serving short-sightedness. Why is it that every time we have a very serious issue (ClickJacking, after all, is not a hack but an abuse of legal, spec-defined HTML functionality) everyone jumps to throw their "quick solution" to the problem, then we consider it solved, and we move on.... why?

It's like a bad joke... "[Patient] Doctor, my arm hurts when I bend it like this. [Doctor] Well, then don't bend it that way, problem solved!" DNS was fundamentally broken back in the 90's... but it wasn't until an earth-shattering PR move that every (or almost every) vendor issued a patch... a short-sighted solution. Is DNS still for the most part fundamentally flawed? Yea-ha. Are we going to wait until the next major hack to solve that singularity? Yea-ha.

Are the folks who make the security world go-round just afraid that if we write fundamentally more secure code, solve the root problems, and address security issues at the grass-roots level we'll all somehow become unemployed? As we keep proving, security issues will never go away, there is no end-game in security, as I've always said. Why not, rather than continuing to pile-on the proprietary crapola, join the party and solve the UI redress issue in a cross-platform/browser way? Why not, rather than patching browsers, actually address the problem inside the HTML standards?

I don't get it. Are we doomed to solving singularities and creating products to be point solutions? Or am I simply too philosophical to realize that this is a self-perpetuating issue which won't ever actually go away?

Tuesday, January 27, 2009

Addressing Web Application Logic Flaws

I just posted a blog over on "Following the White Rabbit" regarding Web Application Logic Flaws... and how addressing them is a problem, with thoughts on catching those flaws as well.

Comments welcome!


Secure Coding, Web Application Security Tools and a Hammer

Tools and automation are the natural evolution of every industry from medicine, to automobile manufacturing, to structural analysis of bridges and buildings. What I never understood is the professional services industry's negative stance against the tools that have been developed to assist with debugging code. Granted, they're not perfect or 100% accurate - but then this is still a new science.

I found something very interesting in an archived Microsoft BlueHat Security Video from Fall 2008, from Vinnie Liu called "Using the Right Tools in the Right Place at the Right Time". The video and presentation is well worth the ~40 minutes or so of your time - Vinnie's a smart guy with a wit to match... but makes several points in the talk I wanted to expand on.

My favorite point is his quote "When all you have is a hammer, everything appears to be a nail". How true.

I've said this so many times it still echoes in my head - learn to write secure code, don't just learn how to fix specific point issues identified by tools (or consultants). American Express had this issue... So what's really going on? The answer is quite simple - no one is teaching developers to write better code, they're simply being shown specific instances of a breakage and told to "fix it".

Tools are partly to blame, because when an organization bases its entire secure coding strategy around a specific tool (and nothing else) the results are disastrously clear. Tools aren't to blame though, and I would content the organization has only itself to point the finger at. Tools, as Vinnie puts it, have a specific purpose and when used properly provide a tester with more accurate, faster, and more consistent results.

As far as building a program around a specific set of tools, or consultant's advice... if you do you're asking for trouble. A solid program is always grounded in process. Period, end of story. What ends up happening otherwise is developers have mistakes pointed out to them, and instead of fixing the actual problem... they fix the instance of the problem in their code. They will then repeat the mistake over, and over, and over again. This wouldn't likely happen if there was a program and process in place, founded on education and grounded with some automation tools.

So my advice? If you're entirely clueless on web application security... don't start by buying tools. Get expert advice and build yourself a SDL-integrated process, which includes a baseline of education and cooperative feedback from the development teams. Then roll that into a full-scale program which includes tollgate reviews with architects, lead developers, and program managers to ensure that someone will be listening. Once people are more aware of the problem and understand the base causes for things like Cross-Site Scripting, SQL Injection, logic flaws, etc... bring in a good set of SDL-integrated tools to make your program efficient and consistent. Oh... and don't forget to regularly use a 3rd party to checkpoint your code and process... they're expertise will far-surpass your in-house knowledge any day of the week.

If you want free advice feel free to ping me directly. I promise I won't sell you anything, only my experience. You don't have to go at it alone... and fail.

Monday, January 26, 2009

Ex-Janitor Stole Nuclear Secrets...

[ Source:,2933,483086,00.html ]

These articles just keep on coming today. I've re-posted the story directly below for your reading pleasure but I have to make a few comments myself.

First off, how did a janitor manage to sneak out of the Oak Ridge nuclear enrichment facility with classified equipment ... honestly? If I wasn't such a cynic on security I would have a hard time believing such a story - but then again... I guess worse things have happened lately. It just stuns me a little to read that a janitor of all people... really? Maybe it's time to review those security policies and procedures?

KNOXVILLE, Tenn. — A former janitor accused of trying to sell broken nuclear weapons equipment from a shuttered Tennessee facility has pleaded guilty.

Roy Lynn Oakley pleaded guilty Monday to one count of disclosure of restricted data before a federal District Court judge in Knoxville.

Under the plea agreement, he will serve six years in prison and three years of supervised release.

Authorities said Oakley was a contract worker at the former K-25 uranium enrichment plant in Oak Ridge when he was arrested in 2007 after offering the gear to an undercover agent. Prosecutors say Oakley took home classified equipment he was supposed to be destroying and tried to sell it to the French government.

The 67-year-old Harriman man was scheduled to face trial after pleading not guilty, but his lawyers filed a motion last week to change his plea.

14 year old fools Chicago Cops...

In an article that truly makes me wonder about the effectiveness of our police force (not just here in Chicago)...

[ Source:,2933,482764,00.html ]

CHICAGO — A 14-year-old aspiring police officer donned a uniform, walked into a Chicago police station and managed to get an assignment — patroling in a squad car for five hours before he was detected, police said Sunday.

The boy did not have a gun, never issued any tickets and didn't drive the squad car, Deputy Superintendent Daniel Dugan said.

Assistant Superintendent James Jackson said the ruse was discovered only after the boy's patrol with an actual officer ended Saturday. Officers noticed his uniform lacked a star that is part of the regulation uniform.

Police said they were investigating how the deception went undetected for so long in what they described as a serious security breach.

Police didn't identify the boy because of his age. He has been charged as a juvenile with impersonating an officer.

Dugan said the boy looks older than 14 and was motivated by a desire to be an officer, not malice or "ill intent."

The boy once took part in a Chicago program for youth interested in policing, so he would have been familiar with some procedures, perhaps helping him blend in, police spokeswoman Monique Bond said.

So this kid was issued an assignment AND get hooked up on a 5hr patrol with a partner? What was his partner doing? Didn't he/she notice the officer was a little young?! What's particularly interesting is that Daniel Dugan quickly made the distinction that the boy clearly did not have any ill intent... but what about someone who does? Will it take the police force a day, hours, or ... to figure it out?

Utter madness folks, someone needs to investigate how/why this happened, and how no one noticed for 5 hours.

Thursday, January 22, 2009

Securing the 44th Presidential Family

It's no secret President Barack H. Obama is a technophile...
It's also no secret that he's recently gotten to keep his SmartPhone (dubbed the "Obama-Berry", haha)... and that General Dynamic has made it "spy-proof"... right. Anyway, the issue is much wider than the media is alluding to.

In my effort to bring you a fresh angle on everything, consider this. Mr. and Mrs. Obama have 2 daughters... Malia and Sasha are young enough that I imagine they're starting to (if they aren't already) live on MySpace, FaceBook, instant messaging, and social media. Makes sense right? Here's the problem with that - the White House is notoriously techno-phobic.... preventing the President from even having an email account, for fear it would be hacked!

So let's take that angle on the story... the big story isn't that Mr. Obama love his gadgets and gets to keep a specially-made SmartPhone (which I'm glad he fought for, honestly...) - but that his family is about to go into a very different lifestyle - much less connected than perhaps they're used to being.

This raises some questions, and of course there are more questions than answers at this point - but I'd love to hear some of the challenges that Mr. Obama and his wife face with the girls... and having to explain to them they can't just IM their friends anymore ...

National Security is one thing, but keeping our president in the dark ages with respect to technology - that's just stupid. Mr. Obama and his family must stay connected, in a safe way, but to demonstrate to the American public that he's not a relic, he's not "just another president"...

7 Things (the Security Blogger's answer to chain letters)

This should be interesting... a great big wave over to Arshan for calling me out. Now I feel loved.

The Rules:

  • 1. Link to your original tagger(s) and list these rules in your post.
  • 2. Share seven facts about yourself in the post.
  • 3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
  • 4. Let them know they’ve been tagged.
Here goes!

First --> Linking to Arshan's original post calling me out ...
Now, 7 facts about me... ok
  1. I love hockey and fast cars... in fact, I love hockey so much I play in a Men's 30+ league here in the Chicagoland area... yes I'm >30. I also drive auto-cross and get on the track as much as I can in my baby, the '05 RX-8/Shinka... she's down for the winter under the away from the salt.
  2. I'm addicted to blogging... in case anyone had any doubts
  3. I heart Jessica Alba, especially in "Sin City"...
  4. I'm a closet amateur photographer, primarily focusing on nature and stalking critters of all kinds with my Canon; I tend to be a Canon snob for no particular reason other than that's what I've been using since '94
  5. I love to hike, camp, and all manner of things outdoors; but oddly enough as my wife pointed out I can't seem to go >8hrs without a shower these days... I must be getting soft in my old age.
  6. I have entirely too many animals in the house (Pomeranian dog - "Kody", cat - "Baby", bunny - "Pancakes" (my wife named him), African Grey parrot - "Joey")
  7. I am absolutely addicted to Sunkist orange soda
Now I have to tag 7 people? Really?... hrmm.....
  1. RSnake... you're famous, and now you're tagged
  2. jabra - whom I've gotten to know is a real psycho on the keyboard (that's a good thing Josh)
  3. Matt Presson of Coding Insecurity
  4. Rob Ragan (dammit Rob, start a blog already, great first post?)
  5. Val Smith... just because I'm curious
  6. Russ McRee - ... I'm willing to bet good money Russ saw this coming...
  7. Stephan Wehner - I love being challenged intellectually... your turn.

Heartland Payment Systems - Quick Point...

A quick point here, and this is frustrating me so much I had to write about it... why is everyone focusing on the data breach rather than the possibly massive resultant fraud? I haven't read a single good article that does anything more than mention 100MM accounts stolen and can't seem to get past the vastness of the numbers in this case... but everyone I've read today (and that is a lot) completely neglects to mention the sheer economics of it!

For your consideration:
  • 100,000,000 account records
  • 3% fraud, guessing conservatively
  • $500/incident of fraud
(100,000,000 x 0.03) x $500 = $1,500,000,000 -->$1.5Bn

So, guessing conservatively* this is potentially a $1.5Bn security incident... why is no one focusing on this?

*In case you wonder where I'm getting my numbers, I'm using statistics I've picked up from the 3 years I worked in IT Security & Risk for one of the largest card private-brand issuers on the planet... and although they are >1yr old, I suspect these statistics will hold true. If someone out there has a better guess, more accurate that is, please correct me.

Wednesday, January 21, 2009 - [in]Security for students

[Just to re-iterate this again... opinions and thoughts expresed here on this blog are mine, and only mine, unless otherwise quoted or cited. This means they are not the opinion of my mother, friends, co-workers, employers, or anyone else...]

In case you missed it, I wrote an article a few days ago on my other blog (Following the White Rabbit) where I addressed the issue of the Pottsville, PA student "hacking" of the grading and online classroom system from

I then thought a little more on the topic and figured I'd take a quick peek at the overall security of the login page where students and teachers as well as administrators go to log into the system. After an initial look, I wasn't shocked by what came next.

First off, the login page is a little scarry... after that, there were Cross-Site Scripting (XSS) issues all over the place. I got worried and decided that the best thing to do was call their support, and see if I could get through to someone who spoke security. I wasn't surprised by the result.

After trying twice unsuccessfully to leave a message and have someone call me back, I decided to get aggressive and pursue someone to talk to - a Mr. Ken Stith was going to be the Security Guy according to the girl in support that gave me his name, number and extension.

Ken seemed like a nice enough fellow, but very quickly I came to understand that we weren't necessarily speaking the same language. I had to explain what Cross-Site Scripting (XSS) was, and after a few tries we were on the same page. Next came having to convince him that even though his login and password boxes weren't necessarily XSS'able (at least not that my cursory check found) the other parameters on the page were open to exploitation... and that this was a problem. I will admit it's been a while since I've had to explain to a person in charge of security why Cross-Site Scripting (XSS) is a problem... but on the bright side Ken was polite enough to point out to me that his team was diligent about fixing issues and had already fixed the "SQL scripting thing"... he meant SQL Injection (SQLi). Before the end of the conversation we were on the same page, and Ken understood that I could, using a simple javascript reference tag in one of his parameters, redress the page or even redirect potential users to a different site where I [if I was a malicious user, or a desperate student - of which I am neither] could harvest student, employee, or parent login credentials. I'm not sure why this didn't register as a big deal with Ken... but he offered to me that the issue would be fixed, in short order and that he would address it with his staff.

True to his word, that particular vulnerability vector (notice the wording there) is mitigated. Now when someone attempts to exploit that specific vector they are greeted by this:

... which is a not-so-polite way of telling the attaker that you're onto them.

I do have some other issues that I really wish ClassBoard would address, but Ken alerted me to the fact that he won't be responding to my query for additional information because giving out information may lead to someone being able to exploit them easier... I'm not sure I buy that.
  1. Why on God's green earth would you ever allow a Non-Secure Login? Ken's original phone-interview response was that some users have incompatible browsers and when this feature was turned off, people flooded their support lines with help - so the option was re-enabled.
  2. Please sanitize all your variables. As an example, the DistrictID variable should be numeric (as far as I can tell) so there should be a nice input filter [on the server side] to simply eliminate any character from the user's input stream that is not a number. This would solve/mitigate your unnecessary risks.
  3. There should absolutely be separate login interfaces for staff and parents/students... absolutely. It's common sense and industry best-practice to not allow people who can administer the system to log in on the same interface as those who use the system. I will be happy to write up why in case anyone disagrees.
Of interesting note, since I can... I looked at some of the source ("view source" option in the browser) and noticed that there are some interesting tidbits hidden in there... Mr. Michael Stith...please review your source code?

Tuesday, January 20, 2009

Psst! Wanna buy some bots? - BFBot SPAM

I opened up GMail today, and what did I find? This little piece of spam was waiting for me:
If you are interest in malware, bots and botnets then read on!

BFBOT is the best bot you can buy for price sub 1000 EUR. It has stability, performance and reliability no other bot can provide. It is enough secure that you will never have to worry about skiddies stealing your bots. The spreading rate is the best out of any bot you can buy, and can each 10.000 or more newly infected PCs per day if you combine it with browsers exploit pack. The protocol is very reliable and proved to be much better choice than standard IRC. Besides minimum bandwidth needed to run the botnet, it also greatly reduces server side resources compared to IRC protocol. Therefore BFBOT server can hold around 4-5 times more bots! That
is not all - you can configure server to give different commands to bots and command bots from certain country only. And when your botnet grows to 20.000 and more, polymorphism of the bot will take care it stays undetected!

Join the small community of happy BFBOT customers that are enjoying their big botnets gained by BFBOT and buy BFBOT today, because there are only 5 packages left!

Website for more info: http:'/'/

BFBOT developer

Whoa! I couldn't help myself so I fired up FireFox, NoScript and headed over to the link above. This thing, if it's all that and a bag of popcorn, is one bad-mother... Apparently it's even polymorphic which means it'll evade signature detection pretty well. Lovely.

Anyone want to scrape some Euro together and buy some bots for, you know, analysis?

Heartland Payment Systems - 100 Million Record Breach

In a word... Unfathomable.

The type of carnage and financial damage fraud on the scale of 100 million cards could wreak on a company in such a fragile economy simply blows my mind.
"A data breach last year at Princeton, N.J., payment processor Heartland Payment Systems may have led to the theft of more than 100 million credit and debit card accounts, the company said today." (src: Washington Post)
Incredible. While they keep stressing (obviously in a panic) that no SSNs or other cardholder information was taken, we know that the information on the magnetic stripe from the card itself has been compromised.
"The company stressed that no merchant data or cardholder Social Security numbers, unencrypted personal identification numbers (PIN), addresses or telephone numbers were jeopardized as a result of the breach." (src: Washington Post)
So the only bright light, or even dimly lit light at the end of this tunnel for Heartland Payment Systems is that card-not-present fraud is going to be unlikely (assuming the breach was contained as Heartland says it is)... but cloning cards and walking into stores that don't check IDs is not that tough...

You've got to feel for the security folks at Heartland Payment Systems today...

Monday, January 19, 2009

CWE Top 25 vs. OWASP Top 10 vs. WASC Classification

"In the theater of the mind, the tone-deaf has the perfect pitch"
Recently some of you that participate in the mailing lists around web application security may have seen a bit of an avalanche of thread activity around a topic we all hold dear to our hearts. The Top x programming mistakes, or vulnerabilities, or defects, or whatever - we love them until they're used as a "standard".
Up until recently, there were essentially 2 separate and divergent (although partially agreeable) taxonomies of "Top vulnerabilities" in code (mainly focusing on web applications) - but now there is a 3rd contender. I'll briefly break them down, give you my opinions (of course!), and give you a chance to form some original thoughts... hopefully you can all form some original thoughts?

First, off, the OWASP Top 10 project, a project from OWASP (Open Web Application Security Project) was the gold standard for the top 10 web-code-borne vulnerabilities out there. Near as I can tell the first official version was published way, way back in 2004... before the clones came.

Then there is the WASC (Web Application Security Consortium) project called the WASC Threat Classification was version 1.00 around the same time in 2004, and has a last-update date of Nov. 29th, 2005. This is all well and good, and it's even nice to have 2 slightly different views or perspectives... a differing opinion from experts is always a good thing - that's why we go get a 2nd opinion from doctors right?

Now, there is the new one. But before I go there, allow me to list the "Top x" from the two previous...

OWASP Top 10 (as of 2007 revision)
  1. Cross-Site Scripting (XSS)
  2. Injection Flaws
  3. Malicious File Execution
  4. Insecure Direct Object Reference
  5. Cross-Site Request Forgery (CSRF)
  6. Information Leakage and Improper Error Handling
  7. Broken Authentication and Session Management
  8. Insecure Cryptographic Storage
  9. Insecure Communications
  10. Failure to Restrict URL Access
WASC Top Threats (as of v.1.00 (2004) revision)
  1. Authentication
  2. Authorization
  3. Client-side Attacks
  4. Command Execution
  5. Information Disclosure
  6. Logic Attacks
No matter how you look at these... they are essentially the same vulnerabilities classified differently into groups. There isn't really anything revolutionary, except for how you group vulnerabilities logically... now let's move on, keeping in mind that these two are focused on web application security vulnerabilities (defects, dammit, defects!). I will insert one thing of my own thought here, and I know lots of people will agree that the WASC Threat Classification is a little more complete, while (as a friend put it) OWASP is a sub-set of the WASC list. But that's another discussion.

Recently we were all alerted to the MITRE CWE Top 25. It's not a list of the most common vulnerabilities, rather, it approaches the idea from the perspective of the most common mistakes programmers make. I rather think this is a novel approach... but there is a problem. The CWE Top 25 breaks down into 3 separate categories like so...
  1. Insecure Interaction Between Components
  2. Risky Resource Management
  3. Porous Defenses there you have it - these are the 3 big families of mistakes programmers make. Ideally, the OWASP Top 10, and the WASC Threat Classes would nicely map into these mistakes... but unfortunately life's just not that easy - and I think this is where the conversation gets sideways and people start to lose their temper.

{ begin opinion }
I like this new document, personally. I know, this shocks lots of you reading this... but I've thought about it and I really do like it. It's written to developers and architects so it takes out a lof of the flowery security-specific language we all have grown to love. It also has a ranking of Weakness Prevalence, Remediation Cost, Attack Frequency, Consequences, Ease of Detection and Attacker Awareness... which I think serves to help developers figure out what things to focus on (based on how dangerous these mistakes are). There is a discussion section, and a Prevention and Mitigations section too... nicely wrapped up in a bow. Where everything has gone to hell in a flower-baseket is when entities such as large corporations try to use a document like this as a measuring-stick, or a "do you detect these issues" line-item on an RFP. See where I'm going with this?

This is a developer's guide to what they're doing wrong, and will now be a 3rd standard to check against... to make sure developers aren't making these sorts of mistakes. It'll be chaos as this mentality forces the 3 classifications listed here to essentially compete which is wrong - as each has their own purpose! Why not, instead of writing a totally new document like this one, write a comprehensive document that speaks to managers, executives, developers and security professionals... is that so hard? (actually yes, yes it is).

So that's what I think. I like the CWE Top 25... and if it actually leads to better software, so be it - I'm still not holding my breath.
{end opinion}

Next I'll tackle the question of whether the CWE Top 25 should be used like this... New York Drafts Language Demanding Secure Code. I want your opinions!

Friday, January 16, 2009

2008 Worst Year Ever for Data Breaches

2008 was the worst year ever, since we started keeping record of these things in 2005. Of course, every year since 2005 has been the worst in recorded history, according to the Identity Theft Resource Center (ITRC), as reported by Forbes.
According to a report released Tuesday by the breach-tracking Identity Theft Resource Center (ITRC), there were 646 data breach incidents reported in 2008, a 47% increase over 2007's total of 446 breaches, itself a record for the most breaches tallied in a single year.
This statistic doesn't shock me for 2 reasons. First, not until recently have Oregon, Wyoming, Massachusetts, and Georgia implemented data breach disclosure regulations and laws - so we can account for the uptick in breach disclosures that way. Second, each year more and more systems are being plugged into the "Internet" and exposed over the world wide web for black-hats to attack.

Considering those two things... I'm not actually shocked at all by a 47% increase, in fact... I think that 2008 was a relatively tame year (as far as increases go). Now... here's where my mind diverges from common thought.

This record number of breach disclosures isn't actually accomplishing the goal that information security and risk management professionals were hoping for. In fact, I'm starting to think that the average CIO has gotten over the shock and awe value of finding their competition on the front page with egg on their face and has started to become apathetic. Yes, I think the shock value of a data breach has lost its luster. Early last year I could walk into a retailer and talk about how their competitor just got massively hacked, exposed, and ransacked and it would evoke an immediate panic and at least the hint of change in the air. Today... a slightly different reaction.

The reaction I'm getting lately is...
"So what, so now that it's happened to almost everybody... won't be just be one of the many faces in the crowd? How much do users/buyers really care?"
That reaction genuinely worries me. I'm still blaming the end-users for corporate America's apathy towards data breaches. We're not holding them accountable. We're not holding big (and small) corporations accountable and filing suits, investigations, and demanding action against them otherwise. We keep using their eStore-fronts to continue to buy, transact and otherwise carry on their business.

Shame on the end-users. Only you can change corporate apathy towards data breaches and information disclosures... Maybe there needs to be a Smokey the Bear -type mascott? (Remembers "Only you can prevent forest fires"... --> "Only you can change corporate data breach apathy".... not the same ring) I don't know.. anyone have an idea?

Web Application Security Survey

Hi readers... for those of you who've not seen this yet - please look at the right side-bar to vote in my non-scientific survey?

Thank you.

Blog Comment Spam - Worsening?

Google Blogger comment-spam is getting worse. I moderate my comments because I don't want you folks to have to dig through a hundred spam comments to find someone's real reply... but lately it's just getting much, much worse. I used to have to moderate away (reject) 1-2 comments/week that were clearly link-bait or blog-spam... and lately it's been more like 1-2/day! It's a relatively large change so I'd like any input on the why of this phenomena... if you have any information on that.

Thanks! Enjoy the long weekend.

Tuesday, January 13, 2009

European Gas Crisis - Russia vs. Ukraine


A quick commentary on the news of Russia's gas to Europe being blocked (reportedly) by Ukraine... I'm sure you're asking yourself what this could possibly have to do with security, and the answer is simple - geo-politics.

There was a movie a long while back (1997) called "The Saint" with Val Kilmer, who's premise was that in an attempt to de-stabilize the government in Russia a military head (general, I believe) was holding heating fuel under the Kremlin... this story in the BBC press started to have an eerie ring to it. The politics of Europe are fragile right now, and it's even worse the further east you go in towards Russia, such that a crisis of epic proportions like this could destabilize political situations... maybe that's what Russia's banking on?

Maybe I've watched too many James Bond marathons but this Russia vs. Ukraine grudge-match over heating gas is starting to stink of something much deeper and scarier. The Russians know full well that over 80% of Europe's gas for heat in a deep winter like this comes from Russian sources, and they're obviously using this to their political ends... at least for now it's a fight with Ukraine over debt and supplies but this brings a slightly different issue to focus.

If you look carefully at the map every single major gas pipeline from Russian Gazprom is running straight through the Ukraine. Who thought this was a good idea? I'm sure there are geographic and other reasons for this, but in the broader scheme of things isn't diversification (such as running a few of these lines through Poland, maybe?) a better thing than having 14+ countries in a deep-freeze heating crisis?

I'm on the lookout for political and possibly European security-related fallout from this... keep your eyes on the news, this one could get heated (no pun intended).Link

Sunday, January 11, 2009

Beyond Passwords: Lessons from the G1

When my wife came home with the new T-Mobile G1 (the Google Android-based HTC Mobile phone), I took a peek at it and thought it was pretty cool.

One thing that caught my attention immediately was the password feature to unlock the phone. Instead of typing in a PIN like I do on my Windows Mobile phone, my wife uses her finger to make a pattern on the grid. Instead of a PIN that someone can guess with enough tries (granted, my phone wipes itself after 8 tries) you can put in a patter on the grid which is nearly impossible to "guess"... that got me thinking.

With all the hacking that's happened in the past several weeks, most notably the annoying Twitter hack that filled up my news inbox... and all the associated "passwords" talk that went around - I wondered what would happen if Twitter had this same kind of security as my wife's G1. Interesting.

What I have been saying for at least 2 years now, and I'll repeat here again is this: passwords are so 5 years ago. Designers of software and systems need to move beyond passwords, no matter how complex, because they're all useless. So many attacks, password-stealing trojans and other attacks would be thwarted if the designers of these systems simply thought a little more intelligently about the security of their system.

Sad, really... a consumer-based handset has better security than most high-technology, high-volume, high-net-worth, high-security web sites.

Friday, January 9, 2009

Windows 7 BETA download = *FAIL*

OT: This post is not security-related, but amusing nonetheless

Have you ever heard someone say... "If you fail to plan, you plan to fail"? I'm sure you have. Someone should have told Microsoft's people this, because.. this is just amusing. After being absolutely crushed all day by volume, Microsoft has given up serving the "Server too Busy" error message and instead has decided to simply post this:

I'm thoroughly amused. Here's why...
The message is clear... too many people pounded the site - did no one anticipate this? This is perhaps one of the most anticipated Windows releases in recent memory... and there was no built-in support for the absolute avalanche of Windows 7 BETA -hungry downloaders? Really?
Planning *FAIL*.

Monday, January 5, 2009

State of IT Security - 2009 Prediction

If you're looking for a list of the top x things that someone is predicting will happen in IT Security, this is the wrong post for you.

From what I've read, there is a lot of predicting going on regarding the "complete disruption" of the Internet infrastructure given the vast numbers of low-level attacks and vulnerabilities that have been discovered. One article even predicted an "eBomb" as quoted below:

David Maynor, CTO with Errata Security, says '09 could be the year when the first large-scale and widespread attack occurs on the Internet's infrastructure. "I think with the [hacking] work being done on Cisco and routing gear in general we'll see the first wide-scale 'e-bomb' that will break peering between ISPs and make large portions of the Internet unreachable," Maynor says.

Most likely it will be a denial-of-service attack, he says, that will "break" sections of the Net.

There is a reason this is unlikely in the general Internet at large. An attack against the Internet infrastructure that "brings down the Internet" simply doesn't make anyone any money, in any practical way. While it may be beneficial to DDoS a competitor or wreak this type of havok for other reasons, they all eventually break down to finance. Someone, somewhere, made money on that attack. Denial of Services (DDoS) on a large scale simply isn't fruitful.

If the chronology of attacks over the past year, or further, should teach us anything it's that everything is based on someone making money in the end. Money drives hacking as much as it drives prostitution, illegal gambling, or other illegal activities so while it's natural to think that the culmination of vulnerabilities will eventually lead to an attack that will completely shut down all Internet communication and disrupt service for days or weeks... that's just not likely.

That sort of attack may be be possible, but in a slightly different form. A disruptive attack may very well be coming against things like governments or internal critical infrastructures (such as SCADA systems?) This was already demonstrated once in a 2007 attack against Estonia. I can only speculate what kinds of attacks may be cooking in the dark corners of the minds of malicious individuals which could potentially disrupt governments, critical infrastructures, or other systems to cause chaos - but chaos even has a goal.

While the disruptive attack may very well be on the horizon for some portion of the Internet infrastructure... I personally feel it's very unlikely it'll be against the whole of the Internet ... without targeting some entity in particular... and I'm willing to bet that the end-game will involve making money somehow.

Sunday, January 4, 2009

RBS WorldPay Sweep Hack Under Rug

RBS [Royal Bank of Scotland] WorldPay ( has royally let its users down.

On December 23rd, 2008 they reported that their computer systems had been "improperly accessed by an unauthorized party" - this translates to being hacked. How much do you folks want to bet it was a nice, simple SQLi vulnerability?

Anyway, there is a big press-release here [PDF], but more importantly, let's look at the facts and figures here:
  • Incident happened Novermber 10th, reported December 23rd by my math that's 43 days from incident to disclosure
  • 100 incidents of confirmed fraud - so far
  • 1.5MM cardholders may have had certain personal information compromised
  • 1.1MM (of the above total) may have had their social security numbers accessed
A great quote from Ben Barone, president and CEO of RBS WorldPay, demonstrating the company's utter lack of understanding for the gravity of the situation
"Privacy is important to RBS WorldPay and we regret any inconvenience this may cause affected individuals"
Brilliant. He's sorry this may "inconvenience" some of his customers... and by inconvenience he means this may lead to a complete compromise of your personal financial identity, causing you potentially hundreds of thousands of dollars in damages, litigation, court fees and other costs, not to mention the intense amount of time it takes to clear your good name. As far as privacy being imporant to RBS... what about security? Should that quote read "Security and customer's privacy....blah blah blah"??

See... I still think that big financial corporations just haven't gotten it. Until customers of RBS WorldPay file a massive class-action suit against them for failure to take "necessary and proper" precautions and security measures to secure their information, they and other companies will continue to pull sweep incidents like this under the rug, hoping people don't realize the incredible mess they may have put you in with their ineptitude and carelessness.

Perhaps this turned into a rant... but these sorts of disclosures make me angry. By the way, as of right now (1:33am CST, January 4th, 2009) the company's landing page has no trace of the disclosure, or additional information their press release implies. Need more proof they're trying to bury it?

EDIT: If anyone's curious about RBS WorldPay's security standards... read here. No wonder they were hacked, can anyone find anything but rudimentary SSL as their big "security" feature?


1/5/09 @ 9:20AM CST
Thanks to the anonymous responder for correcting me. RBS does have a reference link to this matter off their page (I was simply looking in the wrong place/site), the correct link is:

In a strange twist of "Be careful what you wish for" it appears now that a firm by the name of Sheller, P.C. has been investigating a possible class-action suit against RBS. I say this is interesting because I mentioned above that someone should litigate this else it disappear into the archives of yesterday without recourse. Source link here:

Friday, January 2, 2009

Broken MD5, cracked SSL, and the end of all trust

Here's a shocker for you - a major security vulnerability in the grass-roots of the Internet is disclosed, and more importantly proven possible, and security professionals, vendors, and journalists are missing the forest for the trees.

I'm not going to say that I'm the only one who is seeing the "bigger picture" because that would be arrogant and stupid, but after a decently lengthy chat with my colleague Eugene today over this topic, and reading up about it on the various news wires and the disclosure page itself... it's obvious the point is being missed, big time.

The original disclosure post has an interesting quote that most analyses have glossed over -
Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites.

Taken from a post on InternetNews [linked here]:

Mozilla's Johnathan Nightingale, a security and usability specialist at the group, said that the attack could pose a threat to some users but that Mozilla is not aware of any instances of it occurring.

"We advise users to exercise caution when interacting with sites that require sensitive information, particularly when using public internet connections," he wrote in a post on Mozilla's security blog.
While Johnathan defends Mozilla's [good] name I think he demonstrates 2 fundamental issues with the way this particular item is being handled in the press and in the blogs:
  1. Mozilla is not aware of any instances of this occurring - of course not, that's the point! While this attack was theoretical since 2007, and now real but with the assistance of a massive computing effort; it may very well have been exploited by organized crime or hostile governments for a long time due to their access to funds and such computational abilities. Saying "we've never heard it being actually exploited" is like saying "sure, the car could burst into flames, but no one's ever reported that"... that's because those people are likely already dead!... get the parallel there?
  2. Mozilla advises users to exercise caution when interacting with sites that require sensitive information - great advice except that I would be willing to bet that even though the proverbial cat's out of the bag 99.999% of people won't ever look that closely at every SSL cert presented to their browser. In fact, I would be willing to be most security people won't look that closely either... That's the actually scary thing about this type of attack - it's an actual silent killer.
Not to pick on Mozilla or Johnathan in particular, Microsoft's quote is equally worrisome:
Likewise, Microsoft issued Security Advisory 961509, in which it said the vulnerability does not significantly increase the risk to customers, since its discoverers had not published the cryptographic background to the flaw, which hackers would need to mount an attack.
The vulnerability absolutely increases the risk to customers... how could you argue that it doesn't? People around our security community have traditionally argued against sounding the alarm for computationally expensive and "theoretical" attacks like this due to the fact that the average hacker doesn't have the means to execute such an attack. Here's the caveat that no one likes to talk about - organized crime and hostile governments have this type of cash and computational ability to spare... and they're the enemy. So how does anyone really know this attack hasn't been perpetrated yet?

Here's why I think these types of analyses are falsely-calming to the user populous...
  1. They create a false sense of security... people are lulled into believing that "it's not that big of a deal" and can't actually be done and they go back to being careless
  2. I can't think of a single way that any of today's existing automated anti-phishing checkers would not be fooled by this well-executed attack...
  3. This attack is the final piece of the puzzle to completely blow away our trust in the existing internet underpinnings (hint: XSS + DNS flaw + SSL hack = complete disaster)
So now I'll get to the final point here, and that is this: we're very, very screwed.

As you know, the Dan Kaminsky DNS flaw was ugly and shook the very foundations of our belief and trust in the Internet. Couple that with a Cross-Site Scripting (XSS) attack or an open-redirect, and add the SSL hack as the cherry on top and you have an attack situation where you can completely fool the user and any automated systems in place today. This announcement should herald the doom and gloom we've all been trying to counter for years - the Internet is fundamentally broken.

As I've said before, and will likely repeat again - the underpinnings of the Internet are fundamentally broken...
  • SSL is at best a time-mitigant against attack (only meant to protect you as long as the cipher being used withstands current processing power brute-force) - and this is now proving to be breakable
  • There is no "step-up" function from with the browser SSL framework that I can locate. Most browsers can "step down" to support a lower encryption algorightm, but servers and browsers alike have no method to "step up" encryption strenghts
  • DNS is an old, out-dated protocol which every communication on the Intenet hinges on... including SSL! With something so basic being so broken... how can you trust your browser?
  • Improper handling of client-side input (leading to XSS, SQLi, etc) is amplifying the attack strength of these issues with SSL and DNS...
So there you have it... think bigger than Phishing though... think, and every other dns-based, SSL-based system auto-update.

Worried yet?
Others also said the threat won't impact many online users.
I would like to meet these "others"... and ask them what they are thinking, exactly.

Related Articles: