Unix Security Trifecta | TechSNAP 292

chris

6 years ago

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Unix Trifecta — Patch Your Shit

This week saw the trifecta, critical vulnerabilities in 3 of the most important and widely used server applications
CVE-2016-8610 – OpenSSL: A remote attacker who can initiate handshakes with an OpenSSL based server can cause the server to consume a lot of computation power with very little bandwidth usage, and may be able to use this technique in a leveraged Denial of Service attack.
The flaw is in the way OpenSSL handles “SSL Alerts”. The SSL alert protocol is a way to communicate problems within a SSL/TLS session. Due to improper handling of alert packets, OpenSSL would consume an excessive amount of CPU time processing undefined alert messages.
- CVE-2016-8864 – Bind: A remote attacker who could cause a server to make a query deliberately chosen to trigger the failed assertions could cause named(8) to stop, resulting in a Denial of Service condition to its clients.
- A defect in BIND’s handling of responses containing a DNAME answer could cause a resolver to exit after encountering an assertion failure in db.c or resolver.c.
- CVE-2016-8858 – OpenSSH: A remote attacker may be able to cause a SSH server to allocate an excessive amount of memory. Note that the default MaxStartups setting on FreeBSD will limit the effectiveness of this attack.
During the SSH handshake procedure, the client and server exchanges the supported encryption, MAC and compression algorithms along with other information to negotiate algorithms for initial key exchange, with a message named SSH_MSG_KEXINIT.
When processing the SSH_MSG_KEXINIT message, the server could allocate up to a few hundreds of megabytes of memory per each connection, before any authentication take place.
Patches for most OSes should be out by now, make sure you install them.

LessPass, an open source, storage-less password manager? Or is it…

“Managing your Internet passwords is not easy. You probably use a password manager to help you. The system is simple, the tool generates random passwords whenever you need them and save them into a file protected with a strong password. This system is very robust, you only need to remember one password to rule them all! Now you have a unique password for each site on the Internet.”
But, there are some shortcomings to that type of password manager
How do I synchronize this file on all my devices?
How do I access a password on my parents’ computer without installing my password manager?
How do I access a password on my phone, without any installed app?
To solve this, LessPass does it differently
“The system uses a pure function, i.e. a function that given the same parameters will always give the same result. In our case, given a login, a master password, a site and options it will returns a unique password”
“No need to save your passwords in an encrypted file. You just need to access the tool to recalculate a password from information that you know (mostly the login)”
There are some issues though.
- Some sites have different password complexity requirements, such as banks that limit the length of your password, or require a PIN that is all digits
- Some sites obviously do not hash passwords correctly, and do not allow some characters
- What if you want to, or need to, change your password?
LessPass has a solution for all of these, where you specify “password profile”, to remember the different complexity settings to generate the valid password
To manage to change the password, there is also a counter, that starts at 1, and you increment to get a different password.
Of course now, you have to remember: your login, your master password, the password complexity profile for each site, and how many times you have changed your password on that site
So, they have a “connected” version, that remembers each site, your login, the password profile, and your password change counter.
There are obviously some privacy concerns, and security concerns here.
How do you restrict access in the connected version, with a username and password? Is that password the same or different from your master password. Is your profile data encrypted per user?
Of course, being an open source project, there is the option to self-host, which eliminates a number of those concerns
“You can host your own LessPass database if you do not want to use the official one. The requirement for self-hosting is to have docker and docker-compose installed on your machine.”
The fact that the installation instructions are curl | bash (written the other way around, so that when you stick sudo in front of it it works), does raise some other concerns
This leaves a few problems:
- You can never change your master password, as it will effectively change all of your passwords
- It is still technically possible for someone to brute force your master password. Each attempt will require them to do the full PBKDF2 run, but 8192 rounds will take only a small fraction of a second, and it can be parallelized quite well. If someone does compromise your master password (via brute force, or with a keylogger, or whatever), they have access to all of your passwords, but worse, they even have access to your ‘new’ passwords, if you change your password, it just changes the ‘count’ parameter, so I could generate your next 10 gmail passwords and keep them for later.
- The key-derivation seems weak, 8192 rounds of PBKDF2 is likely not enough. LastPass uses 100,000 rounds for its server-side key-derivation. FreeBSD’s GELI disk encryption uses a number of rounds that will take approximately 2 seconds, which on modern machines is over 1 million rounds. The issue is that changing this number in the future will change all of your passwords. At a minimum, it should be part of the password profile, so you can select a different value for each site, so you can change the default for new sites in the future, and increase the strength of the password for one site by changing the password.
- LessPass cannot deal with SSO (Single Sign On). There are a number of sites for which I have the same password, because they all authenticate against the same LDAP database (or ActiveDirectory). LessPass ONLY allows you to use its derived passwords, which might not always work.
There are definitely some interesting aspects to LessPass, especially being able to self host, but, I don’t think I’ll be switching to it.

A very valuable vulnerability

It all started with a facebook post by Colin Percival: “I think I just accidentally exploited a “receive arbitrarily large amounts of money” security vulnerability. Oops.”
Colin Percival is a security and cryptography expert, and a former FreeBSD Security Officer
Colin’s day job is running Tarsnap – backups for the truly paranoid.
To accept payments for his business, he uses Stripe – a credit card processing service, which also allows him to accept bitcoins
“While I very firmly wear a white hat, it is useful to be able to consider things from the perspective of the bad guys, in order to assess the likelihood of a vulnerability being exploited and its potential impact. For the subset of bad guys who exploit security vulnerabilities for profit — as opposed to selling them to spy agencies, for example — I imagine that there are some criteria which would tend to make a vulnerability more valuable:”
- the vulnerability can be exploited remotely, over the internet;
the attack cannot be blocked by firewalls;
- the attack can be carried out without any account credentials on the system being attacked;
- the attack yields money (as opposed to say, credit card details which need to be separately monetized);
- once successfully exploited, there is no way for a victim to reverse or mitigate the damage; and
- the attack can be performed without writing a single line of code.
“Much to my surprise, a few weeks ago I stumbled across a vulnerability satisfying every one of these criteria.”
“The vulnerability — which has since been fixed, or else I would not be writing about it publicly — was in Stripe’s bitcoin payment functionality. Some background for readers not familiar with this: Stripe provides payment processing services, originally for credit cards but now also supporting ACH, Apple Pay, Alipay, and Bitcoin, and was designed to be the payment platform which developers would want to use; in very much the way that Amazon fixed the computing infrastructure problem with S3 and EC2 by presenting storage and compute functionality via simple APIs, Stripe fixed the “getting money from customers online” problem. I use Stripe at my startup, Tarsnap, and was in fact the first user of Stripe’s support for Bitcoin payments: Tarsnap has an unusually geeky and privacy-conscious user base, so this functionality was quite popular among Tarsnap users.”
“Despite being eager to accept Bitcoin payments, I don’t want to actually handle bitcoins; Tarsnap’s services are priced in US dollars, and that’s what I ultimately want to receive. Stripe abstracts this away for me: I tell Stripe that I want $X, and it tells me how many bitcoins my customer should send and to what address; when the bitcoin turns up, I get the US dollars I asked for. Naturally, since the exchange rate between dollars and bitcoins fluctuates, Stripe can’t guarantee the exchange rate forever; instead, they guarantee the rate for 10 minutes (presumably they figured out that the exchange rate volatility is low enough that they won’t lose much money over the course of 10 minutes). If the “bitcoin receiver” isn’t filled within 10 minutes, incoming coins are converted at the current exchange rate.”
“For a variety of reasons, it is sometimes necessary to refund bitcoin transactions: For example, a customer cancelling their order; accidentally sending in the wrong number of bitcoins; or even sending in the correct number of bitcoins, but not within the requisite time window, resulting in their value being lower than necessary. Consequently, Stripe allows for bitcoin transactions to be refunded — with the caveat that, for obvious reasons, Stripe refunds the same value of bitcoins, not the same number of bitcoins. (This is analogous to currency exchange issues with credit cards — if you use a Canadian dollar credit card to buy something in US dollars and then get a refund later, the equal USD amount will typically not translate to an equal number of CAD refunded to your credit card.)”
The vulnerability lay in the exchange rate handling. As I mentioned above, Stripe guarantees an exchange rate for 10 minutes; if the requisite number of bitcoins arrive within that window, the exchange rate is locked in. So far so good; but what Stripe did not intend was that the exchange rate was locked in permanently — and applied to any future bitcoins sent to the same address. This made a very simple attack possible:
- Pay for something using bitcoin.
- Wait until the price of bitcoin drops.
- Send more bitcoins to the address used for the initial payment.
- Ask for a refund of the excess bitcoin.
“Because the exchange rate used in step 3 was the one fixed at step 1, this allowed for bitcoins to be multiplied by the difference in exchange rates; if step 1 took place on July 2nd and steps 3/4 on August 2nd, for example, an arbitrary number of bitcoins could be increased by 30% in a matter of minutes. Moreover, the attacker does not need an account with Stripe; they merely need to find a merchant which uses Stripe for bitcoin payments and is willing to click “refund payment” (or even better, is set up to automatically refund bitcoin overpayments).”
“Needless to say, I reported this to Stripe immediately. Fortunately, their website includes a GPG key and advertises a vulnerability disclosure reward (aka. bug bounty) program; these are two things I recommend that every company does, because they advertise that you take security seriously and help to ensure that when people stumble across vulnerabilities they’ll let you know. (As it happens, I had Stripe security’s public GPG key already and like them enough that I would have taken the time to report this even without a bounty; but it’s important to maximize the odds of receiving vulnerability reports.) Since it was late on a Friday afternoon and I was concerned about how easily this could be exploited, I also hopped onto Stripe’s IRC channel to ask one of the Stripe employees there to relay a message to their security team: “Check your email before you go home!””
“Stripe’s handling of this issue was exemplary. They responded promptly to confirm that they had received my report and reproduced the issue locally; and a few days later followed up to let me know that they had tracked down the code responsible for this misbehaviour and that it had been fixed. They also awarded me a bug bounty — one significantly in excess of the $500 they advertise, too.”
“As I remarked six years ago, Isaac Asimov’s remark that in science “Eureka!” is less exciting than “That’s funny…” applies equally to security vulnerabilities. I didn’t notice this issue because I was looking for ways to exploit bitcoin exchange rates; I noticed it because a Tarsnap customer accidentally sent bitcoins to an old address and the number of coins he got back when I clicked “refund” was significantly less than what he had sent in. (Stripe has corrected this “anti-exploitation” of the vulnerability.) It’s important to keep your eyes open; and it’s important to encourage your customers to keep their eyes open, which is the largest advantage of bug bounty programs — and why Tarsnap’s bug bounty program offers rewards for all bugs, not just those which turn out to be vulnerabilities.”
“And if you have code which handles fluctuating exchange rates… now might be a good time to double-check that you’re always using the right exchange rates.”
A very interesting attack, that was only found because someone accidentally did the wrong thing

Feedback:

ipV6 vs Mirai
Freenas replication
Freenas 10 question
Backup & LUKS
Chromecast across subnets
A user wrote in about the mention of BCP38 the other week, and asked what other best practises there are: here is a list

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

Unix Trifecta — Patch Your Shit

LessPass, an open source, storage-less password manager? Or is it…

A very valuable vulnerability

Feedback:

Round Up: