On May 18th and 19th, Artsiom Holub and I attended and presented at the SOURCE Boston 2016 conference. SOURCE is a great conference, well planned so that people in any role can attend and walk away with a greater understanding about a variety of infosec topics.

Each talk centered around a different security aspect, making for a more comprehensive meeting of the minds. Things like: how to talk to someone about security, what it is to be secure, and the technology and philosophy encompassing all depths of security. Sometimes we researchers get so involved in the details of our projects and algorithms that we can’t see the forest for the trees, and this is a dangerous path to walk down; there’s an easily lost balance between the scope of the problem and the focus of the solution, so having the big picture redrawn at a conference like this is reorienting and refreshing.

First, I must applaud Rob Cheyne on his use of speed networking at the beginning of the conference. Not only did this break the ice for the attendees, but for speakers like me, it was a great source of support and advice from others. That kind of robust interaction resulted in a familiar face in every session of every track.

 

Source Boston Day 1

Source Boston

My water taxi view as I approached downtown Boston to attend Source Conference

 

The first day opened with a thought-provoking keynote from Richard Thieme (ThiemeWorks). “Play through the Pain? The Impact of Forbidden Knowledge on Security and Intelligence Professionals” touched on the hardships of keeping secret or classified information, maintaining a work/life balance, and the personal relationship strain that comes from both. Although I do not work with classified information, my role in the protection of customer data can have an adverse effect on home life.

After some speed networking, I attended “Defending the Cloud from the Full Stack Hack” from Erik Peterson (Veracode), followed by “How Security In the Cloud Changes” from Nathan Cooprider (Threat Stack). These sessions played well off one another, because after hearing Erik talk about the cloud equivalent of physical security, Nathan applied colorful metaphors to what I had just learned.

Erik reminded us all that API access to the cloud is the same as physical access to a server room; because all the servers are now under a single API key, a small vulnerability in one system can compromise your entire network. He also reminded us that it is important to not use your cloud service bill as your Intrusion Detection System (IDS), and that there are ways of monitoring cloud usage through logging.

Erik’s warnings were followed nicely by Nathan’s relation of a cloud infrastructure to the Maginot Line and Belgium playing the roll of a zero-day exploit. Nathan also pointed out that we have to stop treating cloud instances as pets and learn to treat them like cattle: know a sure-fire way to get a replacement, and if it starts acting up, take it out. Part of the benefit of having these virtualized appliances is the fact that we can replace them quickly, so why are we so hesitant to do so?

Next was scheduled as lunch, but instead, I used the time for mental preparation, to ensure that my laptop was cooperating with the projector, and to verify that my lapel microphone was working through the sound-dampening powers of my beard. Because this was only my second speaking engagement — and first away from home base — it was as much a learning experience for me as it was for anyone sitting in on my presentation. The best advice I received during the speed networking session was that “nobody wants you to go up there and fail – everyone is rooting for you.” It’s natural to be a little nervous, but hearing that was very reassuring.

 

I learned three important things during my presentation:

  1. Do not rely on an Internet connection for anything – always have a backup plan. I had a backup plan, and verified that my video recording of a “live” demo displayed on the projector beforehand. It worked perfectly.
  2. Remember to breathe – not only for my benefit, but for the benefit of my audience. Pauses are important because they allow time for all that information I dumped out in one breath to sink in and make sense.
  3. Test every slide – My embedded MP4 video performed perfectly during testing, my animated GIF? Not so much. I still do not know why, but for anyone who wanted to see it, here it is (you may have to click it to watch it):

    Tinba Key Search animation from Source Boston

    Reversing the tinba DGA algorithm to determine the key or set of keys missing from Source Boston presentation

 

An overview of my presentation

I divide all DGAs into two categories, streamed, and chained.  A streamed DGA uses some kind of pseudo-random number generator (PRNG) to generate a stream of numbers which are converted into letters, and then divided into domains as the stream is running.  A chained DGA is one that the previous domain name generated is used in whole to calculate the next domain name.  Each of these categories can include many features, but they are generally one or the other.

 

Slide08

 

DGA categories and features

Chained DGAs can be easy to tackle because all or some of the algorithm used to create them can be reversed.  If the triangle in the diagram below represents the normal flow of a chained DGA, you can imagine that with any two corners, you may be able to solve for the third.  My presentation described just a process and how we use that to our advantage to protect our customers in real time.

DGA Triangle

The normal flow of a chained DGA as presented at SOURCE Boston conference

 

After answering a good set of follow-up of questions, I sat in on Chris Schmidt‘s “The Bad Guys Have Your Pacemaker: How to Stop Attacks on Your IoT Devices.” Chris reminded us that everything you never wanted to network is beginning to join the ranks of the Internet of Things (IoT): smart refrigerators, toasters, light bulbs. Feature-rich may be the end-consumer’s dream, but vulnerability-rich is the current market trend. You may wonder, “what’s the worst that could happen with a smart light bulb?” If some stranger controlling when a random kitchen light turns on and off seems benign enough, Chris encouraged us to consider another possible scenario: what if the same vulnerability that allows that bulb be turned on and off also enables access to firmware controls of wattage beyond the threshold of safety? Did somebody in front of a keyboard thousands of miles away just burn your house down? He said it many times, and I hope this becomes IoT’s mantra: “Build security in!”

I missed the last session in order to grab lunch, but I was able to return in time for the last keynote of the day, given by Chris Nickerson (Lares Consulting). “Nightmares of a Pentester” left us rethinking security. “Does that appliance really give you security, because security isn’t a thing? Have you tested it? Configured it?” Security is a proactive thing; maybe that IDS needs to be pointed to internal traffic too, because not everything bad comes in from an external connection. He's right you know

 

Source Boston Day 2

After a rather unsuccessful night’s sleep and missing the morning keynote, I sat in on colleague Artsiom Holub’s talk on “Deconstructing the Cyber Kill Chain of Angler Campaign”. It was actually the first time I’ve been able to sit through a colleague’s presentation, and I found it satisfying to see a summation of all the hard work behind the slides. His talk covered evolution of Angler Exploit Kit, it’s role in raising of the ransomware threat, methods to deliver payloads, and families of the malware being delivered. It also covered procedures and tools that OpenDNS use to proactively discover and block this threat. In addition preventative measures were discussed. Implementation of them can help end-users and system administrators mitigate the risk of malware infections that use Angler as a delivery mechanism. 

Next I sat in on “The Topology of Malicious Activity IPv4” from Suchin Gururangan and Bob Rudis (Rapid7). Using projects Sonar and Heisenberg, Rapid7 has a massive corpus of data to work with by effectively scanning the IPv4 Internet space. One additional takeaway is that although Rapid7 is doing security research, Suchin identifies as a Data Scientist, not a Security Researcher. He’s an integral part of the team at work discovering valuable data that just happens to be security-related. This serves as another reminder that the value of a team can be measured by its roundedness as a whole, and not necessarily by each team member’s specifics.

Because we were in Boston, I decided that Artsiom and I should do the most Boston-y thing in Boston I could think of for lunch, so we ventured out to Faneuil Hall Marketplace to enjoy a seafood meal from the Quincy Market Colonnade, the largest food hall in New England. There is nothing about a lobster roll and New England clam chowder in a bread bowl that is less than perfection. And, yes, I am picky about my New England clam chowder because let’s face it, if it’s New England “style” clam chowder, you’re only fooling yourself.

Source Boston affords you certain opportunities

New England clam chowder in a bread bowl

With a full belly, I sat in on “Why is Network Access Control So Hard: There Must Be A Better Way” from Jason Garbis (Cryptzone). Although I had never really questioned the traditional techniques of authentication over a network, this session opened my eyes to another way of thinking. Why should anyone be allowed an attempt to authenticate when you can control who has access to what network resource through network access controls first? I enjoyed learning about this technique and will keep it in the back of my mind for future use.

For the last session, I sat in on “Side Channel with Intel Cache Allocation Technique” by Pei Luo (Northeastern University) and Xiaoning Li (Intel), presented by Xiaoning Li. I’ve not personally investigated side channel attacks, but I understand there is always the potential one might occur. In this talk, it was brought to my attention that (especially where cloud computing is in use) although a Virtual Machine (VM) may use a single dedicated processor, somebody else may be running another VM which, although it uses another dedicated processor, may share a higher level of cache and thus is vulnerable to this type of attack.

Overall, Source Boston was a great conference to experience and I hope to attend again in the future.

This post is categorized in: