Show Notes: linuxunplugged.com/415

The post Something Sinister Below Deck | LINUX Unplugged 415 first appeared on Jupiter Broadcasting.

How to get an SSL certificate for other people’s domains, how to decrypt HTTPS traffic with some javascript & the latest storage reliability report.

Plus great questions & a rocking round up!

Thanks to:

• Get Paid to Write for DigitalOcean

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Show Notes:

Keeping Positive: Obtaining wildcard SSL certificates for arbitrary domains

I recently decided to investigate the security of various certificate authority’s online certificate issuing systems. These online issuers allow certificate authorities to verify that someone owns a specific domain, such as thehackerblog.com and get a signed certificate so they can enable SSL/TLS on their domain.

When I started out hunting for possible vulnerabilities, my initial strategy was to look for the cheapest, most 90’s-looking, poorly designed certificate authority websites. Since the compromise of any certificate authority allows an attacker to bypass all the protections of SSL/TLS it doesn’t even have to be a popular provider because they all have the same power. After doing a bit of searching I realized it would be advantageous to do testing against authorities that had free SSL certificates, since doing tests against these wouldn’t cost me any money. I passed on Let’s Encrypt because I figured it had already been thoroughly audited, the second site I saw was a 30 day free trial from Positive SSL (a company owned by Comodo).

Upon entering your CSR and selecting the software you used to generate it, you then select the email address for domain validation (from the website’s WHOIS) and arrive on a “Corporate Details” page. This is the vulnerable portion of the application, where you fill out your company/personal information getting to the email validation portion

When I first went through this process I mindlessly filled out junk HTML for all of these fields. The service then sent a verification email to the email address on the website’s WHOIS info. Once I received the email, I noticed the HTML was not being properly escaped and the markup I had entered before was being evaluated. This is really bad because the email also contained a verification code which could be used to obtain an SSL/TLS certificate for my website. This means if I had a way to leak a victim’s token, I could obtain a valid certificate for their site, so that I could intercept traffic to that site seamlessly without users knowing I was doing so

• Normally, the email provides the user with a link and the code to validate the certificate. However, because an attacker can fill out the form fields with HTML, they can change the message in the email, instead requiring you to click a link within the next 24 hours to REJECT this bogus certificate
• So, in the field he wrote some HTML that included an form tag and a textarea tag that was never closed
• This resulted in everything that appears after that field in the email, being swallowed by the text area, rather than the body of the email.
• Then a later form field adds a button, “click here to reject this request”. When the user clicks the button, it submits the contents of the HTML textarea (including the verification code) to the attacker’s website, giving them the code, allowing them to approve the certificate for YOUR domain

Form submissions are a great way to leak secrets like this because they work in many different mail clients. Even the iPhone’s Mail app supports this functionality

Once I’ve leaked the code from the victim in this way, I can then log into the account I created during the certificate request process and download the SSL/TLS certificate

One other important thing to note is that resellers of Comodo’s certificates were also affected as well. This risk is amplified because resellers can have a customized HTML header and footer for the verification emails that get sent out. This means that it would be possible for a third party vendor to have a dangling tag in the header combined with a single quote in the footer which would side-channel leak the verification code in the email body (similar to the attack above, but automatic with no user interaction). This style of dangling mark-up injection wasn’t possible in the previously proof-of-concept but is possible for resellers.

• Timeline:
• June 4th, 2016 – Emailed security@comodo.com and reached out on Twitter to @Comodo_SSL.
  • June 6th, 2016 – Robin from Comodo confirms this is the correct contact to report security issues, provides PGP key.
  • June 6th, 2016 – Emailed Comodo the vulnerability PGP-encrypted and sent my PGP public key.
  • June 7th, 2016 – Robin from Comodo confirms they understand the bug and state they will work on a fix as soon as possible.
  • June 20th, 2016 – Emailed Comodo for status update.
  • July 1st, 2016 – Outline timeline for responsible disclosure date (90 days from report date per industry standards).
  • July 25th, 2016 – Robin from Comodo confirms a fix has be put in place.

Normally, the name of the game when it comes to finding a way to mint arbitrary SSL/TLS certificates is to find the smallest, cheapest, and oldest certificate provider you can. Comodo is the exact opposite of this, they have a 40.6% marketshare and are the largest minter of certificates on the internet. Basically, they are the largest provider of SSL/TLS certificates and yet they still suffer from security issues which would be (hopefully) caught on a regular penetration testing engagement. This paints a grim picture for the certificate authority system. If the top providers can’t secure their systems, how could the smaller providers possibly be expected to do so? It’s a hard game to play since the odds are heavily stacked in the attacker’s favor with tons of certificate authorities all with the power to mint arbitrary certificates. A single CA compromise and the entire system falls apart.

Luckily, we have some defences against this with newer web technologies such as Public Key Pinning which offers protection against attackers using forged certificates. This is a fairly powerful mitigation against an attacker with a forged certificate. However, the support is iffy with a lack of support in Internet Explorer, Edge, Safari, and Safari on iOS.

Many people like to speak of a certificate authority hack as if it was something only a nation state could accomplish, but just a day’s worth of searching led me to this issue and I don’t doubt that many providers suffer from much more severe vulnerabilities. What happens when your attacker doesn’t care about ethical boundaries and is willing to do much more in-depth testing? After all, this is Comodo, the largest provider. What about the smaller certificate providers? Do they really stand a chance?

HEIST: New attack allows stealing sensitive information web HTTPS encrypted pages

• HEIST: HTTP Encrypted Information can be Stolen through TCP-windows
• This new attack exploits how HTTPS responses are delivered over TCP, and how compression is used, and the new Javascript API

The exploit is notable because it doesn’t require a man-in-the-middle position. Instead, an end user need only encounter an innocuous-looking JavaScript file hidden in an Web advertisement or hosted directly on a webpage. The malicious code can then query a variety of pages protected by the secure sockets layer or transport layer security protocols and measure the precise file sizes of the encrypted data they transmit.

Once attackers know the size of an encrypted response, they are free to use one of two previously devised exploits to ferret out the plaintext contained inside it. Both the BREACH and the CRIME exploits are able to decrypt payloads by manipulating the file compression that sites use to make pages load more quickly.

• “HEIST makes a number of attacks much easier to execute,” Tom Van Goethem, one of the researchers who devised the technique, told Ars. “Before, the attacker needed to be in a Man-in-the-Middle position to perform attacks such as CRIME and BREACH. Now, by simply visiting a website owned by a malicious party, you are placing your online security at risk.”
• Rather than having to visit a malicious website, all that is required is that you end up being served a malicious advertisement, on any website

Using HEIST in combination with BREACH allows attackers to pluck out and decrypt e-mail addresses, social security numbers, and other small pieces of data included in an encrypted response. BREACH achieves this feat by including intelligent guesses—say, @gmail.com, in the case of an e-mail address—in an HTTPS request that gets echoed in the response. Because the compression used by just about every website works by eliminating repetitions of text strings, correct guesses result in no appreciable increase in data size while incorrect guesses cause the response to grow larger.

To determine the size of an HTTPS-protected response, the attacker uses an oracle technique that returns what amounts to a yes-or-no response to each guess. When a request containing “value=” results in the same data size, the attacker knows that string is inside the encrypted response and then tries to modify the guess to include the next character, say “value=0”. If that guess results in a larger file size, the attacker knows it’s wrong and will try “value=1”, “value=2”, and so on until the new guess similarly results in a response that shows no increase in file size. The attacker then tries to guess the next character and repeats the process until the entire token has been recovered.

Until now, this BREACH-style exploit required the attacker to be able to actively manipulate the traffic passing between the Web server and end user. A HEIST-enabled BREACH exploit removes that limitation. It does this by using TCP characteristics as a quasi cryptographic side channel to measure the size of an HTTPS response. TCP divides large transmissions into smaller fixed-sized chunks called frames and further groups frames inside what are called TCP windows, which are sent one at a time. TCP sends a new window only after receiving confirmation that frames from the previous window were received by the end user.

HEIST is able to count the number of frames and windows sent by interacting with a set of newly approved APIs, one called Resource Timing and another called Fetch. In the process, they allow a piece of JavaScript to determine the exact size of an HTTPS response.

Van Goethem said the only mitigation he knows of is to disable the third-party cookies, since responses sent by the HTTPS site are no longer associated with the victim. At the moment, most Web browsers by default enable the receipt of third-party cookies, and some online services don’t work unless third-party cookies are allowed.

Wednesday’s demo will show how a malicious ad displayed on The New York Times website is able to painstakingly measure the size of an encrypted response sent by a fictitious third-party site they dubbed targetwebsite.com (see the image below). It will go on to show how that information can be used to infer the characters contained in a security token designed to prevent cross-site request forgery attacks

• And, we are not protected by the next generation HTTP protocol either

HEIST is also effective against HTTP/2, the drop-in replacement for the older HTTP standard that encrypts all Web traffic. In some cases, HEIST can abuse new features of HTTP/2 to increase the damaging effects.

• If we know that HTTP/2 is used, we can let the browser simultaneously request the targeted resource, and another resource that contains reflected content,” Vanhoef and Van Goethem wrote in a research paper.

Since HTTP/2 is used, both requests are sent in parallel to the server, and the server replies to them in parallel as well.

It’s too early to know if HEIST combined with BREACH will be exploited against real people visiting real HTTPS-protected websites. While there’s no indication that BREACH has ever been exploited in the wild, the new convenience offered by HEIST may change that.

• Blackhat Slides
• Research Paper

Backblaze: 2016 Q2 hard drive failure rates

• Backblaze has published their latest numbers on drive failures
• This is the first report to feature the newer 8TB drives
• As before, the HGST drives are doing very well, although some models seem to be doing better than others. The Seagate drives are on spec, and the Western Digital drives are not doing so well. Although there is relatively few WD drives, not because of the high failure rate, but as explained in the 2016Q1 report, just difficulty acquiring large numbers of them
• Almost half of all drives in BackBlaze are the Seagate 4TB desktop model
• I think it would help for BackBlaze’s formula to consider the age of the drive. Of course the failure rate of older drives will increase over time. It would be interesting to see a graph of the failure rate vs drive age
• The Seagate 4TB drives seem to be doing as expected. I feel confident in my decision to purchase these exact drives for my own use
• Backblaze explains their formula, and reminders readers to consider the formula when looking at the numbers. A single drive failure in a new set of Toshiba 5TB drives gives a result of a nearly 9% failure rate, but obviously the sample set is too small
• There is also an interesting discussion of their migration process, moving data from 64+ month old hard drives to new larger drives
• Further down, they also provide a breakdown of their failure statistics from 2013 through 2016, which makes for much more interesting reading
• In general, most of the drives seem to perform as expected, with a 1 – 3 % annual failure rate
• Of course, BackBlaze does not buy the fancier Enterprise drives. Hopefully someone else will produce a similar report using Enterprise drives, so we can see if they are worth the extra money.

The 4TB Seagate drives are our workhorse drives today and their 2.8% annualized failure rate is more than acceptable for us. Their low failure rate roughly translates to an average of one drive failure per Storage Pod per year. Over the next few months expect more on our migrations, a look at the day in the life of a data center tech, and an update of the “bathtub” curve, i.e. hard drive failure over time

• If you would like to do your own thing with the data, here it is

Feedback:

• Any way to guess or estimate how many drives would be needed? // Slexy 2.0

• how secure are long unique links?

• Google’s Unguessable URLs – Schneier on Security

• Redirecting domain requests, mail and linking droplets

  • DNS Made Easy for dns or backup mx

• Hosting your own email – follow up to Feedback Episode 277

Round Up:

• Networking hardware vendor TP-Link today admitted violating US radio frequency rules by selling routers that could operate at power levels higher than their approved limits. In a settlement with the Federal Communications Commission, TP-Link agreed to pay a $200,000 fine, comply with the rules going forward, and to let customers install open source firmware on routers
• FireFox 48 finally ships, with multiprocess support. For the next few days, only a fraction of a percent of Firefox 48 users will have Electrolysis turned on by default. If this mini-rollout goes well, the multiprocess feature will be rolled out to about half of all Firefox 48 users
• Malvertising Campaign Infected Thousands of Users per Day for More than a Year
• EFF Files lawsuit challenging DMCA provisions that place restrictions on security researchers
• Iranian hackers compromise Telegram’s secure messaging
• FireEye releases: Overload: Critical lessons from 15 years of ICS vulnerabilities
• QRLJacking attack can bypass any QR login system
• Something I have been saying for years, FTC says frequent forced password changes are the enemy of security Allan’s post from 2009 came to the same conclusion
• Japanese Olympic Gymnist racks up $5000 mobile data bill playing Pokemon go in Brazil
• Deanonymizing Windows users and stealing Microsoft and VPN accounts
• SwiftKey was accidently sharing your autocorrect suggestions with other people, leaking email contents, search history, and more

The post Dangerous Dangling Quotes | TechSNAP 278 first appeared on Jupiter Broadcasting.

A Critical OpenSSH flaw can expose your private keys, a new WiFi spec for IoT devices, that has all the classic issues & Intel’s SkyLake bug.

Plus your feedback, our answers, a rockin’ round up & so much more!

Thanks to:

• Get Paid to Write for DigitalOcean

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

— Show Notes: —

Critical OpenSSH flaw can expose your private keys and other client memory

• Two major issues have been identified in OpenSSH
• CVE-2016-0777: An information leak (memory disclosure) can be exploited by a rogue SSH server to trick a client into leaking sensitive data from the client memory, including for example private keys.
• Vendor contributed code for a feature called Roaming, was added in OpenSSH 5.4, that allowed broken SSH sessions to be resumed. The server side code for this was never activated, only the commercial SSH server supported it.
• However, the Roaming feature is on by default, and due to a but a malicious server can exploit the bug to read memory from the client when it tries to connect to the server
• This includes the ability to steal your SSH private keys
• “The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers.”
• Because OpenSSH checks the host key of the remote server, if you are connecting to trusted servers, there is no risk
• You can disable the feature by adding the following line to your /etc/ssh/ssh_config: UseRoaming no
• The feature can also be disabled on a per-user basis using: ~/.ssh/config
• The patch just disabled this feature by default
• CVE-2016-0778
• A buffer overflow (leading to file descriptor leak), can also be exploited by a rogue SSH server, but due to another bug in the code is possibly not exploitable, and only under certain conditions (not the default configuration), when using ProxyCommand, ForwardAgent or ForwardX11.
• Both of these vulnerabilities are fixed in OpenSSH 7.1p2
• It is not clear if the roaming support will be removed entirely
• Researcher Post

Bug in Intel Skylake CPUs means complex workloads can hang the machine

• Intel has confirmed that its Skylake processors suffer from a bug that can cause a system to freeze when performing complex workloads.
• The bug was reportedly discovered and tested by the the community at hardwareluxx.de and passed onto GIMPS (Great Internet Mersenne Prime Search), which conducted further testing. Both groups passed their findings onto Intel.
• Intel states:

“Intel has identified an issue that potentially affects the 6th Gen Intel Core family of products. This issue only occurs under certain complex workload conditions, like those that may be encountered when running applications like Prime95. In those cases, the processor may hang or cause unpredictable system behaviour.”

• Intel has developed a fix, and is working with hardware partners to distribute it via a BIOS update.
• No reason has been given as to why the bug occurs, but it’s confirmed to affect both Linux and Windows-based systems.
• While the bug was discovered using Prime95, it could affect other industries that rely on complex computational workloads, such as scientific and financial institutions.
• Recently, Intel’s Haswell and early Broadwell processors suffered from a TSX (Transactional Synchronization Extensions) bug. Rather than recall the parts, Intel disabled the TSX instructions via a microcode update delivered via new motherboard firmware.
• Additional Coverage

New WiFi spec for IoT devices, WiFi HaLow likely has all the classic issues

• “The new protocol is based on the 802.11ah standard from the IEEE and is being billed as Wi-Fi HaLow by the Wi-Fi Alliance. Wi-Fi HaLow differs from the wireless signal that most current devices uses in a couple of key ways. First, it’s designed as a low-powered protocol and will operate in the range below one gigahertz. Second, the protocol will have a much longer range than traditional Wi-Fi, a feature that will make it attractive for use in applications such as connecting traffic lights and cameras in smart cities.”
• There is also talk of using it for wearables, I suppose as a replacement for bluetooth
• “Wi-Fi HaLow is well suited to meet the unique needs of the Smart Home, Smart City, and industrial markets because of its ability to operate using very low power, penetrate through walls, and operate at significantly longer ranges than Wi-Fi today,” said Edgar Figueroa, president and CEO of Wi-Fi Alliance.
• “But, as with any new protocol or system, Wi-Fi HaLow will carry with it new security considerations to face. And one of the main challenges will be securing all of the various implementations of the protocol. Device manufacturers all implement things in their own way and in their own time, a practice that has led to untold security vulnerabilities and innumerable billable hours for security consultants. Security experts don’t expect Wi-Fi HaLow to be the exception.”
• “While the standard could be good and secure, implementations by different vendors can have weaknesses and security issues. This is common to all protocols,” said Cesar Cerrudo, CTO of IOActive Labs, who has done extensive research on the security of a wide range of smart devices and smart city environments
• Who could possibly be worse at implementing security, than the vendors and government contractors that would be used for a “smart city”
• “Many of the devices that may use the new protocol–which isn’t due for release for a couple of years–are being manufactured by companies that aren’t necessarily accustomed to thinking about threat modeling, potential attacks, and other issues that computer hardware and software makers have had to face for decades. That could lead to simple implementation problems that attackers can take advantage of.”
• This seems to call for a nice clean BSD licensed implementation, although even then, everyone using the same implementation could be just as risky
• Plus, as we have seen, most vendors will ship an old insecure version, rather than the latest, and won’t update the implementation as they iterate their product
• The extended range of HaLow also means that attackers can come from much further away, making it harder to physically protect devices
• “Each new iteration in technology brings with it fresh security and privacy considerations, and the proliferation of connected non-computing devices is no different. The concept of a voice-enabled hub that controls your home’s climate, entertainment, and other systems is now a reality, as is the ability to send an email from your refrigerator. That’s all well and good, until these smart devices start doing really dumb things.”

Feedback:

• Will ZFS work for me?
• HTTP/2 Thoughts?
• UK Government Web Portal Hijacked by Russian Casino Spammers – (I just discovered this)

Round Up:

• US Intelligence director’s personal e-mail, phone hacked
• Seagate announces 10TB helium hard drive, 7 platters, 14 heads
• Why Is Comcast Interrupting My Web-Browsing To Upsell Me On A New Modem?
• Police say they can decrypted Blackberry PGP encrypted emails
• Cisco patches more hard-coded passwords
• Ontario court rules that police “Tower Dumps” violate the Canadian Charter of Rights and Freedoms
• Fixstars Releases 13 TB SSD for Specific Application Workloads
• Apple OS X memory management bug means your porn lives in your video card
• Daily Telegraph Installs Workplace Monitors On Journalists’ Desks

The post Internet of Threats | TechSNAP 249 first appeared on Jupiter Broadcasting.