QUALITY OF LIFE

Michal paek www.michalspacek.com @spazef0rze

Yep, thats 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.

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.

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

Im 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

In July 2016, before the breaches were disclosed, Verizon announced its intent to acquire Yahoos 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.

Russian agents were behind Yahoo hack, U.S. said in March 2017. I dont want to go into attribution business but lets focus on the small text below the picture

Right, that seems quite bad. Id say Mayers quality of life has changed a bit.

Blackmailing

Because
Plaintext passwords

A friend of mine called me some time ago, his voice shaking. He told somebody has hacked alegacy site his company had built. Unfortunately the site stored user passwords just like this and the attacker said hed 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 didnt pay the ransom, and fortunately database was not released.

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.

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 couldnt be confirmed as events linked to the leak, like the San Antonio police captain case.

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.

This is Mark. Mark runs Facebook. Mark used the same password for LinkedIn, Pinterest, and Twitter. Dont be like Mark a dont 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.

In June 2016 a group called OurMine posted Marks password, dadada, on his Twitter.

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.

0f158e648228a19cab5f23acfd6c36f716a702a9

SHA-1 hash

Zuckerbergs password was stored hashed in the LinkedIn dump, this is the hash. But when passwords are hashed with unsalted SHA-1, its quite easy to crack them.

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

When a Google search is not enough, or if you want to crack passwords for living, youll 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.

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

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

https://haveibeenpwned.com

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.

Variable bindingHTTPSFirewalls

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.

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.

Password hashing, a second line of defense, protects users and their passwords when databases leak. Database leaks shouldnt 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/passwords/storages.

Heres 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 apublic 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.

Slow password hashes + docsSlow pw hashes + blog, FB, Twitter

SECURE

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 atalk or a blog post is quite invisible. Both A and B are scores for safe password storage.

Other hashes + salted + iterationsOther hashes + saltedOther hashes, or encrypted

WEAK

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.

FAILFAILFAILFAILFAILFAIL

UNSAFE

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.

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.

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

$1.2 million

Just in 2014-2016 Google has awarded researchers over $1.2 million for reporting XSS bugs in their applications via Googles Vulnerability Reward Program. Not bad.

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.

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 tag.

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.

< >" "' '& &

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

The Browser Exploitation Framework Project

BeEF

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.

2nd 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.

A 2nd 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.

Speaking of stealing cookies this is exactly how it works.

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

XSSAuditor

Yet another 2nd line of defense is built right into your browser if you use Chrome or Internet Explorer, or Edge. Its not built into Firefox, but again, its not a primary defense layer. The XSS auditor, or XSS filter, prevents the reflected variant of XSS.

WEB
APP

1

2

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 whats 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.

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.

mode=block is also the default setting since Chrome 57. Previously, the browser tried to clean the page. You can test your browsers XSS auditor on my demo site.

Content Security Policy is the latest addition to already existing 2nd lines of defense against XSS. Its 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 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.

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.

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 thats not how it works.

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 tags or handlers like onclick might be dangerous so it is called unsafe. But some libraries and/or tools need it.

csp-evaluator.withgoogle.com

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 thats 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.

Michal paek www.michalspacek.com @spazef0rze

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.