You've probably never thought of this, but the home automation market in the US was worth approximately $3.2 billion in 2010 and is expected to exceed $5.5 billion in 2016.
Under the hood, the Zigbee and Z-wave wireless communication protocols are the most common used RF technology in home automation systems. Zigbee is based on an open specification (IEEE 802.15.4) and has been the subject of several academic and practical security researches. Z-wave is a proprietary wireless protocol that works in the Industrial, Scientific and Medical radio band (ISM). It transmits on the 868.42 MHz (Europe) and 908.42MHz (United States) frequencies designed for low-bandwidth data communications in embedded devices such as security sensors, alarms and home automation control panels.
Unlike Zigbee, almost no public security research has been done on the Z-Wave protocol except once during a DefCon 2011 talk when the presenter pointed to the possibility of capturing the AES key exchange ... until now. Our Black Hat USA 2013 talk explores the question of Z-Wave protocol security and show how the Z-Wave protocol can be subjected to attacks.
The talk is being presented by Behrang Fouladi a Principal Security Researcher at SensePost, with some help on the hardware side from our friend Sahand Ghanoun. Behrang is one of our most senior and most respected analysts. He loves poetry, movies with Owen Wilson, snowboarding and long walks on the beach. Wait - no - that's me. Behrang's the guy who lives in London and has a Masters from Royal Holloway. He's also the guy who figured how to clone the SecureID software token.
Amazingly, this is the 11th time we've presented at Black Hat Las Vegas. We try and keep track of our talks and papers at conferences on our research services site, but for your reading convenience, here's a summary of our Black Hat talks over the last decade:
Setiri was the first publicized trojan to implement the concept of using a web browser to communicate with its controller and caused a stir when we presented it in 2002. We were also very pleased when it got referenced by in a 2004 book by Ed Skoudis.
A paper about targeted, effective, automated attacks that could be used in countrywide cyber terrorism. A worm that targets internal networks was also discussed as an example of such an attack. In some ways, the thinking in this talk eventually lead to the creation of Maltego.
Our thinking around pentest automation, and in particular footprinting and link analyses was further expanded upon. Here we also released the first version of our automated footprinting tool - "Bidiblah".
In this talk we literally did introduce two proxy tools. The first was "Suru', our HTTP MITM proxy and a then-contender to the @stake Web Proxy. Although Suru has long since been bypassed by excellent tools like "Burp Proxy" it introduced a number of exciting new concepts, including trivial fuzzing, token correlation and background directory brute-forcing. Further improvements included timing analysis and indexable directory checks. These were not available in other commercial proxies at the time, hence our need to write our own.
The second proxy we introduced operated at the TCP layer, leveraging off the very excellent Scappy packet manipulation program. We never took that any further, however.
This was one of my favourite SensePost talks. It kicked off a series of research projects concentrating on timing-based inference attacks against all kinds of technologies and introduced a weaponized timing-based data exfiltration attack in the form of our Squeeza SQL Injection exploitation tool (you probably have to be South African to get the joke). This was also the first talk in which we Invented Our Own Acronym.
In this talk we expanded on our ideas of using timing as a vector for data extraction in so-called 'hostile' environments. We also introduced our 'reDuh' TCP-over-HTTP tunnelling tool. reDuh is a tool that can be used to create a TCP circuit through validly formed HTTP requests. Essentially this means that if we can upload a JSP/PHP/ASP page onto a compromised server, we can connect to hosts behind that server trivially. We also demonstrated how reDuh could be implemented under OLE right inside a compromised SQL 2005 server, even without 'sa' privileges.
Yup, we did cloud before cloud was cool. This was a presentation about security in the cloud. Cloud security issues such as privacy, monoculture and vendor lock-in are discussed. The cloud offerings from Amazon, Salesforce and Apple as well as their security were examined. We got an email from Steve "Woz" Wozniak, we quoted Dan Geer and we had a photo of Dino Daizovi. We built an HTTP brute-forcer on Force.com and (best of all) we hacked Apple using an iPhone.
This was a presentation about mining information from memcached. We introduced go-derper.rb, a tool we developed for hacking memcached servers and gave a few examples, including a sexy hack of bps.org. It seemed like people weren't getting our point at first, but later the penny dropped and we've to-date had almost 50,000 hits on the presentation on Slideshare.
Python's Pickle module provides a known capability for running arbitrary Python functions and, by extension, permitting remote code execution; however there is no public Pickle exploitation guide and published exploits are simple examples only. In this paper we described the Pickle environment, outline hurdles facing a shellcoder and provide guidelines for writing Pickle shellcode. A brief survey of public Python code was undertaken to establish the prevalence of the vulnerability, and a shellcode generator and Pickle mangler were written. Output from the paper included helpful guidelines and templates for shellcode writing, tools for Pickle hacking and a shellcode library.We also wrote a very fancy paper about it all...
For this year's show we'll back on the podium with Behrang's talk, as well an entire suite of excellent training courses. To meet the likes of Behrang and the rest of our team please consider one of our courses. We need all the support we can get and we're pretty convinced you won't be disappointed.
See you in Vegas!
Like it, hate it or just plain struggling to understand it, Twitter has made a huge impact across a wide range of fields. We use it fairly heavily internally for simulated water-cooler chatter and quick link-exchange. (like any piece of sp-geek-over-engineering we also have a tweet-bot to convert tweets to emails, and convert blog notifications to tweets). It's pretty clear though, that once we started tweeting internally, people started blogging less. There's something liberating about saying "here's a link", as opposed to taking the time to formulate your thoughts into a full blown posting.
We were curious if this twitter-effect was real, imaginary or only applicable to lazy people like us.. Thanks to python-twitter and a few lines of script we can look at the the blogging habits of some info-sec superstars (and maybe confuse correlation and causation to jump to conclusions while we at it).
Hmm.. maybe its not just us!
PS. SensePoster's who tweet (albeit infrequently) can be found at:
a) was the politely dropped kaminsky firefox bug [http://lists.grok.org.uk/pipermail/full-disclosure/2009-September/070620.html]
It still requires a click for command execution, but considering its multi platform firefox ownage sans shellcode, i think its cool.. i think its even cooler that dan dropped it sans any fanfare..
From the post:
"we get lucky here as well in that there is a pointer srv!pSrvStatistics which also points to srvnet!SrvNetStatistics, and counts the number of requests that have been made to a specific call (as well as other things).
So the technique here is to firstly increment srvnet!SrvNetStatistics to be ffe6, ffd6, or 56c3 (jmp esi, call esi, push esi -> ret). Then we set ProcessHighID to a value that when multiplied by four and added to the base address of ValidateRoutines pushes us outside of srv2.sys and into srvnet.sys where we then end up dereferencing the pointer to srvnet!SrvNetStatistics. This now transfers control to the data in our packet which we can massage to gain execution.
i go through a ton of books. Over the past 10 years, this has been dominated by books on computer security, computer science, programming (and some sprinklings of management classics).
I generally stay away from writing reviews, but was genuinely suprised at the number of 5 star reviews Viega's new book had received and felt i had to chime in.
I picked up "the myths of security" (what the computer industry doesn't want you to know) with hope, because O'Reilly books in general are well done and i really liked some of Johns previous books. Alas! I tried hard to think of a good thing to say about the book, and the best i can come up with right now is that "at least, it wont take up space on my bookshelf".
Advertising++ The Foreword alone uses the word McAfee 14 times, and over the 48 chapters, the word McAfee goes on to appear about 65 times. This is acceptable on a blog, in a book i just paid for its slightly annoying.
Target Audience I agree with Bejtlich who cant figure the books target audience. One chapter might give explanations in crayon (presumably for the less sophisticated user) while the next chapter might give advice for how to label the security technology you plan to sell.
Consistency There are a number of times in the book where the author takes opposite sides of an argument (in different chapters). This is useful if coherently positioned as 2 sides of an argument, but if this is used on different arguments on different pages, it seems more like the author is merely choosing the position thats convenient to support his view at the time...
It's slightly odd when compared with his take on security spend to hear the author say this about the TSA and their "Security Theater": "But there's some hidden value here—it makes people feel safer. Whether it works well or poorly, it is better than nothing and it makes people feel better."
General whining (by me). The author dedicates a chapter to Mobile Phones titled "OK, Your Mobile Phone Is Insecure; Should You Care?". He concludes with: "Sure, there will always be the occasional virus for smartphones, but I don't see an epidemic emerging. At the end of the day, there is still lower-hanging fruit for the bad guys. It is still far easier for them to make money attacking traditional PCs and laptops then going after mobile phones. That may eventually change, but I'm not going to hold my breath."
I think the view that you only need to be worried about the ability of your device to withstand an attack "epidemic" is wrong on so many levels. Im far less worried about my iPhone becoming part of a botnet than i am of the fact that these days huge parts of my life are on it, and can be grabbed by Charlie Miller if he is willing to pay the $0.20 to send me a few SMS'es.
In his Epilogue, he writes: "But instead of preaching that the customer is hosed, I'm preaching that the security industry is hosed—I don't think customers are hosed at all." which is an interesting contrast to his chapter on PKI that ends with "That leaves the Internet fundamentally broken."..
Of course the lines that most bothered me were in the chapters on Privacy and Anonymity. Privacy gets just under 200 words but includes the classic line: "privacy is nice in theory, but if you don't have anything to hide, what's the big deal?"
Hmm.. OK.. lets see the take on anonymity before responding.
Anonymity gets 166 words (wow - 100 words more than the word McAfee!) and once more ends with the classic: "Oh, and I've got nothing to hide anyway…."
The author cites the example of Zero-Knowledge, who built a paid service to surf anonymously which "worked pretty well, but nobody cared".
Once more, i think there is so much wrong here, that im not sure where to start. Having to convince someone that Privacy is important even if you cant sell it seems like a pretty old argument to be having..
In general, i think its safe to say that the book left me disappointed, and a little bit afraid that somewhere decision makers could be forming an opinion on an entire industry based on ~250 words dedicated to a topic that deserves much more thought..
At [DeepSec] last year i had the pleasure of hearing Ivan Krsti? speak. While some of his arguments had (small) holes in them (which the audience were quick to pounce on), he raised the ugly fact that people like me like to ignore.. That some of us spend a lot more time thinking of elaborate ways to break stuff than we do designing less breakable stuff..
I think for most security "breakers" its an argument that sometimes hits hard, and makes you wonder if you should be refocusing your efforts..
It seems, he has just taken a position at [Apple]
We recently wrote a paper contrasting the built in memory protection mechanisms on OSX and its windows counterparts, and concluded the paper with the following lines:
"It can be postulated that OS X currently sits in an unusual niche, staying off the radar of server-attackers while below the threshold to make it an attractive target for attackers wishing to capture large volumes of desktop computers (for botnets or similar activities). Apple would be well advised to make good use of their time in this niche to learn from the mistakes made by those before them, because as their market share steadily rises, they steadily inch closer to moving out of this protected space.... .. We hope that Apple is able to make the necessary improvements before it too is forced into altering its views on generic OS protection mechanisms through the media frenzy that follows public security breaches."
It would seem like with a move like this, Apple are thinking these thoughts too..