350 likes | 440 Views
TechTalk Outside Looking In. By: Piotr T. Zbiegiel. Introduction. Attacks from outsiders. Other potential attack vectors outside the cloud. Risks attackers take in attempting to enumerate your environment. Potential vantage points attackers may take once they get inside.
E N D
TechTalkOutside Looking In By: Piotr T. Zbiegiel
Introduction • Attacks from outsiders. • Other potential attack vectors outside the cloud. • Risks attackers take in attempting to enumerate your environment. • Potential vantage points attackers may take once they get inside.
Attacking from the Outside • Attacks that you may consider simple or straightforward can take on nw dimensions in a virtualized environment. • The basics: Attacks from outside a cloud system. • Outsiders are only outsiders until the gain some knowledge that lets them become insiders. • From unknown -> known • The virtual environment can change the playing field here because that “knowledge” may be easier to gain in a virtualized environment.
HR Policies and Procedures • Your book mentions HR policies about VPNs and virtualization. • Does HR write these policies in your company?!? • But they do have a point: Security policies need to clearly define acceptable virtualization practices such as: • Segregating VMs with different security levels. • Utilizing strong encryption for communications. • Network isolation for management traffic. • Here the risk is unclear or lax security policies and procedures can put your virtualization environment at risk. • We’ll discuss this is greater depth in a later lecture based on the Winkler book.
Contractors – Temporary Insiders • Hiring contractors and otherwise outsourcing work is common today. • These workers may be pulled in to work for short periods of time. • They may be granted access to sensitive data assets. • Or systems they have access to may be situated near sensitive resources. • Add in the ephemeral nature of virtual machines and the contract employee may find themselves with the opportunity to abuse their access to steal sensitive data. • http://nakedsecurity.sophos.com/2012/08/29/toyota-says-it-was-hacked-by-ex-it-contractor-sensitive-information-stolen/
Friends and Family • It’s not what you know, it’s who you know. • People close enough to employees can get access to corporate assets intentionally or accidentally. • Spouses, children, roommates, friends. • Their activity would appear under the guise of the employee. • Usually accidental but what if it’s not? • What if a couple of your system admins are roommates and you have to lay one of them off?
Friends and Family cont’d • Once worked at a software company that offered broadband service to their software engineers that terminated in our datacenter! • Internet worms were all the rage at the time and having poorly secured home users with connections into your datacenter is not that great. • Our web proxy logs from these segments were interesting, to say the least. • A more recent version of this is mom or dad working at home using a VPN connection. Junior sits down to use their corporate laptop. • Web surfing • Bittorrent • Gaming • Never mind if junior actually gets the system infected downloading pirated software and then they VPN in.
Outsider -> Insider Countermeasures • A basic countermeasure here: Review Your Logs! • Audit logs can reveal strange activity or users. • Cloud providers weren’t good at providing logs in the past but it is getting better. • Amazon offers CloudTrail which provides an audit trail for API calls. This is a recently added feature. • Also, account audits are useful to validate user account and make sure they are legitimate.
Real Outsiders (who get in) • An attacker may come from the outside and compromise a server via a running service. • They gain a foothold on the system. • A reverse shell. • Admin access through privilege escalation perhaps. • Attacker sets up shop, installs a rootkit, etc. • What’s next?
Real Outsiders (who get in) cont’d • Typically the next step is to pivot to another internal system and take that over. • They will search the system for SSH keys (or password hashes on Windows for PTH) If that doesn’t get them useful authentication information… • They may trojan a service such as SSH to collect credentials. • And then they wait for administrators or other users to log in.
That’s not new! • But wait! That’s not a new attack. • This is true but a cloud system may be at higher risk here: • Tendency for virtual machines to be based on identical system images. • This means that any security vulnerability present in those system images will be propagated to every instance of that virtual machine. • The same goes for users and credentials. • This could mean that an attacker can compromise vast swaths of a virtualized environment with a single exploit or username and password combination!
Delegating Roles to Outsiders • Cloud systems features can also be risks • The self-service characteristic brings a new class of outsider • The novice user can deploy virtual machines in the cloud • All it takes is a credit card, after all. • But will that user know how to manage that virtual machine properly? • Automated policy and configuration management can address this risk but it is something you have to build yourself. • This was a risk identified for Magellan users.
Outsourcing is back! • This time we are not talking about contractors that your organization hires. • Instead we need to consider the employees of the cloud service provider. • Those employees may have behind-the-scenes access to your organization’s data assets and virtual machines. • There also may be the issue of foreign national employees at the CSP. • Depending on your regulatory or legal needs that may be an issue. • Many US government agencies have strict rules on foreign national access to agency systems and that includes those located in a cloud.
Other outsiders: Your SaaS Service • Services in the cloud can develop and evolve rapidly. • Your SaaS provider may utilize agile development processes which lead to frequent new releases. • Since there is no deployment to end users, SaaS products can be upgraded often. • As a customer you are along for the ride with no way to avoid the upgrades. • Without security considerations integrated into the development life cycle it could leave the SaaS vulnerable to compromise. • Which potentially puts your data at risk.
Other outsiders: Bespoke Solutions from you CSP • An organization may have a unique need to fulfill. • Cloud providers are used to providing more generally applicable solutions to their many customers. • Without in-depth knowledge of a customer’s business needs the CSP’s proposed solution may not be ideal. • While a CSP may be able to build a solution to works for the customer they may end up introducing risks or vulnerabilities that may not be immediately apparent to the provider or the customer.
Other outsiders: Continuity Risks • Virtualization allows us to hide the underlying complexity of the hardware. • But this may lead one to ignore the risks of catastrophic failure. • Virtualization technology can weather hardware failures by migrating virtual resources away from failed components. • But there is still a datacenter under that virtualization and catastrophes are still a risk: • Lightning hitting a transformer. • Severe network outage. • The best protection for these type of risk is old-school: build another site. http://aws.amazon.com/message/67457/
Other outsiders: Bad Patches • Another way into your environment may be via system patches. • Attackers can trojan an existing package and wait for admins to install the it on their systems. • Back in 2011 vsftpd had a backdoor introduced into its source code. • The package was available on the site for three days before it was noticed. • Oops! How many copies were downloaded and installed? • http://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-download-backdoored.html • We’ll be using this backdoor to break into a VM in a lab assignment.
Other outsiders: Certificates • Anyone ever see this when they try to SSH? • What do you do? @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 5d:5b:13:56:c6:ed:61:13:3e:cb:19:a1:81:ce:e6:1d. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/user/.ssh/known_hosts:1 RSA host key for ssh.server has changed and you have requested strict checking. Host key verification failed.
Other outsiders: Certificates cont’d • Certificates and encrypted communications do go a long way to protect data and transactions on the Internet • But PKI has its weaknesses: • If an attacker steals a CA’s signing key they can issue certificates that will be trusted by whatever systems trust that CA. • If a CA is more concerned with collecting their fee than validating requestor identities you may have a problem. • Breaking into a system and stealing its certificate and private key. • Hash collision attacks that give the attacker the ability to create fake certificates. • *cough* Government controlled CA *cough*
Other outsiders: Certificates cont’d • Let’s not forget the weakest link: Human nature • What to people tend to do here? • Click-click-Add Exception • Before you do that you better be sure that you know why the connection is untrusted. • Expired • Self-signed • Untrusted signing chain • MITM? • You should always have a solid reason for adding an exception.
Other outsiders: Certificates cont’d • Sometimes it is out of your control. • A security analysis of 60 banking apps revealed (among other problems): “40 percent of the tested apps did not validate the authenticity of digital certificates they received from the server, making them vulnerable to man-in-the-middle attacks using fake certificates.” • Oops! • http://www.pcworld.com/article/2086320/security-analysis-of-mobile-banking-apps-reveals-significant-weaknesses.html • http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-through.html
Wrap-up: Attacks from Outside • Plenty of risk before we fire up even our first virtual machine. • There come in all flavors: • Weak policies • Outsides pretending to be insiders. • Attackers • Novice system administrators • Your CSPs • Your patches • Your certificates • Whew!
Looking In Without Being Noticed • Attackers often want to get into your environment without being noticed. • It maximizes the time they have access to your systems so they can ex-filtrate data or abuse your systems in other ways • Before breaking in it is important to case the joint and doing this without getting noticed means you may be caught unaware when they attack. • When enumerating your environment the attacker can ask three questions: • Are they even watching? • If so, is there a threshold I can stay under? • If I trip a sensor do they respond to alerts?
Are They Even Watching? Do cloud providers pay attention to attacks? • CSPs have a financial dis-insensentive to do so. • The more alerts they disable and ignore the better their bottom line. • Also, the CSP may have no idea what a customer may consider a serious or suspicious and worthy of alerting.
Is There A Threshold I Can Stay Under? • Perhaps the CSP is actually paying attention. They still want to limit the number of alerts. • One way to do that is to set thresholds that must be met before an alert is generated. • If an attacker can discover these thresholds they attempt to operate below the thresholds to avoid detection.
Do They Respond To Alerts? • Finally, does the CSP actually take any action when their systems send alerts? • If no action is taken the attacker may be able to do their work with impunity. • On the other hand, if attackers know that certain actions occur due to certain messages they can attempt to manipulate the monitoring systems by sending fake login messages to cover their tracks.
Clouds Add to Monitoring Problems • Even if all three monitoring levels are in place the cloud still makes things more complicated. • For a CSP it may be hard to tell who is “good” and who is “bad”. • The constantly shifting virtual machine loads and configurations make it difficult to discern legitimate activity from illegitimate. • Nobody out there is wearing white hats and black hats to make it easy to tell.
Also, Your Assets Aren’t Worth It • The CSP may be the custodian of your information assets and have complete control of them but… • That doesn’t mean they will suffer if your information assets are breached. • It’s not their data after all. • Sure they may get a black eye but they will promise it will never happen again. • Worked for TJ Maxx • And I’m sure Target will be fine after this latest breach.
Data Breach Notification Laws • That is why we have data breach notification laws in almost every state in the union. • These laws compel companies that have had a breach to disclose this information to affected customers in a timely manner. (usually with exceptions for disclosures that might impact criminal investigations) • California’s Senate Bill 1386 was one of the first in the country back in 2003. • Today 46 states plus Washington D.C. have some form of breach notification laws on the books. • As of January 2014, Alabama, Kentucky, New Mexico, and South Dakota do not have any form of breach notification law on the books.
Vantage Points Inside • If the attacker gets in, where do they want to be? • Once they have a foothold they may not attack immediately. • Instead they may want to monitor your environment and learn as much as they can. • This type of patience can result in deeper and longer lasting infiltration of a target. • Separating the initial intrusion from outside with further internal movements can mean monitoring solutions may not be able to tie them together. • Some attackers can lie in wait for months before making a move.
View from the Hypervisor • Hypervisors have control over the virtual machines running on them. • Attacker activity on the hypervisor may be invisible to security tools installed on the virtual machines. • Hypervisors can see all network traffic headed to and from virtual machines. • It may be possible to view contents of virtual disks from the hypervisor • VM snapshots that include memory contents can be created and examined at the hypervisor. • Great for troubleshooting or forensics. • Bad if attackers get ahold of it.
View from the Hypervisor cont’d • The hypervisor is an enticing target. • Vendors know this and have been working hard to make them more robust against attacks. • VMWare’s stance has been to minimize the size of their hypervisor. • By reducing their codebase they reduce the corresponding attack surface.
Thinking Bigger • Owning a hypervisor is nice. Owning the administration console for the environment is better. • There are many potential tools an attacker can target: • GUIs for managing VMs installed on administrator workstations. • Configuration management systems that manage vase swaths of VMs (chef, puppet, etc.) • APIs for automated script-based virtual machine deployment and management. • All these tools share some commonalities: • Credentials: logins/passwords, certificates for accessing the systems. • Code bases of these tools provide much larger attack surfaces than hypervisors and likely much easier to access.
Attacking Admin Tools • Infiltration of administrator’s computers via malware. Stealing credentials or remote-controlling these tools may be possible. • Exploitation of API libraries or platforms • MITM attacks on tools. • Remember SSL + human nature • This guy accidentally leaked his AWS API keys and it cost him $500 in 3 days! • https://securosis.com/blog/my-500-cloud-security-screwup
Conclusion • In the first half of the lecture we discussed many different outside risks to your virtualized systems. • In the second half we discussed • How attackers may attempt to bypass monitoring to enumerate and gather information on your systems and why this may be easier than you’d think. • Vantage points they may try to gain access to that will enhance their view and then attack your systems.