A case for more accessible cybersecurity
If you’re a part of the infosec community, you’re likely all too familiar with the frantic calls, text messages and emails we receive from our friends and family about how they’ve been ‘hacked’ and asking what they should do about it.
One of my favorite personal instances of this was when a family member threw away her PC because she was convinced she ‘got the Heartbleed bug.’ Of course, being the loving people that we are, we do the best we can to inform them of what is likely the issue (if there is any in the first place) and try our best not to snicker when they confuse a bug in OpenSSL with malware. I usually end up capping off my advice with something that makes me feel uncomfortably professional, like “update your software and enable two-factor authentication where available.”
What may come as a surprise is that I sometimes get questions similar to these from new analysts or people interested in the field. Truth be told, some of them are questions I asked myself early in my career. I remember the first time I saw a “TTL exceeded” message from a corporate IP to a Chinese IP and I thought I was witnessing data exfiltration.
Experiences like that have taught me that not asking is good way to perpetuate ignorance. However, it also highlights the steepness of the security learning curve and how much additional legwork is often needed to find the true root of a problem.
Case in point: The ACKening
Just recently I received a text from a friend who is hoping to break into the security analyst field. Unlike our usual exchanges, this time he wasn’t texting to ask me about what reverse engineering tutorials I recommend or what websites I frequent. Instead, he had sent me an 1,813-character novella filled with over-excitement and expletives galore. It detailed a potential attack on him and his roommates from an unknown assailant on the Interwebs.
It all started when he began to notice that his router was running slower than normal. He decided to do a factory reset, firmware update and then check the logs. To his surprise, the logs included an alert! The activity was labelled “dos attack: ACK scan.”
This log entry was not there just one time, but many, many times over. It wasn’t just from one IP address either. He checked the timestamps and saw that all of this happened while he and his roommates were not home. He described how his heart began to race as a horrifying scenario played out in his mind.
Fortunately, none of that actually happened. Let me explain.
The log entry my friend saw is referring to a potential DoS attack, so even if the signature was correct it would mean that the worst you would expect is that your internet service would slow down (perhaps to a halt, but still just slow down).
That leads me to my second point: what are the chances that signature is correct? If this was a corporate network’s SOC, something like 80-90% of the alerts processed would be false positives, meaning that the alert didn’t identify what it claimed to. In a corporate networks SOC, there is a lot more traffic, but teams are also using a lot more sophisticated tools than the router or modem you’re renting at home from your ISP.
My home router thinks that the traffic coming from the DNS servers I use is a UDP DoS attack – this kind of false positive is incredibly common. The reason the alert is triggered is because every time any of my devices makes a DNS request, it sends it to the same server, and that server sends the response back. The primitive alert engine on the router sees “lots of UDP traffic from a single source” and jumps to conclusions.
The third thing to mention is that “ACK” scan, is very likely just referring to some high number of ACK packets, which is part of the TCP handshake. An ACK packet on its own is not really a whole lot of anything other than finishing up establishing a TCP session. I wouldn’t expect ACK packets to have much to do with what you would traditionally think of as “hacking,” like the scenarios in the comic strip above. ACK packets can be used in DoS attacks by sending a ton of spoofed ACK packets to the device that don’t belong to any sessions (which is likely what this log was trying to identify), however, as I said before, the purpose of that is to deny your service, not hack your pewters.
What does it all mean?
To begin with, what my friend and many people starting out in the security field need to realize is that there are always going to be new threats but not all are worth chasing. But as an industry, we need to realize how misleading – and even exclusionary – it can be to leave fresh security talent to work off of a single alert or a few snippets of information. If we hope to make progress against the skills gap, we need to start putting more context at people’s fingertips.
From a technology perspective, this means creating tools that allow analysts to ‘see the forest through the trees’ by surfacing the data and connections that are really important. Think of it like Amazon’s Alexa – there are hundreds of “skills” it’s capable of learning, but how many does a single person really need at any given time? Still, it’s nice to know that they’re all available to you in case you need a new one down the line.
The same is needed with security technology. Currently, there’s a ton of data out there, but it’s often spread across several tools and scattered in different places. Each time a new type of threat emerges, analysts need to get and learn a new tool that tackles the specific problem, rather than being able to teach their existing tools a new “skill” that will do the work for them. For the sake of the newbie analyst, we need to filter out the noise by allowing of-the-moment skills development to tackle new security problems as they emerge—rather than overhauling entire toolbelts to chase the latest threat.