Pragmatic Approach to Breaking Mobile Apps

Aa6b7d3a12a61bfe0ce9c8a12405bd75?s=47 Rich Smith
January 12, 2012

Pragmatic Approach to Breaking Mobile Apps

A discussion of mobile app security with examples being given of reversing, understanding and breaking the encryption scheme used to secure documents in a target app. This was given for the Skýrslutæknifélag Íslands (Icelandic Computer Society) in Reykjavík, Iceland.

Aa6b7d3a12a61bfe0ce9c8a12405bd75?s=128

Rich Smith

January 12, 2012
Tweet

Transcript

  1. Pragmatic Approach to Breaking Mobile Apps Rich Smith Thursday, 26

    January 12
  2. Introduction • Talk is focussed on application security not OS

    security (See Dino’s talk) • What Apps do wrong despite the OS • Bugs vs Flaws • The principles are general • Rationale is aimed at Enterprises & SMBs Thursday, 26 January 12
  3. Aims • Rapidly validate a mobile App against a specific

    threat model • End up with a quantifiable set of risks that can be mitigated, or knowingly accepted • You won’t stop the mobile device tide, just try understand your risks Thursday, 26 January 12
  4. Avoid • Blindly believing vendor security claims • Your company

    ending up on the front page of Morgunblaðið Thursday, 26 January 12
  5. The Changing Landscape Mobile devices are at the centre of

    many current tech trends Thursday, 26 January 12
  6. The Cloud Thursday, 26 January 12

  7. Open APIs Thursday, 26 January 12

  8. App Stores Thursday, 26 January 12

  9. BYOD - Bring Your Own Device Thursday, 26 January 12

  10. Mobile Landscape • While these trends don’t create a requirement

    for mobile device usage.... • ....they increase the pressure for them to be used everywhere Thursday, 26 January 12
  11. Mobile Landscape • This pressure is coming from senior business

    people • They handle the most sensitive data • They see security as getting in the way • They wanted it yesterday ...... Thursday, 26 January 12
  12. ...so JUST APPROVE IT ALREADY! Thursday, 26 January 12

  13. The Real World • You will be asked to approve

    increasing numbers of mobile apps in 2012 • You won’t have as long as you want to assess them ™ Thursday, 26 January 12
  14. The Real World • You will be assessing Apps from

    small & start up vendors • They won’t have security as a core skill or priority, time to market wins all ™ Thursday, 26 January 12
  15. The Real World • You will need to prioritise high

    risk, low hanging fruit • You won’t have time to reverse out every function ™ Thursday, 26 January 12
  16. The Real World • You will see the same mistakes

    again, and again and again ..... ™ Thursday, 26 January 12
  17. You will feel like you doing security back in the

    90’s again! Thursday, 26 January 12
  18. Pragmatic Assessment • Rapidly assess an App with focus on

    the areas of highest risk for the given usage • Take a threat centric view of the App • Produce a set of well understood risks that you can mitigate or accept Thursday, 26 January 12
  19. Let’s look at a real App Thursday, 26 January 12

  20. Nasdaq DirectorsDesk • What does it do? • Board member

    collaboration • Document sharing • Offline documents • Messaging • Web & iPad App Thursday, 26 January 12
  21. What About Security? • Says Nothing concerning Application Security Thursday,

    26 January 12
  22. Primary Risks for this App Sensitive Data Loss Loss /

    Theft of device Loss amplification Device as Facilitator Does possession of the device provide advantage for backend attack? Loss Detection Do you know if the data is compromised? Thursday, 26 January 12
  23. Threat Centric View • How is the user authenticated •

    Enrolment, forgotten password.. • How does the device operate offline • How is data at rest secured • How does it use the OS services Thursday, 26 January 12
  24. Focus on Data At Rest • Not enough time to

    discuss full App • Essentially comes down to: • How are documents encrypted? • How is offline authentication done? • Understand the weakest link • Understand attacker level required Thursday, 26 January 12
  25. Online Model (Simplified) • App authenticates against server, establish session

    key • ‘Profile’ contains security policy & crypto material • PDF’s decrypt locally • All with RESTful API over SSL Servers PDF PDF 1. Auth 2. Download user ‘profile’ 3. Download Encrypted PDF’s Thursday, 26 January 12
  26. iOS Keystore not used Thursday, 26 January 12

  27. Offline Model 3 Crypto Schemes encryptionKey Policy Encryption KeyFile Encryption

    Data Encryption • Protects the Security policy: Max Logins Time Offline • Hardcoded key • Same for all users • Protects the encryptionKey file • Downloaded after online auth • Protected with users password • Protects the documents • Uses PDF 1.6 standard crypto • The key is the decrypted KeyFile Thursday, 26 January 12
  28. Policy Encryption • Based on a static string within the

    binary • 3spResS0FTw • Concatenate with users id (email) • jon@example.com3spResS0FTw • SHA1 hash it • b7ac203f457196beea803a26b9253b7799c14c11 • SHA256 hash that • 23a800d22da43a083375c6418fe0768f8905fbffe186e23ca946 e7b7196e008c • Use as a secret in AES 128 to decrypt policy files Thursday, 26 January 12
  29. Key File Encryption • Protects the Document encryption key •

    Based on username & password • Concatenate Username & password • jon@example.comMySecretPassword • SHA256 hash it • c3ff8db5485d4255a5de376791b089ef94d75cf3fb57c895485ffbaf4a 4aa5ea • Use this in AES 128 CBC with 16 byte IV of 0x00 to decrypt keyfile • Yields 64 byte string representing 32 byte hex number • ProTip: Result has 16 0x10 bytes appended which can be used as a truth test when brute forcing Thursday, 26 January 12
  30. Document Encryption • Based on PDF 1.6 crypto standard •

    Uses the 64 byte decrypted encryptionKey as the secret to AES 128 • Supported in many PDF libraries - docs readable anywhere • Pure brute forcing is unrealistic - the doc alone is ‘safe’ Thursday, 26 January 12
  31. What does all this mean? • The security of all

    documents at rest is based on the users password strength • The password can be brute forced off-device • Dictionary attacks particularly effective • Once brute forced the password can be used to access the service over REST • Admin defined security policy useless Thursday, 26 January 12
  32. Everything else.... • RESTful API has simply auth scheme •

    Presentation service does not use SSL • Backgrounding App saves screenshot • Autocomplete cache leaks messages • Developer files left in production App Thursday, 26 January 12
  33. Conclusion • Constructed a Threat Centric App view • Reversed

    the App - Decryption + IDA • Discovered 3 separate keying schemes • Understood what risks these posed • Understood our exposure - TC0 • Got ourselves to where we can mitigate Thursday, 26 January 12
  34. Spurningar rich@kyr.us ? Thursday, 26 January 12

  35. Thursday, 26 January 12