The Emperor's New Cryptosystem - Jacob Ansari, 403 Labs -Toorcon 2011

1,787 views
1,694 views

Published on

Jacob Ansari of 403 Labs presented "The Emperor's New Cryptosystem: How Transparent Data Encryption Doesn't Really Do Anything" at Toorcon 2011.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,787
On SlideShare
0
From Embeds
0
Number of Embeds
223
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • This is not a crypto problem in the way that SQL injection is not a database problem
  • The Emperor's New Cryptosystem - Jacob Ansari, 403 Labs -Toorcon 2011

    1. 1. The Emperor’s New Cryptosystem:How Transparent Data Encryption Doesn’t Really Do Anything<br />Jacob Ansari, CISSP, MSIA, QSA, PA-QSA<br />403 Labs, LLC<br />
    2. 2. 403 Labs, LLC<br />Full-service information security and compliance consulting firm headquartered in Milwaukee with additional offices in Chicago and San Francisco <br />Experts in the Payment Card Industry (PCI)<br />PCI Forensics Investigator (PFI)<br />Qualified Security Assessor (QSA)<br />Payment Application Qualified Security Assessor (PA-QSA)<br />Approved Scanning Vendor (ASV) <br />Penetration testing, including web applications<br />Experienced in handling computer forensic investigations<br />
    3. 3. What we’re trying to do here<br />Define our terms clearly<br />Figure out the root of the problem<br />Discuss some solutions<br />
    4. 4. Defining our terms: TDE<br />The application doesn’t do the crypto, some other underlying piece does:<br />Database<br />Disk or database instance<br />Hardware crypto device<br />
    5. 5. What do we want crypto to do?<br />Protect data from unauthorized access<br />Control continues to work even when other security controls fail<br />Otherwise what’s the point of encrypting?<br />
    6. 6. Why is TDE a good idea?<br />Implementing a good cryptosystem is hard<br />Computationally intensive<br />Hardware devices will do this work for you<br />Labor intensive<br />Even using a good API takes time and effort<br />
    7. 7. Why is TDE a good idea?<br />Implementing a good cryptosystem is hard<br />Software implementation has a variety of challenges<br />Not just AES vs. 3DES <br />Select the right mode (e.g., CBC vs. ECB)<br />Figure out things like IVs, salts, etc.<br />
    8. 8. Why is TDE a good idea?<br />Implementing a good cryptosystem is hard<br />Key management is tricky<br />Generating keys<br />Data-encrypting keys vs. key-encrypting keys<br />Key storage<br />Key rotation<br />This is 98% of the compliance headache<br />
    9. 9. Why is TDE a good idea?<br />Use an existing or specialized tool<br />Why write a crypto scheme if the database will do it for you natively?<br />Sometimes using something like this is the only way to fit it on to a legacy application<br />Old hardware or software<br />Doesn’t support a good cryptographic routine<br />Need to get it done before the polar ice caps melt<br />
    10. 10. How does this usually work?<br />Native database encryption:<br />Enable TDE at the database column level<br />Establish key values and properties<br />INSERT and SELECT statements, for example, then encrypt and decrypt automatically<br />Current versions of MS SQL Server and Oracle do this<br />
    11. 11. How does this usually work?<br />
    12. 12. How does this usually work?<br />Disk/database instance encryption<br />Encryption occurs at the file system or database instance level<br />Mounting the disk or opening the database requires a decrypt action<br />Decrypted while in operation<br />Either in part or entirely<br />Oracle Wallet, EFS, TrueCrypt do this<br />
    13. 13. How does this usually work?<br />Hardware device<br />Sits in front of the database and intercepts database queries<br />Encrypts and decrypts and passes back and forth between the database and the initiator of the query<br />SafeNet (formerly Ingrian) and Vormetric make these devices<br />
    14. 14. How does this usually work?<br />
    15. 15. So what’s the problem? <br />Disk or database instance encryption<br />Decrypted while the file system or database is in use<br />Can technically meet compliance requirements<br />Nice for laptops that go missing; less useful for servers<br />Once decrypted, the system doesn’t distinguish between legitimate and illegitimate use<br />
    16. 16. So what’s the problem? <br />Hardware or native column-level encryption<br />Encrypts or decrypts at the behest of the database user making the query<br />If the database user has the right to decrypt, then the application that makes the query using that credential has the right to decrypt.<br />
    17. 17. So what’s the problem?<br />Many applications make use of a single database user account<br />Thus the ability to decrypt is controlled by the application’s access controls<br />If that control fails, the crypto fails with it<br />
    18. 18. How would an attack work?<br />Web application<br />An attack using SQL injection would query as the user who can decrypt<br />Making database queries defeats the cryptosystem<br />What good is the expensive crypto toy?<br />
    19. 19. How would an attack work?<br />The application likely has some users who have decrypt privilege<br />Attack their credentials<br />Attack their sessions<br />Some crappy web app password is the key to the database<br />
    20. 20. Attacks Part Deux<br />Client software<br />Probably a connection string embedded in the client somewhere<br />Sometimes it’s in the web content<br />Just found credentials in ASP pages two weeks ago<br />Sometimes it’s compiled or encoded<br />Get the client and dig it out with OllyDbg or the like<br />For .NET applications, ILDASM makes this really easy<br />
    21. 21. Attacks Part Deux<br />This actually happened!<br />Database used views to distinguish between clear and ciphertext<br />Just select from the decrypted view:<br /> SELECT * from CARD_DATA_ENC -><br /> SELECT * from CARD_DATA<br />
    22. 22. Common Thread<br />Anyone (from the database’s view) can call the decrypt routines<br />Users, by consequence, have too many privileges<br />Encryption doesn’t hold up when other controls fail<br />
    23. 23. The Root of the Problem<br />Access control<br />Often endemic to application architecture<br />Maps many application accounts onto one database account with no difference in database-level permissions<br />Not really fixed by dropping in some crypto module or device<br />Kind of like using SSL on a web server running Apache 1.3.33<br />
    24. 24. So how do we fix this?<br />Do crypto at the application layer<br />Pros: Database just sees ciphertext<br />Cons: Do crypto at the application layer<br />Key management<br />Implement the cryptosystem yourself<br />Verdict: Not really a terrible idea outright. Just not the right solution for everyone<br />
    25. 25. So how do we fix this?<br />Map each application user to an individual database user account<br />Pro: Can manage database-level access at a very granular level<br />Cons: Everything else<br />Nightmare to manage<br />May cause non-compliance with PCI DSS<br />Verdict: Not a chance<br />
    26. 26. So how do we fix this?<br />
    27. 27. So how do we fix this?<br />Map application users to a small set of role accounts<br />Pros: Gives some useful granularity to the database, not impossible to manage<br />Cons: Maybe requires some major application re-architecture<br />Verdict: Let’s explore this some more<br />
    28. 28. Database Role Accounts<br />What roles make the most sense?<br />Write/Encrypt<br />Read/Decrypt<br />Read/No Decrypt<br />
    29. 29. Database Role Accounts<br />Write/Encrypt<br />Insert records into the database that get encrypted along the way<br />Call the encrypt routine<br />Quite possibly granted to low-level users or a large percentage of the user population<br />Potential weakness: expose symmetric keys during the encrypt routine<br />
    30. 30. Database Role Accounts<br />Read/No Decrypt<br />Can SELECT or read records from the database<br />Does not call the decryption routine<br />Granted to most application users<br />Potential weaknesses: Probably not much<br />
    31. 31. Database Role Accounts<br />Read/Decrypt<br />Can SELECT or read records from the database<br />Does call decrypt routine<br />Granted to privileged users, admins<br />Potential weaknesses: ATTACK APPLICATION HERE<br />Smaller attack surface than before<br />
    32. 32. What this entails<br />The application has to support these kinds of roles<br />Application needs to map application users onto these database roles<br />Granting the same application user too many database roles breaks this<br />
    33. 33. What this entails<br />Need to think clearly about what users need to do within the application<br />Easy to grant too many permissions<br />Easy to get lazy about who should have access to what<br />Who needs to decrypt and why?<br />Who needs to encrypt?<br />
    34. 34. Variations on the theme<br />Separate schema instead of roles:<br />Important data <br />Other data <br />Each schema has its own user<br />Grant application users access to the important data schema based on their role<br />Reduced attack surface<br />
    35. 35. What this entails<br />Possibly requires a major database re-architecture<br />Cranky DBAs<br />Application use cases need to make sense<br />If everyone can encrypt and everyone gets access to the important data schema this fails<br />
    36. 36. Some other considerations<br />Don’t embed credentials in something hard-coded<br />For MS SQL databases, you probably want to use Windows authentication instead of mixed mode<br />Oracle databases support a client-side credential store with Oracle Wallet<br />
    37. 37. Some other considerations<br />Be careful of who can query the database directly<br />Don’t expose the database port to the Internet<br />For that matter, don’t expose it to anything other than the proper front-end system<br />Maybe rethink databases exposed internally to your user population<br />
    38. 38. Some other considerations<br />Good key management practices<br />Still need to rotate keys on hardware devices<br />Key rotation with a big data set is a chore; plan for this<br />Stupid passwords and unencrypted management interfaces still matter<br />Default users are still a problem<br />Default services like HTTP are still a problem<br />
    39. 39. Some other considerations<br />Hardware devices come with default role accounts<br />Stupid user accounts like:<br />Admin<br />Key manager<br />Just because it’s a security device doesn’t mean it’s secure<br />
    40. 40. Wrapping things up<br />TDE isn’t hopelessly broken<br />Has value; can’t stand alone<br />Security in layers and all that advice from 2001<br />Not a silver bullet<br />Just like everything else<br />Legacy apps pose serious challenges<br />TDE might not be able to fix them<br />
    41. 41. In conclusion<br />Many thanks!<br />Questions?<br /> Jacob Ansari<br />jansari[at]403labs[dot]com<br /> 877-403-LABS<br />

    ×