Practical security - access control, least privilege, cryptography at work, security attacks and pen testing your system with MetaSploit. The enemy knows the system. Not security by obscurity

1. Practical security
A half-day seminar for programmers
Copyright Danny Lieberman dl@software.co.il under Creative Commons Attribution License.
http://creativecommons.org/licenses/by/2.0/
V5.0 10/7/2014

2. Prerequisites
• Before the seminar you will need to read this
article and understand the concepts described
The NSA and Snowden: Securing the All-Seeing Eye
http://cacm.acm.org/magazines/2014/5/174340-
the-nsa-and-snowden/fulltext

3. Agenda
• Access control
• Least privilege enforcement
• Cryptography at work
• Security attacks
• Pen testing with Metasploit

4. Agenda
• Access control
• Least privilege enforcement
• Cryptography at work
• Security attacks
• Pen testing with Metasploit

5. Access control
• A security countermeasure for protecting data
at rest
– Necessary but not sufficient
• For data in motion over an insecure channel
we need stronger countermeasures
– Encryption
– One-time tokens
• Based on authorization and authentication

6. Authorization - I
• The process of authorization is distinct from
that of authentication.
– Authentication is the process of verifying that
“You are who you say you are”
– One-factor: Username/password
– Authorization is the process of verifying that
“You’re permitted to do what you’re trying to do".
– Read this file only

7. Authorization - II
• Hash functions are the basis for most methods of enforcing
cryptographic data integrity
– Variable length input
– Fixed length output
• Effectiveness determined by:
– Determining the input from output should be computationally
infeasible
– Given input and output, generating input with same output
should be computationally infeasible
– Collision-free, same outputs with different inputs should be
computationally infeasible
• Examples – SHA-1, SHA-256 and MD5
• Example of password hashing coming up in 2 slides

8. Multi-factor authentication - I
• Something a user has and something the
user knows
– Credit card plus a PIN
– Password and a pseudorandom number from
a security token
• High-security systems
– Screen height, weight, facial, retinal and
fingerprint checks plus a PIN plus a day code

9. Multi-factor authentication - II
• Google Authenticator - 2-factor software token generator for iOS, Android
– Something user has and knows
• Her smartphone.
• One-time password (token)
– Server and client code agree on algorithms and secret key:
• Secret key is the seed value for hashing
• Algorithm used to verify the password
– Algorithms:
• RFC 4226 - HMAC-based one-time password
http://www.ietf.org/rfc/rfc4226.txt
• RFC 6238 - Time-based one-time password
http://tools.ietf.org/html/rfc6238

10. Multi-factor authentication - III
• To generate the one-time password, client code needs secret key, counter and number of
digits (which is 6 for Google Authenticator)
• Counter is used as a “moving factor” to make the algorithm more robust. A “throttling
parameter is also specified in RFC 4226

11. Multi-factor authentication - IV
• RFC 6238 allows for any start date and time interval, but Google Authenticator
requires the Unix epoch and a 30 second time interval.
• This means we can get the current one-time-password using only the secret key.

12. Multi-factor authentication - V
• How do we put it to use?
• IsValid helps with clock skew by checking adjacent intervals for the password.
• Improves user experience, because it doesn't require clocks to be perfectly aligned
See http://www.codeproject.com/Articles/403355/Implementing-Two-Factor-Authentication-in-ASP-NET

13. Access control - Design vulnerabilities
• As the name suggests – a software design will
often have vulnerabilities because of
assumptions
– Ignoring the fate of temporary files storage is a
bad design decision.
– Temp files are very often written into directories
with world read, write permissions for
convenience
• For example, log files.

14. Access control – Operational vulnerabilities
• Rooted in how the source code interacts with the
environment
– Using FTP to transfer files
– FTP users/anonymous FTP users may have access
rights to GET or even worse PUT files on to your
machine.
– FTP is problematic
• Most FTP uploads do not check the uploaded files for
malware.
• FTP credentials are passed in clear text
• FTP servers are frequently forgotten by IT operations

15. Password policy & account handling - I
• Baked into the design and implementation
• Enforce operational security:
– Follow Microsoft server guidelines
• http://technet.microsoft.com/en-us/library/cc526440.aspx
• http://technet.microsoft.com/en-us/security/jj720323.aspx
• Strength, Expiry
– Require strong passwords (AxCrl8N^)
– Expiry policy (changes every 90 days)
• SSO/federated login alternatives
• Social login for customer-facing Web services

16. Password & account handling - II
• So-called strong passwords and expiration
policies that force people to change frequently
are the main reason for:
• Users recycling their corporate passwords on ecommerce
and adult sites
– Which are frequently hacked and then exploited as a back-
channel to corporate networks
• Post Its
– It’s OK to write down a password, just treat it like cash!
• Credentials sharing
– January 24, 2008, Société Générale announced that a futures
trader at the bank had fraudulently lost the bank €4.9BN

17. Password & account handling - III
• Password management tools
– Free open source
• KeePass - http://keepass.info/
– Commercial closed source
• Sticky Password Pro - http://www.stickypassword.com/
• Roboform - http://www.roboform.com/

18. Password and account handling - IV
• Database connection strings
– Credentials should not be the database root user
– Should not be provided in clear text inside code
• An attacker (or security auditor) can grep the code and
pick up the credentials
– Should reference a hashed parameter file outside
the application path

19. Agenda
• Access control
• Least privilege enforcement
• Cryptography at work
• Security attacks
• Pen testing with Metasploit

20. Principle of least privilege - I
• A particular abstraction layer
– Code, users, process, people
• must be able to access only resources that are
necessary for legitimate purpose.
– A key security countermeasure for preventing data
loss and malicious code exploits

21. Principle of least privilege - II
• Users
– User credentials employed in a backup script run
by a job scheduler should not be able to install
software

22. Principle of least privilege - III
• Code
– Code that provides UI functionality should never
run as administrator (even if it is convenient…)
• Malicious code doesn’t have to elevate privilege

23. Principle of least privilege - IV
• Process and people
– People with access to sensitive data and a subset
of super user privileges should not be able to
upgrade their own permissions
– Two administrators need to execute and confirm
permissions update of another administrator

24. Agenda
• Access control
• Least privilege enforcement
• Cryptography at work
• Security attacks
• Pen testing with Metasploit

25. Cryptography at work
• Confidentiality
• Non-repudiation

26. Confidentiality
• Confidentiality is the expectation that only
authorized parties can view data
– For data in motion or in rest that is accessible over
an insecure channel, encryption is required
• Encryption has a long history, dating back to
ancient cultures.
– 2 major classes: symmetric and asymmetric

27. Symmetric encryption
• Symmetric encryption (or shared key) refers to
algorithms where all authorized parties share the
same key
– Simplest and most efficient
– Major weakness since partners have access to same
shared secret.
• May generate unique key for each relationship
– In a group of shared key users
• Key management becomes impossible
• No means for verifying the sender of a message

28. AES - I
• AES is based on a design principle known as a
substitution-permutation network,
– Combining both substitution and permutation
– Fast in both software and hardware
• AES is a variant of Rijndael
– Fixed block size of 128 bits
– A key size of 128, 192, or 256 bits.

29. AES - II

30. AES - III
• Good support in all popular languages
– Crypto++ A comprehensive C++ semi-public-
domain implementation of encryption and hash
algorithms. FIPS validated
– .NET System.Security.Cryptography
– Java Cryptography Extension
– PHP mcrypt extension
– JavaScript - https://code.google.com/p/crypto-js/
and https://github.com/digitalbazaar/forge

31. Applications of symmetric encryption
• Protecting message confidentiality
• Protecting API payloads

32. Protecting message confidentiality
input = “Meet me at 21:00 for beer at JEMS, bring your friend Michal";
message(encrypt(input));
function encrypt(input) {
key = "this is a secret key";
td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_ECB);
iv = mcrypt_create_iv(mcrypt_enc_get_iv_size(td), MCRYPT_RAND);
mcrypt_generic_init(td, key, iv);
return mcrypt_generic(td, input);
}
function decrypt(data)) {
key = "this is a secret key";
td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_ECB);
iv = session.read(‘Client.iv’);
return mcrypt_decrypt ( td , key , string data)
}

33. Protecting API payloads- I
Your site
http://apiconsumer.com/
(I)
API provider
https://api.com
(II)
Response
JSON
Request
POST
https://api.com/edit/data/GUID

34. Protecting API payloads - II
• Problem
– Encryption doesn’t prevent client-side attacks:
• URL hacking
• Manipulation of payload data using “shims”
• Unauthorized disclosure of payload

35. Protecting API payloads - III
• Solution
– Symmetric encryption critical payload fields such
as GUID
• Shared secret between API consumer and provider
• The usual problems and solutions of key exchange and
distribution

36. Asymmetric encryption
• Public and private key pair for each party
• Parties that communicate exchange public keys in
advance
– Message is encrypted by combining recipient public key
and sender private key.
• Message can only be decrypted using recipient private key
• Simplifies key management
– Doesn’t require exposing private keys
– Implicitly verifies sender
– Computationally intensive
– Used to exchange a symmetric key for the duration of
session

37. RSA encryption
• Alice works at a hospital. She needs to send
Bob from the insurance company a list of
records for treatment reimbursement.
• Alice gets Bob's public key from the insurance
company Web page.
• Alice sends the file to Bob encrypted with
Bob's public key.
• Bob uses his private key to unscramble it.

38. Alice and Bob
From: Schneier: Applied Cryptography

39. RSA example

40. Cryptography at work
• Confidentiality
• Non-repudiation

41. Non-repudiation - I
• The maker of a statement cannot successfully
challenge the validity of the statement or
contract.
– In the digital realm, enforced with digital
signatures
– In physical realm, enforced with notaries and
stamps

42. Non-repudiation - II
•‫בת‬ ‫האבן‬ ‫חותמת‬2,500
‫השם‬ ‫ועליה‬ ‫שנה‬``‫תמח‬``
‫עפר‬ ‫בשכבת‬ ‫נמצאה‬
‫ידי‬ ‫על‬ ‫המתקיימת‬ ‫בחפירה‬
‫מזר‬ ‫אילת‬ ‫הארכיאולוגית‬
‫העיר‬ ‫לחומות‬ ‫מחוץ‬
‫לשער‬ ‫בסמוך‬ ‫העתיקה‬
‫האשפות‬.

43. Creating RSA signature keys - I
• Generate an RSA key pair containing a modulus N
that is the product of two large primes, along
with integers e and d such that e d ≡ 1 (mod
φ(N)), where φ is the Euler phi-function.
• The signer's public key consists of N and e, and
the signer's secret key contains d.
• To sign a message m, the signer computes σ ≡ md
(mod N). To verify, the receiver checks that σe ≡
m (mod N).

44. Creating signatures - II
• The message to be signed is first hashed to produce a
short digest that is then signed:
– Efficiency:
• Hashing is faster than signing
– Compatibility:
• Hash can convert an arbitrary input into the proper format.
• For example strings/integers
– Integrity:
• Without the hash function, the text "to be signed" may have to be
split (separated) in blocks small enough for the signature scheme
to act on them directly.
• Receiver of signed blocks cannot recognize if all the blocks are
present and in the right order.

45. Creating signatures - III

46. Agenda
• Access control
• Least privilege enforcement
• Cryptography at work
• Security attacks
• Pen testing with Metasploit

47. Security attack types
• Interception
– Passive tapping
• Interruption
– DOS
• Modification
– Active tapping/packet insertion
• Fabrication
– Man in the middle attacks

48. Typical countermeasures
• Interception/Modification
– Passive tapping / active tapping
• Physical security to prevent insertion of a tap in wiring cabinet
• Network segmentation
• Encrypt communications, including authentication credentials. This prevents sniffed
packets from being usable to an attacker. SSL and IPSec (Internet Protocol Security) are
examples of encryption solutions.
• Interruption
– DDOS
• Firewall, IPS/IDS and special purpose network appliances that detect anomalous traffic
and throttle it down
• Apply patches to TCP/IP stack for example MS13-065:
– https://technet.microsoft.com/en-us/library/security/ms13-065.aspx
• Fabrication
– Man in the middle attacks
• Use encrypted session negotiation (Well known DICOM vulnerability)
• Use encrypted communication channels.
• Patch TCP/IP stack vulnerabilities, such as predictable packet sequences.

49. Kerckhoff’s principle
• Kerckhoffs's principle
– A cryptosystem should
be secure even if
everything about the
system, except the key, is
public knowledge.
• Independently
formulated by Claude
Shannon as "the enemy
knows the system",
• In contrast to "security
through obscurity”

50. Agenda
• Access control
• Least privilege enforcement
• Cryptography at work
• Security attacks
• Pen testing with Metasploit

51. PEN TESTING WITH METASPLOIT
A short introduction

52. Installation
• Download from www.metasploit.com for your
platform
• Prefer Linux 64 bit
• Note that the distribution comes with it’s own
RDBMS – PostgreSQL

53. The absolute basics
• Pre-engagement – set goals
• Intelligence gathering
– What defenses are in place?
– Expendable IP addresses
• Threat modeling
• Vulnerability analysis
• Exploitation
– Often brute force
• Post-exploitation
– What the systems do, what are user roles?
– IP and other sensitive data

54. Concepts
• Exploit
• Payload – code delivered by MSF to target system
– Reverse shell creates a connection from the target
back to attacker as command prompt
– Bind shell binds a command prompt to listener on
target machine in order to execute commands
• Shellcode – e.g. a Meterpreter shell after
executing the payload
• Module – exploit, auxiliary…
• Listener

55. Fundamentals
• Msfcli
• Msfconsole
– search
– show exploits, auxiliary, show options
– use scanner/smb/smb_version
– use windows/smb/ms08_067_netapi
• Databases
– Using the Database
• About Meterpreter
– Meterpreter Basics

56. Information gathering
• Port Scanning
• Hunting For MSSQL
– search mssql
– use auxiliary/scanner/mssql/mssql_ping
– set RHOSTS 10.211.55.1/24
– exploit
• Brute force attack
– Use scanner/mssql/mssql_login
– Set PASS_FILE /pentest/exploits/….wordlist.txt

57. Vulnerability scanning
• SMB Login Check
• VNC Authentication

58. Fuzzing
• Fuzz testing or fuzzing
– Software testing technique,
– Automated or semi-automated
– Provide invalid, unexpected, or random data to
the program input devices/sockets.
– Process is then monitored
• Program exceptions
– Crashes, or failing built-in code assertions
• Finding potential memory leaks.

59. Summary - Snowden
• You’ve read the article and heard the material
in this talk
• What did NSA do wrong in your opinion?
My kind thanks to Raymond Ludwin for his comments.
Copyright Danny Lieberman dl@software.co.il under Creative Commons Attribution License.
http://creativecommons.org/licenses/by/2.0/