Will you hire me?

The Chamber of Deputies had an internship program, and we ended up hiring an intern for the security team. He was a young guy who had just graduated with a degree in Computer Science and already had solid knowledge of security. He started working with us, and we soon noticed he was skilled at testing website security. So we decided to take advantage of his skills and have him test several of the internal systems developed in the Computing Center. Many of those systems had never undergone security testing.

The intern quickly began finding various problems, both in internal systems and in some externally exposed systems, especially those used by other government agencies. One of those systems was almost 20 years old and, we were told, had been developed according to Microsoft’s guidelines at the time. It had a classic SQL injection vulnerability: the query itself was passed as a parameter from the browser to the server. You just had to manipulate the request to completely change the query’s behavior.

In conversations with the intern, it became clear he really liked this kind of activity and tested website security as a hobby. It made sense: that skill came, in part, from practice. He kept helping us with the tests, but also started working on other team activities.

One fine day, the director of the Computing Center called the area coordinator, who was my boss, asking if a certain person worked on our team. It was the intern. The coordinator confirmed this and was called in for an in-person conversation. An email had come in from an IT director at Catho, which at the time was one of the country’s main job sites, claiming that the intern had used the Chamber of Deputies’ network to break into their site.

My boss then had the task of talking to the intern to understand what had happened. At the same time, he asked me to analyze the firewall and proxy logs to check whether there was evidence of attacks on the site from the Chamber’s network.

In the conversation, the intern admitted he had found a flaw in Catho’s site, also related to the WAF they used, from Imperva. He told us that after identifying the problem, he sent an email to the company’s IT director explaining the vulnerability. At the end of the message, he mentioned he was looking for a job, in case they were interested in hiring him. That explained how the company had identified who he was, but the question remained as to why they claimed the access had come from the Chamber’s network.

The intern explained that he normally used a VPN connection to his personal computer at home, so that his connections wouldn’t appear to come from the Chamber’s network. When reviewing the logs, we found one day when he had forgotten to turn on the VPN before testing whether the problem had been fixed. That was when he ended up exposing the source IP address of the Chamber’s internal network.

With the situation clarified, it was clear he had no intention of exploiting the flaw for any illicit gain. He had simply tried to use the discovery as a way to catch the company’s attention for a possible job opportunity. Still, we had a serious conversation with him. We made it clear that this would be the last time we’d defend him in this kind of situation and that, if something similar happened again, the consequences would be more serious. We also emphasized that, regardless of VPN use, this kind of activity shouldn’t be carried out while he was physically on the Chamber’s premises.

Around the same time, the organization decided to deploy electronic timekeeping for all employees. A public tender was held to acquire equipment based on fingerprint reading. This was a project that involved several departments, including the Computing Center and HR. By the time I was called in to participate, the tender had already been concluded and we were at the stage of validating the top-ranked solution.

In practice, that meant checking whether the equipment met the requirements defined in the tender documentation. We set up a room and called the suppliers in to demonstrate their solutions. There were requirements for biometric readers, smart card readers (used in the badges), and also for cryptographic protection mechanisms for the data, ensuring security and privacy.

This project was interesting because it led me to revisit and deepen my knowledge of smart card standards, especially regarding the cryptographic mechanisms used in these devices. By the end of the process, we had to disqualify the supplier that had ranked first, because it could not demonstrate compliance with all the requirements. They were relatively simple flaws, but ones explicitly described in the specifications, which forced us to record them as non-conformities.

The company appealed the decision, and we had to justify the reasons for disqualification several times. Curiously, they ended up making our job easier, because the arguments presented in the appeal showed that they hadn’t properly understood the technical aspects of the requirements. That further reinforced the disqualification decision, since it made their lack of understanding of their own solution clear.

That episode illustrates a recurring problem with procurement processes in Brazil: if the specifications aren’t extremely detailed, it opens the door to companies without the proper technical capability to win on the basis of lowest price alone. That puts a great deal of responsibility on whoever drafts the requirements, since any gap can result in the acquisition of inadequate solutions. It’s not uncommon for equipment bought under these conditions to end up underutilized or even abandoned.

Meanwhile, our team began to realize we needed a better way to handle attacks against the Chamber’s systems. But that’s already a story for another chapter.