Wednesday, July 26, 2017

BHUSA17: Fighting the Previous War

This talk is brought to us by the folks at Thinkst. Back in 2009, they worked on various attacks in the cloud. Attacks like taking extra resources from Amazon. Amazon limited each account to 20 machines, but then they'd get their 20 machines to each get 20 machines... and so on. Cloud is different and needs different thinking.

People still think SaaS as "another webapp" or "just a linux host", but it is very different and should be treated as such.

Footprinting is under-valued. While pentesting a network, they'd spend the bulk of the time finding all the machines - often long forgotten boxes.

Hardly anybody is setting up sendmail anymore, but their apps are sending emails. They need microservices for this, but where do the responsibilities live?  Who is processing your email, and who is making sure the services you integrate with are behaving properly (or used correctly). (reference: White Hats - Nepal: Bug Bounty from Uber, read).

Canary tokens is a framework released in 2015 is a framework to make honeytokens easy to get. It can help you learn about attacks on your systems.

You have to keep in mind that attacks don't look like they used to - devices are getting harder, but boundaries are fuzzier.

Looking at the Atom editor, there are lots of plugins available - it's easy to put in a malicious plugin. You can then easily steal keystrokes or get a user to unknowingly run commands for you. The plugins are not screened and can be very complicated.

This is no longer just hosted virtual machines. Look at how WordPress Hosting on AWS works - it only touches one virtual machine, but there is a very big graph of very complicated issue.

To attack AWS a good bit of recon is to find account ids. It is a 12-digit number, considered private (but not secure).  You can make one call with a valid account ID and an invalid ID and get different responses.  It works, but it is very sloooooow

But you can find these more easily by looking at github or on help forums. Even though Amazon says to not post them, people do. Easy!

Another area to do recon is on the S3 bucket discovery, similar discovery vectors. Areas of potential compromise are around the APIs, for example it is possible to enumerate permissions with a variety of calls without actually knowing what the permissions should be.

Sadly running out of battery.... posting now!

BHUSA2017: Automated Testing of Crypto Software Using Differential Fuzzing

JP Aumasson and Yolan Romailler

JP just released a new book on cryptography - check it out. Yolan is working on his masters.

What do we want to accomplish? We want to prove valid functionality works and that the program cannot be abused and secrets won't leak. They are testing code against code. For example, if you're porting from one language to another, they should be able to do the same things. (the assumption is that the reference code is correct - not always true!).  Additionally, want to test the code against the specifications, though those are sometimes not even complete or leave exercises to the users.

Automated testing can cover static analyzers, test vectors, dub fuzzing, smart fuzzing and formal verification. With things like test vectors, the more vectors you have, the better your coverage. That's a lot of testing, so need to think about how to maximize the efficiency (ease of use x coverage).

There are limitations on the current methods, like randomness quality, timing leaks and test vectors focus on valid inputs.

The researchers came up with a new tool, CDF, to do crypto differential fuzzing. It's a command line tool written in Go, portable to WIndows/Linux/MacOS and made it fast so it won't be a bottleneck. This tool will check for both correctness and security of implemetnations and interoperability between implementations. It will check for insecure parameters, non-compliance with standards (e.g. FIPS) and edge cases for specific algorithms.

This is similar to WycheProof, but different. The two tools will complement each other.

One of their checks for ECDSA will make sure that sending 00 hash or 00 secret key will not send it into an infinite loop. For RSA they do various checks for timing leaks.  With their testing, they found potential DoS with OpenSSL.

Discovered that most libraries are not testing the DSA parameters, found issues with almost every library tested. Even though they did not find issues with DSA in crypto++, it doesn't mean they don't exist - just the test did not trip over it.

Several libraries got an infinite loop with generator set to 0 in DSA. It's not allowed by the  standard, but tripped over several libraries.

Still working on adding additional tests and making the suite more robust.

BHUSA17: How We Created the First SHA-1 Collision and What It Means for Hash Security

Elie Bursztein

There are two other types of attacks, besides collision attack, and those are pre-image attacks (not feasible at this time).

When doing this attack, could not use bruteforce as you would need millions of years of bruteforcing with a GPU - we don't have that much time. Better to use cryptanalysis!

Before you can attack, you must understand how a hash function is constructed. In SHA1, we use a Merkle-Damgard construction. This works by taking the first block of the file, adding an IV and perform compression. Then go block by block until you get to the end and you have a short string of compression that is related to the file.

We got  a cool picture of what SHA1 compression looks like "unrolled". To do cryptanlysis, need to look at the messages differential path and the equation system (we have solved 16 steps and that makes it predictable to step 24).

It turns out it is easier to do collision wit two blocks instead of 1 block. Find two blocks that have almost the same hash for a near collision, then resolve the difference to get a full collision.

So - how do you exploit this? Look at a fixed prefix attack for SHA1. Finda prefix before you find a collision. If you carefully choose the prefix, you can improve the attack.

Let's take a look at real world attacks exploiting MD5. In 2009 there was an SSL certificate forgery. This was exploited by leveraging wildcard (instead of domain name) and adding the old public key and signature as a "comment" in the new certificate.

In 2012 there was massive malware called "Flame" that was used to spy on Iranian computers with fake windows update certificates. The collision in practice used 4 blocks, instead of 2. Shows that the attackers had their own cryptographer.

As of today, MD5 is broken - you can create collisions on your cell phone. For SH1 you still need a lot of time with current computing power.

So - how do create a new collision? Choose carefully what prefix you want, as you cannot change it after the fact. Through 2015 and 2016, worked on near-collision blocks. Used about 3000 CPUS for about 8 months to calculate a near collision. Throughout 2016 worked on a full collision attacka nd 2017 the attack was completed.

You have to find a tradeoff between failure and efficiency and continue to scale the computation. This team did it in 1 hour batches.

In 2016 found their first collision - had to spend a few days analyzing it, and they found a problem. It wasn't usable for finding a full collision.

The team had to make efficient use of GPUs. Work step by step to generate enough solutions for the next step, always try to work at the highest step and backtrack when pool empty.  Also, the work was parallelized: one thread and one solution.

The new attack is called Shattered - it takes 110 GPU for 1 year, which is less than 12milion years for bruteforce. We saw a demo of getting two different PDF files to hash to the same SHA1 hash (but still have different SHA2 hashes)

This is already being exploited, for example on WebKit.  A developer submitted a test to prove WebKit was resistant but tripped an unforeseen bug in SVN and took the site down.

The collision is in the wild - what to do with the legacy software? SHA1 is deeply integated into GIT - how can they protect themselves? They can test for collisions and has negligilve false positives.

The takeaway: SHA1 is dead. Do not do new deployments with it and try to move away from it. We need to continue doing counter-cryptanalysis and keep in mind hash diversity.

BHUSA17: When IoT Attacks: Understanding the Safety Risks Associated with Connected Devices

Billy Rios, Jonathan Butts

There will be 26-30 billion connected devices by 2020! Need to worry about confidentiality, integrity and availability - but is that enough? Is there something more imortant than keeping your credentials safe? Yes - safety! Many of these devices are controlling environmental factors in laboratories, chemical mixtures, etc.

Rios and Butts looked at devices conencted to the internet, in a public space accessible to the general public, and exploitation of the device could result in a safety issue.

Currently, there are only a few devices that meet all 3 criteria. One surprising device they found - car washes! The looked at Laserwash. Car washes are really just industrial control systems (ICS) - and come with all the attitude and controls those systems come with. The car wash is different than most ICSs - it's accessible to the general public, with no screening at all.

The researchers wrote an exploit that can cause a car wash system to physically attack an occupant. Currently there is no patch for the vulnerability - if you own one of these car washes, please contact the manufacturer.

The big takeaway here - you should wear a hard hat to go into a car wash.

When Charlie and Chris attacked a car, they had to buy a car and about $15,000 in tools to analyze the car. The systems are so specialized you must buy specilized tools. In that referenced paper, the tools they bought were only good for Fiat-Chrysler vehicles.

Their cost considerations - acquired firmware in 2014 through compensated operator. Did not find a willing owner until 2017 (which they also had to compensate and pay for the car washes).  Buying a carwash is a large sum ($250K?) - so they really had to find people that already owned them that were interested in the academic interest. shouldn't there be a better way? Should manufacturers give access to systems?  Without this, researchers are looking at live and deployed systems and spending their own money.

Initially disclosed the bug to vendor in February 2015. Reached out repeatedely through April 2017... still no response. In May they got a fully working remote exploit code (PoC) - still no response. Once posted to BlackHat schedule, vendor asked if they tested against a demo system.

From other vendors, got a lot of comments like "that's not how we designed the system to work", etc. so writing up a vulnerability is not sufficient. Researchers had to do the PoC and prove their exploit worked - very costly and time consuming. Could vendors do better?

Need to remember these devices are just a computer - the car wash has storage, cables, disks, programs. Older car washes had a manual physically connected interface with a joy stick to manually control the arm, etc. Now they have close proximity remotes. If you are within line of site of the car wash, you can control the car wash.

When these car washes are deployed, they likely come with warnings for the new owner that the car wash is connected to the Internet. But, why?  You can configure the car wash to send emails. Maybe the owner wants to see how many car washes happened in any given day, which packages are the most popular and what times are the busiest - business reasons.

But - this car wash is on facebook, YouTube and LinkedIn. Now, that is perplexing.

At the end of the day, this is a computer running WindowsCE, Intrinsyc Rainbow web server with a Binary Gateway Interface. Windows CE is end of life - there is no more support for any vulnerabilities.  The webserver calls mapped to an unmanaged ARM DLLs. There are a lot of DLLs on the system that could be abused.

From the web browser, you can point to various DLLs and access them directly via rbhttp22.dll.

Now... there are credentials. The owner credentials are ...12345. This gives you all access, including free car washes. THe engineer creds (PDQENG) are 83340.  But, the researchers don't think having the default creds is a true exploit.

There is a PLC driving the functioality of the car wash. This is a system of systems, lots of communication happening. There are 3 key DLLs for exploits.

They won't be publishing the details of the exploit, because these vulnerabilities are just not fixed.

One of the basic issues is that authentication is handled very simply. The authentication level is set to OWNER before the credentials are checked...Just cause an exception in the authentication routine, and you will remain as OWNER!

It doesn't matter if the owner changes tha password, you can read it back.

The researchers identified where the hardware safety mechanisms were - those are difficult to override, much easier to do the software mechanisms. An example of a hardware mechanism si an example of a welded on safety stopper - more difficult to defeat.

Software controls the doors that go up and down, after interacting with sensors that report "all clear". You can exploit the door, for example, to disregard the response from the sensors. Video was shown of a car wash door crushing th ehood of a car that was only part way into the car wash.

There is another issue with CVSS scoring. There is a medical infusion device with a vulnerability that can kill the user - it's rated at 7.1.  A bug in a medical cabinent that allows people to steal drugs - 9.7. Why should that be "more severe" than death?  The speakers have additionally been working on a scoring system specifically for medical devices.

You cannot rely on software solely for physical security, and you should never respond to a vulnerability researcher with "the system wasn't designed to do that" :-)

BHUSA2017: BlackHat USA posts will be out of order

Due to connectivity issues, some posts are being written offline. Hope to get them up by the end of the week, but will live blog what I can.

Friday, May 19, 2017

ICMC17: Thomas Jefferson and Apple versus the FBI

Daniel J. Bernstein, University of Illinois at Chicago & Technische Universiteit Eindoven

Gutenberg's original printing press was based on a wine press - who knew? If you think beer or wine is dangerous, you may think the best thing to do is prohibit alcohol. In 1919, the Womens Christian Temperance Union requested that the public library to remove books and pamplets on the home production of alcohol for drinks. the librarians would not destroy the books, but did remove them from public access.

Why do censors try to ban instructions? "It might be bad if people follow these instructions" - stop people from acting on information.   We have freedom of speech, though, so we shouldn't accept this. You can try to hide the information, but they will still find it and figure it out. Censorship adds very little benefit, and often causes massive damage.

There are careful exceptions to free speech in the US- you cannot intentionally solicit criminal activity. You also cannot advocate an imminent lawless action if it's likely to produce such an action: "Let's burn down that mosque" - not protected by free speech.  You also can't make false promises (breach of contract), deceive people for profit (fraud), or make false statements that damage reputation with reckless disregard for the truth (defamation).

What about training videos? Is Ocean's Eleven a training video? What about Tom Clancy's Debt of Honor, 1994 that described something very similar to 9-11 attacks. Some people also don't want to see historical documents and books on things like Kamikaze pilots - what if terrorists act on these examples?  It turns out they will come up with it themselves, even without such inspiration.
So, the court has to look at it from the point of view - are you intentionally aiding and abetting criminal activities?

What if a terrorist stays hidden and alive in the woods by reading a book on "how to fish"? It's clearly not intended to help criminals.  That type of book is protected under free speech.

On software - it's usually (always?) something a human could do/calculate by hand, with time, but we're using the computer to help make it faster. If you hear statements from the government that is talking about restricting computers - remove the word "computer" and see if the same rationale for censoring instructions followed by people?

People are using encryption to protect files and conversations, as the FBI calls it "going dark".  So, should we be allowed to publish encryption software?  Imagine if you remove the computer from this situation

Jefferson and James Madison communicated via 'encrypted' messages, encoded. Thomas Jefferson distributed instructions that James Madison used, by hand, to encrypt private letters. No computer involved here, doing it by hand. What if they  published how to do this in a book? And then a criminal used it, and the FBI comes and says you can't publish this. Is that allowed? If the book is intended to help criminals, the government can censor.

Lawyers will claim that free speech needs a software exception. Imagine sw made to destroy navigational systems on airplanes? What if it was a book that described how to do this? The computer is irrelevant to the question. The courts should look at the intent, just like they do when you present them with a book.

According to the FBI, in 1963, the Domestic Intelligence head thought he was a Russian agent. In 1964 he won the Nobel Peace Prize. In 1964 FBI sent King an anonymous letter encouraging him to commit suicide.  In 1967, NSA also started surveillance on King.

As far back as 1977, the NSA (Joseph Meyer) threatened  organizers of a crypto conference with prosecution under export laws.

For Dan himself, he sent a crypto paper and crypto software to NSA asking them for permission to publish. NSA refused, classifying paper and software as "munitions" and subject to export control.  Though in 1995, the NSA told the courts they were trying to protect America - but papers were okay (free speech) and allowed Dan to publish the paper (but not the software).

Unfortunately for the NSA, Judge Marilyn Hall Patel disagreed with them in 1996, and agreed that software was free speech. It's just language. The court of appeals agreed in 1999.

Now back to modern day - Apple vs FBI - but imagine w/out the computer. Imagine the FBI coming to Jefferson and demand that he write a new anti-encryption instructions and falsely sign those instructions as being legitimate.  Jefferson says that the instructions are too dangerous to create. The US Supreme Court notes that freedom of speech includes "both what to say and what not to say".

Ask yourself - what is the software doing in this picture?  What if we were doing this ourselves? The courts know how to handle that and you should, too.

ICMC17: Zero Knowledge Doesn't Mean Zero Ethics

Joshua Marpet, SVP, Compliance and Managed Services CyberGRC

Zero knowledge system: A mathematical proof: zero knowledge proofs and verifiable secret sharing are vital for mutli-party secure sharing. Can be used in health care, blockchain, etc.

Can use blockchain in  healthcare to exchange information across health care networks (for example between a hospital in DC and hospital in California).

How do you know you are working with an ethical party? Is the NSA ethical? What about Geek Squad? If you are building a zero knowledge system, will you be fostering bad ethics?  For example, the blockchain for bitcoin contains child porn.

Think about free speech - you can talk about all things, but not necessarily incite behaviours. For example, you cannot shout fire in a theater.

So, you need a very clear Terms of Servie and Acceptable Use and a provisioning checkbox along the lines of "Will you be hosting illegal content?"  Yes, they can break it - but then you will not have an ethical conundrum when law enforcement asks for that users illegal data.

Now, don't be a bad provider. Don't monitor your customer's content, be inconsistent or non responsive. Respect warrants - but use reason. Something doesn't seem right? Consult your lawyer, EFF, etc.