Security testing - crossing the line

I have been pondering the case of Marcus Hutchins who was recently arrested in the U.S for hacking and the parallels to an experience I had a number of years ago.

Marcus Hutchins gained notoriety for stumbling onto a “kill switch” for the WannaCry ransomware in May 2017. He did this by registering a domain during some diagnostic tests he was running against the ransomware, in an effort to learn more about it, which caused the ransomware to believe it was in a lab and shutdown (so he believes). The more detailed explanation is here but to summarise he believes that in a lab environment the ransomware would try to detect if it was in a lab and want to shut itself down to avoid analysis. To try and determine if it was in a lab the ransomware checks to see if a spuriously long domain existed, was being answered, or not. In a lab environment every call by the ransomware would be answered to see what the traffic it was sending but this would also let the ransomware know it was being answered and thus in a lab so it would shutdown. However this also means if you just register the domain then those outside the lab would just shutdown as well…

So fast forward a few months and Marcus goes to the U.S to visit friends at a conference and has been arrested for writing malware by the FBI. This, at time of writing, is unproven but would be odd for someone who is a white hat hacker to be writing malware and selling it on the side as you are making yourself very publicly known and thus a target to people on both sides.

Anyway this led me back to a story I wanted to tell that has very direct parallels with non-technical people in positions of authority and them being needing to take action on something that they don’t understand. So lets rewind a bit, and for this you are going to have to excuse my memory of the situation, to an early part in my career where I was looking at some security testing as part of my job.

Part of my job at this company was to look at the security of an in house application they had built. This was only a part of my job and not the full extent of what I was doing but I was the only person looking at this part of the product and I had been told to test it. So as part of that I started to devise what it was I was going to look at; what happens when you assign privileges, do they work? What happens when you change a password, does it work? When you do this through the GUI does it change in the database?

It was a standard part of the toolkit of most people who worked within IT to have read-only database access; working out what had happened and how to fix was part of the job especially in test. So as part of my job to test the permissions and passwords changing within the security module I also checked they had changed within the database but that is where things started to look a little odd to me.

Having run a query to select the T_Users table (table names changed to protect the innocent!) I notice something:

Why are James, Bill and Emily’s passwords the same? Why would they think of the same password? I bet it’s because they used “Password”. So I check this by logging into the test system as Bill with the password of “password” and sure enough I can login. But I also notice that the length of the password actually matches the length of the word “Password” if you remove the $ symbols (none of this is rocket science). I further notice that position 3 of my password is also the letter “S” and the number 29  which is then repeated for the next letter which is also “S”  so it must be direct substituting letters for numbers. So what position is the letter S in the alphabet? 19. What position is P? 16.

• P (position 16 in the alphabet) : 26 - 10 = 16
• A (position 1 in the alphabet) : 11 - 10 = 1
• S (position 19 in the alphabet): 29 - 10 = 19
• S (position 19 in the alphabet): 29 - 10 = 19

Oh dear.

So clearly the strength of the encryption of the passwords in the database wasn’t terribly strong. What was slightly worse is that most people in the live environment also had some sort of query access to the database to run reports against it (the system was still in development).

Then another thought struck me; what is in the .ini file that the application (executable) uses to login into the database to do it’s work.

(.ini file)
Username: BLAHBLAH
Password: 32$28$29$27$19$20$21$32$35$17$27$26$18$15$31$20$24

Oh please don’t tell me this is true. I notice that the username is the Oracle schema owner (not a user with privileges to do work) and that this password looks awfully familiar. So to finish my testing I “decrypt” the password and check that by logging into the live system with the username and the decrypted password.

Mistake.

No alarm bells go off or anything but I realise I have just logged into the live company system as the schema owner with access to everything. This is possibly a step too far and in hindsight I wish I had logged into test (they would have been the same passwords, same data etc etc but there you go).  But of course I am testing this module for the security of the system so I go over to the developers and start to talk to them about how their encryption isn’t very strong (this is understating it somewhat). The next thing I know I am brought in-front of my boss and told that I am subject to a disciplinary.

The disciplinary runs along the lines of:

• Why were you testing the security module? Because you told me to.
• Why did you test the passwords? Because I was testing the security module.
• Who told you to check the passwords? No-one, but you didn’t tell me what to do or give me any other instructions other than test the module.
• Why did you think it was your job to test the encryption? No-one else is testing it, who else is going to check it. You spot a problem you have a look to see if it is “broken” you don’t just ignore it!

So that goes on for about an hour and, what with me being slightly inexperienced in these things, I am very very nervous and wondering what is going to happen to me. I understand that the database manager wants me fired, one of the other managers thinks I was only doing my job and the developers are kind of embarrassed. So with the director of the department and an HR advisor sat there in this disciplinary meeting I am told I am being given a verbal warning. *phew*

So I now look at this with years of hindsight and the benefits of being in management and working out what I would do. Looking back I am pretty sure that none of those involved had any idea of what they were talking about. The development team was blowing smoke and trying to deflect attention away from their poor coding and the management team was trying to work what was going on. Had their been a technical manager involved above me I doubt I would have gone anywhere near a disciplinary but all those above me were project managers. They needed to take some sort of action but didn’t know what was proportional or appropriate so they ended up making a whole load of noise and doing nothing.

So where are the parallels to Marcus? Well the lack of technical understanding of the management involved in my little incident meant they could not objectively evaluate what had taken place and whether or not I had acted in the best interests of the company, they only knew the word “hacker” and that must mean I had done something bad. The U.S justice department needs to “get results” in the current political climate and I cannot help but wonder if their lack of technical skillset has led them to go after a “hacker” who once wrote code to show how other people hack into systems (how else are you going to know?). Marcus is a, young, white hat hacker and finds problems that can be fixed before someone with malicious intentions finds it, exploits it and causes damage. In both our cases if you don’t look and reverse engineer systems and code you will not be able to determine if it is secure or actually poses a vulnerability. By writing code showing how hackers work he educates coders on how to protect their systems by showing them the vulnerabilities.

It’s a fine and difficult line to walk where you are trying to explain the methods used to gain access to help stop criminal activity without looking like a criminal yourself. But this goes on all the time where people pick locks on youtube and show it is done to show you how good or bad a product might be and how difficult it is to pick. There are guys called “Lock Smiths” who pick locks for a living when you lock yourself out and you don’t see them being arrested by police as soon as they let someone back into their home.

I feel sorry for Marcus as it is going to be difficult for him to explain his actions to a potentially non-technical audience in even more so to a “jury of his peers” in the differences between white and black hat hacking. I am also giving him the benefit of the doubt as we all should in these cases until different evidence appears. For a guy so young he, like I was back then, must be very worried about his future and i do feel for him.

For the record I continued to work, and undertook multiple roles, at the same company for many years before I left to progress my career elsewhere. Of those involved I continued to enjoy a good working relationship with all and the whole episode was swept under the rug where I think they would have preferred it had never been dragged out from in the first place!