Thursday, April 30, 2009

ChicagoCon: "Hacking the Web 2.0"

Hey everyone - if you're in the midwest and have some spare time the week of May 8th and 9th (Fri/Sat) why aren't you coming to ChicagoCon?Link

The conference will feature people like my good pal Mike Murray, and even I'll be there giving a Saturday morning workshop entitled "Hacking the Web 2.0", a hands-on way to learn some of the basics of "auditing and testing" Web 2.0 appliations with a focus on AJAX and Flash-based technologies.

Come on down. Bring your friends, co-workers, or your boss.
I promise you'll learn something and have a darn good time.

Also... I've got a super-secret surprise if you haven't registered yet... post a comment that you're going but not registered yet and a way to contact you. Early birds get the worms.

Tuesday, April 28, 2009

PDF and JavaScript - Strange Bedfellows

When the latest word on Adobe's problems with Acrobat came down[1,2], recommending people to "turn off JavaScript in Adobe Acrobat" I admit I was curious, like everyone else, why JavaScript was even in PDF files in the first place.  Over the last several months going back to last year, we've started reading about Adobe's ill-fated attempt to insert JavaScript into Acrobat tools - and it begs the question - WHY?

As you can probably tell, Adobe does a pretty good idea of convincing people allowing JavaScript to run inside Acrobat is a good idea... selling its functionality to feature-hungry PDF developers...
"...you can customize the behavior of a particular PDF document, implement security policies, interact with databases and web services, and dynamically alter the appearance of a PDF document by using JavaScript. You can tie JavaScript code to a specific PDF document, a particular page within a PDF document, or a form field or button in a PDF file. When an end user interacts with Acrobat or a PDF file displayed in Acrobat that contains JavaScript, Acrobat monitors the interaction and executes the appropriate JavaScript code."
Investigating the matter a little further, and realizing that there are many issues inside Adobe's Acrobat product line with or without JavaScript being involved, here are some examples of seemingly insane JavaScript extensions to the PDF functionality:
  1. Global object | This object is "used to store data that is persistent across invocations of Acrobat or shared by multiple documents"; it's easy to see where this could go wrong very quickly.  The global object is subscription-based; meaning, a document must subscribe to the functionality, but we've seen many instances where a global object in other languages simply becomes abused through some exploit in the security mechanism...
  2. SOAP object | This object "provides support for rich text responses and queries, HTTP authentication and WS-Security, SOAP headers, error handling, sending or converting file attachments, exchanging compressed binary data, document literal encoding, object serialization, XML streams, and applying DNS service discovery to find collaborative repositories on an intranet"... while the intentions are good, one can certainly find interesting things to do here, especially utilizing the "exchanging compressed binary data" feature
  3. Priviliged context | According to Adobe's reference, once you explicitly state your trust for a document's signing certificate, that PDF file can then do "priviliged things" which otherwise would be disallowed.  Seriously, how hard is it to fool even an educated user to trust a digital certificate?
  4. Safe path | Safe paths are places where JavaScript can write to the local  disk... safely.  According to the Adobe documentation, "a path cannot point to a system critical folder, for example a root, windows or system directory.  A path is also subject to other unspecified tests."  Unspecified tests?  So Acrobat controls where the PDF (via JavaScript) can read/write?  If this is anything like the old IIS ../../../ issues, I can only imagine the fun.
The point here is this... JavaScript interpreters have notoriously been... buggy... to say the least and there is a lot of damage that Adobe could be doing here without really considering the consequences.  It's irrisponsible to randomly add functionality to a file format and rendering engine without first considering the serious consequences.  Did Adobe think about the millions of users who use Acrobat to read/write PDF files every day?  Of course you and I would hope so... but we can't assume.  Adding powerful functionality like JavaScript into the PDF file format and interpreter has clearly caused some serious damage... just Google "Adobe PDF vulnerability" yourself (or click here for results).

Adobe needs to answer the main question looming over this JavaScript functionality disaster - "Was JavaScript added because developers and designers demanded it?  Or was it simply another example of a vendor throwing in cool functionality to lure developers to use their product?  Adobe, we're listening...

[1] TheRegister Article - April 28th, 2009
[2] Adobe PSIRT Blog - April 28th, 2009

Thursday, April 23, 2009

IRS Playing with Fire

Rubbing salt in the wounds of over 1MM people who had their personal information compromised, the IRS (Internal Revenue Service) has awarded RBS WorldPay a contract to process tax return payments for the 2010 filing season.

The Internal Revenue Service has awarded a contract to process tax return payments for the coming filing season to RBS Worldpay, a company that recently disclosed that a hacker break-in jeopardized financial data on 1.5 million payroll card holders and at least 1.1 million Social Security numbers.
It would seem to me that this is rubbing salt in our wounds.  The article goes on to show how even the government is resting on the laurels of PCI Compliance, in an effort to comprehend (or at least pretend to comprehend) the complexities behind securing private information in the banking/card services sector.
IRS spokesman Anthony Burke said RBS will not be allowed to process credit card payments for taxpayers owing money to Uncle Sam until Jan. 20, 2010. Before that date, he said, RBS will not only have to show that it is once again PCI compliant, but that it also has passed the IRS's own payment security audit.
All I can really say is... yikes.  So are we once again equating passing a "point in time" audit as demonstration of overall good ongoing security?  I know this could spark a disagreement between the two sides in the compliance-based security debate, so I'm going to leave that alone for now. My bigger concern is that the US Government (the same government which has now spent our great-great-grand-children's money) is making some very poor decisions.  There is also a hint of using the IRS's "own payment security audit"... but a browse and search through the IRS.gov website, including their FOIA (Freedom of Information Act) reading room, shows zero documents or disclosures relating to this audit process...  In a government which is re-inventing itself as more transparent... this type of information would be nice to have.

This quote caught my attention immediately, as it hints at a 3rd party "verifier" of security; running a "series of tests" which I can only guess is a functional testing cycle rather than a security "vulnerability test"?
"All service providers must undergo system acceptability testing," Burke said. "We have a third-party who runs a series of tests on all of our providers to make sure their systems are security before they accept credit card payments" on behalf of taxpayers, he said.

In the end, I suspect we the taxpayers will be the ones who pay (literally and figuratively) for the failures of the IRS in managing their processing and payment partners...

Wednesday, April 22, 2009

Raising the Bar? Flash Encryption, Obfuscation

[Cross-post from "Following the White Rabbit"]

On the heels of my OWASP talk regarding decompiling and analyzing Flash [see SWFScan link] files lots of you have asked "So what about Flash file encryption or obfuscation?  Does that make my code any more secure?"  I've done the research and talked to experts (including our very own Billy Hoffman) - and have a blog post just for those of you starving for this information.

 There are a lot of Flash file obfuscators/encryptors out there... all of them hoping to raise the bar for attackers against your client-side Flash code.  I'd like to make sure I properly set the background for you here - everything you'll read about is happening on the client side within the user's browser framework, meaning, it's running in potentially hostile territory.

 Now let's move on and take a look at some of the ideas we're addressing.  First when-ever you're discussing client-run code you have to understand that whether it's encryption, obfuscation, or magic you have one major problem: the client has to know how to un-do the magic.  When the Flash! file comes to your client it has to be interpreted by the Flash! player, right?  In order for it to do that it has to be readableand understandable by the Flash! player.  Think about that.  If the code is sent encrypted, say using some strong AES-256 encryption technology, then the player is unable to render it thus creating a quite secure, but completely unusable "blob".  In order for the code to be worth anything to the client it has to be de-crypted (or obfuscated).  For that to happen you have to have the routine to decrypt | de-obfuscatethe blob located within that blob, likely as a pre-cursor to the whole piece of code.  You should already see a huge gaping hole here.  Here's what this all looks like in terms of process from developer's workstation to client player:

  1. Developer writes some [potentially bad] ActionScript code
  2. Developer "obfuscates | encrypts" the code
  3. User hits page, downloads embedded "blob"
  4. User starts to execute Flash! file
  5. Decryption|De-obfuscation routine runs, produces valid (unprotected) Flash!
  6. Flash! player executes code, movie runs

Immediately, in the above step-by-step you'll notice that step 5 the decryption|de-obfuscation routine has to run on the client to unprotect the SWF file.  This essentially breaks down to mean that the deobfuscation|decryption code has to exist on the client, within the protected SWF file.  Ask yourself what sort of security that buys you, if you're including the unprotect routine with the protected code.

After wading through many different SWF encryption|obfuscation tools I've come to realize that they're selling to folks who simply don't understand the full scope of the problem.  Here is an interesting quote from one vendor's marketing material.  I'm not identifying the vendor... mostly to protect them from the questions you would have about their effectiveness.

"PRODUCT X uses Advanced Obfuscation Techniques along side proven Encryption Technology to provide security and protection for your Adobe Flash® SWF Files. Put simply, PRODUCT X prevents other people from decompiling or reverse engineering your SWF movie and stealing the ActionScript Code." How can a vendor make a statement like that, consciously, knowing full-well that this is just like the obfuscation techniques that are being used on JavaScript right now... their effectiveness is only marginal to the determined attacker.  You have to continue to put these types of technologies into context because if you're looking at "encrypted content" you'd think that it's secured, much like an "encrypted database" is secured from someone who steals it... until you realize the main difference is that generally the decryption routine is not included with the database but as a separate process.  This is the main difference.  Since Flash! player has no internal mechanism to decrypt|de-obfuscateflash files the work falls to the application itself, meaning it has to be included into the code blob.

The verdict?  If you're depending on a code obfuscation|encryption tool to protect your Flash! files, you should probably re-think your strategy.  First ask yourself why you're hoping to hide the client-side code.  Intent here is key... because while the tools you're using may temporarily deter a simple Flash decompiler, in the long-run it will not protect your code.  As Billy Hoffman notes "Client-code obfuscation|encryption is much like WAF (Web Application Firewall) technology, it's a temporary fix meant to increase the "time to hack" while not providing anything permanent."  Including sensitive information on a client-side code blob is never a good idea.  This should be self-evident but apparently there is a significant market for Flash! obfuscation|encryption tools so maybe I'm wrong.  Here are a few pointers for those of you thinking about writing sensitive client-side Flash! apps...

  1. Never put sensitive information on a client (passwords, 'hidden" URLs, validation routines, encryption routines, etc)
  2. Understand that anything on a client can be compromised because you no longer have control
  3. Any encryption|obfuscation of client-side code has to be un-done in order for the framework to process it... thus only providing marginal security improvement

When all is said and done, to quote Billy Hoffman "It's like boxing a 7 year-old... you're going to win it's just a matter of how hard do you want to try".  --Thanks to Billy Hoffman of HP's Web Security Research Group for his contribution to this blog, and his ongoing effort to protect developers from their own worst enemy... themselves.

Monday, April 20, 2009

Hackers are Opportunists

Over the years we've all seen the arguments over which operating system is "better" or for the purposes of this blog, more secure.  In the end, I've always contended that any OS can be mis-configured equally poorly and each of the relevant, modern operating platforms has their positives and negatives.  Whereas Microsoft's Windows platform tends to cater to the less technically intensive administrators, Linux covers those who need ultimate flexibility and aren't afraid to write their own code when the need comes, and the various UNIX platforms cater to more advanced administrators who don't need the GUI to control their OS.  Those are given, accepted arguments that don't need to be re-defined.

At the desktop, the debate of late has been which OS is more secure in spite of the user sitting at the controls.  While Apple has launched an entire campaign aimed at making Microsoft's Vista OS look inept, insecure, and crash-prone... and quite frankly "no fun" they have quietly misled the audience.  Apple's message, snuck into the latter series of the commercials, has been "Macs don't get viruses or malware"... yet they continue to advise their users to purchase and use anti-virus applications.

Interestingly enough under the Mac's Frequently Asked Questions section  you'll find this little gem:

Are Mac computers secure?

Yes. While no computer connected to the Internet is 100 percent immune to viruses and spyware, the Mac is built on a solid UNIX foundation and designed with security in mind. The Mac web browser, Safari, alerts you whenever you’re downloading an application — even if it’s disguised as a picture or movie file. And Apple continually makes free security updates available for Mac owners. You can even have them download automatically.

Fairly interesting, there is no mention of needing anti-malware software anywhere... Even more interesting is this link from SC Magazine which takes note of the quiet release from Apple telling users to start using Anti-Malware software on their Macs... even more interesting is the fact that the alert issued apparently doesn't exist anymore (it was pulled, or changed, or....?).

Now it looks like there is even a new trojan hidden inside some Mac software (warez) downloads from the pirate Internet which creates a Mac botnet!  While reports of how effective this botnet and trojan really was has been debated - quite frankly it's immaterial.  The fact is, Macs are now a taret too.  The Macintosh has become a victim of its own success, much like the PC was years and years ago.  Apple's brilliant marketing blitz coupled with users' backlash against Windows operating-systems issues has propelled Macs to the height of popularity - of course this means new Mac owners and thus more Macs out there to exploit and use.

Hackers are opportunists, I hope that's no revalation.  The goal of a hacker is to exploit a system to achieve some end, usually that end is to make money.  If I'm a writer of malicious code (or other malware) I want to tough the largest audience possible with my piece of software - therefore I will go after the largest market-share of operating systems.  This clear example illustrates why Windows users have been the taret for such an overwhelmingly large percentage of malware over the years... simple economics.

Now that Macs have become more popular we're starting to see an huge influx of clueless Mac users, much like the PC experienced years and years ago.  Naturally, this means that more malicious software will start to flood the dark corners of the Internet as user volumes increase for the Mac.

Stay vigilant... it doesn't matter what OS you're using, what browser you're using and how natively secure you were told your operating system is... you're going to be a target at some point.  There is no such thing as effortlessly secure, the fact is that whether you're using a Mac, a Windows OS, or something else - you're still going to be a victim if you're ignorant.

Thursday, April 16, 2009

Fan of Ubuntu Linux? Thinking security?

Linux Magazine has an article titled "Your Distr ois Insecure: Ubuntu"... and it hit home for me since I converted over from gentoo a few years ago and never looked back.

It's a worthy read and bashes Ubuntu creators a bit for focusing too much on simplicity versus security - but can you blame them?  This is a very careful high-wire act trying to keep usability high and making the OS simple to install, configure and use and the need to make it secure.

My personal verdict?  I still prefer it to a Windows box any day of the week for my needs; it's just important to continue to think about security even as you install Linux.

Wednesday, April 15, 2009

Password Re-use Lessons for the Seoul


An article on the Joong Ang Daily site today had a lesson for Koreans that the whole world can share in: Don't re-use the same login/password everywhere on the 'net.
"Two computer programmers were indicted yesterday on charges of hacking into Web sites and obtaining personal data of 2.3 million persons and using part of that information to post spam advertisements on Naver and other Web sites."
What made me cringe was this metric below... this is a full 6.5% password-re-use on this single site!
"Of the 2.3 million people whose personal information was hacked, some 150,000 had used the same ID and passwords on Naver, prosecutors said. "
Please, people... learn the lesson.  Don't re-use the same UserID and password all over the place.  More importantly, if you are going to re-use... at least don't mix password use across different types of sites (credit cards, banks, media, social networking, etc)...

Good luck!

AntiVirus is like a CD Player

Your anti-virus client on your computer is much like a CD player these days. It was cool, at first. Everyone got one. They were "cool" for a while. Now your car comes with it and you can't figure out where to plug in your iPod.

I know there have been many, many blogs and articles that have said this, and even I have over the past year or so banged this drum too - but AntiVirus is simply a relic technology. Want proof? Go read the Verizon 2009 Data Breach Investigations Report (summary here).  One of the things that immediately stands out to me is that a staggering percentage of cases (38% of the total investigated) were "hacked" by malicious software (malware).  That's a mind-boggling number.

Couple this with the fact that both SRA International, as well as Heartland Payment Systems were "hacked" by what was referred to as "malicious software strategically placed on their systems"... and you have a very, very serious problem brewing.  The issue is exacerbated by the fact that corporate security still sees "antivirus" as a reasonable stop-gap for combating these types of threats.

I can't tell you how many people simply nod their head and smile when they hear me rant about how I hate the agents that continually get added to my corporate laptop.  AntiVirus was the first, then because I research nasty things more often than most I added a few things on my own like "Anti-Spyware" and "Anti-Spam" and other stuff... then I doubled-up on my Anti-Virus protection and I think I've now got around 5 disparate agents which are all anti-.

Guess what folks - odds are that if your company is going to be the target (and I specfically say "target" here for a good reason) of a malware plant - you're still screwed.  I specifically mention that if your company is a target because the run-of-the-mill malware that's circulated for days or weeks typically *can* be caught by standard anti-malware agents these days... but targetted attacks such as custom-written malware... you're screwed.

The answer?  I don't know of a good one, unfortunately.  I can tell you that best-practice including locking your users from being local admin still works pretty well.  Filtering and limiting people's access from their office computers works pretty well.  I'm sure there are many other counter-measures out there too... but education wouldn't hurt.

Bottom line is this... stop adding anti- agents to your machines... if the battle is on your doorstep, it's lost already.

Friday, April 10, 2009

Lawyers & Settlements - (o)(O)ps...

Would you consider this hypocrisy, irony or some combination of both?

LawyersandSettlements.com a news site that publishes cases like class-action law suits against corporations for data breach, negligence, etc... (see link): http://www.lawyersandsettlements.com/search.html?keywords=data+breach is just as guilty as those companies being sued for poor security practice. They've got some basic web site issues that if properly manipulated could lead to the compromise of their users. It would sure be ironic if they ended up on their own pages, wouldn't it? I mean, I'm no lawyer and have zero expertise in this but it would be kind of funny.

That being said, the fact that you can simply do this should be embarrassing, to say the least - and a little hypocritical to be sure http://www.lawyersandsettlements.com/search.html?keywords=

I wonder how seriously they take security? I also wonder if they grasp that the simple cross-site scripting (XSS) issue demonstrated here could be weaponized to make a whole lot of additional zombie machines (like we need any more of those)!

I've sent them a request via their contact us page, I hope to get their reply soon and hopefully they'll fix the issue... and review their web site security some.

NJ Devils Make it Exciting

Totally OT...

WOW... Jeff (@SecurityAgent on twitter) took me out to the Devils vs. Senators game tonight - and the Devils sure made it interesting fallig behind 1 to 0 early, then taking 2 goals in a row only to have the Senators tie it with 1:00 minute left on the clock in the 3rd period.  Eventually we took it to the shootout - and Marty Brodeur shined as always leading us to a victory, and sealing the Divisional title... again.

Devils vs. Penguins in the playoffs - awesome!

Any predictions before the playoffs start that anyone wants to make?

Tuesday, April 7, 2009

OWASP - Ottawa and Montreal

First let me say that it's been a blast so far getting in front of these two new OWASP chapters!  Sherif and Benoit are doing a marvelous job getting people excited and engaged... and I wish you best of luck  - hopefully our pathes will cross again in the near future.

Now... I have to make a few comments on the last 2 nights -

The Ottawa group was awesome, met a lot of great people and had a fun time - I hope you all enjoyed the talk and topic, and feel free to contact me either through Sherif or directly if you have any follow-up question!  You know you're hanging out with a unique group of people when it's 10:30pm and suddenly you're talking about thermite... yea, thermite.  (I told you I'd blog about it!)  Guys, Moxie's was amazing... quite the place to be definitely.

My night here in Montreal was overwhelming.  I couldn't have asked for a better turn-out, a nicer facility (special thanks to the folks at CN for hosting!) and a more engaging conversation afterwards.  Here are some pictures from the room we had - it was truly a humbling experience!


------

And of course... you can't quite call it an awesome night in Montreal without running into a celebrity at a bar... 

Pat Quinn at some random Irish bar... nice!

Monday, April 6, 2009

Register.com DDoS - Part Deux

There's nothing worse than being victimized.  Scratch that... the only thing worse than being victimized is then being blamed for the troubles.

Now, I'm the first to say that a massive Domain Name behemoth like Register.com should be well-prepared to hold up against even a large-scale DDoS so I think it's only fair to ask those folks to be forthright and honest with the customers about what happened, how it happened, and what they are doing to build more resiliency into their infrastructure.  I realize that there are some proprietary company secrets in there they would rather not disclose publicly but in the name of transparency and positive PR they should make a best-effort and really push for openness.

My personal feelings here, as a customer of theirs affected by this outage, is that something should have been done to make sure I was at least getting minimal service during this massive outage.  While you can't control things like a DDoS we know after years of research that there are technologies that can aide in holding back the flood-waters of a DDoS and at least let some transactions function.

As this article clearly points out there are at least two different ways that such an outage can be handled in the PR arena... both of them were terrible.  Denial is not good because customers and analysts can see right through it - quite obviously; and radio silence (a la no information) is just as bad...  I've been urging the Register.com folks (Nick Dellis posted a comment previously on this blog) to come clean and give us at least some information on what took place.  I'm not asking for every intimate detail, I just want to know what/how/why and why it won't happen again... as a paying customer I feel that is my right.

So to the Register.com folks, I'm posing this request, please reply either privately or publicly to this blog with the following information...
  1. Please explain to us with as many technical details as you are able WHAT happened
  2. Please provide the scope, length and nature of the attack
  3. Please tell us what Register.com is doing to make their service resilient against this type of attack going forward
There are a lot of DNS services out there, and quite honestly I don't think silence is an acceptable response.  If Register.com doesn't feel the need to share some of this information... I don't feel I want to continue as a customer - it's only fair.  I'm fairly sure I won't be alone in that regard.

Friday, April 3, 2009

And the winner is...

Quine (Zach Lanier) with "A Laugh RIAt - Security in Rich Internet Applications"

Thanks to everyone who submitted a suggestion, and to the almost 100 people who voted! You guys rock... Zach eeked a narrow win over Lisa by 2 votes 36 to 34... wow!!

Zach - I owe you an adult beverage (or the beverage of your choice) as per the contest rules next time around...

Register.com DDoS'd off the Internet

The hot story the last 24 hours has been behemoth DNS registrar Register.com. They have been, apparently, getting pounded by a distributed denial of service over the past several (24+) hours, and I can count myself among the domains down.

The Inquirer (INQ) is carrying the story here, with little other coverage, oddly enough.

What is going on at Register.com? I'm losing business as seconds turn to minutes turn to hours turn to days now... I'm raging mad and I can't even get their overwhelmed tech-support folks to pick up the phone!

If you've been affected by the massive DDoS - leave a comment either here or on the INQ's site... Regiser.com needs to know this is not acceptable.

Wednesday, April 1, 2009

Crossing Over

One of the most difficult things to do for a technologist is to take a tour of duty on the other side of the table.

For someone who deals every day with the technology and realities of security it's difficult to understand why anyone in their right mind would want to do things the wrong way.  And yet, every day we're presented with oft-bizarre problems that defy logic and sometimes even common sense - coming from whom we would otherwise thing of as reasonable people.  Our associates in the business world can sure as the sun rises ask for some ridiculous things some times, right?  What makes them tick and why do they think the way they do?  There is a bit of magic that happens when one understands the mind of a business analyst because we can then communicate using the same language and on the same level.

Whilel this sounds great in theory let me first point out why it's so difficult for technologists to comprehend the vernacular of business and the logic.  From the outset technologists are taught to see the problem as a technology-centric problem.  When packets don't cross the wire, the wire must be broken... or something on that wire is dropping the packets on the floor.  If we've just patched a server and upon reboot it goes nuclear then the obvious thought that comes to mind is the patch must somehow cause the defect.

We technologists get a tunnel-vision for technology solutions and everything begins to look black and white.  Every problem is either solvable, or it's not.  The network is either secured by the firewall, or it's not.  The server is either patched or it isn't.  Things are either secured... or they're not.  Black or white.  Yea... that's mostly wrong.

What we consistently fail to see is the middle ground out there, the gray areas, the good enough that eludes our technical genius.

So the most logical thing to do is to cross over.  Go shed your technical propeller-hat and become a business analyst for a few months... but this is a lot more difficult than it may seem at first.  Standing in the midst of people who don't think like you do, who don't immediately throw technology at a problem - that may be more difficult tha you're prepared to handle.  Remember... technology is simply an enabler for the business.  Often times the correct answer for the business is absolutely the wrong answer for technology and security - but it's got to be done.

Here are a few things you'll need to change your thinking on in order to succeed as a business analyst:
  1. IT is a tool to accomplish a business-end
  2. Risk is acceptable, to a degree
  3. Cost is important
Crossing over, and understanding the other side is paramount in a successful technical security agent's career.  Understanding the mindsets, the drives, and the goals of the business side of things will make you better prepared to have a conversation about security.

.
Google+