The Elmo



  •     I work at a small, open source RFID software company.  I used to work with “Greg” (as we will call him).  He was a very accomplished programmer, and everything he did worked well and had excellent documentation.  Greg had interned before at the First Bank of New Portlandopolis (as we will call it). 

        At the company I work for now, we have punishments for various developer infractions: “The Elmo”* is for minor infractions, such as being late to work or failing to restock the fridge with soda when you take the last one.  “The Goat”** is for serious infractions, such as breaking the build or missing a meeting.  Any employee can go to your desk and press the buttons of the toy, which will then spring to life and sing its heart out, while you silently long for the sweet embrace of death.  This practice of giving The Elmo is a holdover from the First Bank of New Portlandopolis, where several of the current employees (including Greg) had worked. 

        After Greg left, I asked another employee who had worked with Greg if he had ever been punished with animal-induced pain at the bank.  The employee said that he had, and told me the story. 

        Greg was diligently working on the banks system, when he noticed that the software he was working on didn't have any limit of connection attempts before the account was locked out of the system while entering a PIN.  This meant that someone attempting to break in only had 10,000-ish PINs to try before they were in.  Greg, being the diligent employee that he was, wrote up a piece of software that could break into any account the bank had in about 3 seconds. He showed his software to his manager. 

        The next day, Greg was fixing the bug he had found with Elmo doing the chicken dance on his desk. 


    * →  http://www.youtube.com/watch?v=rYIQrScuxj0
    ** → http://www.youtube.com/watch?v=34XXyXL9pY4



  • Wow, so the real WTF is Greg's manager at the other company, who really knew how to discourage developers from disclosing bugs they found? 



  • Maybe we should call this the ostrich approach to security - "What exploit?  There's no security hole!  LALALALALA I can't hear you!" 



  • So, finding bugs is considered an infraction at this bank?

    I can see why he left. 



  • @Zylon said:

    So, finding bugs is considered an infraction at this bank?

    I can see why he left. 

     

    I don't think that it's so much that he found the bug (as you can see by the last line in the story, he fixed the bug), but the fact that he wrote a working exploit without even consulting anyone. What would happen if he had just taken that binary home and not reported the bug at all?

    I think punishing him was a bit extreme, but he definitely should have reported the bug and not written a working exploit until someone had said "that's not a bug!"



  • Nosense. Writing an exploit only helps determining the extent of the problem. You can theorize all you want, but until you actually figure out the gritty details, you might not be fixing the right thing.

    But at least the Elmo threat is sure to deter any hackers who managed to slip into the company from writing exploits for their own code.



  • @KNY said:

    I don't think that it's so much that he found the bug (as you can see by the last line in the story, he fixed the bug), but the fact that he wrote a working exploit without even consulting anyone. What would happen if he had just taken that binary home and not reported the bug at all?

    I disagree.

    He had to test his theory that there was a problem.  How would you do that?  His test proved to work much better than he expected and showed the extent and severity of the problem.  This guy should have been rewarded rather than punished.

    It is not the fact that he wrote the code, it is the purpose he put the code to.  Since he was testing he was doing his job and doing it well.  If he didn't notify anyone and brought the code home, he would have broken the law.



  •  Maybe I'm wrong, but I understood it to mean that the original bug turned out to his... so he discovered his own bug...



  • They should have had one of thos biomimetic pups doing a dance instead of elmo



  • @Faxmachinen said:

    Nosense. Writing an exploit only helps determining the extent of the problem. You can theorize all you want, but until you actually figure out the gritty details, you might not be fixing the right thing.

     

    Exactly.  In other companies they're called "unit tests". 



  • @KattMan said:

    I disagree.

    He had to test his theory that there was a problem.  How would you do that?  His test proved to work much better than he expected and showed the extent and severity of the problem.  This guy should have been rewarded rather than punished.

    It is not the fact that he wrote the code, it is the purpose he put the code to.  Since he was testing he was doing his job and doing it well.  If he didn't notify anyone and brought the code home, he would have broken the law.

     

    The test needed to be run - but he should have still consulted someone.  Some grunt dealing with log data could easily have spotted the unusual traffic and freaked out - depending on the setup in place.  

    Besides, if it had been caught after running the exploit - all he'd have to say for himself was he didn't intend to use the PINs he stole, just... get them to prove an exploit - honest!  Granted, his boss would probably believe him, but its not a fun position to be put in as an employeer.



  • If one tests the exploit on ones own account, or on test accounts, the various log items shouldn't have been a problem.

    It's also possible that he knew that the code wouldn't trigger any logs - if it's not going to fail after three attempts, and there's no artificial delay, who's to say that it's even going to log the attempts? It could wait to log it until the operation is aborted - and so hitting it with a program that wouldn't abort the operation would not show anything funny.

    That having been said, were I in the same position, I would have at least told the boss, "Hey, I think I found a major bug in our security. I'm going to write up a quick test case to verify the problem, and if it really exists, I'll get right on fixing it. Um, actually, you approved me fixing this one when you gave me my job description - it's *that* bad."



  • @Soviut said:

    Exactly.  In other companies they're called "unit tests". 

     

    Not exactly. A unit test for this case would make at 4 login attempts if the system is expected to block him after 3 unsuccesful attempts. It would not attempt to crack the PIN when the test already failed.



  • @Soviut said:

    Exactly.  In other companies they're called "unit tests". 

     Hmmm, there I was, thinking testing should be done on a test environment...

    IMO, he should get punished for running the script on a production environment. There's no excuse for 'hacking' production PINs, not even good intentions.

     



  • Well, first off I'm going to assume he ran it on a dev system without real PIN's... if not legal action would probably be more likely than an elmo toy for attacking a PIN database of a bank..

    Even still, the first step should be going to the manager and going "I think there's a security hole in this, it could potentially comprimise all our pins. I can build a proof-of-concept if you like or I can work on fixing the issue?". If the manager asked you to go ahead with a proof and you build something that can crack the pin in 3 minutes (On the dev DB ofc) then the manager should go "Holy crap, good work, we need to fix this fast!" and a bonus would be more fitting than an elmo toy :P

    On the other hand building the whole exploit while something that fundamental is wrong without telling anyone then yes that is a WTF. A small unit test that sends like 20 fake pins and sees whether you're locked out or not sure, but the whole brute-force top to bottom definately shouldn't have been written. Especially since for your manager it changes from a "We closed a potential risk before it became a reality" to a "One of our developers managed to find a way to steal the pin of any user he wants so we fixed it" when he reports to management... and that's basically for him a "great news" to a "what the hell is wrong with you guys?" :P



  • @fyjham said:

    Well, first off I'm going to assume he ran it on a dev system without real PIN's... if not legal action would probably be more likely than an elmo toy for attacking a PIN database of a bank..

    Even still, the first step should be going to the manager and going "I think there's a security hole in this, it could potentially comprimise all our pins. I can build a proof-of-concept if you like or I can work on fixing the issue?". If the manager asked you to go ahead with a proof and you build something that can crack the pin in 3 minutes (On the dev DB ofc) then the manager should go "Holy crap, good work, we need to fix this fast!" and a bonus would be more fitting than an elmo toy :P

    On the other hand building the whole exploit while something that fundamental is wrong without telling anyone then yes that is a WTF. A small unit test that sends like 20 fake pins and sees whether you're locked out or not sure, but the whole brute-force top to bottom definately shouldn't have been written. Especially since for your manager it changes from a "We closed a potential risk before it became a reality" to a "One of our developers managed to find a way to steal the pin of any user he wants so we fixed it" when he reports to management... and that's basically for him a "great news" to a "what the hell is wrong with you guys?" :P

     

     

    You are correct about the dev system, he was not working with real data.  


Log in to reply