- "Hacking" code = programming
- "Hacking" hardware/etc = building things against their intent
- "Hacking" in a traditional sense: people or computers/software
- Social engineering
- You've seen the African Prince-type
- "send me your bank account info"
- Print up some checks with names that match your fake ID
- Spend them!
- Better yet, get people on Craigslist to deposit them and send you the money for a 25% cut
- "Real Estate Apprentices"!
- Most social engineering is more nuanced
- Essentially a game of tricking people to reveal their secrets: passwords, pin numbers, bank account, credit card, security question responses, etc
Quick Turn & Talk: What was the last social engineering scheme you got attacked with?
- Typically starts with mis-using or cross-using software
- Hackers are like Q/A teams with motivation
- Try to find the soft spots in software and exploit them
- There are patterns of common weaknesses, mostly anchored around user input
- Historically fueled by curiosity
- Sometimes for profit -- but the profits are typically small
- Politics and political expression have always been a part
- Using technical skills to create yourself a voice
- Ex: Display boards
- IR interfaces with four-digit security codes
- Transmit the code, the write instruction, then your message
- Palm Pilot III used IR for transmission and was easily programmable
- Iterate through all 10-thousand possible codes sending:
- possible_code-write-possible_code
- Now the board is displaying it's own password
Quick Turn & Talk: Have you ever hacked anything?
- One of the classic vulnerabilities of web applications
- Set up by a developer injecting user input into a SQL query
- Say you have a new site and allow users to view articles published on a certain date by pulling the date out of the URL
date_from_url = (some string manipulation to pull the date out of the URL)
Article.find_by_sql("SELECT * from articles where published_on='#{date_from_url}'")
You're expecting a URL like this:
http://example.com/articles?published_on=2019-09-14
But instead you get a URL like this:
http://example.com/articles?published_on=2019-09-14');select%20*%20*from*users;
Now when you inject that string into your SQL query you get:
"SELECT * from articles where published_on='2019-09-14';select * from users"
And your app probably gives a 500 error because it's now trying to find title and body fields in data that has username and password. No problem, just a little change to the URL:
http://example.com/articles?published_on=2019-09-14');select%20username%20as%20title,password%20as%body%20*from*users;
Then your article display is going to be really great. The user can save the HTML, clean up the content, and have a table of all your usernames and (encrypted) passwords.
Quick Turn & Talk: Based on the languages/frameworks your familiar with, what might the programmer have done differently to avoid this vulnerability?
- You should never store a plain-text password
- In the scenario above, you would have dumped all the user's passwords
- Instead you typically use a one-way hash
- A hashing function takes an input and generates a relatively unique output
- Given an output you cannot calculate the input
001 > require 'digest'
=> true
002 > Digest::MD5.hexdigest 'hello'
=> "5d41402abc4b2a76b9719d911017c592"
003 > Digest::MD5.hexdigest 'Hello'
=> "8b1a9953c4611296a827abf8c47804d7"
The output from the SQL injection hack above with hashed passwords might look like this:
username | hashed_password
admin | "93a09efb8dc498329d728bbc25e64026"
ghost | "bad670f05ad869901d90a37aef62572c"
security | "93f8936838d0b97a4e472781709e0a86"
Remember that there's no way to go from the hashed password back to the original password. But maybe you can guess and check.
- Say you have some ideas about password patterns
- Maybe the site where you dumped the encrypted passwords is related to banking/finance
- You see that the site requires at least eight characters in the password
- There's a good chance that some users took their four-digit ATM pin and repeated it to make an 8-digit password
(1..9999).each do |pin|
pin_digits = pin.to_s.rjust(4,'0') * 2
puts pin_digits + " | " + Digest::MD5.hexdigest(pin_digits)
end
Now I can do what is essentially a reverse lookup based on the known output.
Is the double-four-numbers a cheat? Kinda. But to generate the same table to all possible 8 digit numbers took just 20 minutes of computer time. Imagine what you could do with cloud servers or a botnet of hijacked desktop computers?
Tada! We're hackers now.
- How might these principles influence how you build applications?
- Being an expert in computer security is like being an expert in crime. What does this mean about the people who work to prevent these attacks?
- Why would a team/product likely struggle if there's just one person "in charge" of security?