Research

This is a corporate news post, so skip it if all you want is our usual snarky security analysis. For the first time since starting Securosis we are increasing our prices. Yes, it has been over seven years without any change in pricing for our services. The new prices are only a modest bump, and also streamlined to remove the uncertainty of travel expenses on engagements. Call it ego, but we think we are a heck of a bargain. This only affects speaking/strategy days and retainers. Papers, Securosis Project Accelerator workshops, and one-off projects aren’t changing. Strategy day pricing stays the same at $6,000, but we are adding in $1,000 for travel expenses and will no longer bill travel separately (total of $7,000 for a strategy day or speaking engagement which involves travel). Webcasts stay the same, at $5,000 if we don’t need to travel. Our retainer rates are increasing slightly, around $2-3K each, with $2,000 also being added to our Platinum plan to cover the travel for the two included strategy days: $10K for Silver. $15K for Gold. $25K for Platinum. The new pricing goes into effect immediately for all new clients and renewals. As a reminder, for our papers we offer licenses, not sponsorship, so nothing has changed there. Securosis Project Accelerators (our focused end-user workshops for SaaS providers, enterprise cloud security, security management, network security, and database/big data security) are still $10,000. We do have some other workshops in the… works for next year, so if you are interested in another topic just ask. If you have any other questions, just go ahead and email. Service levels remain the same. You can only blame yourselves for keeping us so darn busy. Share:

Rich here. I only consistently read comic books for a relatively short period of my life. I always enjoyed them as a kid but didn’t really collect them until sometime around high school. Before that I didn’t have the money to buy them month to month. I kept up a little in college, but I probably had less free capital as a freshman than in elementary school. Gas money and cheap dates add up crazy fast. Much to my surprise, at the ripe old age of forty-something, I find myself back in the world of comics. It all started thanks to my kids and Netflix. Netflix has quite the back catalog of animated shows, including my all-time favorite, Spider-Man and His Amazing Friends. You know: Iceman and Firestar. I really loved that show as a kid, and from age three to four it was my middle daughter’s absolute favorite. Better yet, my kids also found Super Hero Squad; a weird and wonderful stylized comedy take on Marvel comics that ran for two seasons. It was one of those rare shows loaded with jokes targeting adults while also appealing to kids. It hooked both my girls, who then moved on to the more serious Avengers Assemble, which covered a bunch of the major comics events – including Secret Invasion, which ran as a season-long story arc. My girls love all the comics characters and stories. Mostly Marvel, which is what I know, but you can’t really avoid DC. Especially Wonder Woman. Their favorite race is the Super Hero Run where we all dress in costumes and run a 5K (I run, they ride in the Helicarrier, which civilians call a “jog stroller”). When it comes to ComiCon, my oldest will gut me with a Barbie if I don’t take her. The there are the movies. The kids are too young to see them all (mostly just Avengers), but I am stunned that the biggest movies today are all expressions of my childhood dreams. Good comic book movies? With plot lines that extend a decade or more? And make a metric ton of cash? Yes, decades. In case you hadn’t heard, Disney/Marvel announced their lineup through 2019. 2-3 films per year, with interlocking television shows on ABC and Netflix, all leading to a 2-film version of the Infinity Wars. My daughter wasn’t born when Iron Man came out, and she will be 10 when the final Avengers (announced so far) is released. Which is why I am back on the comics. Because I am **Dad*, and while I may screw up everything else, I will sure as hell make sure I can explain who the Skrull are, and why Thanos wants the Infinity Gems. I am even learning more about the Flash, and please forgive me, Aquaman. There are few things as awesome as sharing what you love with your kids, and them sharing it right back. I didn’t force this on my kids – they discovered comics on their own, and I merely encouraged their exploration. The exact same thing is happening with Star Wars, and in a year I will get to take my kids to see the first new film with Luke, Leia, and Han since I was a kid. My oldest will even be the same age I was when my father took me to Star Wars for the first time. No, those aren’t tears. I have allergies. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in SC Magazine on Apple Security. Adrian will be discussing Enterprise App Security on the 19th. Webcast with Intel/Mashery November 18th on Data Centric Security. Favorite Securosis Posts Mike Rothman: Friday Summary: Halloween. Adrian and Emily get (yet) another dog. 😉 Rich: We are still low on posts, so I will leave it at that and tell you to read all of them this week 🙂 Other Securosis Posts Building an Enterprise Application Security Program: Security Gaps. Incite 11/5/2014: Be Like Water. Monitoring the Hybrid Cloud: Evolving to the CloudSOC [New Series]. Favorite Outside Posts Mike Rothman: Don’t Get Old. I like a lot of the stuff Daniel Miessler writes. I don’t like the term ‘old’ in this case because that implies age. I think he is talking more about being ‘stuck’, which isn’t really a matter of age. Rich: How an Agile Development Process Fits into the Security User Story. This is something I continue to struggle with as I dig deeper into Agile and DevOps. There is definitely room for more research into how to integrate security into user stories, and tying that to threat modeling. Maybe a project I should take up over the holidays. Adrian Lane: Facebook, Google, and the Rise of Open Source Security Software. It’s interesting that Facebook is building this in-house. And contributing to the open source community. But remember they bought PrivateCore last year too. So the focus on examining in-memory processes and protecting memory indicates their feelings on security. Oh, and Rich is quoted in this too! Research Reports and Presentations Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Top News and Posts FBI and Homeland Security shut down Silk Road 2, arrest alleged operator Apple comments on ‘Wirelurker’ malware, infected apps already blocked Accuvant and FishNet Security merging. That’s one BIG security VAR/services company. NSA Director Says Agency Shares Vast Majority of Bugs it Finds. They have said a lot of things lately – hopefully this one is true. Share:

I realize I have been slacking off posting here at Securosis, but thanks to a string of big event thingies, I thought I should link to a bunch of recent Apple security and privacy articles I posted over at TidBITS (mostly) and Macworld. I do probably need to write up the bit where local apps that are iCloud enabled seem to save document drafts on iCloud once you start writing, as opposed to when you save the documents in iCloud. This means any open drafts, in many text editors, load data into the cloud even if you only want to save them locally. Apple states they remove this data once you save the file to your local drive, but it is a bizarre design decision from a company that has made so many security and privacy improvements recently. So, um, don’t open up a TextEdit window and paste your temporary (or permanent!) passwords in it, unless you save the file someplace local first. Now on to the articles: First is an older Macworld article, Why Apple Really Cares About Your Privacy. This one predated Apple’s big public privacy push, and is the key piece that ties the rest of these together. Basically, Apple is using privacy against Google (and to a lesser degree certain other competitors) because the differences in business models makes it difficult for anyone else to differentiate on privacy to the same degree. This is an excellent alignment of economics to improve security and privacy, and I expect it to define a lot of what we see in the coming years. The next three articles show how Apple is following through on its privacy messaging within products: To start Apple dramatically improved the data security of iOS, much to the chagrin of folks in law enforcement. You likely read this all over the place, but this piece ties together a lot of context I didn’t see in other articles. Also, as an emergency responder, my arguments cannot be dismissed with the “if you only saw what we see” argument. I have seen more than my fair share of horrible things, including horrible things happening to children, so I get it. But that is no excuse to sacrifice fundamental civil liberties. Part of the problem is that some people in law enforcement are so used to getting access to whatever they need for an investigation that they see it as a legal right, and don’t understand that today’s technologies cannot include lawful access capabilities without deeply compromising security. Next up I wrote a piece detailing how Spotlight Suggestions handles privacy. While less of a big picture issue, this highlights the steps Apple is taking to harden their pro-privacy stance down to low-level feature design. Not that they always get it right – as illustrated by that iCloud issue. This next piece also relates to privacy, but is more about the business landscape Apple is working within. I discussed the real reason some merchants are blocking Apple Pay. Many of you understand the reasons merchants hate credit card companies (Hello, PCI!), and Apple is merely caught in the middle. For the record, I wish we would get half as many comments on Securosis articles as on this one! One last article ties the series up (even though it wasn’t the last one published) and serves as a good bookend to the privacy piece: The last piece is the most important for the long term. You Are Apple’s Greatest Security Challenge. Yes, Apple made mistakes with the celebrity photo thefts. Mistakes that those of us in cloud security are very familiar with. But, to their credit, they also deal with a scale and scope very few organizations need to consider. Including some key differences from Google, who has been doing a better job on this front. It is a very nuanced issue, and the decisions Apple makes here will have profound repercussions for the ecosystem. That’s it for now. It seems there is Apple-related security news every week. A lot of the headlines are total BS, like the article a few years back claiming a major security flaw in iPhones, when it was really a problem in every GSM phone on the planet. But that doesn’t get page views, and Apple security has become the “if it bleeds, it leads” of the tech world. Share:

Adrian is out, so Rich and Mike cover the latest Amazon Web Services news as their big re:Invent conference closes in. We start with the new Frankfurt datacenter, and how a court case involving Microsoft could kill off the future of all US-based cloud companies (it’s always the little things). Then we discuss directory services in the cloud, and how this indicates increasing cloud adoption and maturity at a pace we really haven’t ever seen before. The audio-only version is up too. Share:

Rich here. Last night I arrived home around 11pm from the totally awesome SecTor conference in Toronto. It took about 11 hours to wend my way home through the air system, which has a certain beauty. Yeah, I took it to 11. Before that I was home for a couple days, during one of which we took the kids to the local aquarium-in-the-outlet-mall to meet the Octonauts. Yes, we have one of those. Yes, if your kids are of a certain age, they know the Octonauts. And yes, the Octonauts have a totally awesome Star Trek TOS vibe, and I weirdly learn cool stuff – like how freaky vampire squids are – from watching it. I won’t link – I want you to have the pleasure of searching for “vampire squid” and then not sleeping. Before that I was in Amsterdam for 5 days. With my wife but without kids. I spent two of those days teaching the cloud security class for Black Hat, and the two free days touring around with her. Amsterdam reminds me of New Orleans in spots, which means it’s fun, and then it’s smelly. I have never been into the hedonistic stuff but I love cool historical cities. Especially without the kids. Assuming they have beer. Before that is a blur; it probably involved airplanes. Next week I head to Houston for Camp DevOps. I really like those events – so much so that I will spend 6 hours on a plane for what is normally an under-2-hour flight. One problem with traveling so much is that I struggle to find time to set up the next trip, so I got hammered with insane prices. I am unwilling to spend over $1K to fly from Phoenix to Houston, so I got a middle seat on Delta, routed through Salt Lake and Atlanta. Yay team. After that, I can’t talk about it, but the week after that is Amazon re:Invent. I’m not speaking there, but even if you use other cloud providers re:Invent is a must-attend event. Okay, it helps if you use AWS, but still, there is a ton of great info, some of it generalized. So there you have it. I am wicked jetlagged from too many time zones in too short a time, but when you work for yourself you can’t gripe too much about being busy. And, you know, 5 days in Amsterdam with my wife & my kids, so I should really just shut up and not complain. On a different note, you may have noticed some weirdness with our site recently. We had a conflict between our super-secure hosting architecture and an underlying component update we couldn’t totally nail down. It got so bad we moved to a slightly-less-secure host temporarily, which fixed the problem. I am actually rearchitecting the entire deployment (with our developer contractors) to take advantage of all the cloud security and DevOps research I have been working on, but that move will take a little time. We apologize sincerely, and at some point I will provide a more detailed writeup. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences eWeek covered Rich’s talk on DevOps at SecTor. Their writeup was great and really captured the core of the talk. eSecurity Planet covered the SecTor Fail Panel. That one also had Mr. Lewis and Mr. Arlen. Rich wrote up Spotlight Suggestions privacy for TidBITS. I guess this is why I didn’t post much on our own site. Need to work on that. Favorite Securosis Posts Adrian: Running Man. Mike. Running. Running distance !?! I … {head explode}. Rich: I guess I need to kneecap Mike. He’s stealing my thunder. I’ve done some half marathons, and no f###### way I will let him beat me to doing a marathon. Other Securosis Posts Hindsight is 20/20. Favorite Outside Posts Adrian: NSA Tech Director Explains Snowden Docs. I don’t know when this was published but it’s fascinating. I usually suspect disinformation attempts but this seems genuine. Mike: 6 Buddhist Principles That Will Help You Be A Better Boss. Yeah, I’m pimping some more mindfulness stuff. But these are good things to think about, regardless of how much time you spend being mindful… Research Reports and Presentations Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Top News and Posts Updated Windows FTDI Drivers bricking chips Schneier on Crypto Wars II. Google Launches 2FA as part of FIDO Alliance NAT-PMP vuln puts 1.2 million routers at risk. Share:

Writing is an oddly physical act. Technically you are just sitting there, clanking away on the keyboard, while your bottom loses circulation and gets sore. (Maybe I need a new chair.) But keeping your brain running at the right tempo for effective writing involves a complicated dance of nutrition, sleep, physical movement, and environmental management. The past few days I have been cranking through some projects, writing one or two major pieces a day. While sometimes the words flow, this run was more the molasses sort. I never seemed to maintain the right combination of sleep, caffeine, food, and activity to hammer through the content effectively. But deadlines are deadlines so I pushed through as best I could. Take today, for example. I felt better than any other morning this week, so I ran to a coffee shop and carefully managed my food-to-caffeine ration in an effort to maintain a productivity-enhancing caffeine buzz. Too much and I can’t focus. Too little and I… can’t focus. I did manage to keep it going for a few hours and finished one deliverable, but then it was time for lunch. If I didn’t eat I’d crash. But I knew once I did, I’d crash in a different way. Lose/lose situation. So I ate, then had more coffee, then wasted an hour before I could write again. But at that point it was mid-afternoon, when I tend to be at my worst. Normally I’d go work out to clear the head, but that wasn’t an option. So I muscled through. As a result, my 600-800 word piece is now clocking in at 1,800 words, and I cannot figure out whether it’s better than what I mapped out in my head last night. I knew I should have written it right then and there. And 1,800 words takes a certain amount of time, no matter how fast your write. Leaving me at 6pm to write this summary sitting on the floor, watching Peppa Pig with my two youngest kids, barely able to hold my head up, but knowing that if I don’t go for a run when my wife gets home I won’t sleep well tonight, and will be even less productive tomorrow. Yes, there are worse work-related problems out there. I have held far more outwardly physical jobs, some putting me at great physical risk. But never doubt that writing isn’t physical. And unlike rescue or manual labor, you don’t get to release any of the stress through movement. I am not thrilled with most of what I wrote this week. I’m hoping that’s just my usual self-criticism, but nothing really came out as I intended, and that is a direct result of being unable to properly manage my physical state to optimize my focus. Sounds stilly, but in the end I might have blown an article because a cat decided to sleep on my face the other night. In unrelated news, the rest of the Securosis team is completely out this week, so the rest of this summary is slimmed down. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian will be presenting Pragmatic WAF Management October 15. Favorite Securosis Posts Adrian Lane: Deployment Pipelines and DevOps. Rich does a great job tying the series together and showing how and where DevOps is making development and security more Agile. Other Securosis Posts Firestarter: Hulk bash. Like I said: everyone is out. Favorite Outside Posts A special note first – Brian Krebs is releasing his book, Spam Nation. I haven’t read it, but I guarantee you it will be good. Brian knows more than anyone about the computer underground. Well, more than anyone who can talk about it without getting shot. I mean, he probably won’t get shot. Er, I hope he doesn’t get shot. Adrian Lane: A State of Xen – Chaos Monkey & Cassandra. Keeping a 2,600-node Cassandra cluster up and running is hard. Keeping it fully functional while 10% of the cluster is rebooted is fracking astounding! Chaos Monkey is one of the few truly Rugged approaches to software development I have seen. Rich: Have most analysts completely given up doing “research”? An interesting take, especially because Securosis is quite profitable, and doesn’t do a single thing they talk about. Then again I’m not sure you could scale us. Research Reports and Presentations Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Top News and Posts The Horror of a ‘Secure Golden Key’. Hackers’ Attack Cracked 10 Financial Firms in Major Assault BadUSB ‘Patch’ Skirts More Effective Options Share:

Our last post reviewed key tools to conduct security tests in the development process, and before that we discussed big picture process adjustments to accommodate security testing, but didn’t fully how to integrate. Agile itself is in the middle of a major disruptive evolution, transforming into a new variant called DevOps, bringing significant long-term implications which are beneficial to security. The evolution of development security and Agile are closely tied together, so we can start by specifying how to integrate into the deployment pipeline, then discuss the implications of DevOps. Understanding the Deployment Pipeline The best way to integrate security testing into the development process is by integrating with the deployment pipeline. This is the series of tools an organization uses to take developed code from the brain of a developer into the hands of a customer. While products vary greatly, the toolchains themselves are relatively consistent, although not all organizations use all components. Integrated Development Environment (IDE): The IDE is where developers write code. It typically consists of a source code editor (a text editor), a compiler or an interpreter, a debugger, and other tools to help the programmer write code and build applications (such as a user interface editor, code snippet library, version control browser, etc.). Issue Tracker: A tracker is basically a project management tool designed to integrate directly into the development process. User stories are entered directly, broken down into features, and broken down again then specific developer tasks/assignments. Detected bugs also go into the issue tracker. This is the central tool for tracking the status of the development project – from earliest concepts, to updates, to production bugs. Version Control System/Source Code Management: Managing constantly changing code for even a small application is challenging. Source code is mostly a bunch of text files. And we mean a lot of files, which may be worked on by teams of tens, hundreds, or thousands of developers. The version control system/source code management tool keeps track of all changes and handles checkout, checkin, branching, forking, and otherwise keeping the code consistent and manageable. Whichever tool is used, this is typically referred to as the source code repository, or repo for short. Build Automation: Automation tools convert the text of source code into compiled applications. Most modern applications include many components which need to be compiled, integrated, and linked in the correct order. A build automation tool handles both simple and complex scenarios, according to scripts created by developers. Continuous Integration (CI) Server: A CI server is the next iteration of build automation. It connects to the source code repository and, based on rules, automatically integrates and compiles code as it is committed. Rather than manually running a build automation tool, the CI server grabs code, creates a build, and runs automated testing automatically when triggered – such as when a developer commits code from an IDE. CI servers can also automate the deployment process, pushing updated code onto production systems. There are an unlimited range of possible deployment pipelines, and the pipeline is often actually a series of manual processes. But the broad steps are: The product owner enters requirements for a feature into the issue tracker. The product owner or someone else on the development team (such as the program manager) breaks the user story and features down into a set of developer assignments, which are then added to the backlog. The program manager assigns specific tasks to developers. A developer checks out the latest code, writes/edits in an IDE, tests and debugs locally, and then commits it to the source code repository using the version control system. The developer might for existing for independent development and testing, depending on the nature of the feature. The build automation tool compiles the code into the main application and may perform automated testing. The compiled product is then sent to QA/testing and eventually to operations to push into production. If something breaks, that is marked as a bug in the issue tracker. If the organization uses continuous integration the code will be automatically compiled, integrated, and tested using the CI server. It may be pushed into deployment or handed off for additional manual testing, such as user acceptance testing. Again, if something breaks that becomes a bug in the issue tracker, probably automatically. Not every organization follows even this general process, but just about everyone running Agile uses some variation of it. Integrating Security If you map our security toolchain to the deployment pipeline there are clear opportunities for integration. The ones we most commonly see are: Security manages security issues and bugs in the issue tracker. Security features are often entered as user stories or feature requirements, in cooperation with the product owner or program manager. Security sensitive bugs are tagged as security issues. In some cases security teams monitor the issue tracker to help identify potential vulnerabilities that might have been entered as simple bug reports. Static analysis is integrated in the IDE, build automation tool, or CI server. Sometimes all of the above. For example when a developer commits code locally it can undergo static analysis, with issues highlighted back in the IDE for easy identification and remediation. Static analysis may also be triggered when code is committed to the source code repository. Dynamic analysis is also typically integrated at the build automation or CI server, using tests defined by security. Other security tests, such as unit, component, and regression testing, are also often best integrated at the build or CI server. Vulnerability analysis may be automated if the organization uses a CI server, but otherwise is often a manual or periodic process. Any problems discovered by the testing tools generate entries in the issue tracker, just like any other bugs. Ideally security needs to sign off on any unremediated security bugs before release. Security and DevOps There is no single definition of DevOps, but essentially it means deeper integration of development and operations in the software deployment process. A better way to phrase it is

Mike, Adrian, and I start off a little rough around the edges, but eventually get to the point. Travel is taking its toll so we won’t be able to keep our usual weekly schedule, but we will stay as close as possible – until I run off to Amsterdam for a week, for Black Hat Europe. We catch up on the inane for a few minutes, before jumping into a discussion of the bash vulnerability and disclosure debacle. We agree it is often valuable to analyze an event after the initial shock waves (See what I did there? Shellshock? Shock waves?). Today we focus on the deeper implications and how the heck a disclosure could be so bungled. Plus a little advice on where to focus your patching efforts. The audio-only version is up too. Share:

Update: Amazon published some details. Less than 10% of AWS systems are affected, and the vulnerability will be disclosed October 1st. As suspected this is about Xen – not the bash vulnerability. Yesterday I received notice that Amazon Web Services is force rebooting one of my instances. Then more emails started rolling in, and it looks like many (or all) of them will be rebooted during a single maintenance window. It has been a few years since this happened, and the reason ties into how AWS updates the servers your instances run on. We actually teach this in our cloud security training class, including how to architect your own cloud so you might not have to do the same thing – with, of course, many caveats. My initial assumption was application of a quiet security patch, and that looks dead on: From @ClipperChip via Matt Green on Twitter: Amazon rebooting all AWS instances (https://t.co/xg2XoXDdEe) + an undisclosed advisory on http://t.co/PdLqk8qXSE http://t.co/Fo1beT7xrN 🙂 And here is what looks like that vuln: XSA-108 | 2014-10-01 12:00 | none (yet) assigned | (Prereleased, but embargoed) How AWS updates servers Amazon uses a modified version of the Xen hypervisor. Our understanding of their architecture indicates they do not support live migration. Live migration, available under VMware as vMotion, allows you to move a running virtual machine from one physical host to another without shutting it down. When you build a cloud, host servers consist of (at least) a hypervisor with management and connectivity components. Sometimes, as with OpenStack, you even have a usable operating system. All these components need to be updated periodically. Some updates require rebooting the host server. To update the hypervisor you typically need to shut down the virtual machines (instances) running on top of it. There are two common ways to manage these updates to reduce downtime: Update a host without any virtual machines running on it, then live migrate instances from a vulnerable host to a patched one. Then update the vulnerable host once all its instances are running elsewhere. If you cannot live migrate, do the same thing by shutting down and restarting the instances. If you built your cloud properly you can set a rule in the controller to not launch instances on the vulnerable host while preparing to reboot. Then the simple act of shutting down and relaunching the instance will automatically migrate it to a patched host. In case you didn’t realize, every time you shut an instance down and start it again you likely move to a new host server. That is just normal cloud automation at work. When AWS has a large security patch like this they cannot rely on all customers conveniently relaunching during the desired window, so they need to take a maintenance window and do it for all affected users. Simple reboots generally do not trigger a host migration because a reboot doesn’t actually shutdown the entire instance – the virtual machine just executes the operating system shutdown and reboot procedures, but the instance is never destroyed or completely halted. Many people don’t architect resilient servers to handle reboots, which is the problem. Or the reboots require some manual testing. This is why I am a massive fan of DevOps – its techniques provide extra resiliency for situations like this – but that’s for another post. Our cloud security training covers this, and one critical security requirement when building a private (or public) cloud is to understand your patching requirements and their implications for instances. For example if you architect for live migration you can reduce required reboots, by accepting different implications and constraints. Share:

Updated: I made a mistake and gave Akamai credit. Stephane doesn’t work for them – I misread the post. Fixed. Critical update: Red Hat confirmed their patch is incomplete, and patched bash is still exploitable. The technical term is “cluster fuck”. Anything you patch now will need to be repatched later. For critical systems consider the workaround in their post. For everything else, wait until your vendors release complete patches. Earlier today details of a vulnerability in the UNIX/Linux/OS X tool bash, discovered by Stephane Chazelas, became public with a disclosure and patch by Red Hat. It is called Shellshock, and it might be worse than Heartbleed. Most of you reading this are likely extremely familiar with bash, but in case you aren’t it is the most popular command-line shell program in the UNIX world, installed on pretty much anything and everything. From Red Hat: Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. You might be thinking that someone needs to log in before they can ever reach bash, so no big deal, right? Wrong. Access to bash is embedded in a ton of applications. From CGI scripts running on Apache web sites to all sorts of random applications. Here is the short explanation of why this is so bad, and why we will likely be dealing with it for years: bash is embedded and accessed in so many ways that we cannot fully understand its depth of use. Many systems you would never think of as having a command line use bash to run other programs. I have used it myself, a bunch, in programs I have written – and I barely code. We cannot possibly understand all the ways an attacker could interact with bash to exploit this vulnerability. As Rob Graham has discovered, this is likely wormable. That places it into Code Red/Nimbda territory. A workable bug that can exploit public web servers is scary. We don’t know for sure, Rob doesn’t know for sure, but it looks very very possible. Potential worms are like staring at the smoking volcano while the earthquakes stir your martini – they aren’t the sort of thing you can wait for definitive proof on before taking seriously. There are rumors the patch may be incomplete. There is already a Metasploit module. Gee, thanks guys… you couldn’t give us a day? I strongly suggest keeping up with Rob’s analysis. There is really only one option: patch. It isn’t a fancy patch, but fragile systems could still suffer downtime. And you may need to re-patch if the original patch turns out to be faulty, which is always terrible. I will patch my systems and keep my ears open for any updates. Don’t trust any security vendor who claims they can block this. Patching is the only way to fix the core problem, which likely includes multiple exploit vectors. I will give bonus points to anyone who finds a vendor using Shellshock in their marketing, which then turns out to have a vulnerable product. Any security product based on UNIX/Linux is potentially vulnerable, although not necessarily exploitable. I suspect the Microsoft Security Response Center is very much enjoying their quiet evening. Share: