Posted: 08 Oct 2008 12:24 AM CDT
Yesterday a PoC of the Clickjacking exploit was released. Today Adobe released a workaround to fix the Clickjacking vulnerability in Flash. Here is a video of the PoC. Since I shared this with my students last month I wanted to share the details now that they have been made public. The whole Clickjacking exploit has had [...]
Posted: 08 Oct 2008 12:23 AM CDT
Web pages know what websites you've been to (without JS), where you're logged-in, what you watch on YouTube, and now they can literally "see" and "hear" you (via Clickjacking + Adobe Flash). Separate from the several technical details on how to accomplish this feat, that's the big secret Robert "RSnake" Hansen and myself weren't able to reveal at the OWASP conference at Adobe's request. So if you've noticed a curious post-it note over a few of the WhiteHat employee machines, that's why. The rest of clickjacking details, which includes iframing buttons from different websites, we've already spoken about with people taking note.
Predictably several people did manage to uncovered much of what we had withheld on their own, whom thankfully kept it to themselves after verifying it with us privately. We really appreciated that they did because it gave Adobe more time. Today though much of the remaining undisclosed details we're publicly revealed and Adobe issued an advisory in response. Let's be clear though, the responsibility of solving clickjacking does not rest solely at the feet of Adobe as there is a ton of moving parts to consider. Everyone including browser vendors, Adobe (plus other plug-in vendors), website owners (framebusting code) and web users (NoScript) all need their own solutions to assist incase the other don't do enough or anything at all.
The bad news is with clickjacking any computer with a microphone and/or a web camera attached can be invisibly coaxed in to being a remote surveillance device. That's a lot of computers and single click is all it takes. Couple that with clickjacking the Flash Player Global Security Settings panel, something few people new even existed, and the attack becomes persistent. Consider what this potentially means for corporate espionage, government spying, celebrity stalking, etc. Email your target a link and there isn't really anyone you can't get to and snap a picture of. Not to mention bypassing the standard CSRF token-based defenses. I recorded a quick and dirty clickjacking video demo with my version having motion detection built-in.
Robert and I are currently scheduled to give more or less simultaneous presentations in Asia about clickjacking. For myself, I'll be delivering a keynote at HiTB 2008 Malaysia (Oct 29) and RSnake will be speaking at OWASP AppSec Asia 2008 (Oct 28). The timing just happened to work out well. The next couple weeks will give us time to put our thoughts in order, explain the issues in a more cohesive fashion, and bring those up to speed who've gotten lost in all the press coverage. For those that have been following very closely, you'll probably not find any meaningful technical nuggets of information that are not already published. Our job now is to make the subject easier to understand and help facilitate solutions to the problem. Unless the browser is secure, not much else is.
What a couple of a weeks this has been. Thank you to Adobe PSIRT for their diligence and hard work.
Posted: 07 Oct 2008 11:59 PM CDT
Posted: 07 Oct 2008 11:16 PM CDT
So I was lucky enough to be able to take part in SecTor training this week (as I previously mentioned). I spent all day Monday in HD Moore's Metasploit training.
Having been been an avid metasploit user for quite some time, I was hoping that the training would include some features that were unknown to me. I definitely wasn't disappointed.
The initial portion of the training was fairly straight forward and included writing a basic auxiliary module and a plugin. The basics of Metasploit use were also covered.
This occupied roughly half the day, at which point we had lunch... the food wasn't great but it also wasn't awful. Then we were right back into the training.
Over the course of the afternoon we covered meterpreter, NTLM (smb_relay, and some others), Wireless and IPv6. A number of new and interesting things were covered and I really enjoyed the afternoon.
Following the training, myself and a colleague who also attended to the training met up with HD and a few other speakers and attendees to grab dinner. This was the sort of thing that I really enjoy about the cons, sitting around the table with a few beer talking shop. While I enjoy the talks, a lot of the time there's nothing overly new and it's when you're chilling and chatting that you really get a chance to discuss the interesting things.
At the end of the day, the training was definitely worth it. The only real shame (although a bonus for those of us attending) was that the training room was so empty... We had ~11 people. My worry is that SecTor won't be able to get decent trainers next year unless they can increase the attendance numbers.
Stayed tuned for another post on SecTor - Day 1... (which will eventually be followed by SecTor - Day 2).
Posted: 07 Oct 2008 10:55 PM CDT
The next time you read a statement that a breached entity has found no evidence of data misuse, remember this: data may have been misused even though entities are unaware of it.For the rest, you'll have to click over to PogoWasRight.
Posted: 07 Oct 2008 06:27 PM CDT
The coveted Security for All “Energizer Bunny” award goes to Microsoft Windows XP for it’s ability to just keep going and going… Yep, the rumors of XP’s impending demise, ostensibly to be replaced by the exciting new Windows Mojave er… Vista are still somewhat premature. Undoubtedly to Microsoft’s chagrin. Check out this announcement as reported in InfoWorld.
Competition with oneself issues aside, hats off to Windows XP for winning this prestigious award.
Posted: 07 Oct 2008 04:43 PM CDT
I make a conscious effort not to blog on topics that others have already discussed, unless they impact me directly. So to add to the pile of “FAIL” account resets, which I refuse to call “hacks,” I have another one to add. Yesterday, I tried to login to an online software stores but I couldn’t remember [...]
Posted: 07 Oct 2008 03:03 PM CDT
Regular readers of this blog know that as a Software Engineer and music composer I’m all about getting paid for the intellectual property that I create and develop. The mechanism, flawed though it may be, that protects most of the work I do is copyright, which is typically held by my employer. If my company doesn’t get paid for the products I develop, they in turn can’t pay me. So I’m all for copyright enforcement.
I am most assuredly not for the kind of asinine, over-the-top enforcement that is the focus of this article from Make:.
Aside from the clear moronic “copyright infringement” excuse, what really chaps my hide is the idea that these brain donors from U.S. Customs and Border Protection were concerned with copyright enforcement in the first place. Such an egregious violation of common sense, not to mention personal liberties, is surely not an actual CBP policy or directive. Is it? So I did a little digging and discovered this information about Intellectual Property Rights on the CBP web site.
So exactly what kinds of “counterfeit and pirated goods” and “patent-infringing and other IPR violative goods” are we talking about here. Well, there’s also this report posted on the CBP web site that details exactly that.
OK I guess I can see that. It’s the CBP’s job to protect the interest of American businesses. So a drawing of a SUV cozy would fall into the “All Other Commodities” category - which does, in fact, account for 9% ($6,576,378 US) of the commodities seized. Golly, I’m glad we’ve got the CBP watching our (businesses) backs to protect us from dangerous (to our wallets) IPR violators like Ms. Zempel. Are you kidding me? I’m starting to get the sneaking suspicion that this episode is only tangentially, through creative bending of overly broad policy (now where have we seen that before?), related to IPR enforcement. Could it be that CBP can now detain, harass, and otherwise violate the rights of anyone coming into the U.S. based on specious suspicions of “Intellectual Property Rights violations”? I sincerely hope not, but this episode is clearly evidence of exactly that.
I guess my next trip abroad I will have to make certain that I’m not in possession of such heinous “IPR violative” items as a hand sketched SUV cozy. Thanks CBP for your stellar vigilance. NOT.
Posted: 07 Oct 2008 02:49 PM CDT
Unfortunately, I have not had much time to read lately. The only time I really get to see a book is just before bed and then I usually don't read more than a few pages. Because of this, I was a little skeptical to take on two new titles: the new school of information security and Into the Breach. The latter one is at the top of my current reading stack for a number of reasons. First of all, Michael handed it to me personally at Defcon. Secondly, because it has much less pages, and the chances that I actually finish the book are somewhat greater.
Having said that, I just finished part 2 of the book and my opinion of the book is already a very positive one. Santarcangelo captures the true essence of modern information security: information exists to serve users, and users just want to get the job done. Most people are truly willing to do the right thing, but they need to be enabled and empowered to do so.
When a person is confronted with having to chose between finishing the job in a timely enough fashion for senior management to proceed, versus full and unquestioning compliance with information security controls that might prevent him from getting the job done, it is clear what that choice will be.
Just realizing that is paramount.
Information security must never get in the way of doing business.
And yes, that implies that an information security officer must actually know what the business is all about and how it is conducted.
Posted: 07 Oct 2008 01:12 PM CDT
DarkReading has a good article on the overarching challenges facing security administrators today (bonus alert: it has an I Love Lucy reference!), including mentions of recently "revealed" vectors around both clickjacking and Cross-site Request Forgery attacks. I quote revealed since, even though the Princeton researcher's work on CSRF is well documented, we'll have to wait until the Hack in a Box conference to get the full scoop. The downside of this is that it sure sounds and smells a lot like the Kaminsky thing, and I'm not sure even he would do it that way again. The upside is that it's a chance/excuse to go to Kuala Lampur, which is a beautiful city with amazing food (the latter being an obvious requirement for the former). But I digress.
It's easy to come away from the series of darkreading articles with a, well, dark impression of the state of endpoint secuirty these days. With continually morphing combinations of browser vulnerabilities, infected emails, user gullibility and malware-laden websites, it's difficult to see how any security manager can keep his endpoints malware-free for any window of time. And all of this is made even worse by the fact that many of the new vulnerabilities aren't bugs per se, but rather dependencies on the very things that help make today's web cool. So, never mind, one might argue. We've failed and the cause of malware-free computing is lost.
But perhaps what we need is to change our thinking about what failure is (which is different than re-thinking what is is). Perhaps we've spent too much time so far putting our collective eggs in the basket of avoiding endpoint infection, when, really, at least some that attention is better spent on the idea of containing infections that are, in the end, inevitable. Put another way, it's not an engineering failure to have a router (or WAN card, or FRAD, or whatever) failure in the Bogota office. It is an engineering failure for that equipment failure to result in a services outage for the people in the Bogota office or anywhere else (I'm not intending to pick on Bogota, by the way. They have fine food too). We accepted long ago that what equipment does is fail. That acceptance didn't stop global data networking, obviously; it simply drove best practices around the notion of engineering for that failure.
My thinking of late, then, is that we've so far put too much attention on the single point of failure that is infection avoidance. That means (yes) having mechanisms in place to (a) detect the infection and (b) affect the network access of the endpoint in a timely way. But it also means things beyond just NAC, like the ability to clean/restore the system without having to put a help desk person on a plane. Not easy, perhaps, but it seems an answer that is at once more in keeping with the traditions of IT, and, well, more hopeful.
Posted: 07 Oct 2008 11:51 AM CDT
I wanted to comment quickly on an interesting post by Michael Zimmer, " On the “Anonymity” of the Facebook Dataset." He discusses how
A group of researchers have released a dataset of Facebook profile information from a group of college students for research purposes, which I know a lot of people will find quite valuable.and
Of course, this sounds like an AOL-search-data-release-style privacy disaster waiting to happen. Recognizing this, the researchers detail some of the steps they’ve taken to try to protect the privacy of the subjects, including:In the comments, Jason Kaufman implies that the data really isn't that private, asking what could go wrong, and why would someone post it to Facebook expecting it to remain private.
I have just one question on all of this. If the data isn't private, why did they attempt to anonymize it?
I believe they attempted to anonymize it because it's fairly obvious that the data is private, and releasing it with names obviously attached would be pretty shocking. As Michael Zimmer says, "we really need to keep working on a new set of Internet research ethics and methodologies."
Also, don't miss Michael Zimmer's followup post, "More on the anonymity of the Facebook dataset: It's Harvard College."
Posted: 07 Oct 2008 09:02 AM CDT
Gadi Evron, (founder of the Zero Day Emergency Response Team) via his blog, comments (philosophically) on the recent shutdown of Atrivo, cybercriminals and their ilk. His post is today’s MustRead, and is highly recommended.
Posted: 07 Oct 2008 08:52 AM CDT
I couldn't help but laugh reading Tim Greene's NAC newsletter today. Tim is taking about a NAC customer who uses NAC without the enforcement or "self-remediation" turned on and has done so for over a year. Tim reports that the customer is still finding tremendous value in his NAC product by being able to understand who is logging on the network, what port they are plugged into and what their endpoints look like.
Though the customer referenced in Tim's article is not a StillSecure customer, it really doesn't matter. What Tim is describing is exactly what we have been preaching on NAC for 2 years now. NAC is not all about the quarantine! Too many people focus in on NACs ability to shut people off the network, but that is not end game people. Here at StillSecure we have one large network that tests over 200k devices a day and quarantines almost no one!
Most people accessing the network have a legitimate right to be on the network. Our job is to make sure they do so in compliance with our security policies so they do no harm and are not harmed. We actually wrote a great white paper on this very subject called "A phased approach to NAC" that describes how to roll out NAC in phases and the value that can be derived from each phase. You don't have to get all the way to the enforcement or quarantine phase. Many customers are content with the value they derive without quarantine to more than justify the investment in a NAC system.
I think part of the maturation of the NAC market is the realization of this value. I hope that Tim's newsletter will help spread the word that NAC is not just about the quarantine!
One caveat though is that some customers are just not happy unless they can eventually quarantine devices. For those customers your NAC solution has to have the ability to do this irrespective of your network architecture.
Related articles by Zemanta
Posted: 06 Oct 2008 04:02 PM CDT
So lets start thinking about the basic requirements for confidentiality in the workplace. In particular let us consider the principal causes of unintended disclosure:
We have no means of accurately evaluating the relative importance of these factors in actual attacks. While conventional wisdom holds that '60%' of all attacks come from within the enterprise the evidence for this claim appears to be anecdotal and is almost certainly out of date in any case.
Posted: 06 Oct 2008 12:32 PM CDT
Related PostsWebroot® Threat Advisory: Hackers Using Real Headlines to Attract Users to Fake Blogs
Posted: 06 Oct 2008 10:50 AM CDT
I had a great time in a conversation with Dennis Fisher which is now up on his nameless security podcast: Adam Shostack on privacy, data breaches and “The New School of Information Security”
Check it out.
Update: Amazon seems to be having trouble keeping The New School in stock. (Thank you!!!) Addison Wesley has the New School in stock, if you'd like to buy it now.
And really, thank you! You don't know how happy it makes me that the emergent behavior of readers (and listeners) have wreaked chaos on Amazon's prediction algorithms.
Posted: 06 Oct 2008 09:42 AM CDT
CERN’s LHC Computing Grid has gone live. One of the largest Computational Grids in existence, estimated analysis & data management sizes are on the order of 10 to 15 Petabytes per annum. Fascinating up to date views of Grid activity are available to the public.
Posted: 06 Oct 2008 09:36 AM CDT
The Office of the Director of National Intelligence (ODNI) has announced a new policy targeting information sharing amongst US Federal Agencies. Created by the United States Congress and the President, the Information Sharing Environment (ISE) supports five agency (or community) types: , Law Enforcement, Defense, & Intelligence.
Posted: 06 Oct 2008 09:29 AM CDT
"We are at an interesting juncture today; there are no threats to information technology for which we do not have the tools to combat them" Reliable Security, Steven J Ross. Information Systems Control Journal, Volume 5, 2008, pp 9-10.
Whether or not the author truly believes that this statement is true, it is a definite attention-getter. Other phrase in the article reads "[...]it appears that we know what to do to achieve information security, but we are not doing it".
My first thought after reading these statements was that the author has no idea what he is talking about, or that he is trying to start a flame war. However, given that the author holds a director position at Deloitte, his thoughts may deserve more consideration.
After giving it some thought, I realized what the flaw in this logic is.
I actually agree with the point-of-view that most (if not all) technology-borne threats can be mitigated or removed.
However, what must never be forgotten is that preventive controls come at a price. And while it may be true that all technology-based vulnerabilities can be mitigated (for example, by stopping to use the technology altogether), the cost of doing so might simply not outweigh the risk of doing it.
Most of the time, I am a firm opponent of the traditional quantified risk-based approach of calculating the annualized loss expectancy of a vulnerability and offsetting those cost against the annualized cost of mitigation.
While this is indeed the way to approach information security management from a theoretical business-driven approach, the reality of the matter is that we do not currently have the body of knowledge required to assess asset value, exposure factors, probabilities of manifestation, etc.
The collective knowledge in the information risk management discipline is much too under-developed to adopt this method of creating an objective and rational approach to investment decisions.Having said that, using common sense and maybe perform some qualitative guestimating every now and than will argue in favor of my opinion: It may be possible to mitigate any technology-borne risk, but the cost of doing so will usually be prohibitive. It is unfortunately that Ross neglegted to emphasis this in the article.
|You are subscribed to email updates from Security Bloggers Network |
To stop receiving these emails, you may unsubscribe now.
|Email Delivery powered by FeedBurner|
|Inbox too full? Subscribe to the feed version of Security Bloggers Network in a feed reader.|
|If you prefer to unsubscribe via postal mail, write to: Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610|