Solving Race Condition Vulnerabilities with Tanya Janca

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
Resources:
About the vulnerabilities discussed:
The Starbucks infinite credit race condition: https://www.schneier.com/blog/archives/2015/05/race_condition_.html (https://www.schneier.com/blog/archives/2015/05/race_condition_.html)
The Gitlab ‘merge any pull request’ race condition:
https://www.cvedetails.com/cve/CVE-2019-11546/ (https://www.cvedetails.com/cve/CVE-2019-11546/)
The Dirty Cow vulnerability: https://dirtycow.ninja/ (https://dirtycow.ninja/) with the research paper: http://www.iiisci.org/journal/CV$/sci/pdfs/SA025BU17.pdf (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 (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 (https://doc.rust-lang.org/nomicon/races.html#data-races-and-race-conditions)
GoLang race detector: https://blog.golang.org/race-detector (https://blog.golang.org/race-detector)
Testing race conditions on REST APIs: https://github.com/TheHackerDev/race-the-web (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/ (https://www.amazon.com/dp/1119687357/)
https://shehackspurple.ca/ (https://shehackspurple.ca)
https://twitter.com/shehackspurple (https://twitter.com/shehackspurple)
https://www.youtube.com/shehackspurple (https://www.youtube.com/shehackspurple)  
https://dev.to/shehackspurple (https://dev.to/shehackspurple)
https://medium.com/@shehackspurple (https://medium.com/@shehackspurple) 
https://www.youtube.com/shehackspurple (https://www.youtube.com/shehackspurple)  
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.twitch.tv%2Fshehackspurple&data=02%7C01%7CTanya.Janca%40microsoft.com%7C07d4df77a23e4530bbec08d606f82846%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636704060233537602&sdata=M1gR%2BErMWUyDGu0OxeFWXP1XcgsPEloCVKdraOmaLm4%3D&reserved=0 (https://www.twitch.tv/shehackspurple)
https://www.linkedin.com/in/tanya-janca (https://www.linkedin.com/in/tanya-janca)
https://github.com/shehackspurple/ (https://github.com/shehackspurple/)
https://www.slideshare.net/TanyaJanca/ (https://www.slideshare.net/TanyaJanca/)
Tanya mentioned she’s also a professional musician, you can find her...

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:

https://www.cvedetails.com/cve/CVE-2019-11546/

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/

https://shehackspurple.ca

https://twitter.com/shehackspurple

https://www.youtube.com/shehackspurple  

https://dev.to/shehackspurple

https://medium.com/@shehackspurple 

https://www.youtube.com/shehackspurple  

https://www.twitch.tv/shehackspurple

https://www.linkedin.com/in/tanya-janca

https://github.com/shehackspurple/

https://www.slideshare.net/TanyaJanca/

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:

https://wehackpurple.com

https://twitter.com/wehackpurple

https://www.youtube.com/wehackpurple  

https://linkedin.com/company/wehackpurple

https://newsletter.wehackpurple.com 

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

Transcript:

[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...