Research

I almost didn’t write this post since it’s about iOS, and I about defending iOS security too much. Not that I think I’m biased, but I worry about being misinterpreted as an apologetic defender (I’m not – Apple still has security issues they need to work on, but iOS is in really good shape these days). That said, this piece by Erika Morphy over at Forbes is so horribly written, poorly researched, and miscast, that I cannot help myself. It could have been written about other platforms and I would have the same reaction. I know hammering ill-informed press is like tilting at windmills, but every now and then a guy just needs to let loose. The press likes to sensationalize security, and sometimes with good reason. But articles like this juxtapose incorrect information and cherry-picked quotes to scare users needlessly. They are the local news of the Internet, and we shouldn’t give them a pass. This piece is an excellent example of poor writing, and the analysis of why it’s garbage is just as relevant for any sensationalistic piece, whatever the subject, that lands in front of us. First some factual corrections: Kaspersky Labs reports that the first malware to specifically target Google’s Android mobile operating system has been discovered. No. It’s the first targeted attack using Android they’ve seen, not the first to target Android. Big difference. iOS was found to be the most vulnerable in a report by SourceFire. Wrong. Those are historical vulnerabilities, not current vulnerabilities. Big difference. That’s like lumping all Windows vulnerabilities since Windows 1.0 together to say Windows 8 is the most vulnerable platform out there. And vulnerabilities don’t equate to exploits. Raw, historical vulnerability counts are effectively meaningless for evaluating security on any platform. It is the rate of zero-day exploits, not vulnerabilities, that has everyone’s panties in a bunch. These two worlds-smugly complacent Apple users and an iOS apparently riddled with vulnerabilities-will surely collide sooner or later, probably sooner. Do I need to address this? Really? A factually incorrect ad hominem attack? Look at the rise of adware aimed specifically at Macs, which has been rising since the beginning of the year Damn. My Ford Escape was recalled, so I had better assume my Ford Explorer is dangerous. Movie trailer! Media player! I would have thought Mac users to be smarter than that, being one of them myself. Well, I do suppose this helps prove a point, but probably not the one you were trying to make. Share:

Rapid7 reported this week on finding a ton of sensitive information in Amazon S3. They scanned public buckets (Amazon S3 containers) by enumerating names, and concluded that 1 in 6 had sensitive information in them. People cried, “Amazon should do something about this!!” S3 buckets are private by default. You have to make them public. Deliberately. If you leave a bucket public, you eventually get an email like this (I have a public bucket we use for CCSK training): Dear Amazon S3 Customer, We’ve noticed that your Amazon S3 account has a bucket with permissions that allow an anonymous requester to perform READ operations, enumerating the contents of the bucket. Bucket READ access is sometimes referred to as “list” access. Amazon S3 buckets are private by default. These S3 buckets grant anonymous list access: REDACTED Periodically we send security notifications to all of our customers with buckets allowing anonymous list access. We typically recommend against anonymous list access. We know there are good reasons why you may choose to allow anonymous list access. This can simplify development against S3. However, some tools and scripts have emerged which scan services like Amazon S3 and enumerate objects in publicly listable buckets. With anonymous list access enabled, anyone (including users of these tools) may obtain a complete list of your bucket content. As a result of calls against your bucket, you may see unintended charges in your account. We’ve included specific steps to remove anonymous list access as well as further information about bucket access considerations. Use the following steps to immediately remove anonymous access to your bucket. Go to the Amazon S3 console at https://console.aws.amazon.com/s3/home. Right-click on the bucket and click Properties. In the Properties pane, click the Permissions tab. The tab shows a list of grants, one row per grant, in the bucket ACL. Each row identifies the grantee and the permissions granted. Select the row that grants permission to everyone. “Everyone” refers to the Amazon S3 All User group. Uncheck all the permissions granted to everyone (or click x to delete the row). This removes all permissions granted to public. Click Save to save the ACL. Learn more about protecting your bucket by reading the AWS article on Amazon S3 Bucket Public Access Considerations at http://aws.amazon.com/articles/5050. This article includes alternative options if you need methods for unauthenticated end users to read and write content, as well as detailed information on configuring bucket access for website hosting if you are hosting your site on Amazon S3. It also describes how you can use Bucket Policies if you would like to specify more granular access control on your bucket. Bucket Policies enable you to add or deny permissions across all or a subset of objects within a bucket. You can use wildcarding to define sets of objects within a bucket against which policy is applied, more specifically control the allowed operations, and even control access based on request properties. For further information on managing permissions on Amazon S3, please visit the Amazon S3 Developer Guide at http://docs.amazonwebservices.com/AmazonS3/latest/dev/Welcome.html for topics on Using ACLs and Using Bucket Policies. Finally, we encourage you to monitor use of your buckets by setting up Server Access Logging. This is described in our Developer Guide under Setting Up Server Access Logging. Sincerely, The Amazon S3 Team My scientific conclusion? 1 in 6 Amazon S3 users can’t read, or don’t care. Seriously, what do you want Amazon to do? Drive to your house if you mess up and then ignore their warnings? Share:

Sam Biddle at Gizmodo says: This guy, Prince said, could back up CloudFlare’s claims. This really was Web Dresden, or something. After an inquiry, I was ready to face vindication. Instead, I received this note from a spokesperson for NTT, one of the backbone operators of the Internet: “Hey Sam, nice to hear from you. I’m afraid that we don’t have anything we can share that substantiates global effects. I’m sure you read the same 300gbps figure that I did, and while that’s a massive amount of bandwidth to a single enterprise or service provider, data on global capacities from sources like TeleGeography show lit capacities in the tbps range in most all regions of the world. I side with you questioning if it shook the global internet. Chris” Bad for SpamHaus, but unnoticeable to everyone else. Share:

Infrastructure as a Service storage can be insanely complex when you include operational and performance requirements. First you need to create a resource pool, which might itself be a pool of virtualized and abstracted storage, and then you need to tie it all together with orchestration to support the dynamic requirements of the cloud – such as moving running virtual machines between servers, instantly snapshotting multi-terabyte virtual drives, and other insanity. For security we don’t need to know all the ins and outs of cloud storage, but we do need to understand the high-level architecture and how it affects our security controls. And keep in mind that the implementations of our generic architecture vary widely between different public and private cloud platforms. Public clouds are roughly equivalent to provider-class private clouds, except that they are designed to support multiple external tenants. We will focus on private cloud storage, with the understanding that public clouds are about the same except that customers have less control. IaaS Storage Overview Here’s a diagram to work through: At the lowest level is physical storage. This can be nearly anything that satisfies the cloud’s performance and storage requirements. It might be commodity hard drives in commodity rack servers. It could be high-performance SSD drives in high-end specialized datacenter servers. But really it could be nearly any storage appliance/system you can think of. Some physical storage is generally pooled by a virtual storage controller, like a SAN. This is extremely common in production clouds but isn’t limited to traditional SAN. Basically, as long as you can connect it to the cloud storage manager, you can use it. You could even dedicate certain LUNs from a larger shared SAN to cloud, while using other LUNs for non-cloud applications. If you aren’t a storage person just remember there might be some sort of controller/server above the hard drives, outside your cloud servers, that needs to be secured. That’s the base storage. On top of that we then build out: Object Storage Object storage controllers (also called managers) connect to assigned physical or virtual storage and manage orchestration and connectivity. Above this level they communicate using APIs. Some deployments include object storage connectivity software running on distributed commodity servers to tie the servers’ hard drives into the storage pool. Object storage controllers create virtual containers (also called buckets) which are assigned to cloud users. A container is a pool of storage in which you can place objects (files). Every container stores each bit in multiple locations. This is called data dispersion, and we will talk more about it in a moment. Object storage is something of a cross between a database and a file share. You move files into and out of it; but instead of being managed by a file system you manage it with APIs, at an abstracted layer above whatever file systems actually store the data. Object storage is accessed via APIs (almost always RESTful HTTP APIs) rather than classic network file protocols, which offers tremendous flexibility for integration into different applications and services. Object storage includes logic below the user-accessible layer for features such as quotas, access control, and redundancy management. Volume Storage Volume storage controllers (also called managers) connect to assigned physical (or virtual) storage and manage orchestration and connectivity. Above this level they communicate using APIs. The volume controller creates volumes on request and assigns them to specific cloud instances. To use traditional virtualization language, it creates a virtual hard drive and connects it to a virtual machine. Data dispersion is often used to provide redundancy and robustness. A volume is essentially a persistent virtual hard drive. It can be of any size supported by the cloud platform and underlying resources, and a volume assigned to a virtual machine exists until it is destroyed (note that tearing down an instance often automatically also returns the associated volume storage back to the free storage pool). Physical servers run hypervisors and cloud connectivity software to tie them into the compute resource pool. This is where instances (virtual machines) run. These servers typically have local hard drives which can be assigned to the volume controller to expand the storage pool, or used locally for non-persistent storage. We call this ‘ephemeral’ storage, and it’s great for swap files and other higher-performance operations that don’t require the resiliency of a full storage volume. If your cloud uses this model, the cloud management software places swap on these local drives. When you move or shut down your instance this data is always lost, although it might be recoverable until overwritten. We like to discuss volumes as if they were virtual hard drives, but they are a bit more complex. Volumes may be distributed and data dispersed across multiple physical drives. There are also implications which we will consider later for considering volumes in the context of your cloud, and how they interact with object storage and things like snapshots and live migrations. How object and volume storage interact Most clouds include both object and volume storage, even if object storage isn’t available directly to users. Here are the key examples: A snapshot is a near-instant backup of a volume that is moved into object storage. The underlying technology varies widely and is too complex for my feeble analyst brain, but a snapshot effectively copies a complete set of the storage blocks in your volume, into a file stored in an object container which has been assigned to snapshots. Since every block in your volume is likely stored in multiple physical locations, typically 3 or more times, taking a snapshot tells the volume controller to copy a complete set of blocks over to object storage. The operation can take a while but it looks instantaneous because the snapshot accurately reflects the state of the volume at that point in time, while the volume is stil fully usable – running on another set of blocks while the snapshot is moved over (this is a (major oversimplification of something that makes my head hurt). Images are pre-defined storage volumes in object storage, which contain operating systems or other virtual hard drives used to launch instances. An

Infrastructure as a Service (IaaS) is often thought of as merely as a more efficient (outsourced) version of our traditional infrastructure. On the surface you still manage things that look like simple virtualized networks, computers, and storage. You ‘boot’ computers (launch instances), assign IP addresses, and connect (virtual) hard drives. But while the presentation of IaaS resembles traditional infrastructure, the reality underneath is anything but business as usual. For both public and private clouds, the architecture of the physical infrastructure that comprises the cloud, as well as the connectivity and abstraction components used to provide it, dramatically alter how we need to manage our security. It isn’t that the cloud is more or less secure than traditional infrastructure, but it is very different. Protecting data in the cloud is a top priorities of most organizations as they adopt cloud computing. In some cases this is due to moving onto a public cloud, with the standard concerns any time you allow someone else to access or hold your data. But private clouds also comes with the same risk changes, even if they don’t trigger the same gut reaction as outsourcing. This series will dig into protecting data stored in and used with Infrastructure as a Service. There are a few options, but we will show why in the end the answer almost always comes down to encryption … with some twists. What Is IaaS Storage? Infrastructure as a Service includes two primary storage models: Object storage is a file repository. This is higher-latency storage with lower performance requirements, which stores individual files (‘objects’). Examples include Amazon S3 and RackSpace Cloud Files for public clouds, and OpenStack Swift for private clouds. Object storage is accessed using an API, rather than a network file share, which opens up a wealth of new uses – but you can layer a file browsing interface on top of the API. Volume storage is effectively a virtual hard drive. These higher-performing volumes attach to virtual machines and are used just like a physical hard drive or array. Examples include VMWare VMFS, Amazon EBS, RackSpace RAID, and OpenStack Cinder. To (over)simplify, object storage replaces file servers and volume storage is a substitute for hard drives. In both cases you take a storage pool – which could be anything from a SAN to hard drives on individual servers – and add abstraction and management layers. There are other kinds of cloud storage such as cloud databases, but they fall under either Platform as a Service (PaaS) or Software as a Service (SaaS). For this IaaS series, we will stick to object and volume storage. Due to the design of Infrastructure as a Service, data storage is very different than keeping it in ‘regular’ file repositories and databases. There are substantial advantages such as resilience, elasticity, and flexibility; as well as new risks in areas such as management, transparency, segregation, and isolation. How IaaS Is Different We will cover details in the next post, but at a high level: In private cloud infrastructure our data is co-mingled extensively, and the physical locations of data are rarely as transparent as before. You can’t point to a single server and say, “there are my credit card numbers” any more. Often you can set things up that way, at the cost of all the normal benefits of cloud computing. Any given piece of data may be located in multiple physical systems or even storage types. Part of the file might be on a server, some of it in a SAN, and the rest in a NAS, but it all looks like it’s in a single place. Your sensitive customer data might be on the same hard drive that, through layers of abstraction, also supports an unsecured development system. Plan incorrectly and your entire infrastructure can land in your PCI assessment scope – all mixed together at a physical level. To top it off, your infrastructure is now managed by a web-based API that, if not properly secured could allow someone on the other side of the planet unfettered access to your (virtual) data center. We are huge proponents of cloud computing, but we are also security guys. It is our job to help you identify and mitigate risks, and we’ll let infrastructure experts tell you why you should use IaaS in the first place. Public cloud infrastructure brings the same risks with additional complications because you no longer control ‘your’ infrastructure, your data might be mingled with anyone else on the Internet, and you lose most or all visibility into who (at your provider) can access your data. Whether private or public, you need to adjust security controls to manage the full abstraction of resources. You cannot rely on knowing where network cables plug into boxes anymore. Here are a few examples of how life changes: In private clouds, any virtual system that connects to any physical system holding credit card account numbers is within the scope of a PCI assessment. So if you run an application that collects credit cards in the same cloud as one that holds unsecured internal business systems, both are within assessment scope. Unless you take precautions we will talk about later. In public clouds an administrator at your cloud provider could access your virtual hard drives. This would violate all sorts of policies and contracts, but it is still technically quite possible. In most IaaS clouds a single command or API call can make an instant copy (snapshot) of an entire virtual hard drive, and then move it around your environment or make it public on the Internet. If your data is on the same hard drive as a criminal organization using the same cloud provider, and ‘their’ hardware is seized as part of an investigation, your data may be exposed. Yes, this has happened. It comes down to less visibility below the abstraction layer, and data from multiple tenants mixed on the same physical infrastructure. This is all manageable – it’s just different. Most of what we want to do, from a security standpoint, is use encryption and other techniques to either restore

MailChimp is offering a 10% discount to customers who enable 2-factor authentication. Impressive. Time to finish migrating our lists over to MailChimp (we only use them for the Friday Summary right now). We need to reward efforts like this. Share:

When writing about the flaw in Apple’s account recovery process last week, something set my spidey sense tingling. Something about it seemed different than other similar situations, even though exploitation was blocked quickly and the flaw fixed within about 8 hours. At first I wanted to blame The Verge for reporting on an unpatched flaw without getting a response from Apple. But I can’t, because the flaw was already public on the Internet, they didn’t link to it directly, and users were at active risk. Then I realized that it is the nature of cloud attacks and disclosures in general. With old-style software vulnerabilities when a flaw is disclosed, whatever the means, attackers need to find and target victims. Sometimes this is very easy and sometimes it’s hard, but attacks are distributed by nature. With a cloud provider flaw, especially against a SaaS provider, the nature of the target and flaw give attackers a centralized target. Full disclosure can be riskier for users of the service, depending on the degree of research or effort required to attack the service. All users are immediately at risk, all exploits are 0-days, and users may have no defensive recourse. This places new responsibilities on both cloud providers and security researchers. I suspect we will see this play out in some interesting ways over the next few years. And I am neither equating all cloud-based vulnerabilities, nor making a blanket statement on the morality of disclosure. I am just saying this smells different, and that’s worth thinking about. Share:

According to The Verge, someone discovered a way to take over Apple IDs using only the owner’s email address and date of birth. This appears to be an error exposed when they enabled 2-factor authentication, but as soon as it went public Apple disabled the iForgot feature and locked all accounts down. This seems to be one of those annoying cases where someone decided to disclose something in the press instead of just reporting it and getting it fixed. That’s really damn dangerous when cloud services are involved. I expect this to be resolved pretty quickly. Possibly before my bracket is blown to unrecoverable levels. We’ll update as we learn more … Share:

Galaxy Note II security flaw lets intruders gain full device access. Confirmed: iOS 6.1.3 Has Another Passcode Security Flaw The iOS one in particular is very limited, but I am continuously astounded by the creativity of some of these passcode flaws. Give me SQL injection or heap sprays any day… Share:

Microsoft confirms ‘high-profile’ employee Xbox Live accounts hacked Major vulnerability in EA’s Origin platform lets hackers overtake PCs Anyone surprised? Games made an estimated $25.1B in 2010 in the US alone. This is an industry under constant attack – just ask Sony. I’d love to learn more security lessons from them. Share: