Episode 1

Solving Race Condition Vulnerabilities with Tanya Janca

Published on: 14th October, 2020

In our inaugural episode, we sit down with Tanya Janca, founder of WeHackPurple, to discuss her expertise in solving for Race Condition vulnerabilities during her career as both a software engineer and application security professional. We spend some time talking through the most common types of Race Conditions, review a few real-world hacks and vulnerabilities, and present actionable tips security and technology teams can make to solve this class of vulnerability. 

About our Guest:

Tanya Janca, also known as SheHacksPurple, is the author of ‘Alice and Bob Learn Application Security’. She is also the founder of We Hack Purple, an online learning academy, community and weekly podcast that revolves around teaching everyone to create secure software. Tanya has been coding and working in IT for over twenty years, won numerous awards, and has been everywhere from startups to public service to tech giants (Microsoft, Adobe, & Nokia). She has worn many hats; startup founder, pentester, CISO, AppSec Engineer, and software developer. She is an award-winning public speaker, active blogger & streamer and has delivered hundreds of talks and trainings on 6 continents. She values diversity, inclusion and kindness, which shines through in her countless initiatives.Founder: We Hack Purple (Academy, Community and Podcast), WoSEC International (Women of Security), OWASP DevSlop, OWASP Victoria, #CyberMentoringMonday


About the vulnerabilities discussed:

The Starbucks infinite credit race condition: https://www.schneier.com/blog/archives/2015/05/race_condition_.html

The Gitlab ‘merge any pull request’ race condition:


The Dirty Cow vulnerability: https://dirtycow.ninja/ with the research paper: http://www.iiisci.org/journal/CV$/sci/pdfs/SA025BU17.pdf

The Spurious DB race condition, impacting all major operating systems: https://www.triplefault.io/2018/05/spurious-db-exceptions-with-pop-ss.html

Tools discussed:

Safe Rust race condition guarantees: https://doc.rust-lang.org/nomicon/races.html#data-races-and-race-conditions

GoLang race detector: https://blog.golang.org/race-detector

Testing race conditions on REST APIs: https://github.com/TheHackerDev/race-the-web

Links for Tanya:

Tanya's book Alice and Bob Learn Application Security: https://www.amazon.com/dp/1119687357/











Tanya mentioned she’s also a professional musician, you can find her amazing rock band here! https://www.youtube.com/watch?v=zI6Mh2-E_CQ

Links for We Hack Purple:






Tanya also shared about https://www.clouddefense.ai/ their new company just going out of stealth.


[00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern Apps hosted by JB Aviat.

Jb: [00:00:14] Welcome to the first episode of AppSec Builders. I'm Jb Aviat, and today I'm proud to welcome Tanya Janca to discuss race conditions. Race conditions are a common class of vulnerabilities in APIs or applications with business logic, which are very well known. For instance, they aren't part of the OWASP top 10. Tanya Janca will tell us more about the application security book she just finished writing, and about her company that just came out of stealth mode.

Jb: [00:00:44] Our guest today is Tanya Janca, also known as SheHacksPurple. She's the founder of We Hack People, an online learning academy dedicated to teaching security, DevSecOps, and cloud security. Tanya is devoting a lot of her energy to democratizing security. [00:01:00] She also is the host of an amazing podcast where inclusion and diversity shine through. You have experience working at several software companies such as Microsoft, Adobe and Nokia, and have had varying rules across security and engineering throughout your career. As pentester, CISO, AppSec engineer and software developer. So Tanya, I think you wrote a book, recently. Would you like to tell us a bit about it?

Tanya: [00:01:27] Yes. So my book is called Alice and Bob Learn Application Security. Do you remember the characters of Alice and Bob when they first explained what encryption was?

Jb: [00:01:38] Of course, who doesn't?

Tanya: [00:01:41] Yeah, so and whenever I would give examples I would always say, you know, it's not Alice's fault or or Bob's fault.

Tanya: [00:01:48] It's that a safeguard was broken. And that's how this happened to Alice or there was a security header missing and that's how it happened to Bob. And so I would always weave them into things. And when I was trying to decide what to name [00:02:00] of my book, that was all about application security. Well, all my examples will be Alice and Bob. So maybe it should be called Alice and Bob Learn. And it's a text book written in casual language to try to make it really easy to understand. And it's basically the very beginning of AppSec, like how to do security requirements, how to design a secure web app, what is secure coding and what are all the things I need to do? What does that security header mean and why do I have to have it all the way up to, you know, all the different types of security testing, all the different types of tools or activities that exist, how to build an exact program?

Tanya: [00:02:38] Basically, I was like, I'm going to take my brain and put it into a book. With jokes.

Jb: [00:02:44] Who's the ideal reader of your book, that developers interested in security, AppSec engineers?

Tanya: [00:02:50] I would say definitely an AppSec engineer would want to read the book or any software developer. I would say that other areas of I.T. that want to [00:03:00] know about security should read most of it. So there's a bunch of chapters like "How to secure your own digital privacy" and things like that, and the ideas of what is secure design and what are all these security concepts and what do they mean and how do I apply them? And I would say at least half of the book, almost anyone in it, could easily read and understand. But then there is two chapters that are just like, here's a lot of code. I'm getting really nerdy and I can't help it.

Jb: [00:03:31] So you sent me to the table of contents of the book and I really enjoy reading it.

Jb: [00:03:37] So like, way, before I plan this podcast, I bought three versions of the book to share with the team. We have a team of thirty five engineers and so scaling security is something that is really on my mind. And so I'm super excited about receiving that book because I think that will be the perfect introduction to that. Knowing your background of software developer [00:04:00] for ten years, if I'm correct

Tanya: [00:04:02] 17 - I'm older than I look.

Tanya: [00:04:05] Yeah, I got I started coding like in the mid nineties and then got my first job in nineteen ninety seven and I was like, oh my God, I'm a professional.

Jb: [00:04:14] Congrats to you. But you've been a developer specifically for ten years, righ?

Tanya: [00:04:21] More than that.

Tanya: [00:04:22] Yeah. Like mostly I did software development for 17 years and then I've done security for six or seven years now.

Jb: [00:04:29] All right. OK. And so from my point of view, that's like the best way to get into AppSec because the people who are making your job basically are software developers. And so being a former software developer is just amazing to be able to understand them and just add this software. I believe.

Tanya: [00:04:47] I think that the best way to make application security engineers is just find the software developers that are super interested in security and then just feed that interest like, [00:05:00] oh, here's a book for you. Oh, I listen to this podcast. Oh, I'm going to go do this, do you want to come? Until eventually, you hire them to the security team.

Tanya: [00:05:11] My plan.

Jb: [00:05:14] Smart, smart.

Jb: [00:05:16] We will try that to internally maybe. And I've seen that one part of your book is on several different vulnerabilities. Is race conscious one of them?

Tanya: [00:05:27] Yes it is Jb.

Jb: [00:05:30] Unbelievable.

Jb: [00:05:33] So I'd like to introduce the race condition, the vulnerability with an analogy. And after we can definitely jump on one of your favorite examples on that Tanya. So let's assume that you have $50 remaining in your bank account, so you go to an ATM to empty your bank account - that you can only do once. But if you arrange with a friend to withdraw the money simultaneously from [00:06:00] two different ATMs will it work? So if it does, it means that you have successfully exploited the race conditions. Congrats. Race Conditions is a category of vulnerability that often does not come from using a specific library. It only comes from using shared resources and forgetting that those resources are shared. And shared resources are legion, in particular in Web programming, with databases, or caches, as opposed to, for instance, injection bugs. A source code can be 100 percent bug free when you look at it, but still present some race conditions. Race condition bugs require the software engineers to think of the code with one more dimension in mind. And this dimension is time. So if you're into security, you can think of it as an adversarial context. What's happening if a part of the code is executed in parallel, for instance, what happens if any shared resource changes [00:07:00] state at any point of this function execution. And this is what makes this class of bugs extremely hard to detect in most setups. And so Tanya you suggest race conditions as a subject for this episode. So I seem to have some particular history or examples that you like with this class of vulnerability, right?

Tanya: [00:07:22] Yes, in my first programming job, I had a race condition with my boss

Jb: [00:07:29] The human Race Condition!

Tanya: [00:07:32] Yeah, we would design these bill of materials, types of applications. And basically I figured out that if I didn't lock the resources that the things humans programming could come and steal the resources that I was trying to use. And so we made custom software for all these different manufacturing plants. So it wasn't beautiful, GUI stuff like in Web Applications. There was all that backend stuff where you just see [00:08:00] a terminal. And I remember saying, like, Bill, you stole my resource.And he said, oh, you have to put a lock on it. And then we had a discussion about race conditions and say, oh, that's interesting. I never knew that. Same with if someone goes and edits a file in a shared folder and then you try to open it, you know, Microsoft Word, for instance, it'll say no, that's in use, right. Because it's a race condition. And then, you know, we get as my career moved on, I got to use different types of code repositories to save my code.

Jb: [00:08:37] I had to work in bigger teams because I started at startups. And then I was like, well, what if we both want to edit this giant program? You can't just lock the whole program. So we had to learn about merging, which was also good. And so when I was writing the book, everyone kept asking, are you going to cover the OWASP top 10? And I was just like, it's such a tired list. Like everyone knows it and they're like [00:09:00] someone reading your book might not know it. You can't not cover the thing everyone knows. And so I decided I would do a whole chapter about all sorts of common mishaps. So common issues that you find. And so I included the OWASP top 10, but I didn't want to just be the top ten. So I covered all sorts of things that are issues that you as a pen tester might find and issues that you as a software developer might inadvertently create. And one is race conditions. And so the example I used in the book.

Tanya: [00:09:29] So I really like Starbucks. 

Jb: [00:09:35] So I do as well.

Jb: [00:09:36] Better customer for the best three month because our coffee machine was forbidden for health safety reasons.

Tanya: [00:09:44] So some of Starbucks for the last three months, I actually had a vendor ask me to advertise their event recently and they tried to bribe me with a Starbucks card and stuff like that. But [00:10:00] in the vulnerability, basically a security researcher, they realised, oh, well, if I load money onto one of the cards and then transfer the money to a bunch of different cards at the exact same time, I can put on five dollars to card number one. But card number two, three, four or five, six, I can put that five dollars onto all of them at the exact same time so that my five dollars and a twenty five dollars and he just kept doing this circle with the cards and then eventually he's like, OK, so I can reproduce this. Boom. I have a race condition. And so then he submitted a. And so you shared an article with me that Starbucks didn't have a responsible disclosure program, but the article that I quoted in the book was actually how he did it as part of their bug bounty program. So I'm not sure what happened, but they they did give him a reward. I have to say, like, that person's really honest because I really [00:11:00] like their mocha beverages.

[00:11:03] And so that's a great example of a real life application. And another example I found that is similar is GitLab. And this bug was publicly reported because GitLab is open source. So a user would be able to approve a merge request, multiple times, and so potentially reaching the approval counts required to merge it. So here we can simply guess that the code checks if the user is authorized to approve the request, then updates the approval and if several requests are executed at the same time, then several will complete the checks more or less at the same time and perform the updates concurrently leading to this check bypass, and to the pull request being authorized. So pretty common class of vulnerability. And as you mentioned, Tanya, pretty easy to slip into programs because I'm not sure that's something that you are really teached at school, or notextensively, and you need to experience that kind of bugs.

[00:11:59] I feel in school [00:12:00] or at most universities, they just don't really teach security thoroughly enough to ensure that they're making secure software. Like, I haven't seen a school that teaches race conditions. I mean, I haven't checked out all of the schools. I would love to be corrected, but there are some universities where I live and I have lots of their students come and they say, I wish they taught this in my school. I'm like, they can. I wrote a book, but like, I, I feel like race conditions and all the top 10 and all the other things that I know you're going to talk about from episode to episode on this awesome podcast, you're starting like, I wish that there was a way we could get the word out to all the software developers so that if they know it exists, then they know to try to watch out for it, right?

Jb: [00:12:45] Yes, I'm sure they would. But you have a lot of things you need to learn as a developer. And so security is one amongst many.

Jb: [00:12:54] And yes, I think if we wanted to perfectly trained software engineers, it would take [00:13:00] another two years to five years training. It would be much more. And there are so many things that you learn when you start actually working in a company that you never touched at school, that I don't think we could ever have a complete developer training just because the field is too broad. And so that's something we will touch after is how tools could help developers actually write bytecode without race conditions.

Tanya: [00:13:28] In that case, do you think maybe they should all just subscribe to our podcast? Do you think that could help?

Jb: [00:13:36] So maybe the that's a good introduction and maybe they should all read your book then. Yeah, that's a yes. Yes. When we'll be the first translation.

Tanya: [00:13:48] I don't know when the translations are going to start for the book. I guess it depends on how well it sells in English.

Jb: [00:13:54] I'm crossing fingers to have it in French someday.

Tanya: [00:13:57] I know I speak French, but my French isn't [00:14:00] beautiful. It's not my first language, so it's a bit chunky. So no one wants me translating the book into French because it'll sound like a dictionary threw up. But I'm actually translating my training courses that WeHackPurple into French. And I got yeah, I hired a friend like a teacher who gives talks like she's a famous person to teach in French. Her name's Nancy Kuraishi. And then I actually also have hired Vandana Verma to translate our courses into Hindi because I don't know, there's an amazing, huge technology industry in India and there's just they're amazing. Right. And so, of course, let's let's see if this works. So hiring awesome ladies who speak different languages and like this could only be good.

Jb: [00:14:46] Of course. Of course. And so we mentioned about two different race conditions. Bugs in like business could write. One is the custom Starbuck code, the other, was in GitLab, but [00:15:00] you have more. And so not only in custom code, there were a famous one called Dirty Cow, which is a race condition inside the Linux kernel. And so that was a pretty big deal when released in 2016 because it allowed a reliable and local privilege escalation on most Linux machines. So the issue was that the kernel didn't coherently check for the memory permissions prior to allowing writing, and so the exploit allowed any one of the Linux machine to get through it.

Tanya: [00:15:33] Yes, I remember you telling me how you named the meeting rooms after vulnerabilities.

Jb: [00:15:40] Yes. Good, memory Tanya.

Jb: [00:15:44] So all of our meeting rooms at screen that have the name of vulnerabilities, so I'm currently sitting in Vietnam, we also have a world leader, Spectre. I see you happy with the Venom. Do you like this one?

Tanya: [00:15:56] I love it. Do you have one called Heartbleed? [00:16:00] And then everyone goes there when they're sad.

Jb: [00:16:03] Yes. So I didn't. But we do have a box of tissue in that meeting room. So maybe, yes, there is a pattern here.

Tanya: [00:16:13] In 2016 I was in a band, so I've been a professional musician most of my life and our band was called the Zero Day Reapers and we had a song called Heartbleed and I was telling them we can't write a song called Dirty Cow because it just sounds it sounds to me it sounds like I'm calling another woman names and I just can't do it.

[00:16:35] I understand. And so I wanted to name a meeting room, Dirty Cow. But double thinking about that.

Jb: [00:16:41] If you if you send someone in for a meeting in Dirty Cow, the meaning is strange. And another vulnerability that I love, because I was working at a Apple before Sqreen, is the goto fail vulnerability. That was a vulnerability. So to fail. Exactly. [00:17:00] Yes. Let's have this a very important meeting about your career in goto fail.

Tanya: [00:17:08] Oh, my gosh. Could you imagine? People are like, no, can we just please can we please meet in the Dirty Cow room? Not goto fail

Jb: [00:17:15] Oh, yes. You have a scale of meeting room names quality. Absolutely. So we have none of them.

Jb: [00:17:22] But thankfully, more and more vulnerabilities are being released. So our next meeting rooms will still have awesome names, I'm sure. And so we can even find the things that are lower level than the Linux kernel. One of the Amazing Race conditions vulnerability's is called Spurious DB, or POP SS vulnerability. And so that's a race condition that originated from the CPUs. So in 2018 two researchers realized that all of the major operating system vendors misunderstood the Intel manual for 64 bits architectures. And in order to prevent privilege escalation or crashes, all the [00:18:00] major operating system, Windows, Linux, MacOS, Xen, pushed updates simultaneously to all of their operating system to prevent this kind of things. And so that was a race condition happening when the process was giving back control to the operating system. So pretty amazing to see that those race condition vulnerabilities have a super large spectrum from custom code to almost hardware issues.

Tanya: [00:18:27] Yes, if all of the vendors misunderstood the manual, maybe the manual was wrong to do it. I mean, if everyone reads it and interprets it the same wrong way, it's like, well, I remember them asking us to read the manual in school when we took Assembler, they're like, oh yeah, just read the notes, read the programming guide for the hours, you know? And I was just like, no, no, I'm never going to be a low level programmer. They made us switch to machine code and stuff. I'm like, it was awful.

Jb: [00:19:01] I [00:19:00] understand. And what a couple of friends and myself did during engineering school? We all ordered the Intel manual. And so they were sending you for free like five or six huge books of the Intel manual printed in paper. And it was like my only furniture as a student, basically, but it looked great in my in my students room.

Tanya: [00:19:24] Oh, my gosh.

Tanya: [00:19:26] I actually saw a talk, so one of the first conferences I went to was besides Ottawa and this guy gave a talk about a race condition at this place where he buys pants. And so he was wearing the pants. And these are my favorite pants there by this company. And then he showed us the race condition that you could do with a coupon. So he's like, yeah, you put it in and then you have multiple shopping carts and you just go on all of them at the same time. And he's like, so once a year they give you this 50 percent off coupon, but it's only good for one pair of pants. But I need more [00:20:00] than one pair of pants per year. And then he showed us how to do it.

Tanya: [00:20:03] And if he hadn't reported it to the manufacturer, it's just like you're showing us how to stand by. And people are like, it's a security conference. What did you expect? I was like, oh, my gosh, I'm so shocked.

[00:20:15] So writing software is hard. We see here that those race conditions, vulnerabilities are pretty easy to be put into software. So we had several examples. And so we knew that software engineers, they need all the help they can get from the machine. And so as most things in software engineering, the space is evolving quickly and there are a lot of tools and solutions to help software engineers with race conditions. So some solutions are pretty old, like the support of transactions in databases that would prevent like the Starbucks the GitLab one, the pants one... And this is supported in most libraries to interface with [00:21:00] databases, but many developers just don't know about it. And another point is you could have help at the language level to prevent race conditions so that say there are been huge improvements in modern languages such as Rust or Go, for instance. Are you aware of some tools or tactics to prevent or spot trace connections?

Tanya: [00:21:22] I feel like testing is really important. I know that there's a race condition, open source tool that I meant to look at the actually before because I thought about it earlier this morning and I meant to look it up. So Aaron Hnatiw, he actually open sourced a race condition testing tool, which I am definitely going to look up for you the name of so that you could share it in the show notes, please. Yes. And it basically just tries to do multiple connections at the same time to see if there's a walk or whatever the resources. That's perfect. I would say, though, that using modern frameworks and programming languages like reste like go is a good start. [00:22:00] But I think that testing and code review, I know that like people could review not that sexy code review catches lots of problems. They do like using as a tool to review, to see like, oh, it appears that you're not putting a lock on this transaction, of course.

Jb: [00:22:18] But to do that, you do need that the righter either the reviewer is aware of race conditions. Right, because the issue is still possible. And if, as we said, the software engineers are not aware of race conditions at some point of their career, then that's something you will miss. But obviously, you agree with the review.

Tanya: [00:22:36] You think I'm going to be a little biased here because my startup, WeHackPurple gives training, but I think training could help you. I see you trying to hold back the last.

Tanya: [00:22:49] But I just like to just talk about your company, Tanya, don't you know?

Jb: [00:22:55] But and that's actually something, because my thinking is that it's hard to train all [00:23:00] of the developers about security. Maybe we just need to train a subset of them. But if you think of software engineers at school, some of them will do Web programming, some of them will do embedded programming. Some of them will do something completely different. But one common trick here is the security. No matter what you do, you may have race conditions very likely. So you may not have XSS, if you don't work with HTML, you may not have SQL injections if you don't work with SQL databases, but injections vulnerabilities are everywhere. So, yes, there could be some varnish on that.

[00:23:35] I'm a big fan of security champions programs. Before I even knew that they existed, I accidentally started one because I had started an exact program and I was kind of learning on the fly. And basically I started giving software developers a copy of OWASP Zap because it's easy to use and it's free. And my budget was zero. And and before I knew it, I had on each team that one [00:24:00] person that was super into scanning that was super. Hey, I found this. Let's talk about it. And so I just kept encouraging them and sending them more stuff. I dragged them to OWASP with me. Right. And before I knew it, at a team of champions that would do all the awesome stuff. And so, you know, if you have a team that's doing embedded and you have a team that's doing well and another team the. Doing something else, if you could have that one person that's kind of got your back. The person that is security minded, that's obsessed with security and you can encourage that person, like that's the person where I'm like, I'm going to buy you a book about, you know, embedded systems and security, know how to secure them, etc.. Right. And then you said, oh, I saw this cool conference talk you might like, etc., and you kind of focus more on those people, even if you aren't allowed to start a formal security champions program, because quite often I'm not always given permission to do things immediately, so I just do [00:25:00] them quietly. And that's one option that you could do, right?

Jb: [00:25:05] It's yeah, it's the better way to prove that it works and then get allowance.

Tanya: [00:25:08] Yeah. Yeah, exactly. And then you also could get the time with them because you won't be allowed to have time with an entire team on a regular basis. They'll be like chavy. You can't have one hour with the embedded team every week. Maybe you could have one hour with one member of the embedded team every week. Right. And maybe if you're having coffee, it looks like you're on a break. You just have to buy the coffee. And you just happened to give them a book, right?

Jb: [00:25:37] Yes, absolutely. The security champion is a great technique. You have seen you walking in several different context. Yeah.

Tanya: [00:25:45] Oh, I've done security champions where it's a really formal program and we're like allowed to name them. I've advised clients where they said we started a security champions program and it's not going well. And I said, how did you find your champions? And they said, we just [00:26:00] chose people at random and told them that was their thing. And I'm like, oh, that sounds like a disaster. So you just chose people at random and tell them they have a lot of extra work that they're not getting paid for. Awesome. That they don't want to do that they're not interested in. Great. I'm surprised that that didn't work out extremely well. I'm like, what type of recognition are you giving them? And they're like, why would we give them recognition for doing their job? Like, OK, so let's have a different talk. Even if it's just free. Starbucks coffee is once a week when you meet them. Has that is a word for word, right?

Jb: [00:26:35] Yes. But those are companies that might have other management problems.

Tanya: [00:26:39] But that's another that's another podcast episodes you need.

Jb: [00:26:44] And so you mentioned testing actually is a good way to find risk conditions. So I didn't know about your friends tool, so I'm looking forward to know more about that. And there are two things that I have in mind is the Go race detector that is pretty old also from [00:27:00] September 2012. And so the Go team is saying that you found 42 race conditions. Is the Go standard library.

Tanya: [00:27:08] Wow, that's amazing. So, yes, absolutely amazing.

Jb: [00:27:12] Testing, very good option. And there is another one for C++ program that is called tsan on the clang compiler - thread sanitiser. And that will also work to find a lot of race conditions as clang as knowledge of all the intrinsics about looks and everything that the computer is placing. So that's that's a good place to find for race conditions.

Tanya: [00:27:34] Let's spell that, because clang is a weird word. It's not even a word. So it's C, L, A N G for C++ and clang has tsan. So that's T S A N Because when you're saying it, I was like, yeah, I don't know how to spell that. 

Jb: [00:27:56] OK, I was that, that [00:28:00] plus my French accent. Yes. So thanks a lot for spelling that, you know, the resources will be shared after that.

[00:28:09] Also I believe you mentioned safe Rust when we were talking earlier. Do you talk about safe Rust? Because Rust is awesome and I'm kind of excited about Rust because it's a memory safe language that's low level like C and C++.

[00:28:23] Yeah, Rust was born at Mozilla. And so Rust has a lot of guarantee out of the box to prevent data races and to enforce at compile time. So in safe Rust, it's like the default Rust mode. So if you don't leave it, you will have these guarantee applied to your code. And I notice that there is a university in Germany that is doing actually a like a formal investigation of the risk safety guarantee by PHDs. So we might have a lot evolutions on that side soon.

[00:28:55] I love that. I love that academia is helping. Good job. [00:29:00] Academia.

[00:29:01] Yes. So many things want out of there and especially that I can formula compilers and languages. And so on the hand there another thing that can help prevent a condition that is awareness. And so there is one thing that is the feeling of immunity, that some tools may provide.

Jb: [00:29:21] And so when misconceptions often heard about Node.js, so I love Node.js, that's not the question, people tend to say that in Node you cannot have race conditions because Node has only one thread. And so that's incorrect. That's the misconception. And so Node a lot of threads like you have one for the main loop, yes. You have four asynchronoss operations out of the box. If you spawn a simple Node script in macOS it will have 7 threads out of the box. And so that creates a lot of opportunities for things to mess up. And so even if you have only one thread, obviously Node Express or Koa , lots of other Web frameworks [00:30:00] you are using will serve several HTTP request concurrently. And so obviously the risks regarding race conditions are exactly the same than in any other language.

Tanya: [00:30:11] Yeah, I feel like people only talk about the OWASP top 10. So I was really glad when you said can we talk about a vulnerability? And I chose something that was not on the top 10 and you actually said, yes, like all these examples throughout this podcast, I feel first of all, I'm hoping that helps whoever is listening. But second of all, I feel like if we don't talk about these things and we only just talk about the top 10 over and over, software developers and even security people think, OK, so we've handled everything like and having these misconceptions that no, just has one thread all the time. And it's like, actually, that's not true.

Jb: [00:30:47] So I believe that some of the methodologies is the as you described in your book and that are pretty common about the more security mature actors across the industry are pretty common. So [00:31:00] could you share with us what kind of successful effect you have seen about security programs or things that could help erase people from putting such mistakes?

[00:31:10] So this is my favorite topics. I like how you've really teed up for me. So AppSec programs create a formal, secure development lifecycle.

[00:31:21] So that means having security requirements for every new app. That means when you have the design phase, doing a whiteboard with a security person and having them raise issues with you, doing a threat modeling session, following secure design concepts like applying least privilege or assume breach and all of these things while you're designing to make sure that it is secure. And then during the coding phase, having a secure coding guideline that possibly mentions race conditions like lock your transactions if you have a transaction, fail partway through, always fail close and reverse the transaction no [00:32:00] matter what. Also, you can do scanning during the code phase, you can do software composition analysis during the code phase. You can even do some testing, you can write unit tests and you can add security to some of the unit tests, which is awesome.

[00:32:15] And then while you are doing your testing phase, though, there's so much good testing, Jb, so much there's so many awesome tools on the market. I know that screen makes a tool and there are just like so many good types of testing you can do and you can do manual testing and that's awesome. But there's also just of course, you're going to use a tool. You're not going to do everything manually. We don't have time to do all the things we want to do. And so things you could do, like you could have a bug bounty program and you could put race conditions in scope, like specifically suggest that they should look for it. But for just want to look for it yourself. Right. You could hire a pen tester to do a security assessment or penetration test and just like beat the living tar out of your [00:33:00] app. I'm a big fan of that. You could have red team exercises. You could definitely talk about it during your. So I like to call it whiteboarding. I just I like to go and meet with all the different teams and say, could you just tell me about your design? And I'm just going to draw it on the board and then I just threat model and ask interesting questions like if you were going to hack your app, how would you do it? Because it's my gosh, they have the most evil answers.

Jb: [00:33:28] That's actually the most interesting way to do that, and I think that's also a smart way to look for it, because if you manage to brainstorm the system design with the team who built it, that knows who exactly what does, how does it, it's actually the best time to really get all the security insights you might have and ask the questions and ask very, very candid questions, which sometimes the team is not able to answer because you need like a twisted security mindset sometimes to think about some stuff, right?

Tanya: [00:34:00] I [00:34:00] feel that every software developer is a hacker, what we would call an exploit they call a workaround. Because when I was a software developer, I would hack things all the time, but I didn't understand that I was exploiting a vulnerability.

Tanya: [00:34:17] So I think you teased me when we were preparing this with something you've been working on for a while, right?

Tanya: [00:34:25] Yes. Oh, yes. I forgot we were going to talk about this because I've been under NDA super secret hush hush since December. So since the beginning of January, I have been working with a startup called CloudDefense.ai That I can finally say it and tell people. Yes. So I'm their technical advisor and I've been helping them with a bunch of stuff. And basically they have made this super cool. I don't know what to call it because you know how there's DAST and SAST, there's all these categories, but they're tools, an amalgamation tool. So basically it does secret [00:35:00] scanning, SAST, DAST, licensing, SCA. We have just all these different things that it does all simultaneously and it can actually do it for multiple apps all at the same time. And then it takes all the information and puts it into the same dashboard so that you can do vulnerability management. So I'm obsessed with metrics and numbers and I'm obsessed with being able to get the results from all the different tools and look at it.

[00:35:27] It's like, what if we made a product that did it? And so we are just starting to take on customers now. And so I'm ridiculously excited that we are finally out of stealth, like literally just like two days ago.

Tanya: [00:35:43] You can tell people because I would tell people like, do you want to meet my super secret self thing? And you had to sign an NDA and all of this. But every time I would send them, we would be super overwhelmed because there are so many things like because of your customers, you know, I would send them like twenty leads. And [00:36:00] they're just like I we don't have enough people, but we have bulked up and scaled and we feel that we are ready to talk to the public.

Tanya: [00:36:07] And it's so exciting.

Tanya: [00:36:08] Oh my gosh.

Jb: [00:36:10] CloudDefense.ai.

[00:36:12] Yes, yes. That is us. It's so exciting. It's so exciting to be on the board with these amazing humans. It's so exciting to work with people that are just as nerdy as I am having meetings and being like, have you tried this? What about that, Vogeler? And we're opening it up to so that we can plug in third party tools. So all the super popular tools, you're going to be able to plug them in. So if you already own screen, we don't currently have a plug in for that. But obviously the first customer that is a customer of screen that wants to plug it in. Oh, yeah. We're just going to build these little Amazon so that you can see all the results for all your tools and you can call it from this one place. And it just oh my gosh, it's so exciting because a problem that I have always had as an engineer is OK. So I have [00:37:00] four hundred folders with like six hundred reports and then I'm trying to copy and paste from all these different formats like I used to use at this one place. We used app scan and burps. We and then I was trying to copy and paste from the different reports into the same thing. And I was like, I just wish I had a CV file and then I could just use my Excel Fu on it. And I'm trying to explain the management like, listen, this one team's having serious problems, but it was so hard to spot the trends. And then I would use like something like Thread Fix or Defect Dojo. And I put all the stuff in there and I'm like, OK, this is so much better. But now imagining they could just automatically like the one tool calls everything and then amalgamates all the information, I'm just like, oh my God.

Jb: [00:37:42] So good, so good. Yes. I understand completely your feelings and your execution. And that's the. Yeah. Because when you are doing your security for a while and one thing that is frustrating is that in the end it's all humans doing the walk in the skating union is pretty hard.

[00:38:00] So [00:38:00] when you manage to find with a tool that will help you actually solve a whole category of problem and that you can actually really do that and get that used by customers. Yes, the expedition is amazing. And it was my feeling when launching a screen, like seeing that we actually started to solve things of customers at scale. It's an amazingly well so thing.

[00:38:24] So that's done you for everything you you shared with us to.

[00:38:28] All your experience, I really enjoyed having you abroad and really looking forward to reading your book soon and sharing it with my teams, and I'm super excited for that. Thanks a lot for coming with us and build us today, Tanya.

[00:38:44] Thank you so much for having me.

[00:38:47] Thanks for listening to this episode of Abscessed Builders. You can find all the resources discussed during the show on our website, Builders Dotcom's. Be sure to subscribe to our podcast to get updates on our upcoming episodes. [00:39:00]


Next Episode All Episodes
Show artwork for AppSec Builders

About the Podcast

AppSec Builders
The podcast for practitioners building modern AppSec.
AppSec Builders features practical and actionable conversations with application security experts and practitioners. Topics range from understanding and solving classes of vulnerability, building protections to efficiently scale with your business, and core best practices to strengthen your security posture. AppSec Builders is hosted by Jb Aviat, AppSec staff engineer at Datadog, former CTO and co-founder at Sqreen and Apple Red Team member.

Contact us at appsecbuilders@datadoghq.com

About your host

Profile picture for Jean-Baptiste Aviat

Jean-Baptiste Aviat

Jean-Baptiste Aviat is AppSec staff engineer at Datadog, former CTO and co-founder at Sqreen. He spent half a decade hunting security bugs at Apple, helping developers fix them, and developing protections used by millions of devices.

Prior to Apple, Jb was a full-stack, white-hat hacker for a consulting company, developing numerous security tools in whatever language he needed to hack into.