[00:00:36] Camille Morhardt: Hi, and welcome to this episode of Cyber Security Inside What That Means with Camille. Today, we’ve got three of the leaders of the teams that won the Hack@ event, which is a design automation conference event that took place December, 2021. This was a hardware security capture the flag two day long competition that they and their teams participated in. So welcome. We have Animesh Chowdury from NYU. We have Orlando Arias from University of Florida and Baleegh Ahmad also from NYU, but a different team–so some good internal competition there. Welcome to the show.
[00:01:18] Animesh Chowdury: Thanks, Camille.
[00:01:19] Baleegh Ahmad: Yeah, glad to be here.
[00:01:20] Orlando Arias: Thank you.
[00:01:21] Camille Morhardt: Cool. So I was telling these guys, I am not the level of technical that they are by any means. So I’m going to ask both kinds of questions. I want to know the winning strategy. I also want to know some of the human aspects of what it’s like to enter a competition like this, but let me kick it off. Animesh, how did you guys pick the name of your team? That’s my first question.
[00:01:45] Animesh Chowdury: Yeah, so my team name is [inaudible 00:01:47], so it’s kind of a sword, a mythological sword, which actually has this double agent kind of thing. So it actually represents the power and the strength. It’s the simple motivation to pick a name for my team. Also, I was participating as a one man team, so I find it not competitive. So I did not have to compete with anyone for the team name. I just went ahead with that.
[00:02:11] Camille Morhardt: So you actually did not have any other team members. It was one-man show.
[00:02:15] Animesh Chowdury: Yeah, it’s a one man show.
[00:02:17] Camille Morhardt: Okay. So you did not sleep for two days.
[00:02:21] Animesh Chowdury: So it was not like that I didn’t sleep, but I slept for couple of hours, three, four hours a day. That’s all.
[00:02:27] Camille Morhardt: Interesting. So I’m going to move on to Orlando and I want to know for you guys, what was the winning strategy?
[00:02:35] Orlando Arias: We had a strategy going into the competition. We had a bunch of pre-written tools and that was one of our motivations to enter–to see how our tools actually dealt with scenarios that were not crafted by us in any means. So going in, we looked at the HDL, then we ran the HDL through our tools and we got some results out of that. We examined some of those results manually. We examined some of the HDL manually for possible things that our tools didn’t really give us, and then after finding possible vulnerabilities, we began trying to write software exploits to be able to do stuff with them.
[00:03:18] Camille Morhardt: So why are you writing software exploits when you’re trying to capture the flag? Can you explain how that plays into it?
[00:03:26] Orlando Arias: The idea was that there were hardware vulnerabilities, but some of these hardware vulnerabilities to actually see the full effects you needed to run some code on that SOC, on that system on ship, that we were given. Some of the bug in the hardware allowed us to illegally access data that we will otherwise have no actual access to or to illegally modify data in ways that we weren’t supposed to modify in order to actually showcase the effects of the bug. That’s where software running on the platform came to actually be … it was kind of like a demonstration thing. So here’s the bug, here are the consequences of the bug once you run this piece of code, meaning we will access cryptographic keys that we will otherwise have no access to. We will change security settings on the SOC that we will normally have no access to, that kind of thing.
[00:04:29] Camille Morhardt: Did you have to write those on the fly or were those things that you could bring portions of tools you’d already written?
[00:04:37] Orlando Arias: So for the demonstrations, these were things that we had to write on the fly given some of the example code that we were given. The platform that we were using had a library that helped us access some of the hardware features that we wanted to utilize and through making calls through those libraries, we were able to actually make our development process a bit easier.
[00:05:06] Camille Morhardt: So Baleegh, I’m going to go to you and I’m going to ask you, do you think that this is a … is this a team sport?
[00:05:11] Baleegh Ahmad: I mean, the more people you have the better. That’s for sure. Because quantity matters, it’s the amount of bugs you can identify and there were plenty out there. So I think within that timeframe, especially because of that time crunch, it’s definitely a team sport so you have advantage in numbers.
[00:05:28] Camille Morhardt: Did you and your teammates divide and conquer according to type of bug or portion of triage or some people were writing code and other people were fielding or looking for stuff? How do you divide up the work?
[00:05:42] Baleegh Ahmad: So, yeah, initially we started looking at different peripherals, so we assigned different peripherals within the system on chip to each individual. That kind of worked well for phase one, but also within phase one, we kind of realized that everything is connected to everything. So dividing by these different peripherals won’t necessarily work too well. So eventually we gravitated towards more of a strategy based division. So my teammate Abdul was more focused on generating user exploits using the virtual machine and I was more focused on generating automated exploits. So I think that was a better strategy when we started dividing things based on different strategy rather than looking at different parts of the code.
[00:06:28] Camille Morhardt: Yeah. Let me ask, Animesh, a similar kind of a question, because you were a one-man show. So did you have to then approach at all kind of systemically from the beginning or did you just take part by part?
[00:06:40] Animesh Chowdury: Okay. So one of the things I would say that helped me a lot is by looking at the bugs which were given to us in the phase one of the competition. So the phase one competition actually spans around 30 to 40 days where you have got eventually a lot of time to analyze different parts of the SOC and see which parts of SOC might be much more vulnerable than the other parts. So in that way, before entering into phase two of the competition, which is 48 hours, so I have to prioritize the areas of SOC, which are likely to have much more bugs than the other side. So I specifically looked at certain peripherals code, some other … so for example, there is something called memory manager. So there I knew that some sort of bugs can be there so I tried to focus my attention on certain areas in order to compete with the other teams where much more people were trying to find the bugs, I would say. So participation in phase one helped me to prioritize my selection in SOC to find the bugs for phase two.
[00:07:50] Camille Morhardt: You’re a winner, so I want to ask in the future, would you have teammates or would you go solo again?
[00:07:58] Animesh Chowdury: I think having, as Baleegh was saying, that having more numbers is way more better and the good part is we actually belong to the same university and our advisor is also same. So in a way I would say that when we were competing, we were adopting different strategies and those strategies were orthogonal. So after the competition, we were thinking that if we both team combined together, we would have scored more points than individual teams.
[00:08:26] Camille Morhardt: Orlando, tell me something that surprised you about this competition. First of all, is it the first type of competition you’ve entered like this, or have you done many?
[00:08:36] Orlando Arias: This is the first time I’ve been in a competition of this hackathon style where it is a continuous stream of do as much as you can in this time period. I’ve been in other competitions before. I’ve participating in ES Week, which is usually held in NYU where these other nice gentlemen are from, and at least embedded systems challenge over there was always more like a one day event with a predetermined schedule. You present your findings at a certain time and that’s pretty much it. You demonstrate what you have and then the judges will come by and tell you, “Hey, so this is how well you did.”
Yeah, it was kind of fun in a sense, but it’s not a style that … it’s the first time I get to participate in a competition with that particular style.
[00:09:37] Camille Morhardt: So Baleegh, it’s not very civilized to go straight. This is a little bit more, dare I say, real world when it doesn’t stop just because it’s bedtime. How did you and your team handle it?
[00:09:49] Baleegh Ahmad: So two of us were able to join in person during the conference and one of our teammates was online. I don’t think we got a lot of sleep together, but since we were using the same common virtual machine that the organizers provided us, we were kind of able to divide times a bit. So I would sleep and somebody else would use the simulation and then we would kind of alter that a bit. So I think that worked out for us.
[00:10:16] Camille Morhardt: Was there anything for any of you that really surprised you that you were not expecting?
[00:10:23] Baleegh Ahmad: I think for me personally, in phase two we weren’t expecting the inclusion of formal tools. So we were introduced to all these tools and I hadn’t used them before. Right? So just to get that opportunity and that a better level of ability to intrude into the SOC, that was, that was a bit out of the box or at least we didn’t expect it. Right? So I think that took us a while to get used to learning those new tools because there’s a bit of a learning curve there.
[00:10:54] Camille Morhardt: Orlando, you’d also found something surprising. What was that?
[00:10:58] Orlando Arias: Yeah, it was more on the technical aspect of things. We were kind of surprised the amount of things some of the existing HDLs, hardware descriptor languages, which is what we were working with, let you get away with. Now, a portion of my background is in systems programming so I get to deal with things like C and assembly and all of those low level languages and they can be finicky and you can make pretty huge mistakes if you’re not careful.
But for something like describing hardware, we found some constructs in SystemVerilog, the language we were using in the SOC, that I feel at the very least that the tools that convert this language into either a simulation environment or an actual piece of hardware, once you put it on an entire silicon workflow tool chain, the tools, I feel like they should reject some of the constructs that we saw because those constructs are things that you look at them and you can say, “Hey, this is most definitely wrong. This is most definitely incorrect. This makes no sense so why are we accepting this and why are we generating hardware using this particular kind of thing?”
[00:12:28] Camille Morhardt: Animesh, question for you. Did you go down any dead ends and have to correct yourself?
[00:12:34] Animesh Chowdury: I don’t say that it was a dead end or something because since I was participating all alone and like Baleegh even was saying, that there were a lot of opportunities to find the bug in the hardware, so I kept on looking and looking and surprisingly within this 48 hours, there was not a moment where I felt like that I have run out of more bugs to explore. So I kept on exploring as much as I can, I would say.
[00:13:03] Camille Morhardt: Is that sort of the reality of the world, or do you feel like it’s staged?
[00:13:09] Animesh Chowdury: I would say there are two school of thoughts to that. From the organizer perspectives, what they actually want is to evaluate how people actually approach to this problem of finding vulnerabilities in the hardware. So they try to actually insert bugs in this hardware which actually resembles similar sort of actual vulnerability which exist in the hardware. So they try to emulate that and I think in somewhere or the other, they have tried to introduce more variants of the bug, which made the life of the participants simpler to certain extent. But I feel like as we go down the years of this competition, it’ll become much more challenging because they will try to reduce the hardness of the bug … not hardness, but increase the hardness of the bug to certain extent and it’ll make the life difficult for the participants, I would say.
[00:14:05] Camille Morhardt: I mean, my assumption is that all three of you may look for vulnerabilities separate from events. So I guess one question I have is just how similar do you find problems in the real world, without naming where you found them, we’ll protect the privacy and assume you’re disclosing separately, but how realistic is this kind of a competition versus if you were to just go dig into any kind of real world situation?
[00:14:37] Baleegh Ahmad: I can take a shot at that. So I think like Animesh said, some of these bugs are deliberately made easier, but I think they’re definitely developed from a academic’s point of view of bugs that were detected in these open source cores. So the core that we’ll use, the Arian core, in previous editions of Hack@DAC as well, participants were able to find bugs that weren’t deliberately introduced and they were of a similar nature. A bit gone, an incomplete assignment, a wrong password check, stuff like that. So I think it’s a bit of both. So for the purpose of competition, there are a few easy ones introduced, but they also to a certain extent do represent the kind of mistakes that can be made.
[00:15:20] Camille Morhardt: So my last question, I’m going to ask each one of you to answer this, your advice to architects or developers or coders as they’re securing their product. What is the one thing you would say, please, please, please, for the love of Pete, make sure you do this or make sure you don’t forget that.
[00:15:43] Baleegh Ahmad: I would say that the majority of the bugs we found were in assignments and in access controls. I’m sure people do this, but checking that again and again, that the access bits are appropriately set and the register log bits are appropriately set.
[00:15:58] Animesh Chowdury: From my side, I would say that … So there is an increasing interest in this formal verification kind of thing, which has been used a lot in the software verification, software testing part. So I would encourage all the hardware developer teams to use this formal verification tools time and again to ensure that the quality of code which they’re writing for designing a hardware is good enough.
[00:16:26] Camille Morhardt: Orlando?
[00:16:27] Orlando Arias: I am going to agree with Animesh here that formal verification tools are extremely powerful. They can detect many, many things that we will normally not be able to detect ourselves. However, I also want to say that formal verification tools are not 100% guaranteed. They usually will go ahead and try to prove a property that you have already defined, meaning that if that property is proven, well, congratulations, you managed to evaluate and give a formal proof of something that you actually wanted to prove. It doesn’t really guarantee any other property that you have not enumerated on the tool itself. So I believe we have to go beyond just formal verification to other types of analysis as well. Static checks, LinkedIn, anything that you can think of, go ahead and throw it at it. Even then things will go ahead and slip by.
[00:17:35] Camille Morhardt: Animesh, do you consider yourself a hacker?
[00:17:38] Animesh Chowdury: Not exactly kind of a hacker, but it is very super cool to identify bugs in someone else’s code. It’s always super interesting because you get bounty, you get awards, you get a lot of things. So our university students have been participating for last three, four years into this competition and our seniors have kind of motivated us that this is really super cool thing and you should try out, get your hands dirty and do a lot of things. So I would say that over the years, I think this is the first time a team from NYU has got the first position in Hack@DAC. I think it didn’t happen before, but yeah, at least we tried to get ourself into a top three position every year, like the year Hack@DAC started.
[00:18:24] Camille Morhardt: Very cool. Baleegh, are you going to do it again in the future?
[00:18:28] Baleegh Ahmad: Oh, that’s a tough one. Yeah. I can’t answer that right now.
[00:18:34] Camille Morhardt: Orlando, would you recommend it to other people?
[00:18:38] Orlando Arias: Oh, absolutely. If anything, just for the learning experience actually. It was a lot of fun participating and we learned a lot. Like I said, one of our objectives was to beat our tools, the tools that we had previously developed, to see how well they do against a scenario that we didn’t concoct ourselves. So even just for that, it was just a learning experience. We got to use other tools that we hadn’t used before either. Synopsis was kind enough to provide us a virtual machine for us to access and we had a whole bunch of their tools in there that we could use to do testing and perform analysis. So yes, absolutely, I will strongly encourage anybody interested to at the very least look into it and, of course, to participate.
[00:19:29] Camille Morhardt: So Orlando, Baleegh and Animesh, thank you guys very much for joining. Again, representatives of their teams, unless of course it’s Animesh, who was one man show for his team, of the winning teams of Hack@ Design Automation Conference, the hardware security capture the flag, and they talked a little bit about their winning strategies and what it was like participating. So thank you so much for joining us on What That Means.
[00:19:54] Baleegh Ahmad: Thank you very much
[00:19:55] Animesh Chowdury: Thank you.
[00:19:56] Orlando Arias: Yeah, you’re welcome.
