Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Improving Cloud Security with Attacker Profiling

Bryan Payne
November 18, 2015

Improving Cloud Security with Attacker Profiling

Presented at QConSF 2015
Video available at http://www.infoq.com/presentations/attacker-profiling-security

When securing a system, what are the modern realistic threat scenarios that you should be protecting against? And how does use of an IaaS cloud provider shape these threats? This talk will take a deep dive into the murky world of offensive computing. You’ll gain a clear understanding of different types of attackers, their skill sets, and how compromises happen, with a specific focus on protecting cloud-based applications. Along the way you’ll laugh, you’ll cry, and you’ll shift uncomfortably in your seat as you come to the inevitable conclusion that many applications have inadequate security against modern attackers. You will leave the talk with a clear conviction to make your systems more secure, and a new mindset that will help keep your threats away.

Bryan Payne

November 18, 2015
Tweet

More Decks by Bryan Payne

Other Decks in Technology

Transcript

  1. Platform Security Overview Microservices in the Cloud Device or Browser

    Netflix Open Connect Appliance 1 2 - AWS Mgmt - Security Tools - Code Review - Forensics / IR - IT Security - Content Protection - Device Security Platform Security - Foundational Security Services - Security in Common Platform - Security by Default in base AMI
  2. Classic Security via AWS CloudHSM Instance Metadata Signature Identity &

    Access Management Trusted Services (AWS) Great Unknown Hypervisor Hardware Platform Physical Security Malicious Insider Key Management Supply Chain Firmware Side Channel Leaks Trusted Services (Netflix) Secret Deployment Service Self-Service CA Crypto / Key Management Service
  3. Ubiquitous Security • Partner with other teams • Make security

    transparent (or easy) • Focus on common components • Also focus on strategic risks Platform Security Review Implement Im plem ent D eploy Report Service Creation Service Maintenance Security Audit IR / Forensics Plan Security Improvements Security Services Security Defaults
  4. Murdoch et al, Chip and PIN is Broken, IEEE Symposium

    on Security and Privacy, 2010 Greenberg, X-Ray Scans Expose and Ingenious Chip-and-PIN Card Hack, Wired, 19 October 2015
  5. Attacker Skill & Exploitation Likelihood Likelihood of Attack Intelligence Services

    Serious Organized Crime Highly Capable Groups Motivated Individuals Script Kiddies OpenStack Security Guide (CC BY 3.0) http://docs.openstack.org/sec/ Political & Industrial Espionage Financial Financial & Idealogical Financial, Revenge, Fun Fun, Demonstration
  6. • Little trust in authorities • Desire control • Hacker

    life kept secret • “Don’t foul your own nest”
  7. Attacker Characteristics • creative and brilliant • curious • motivated

    • shy in real life • comfortable with computers “Yes, I am a criminal. My crime is that of curiosity.” The Hacker Manifesto
  8. Attack Characteristics • access (nmap, exploit, configuration error, etc) •

    file cleaners • backdoor • password cracking • monitor system admin • proceed with goals (files, network sniffing, etc)
  9. Joshua Davis. The Untold Story of the World’s Biggest Diamond

    Heist. Wired, http://archive.wired.com/politics/law/magazine/17-04/ff_diamonds 1. Combination dial 2. Keyed lock 3. Seismic sensor 4. Locked steel grate 5. Magnetic sensor 6. External security camera 7. Keypad to disarm sensors 8. Light sensor 9. Internal security camera 10. Heat / motion sensor
  10. • USG employee background checks & fingerprints • Credit cards

    • User data • PPI: SSN, driver’s license, phone, address, DoB, etc • Passwords
  11. Photo Credit: Tom Varco (CC BY-SA 3.0) https://en.wikipedia.org/wiki/Safe#/media/File:Safe.jpg Photo Credit:

    Jonathunder (CC BY-SA 3.0) https://en.wikipedia.org/wiki/Bank_vault#/media/File:WinonaSavingsBankVault.JPG
  12. Cloud Attack Graphs • Cloud account credentials • Instance account

    credentials • Your employees, supply chains, code • Provider’s employees, supply chains, code • Corporate network • Build pipeline
  13. from cryptography.fernet import Fernet key = Fernet.generate_key() f = Fernet(key)

    ciphertext = f.encrypt(b”A message.") plaintext = f.decrypt(ciphertext) Simple Libraries (e.g., python-cryptography) Traditional Libraries (e.g., openssl) #include <openssl/conf.h> #include <openssl/evp.h> #include <openssl/err.h> #include <string.h> int main(int arc, char *argv[]) { /* Set up the key and iv. Do I need to say to not hard code these in a * real application? :-) */ /* A 256 bit key */ unsigned char *key = "01234567890123456789012345678901"; /* A 128 bit IV */ unsigned char *iv = "01234567890123456"; /* Message to be encrypted */ unsigned char *plaintext = "The quick brown fox jumps over the lazy dog"; /* Buffer for ciphertext. Ensure the buffer is long enough for the * ciphertext which may be longer than the plaintext, dependant on the * algorithm and mode */ unsigned char ciphertext[128]; /* Buffer for the decrypted text */ unsigned char decryptedtext[128]; int decryptedtext_len, ciphertext_len; /* Initialise the library */ ERR_load_crypto_strings(); OpenSSL_add_all_algorithms(); OPENSSL_config(NULL); /* Encrypt the plaintext */ ciphertext_len = encrypt(plaintext, strlen(plaintext), key, iv, ciphertext); /* Do something useful with the ciphertext here */ printf("Ciphertext is:\n"); BIO_dump_fp(stdout, ciphertext, ciphertext_len); /* Decrypt the ciphertext */ decryptedtext_len = decrypt(ciphertext, ciphertext_len, key, iv, decryptedtext); /* Add a NULL terminator. We are expecting printable text */ decryptedtext[decryptedtext_len] = '\0'; /* Show the decrypted text */ printf("Decrypted text is:\n"); printf("%s\n", decryptedtext); /* Clean up */ EVP_cleanup(); ERR_free_strings(); return 0; } int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *key, unsigned char *iv, unsigned char *ciphertext) { EVP_CIPHER_CTX *ctx; int len; int ciphertext_len; /* Create and initialise the context */ if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors(); /* Initialise the encryption operation. IMPORTANT - ensure you use a key * and IV size appropriate for your cipher * In this example we are using 256 bit AES (i.e. a 256 bit key). The * IV size for *most* modes is the same as the block size. For AES this * is 128 bits */ if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)) handleErrors(); /* Provide the message to be encrypted, and obtain the encrypted output. * EVP_EncryptUpdate can be called multiple times if necessary */ if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len)) handleErrors(); ciphertext_len = len; /* Finalise the encryption. Further ciphertext bytes may be written at * this stage. */ if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors(); ciphertext_len += len; /* Clean up */ EVP_CIPHER_CTX_free(ctx); return ciphertext_len; } int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char *key, unsigned char *iv, unsigned char *plaintext) { EVP_CIPHER_CTX *ctx; int len; int plaintext_len; /* Create and initialise the context */ if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors(); /* Initialise the decryption operation. IMPORTANT - ensure you use a key * and IV size appropriate for your cipher * In this example we are using 256 bit AES (i.e. a 256 bit key). The * IV size for *most* modes is the same as the block size. For AES this * is 128 bits */ if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)) handleErrors(); /* Provide the message to be decrypted, and obtain the plaintext output. * EVP_DecryptUpdate can be called multiple times if necessary */ if(1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len)) handleErrors(); plaintext_len = len; /* Finalise the decryption. Further plaintext bytes may be written at * this stage. */ if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len)) handleErrors(); plaintext_len += len; /* Clean up */ EVP_CIPHER_CTX_free(ctx); return plaintext_len; } [edit]
  14. Simple Framework for Key Handling Throughput Protection It’s Exposed! It

    lives… Low Sensitivity High Low No biggie In lots of VMs Medium Sensitivity Medium Medium It’ll be a long week. In very few VMs High Sensitivity Low High No. Just. No. In Special Hardware
  15. Use Case of a Key Implies Handling Requirements TLS Session

    Key - Fast, Handled in Dynamic Environment
 • But easy to have a reasonable policy if we lose it Certificate Authority Private Key - Maybe not used so much • Probably way more important that you just don’t lose it
  16. Cryptex - Our Framework for Key Handling Eureka Server(s) Eureka

    Server(s) Cryptex Server(s) Web Server Logic Netflix Business Application Cryptex Client Library Netflix IPC Components (Ribbon/Hystrix/etc) Many of these Not Many of these Cloud HSMs - Dedicated Hardware
  17. “Low” Key Handling Cryptex Client Library Netflix Business Application Cryptex

    Server GetKey(ID=123) Resp(Value=iXKQ…) Client Auth TLS Encrypt/Decrypt Key Exported Out to Every Client • Extremely High Throughput • Client Library Attempts to be Mindful of Key Handling
  18. “Medium” Key Handling Every Operation is a REST Call •

    Luckily we don’t have many bulk encrypt use cases for these • Cryptex servers not publicly facing; ostensibly harder to get onto Cryptex Client Library Netflix Business Application Cryptex Server GetKey(ID=456) Resp(Value=null) Client Auth TLS Encrypt(ID=456,PT=…) Resp(CT=5pI6…)
  19. “High” Key Handling Cryptex Server Cryptex Client Library Netflix Business

    Application GetKey(ID=789) Resp(Value=null) Client Auth TLS Encrypt(ID=789,PT=…) Resp(CT=JGVqF…) HSM API Encrypt(ID=789,PT=…) Resp(CT=JGVqF…) Every Operation is a call to specialized hardware • HSM API challenging relative to REST calls (only Cryptex does it) • Very constrained throughput;VM side channel attacks negated
  20. “Asymmetric” Key Handling Cryptex Client Library Netflix Business Application Cryptex

    Server GetKey(ID=111) Resp(PubValue=iXKQ…) Client Auth TLS Verify We support the basics: AES, HMAC-SHA, RSA • Optimize RSA verify/encrypt by pushing public key to edge • At scale computational intensity of RSA quite apparent
  21. • 802.11a/b/g/n/ac • Bluetooth • Gigabit Ethernet • Out-of-band SSH

    access over 4G/GSM cell networks https://www.pwnieexpress.com/product/pwn-plug-r3penetration-testing-device/ Attackers Are Creative
  22. A team participating in a CTF competition at DEFCON 17

    Photo Credit: Nate Grigg (CC BY 2.0) http://www.flickr.com/photos/nateone/3792232737/