It actually looks like the company was OK with it. The disclosure timeline shows they were responsive and addressed the problem quickly when they were made aware of its existence.
That is correct. The reporter requested public disclosure after the report was closed. The bug automatically gets disclosed publicly 30 days after the report is closed, unless the team requests more time by re-opening the bug. You can read more about the disclosure philosophy here: https://hackerone.com/guidelines
Another interesting feature might be notifying the engineering team that a following list of bugs will be automatically disclosed in x days and give them a chance to review them with a fresh pair of eyes.
In the post he also describes that he now uses a new process which involves a computer that has never been connected to the internet and its sole purpose is encrypting and decrypting files. Why not use it to encrypt and decrypt emails as well? That'd also potentially involve generating a new key pair.
> 3) Assume that while your computer can be compromised, it would take work and risk on the part of the NSA – so it probably isn't. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it's pretty good.
I assume it's a well thought through and properly risk-assesed security/convenience tradeoff. Handling encrypted files is much less frequent than handling encrypted email - and putting an airgap between the internet and your email is likely to cause more grief than the security improvement it creates.
I've got the seeds of an idea which has been kicking round my head for a few weeks now - a rasbperrypi (or similar) with GPG installed on it, which is connected to my main computer as a usb device (possibly impersonating a usb keyboard). The 'pi could be sent encrypted data over the usb/serial connection, and send back the plaintext. The 'pi would have no network connection – reducing the attack surface for someone trying to extract my private key remotely to some exploit that'd work over a tightly constrained serial connection. Sort of like a RSA SecureID on steroids - here's a device with a "cryptographically secure secret", but instead of just displaying TOTP tokens, you can feed it encrypted data and have it send back cleartext (optionally with a keypad and PIN/passcode required, but it's not "secure" against physical access, so I'm probably not going to try and implement that...).
That definitely fits with the 'hacker ethos' and all, but why not just use a smartcard with a Class III reader (i.e. dedicated pinpad and display on the reader itself).
Support is already integrated with GnuPG, they are specifically designed to prevent key material leaking, and they have some other nice properties (like self-destruction after three incorrect admin PIN attempts).
Mostly because I've got a pair of RspberryPis – and I'm doing this mostly out of curiosity and learning (and a little bit of "sticking it to 'the man'"…).
If you have to store encrypted credit card data, that's the recommended way of keeping it safe. Your Pi is analogous to hardware encryption devices that have been available for some time.
With linux, is there any way to compromise the USB stick used for the air gap? AFAIK the Stuxnet virus was originally spread via USB stick, however I reckon that it involved Windows machines that are known to execute files on USB sticks.
If you aren't 100% sure of the providence of your usb stick, you can't really rely on it for _anything_ – have you seen Travis Goodspeed's "Writing a Thumbdrive from Scratch" presentation?
Indeed! An intelligent "USB Device" is what was used to originally jailbreak the PS3. [0] A USB device (commonly using an AVR USB microcontroller) sends differing USB descriptors at different times - a sort of double-fetch vulnerability. The exploit leads to complete hypervisor access. Do NOT trust your USB device!
I think some basic opsec is in order here. The airgapped computer should format every thumb drive plugged into it, or even better, should ignore any USB device that is not the specific thumb drive you are using. All of this could be configured without terribly much pain (which is not to say it is trivial) in GNU/Linux. Not perfect, of course, but would stop quite a few attacks and reduce the chance of carelessness screwing up security.
Years ago, a classmate of mine built a rig out of a receipt printer and one of those old handheld scanners to provide an "air gap", though it never really worked (sort of an art project at the time). Might be time to revive the idea...
How about 2 serial ports, connecting only TxD, RxD and GND? 3-wire RS-232 basically has no attack surface, there's no protocol to speak of. [edit: shabble already suggested this]
Something very similar to this has been used in the military to "bridge" network barriers at differing security levels. The US Navy uses "SDR" (Secure Data Replication) to transfer content under control.
You could get all stuxnet and exploit the various applications (such as the components that inspect zipped content), but the transport itself is a simple file copy over a bitstream. You could do the same thing with kermit and uuencode a bit more easily.
I'm just speculating here... but I think it could be done PC-to-PC up to 100mbit. IIRC, there's a "link" signal that normally exists -- you'll have to configure both cards to ignore the link signal. (Which, I suppose, would mean that this wouldn't work going to a switch or hub with factory-default firmware.)
Half-duplex, 100mbit, ignore link. I suppose it can be done?....
Yep, if you're blocking remote hosts to authenticate on 3306 (or any other port you're running mysqld on) you're safe. The attacking host can't authenticate itself, so it's unable to exploit this bug.
