Heading into the Infiltrate conference, I was slightly intimidated that the content might be so far over my head that I couldn't accurately report on many of the talks.
As it turns out, I actually understood much of what the speakers discussed, particularly Omer Coskun, Ryan Stortz, and Joseph Fitzpartrick. Here is what I learned from these three presenters.
Omer Cosnuk talked about "Why nation-state malwares target Telco Networks: Dissecting technical capabilities of Regin and its counterparts." He presented the findings of his 18 months of research into the vulnerabilities of Telco networks.
[ MORE FROM THE SHOW: Offensive hackers should be part of enterprise DNA ]
After the Regin attacks (nation state malware), many European Telco companies became rightfully paranoid as they were indeed the targets of these attacks. Whether the intent was to block communications or access stored subscriber information the attackers understood the vulnerabilities inherent in the architecture of the GSM network, which allowed them to exploit it.
The vulnerabilities in Signaling System 7 (SS7) protocol exist because "it's very old and didn't have security features, but these companies need to use it to communicate with each other," Coskun said. There is no easy fix, but security professionals can take some precautionary measures to prevent an attack. Coskun recommended these four measures:
- IPSec following 3GPP TS 33.201 to ensure end of the tunnels known identities
- Proper SMS inbound and outbound routing to prevent operator network sniffing
- Advanced ACL—whitelist/blacklist partner nodes, anti-spoofing, origin-realm
- Cross-layer checking for messages routed over SS7 and diameter
Coskun also said, "GSM companies are missing forensic capabilities in their data centers and radio stations and base station controller (BSC). If they introduce these forensic capabilities and check indications from the BSC, they can detect and remediate issues."
Ryan Stortz and I sat down to talk about Swift reversing, and he was probably one of the most helpful security folks I've ever had the pleasure of talking to. He really simplified the process of reverse engineering in a way that made sense to me.
His talk, "Swift Reversing" explained the binary reverse engineering of Apple's new program and language that soon everything will be written in.
"Given a binary, how do you reverse if to find problems with business logic, crypto, or handling of user data?" Stortz said. What he has done is take snippets of Swift and looked at the binary then examined what it looked like in binary form and what he could learn from that.
When someone writes a program, "It is written in a higher level programming language, then it is compiled and transferred to computer language called machine code," Stortz said. "Binary reverse engineering is taking machine code and getting it back to that original higher language."
Tools are helpful in this process, and Stortz explained that he uses dis-assemblers to take the bit patterns and output them to disassembly. "There are tools that then can lift that and turn the disassembly into a pseudocode so that you can figure out if it looks like C. There is a tool called Hex-Rays Decompiler—they are the best."
Regardless of the application or tools used in reverse engineering, Stortz said, "You don't want to be encumbered by language features, you want to know what the app does."
Joseph Fitzpatrick, who presented "The Tao of Hardware, the Te of Implants," helped to augment my understanding of exploiting hardware. By tinkering around with hardware, Fitzpatrick was able to plug things in at a low enough level that the software can’t detect it. The result is that he was able to use hardware to get into a system.
In response to the release of the NSA's ANT catalogue, Fitzpatrick and some cohorts created the NSA playset, a joke project, to show the vulnerabilities in any hardware.
Using a variety of cheap products from pogo pins to USB cables, Fitzpatrick demonstrated how easy it is to manipulate hardware. "They’re small they are light and cheap and relatively easy to configure and hard to detect," he said.
His point is not to instill fear, uncertainty, and doubt, but to remind practitioners that vulnerabilities are not only in software. Through recreated hardware a malicious actor can gain entry into a system, modify code, and then transfer privileges to software.
"Don’t trust your hardware. We have a habit of implicitly trusting our hardware, and we need to at least call into question the hardware that we use,” Fitzpatrick said.
This article is published as part of the IDG Contributor Network. Want to Join?