https – Jupiter Broadcasting

Need more help than a radio show can offer? Altispeed provides commercial IT services and they’re excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show!

Altispeed Technologies

Contact Noah

asknoah [at] jupiterbroadcasting.com

— Twitter —

The post Starting a Business with Linux | Ask Noah 26 first appeared on Jupiter Broadcasting.

HPKP: Hard to Say, Hard to Use | TechSNAP 334

chris — Tue, 29 Aug 2017 21:57:11 +0000

RSS Feeds:

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

Become a supporter on Patreon:

Show Notes:

Using VPN for all WAN traffic

“I have a server with 2 1GB NICs, an un-managed switch, and a single gateway. Ideally, I would like WAN traffic routed through a PIA VPN
using openVPN, and LAN traffic to be routed locally without a VPN.”
Unmanaged switch isn’t ideal, but it’s far from bad.
Assuming the server will act as firewall / gateway
NIC #1 to router/modem, NIC #2 to switch with a static IP (say 10.1.1.1)
run a DHCP server on there, handing out 10.1.1.1 as the default gateway, DNS as you see fit
everything from LAN will go out via NIC #2 of server
server connects to VPN provider via OpenVPN. There are options on to set the default gateway. This is the gateway which the server will use. All traffic leaving your network will go out to that destination.
Not having used PIA, but I’ll guess you want your OpenVPN connection to accept their configuration settings (dns, etc) and use that on your server while it is running OpenVPN.

A Protocol For Distributed Multiparty Chat Encryption

review by nccgroup.
The protocol has the following security properties for group messaging:
Confidentiality: the conversation is not readable to an outsider
Forward secrecy: conversation history remains unreadable to an outsider even if participants’ encryption keys are compromised
Deniable authentication: Nobody can prove your participation in a chat
Authorship: A message recipient can be assured of the sender’s authenticity even if other participants in the room try to impersonate the sender
Room consistency: Group chat participants are confident that they are in the same room
Transcript consistency: Group chat participants are confident that they are seeing the same sequence of messages

I’m giving up on HPKP

what is HTTP PKP?
https://securityheaders.io – belongs to author
Be Afraid Of HTTP Public Key Pinning (HPKP)
Certificate Authority Authorisation – Later this year all CAs will be required to check a new DNS record called CAA before issuing a certificate – you can set a DNS record that specifies which CA you authorise to issue certs for your domain
Certificate Transparency – Once CT is a requirement no CA will be able to issue a certificate in secret without the owner of the domain knowing about it because it will be present in publicly visible CT logs. See crt.sh
OCSP leaks information
What is OCSP (Online Certificate Status Protocol)?

Feedback

Database migrations in Episode 332
Extra skimming prevention tip
Let’s Encrypt uses ~/.well-known/ directory – referenced in How It Works, but not named and explicity named in the Integration Guide

Round Up:

The post HPKP: Hard to Say, Hard to Use | TechSNAP 334 first appeared on Jupiter Broadcasting.

LetsEncrypt is a SNAP | TechSNAP 328

chris — Tue, 18 Jul 2017 22:47:27 +0000

RSS Feeds:

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

Become a supporter on Patreon:

Show Notes:

‘Devil’s Ivy’ Vulnerability

Beyond public key encryption

One of the saddest and most fascinating things about applied cryptography is how 6689264031_4c7516b3e1_zlittle cryptography we actually use. In fact, with a few minor exceptions, the vast majority of the cryptography we use was settled by the early-2000s.*
Identity Based Cryptography – In the mid-1980s, a cryptographer named Adi Shamir proposed a radical new idea. The idea, put simply, was to get rid of public keys.
Attribute Based Encryption – The beautiful thing about this idea is not fuzzy IBE. It’s that once you have a threshold gate and a concept of “attributes”, you can more interesting things. The main observation is that a threshold gate can be used to implement the boolean AND and OR gates

Dan’s Let’s Encrypt Tool

use case is centralized Let’s Encrypt with dns-01 challenges

Feedback

ARM & risc systems not readily sold. Intel and AMD have a very compelling AESNI and virt instructions, and PCIe
Host your own mail server – see https://www.nethserver.org/
PXE boot – see Zalman ZM-VE350
HOWTO: setup a PXE Server with dnsmasq
Cobbler – Linux install and update server

Round Up:

Alexa is listening to what you say – and might share that with developers – see https://nakedsecurity.sophos.com/2017/07/17/alexa-is-listening-to-what-you-say-and-might-share-that-with-developers/
Life Is About to Get a Whole Lot Harder for Websites Without HTTPS
BCBS sent out USB cards telling people to insert into their computer. Here is the prototype for the next big wave of security breaches.
Google Glass 2.0 is a startling second act
Google Glass is officially back with a clearer vision

The post LetsEncrypt is a SNAP | TechSNAP 328 first appeared on Jupiter Broadcasting.

Broadband from Space | TechSNAP 326

chris — Tue, 04 Jul 2017 22:52:58 +0000

RSS Feeds:

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

Become a supporter on Patreon:

Show Notes:

Low-latency satellite broadband gets approval to serve US residents

UK Cops Say Visiting the Dark Web Is a Potential Sign of Terrorism

Dark web was mentioned in a leaflet amongst other items to watch
Police in the capital (London) have reportedly been handing out leaflets listing what authorities deem as suspicious activity, in the hope that vigilant community members can continue to provide helpful information to law enforcement.

https://krebsonsecurity.com/2017/06/got-robocalled-dont-get-mad-get-busy/

Feedback

Black and white print tracking dots: document forgery and counterfitting is not limited to cash, nor is the desire to track. – Joe

Round Up:

The post Broadband from Space | TechSNAP 326 first appeared on Jupiter Broadcasting.

Cloudy with a Chance of Leaks | TechSNAP 308

chris — Tue, 28 Feb 2017 21:37:19 +0000

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Announcing the first SHA1 collision

Not just Google on this, they worked with CWI
SHA1 is a Cryptographic hash function
SHA-1 was developed as part of the U.S. Government’s Capstone project. The original specification of the algorithm was published in 1993
two PDFs that have identical SHA-1 hashes but different content
Lifetimes of cryptographic hash functions – by Valerie Aurora
Git fscked by SHA-1 collision? Not so fast, says Linus Torvalds – Attack is hard, discovery is easy, so fix it right
rather than right now
Suggestion: Don’t panic. Things aren’t suddenly going to become vulnerable. Take your time, review your systems looking for SHA-1 usage and evaluate the risk, but best to get it of it all if you have not already.

Three C’s to Tweet By | TechSNAP 304

chris — Wed, 01 Feb 2017 01:23:17 +0000

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Dropbox Kept Files Around For Years Due To ‘Delete’ Bug

Dropbox has fixed a bug that caused old, deleted data to reappear on the site. The bug was reported by multiple support threads in the last three weeks and merged into one issue here. An anonymous Slashdot reader writes
In some of the complaints users reported seeing folders they deleted in 2009 reappear on their devices overnight. After seeing mysterious folders appear in their profile, some users thought they were hacked. Last week, a Dropbox employee provided an explanation to what happened, blaming the issue on an old bug that affected the metadata of soon-to-be-deleted folders. Instead of deleting the files, as users wanted and regardless of metadata issues, Dropbox choose to keep those files around for years, and eventually restored them due to a blunder. In its File retention Policy, Dropbox says it will keep files around a maximum 60 days after users deleted them
If you have sensitive data, do not rely on delete, rely on encryption.
If you have sensitive data, you shouldn’t have it on third-party systems without encryption.
The encryption and decryption should occur on your system, not theirs.
Imagine you deleted those risky files just before an international trip, you get requested to power up your laptop, and bang, there’s those deleted files back….!

Twitter Activist Security – Guidelines for safer resistance

We’ve covered privacy on the Internet before. We’ve stated very clearly that using privacy tools such as Tor is not illegal nor is it suspicious, no more so than someone paying cash at the grocery store.
This guideline is specfically for Twitter, but many of the suggestions can be apply to other social media as well, but I am not sure how well they will travel. Chose carefully
Many people are starting to get politically active in ways they fear might have negative repercussions for their job, career or life. It is important to realise that these fears are real, but that public overt resistance is critical for political legitimacy. This guide hopes to help reduce the personal risks to individuals while empowering their ability to act safely.
I am not an activist, and I almost certainly don’t live in your country. These guidelines are generic with the hope that they will be useful for a larger number of people.
Security Principles To Live By The basic principles of operational security are actually very simple, they’re what we call the three Cs: Cover, Concealment, Compartmentation

Move over skimmers, ‘shimmers’ are the newest tool for stealing credit card info

Consumers and retailers be on guard: there’s a new and more devious way for fraudsters to steal your credit and debit card information.
“Shimmers” are the newest form of credit card skimmers, only smaller, more powerful and practically impossible to detect. And they’re popping up all over the place, says RCMP Cpl. Michael McLaughlin, who sounded the alarm after four shimmers were extracted from checkout card readers at a Coquitlam, B.C., retailer.
“Something this sophisticated, this organized and multi-jurisdictional has all the classic hallmarks of organized crime,” said McLaughlin.
Unlike skimmers, a shimmer — named for its slim profile — fits inside a card reader and can be installed quickly and unobtrusively by a criminal who slides it into the machine while pretending to make a purchase or withdrawal.
Once installed, the microchips on the shimmer record information from chip cards, including the PIN. That information is later extracted when the criminal inserts a special card — also during a purchase or cash withdrawal — which downloads the data. The information is then used to make fake cards.
Shimmers have rendered the bigger and bulkier skimmers virtually obsolete, according to Const. Alex Bojic of the Coquitlam RCMP economic crime unit.
“You can’t see a shimmer from the outside like the old skimmer version,” Bojic said in a statement. “Businesses and consumers should immediately report anything abnormal about the way their card is acting … especially if the card is sticking inside the machine.”
McLaughlin said the Coquitlam retailer detected the shimmers through its newly introduced daily testing of point-of-sales terminals. A test card inserted into the machines kept on getting stuck and the shimmers were found when the terminals were opened.
“We want to get the word out,” said McLaughlin. “Businesses really need to be checking for these kinds of devices and consumers need to be aware of them.”
Bojic said using the tap function of a chip card is one way to avoid being “shimmed.”
“It’s actually very secure. Each tap transfers very limited banking information, which can’t be used to clone your card,” Bojic said.
Krebs wrote about this and has a post which is all about skimmer and shimmer
Not new tech, been around since at least 2015

Feedback:

Round Up:

The post Three C's to Tweet By | TechSNAP 304 first appeared on Jupiter Broadcasting.

Dangerous Dangling Quotes | TechSNAP 278

chris — Thu, 04 Aug 2016 17:47:47 +0000

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

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:

RSS Feeds:

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:

Round Up:

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

Google Gets Pushy | TTT 254

chris — Mon, 01 Aug 2016 16:32:54 +0000

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

A lot is happening in the world of Google this week & some of the new changes are big improvements for it’s users. Plus the new MacBook killer by Xiaomi that might really be killer & Washington State is suing Comcast.

Plus a really neat Kickstarter of the week, local streaming to a Chromecast & more!

Direct Download:

RSS Feeds:

Become a supporter on Patreon

Show Notes:

Kickstarter of the week:

Time Flies: Levitating Nixie Clock by Tony Adams — Kickstarter

The post Google Gets Pushy | TTT 254 first appeared on Jupiter Broadcasting.

Open Server Sadness Layer | TechSNAP 256

chris — Thu, 03 Mar 2016 17:20:45 +0000

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

OpenSSL issues a major security advisory, we break down the important details, then go in depth on the real world impact of these flaws.

Plus some great storage and networking question, a packed round up & much, much more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

OpenSSL issues major security advisory

OpenSSL has released versions 1.0.2g and 1.0.1s to address a number of vulnerabilities:
CVE-2016-0800 (DROWN): HIGH: Cross-protocol attack on TLS using SSLv2
CVE-2016-0703: HIGH: Divide-and-conquer session key recovery in SSLv2
CVE-2016-0702 (CacheBleed): LOW: Side channel attack on modular exponentiation
CVE-2016-0704: MODERATE: Bleichenbacher oracle in SSLv2
CVE-2016-0705: LOW: Double-free in DSA code
CVE-2016-0798: LOW: Memory leak in SRP database lookups
CVE-2016-0797: LOW: BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption
CVE-2016-0799: LOW: Fix memory issues in BIO_*printf functions
As per previous announcements, support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date
Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates.

As many as one third of all HTTPS sites vulnerable to DROWN

“More than 11 million websites and e-mail services protected by the transport layer security protocol are vulnerable to a newly discovered, low-cost attack that decrypts sensitive communications in a matter of hours and in some cases almost immediately”
The researchers have dubbed the latest vulnerability DROWN, short for Decrypting RSA with Obsolete and Weakened eNcryption
DROWN Attack
“The attack works against TLS-protected communications that rely on the RSA cryptosystem when the key is exposed even indirectly through SSLv2, a TLS precursor that was retired almost two decades ago because of crippling weaknesses. The vulnerability allows an attacker to decrypt an intercepted TLS connection by repeatedly using SSLv2 to make connections to a server. In the process, the attacker learns a few bits of information about the encryption key each time. While many security experts believed the removal of SSLv2 support from browser and e-mail clients prevented abuse of the legacy protocol, some misconfigured TLS implementations still tacitly support the legacy protocol when an end-user computer specifically requests its use.”
LibreSSL is not affected by DROWN because support for SSLv2 was removed long ago
“Recent scans of the Internet at large show that more than 5.9 million Web servers, comprising 17 percent of all HTTPS-protected machines, directly support SSLv2. The same scans reveal that at least 936,000 TLS-protected e-mail servers also support the insecure protocol. That’s a troubling finding, given widely repeated advice that SSLv2—short for secure sockets layer version 2—be disabled. More troubling still, even when a server doesn’t allow SSLv2 connections, it may still be susceptible to attack if the underlying RSA key pair is reused on a separate server that does support the old protocol.”
So even a locked down and tightened up server can be compromised, if a less secure server shares the same certificate
I have seen this with my bank, when I changed settings in my browser to be more restrictive on what TLS versions and algorithms were used, a specific subdomain of the bank’s site would no longer load properly
“A website, for instance, that forbids SSLv2 may still be vulnerable if its key is used on an e-mail server that allows SSLv2”
How many people think to adjust the settings on their email server to protect their web server?
TLS security hit a new low last May with the discovery of Logjam, a vulnerability caused by deliberately weakened cryptography that allowed eavesdroppers to read and modify data passing through tens of thousands of Web and e-mail servers
“It’s pretty practical because if you know you want to target certain websites and they’re vulnerable, you can pretty much set up shop and the next thing you know you have all of these secure connections, the passwords, and everything else,” Matt Green, a cryptography expert at Johns Hopkins University who has read the research paper, told Ars. “It’s amazing to me that we keep finding one or two of these [vulnerabilities] per year for protocols that are this old. This shouldn’t keep happening. It kind of makes me feel like we’re not doing our jobs.”
“Tuesday’s OpenSSL updates make it impossible for ordinary end users to enable SSLv2 without declaring explicit intent to do so. The patch also removes support for extremely weak 1990s-era ciphers that are key to making DROWN attacks work. The weak ciphers were added to all SSL and TLS versions prior to 2000 as part of US government’s export regulations”
“Microsoft’s IIS versions 7.0 and on and versions 3.13 and above of the NSS crypto library all have SSLv2 disabled by default. Anyone using older versions of either of these programs should upgrade right away.”
“The most general DROWN attack exploits 1990s-era cryptography that uses extremely weak 40-bit symmetric encryption so software would comply with export restrictions. The attacker captures roughly 1,000 RSA key exchanges made between an end user and a vulnerable TLS server, and the connections can use any version of the SSL or TLS protocols, including the current TLS 1.2. The attacker then uses the intercepted RSA ciphertexts to initiate several thousand SSLv2 connection attempts that include an instruction for the server to use the 40-bit cipher. The attacker then compares the ciphertext to all the 240 possibilities”
“Decrypting the TLS connection requires just 250 computations, a task that in a worst-case scenario Amazon’s EC2 service can perform in eight hours for just $440. The researchers devised an alternate decryption method that uses a cluster of graphics cards and takes 18 hours”
“The researchers also devised a significantly more severe version of DROWN that works against servers running versions of OpenSSL that haven’t been patched since March 2015. It allows attackers to decrypt the “premaster secret” almost instantly. An attacker can use the technique to perform man-in-the-middle attacks that cryptographically impersonate a vulnerable server. Scans performed by the researchers show that a significant percentage of servers vulnerable to DROWN are also susceptible to this more severe version of the exploit. The finding suggests that a surprisingly large number of OpenSSL users have yet to install the March 2015 update, which unknowingly fixed the vulnerabilities that make the more severe attack possible.”
“DROWN is an extension of what cryptographers call the 1998 Bleichenbacher attack, named after Daniel Bleichenbacher, the Swiss cryptographer who discovered the underlying weakness in the PKCS#1 v1 encoding function. While considered a seminal exploit for the mathematical insight it provided, it wasn’t considered especially practical, because it required attackers to make hundreds of thousands or millions of connections to the victim server to compromise a single session key.”
“Ironically, some of the Bleichenbacher countermeasures built into the SSLv2 provided precisely the type of data required to carry out the type of so-called “padding oracle” attack that Bleichenbacher discovered. The Bleichenbacher defenses, it turned out, provided its own oracle that exposed TLS version 1.0 and later exposed it to plaintext recovery attacks. The DROWN research is notable not only because it requires many fewer queries to the server, but also because its cross-protocol nature allows attackers to exploit the SSLv2 weakness to defeat the separate TLS specification. The DROWN findings are also significant because they were the first to identify the ineffectiveness of the Bleichenbacher countermeasures, some two decades after they were added to SSLv2.”
Additional Coverage: CSO Online — Latest attack against TLS shows the pitfalls of intentionally weakening encryption
There is actually a second major exploit that is fixed by this recent OpenSSL update
While this one requires local access to the machine, and is much harder to pull off, the results could be quite disastrous
CacheBleed: A Timing Attack on OpenSSL Constant Time RSA
“CacheBleed is a side-channel attack that exploits information leaks through cache-bank conflicts in Intel processors. By detecting cache-bank conflicts via minute timing variations, we are able to recover information about victim processes running on the same machine. Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys from OpenSSL 1.0.2f running on Intel Sandy Bridge processors after observing only 16,000 secret-key operations (decryption, signatures). This is despite the fact that OpenSSL’s RSA implementation was carefully designed to be constant time in order to protect against cache-based (and other) side-channel attacks.”
“While the possibility of an attack based on cache-bank conflicts has long been speculated, this is the first practical demonstration of such an attack. Intel’s technical documentation describes cache-bank conflicts as early as 2004. However, these were not widely thought to be exploitable, and as a consequence common cryptographic software developers have not implemented countermeasures to this attack.”
“We believe that all Sandy Bridge processors are vulnerable. Earlier microarchitectures, such as Nehalem and Core 2 may be vulnerable as well. Our attack code does not work on Intel Haswell processors, where, apparently, cache-bank conflicts are no longer an issue”
“Cache timing attacks exploit timing differences between accessing cached vs. non-cached data. Since accessing cached data is faster, a program can check if its data is cached by measuring the time it takes to access it.”
“In one form of a cache timing attack, the attacker fills the cache with its own data. When a victim that uses the same cache accesses data, the victim’s data is brought into the cache. Because the cache size is finite, loading the victim’s data into the cache forces some of the attacker’s data out of a cache. The attacker then checks which sections of its data remain in the cache, deducing from this information what parts of the victim’s memory were accessed.”
“To facilitate access to the cache and to allow concurrent access to the L1 cache, cache lines are divided into multiple cache banks. On the processor we tested, there are 16 banks, each four bytes wide. The cache uses bits 2-5 of the address to determine the bank that a memory location uses. In the Sandy Bridge microarchitectures, the cache can handle concurrent accesses to different cache banks, however it cannot handle multiple concurrent accesses to the same cache bank. A cache-bank conflict occurs when multiple requests to access memory in the same bank are issued concurrently. In the case of a conflict, one of the conflicting requests is served immediately, whereas other requests are delayed until the cache bank is available.”
“The main operation OpenSSL performs when decrypting or signing using RSA is modular exponentiation. That is, it calculates cd mod n where d is the private key. To compute a modular exponentiation, OpenSSL repeatedly performs five squaring operations followed by one multiplication. The multiplier in the multiplications is one of 32 possible values. All the numbers involved in these operations are half the size of the key. That is, for a 2048 bit RSA key, the numbers are 1024 bits long.”
“Knowing which multiplier is used in each multiplication reveals the secret exponent and with it the private key. Past cache timing attacks against OpenSSL and GnuPG recover the multipliers by monitoring the cache lines in which the multipliers are stored. To protect against such attacks, OpenSSL stores the data of several multipliers in each cache line, ensuring that all of the cache lines are used in each multiplication. However, the multipliers are not spread evenly across cache banks. Instead, they are divided into 8 bins, each bin spanning two cache banks. More specifically, multipliers 0, 8, 16 and 24 only use bin 0, which spans cache banks 0 and 1. Multipliers 1, 9, 17, and 25 only use bin 1, which spans cache banks 2 and 3, etc. As a result of this memory layout, each multiplication accesses two cache banks slightly more than it accesses the other cache banks. For example, in the case of 4096-bit RSA, the multiplication makes 128 additional accesses to the multiplier’s cache banks.”
“Recovering a 4096 RSA key from 60% of the key material requires around two CPU hours and can be accomplished on a high-end server in less than 3 minutes.”

Feedback:

Round Up:

The post Open Server Sadness Layer | TechSNAP 256 first appeared on Jupiter Broadcasting.

National Security Breaking Agency | TechSNAP 236

chris — Thu, 15 Oct 2015 18:03:54 +0000

To view this video please enable JavaScript, and consider upgrading to a web browser that supports HTML5 video

How the NSA might be breaking Crypto, fresh zero day exploit against Flash with a twist & Keylogging before computers.

Plus a great batch of your questions, a rocking round-up & much more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

— Show Notes: —

How might the NSA be breaking crypto?

“There have been rumors for years that the NSA can decrypt a significant fraction of encrypted Internet traffic. In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a “computing breakthrough” that gave them “the ability to crack current public encryption.” The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand. However, the documents do not explain how these breakthroughs work, and speculation about possible backdoors or broken algorithms has been rampant in the technical community.”
“Yesterday at ACM CCS, one of the leading security research venues, we and twelve coauthors presented a paper that we think solves this technical mystery.”
PDF: Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
“The key is, somewhat ironically, Diffie-Hellman key exchange, an algorithm that we and many others have advocated as a defense against mass surveillance. Diffie-Hellman is a cornerstone of modern cryptography used for VPNs, HTTPS websites, email, and many other protocols. Our paper shows that, through a confluence of number theory and bad implementation choices, many real-world users of Diffie-Hellman are likely vulnerable to state-level attackers.”
“If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime.”
“For the most common strength of Diffie-Hellman (1024 bits), it would cost a few hundred million dollars to build a machine, based on special purpose hardware, that would be able to crack one Diffie-Hellman prime every year.”
“Would this be worth it for an intelligence agency? Since a handful of primes are so widely reused, the payoff, in terms of connections they could decrypt, would be enormous. Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a one-time investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections.”
“Based on the evidence we have, we can’t prove for certain that NSA is doing this. However, our proposed Diffie-Hellman break fits the known technical details about their large-scale decryption capabilities better than any competing explanation. For instance, the Snowden documents show that NSA’s VPN decryption infrastructure involves intercepting encrypted connections and passing certain data to supercomputers, which return the key. The design of the system goes to great lengths to collect particular data that would be necessary for an attack on Diffie-Hellman but not for alternative explanations, like a break in AES or other symmetric crypto. While the documents make it clear that NSA uses other attack techniques, like software and hardware “implants,” to break crypto on specific targets, these don’t explain the ability to passively eavesdrop on VPN traffic at a large scale.”
“8.4% of Alexa Top 1M HTTPS domains allow DHE_EXPORT, of which 92.3% use one of the two most popular primes”
“After a week-long precomputation for each of the two top export-grade primes (see Table 1), we can quickly break any key exchange that uses them. Here we show times for computing 3,500 individual logs; the median is 70 seconds.”
“Our calculations suggest that it is plausibly within NSA’s resources to have performed number field sieve precomputations for at least a small number of 1024-bit Diffie-Hellman groups. This would allow them to break any key exchanges made with those groups in close to real time. If true, this would answer one of the major cryptographic questions raised by the Edward Snowden leaks: How is NSA defeating the encryption for widely used VPN protocols?”
If the NSA has precomputed just one DH 1024 group, they would be able to compromise 37% of the HTTPS traffic to the top 1 million sites using an active downgrade attack. If they have precomputed the ten most popular DH 1024 groups, that number increases to 56%
When applied to VPNs, the single most popular DH 1024 group would comprise 66% of all traffic. For SSH, the number is 25%. For both VPN and SSH, the top 10 does not increase the likelihood of compromise, this suggests that outside of a specific very popular 1024 bit group, most other sites do not reuse the same group as others.
“we performed a scan in which we mimicked the algorithms offered by OpenSSH 6.6.1p1, the latest version of OpenSSH. In this scan, 21.8% of servers preferred the 1024-bit Oakley Group 2, and 37.4% preferred a server-defined group. 10% of the server-defined groups were 1024-bit, but, of those, near all provided Oakley Group 2 rather than a custom group”
Recommendations from the paper:
- Transition to elliptic curves: Transitioning to elliptic curve Diffie-Hellman (ECDH) key exchange with appropriate parameters avoids all known feasible cryptanalytic attacks
- Increase minimum key strengths: Server operators should disable DHE_EXPORT and configure DHE ciphersuites to use primes of 2048 bits or larger.
- Avoid fixed-prime 1024-bit groups: For implementations that must continue to use or support 1024-bit groups for compatibility reasons, generating fresh groups may help mitigate some of the damage caused by NFS-style precomputation for very common fixed groups.
- Don’t deliberately weaken crypto: Our downgrade attack on export-grade 512-bit Diffie-Hellman groups in TLS illustrates the fragility of cryptographic “front doors”. Although the key sizes originally used in DHE_EXPORT were intended to be tractable only to NSA, two decades of algorithmic and computational improvements have significantly lowered the bar to attacks on such key sizes.
“Prior to our work, Internet Explorer, Chrome, Firefox, and Opera all accepted 512-bit primes, whereas Safari allowed groups as small as 16 bits. As a result of our disclosures, Internet Explorer, Firefox, and Chrome are transitioning the minimum size of the DHE groups they accept to 1024 bits, and OpenSSL and Safari are expected to follow suit.”
Additional information from the researchers site WeakDH.org
Sysadmin’s guide to securing your servers

https://www.onlinemeetingnow.com/register/?id=pmsy0fu2ck&inf_contact_key=c3de960e4fc660a9c3744ecc74a608bdde91a80fc9d58288c71bfd6d9c0209ad

Fresh Zero Day exploit against fully patched Adobe Flash

Just last week, we were commenting on how quiet things have been on the Adobe Flash front
Sorry for jinxing it for everyone
This zero day exploit even affects Flash version 19.0.0.207 which was released on Tuesday
Adobe expects to release a patch that fixes the Zero day some time next week
“Attackers are exploiting a previously unknown vulnerability in fully patched versions of Adobe’s Flash Player so they can surreptitiously install malware on end users’ computers”
“So far, the attacks are known to target only government agencies as part of a long-running espionage campaign carried out by a group known as Pawn Storm, researchers from antivirus provider Trend Micro said in a blog post published Tuesday. It’s not unusual for such zero-day exploits to be more widely distributed once the initial element of surprise wanes. The critical security flaw is known to reside in Flash versions 19.0.0.185 and 19.0.0.207 and may also affect earlier versions. At this early stage, no other technical details are available”
“In this most recent campaign of Pawn Storm, several Ministries of Foreign Affairs received spear phishing e-mails. These contain links to sites that supposedly contain information about current events, but in reality, these URLs hosted the exploit”
In this wave of attacks, the emails were about the following topics:
- “Suicide car bomb targets NATO troop convoy Kabul”
“Syrian troops make gains as Putin defends air strikes”
“Israel launches airstrikes on targets in Gaza”
“Russia warns of response to reported US nuke buildup in Turkey, Europe”
“US military reports 75 US-trained rebels return Syria”
The most startling thing here is that you would not expect government employees to get such news via email, so they should know better than to fall for emails with these subjects or follow links with such headlines.
“It’s worth noting that the URLs hosting the new Flash zero-day exploit are similar to the URLs seen in attacks that targeted North Atlantic Treaty Organization (NATO) members and the White House in April this year.”
It will be interesting to see if any of the exploit kits manage to pick up this Zero-day before the patch is released
This attack is currently focused on the government, and the attackers likely want to keep their zero-day to themselves
Once a fix is released, I would expect the regular malware authors to reverse engineer the fix to find the exploit, and see this added to the regular exploit kits
Additional Coverage: Krebs

Keylogging before computers: How Soviets used IBM Selectric keyloggers to spy on US diplomats

“A National Security Agency memo that recently resurfaced a few years after it was first published contains a detailed analysis of what very possibly was the world’s first keylogger—a 1970s bug that Soviet spies implanted in US diplomats’ IBM Selectric typewriters to monitor classified letters and memos.”
“The electromechanical implants were nothing short of an engineering marvel. The highly miniaturized series of circuits were stuffed into a metal bar that ran the length of the typewriter, making them invisible to the naked eye. The implant, which could only be seen using X-ray equipment, recorded the precise location of the little ball Selectric typewriters used to imprint a character on paper. With the exception of spaces, tabs, hyphens, and backspaces, the tiny devices had the ability to record every key press and transmit it back to Soviet spies in real time.”
“The Soviet implants were discovered through the painstaking analysis of more than 10 tons’ worth of equipment seized from US embassies and consulates and shipped back to the US. The implants were ultimately found inside 16 typewriters used from 1976 to 1984 at the US embassy in Moscow and the US consulate in Leningrad. The bugs went undetected for the entire eight-year span and only came to light following a tip from a US ally whose own embassy was the target of a similar eavesdropping operation.”
“”Despite the ambiguities in knowing what characters were typed, the typewriter attack against the US was a lucrative source of information for the Soviets,” an NSA document, which was declassified several years ago, concluded. “It was difficult to quantify the damage to the US from this exploitation because it went on for such a long time.” The NSA document was published here in 2012. Ars is reporting the document because it doesn’t appear to have been widely covered before and generated a lively conversation Monday on the blog of encryption and security expert Bruce Schneier.”
“When the implant was first reported, one bugging expert cited in Discover magazine speculated that it worked by measuring minute differences in the time it took each character to be imprinted. That theory was based on the observation that the time the Selectric ball took to complete a rotation was different for each one. A low-tech listening device planted in the room would then transmit the sounds of a typing Selectric to a Soviet-operated computer that would reconstruct the series of key presses.”
“In fact, the implant was far more advanced and worked by measuring the movements of the “bail,” which was the term analysts gave to the mechanical arms that controlled the pitch and rotation of the ball.”
“In reality, the movement of the bails determined which character had been typed because each character had a unique binary movement corresponding to the bails. The magnetic energy picked up by the sensors in the bar was converted into a digital electrical signal. The signals were compressed into a four-bit frequency select word. The bug was able to store up to eight four-bit characters. When the buffer was full, a transmitter in the bar sent the information out to Soviet sensors.”
“There was some ambiguity in determining which characters had been typed. NSA analysts using the laws of probability were able to figure out how the Soviets probably recovered text. Other factors which made it difficult to recover text included the following: The implant could not detect characters that were typed without the ball moving. If the typist pressed space, tab shift, or backspace, these characters were invisible to the implant. Since the ball did not move or tilt when the typist pressed hyphen because it was located at the ball’s home position, the bug could not read this character either.”
“The implants were also remarkable for the number of upgrades they received. Far from being a static device that was built once and then left to do its job, the bugs were constantly refined.”
“There were five varieties or generations of bugs. Three types of units operated using DC power and contained either eight, nine, or ten batteries. The other two types operated from AC power and had beacons to indicate whether the typewriter was turned on or off. Some of the units also had a modified on and off switch with a transformer, while others had a special coaxial screw with a spring and lug. The modified switch sent power to the implant. Since the battery-powered machines had their own internal source of power, the modified switch was not necessary. The special coaxial screw with a spring and lug connected the implant to the typewriter linkage, and this linkage was used as an antenna to transmit the information as it was being typed. Later battery-powered implants had a test point underneath an end screw. By removing the screw and inserting a probe, an individual could easily read battery voltage to see if the batteries were still active.”
“The devices could be turned off to avoid detection when the Soviets knew inspection teams were in close proximity. Newer devices operated by the US may have had the ability to detect the implants, but even then an element of luck would have been required, since the infected typewriter would have to be turned on, the bug would have to be turned on, and the analyzer would have to be tuned to the right frequency. To lower this risk, Soviet spies deliberately designed the devices to use the same frequency band as local television stations.”
I thought this was an interesting example of how espionage works and how hard it can be to detect

Feedback:

2gbps with direct connections?
- ifconfig lagg0 create
- ifconfig lagg0 laggproto roundrobin laggport igb0 laggport igb1
- ifconfig lagg0 192.168.101.1/24
VLAN Basics
PHP-FPM Tweaking
Remote PC power on
- APC AP7900 is $600+, but can be cheap on ebay

Round Up:

The post National Security Breaking Agency | TechSNAP 236 first appeared on Jupiter Broadcasting.