Quality of Life and Lines of Defense

Check the online version, I often update my slides.

Talk detail

On multiple lines of defense, how to implement them in your typical web app, and why. Explained on passwords and Cross-Site Scripting.

Date and event

March 19, 2017, Human Inference Kick-Off, Sitges, Spain (talk duration 75 minutes)

Slides

SlideShare

Notes transcript

1. Uh, huh.

   Yep, that's me fixing some security issues while on vacation. This talk is about quality of life, multiple lines of defense, how to implement them in your typical web app, and why. Explained on passwords and Cross-Site Scripting. This slide deck contains extra speaker notes not available in the original deck.

2. Yahoo confirms massive data breach

   In September 2016, Yahoo confirmed a 500 million accounts leak. The breach is said to have occurred in late 2014. It has changed lives of quite a few people.

3. Yahoo says 1 billion user accounts were hacked

   Only three months later, in December 2016, Yahoo released a statement saying that 1 billion accounts were compromised in a different attack in 2013.

4. NASDAQ: YHOO 46.29 USD (Mar 15, 2017)

   I'm not a market expert, but this stock price chart says Yahoo is doing quite fine. Obviously the breach had no influence on the stock price. But…

5. Verizon will pay $350 million less for Yahoo

   In July 2016, before the breaches were disclosed, Verizon announced its intent to acquire Yahoo's Internet business for $4.8 billion. On February 21, 2017, Verizon agreed to lower its purchase price for Yahoo by $350 million, and share liabilities regarding the investigation into the data breaches. Talk about losing money.

6. Russian agents were behind Yahoo hack, U.S. says

   Russian agents were behind Yahoo hack, U.S. said in March 2017. I don't want to go into attribution business but let's focus on the small text below the picture →

7. Marissa Mayer, Yahoo's chief executive, lost her 2016 bonus and 2017 stock compensation after an investigation into a security breach of user accounts.

   Right, that seems quite bad. I'd say Mayer's quality of life has changed a bit.

8. Blackmailing, because plaintext passwords

   A friend of mine called me some time ago, his voice shaking. He told somebody has hacked a legacy site his company had built. Unfortunately the site stored user passwords just like this and the attacker said he'd publish the database unless the company pays a ransom. That friend and his team had to work 24/7 for a few days to fix the app and some others. Life quality reduced. Eventually they didn't pay the ransom, and fortunately database was not released.

9. Ashley Madison

   In summer 2015 a group or an individual named The Impact Team released 25 GB of company and user data taken from Ashley Madison, a Canadian dating site marketed to people who are married or in committed relationships. Not every user of the site had an affair, but most of the media presented the incident as “database of cheaters leaked”. Days after the data was published a lot of Ashley Madison users started to be blackmailed: “send bitcoinz and we will not tell your partner you had an account with Ashley Madison,” or “send bitcoinz and we will tell you whether your partner had an account, or not.” The hack made a mess of lot of lives.

10. Ashley Madison: ‘Suicides’ over website hack

    Supposedly two Ashley Madison users commited suicide because of the hack. One of them was an american pastor, the other one a man my friend had talked to. Some other suicides eventually couldn't be confirmed as events linked to the leak, like the San Antonio police captain case.

11. LinkedIn lost 167 million account credentials in data breach

    In 2012, LeakedIn, I mean LinkedIn lost 6.5 million usernames and hashed passwords but in May 2016 it became apparent that the leak was much bigger than originally thought. It was 167 million credenentials in total. The company discovered the full extent only after somebody tried to sell the whole database dump.

12. Mark Zuckerberg

    This is Mark. Mark runs Facebook. Mark used the same password for LinkedIn, Pinterest, and Twitter. Don't be like Mark a don't use the same password for multiple services. Use strong unique passwords. Use a password manager to generate and keep your passwords. Have a backup plan in case you forget the master password.

13. Hey, @finkd You were in Linkedin Database with the password “dadada” ! DM for proof..

    In June 2016 a group called OurMine posted Mark's password, dadada, on his Twitter.

14. Digital trail betrays identity of Russian ‘hacker’ detained in Prague

    Da in Russian means Yes. And guess what? This guy, Yevgeny Nikulin, a Russian national detained in downtown Prague, Czech Republic on October 5, 2016, is accused by American officials of hacking U.S. targets. Coincidence much, da.

15. SHA-1 hash 0f158e648228a19cab5f23acfd6c36f716a702a9

    Zuckerberg's pas­sword was stored hashed in the LinkedIn dump, this is the hash. But when passwords are hashed with unsalted SHA-1, it's quite easy to crack them.

16. Google SERP

    For weak passwords like dadada, you can even Google the unsalted SHA-1 hash.

17. 9× GeForce GTX

    When a Google search is not enough, or if you want to crack passwords for living, you'll need machine full of GPUs, like this one built by Jeremi Gosney and his company Sagitta HPC. It generates tens of billions of SHA-1 hashes per second.

18. High Performance Cracking Cluster

    When even a machine full of GPUs is not fast enough, maybe you'll more machines.

19. PaletteForce

    These Sagitta HPC guys are crazy. Now they're ordering their GPUs by kilos. So this is how 300 kg of NVIDIA GeForce GPUs looks like.

20. ';-- have i been pwned?

    Use Have I been pwned? to see if your account has been compromised in a public data breach. You can also set up notifications or search across an entire domain.

21. Variable binding, HTTPS, Firewalls + The Seven Layers of OSI

    Security is not just “buy this box and plug it in the network”. When transmitting and receiving, the data goes through several layers. Each of the layers needs their own protection. A site using HTTPS to encrypt the traffic can still be hacked and have the database dumped. Users get phished on sites using HTTPS. But we still ❤ HTTPS.

22. Observatory by Mozilla

    Use Observatory by Mozilla to scan some of the layers, it will offer few hints to make them more secure. It scans HTTP headers, cookies, etc., and optionally includes results from third-party scanners, like the SSL Labs Server Test.

23. Password storage disclosures

    Password hashing, a second line of defense, protects users and their passwords when databases leak. Database leaks shouldn't happen, but they do. Multiple lines of defense offer protection when something goes wrong. I've actually started collecting info on how companies store user passwords. The collection is available at https://pulse.michalspacek.cz/…rds/storages.

24. www.slevomat.cz password storage disclosures

    Here's a Czech company using bcrypt. Their disclosure has been rated “A”. They have also provided historical info and some details in their FAQ. I always link to a public disclosure, so the site is actually more like a collection of links to who said what. Disclosure: I worked for Slevomat.cz in 2013–2014.

25. Secure: A, B

    My scoring system is inspired by the SSL Labs Server Test rating and it works like this: the better the hashing algorithm is and the better the disclosure is, the better score the site gets. So if a site uses bcrypt (or PBKDF2, scrypt, or Argon2) and they tell us in their docs, they score “A”. If they tell us only in a blog post, talk, or on a social media they score “B”, because a talk or a blog post is quite invisible. Both “A” and “B” are scores for safe password storage.

26. Weak: C, D, E

    A site scores “C” if they use unsuitable hashes like MD5 or SHA-1 with a salt and multiple iterations. They score “D”, if they hash passwords with one iteration of an unsuitable hashing function, with a salt. Grade “E” is for when they use plain fast hashes or encrypt passwords. Users are strongly advised to create unique passwords for sites with these scores, especially for sites with “D” or “E”.

27. Unsafe: F

    Last but not least, “F” is for total failure, and that's when the site stores passwords just like this, in plaintext. When signing up for the service, users should, and I mean SHOULD use a unique password, not used anywhere else.

28. XSS, Cross-Site Scripting

    The concept of multiple lines of defense could also be demonstrated using Cross-Site Scripting, an attack on users and their browsers. Using XSS, the attacker can execute their malicious JavaScript downloaded from some other site in the context of the vulnerable app.

29. What is the first published XSS vuln that you are aware of? 1999–07–09 according to our list.

    Cross-Site Scripting is not new. According to Open Sourced Vulnerability Database, the first XSS vulnerability was published in 1999.

30. $1.2 million

    Just in 2014–2016 Google has awarded researchers over $1.2 million for reporting XSS bugs in their applications via Google's Vulne­rability Reward Program. Not bad.

31. Man and money

    A man, left, and $1M in $100 bills, right, according to PageTutor. Feels like it fits in a shoe box, right? This is roughly what Google has paid for XSS for 2 years.

32. <img src=x onerror=alert(1)>

    Cross-Site Scripting happens when a bad guy injects a JavaScript into the page. They can also inject an img tag with onerror handler, not just a <script> tag.

33. alert(1)

    When XSS is demonstrated or reported, it mostly comes as an alert(1). While this really is a proof that the attacker is able to run JavaScript, it might not be enough to convince somebody that Cross-Site Scripting is dangerous and deserves a fix.

34. < → <, > → >, " → ", ' → ', & → &

    When developers forget to convert these special characters, mostly the first four lines, in user input to HTML entities, that's when bad things (and XSS) happens.

35. BeEF: The Browser Exploitation Framework Project

    But XSS is much more than just alert(1). Meet BeEF, the XSS framework. It comes with some 300 predefined modules, like fake Flash update notifications, fake login windows, code to take screenshots of pages, or play an audio file.

36. 2ⁿᵈ line of defense

    Developers quite often forget to escape special characters in input, and will keep doing so. Because deadlines, bad coffee, or one too many beers. So we need this.

37. “Don't worry, I gotcha…”

    A 2ⁿᵈ line of defense, like this one, might not work for all cases and/or users, but when primary defense layer fails it might just save your life. Or cookies.

38. Bunny steals cookie from baby

    Speaking of stealing cookies… this is exactly how it works.

39. PHPSESSID HTTP-Only cookie

    To prevent JavaScript from stealing your session cookies, mark them as HTTP-Only in the app you've built. Such cookies will still be sent over the wire, but JavaScript won't see them, so an attacker won't be able to hijack the session using XSS. They still might be able to sniff the cookie when it's sent over plain HTTP, though.

40. XSS Auditor

    Yet another 2ⁿᵈ line of defense was built right into your browser if you used Chrome or Internet Explorer, or Edge. It's not built into Firefox, but again, it's not a primary defense layer. It was removed from Chrome, Chromium, Edge in version 78. The XSS auditor, or XSS filter, prevents the reflected variant of XSS.

41. :-| → 1 → :-) → 2 → App → 3 → :-)

    This is how reflected XSS works. The attacker sends a link with some evil JavaScript in the URL to the user (1), user clicks the link and a request is being sent to the web application (2). The request includes the JavaScript, which in turn gets injected into the page and is send back to the user (3) and is executed in their browser. The browser sees what's coming back from the application and if it looks like the JavaScript it sent out with the request then the XSS filter gets triggered, if enabled.

42. X-XSS-Protection: 1; mode=block

    You can control the XSS filter by the X-XSS-Protection response header. Using mode=block is recommended, and will make the browser not display the page at all.

43. ERR_BLOCKED_BY_XSS_AUDITOR

    mode=block was also the default setting in Chrome 57–73. Previously, the browser tried to clean the page (and Chrome 74+ does that too, until the whole feature was removed in Chrome 78). You can test your browser's XSS auditor on my demo site, check the devtools console error message too.

44. Response Headers: Content-Security-Policy

    Content Security Policy is the latest addition to already existing 2ⁿᵈ lines of defense against XSS. It's a response header which provides a list of allowed URLs for the browser to load images, JavaScript, CSS, etc. from into the page. So even if in the attacker is able to inject a <script> tag into the HTML the browser will not load the code from the specified URL provided the host or path is missing from the whitelist.

45. Content-Security-Policy: default-src 'self'

    The Content-Security-Policy response header might look like this basic example. This will allow JavaScript, images, CSS and some more to be loaded into the page associated with the header only from 'self', the current origin.

46. Content-Security-Policy: default-src 'self'; img-src 'self' https://www.google-analytics.com

    The header can be extended by allowing images also from https://www.google-analytics.com for the Google Analytics tracking script to work properly. The script itself would need to be loaded from current origin now, and that's not how it works.

47. Content-Security-Policy: default-src 'self'; img-src 'self' https://www.google-analytics.com; script-src 'self' https://www.google-analytics.com 'unsafe-inline'

    The origin for the Google Analytics script can be added to the whitelist too. The inline JavaScript is also allowed here by using the 'unsafe-inline' directive. Yes, the JS code written directly in the HTML using <script> tags or handlers like onclick might be dangerous so it is called unsafe. But some libraries and/or tools need it.

48. CSP ✅

    Tools like the Google Tag Manager make CSP deployments hard. You need to make your policy quite open, allow a lot of origins, or hostnames, enable inline JavaScript. And that's just making it easier for the attacker to find an opportunity to inject their code. You can test your policy with CSP Evaluator to see if it can be bypassed. To make deployments easier, CSP level 3 introduces 'strict-dynamic' which makes the browser ignore host-based whitelists, and only works with nonces. But enables the already allowed script to load more scripts without actually extending the policy. See how 'strict-dynamic' works and test it on my CSP3 demo page.

49. Stop executing scripts on this page

    To err is human, obviously, so please think about multiple lines of defense when building apps because even 20 years old attacks are still hot and dangerous.