Security – FU-BAR

2018-11-05

Obfuscated encryption fails again… No Shit, Sherlock!

This is obfuscation, rather than encryption, for all purposes.

Major hardware vendors are involved, and «the issue is worse on Windows». No surprises, then… Glad I don’t use that poor excuse for an operating system… 🙂

It seems a few popular devices with hardware controlled self encryption aren’t really doing it good by having master passwords (truly a #WTF) and faulty standards implementations.

«SSDs from Micron (Crucial) and Samsung are affected. These are SSDs that support hardware-level encryption via a local built-in chip, separate from the main CPU. Some of these devices have a factory-set master password that bypasses the user-set password, while other SSDs store the encryption key on the hard drive, from where it can be retrieved. The issue is worse on Windows, where BitLocker defers software-level encryption to hardware encryption-capable SSDs, meaning user data is vulnerable to attacks without the user’s knowledge»

There’s a paper with all the gory details for the hard core guys and a report on ZDNet for the rest.

2018-02-092018-02-10

Using Let’s Encrypt with getssl and minimal root usage #letsencrypt

is an amazing initiative to have X.509 certificates for your website, or even your email servers, but most instructions just tell you to run (some more some less) complicated programs as root in order to run the periodic certificate renewal workflows, and that is sub-optimal as it substantially increases the number of attack vectors your already exposed system is susceptible to.

This article is just a way to enjoy the benefits of Let’s Encrypt while minimizing the need for root privileges in your system,and thus keeping it reasonably secure, and this example is doing it with getssl (don’t be scared it hasn’t changed much for some time, they’re working on the new APIv2 support).

It’s taking in account a typical CentOS/Red Hat 7 server, your mileage might vary with other systems but it should mostly be the same.

You can start setting up your environment by adding a non privileged user, let’s say… acme… who will run the renewal workflow:

# useradd acme

Then you can proceed to installing getssl and setting up directories for your files:

# curl https://raw.githubusercontent.com/srvrco/getssl/master/getssl > /usr/local/bin/getssl
# chmod 0755 /usr/local/bin/getssl
# mkdir -p /etc/letsencrypt/acme/ssl.{crt,key,pem}
# chown -R acme:acme /etc/letsencrypt/acme
# chmod -R 0755 /etc/letsencrypt
# chmod 0750 /etc/letsencrypt/acme/ssl.{key,pem}
# mkdir -p /var/www/html/letsencrypt/.well-known/acme-challenge
# chown letsencrypt:letsencrypt /var/www/html/letsencrypt/.well-known/acme-challenge
# echo 'letsencrypt yourhostname=NOPASSWD: /usr/bin/systemctl restart httpd' >> /etc/sudoers.d/letsencrypt

That last line adding a sudo rule is part of the magic and the single root command that is executed. You can also make it restart Postfix, Dovecot, or any other service you use a certificate and that needs restarting in order to take the new certificate.

In order to let you read it all from this article, I’ll borrow the example’s from getssl’s github page and then add in my own suggestions.

Now you want to prepare the environment (as the user acme) for your domain:

getssl -c yourdomain.com

This will create a ~/.getssl/yourdomain.com directory, the main files you want are called getssl.cfg, there’s a global file on ~/.getssl/getssl.cfg and then more specific files per domain, ~/.getssl/yourdomain.com/getssl.cfg

In the main file, ~/.getssl/getssl.cfg, you’ll need to set up the values accordingly to your needs (I won’t dive into how to get an account), but for this setup you’ll want to change the following:

RELOAD_CMD="/usr/bin/sudo systemctl restart httpd"
ACL=('/var/www/html/letsencrypt/.well-known/acme-challenge')
CA_CERT_LOCATION="/etc/letsencrypt/acme/ssl.crt/lets-encrypt-x3-cross-signed.pem
RENEW_ALLOW="30"

And that RELOAD_CMD right there is part of the magic…

Now edit ~/.getssl/yourdomain.com/getssl.cfg and change the following:

DOMAIN_CERT_LOCATION="/etc/letsencrypt/acme/ssl.crt/yourdomain.com.crt"
DOMAIN_KEY_LOCATION="/etc/letsencrypt/acme/ssl.key/yourdomain.com.key"

Now all you need is to set up a cron job:

45 6 * * * /home/letsencrypt/getssl -u -a -q

And finally you configure Apache httpd to use the files paths for the CERTificate and its KEY:

(...)
SSLCertificateFile /etc/letsencrypt/acme/ssl.crt/blog.1407.org.crt
SSLCertificateKeyFile /etc/letsencrypt/acme/ssl.key/blog.1407.org.key
SSLCertificateChainFile /etc/letsencrypt/acme/ssl.crt/lets-encrypt-x3-cross-signed.pem
Alias /.well-known/acme-challenge /var/www/html/letsencrypt/.well-known/acme-challenge
(...)

And you’re done: the cron job will run every day, and when you reach the 30 days to renew threshold your certificate will be renewed with minimal root usage.

2014-04-122014-04-16

Musings on #Heartbleed

Several thoughts have been on my mind about #heartbleed. You may have heard similar thoughts about it, but I’d like to add my own.

Ah… nothing like checking the news in the morning, feels like… ah… a bug in OpenSSL, let’s check it out… OMFG… By 10:00 I was already applying patches to vulnerable (and exposed) servers all around, processes be damned!

Is Free Software security tarnished?

Absolutely not!

Let me start by the first thing you should take in mind: you’re better off than with proprietary software and this bug proves it, few could have said as well as Sam Tuke of FSF Europe did, there are also a few words from Simon Phipps and Eric Raymond.

In a gist, there are several instances of just as serious bugs, and many much more serious, on proprietary software. Even in the field of network security. And those are just the tip of the iceberg, those that were guessed and not found.

This bug had patches available within few hours of being published available to those affected.

Several documented flaw finding studies have been made, guess who turned out better in every single one of them in average? Yes, Free Software. Proprietary software has constantly been found to have, in average, more bugs, more security bugs, more delayed patch releases, etc..

Update (2014/04/13): Also, an even such as this one prompted an independent audit review from the OpenBSD people, here’s another bug in OpenSSL that has been fixed there, proving once again how Free Software works to make software more secure:

you can do independent and public audit reviews
you can push fixes for what you found publicly on the Internet
anyone can take advantage of those changes thus maximizing the effect

Now imagine such a bug happened in Microsoft’s crypto…

you can’t do independent audit reviews
you can’t push fixes for what you found publicly on the Internet
nobody but Microsoft can make a fixes Microsoft crypto library

Replace Microsoft by whomever you prefer above, they’re just an easy target. 😉

Exposure

Here’s the most detailed timeline of public information on the bug that I found.

Yes, the code was there for about two years, but the exposure was not that big. It was big, about a fifth of the “secure” web. Unfortunately, lots of very popular websites were exposed, so the general recommendation is: don’t assume they’re safe, change your passwords everywhere.

Why wasn’t it bigger? Because not everyone runs the latest releases, lots of GNU/Linux distributions have more conservative approaches to running recent software. Take in point Red Hat Enterprise Linux and it’s derivate distributions.

Only since the 6.5 release, released in late November last year, did updated Red Hat (and derivatives) installations become exposed. CentOS followed a about a couple of weeks later.

Ironically, this bug affected the most efficient system administrators who had kept their systems updated 🙂

But many run their services in, for instance, Red Hat Enterprise Linux 5 (and derivatives) which is completely unaffected by this bug. Same for other software.

Even those who run the major 6.5 release could be totally unaffected, if they used NSS instead of OpenSSL with Apache, for instance.

In short: it was big, but not catastrophically big.

Also affects proprietary software!

What? How could this be? Isn’t OpenSSL Free Software? Well, yes, yes it is, but it is licensed in such a way that permits proprietary derivative versions.

They should be safer, right? Hi Cisco and Juniper… I’m sure there are others. I wonder if they’ll be at least honest enough with us… I urge people to check their ultra-expensive and highly proprietary Web Application Firewalls, Load Balancers, Proxies… etc…

All your keys are belong to US!

9 out of 10 SSL certificates are under indirect control of the US Government. Think Patriot, NDAA, National Security Letters, Secret Courts with Secret Interpretations, people and companies coerced under threat of being formally accused of treason if they don’t cooperate or if they talk about it.

Even if #heartbleed can really lead vulnerable software to leak the private keys, you should renew your certificates under a non-american CA.

Really, don’t make it easy for them, they don’t deserve that, your customers don’t deserve that, your friends and family don’t deserve that.

Change management be damned!

If you ever have an axe to grind about ISO 20000, ITIL or similar brain dead efficiency killers, specially when implemented by complete and utter idiots, now you can have some revenge.

It is a bug of such seriousness that I recommend to screw the change management processes. Update now if you are affected or change your career because you either are managed by complete and utter idiots or you don’t take it seriously enough.

Places that have enough good sense will allow you to run the Emergency Change process by your ECAB after the fact for such serious situations.

Take advantage of that, this is such a case.

Conspiracy theories

Unlike some suggested, it appears to be an honest mistake that neither the developer nor his reviewers did spot, and they felt quite embarrassed:

The author of the bug, Robin Seggelmann,^[78] stated that he “missed validating a variable containing a length” and denied any intention to submit a flawed implementation.^[79]

Theo de Raadt, OpenBSD’s founder, said «OpenSSL is not developed by a responsible team», but I doubt they’ll bother implementing a new SSL library. ~~I wonder what they’ll do though…~~ but are ~~likely~~ making an independent review.

Prophecy come true!

Poul Henning-Kamp’s hilarious ending keynote of FOSDEM 2014 pretending to be an NSA agent speaking of Operation Orchestra, calling it a crown jewel:

Crown jewel: OpenSSL

Go-to library for crypto services

API is a nightmare

Documentation is deficient and misleading

Defaults are deceptive

We need to ask him where he has found spice… he certainly seemed like he had blue eyes and #Heartbleed was truly a Crow Jewel for…

…The NSA

No such agency had such a duty to find a serious bug like this one and responsibly proceed to get it fixed ASAP as it was affecting its nation like the National Security Agency had.

There are innuendos that the NSA knew about heartbleed for a long time. They certainly have the expertise and the budget to have found it, but they did deny any knowledge or exploit for years, in fact that they didn’t know about it before April.

Of course, no one can trust the NSA anymore because they have been proven invested into breaking security for everyone, so they could be lying in order to cover their asses after such a monumental fail in protecting their own country’s security.

Or they could have just been doing it for less than two years, like one year and 364 days, not yet years (plural), right?

One never can tell, and that’s symptomatic of a very botched organization.

Is Microsoft involved?

I don’t know. It’s certainly fishy that:

The publication date coincides with the death of Windows XP. It could be called a distraction manouver, so that people get scared of moving away from Windows XP into a GNU/Linux… it certainly has been effective at crying wolf in big media outlets
Codenomicon is run by a Microsoftie, well, ex Chief Security Officer of Microsoft, but those kinds of people tend to leave the companies with strong lobbying and partnership relations in their next ventures with the big mothership
It is documented that Microsoft has been a faithful collaborator of the NSA for many years, even to the point of maybe having a dedicated backdoor

Maybe it’s just coincidence. Maybe…

OpenSSL is grossly unappreciated

They few OpenSSL developers are highly dedicated people that don’t exactly live well off of it. In fact, the importance of OpenSSL is disproportionately unappreciated, specially in a financially rewarding form.

Fortunately, the devlopers do it more out of other rewarding factors, like responsibility and pride.

Conclusions

It’s one of the most serious security bugs in the history of the Internet
Use any of the available mitigations if you’re affected (upgrade, recompile disabling the feature, downgrade, change software)
More people (specially corporate companies making money with OpenSSL) should donate mone to the OpenSSL Software Foundation
I don’t remember writing such a long post, it’s probably very flawed, I accept patches, comment below 😉

2014-01-12

Free Software and Security under the #NSA

Anyone claiming Free Software “does not magically make things more secure – never has, never will” without explaining how you’re so much better off at securing yourself is using truths to lie to you.

Here’s an example:

Explicit truth: it doesn’t “magically make things more secure”
Hidden truth: it technically and scientifically does by exposure to peer review and the scientific method, the end results have definitely been proved more secure in average than the proprietary “alternatives”
Hidden lie: “never has, never will” It’s just piggy backing on the explicit truth in order to hide (using a true statement) that in average it does and that you’re better off.

So, if someone is lying to you so straight faced, how can you trust that person when he’s been claiming badBIOS is a myth?

The fact is it is possible, it’s installed code running on chips and it can be updated. Didn’t he himself just say that all software has security bugs when he told that being Free Software doesn’t “magically make things more secure“?

So why couldn’t these computers be compromised in such ways? In fact the NSA backdoor catalogue explicitly details BIOS level security compromises and implants! Go read this list, specially the BIOS level attacks then think for yourself upon badBIOS rather than trust people who tell you “no, that’s not it” or “just conspiracy theories”.

Those people are lying to you and they have hired a lot of security people under their wing, so of course they’d use these hired high tech spooks in order to try to discredit you…

So go watch Jacob Applebaum’s talk at 30C3, To protect and infect, part 2, rather than believing someone calling him a conspiracy theorist.

He’s publishing these findings at a respectable newspaper (Der Spiegel), the other guy is just name calling.

Which one deserves more credit? You decide.

Me, I’ll be trusting Free Software security, if anything, these NSA scandals have proven my reason, and sure they could try to insert backdoors in Free Software, but tell me, how easily can you put a backdoor where anyone can see?

Not. Easily. Not at all.

What about when most people are blinded except from the builders?

Riiight…

Here’s an example, from Jacob’s talk: Jake tells about those little USB dongles that randomly move your mouse in order to prevent the screensaver from launching… you know what Systemd now does when it finds one? Automatically locks the screen. What do Windows or MacOS do?

Riiight… you guessed it, move the mouse and prevent the screensaver from launching.

I’ll be using Free Software and so should you, but you’re your own boss.

You can choose a greater likelihood of being infected.

2013-11-01

Airgap-Jumping Malware May Use Ultrasonic Networking To Communicate

Hugh Pickens DOT Com writes “Dan Goodwin writes at Ars Technica about a rootkit that seems straight out of a science-fiction thriller. According to security consultant Dragos Ruiu one day his MacBook Air, on which he had just installed a fresh copy of OS X, spontaneously updated the firmware that helps it boot. Stranger still, when Ruiu then tried to boot the machine off a CD ROM, it refused and he also found that the machine could delete data and undo configuration changes with no prompting. Next a computer running the Open BSD operating system also began to modify its settings and delete its data without explanation or prompting and further investigation showed that multiple variants of Windows and Linux were also affected. But the story gets stranger still. Ruiu began observing encrypted data packets being sent to and from an infected laptop that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer. The packets were transmitted even when the laptop had its Wi-Fi and Bluetooth cards removed. Ruiu also disconnected the machine’s power cord so it ran only on battery to rule out the possibility it was receiving signals over the electrical connection. Even then, forensic tools showed the packets continued to flow over the airgapped machine. Then, when Ruiu removed internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped. With the speakers and mic intact, Ruiu said, the isolated computer seemed to be using the high-frequency connection to maintain the integrity of the badBIOS infection as he worked to dismantle software components the malware relied on. It’s too early to say with confidence that what Ruiu has been observing is a USB-transmitted rootkit that can burrow into a computer’s lowest levels and use it as a jumping off point to infect a variety of operating systems with malware that can’t be detected. It’s even harder to know for sure that infected systems are using high-frequency sounds to communicate with isolated machines. But after almost two weeks of online discussion, no one has been able to rule out these troubling scenarios, either. ‘It looks like the state of the art in intrusion stuff is a lot more advanced than we assumed it was,’ says Ruiu. ‘The take-away from this is a lot of our forensic procedures are weak when faced with challenges like this. A lot of companies have to take a lot more care when they use forensic data if they’re faced with sophisticated attackers.'”

Airgap-Jumping Malware May Use Ultrasonic Networking To Communicate

4 (out of 5) ssh security tips

There are some security tips for your sshd_config at http://www.debian-tutorials.com/5-steps-to-secure-your-ssh-server however the third one, Change the SSH Port on the server, is a lot of hot air.

“By changing the default port you will make SSH server more secure. By changing the default port you will reduce the amount of brute force attacks.”

Only the second phrase of this statement is truthful, but still, not by a wide margin…

Security by obscurity never works, it’s better to follow the other 4 advices and use fail2ban or something similar.

2008-08-242010-12-12

O ataque à Red Hat/Fedora em Links

Os sistemas deixam de estar disponíveis. Um posterior (alguns consideram tardio) aviso na Fedora Announce denúncia um problema de segurança com pacotes «as a precaution, we recommend you not download or update any additional packages on your Fedora systems»
Enquanto a investigação prossegue à porta fechada, possivelmente por motivos legais, os sistemas vão lentamente voltando a funcionar
Finalmente (8 dias depois do anúncio oficial) revelam o que aconteceu: alguém conseguiu penetrar no sistema de compilação automática de software.
Conseguiram submeter pacotes de OpenSSH assinados com a chave da Red Hat, mas em princípio não chegaram a ser distribuídos. Publicaram novos pacotes de OpenSSH e um script para verificar se por azar algum um cliente de Red Hat Enterprise Linux chegou a descarregar esses pacotes.

É mau? Sim, é mau. Mas o pior que aconteceu foi um beliscão na imagem da Red Hat. Já passo.

Sem dúvida seguir-se-ão as piadas do costume na Internet (Debian passou por isso recentemente, embora no seu caso tivesse sido bem mais grave), até que a moda canse ou seja substituída por outro evento.

Felizmente foi detectado atempadamente e, mais importante ainda, não conseguiram acesso às chaves da Red Hat. Estão preservadas num HSM (High Security Module), apenas conseguiram submeter pacotes corrompidos para o sistema de assinatura automática.

Move along…