Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday August 27 2016, @06:07PM   Printer-friendly
from the don't-go-through,-go-around dept.

Earlier this summer, the team at Inversoft published a comprehensive and sophisticated guide to user data security. The guide spans from hardening servers from provisioning, up through the IP and SSH layers, and all the way to application-level techniques for password hashing, SQL injection protection, and intrusion detection. As proof that they stood behind their advice, the Inversoft team provisioned a pair of Linode hosts, a web server and database server, and gave them the hardening treatment. Inversoft offered up a fully-loaded MacBook to anyone who could break in, taunting all comers by naming the hardened web server hackthis.inversoft.com.

Game on.

Needless to say, they found a way in.

[...] After discovering an unpatched, unfirewalled Elasticsearch instance using nmap, we gained shell access on a utility server used for various functions at Inversoft. On there, we found API keys for Linode left behind by a human operator. Those keys allowed us to detach disks from running servers and attach them to servers we controlled, stealing sensitive user data (all to win a prize).


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by frojack on Saturday August 27 2016, @06:22PM

    by frojack (1554) on Saturday August 27 2016, @06:22PM (#393994) Journal

    More In the Box thinking on the part of the defenders, and some rule-stretching by the attackers.
    Bravo!

    It goes to show just how vulnerable everything is due to the intertwined nature of everything Digital. Best practices still leave vulnerabilities laying around.

    The password, and its "high-tech" cryptographic offspring, is probably the single biggest security blunder the entire industry has made. The whole concept is due for some out of the left field new idea to come along and change everything. I have no clue what it will be, but it can't come soon enough.

    --
    No, you are mistaken. I've always had this sig.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Interesting=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 4, Insightful) by Anonymous Coward on Saturday August 27 2016, @08:37PM

    by Anonymous Coward on Saturday August 27 2016, @08:37PM (#394030)

    I have no clue what it will be, but it can't come soon enough.

    It can fuck right off if it involves fingerprints or other such nonsense.

  • (Score: 2) by Scruffy Beard 2 on Saturday August 27 2016, @08:58PM

    by Scruffy Beard 2 (6030) on Saturday August 27 2016, @08:58PM (#394037)

    Public key encryption has some feature passwords lack.

    For example, I am considering encrypting my back-up in transit. Instead of sending the encryption key separately, I can simply encrypt them with the back-up server's public key.

    The private key would be encrypted with a long passprase that I carry with me. The passphrase alone will not decrypt the data though.

    • (Score: 3, Insightful) by DrkShadow on Saturday August 27 2016, @09:06PM

      by DrkShadow (1404) on Saturday August 27 2016, @09:06PM (#394039)

      After discovering an unpatched, unfirewalled Elasticsearch instance using nmap, we gained shell access on a utility server used for various functions at Inversoft. On there, we found private keys for Linode left behind by a human operator. Those keys allowed us to detach disks from running servers...

      Public key crypto has the same drawbacks as API keys being left around: if you have the private key, you have everything. I bet you don't even password-protect your private keys ...

      • (Score: 3, Touché) by gnampff on Saturday August 27 2016, @09:30PM

        by gnampff (5658) on Saturday August 27 2016, @09:30PM (#394042)

        You lost the bet. Please consider reading the last of the three lines your were replying to. Something about a long passphrase for the key :)

        • (Score: 0) by Anonymous Coward on Sunday August 28 2016, @05:55AM

          by Anonymous Coward on Sunday August 28 2016, @05:55AM (#394111)

          I see the words "would be" not the word "is."

      • (Score: 2) by Scruffy Beard 2 on Sunday August 28 2016, @04:33AM

        by Scruffy Beard 2 (6030) on Sunday August 28 2016, @04:33AM (#394098)

        While I have not implemented it yet, I was thinking the private key would exist only on the back-up server. If the key is lost, the data on the server is probably gone as well. Any (optional) second server would have its own private key.

        Where I think encrypting your key is a little pointless is when you are backing up your keys (not the case in the scenario above). If you use a passphrase protect your secret keys, you need to store the passphrase somewhere. Encrypting the key with a passphrase also prevents m of n key distribution schemes.

        And yes, the PGP or GPG file on a computer in active use should have the keys encrypted with a passphrase.

        • (Score: 2) by Scruffy Beard 2 on Sunday August 28 2016, @04:37AM

          by Scruffy Beard 2 (6030) on Sunday August 28 2016, @04:37AM (#394099)

          Maybe the confusion arose because I was using a "server" to refer to a machine with no direct network access.

          Sneakernet [wikipedia.org] FTW!