The document outlines a seminar on practical security for programmers, emphasizing topics such as access control, least privilege enforcement, cryptography, and security attacks. Key concepts include multi-factor authentication, password management, and the principles of symmetric and asymmetric encryption. The seminar aims to prepare participants for identifying and mitigating security vulnerabilities in software design and implementation.

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/