Thursday, April 30, 2009
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
- 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...
- 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
- 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?
Thursday, April 23, 2009
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 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.
Wednesday, April 22, 2009
[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:
- Developer writes some [potentially bad] ActionScript code
- Developer "obfuscates | encrypts" the code
- User hits page, downloads embedded "blob"
- User starts to execute Flash! file
- Decryption|De-obfuscation routine runs, produces valid (unprotected) Flash!
- 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.
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...
- Never put sensitive information on a client (passwords, 'hidden" URLs, validation routines, encryption routines, etc)
- Understand that anything on a client can be compromised because you no longer have control
- 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
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.
Thursday, April 16, 2009
Wednesday, April 15, 2009
"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. "
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.
Friday, April 10, 2009
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.
Tuesday, April 7, 2009
Monday, April 6, 2009
- Please explain to us with as many technical details as you are able WHAT happened
- Please provide the scope, length and nature of the attack
- Please tell us what Register.com is doing to make their service resilient against this type of attack going forward
Friday, April 3, 2009
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...
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
- IT is a tool to accomplish a business-end
- Risk is acceptable, to a degree
- Cost is important