Mandatory Java Security Training



  • I just got an email blast sent out to everyone in the firm (and I mean all 200+K of us) regarding mandatory training about how to avoid coding potential security loopholes in Java. The demonstration will be via webex (ok). It will use the production database (hmmm). 

    It then went on to include:

       - the dial-in phone number (ok)
    - the passcode for the call (ok)
    - the webex url (ok)
    - the webex passcode (ok)
    - the url for the database to be used (uh oh)
    - the login and cleartext password so we can access the database
    via sql-developer to follow along with the webex (WTF?!)

    That's right. They gave the login and password to the fucking production database (that they spent the last year taking away from everyone) to everyone, whether they were a support person or not, whether they were a developer or not, whether they know java or not.



  • But you didnt post the information here!!!! <wicked grin>


  • Trolleybus Mechanic

    @TheCPUWizard said:

    But you didnt post the information here!!!! <wicked grin>
     

    Username: database

    Password: letmein

     



  • Using the production-database to give a demo and giving everyone the password is bad enough though the real cherry is the fact that this is for a SECURITY TRAINING.

    WTF were they thinking?



  • Bonus WTF

    When I pointed out what the training folks had just done, the db folks immediately changed the production passwords.

    Before we could stop them from changing the production db password, numerous on-demand production systems immediately started failing as they no longer had access to the database.

    Of course, the DBAs had to put the passwords back to their original values.

    Naturally, there was a flurry of emails - before, during and after - to a whole lot of people - all replying-to-all (with the original login and password still visible).

    Sigh.

     



  • BTW: this all happened in the last hour. The security training starts in 30 minutes. I can't wait to see what they tell us.

     



  • @snoofle said:

    BTW: this all happened in the last hour. The security training starts in 30 minutes. I can't wait to see what they tell us.

    And we can't wait to hear it!



  • @AJK85 said:

    @snoofle said:
    BTW: this all happened in the last hour. The security training starts in 30 minutes. I can't wait to see what they tell us.
    And we can't wait to hear it!
    The class is supposed to last all day. If there's anything noteworthy, I'll post it on Saturday or Monday.



  • @snoofle said:

    Naturally, there was a flurry of emails - before, during and after - to a whole lot of people - all replying-to-all (with the original login and password still visible).

     

     

    If your email server survived that, you can at least take some comfort in the fact that your email admins know what they are doing :}

     

     


  • ♿ (Parody)

    @Lorne Kates said:

    Username: database scott

    Password: letmein tiger

    FTFY

  • ♿ (Parody)

    @snoofle said:

    BTW: this all happened in the last hour. The security training starts in 30 minutes. I can't wait to see what they tell us.

    The security training has been completed        
    in an entirely different database at great
    expense and at the last minute.   
    


  • That is the biggest WTF I think I've seen. Absolutely amazing.



  • @snoofle said:

    Bonus WTF

    When I pointed out what the training folks had just done, the db folks immediately changed the production passwords.

    Before we could stop them from changing the production db password, numerous on-demand production systems immediately started failing as they no longer had access to the database.

    Of course, the DBAs had to put the passwords back to their original values.

    Naturally, there was a flurry of emails - before, during and after - to a whole lot of people - all replying-to-all (with the original login and password still visible).

    Sigh.

     

     

    You need to cook up an embarrasing, but recoverable, "sample" query. Maybe something that appends "snoofleCorp R 1d10ts!!!" to all the customer names, for instance. Then send that out as an example query to everyone via "reply to all".

    Word the email along the lines of "wouldn't it be funny if..." so you can pretend you just meant to send to your immidiate co-workers and 'accidentally' hit reply to all.

    Bonus side effect: PHBs at your co decree that a custom solution to disable reply to all is implemented :-)


     



  • ...so far I've been in the class for about two hours (on a break).

    Basically, it's like in the military when they give you a class on how to defend yourself against torture: they show you a whole bunch of different types of torture, then tell you that there's no known defense against them. What they've really taught you is how to torture people.

    I've spent the last few hours learning how to do SQL injection, authentication spoofing and XSS.

     


  • Considered Harmful

    @snoofle said:

    SQL injection, authentication spoofing and XSS.

    But. There are known defenses against each and every one of those.



  • @snoofle said:

    ...so far I've been in the class for about two hours (on a break).

    Basically, it's like in the military when they give you a class on how to defend yourself against torture: they show you a whole bunch of different types of torture, then tell you that there's no known defense against them. What they've really taught you is how to torture people.

    I've spent the last few hours learning how to do SQL injection, authentication spoofing and XSS.

     

    So, does this mean that the company business model is changing to renting out black-hat "services?"



  • Whoever gave the production DB password to training should be shot first thing Monday and hung from the flagpole in front of the building. No wait, they should be hung from the flagpole first thing Monday, then shot at quitting time while still there.



  • @YourNameHere said:

    Whoever gave the production DB password to training should be shot first thing Monday and hung from the flagpole in front of the building. No wait, they should be hung from the flagpole first thing Monday, then shot at quitting time while still there.
    Piñata.



  • @YourNameHere said:

    Whoever gave the production DB password to training should be shot first thing Monday and hung from the flagpole in front of the building. No wait, they should be hung from the flagpole first thing Monday, then shot at quitting time while still there.
    I think the shooting should have been the first item on the agenda.  The best time would be to do it is close to the end to help keep everyones attention, and it would give it a great finale and would def boost morale.

    Does anyone know if normally an email sys admins can perform a mass delete of all the meeting notice emails containing the production database information?

     



  • @Anketam said:

    Does anyone know if normally an email sys admins can perform a mass delete of all the meeting notice emails containing the production database information?

    Exchange/Outlook can "recall" messages, but it only works under very specific circumstances. If someone's already opened the message, that person has a copy that can't be recalled and nothing prevents them from forwarding it on.

    Other than that you could write a script that dives into the email repository and deletes the email, matching sender and email ID. But that won't work if anybody uses a local archive instead of reading email on the server, once the email is downloaded, the client could have saved it anywhere and there's no way to make it go away.

    If they're using any other email system, it probably has even less support for this than Exchange does.



  • Deleting the emails is a moot point. The password is a very-easy-to-remember: Princess12 and the login is the same one as in all the other environments, so everyone who would know what to do with it already knows it.



  • @snoofle said:

    Deleting the emails is a moot point. The password is a very-easy-to-remember: Princess12 and the login is the same one as in all the other environments, so everyone who would know what to do with it already knows it.
     

    See! They use mixed-case passwords and they use numbers. They already know all about security.



  • I would blast reply-all mocking their stupidity and credibility. They need to be fired on the spot.


  • Trolleybus Mechanic

    @OhNoDevelopment said:

    I would blast reply-all mocking their stupidity and credibility. They need to be fired on the spot.
     

    I would pick one of the code-shitters who keep shitting up snoofle's code. I'd casually mention (verbally) that the plaintext password is in the email, isn't that weird? I bet no one even noticed. Man, whoever points that out to everyone's going to be a damn hero for stopping a major data leak, and will get to embarrass one of those lowly training people in the process.

     I'd then sit back and watch the fun enfold. Codeshitter sends a scathing reply-all.  Training person, since he's been attacked, sends back a defensive one. This little piss war gets bounced all the way up the chain of command. Not only has an embarrassing mistake been publicly pointed out to the point where it cannot be ignored, but the code-shitter gets drawn on quartered for not being a team player.

    Two birds with one owl pellet.



  • Have they taken questions yet? I bet you could think of a really good one.



  • @snoofle said:

    Deleting the emails is a moot point. The password is a very-easy-to-remember: Princess12 and the login is the same one as in all the other environments, so everyone who would know what to do with it already knows it.

    At least it's not "sa", which was our company's external-facing SQL Server password for at least a decade. I've kinda stopped caring about security around here after the powers that be refused to change our "flagship" debtors application, that manages millions in cash for various clients, to use something other than plaintext storage for passwords. The rationale was "it's a desktop app so it's not vulnerable to hackers", at which point I gave up.



  • If this were the start of some fiction, everyone would say that such a stupid thing would never happen. Well, nature is totally superior to art. Fan-tas-tic story.



  • @TGV said:

    If this were the start of some fiction, everyone would say that such a stupid thing would never happen. Well, nature is totally superior to art. Fan-tas-tic story.

    Now you've done it. This being the Internet, it's only a matter of time before erotic fanfic versions of Snoofle's stories start appearing.

     "It Happened in the Conference Room (Boss+1/Boss+2/Boss+3)"

    "Dirty Thoughts and the Database Server"

    "Cluster Server Cluster F"

    Quick: Identify which titles are fanfic, and which are legit stories.

     



  • @snoofle said:

    Before we could stop them from changing the production db password, numerous on-demand production systems immediately started failing

    There, you just pointed out another WTF. Basically all applications running against that db are using the same user/pwd. Many shit comes from this.



  • @RichP said:

    Quick: Identify which titles are fanfic, and which are legit stories.
    That's a hard one (kadjing!).

    "In the server room": snoofle fan fiction

    It was a warm Friday in August. Temperatures outside were running up, and the airco could hardly keep up. Slowly the temperature in the office started rising. Snoofle was glad it was casual Friday, because that meant he could take off his jacket and tie. But what was that? An inconspicuous alarm was blinking on a console two desks away. It was on a monitor on Janice' desk, who he hadn't seen all day, and Janice was one of the few people Snoofle would have noticed. But there were more pressing matters: what was the alarm? Snoofle headed over to Janice's monitors and saw the title of the blinking window: server room temperature. Not only had the office become too warm, the servers were near boiling point.

    Quickly Snoofle ran over to the server room. The door was not locked, which was a bit odd. He pushed the door open, and a blast of hot air hit him. Quickly he closed the door behind him, and started to look for the airco controls. It was so warm, that he quickly unbuttoned his shirt a bit, while wondering around the racks of expensive hardware. Just as he rounded the last rack, he saw Janice: she was lying on the floor, red faced, breathing heavily. In a flash, Snoofle took off Janice' jacket and ...

    Like that?



  • I imagine Janice as weighing 150 Kg / 330 Lb ("Snoofle would have noticed" == "she's rather large").



  • @Zecc said:

    I imagine Janice as weighing 150 Kg / 330 Lb ("Snoofle would have noticed" "she's rather large").
    FTFM



  • @TGV said:

    ...

    Like that?

     

    (in my best Frank Drebin voice): No. No I don't like that at all.

     



  • I say that snoofle, in class discussions about security, should print or email an example SQL script that would vandalise the production DB and make it look like someone else was responsible, thereby fooling investigations. To cover his ass, he should emphasise that it's hypothetical.


  • Trolleybus Mechanic

    @snoofle said:

    security loopholes in Java.
     

    @snoofle said:

    email blast... went on to include... the login and cleartext password so we can access the database
    via sql-developer to follow along with the webex (WTF?!)

    I just realized, this isn't a wtf at all. The class was only supposed to cover security holes in JAVA. So unless your email client was written in Java, there's no reason to blame the highly paid consultant / boss' nephew who wrote the original email. Come on, man, try thinking things through before you blame someone who would be embarrassed if they were forced to take responsibility for their actions.



  • @joe.edwards said:

    @snoofle said:
    SQL injection, authentication spoofing and XSS.
    But. There are known defenses against each and every one of those.
     

    Just playing Devil's Advocate here: there are known ways to prevent each and every one of those.  But if you fail to use them, and someone actually launches an attack on a vulnerability in your system, you're screwed.  There's no defense against *that.*



  • @Mason Wheeler said:

    @joe.edwards said:

    @snoofle said:
    SQL injection, authentication spoofing and XSS.

    But. There are known defenses against each and every one of those.
     

    Just playing Devil's Advocate here: there are known ways to prevent each and every one of those.  But if you fail to use them, and someone actually launches an attack on a vulnerability in your system, you're screwed.  There's no defense against that.

    There's no defense against someone attacking an undefended system?

    I'm failing to grasp your point.



  • Oh my!
    There are some pretty clueless people working at your company..

    Or is this lesson 1 of the training? :)



  •  Wow, this is the most unthinkable snoofle wtf i've read so far.


Log in to reply