He Won George Hotz's Money - Andrey Petrov
Download MP3You up for one more?
Kevin:Yeah. Absolutely.
Andrey:Alright. So the last one features George Hotz, which some people might remember from hacking the original PlayStation 3 and the iPhone.
Kevin:I remember him from, like, telling Elon he would solve all of Twitter's problems in a week.
Andrey:He tried.
Andrey:The one thing most people might not know is he's also been on and off involved in some Ethereum stuff. One of the interesting attributes of Ethereum is this this collectively owned computer, essentially. We have these guarantees where all the code executed on it will be 100% right because every node verifies it. For some values of right. One of the kind of the constraints in order to maintain these these decentralization properties and for everyone to be able to run a node at home on their laptop, there's a very there's a fairly small limit on how much throughput it can handle.
Andrey:People often make fun of it for having something like, like, like, like, 10 transactions per second. But turns out we can solve it by this this innovation called roll ups. And essentially, we can run the transaction somewhere else, and we basically commit to a batch of transactions on on Ethereum, and we can prove that they they executed accurately. So back when these roll ups were first kind of designed slash discovered, the theory of it was fairly well established. But the wave but implementation was still kind of a long road ahead.
Andrey:The people working on these roll ups, they're hanging out in, like, a San Francisco cafe, and they're just, like, bashing their heads. Like, how are we gonna build this? The churn, and and George Hotz is there next to them. They know he's really smart, so they just, like, start, like, brainstorming with them, and and he gets nerd sniped. And they basically convince him to build a proof of concept of a roll up, in exchange for a very generous amount of money.
Andrey:But the term that they came up with is that they're gonna do an initial bug bounty and a, like, $50,000 bug bounty, but the money is gonna come out of his compensation if there's bugs. Long story short, we got $50,000. Howdy, folks.
Kevin:We are back once again on the War Stories podcast on Critical Point. Today I am here with a friend of a friend, who I met through Twitter, Andrey Petrov, chat about that time he broke production. That's what we do here or several specific varieties production. I think we have a few stories here maybe to chat through. So very little preamble today.
Kevin:As always, we are available at more stories. Criticpoint. Tv on all your podcast apps if you are watching this on video and on YouTube at criticpoint. Tv if you would like the video. But I'm excited to get stuck in and don't have too much more to say than that.
Kevin:So we will roll the titles and get started. And we're back. Once again, this is the War Stories podcast on Critical Point. I'm Kevin Riggle, and I'm here with Andre Petrov. Andre, can you tell us a little bit about yourself and how you found yourself in
Andrey:a place where you might break production? Hi, I am an independent open source developer. I've been largely building open source things, since 2007 or so. One of my most known things is UroLift 3. It's an HTTP library in Python that's used by a lot of people.
Kevin:That lies under like the requests library, which
Andrey:is
Kevin:used by everybody, which is now baked into the Python standard library, if
Andrey:I recall. Not super much. Okay. But like PIP uses your libs 3 as well. So basically, anytime you've done any kind of Python stuff, you've probably run some of my code.
Kevin:I think, like, yeah, every time I see a Python exception, half the time it's got URL lib3 in there somewhere. So yes. Yeah.
Andrey:Yes. Although there's a bunch of other people working on it and like maintaining it these days. So I kind of more do meta maintaining.
Kevin:Okay. Okay. Community management kind of things or
Andrey:Something like that. Yeah. Okay.
Kevin:Yeah. What got you into doing that?
Andrey:My first job, they've so basically, we were uploading a lot of images to S3. At the time, we were actually one of the largest, S3 customers. This is 2,008 maybe. It turned out the state of HTTP libraries at the time was not great. Every request was like a separate socket, separate everything.
Kevin:Yeah. It was dire. I remember this. It was bad.
Andrey:Yeah. I estimated how long it would take us to upload all the images we had, and it was like 3 months or something. They're like, I can write a new HP library in less than 3 months. So while that's going, I basically wrote what later became a year loop 3, largely support for multithreading, support for using sockets, a whole bunch of stuff like that. And then we got that down to, I think, like, like 3 or 4 days.
Andrey:And they very generously let me open source it under my own name and kind of one thing led to another from there.
Kevin:And so but that is not that's that comes sort of after the story that we're talking about, like, yes. Because the story if I recall from our conversation starts in high school.
Andrey:Yeah, so originally, so I started coding in my early teens, and my high school had this really I went to this, like, big public high school, And they had this half assed computer programming class that was organized by our gym teacher who has never written any kind of code. Oh, goodness. Okay. Sure. Why not?
Andrey:Great. Yeah. But, yeah, they they kind of handed us a book, which I think was we did some Turing. And I think at some point, c I I I chose to learn c. And that was going on.
Andrey:And I was also at the time was working my personal website, which I ended up using PHP for. And I was kind of doing some work for our high school. High school needed a bit. We didn't have any kind of software and their their rooms were constantly their like booking system was kind of this just like a piece of paper on the wall and people were constantly running into each other. So I built them this kind of booking suite and that they really liked.
Kevin:So I'm getting, the sense that you're like maybe about my age and you're doing this maybe in the early aughts. I'm yeah.
Andrey:Yeah. This is, like, started around 99 and kind of the incident happened around 2,000. Okay. And and very important context, this is the age where people are using modems. So this is like 36 k modems, maybe sorry, 33 point 6 k modems, maybe 56 k modems are just have just been released.
Kevin:Okay. Yeah. Yeah. Yeah. So we're we're at this moment where the internet is taking off in a big way.
Kevin:A lot of people are coming onto the internet for the first time. Like I've been on the internet for, you know, since the mid 90s at that point, you know, with dial up account. And so, but yeah, a lot of people were coming on for the first time.
Andrey:Yeah. I would say we're probably a couple of years behind you there, like, at least back then. So this is like almost everyone is on, like, a 33.6 k modem. Just like a few people got a 56 k just now. So, basically, I'm kind of unofficially just just kind of building software for my high school.
Andrey:I think at one point, they, like, paid me $200 or something. Kind of just like you gave me some cash.
Kevin:Kind of an honorarium. Yeah. You're probably like 15, 16. They maybe can't even officially employ
Andrey:you. Yeah. Like Yeah. And then one day they approached me, it's like, Oh, we want to send a newsletter to all of our alumni. They have this basically the CSV of around 1,000 email addresses, and they wanna start sending these monthly newsletters.
Andrey:And they don't like newsletter software doesn't exist back then. So so, like, how do we do that? Can you, like, write us a thing to do it? So I go to my PHP and I start that's mainly the reason I wrote it in PHP is because I knew how to run it and deploy it. And it had kind of the, like, SunMail API built into it somehow.
Andrey:So I'm writing my PHP. I got my loop. I go over every email address. I send the email. I run it locally.
Andrey:It's slow, but it works great because it's it's a modem. That was okay. And then I I bring it to him, oh, wait. We wanna also attach a PDF to it. And it's like a 1 and a half meg
Kevin:Oh. PDF. Okay. Yes.
Andrey:It's really big. And I I don't know. I might have mentioned something at the time. Like, oh, that's really huge. It's like, yeah, whatever.
Andrey:It doesn't matter. So I tried running it locally, and I'm on like a 36 k moto. And it's really slow because uploading 1 and a half meg, 1,000 times, it's gonna take me a week. So I had this brilliant idea. Instead of sending a bunch of 2 emails separately, I'm just gonna BCC everyone
Kevin:Right.
Andrey:With one email. So that way, I only have to put it once and Right.
Kevin:And let them the mail server figure it out. Yes. Yeah. Yes. Exactly.
Kevin:Yes.
Andrey:So I have this very vivid memory. I have my loop, and then aside, I'm gonna write I'm gonna keep that loop for now. I'm gonna write another loop underneath it to kind of accumulate the BCC string. So I'm looping over all the email addresses, I'm building up a big string to put in the BCC. And I don't know if you can guess what I
Kevin:have to guess as to where this is going. Yes, yes, yes.
Andrey:Yeah. So I wrote this. I tested it with like one email, worked great. I get my the gym teacher had this server that they rented. He gave me the login and password and their mail server and everything.
Andrey:I log in, it's really fast. I think it was like running on like a t 3 or something.
Kevin:Okay. Like, I've never I've never touched
Andrey:a server this fast, so I was really excited. Oh, that's the
Kevin:power, yes. Yeah.
Andrey:So I upload my PHP in there, I upload my inputs, I go to the PHP endpoint, which is how I would run PHP back then. I just open it my browser and then just kinda like let it spin. It's, like, taking a while. It's taking a while. I'm like, oh, it's taking a while.
Andrey:I would think it'll be really fast. It's like it's like a t 3, so it should be really fast. And it's sitting there, and then I'm kind of like as it's going, I'm kind of replaying all my lines of code in my head Right. That it should be running. Right.
Andrey:And then I had this realization. I never took out the outside loop. Right. Yes. So basically what happened is I sent a a 1 and a half meg PDF 1000 times.
Andrey:I I know 30 3 k modem Oh, no. In their inbox. So they they got over a gig of email blocking their inbox. 1,000 people, it was just basically everyone ever went to the school.
Kevin:And this is in the era where people's inboxes were generally limited to like 10 megs.
Andrey:Well, there's that, but also there wasn't any kind of server side mitigations, like the idea of like a what actually did is did this denial of service attack, basically. And maybe I was the one that encouraged him to build some mitigations for that, maybe not, but there weren't any at
Kevin:the time. So You were certainly part of the wave of, like, adversarial behavior, even though here the adversary was as much Murphy as anybody, to, yes, encourage the formation of those, yes, controls.
Andrey:Yeah. So basically, for the next 2 weeks, our school just getting nonstop calls from everyone that ever went to that school. It's like, I can't get my email. I can't get my email. People are, like, leaving their computers on for days at a time trying to download everything.
Andrey:I got right down to the principal's office. I had to give a like formal apology, whatever that means. Yeah.
Kevin:Were there besides sort of, like, making you call you on the carpet and making you sort of promise to never do it again? Were there any other, like, repercussions or
Andrey:how they handled it? The way I remember it is I I they wanted to keep using it after I fixed it. So they I built them a little UI and I think they they kept using for some number of years afterwards. I think they paid me around $80
Kevin:for that one.
Andrey:Okay. Great.
Kevin:Great. Yes. Maybe they
Andrey:got what they paid for. I don't know.
Kevin:Yeah, I mean, we always do. Yes, we have the best humans available.
Andrey:I did the math on this would have taken them 3 day, 3 and a half nonstop days to download everything in their inbox in order to get access to their later emails.
Kevin:Okay. Okay. Or could they call up the ISP and be like, hey, I please delete everything in my inbox? I I don't know.
Andrey:I mean, I'm sure some have tried. I can only imagine what the level of confidence was back then.
Kevin:Yeah. Yeah. Like, you have to get through I mean, I don't know, we were on a little rural phone company. So like, the odds of actually getting through to somebody with privileges on the email server were actually fairly high. Fair.
Andrey:Yeah, we're like in a little city with kind of a national telecom. Most people using Yeah, so I don't know. I think it's possible. But I think most people just left their devices on for the half a week and let it plow through.
Kevin:Oh, my God. Okay. Well, this is like we had a gigs worth of hard drive space, but we had a gigs worth of hard drive space. So like, that's, yeah, quite a substantial amount of stuff to download and then delete. Goodness.
Kevin:And this was also in an era where I don't know about you, but on my dial up line. Well, okay, so first of all, we were lucky to have the dial up line before we got DSL on a separate line. Because otherwise, it would just tie up the main phone line. And right, you know, that was a main point of contact for everything. You know, my dad's pastor.
Kevin:So that was how his, you know, congregation. Yeah, that was how it was livelihood. Like, you know, for the longest time when I was young, I could only be on the internet 30 minutes because that was the only the longest my parents were willing to have the phone line tied up for dad's work stuff. But once even once we got the 2nd line, it was still the case that it would kick you off after 12 hours, which I remember because I was trying to download my first ever set of Linux ISOs. Yeah, like Red Hat 7 or something.
Kevin:And was like, Oh, I you know, it's free. We can technically speaking download it. But yeah, it was going to take several days. And after 12 hours we got kicked off of
Andrey:like, and also back then. Resuming was very unreliable too. Extremely unreliable. Yeah. Yeah.
Andrey:Yeah. I remember downloading the Diablo 1 demo. It was like 54 megabytes.
Kevin:Okay. Yeah.
Andrey:Which was like 16 hours of downloading or something like that. Right. Yeah. Yeah. And my computer would blue screen right before I finished.
Andrey:Oh. But but that was kind of the the impetus to get me to, like, I rage quit Windows so hard when that happened. Yeah. That it actually like I got to reinstalling operating systems and like formatting things and like, I got to the next level and then eventually using Linux and all that. So yeah, same.
Andrey:Guess what's a good thing in the end?
Kevin:End. Yeah, same. My first Linux came out of a CD at the back of one of those books. I think it was called Dara Open Linux and it was like learn Linux in 30 days or something, you know? Yeah, that was that was wild.
Kevin:So cool. Yeah. Okay. So very much that that early scrappy era of the internet when everybody is still figuring it out. Like nobody's quite sure yet if it's gonna be a big deal or not.
Andrey:Yeah, I mean, in retrospect, like I was, I was kind of writing down notes earlier and kind of reflecting that experience. And on the one hand, you can say it was irresponsible of the gym teacher to enlist me this way. But in any hand, that was really useful, very hands on experience. Oh, absolutely. I feel like has had very substantial impact on me moving forward.
Andrey:So I really wish more more students would have that kind of opportunity to kind of make these these kinds of mistakes?
Kevin:Yeah, for sure. Yeah, I was very, I don't know, I was very desperate in that era for any kind of real thing to do. With my computer programming experience my, you know, computer interest, and I really struggled to find people who were willing to let me, you know, make those mistakes. Yeah, yeah, I remember a
Andrey:lot of our kind of computer class assignments were just glorified it. Interview questions, basically. Like, yeah, all like little, little, little programming puzzles, like, yeah,
Kevin:we did some computer competition, programming competition stuff, which were all structured as like, take this as input, do a little algorithm on it, you know, produce this output. And it was fine.
Andrey:But you don't learn to like, to actually comment out your extra for loop before writing the other loop. Until you actually do something in production.
Kevin:Yeah, exactly. Yeah. Well, and if you hadn't done that somebody else would have and did probably probably fix several, you know, rounds of that before the administrator is implemented, whatever, you know, send mail, you know, limits were available and whatever, you know, mail server, they were running whatever post fix limits were available on the receiving end and like started to think harder about that because yes, spam was only just kicking off and spam filtering was not yet a substantial thing we were starting to I was starting to play around with like, spam assassin, or whatever the built stuff that was built into like the Linux email clients was in that era, or just a little bit past that era. So yeah. So what happened?
Kevin:Where did you go after that after after drawing the attention of the entire alumni community of your high school and I mean, positive way?
Andrey:Yeah. Ultimately, it was kind of a non event. I don't I don't think anyone kind of remembers it except me. Yeah. Yeah.
Andrey:And then I went off to university, studied science, the Europe 3 stuff, moved to Silicon Valley to do my start a pilgrimage that I'm obligated to do. That one does.
Kevin:Yes. Yes. Excellent.
Andrey:Yeah. So so around then, I was working on these social analytics applications. So the next story, this this one's not really my fault, but but but also kind of a war story. So I built this Twitter analytics tool called Sweepsect. And basically, what it did is I loaded your graph and it did a set intersection.
Andrey:So everyone that you're, like, following, everyone's following you. You do the intersection, it give you your mutual followers, who's following you only, who you're following only. And then I refer to them as stalkers and stalking.
Kevin:Okay.
Andrey:Which is kind of Right. Got people excited. Yeah. And one cool thing about the way that app was built is it was pure client side JavaScript. Okay.
Andrey:So there was a small server side, shim to do the OAuth handoff. But after that, it was entirely run-in browser, which is really cool because we basically have infinite scaling without any kind of cost. It was like literally just like a static website otherwise. And, so this is like back when Twitter had an open API that everyone could use. Right.
Andrey:Yes. Yes. Anyways and then the other thing that's kinda relevant is I also have built another social analytics I was building like this, like, social analytics data called Social Grapple, and I was going through these these acquisition talks. And, one of the talks was actually was was Twitter. So I had just met their director of platform, just a few weeks earlier.
Andrey:So I built this specific thing kind of the year before, and then and then a year later, this is happening. So I I met their direct platform. We talked about acquisition stuff. It kind of didn't super work out. And if fast forward a few weeks later, I use Google Analytics to track who's using my stuff, so I could see kind of like a a real time thing of people searching, and I would get maybe a few dozen people a day, maybe a few 1,000 or 1,000 people a month using this thing.
Andrey:And then one day, I open up Google Analytics, and I see all of a sudden there's like a thousands of people there at the same time. Okay. I'm like, what? What's happening? What is happening?
Andrey:Yeah. And I assume it's it's a bug in my analytics. So I go on the app, check that, everything looks fine. I search on Twitter, people mentioning it, and it's being mentioned. And then every so often, I see a mention with my app's name but with a different link.
Andrey:It had a different link to it. And I opened it incognito and it checked, and it's like exactly my app. It even had my, like, analytics code in it and and everything, but it's under the URL.
Kevin:Yeah.
Andrey:Interesting. Okay. Yeah. Yep. And when you click log log in, it goes to, like, this, like, Twitter login form, but it's not on twitter.com.
Andrey:It's on the itwitterrerdrew.com or something like that. Okay. Yeah. Yeah. They kinda bought another domain that looks similar.
Kevin:Right. Classic.
Andrey:Yeah. So what happened was they basically they were stole my app and they built this, like, phishing website where they would harvest people's logins, and then they would they would redirect back to my app. So I would still get all the traffic, which I really which I appreciate.
Kevin:Okay. Great. Yes. Glad that worked out. Yeah.
Kevin:It doesn't always.
Andrey:But then once they stole the logins, they would go through everyone who's following you, and they would DM everyone that link. So it spread virally. Everyone would get a DM saying, oh, check this out. I just I I looked up who's, like, stalking me. You you should try it.
Andrey:Or something along those lines. There's Yeah. Somebody was running
Kevin:a viral marketing campaign for you. Exactly.
Andrey:But they're also stealing everyone's logins faster. It's kind of weird because that is basically live dashboard of every account that that's being stolen Oh, sure. In real time. So just like the numbers just like just like going up like crazy. So I mentioned the, like, Twitter support team and stuff and, like, hey.
Andrey:Can you help? Can you do something about this? No one answered. But luckily, I just met the director there, and I emailed them. And then even though it was like it was like 11 PM at night, he, like, responded a few minutes later, and allegedly they were on it.
Andrey:Okay. Yeah. But the interesting thing is that it kept going for kind of about a month after that. Like, oh, look oh, look at my analytics, and it like dropped for a few hours. Okay.
Andrey:Yeah. I'm assuming they're kind of playing some weird kind of some cat mouse game Maybe. Yeah. With their, like, auth with their authentication flow to kind of block try to block them.
Kevin:Okay. And then and then
Andrey:it would go back up like Yeah. Like a day later because they would just change their method.
Kevin:Okay.
Andrey:Interesting. And the other funny thing about that one was that they were live they they had a live proxy of my website. So I could make changes on mine, it would be reflected on theirs. So I put up a big fat warning Okay. And it showed up on theirs as well.
Andrey:But unfortunately, that also prompted them to eventually stop doing that method and they just kind of Yeah. Right. They just stole it wholesale. Okay. And, yeah, it's kind of interesting.
Andrey:I mean, based on my analytics, some like hundreds of thousands of accounts were harvested, and even made it into mainstream news at some point. If you search for Stocktrack, it was, like, mentions on it because they, like, kept it doing stuff with it. They kept trying to, like, harvest more and more just in more ways. And I think up to, like, 2015, there was some mention of it to say, like, this is a scam. Don't log in with this app and stuff like that.
Andrey:So, yeah, that that was really wild. But, yeah, ever since after that, my my I went from having around a 1000 visitors a month to having about a 100000 visitors a month and it kind of like stayed that way for what they say year or 2. And then I put some ads on there and made a few $100. Yeah, yeah, for sure. Yeah.
Kevin:I wonder, did you ever figure out who was behind it or have any guesses as to what the attribution was?
Andrey:I mean, given that they kept going with it and kept kind of, it just kept, like, building other scams. It feels like some kind of team somewhere that's just that's been doing this for a while and that they're they're gonna keep doing it. So, no, I don't know who's behind it. But it it feels like one of those things that just kind of there's an adversarial group out there, and then there always will be and they just happen to launch with with my app. With your app.
Andrey:Yeah.
Kevin:Yeah. The sort of carrot. Yeah. That's interesting. You know, seed.
Kevin:Yeah. Yeah, exactly. You hear about all these influence operations and, and this is a little bit of a, you know, window into how they work. You know, it's very convenient of them, if there's already something in the environment, which they can appear to be like, you know, already something legitimate, which they can, yeah, copy like this and leverage because that means, you know, people are coming into this from a place of like, oh, yes, this, you know, looks legitimate. This looks like it's, you know, done by somebody rather than Yeah.
Kevin:Even if it doesn't look super legit, it's just like it's it's an interesting use case that
Andrey:you can kinda use as a distraction. Yeah. I think for sure.
Kevin:Was there ever any sense of what, they were doing with the accounts? Like, were they using them to send other kinds of spam? Or That's a good question.
Andrey:Yeah, it's a good question. This was back before the day of password managers. So I'm assuming they were also reusing the logins on other websites. Oh, for sure. That will be my guess.
Andrey:Okay. The the other thing that's interesting is, like, there's basically no mention on this. Like, probably half a 1000000 accounts got harvested, and it wasn't really in the news or anything. And, like, Twitter didn't make an announcement. I mean, it's not technically their sole responsibility, but also, like, it's a substantial number, especially for Yeah.
Andrey:This was 2011. Yeah.
Kevin:So Okay. Yeah. Yeah.
Andrey:When it wasn't that huge? We hadn't
Kevin:Yeah, we hadn't yet quite figured out how big a problem account takeovers were going to become and quite exactly what that was gonna look like at that era. But yeah.
Andrey:But I think it's still happening on other services in some way, shape, or form. And we just kinda never hear about it. So it's it's kind of interesting to be in the eye of the storm almost just like having a real time analytics dashboard. Like, how what are the odds Right?
Kevin:Yeah, I'm getting that right? Yeah, yeah. Yeah, that's actually a very interesting data set. I don't know if you still have access to that. But it seems that something that could be interesting for one of these.
Kevin:Yeah. Account security researchers to take a look at and maybe do some Yeah, work on so if anybody listening to this or in the comments wants to get in touch with Andre, the contact info is available there. Yeah, hit me up. Yeah, we'll be in the description and in the show notes. That's also I don't know the on the Twitter side, I feel like the managing the OAuth security, like managing your OAuth endpoint, being able to blacklist apps, which are misusing it is something that we didn't really understand was important until relatively recently.
Kevin:There was I think, a Google thing, which went around in like 2017, actually, when I was at Stripe. And we were very lucky because the lady who ran our internal phishing tests had also run an internal attack testing whether she could get people to approve a malicious OAuth app, which worked great. And so was what the way she ran this is her name's Carla. She's got a talk up on that she did a blackout a few years ago, called fishing or called ichthyology, fishing is a science, which is brilliant, and I will link in the description and notes. But she always uses the internal phishing tests, which we were required to do by some one of our compliance regimes not to like, you know, go shame people for clicking links, or whatever, but to drive internal change in the business.
Kevin:And so Carla got us to set up single sign on. Carla got us to block to set up a allow list for OAuth apps on our Google Workspace rather than doing a blog list. Carla is, I forget what the third thing was. But Carla is also the reason that AWS supports, YUPE keys now. That's the
Andrey:key because I feel like auth namespacing would not matter because they're just harvesting usernames logins, but having multi factor auth would
Kevin:have helped for sure. Okay. They're interesting. On the part of Twitter?
Andrey:Yeah. Just in the example that that I was using. Yeah. Just being able to log on username put your username and password and just be able to DM everyone with a link. Like, no amount of OAuth would have helped.
Kevin:Okay. Yeah. Yeah. Yeah. I guess was it actually OAuth that they were using, or were they actually popping up a, like, a fake Twitter login form
Andrey:of Yeah. Or they actually duplicated the actual login form, and they were just harvesting straight up, and then they were just logging in. Yeah.
Kevin:So yeah, then there. Yeah. 2 factor, especially of the like, Yubikey kind, where not everybody recognizes this, but it's actually checking the URL that you are sending your credentials to for you because it turns out that humans are really bad at bitwisestring comparison at catching that itwitter.com rather than twitter.com, whereas computers are really good at bitwisestring comparison. And so we should make our computers do bitwise doing comparison for us and Yupi keys do. Or all the other little E2F tokens.
Kevin:And so yeah, that is
Andrey:the kind of thing that
Kevin:would have helped there a lot. I think that that attack
Andrey:is still possible with, like a Yeah.
Kevin:Phone based 2FA. I I mean, at the end of
Andrey:the day, also Twitter should have been noticing that the same IP address is probably logging in a 100000 times Yeah. To a 100000 different accounts. Yes. Yes. Also So something like that.
Kevin:Where's the rate limiting on Twitter's login form? Actually, maybe those drops you saw in the analytics were like Twitter hastily implementing rate loading and returning the right building knobs. Yeah.
Andrey:They probably blocked an IP and they got a different IP and then they went back up and that kind of thing.
Kevin:Yeah, exactly. Folks who I think like when I talk with software developers, you know, software engineers who are working on the sort of like more feature side, I think folks just like have never been on the receiving end of this stuff, or if they have a login form on the internet have maybe like, looked to see what is being sent to their login form. And if you have a login form on the Internet, and you do not have rate limiting on it, and you have not looked at it recently, maybe go maybe go check your logs, see what people are sending.
Andrey:Yeah. I mean, yeah, I was gonna say, ideally, whatever scrypt or like bcrypting you're using is kind of implicit rate limiting just by overloading your system. But Woah. Yeah.
Kevin:Up to a point. And we really hope that you're using scrypt or and not I don't know, MD 5. There's still a number of bad login forms out there on the internet. It's nice to have extra rate limiting because even though like, the those are the password hashes, which you're you should be using, along with assault, this gets into a hole. I should do I am actually contemplating doing a video about some of this stuff.
Kevin:But this gets into the weeds. But like, if somebody is sending you more than like one login request a second, even one login request every 10 seconds, that is not a human typing their password. That is an automated system.
Andrey:Yeah. I mean, maybe we're just a few years away from not wanting to discriminate between computers and humans. So we'll see.
Kevin:Maybe I'm still very skeptical lift chat tbt is sending me more than one login request a second that is also too many. Thank you. You get a different IP address.
Andrey:Come on. Get a different IP address. Yeah.
Kevin:That is going to change things in interesting ways. And I'm very curious to see what happens on the account security side. I'm not super looking forward to it. I'm not thinking that it is going to change things first in positive ways. It is going to introduce new and interesting adversarial patterns that we're going to have to deal with.
Kevin:So For sure.
Andrey:Yeah. Yeah,
Kevin:I did a talk actually. So we met via our mutual friend, Patrick McKenzie.
Andrey:No, we met through Willie, I think.
Kevin:Oh, okay.
Andrey:Yeah, but I have met also Patrick McKenzie. But we're not close. Okay, cool. Never mind. Yeah.
Andrey:Yeah.
Kevin:I did a talk at MicroConf, which is the conference that Patrick McKenzie goes to and talks about
Andrey:a lot. My wife actually works there. She's she's the the yeah. Tracy Osborne. She's a director of of Penny Seed.
Kevin:Oh, oh, brilliant. Okay, cool. Oh, I hadn't realized that connection. Okay. It's a small world.
Kevin:Yeah, I gave a talk at MicroConf this this year about the 3 simple cybersecurity changes every bootstrap software as a service business needs to make. And one of them was implementing rate limiting on your primary, or on your on all of your authentication endpoints. So yeah, it was well received. I had a number of people come up to me afterwards and be like, so I, you know, the CEO is asking the CTO like, are we doing that? And the CTO is like, let me double check.
Kevin:I'm like, okay, great. My work here is done. Nice. I
Andrey:think the
Kevin:answer was yes, for most people. But, yeah, still important to know that and to know why. Because yeah, like, until you have run something at scale, you've probably never had the experience of somebody, you know, trying a bunch of password dumps at you or in this case, like, you know, cloning your site and, you know, setting up a phishing version of it and trying to trick your users into giving, you know, away their credentials. And Exactly. Yeah.
Kevin:You up for one more? Yeah, absolutely.
Andrey:All right. So the last one features George Hotz, which some people might remember from hacking the original PlayStation 3 and the iPhone. Yes. And a bunch of other stuff. Now he he also started comma AI and now he started another AI company.
Kevin:Okay. Most recently, I remember him from like, telling Elon he would solve all of Twitter's problems in a week coming on and like, yeah, he tried and like 4 days in noping out and yeah, and having a long like Twitter spaces with Elon about how horrible things were inside, which to me, sounded like someone who had never encountered a large software system before.
Andrey:Yeah, I think they had a mismatch of expectations, both of them. Yes, yes, yes. Yeah. So one thing most people might not know is he's also been on and off involved in some Ethereum stuff, which is just like a cryptocurrency thing, that I also happen to work on on and off. And so some backstory.
Andrey:One of the interesting one of the interesting attributes of Ethereum is this this this this collectively owned computer, essentially, where we can all execute we have these guarantees where all the code executed on it will be 100% right, because every node verifies it. For some values of right. It like, it'll match the spec. Like, they don't always execute accurately. It will
Kevin:it will it will the computer will always do exactly what you told it to do.
Andrey:Yes. For better or for worse. And it also has a lot of interesting, censorship resistant properties where basically in order to stop a transaction from happening, someone would have to burn 1,000,000,000 of dollars at a time for an extended period of time for as long as they would wanna stop a transaction from happening.
Kevin:This does also make security updates hard, unfortunately. Yeah.
Andrey:It does. It's it's a huge orchestration that happens once every year or 2 where it's, like, many hundreds of people involved all over the world. That's very magical to watch. Okay. Yeah.
Andrey:But yeah. Well, so so one of the things one of the kind of the constraints in order to maintain these these these centralization properties and for everyone to be able to run a node at home on their laptop, there's a very there's a fairly small limit on how much throughput it can handle. People often make fun of it for having something like 10 transactions per second or something like that.
Kevin:And then Patrick McKenzie calls it a slow database. Yeah.
Andrey:Yes. But turns out we can solve it by this this innovation called roll ups. And, essentially, we can run the transaction somewhere else, and we basically commit to a batch of transactions on on Ethereum, and we can prove that they they executed accurately. So back when these roll ups were first kind of designed slash discovered, people were like, the the theory of it was fairly well established. But the way but implementation was still kind of a long road ahead.
Andrey:This is 20 19, maybe? Okay. 2020? Actually, I have a date. 2022 is when this story happened.
Andrey:So the way this this story goes, man, I'm I'm retelling someone else's story, and then my story comes in later. The people working on these roll ups, they're hanging out in, like, a San Francisco cafe, and they're just, like, bashing their heads, like, how are we going to build this? How are we going to build this? And then they sit they churn, and and George Hotz is there next to them. And they know him because he's kind of experimented in the in the ecosystem.
Andrey:And they know he's really smart, so they just, like, start, like, brainstorming with them. And and he gets nerd sniped. And they basically convince him to build a proof of concept of a roll up, in exchange for a very generous amount of money. But the term that they came up with is that they're gonna do an initial, bug bounty and a like $50,000 bug bounty, but the money is going to come out of his compensation if there's bugs. Okay.
Andrey:It's kind of an interesting arrangement. Basically, just to build this, they're gonna pay him. But if there's bugs in it, he's gonna pay
Kevin:for the bugs. You have an immutable piece of software where once you deploy it, it's going to be very hard to update it. And it is going to be responsible for 1,000,000 of dollars. So okay, yeah, better get it right the first time.
Andrey:Yeah. And the the nice thing about these kinds of immutable softwares is you could still deploy more instances of it and just say this version is the new version. You can disregard the old version. So it's immutable, but also there's kind of a, like, social layer where we can still orchestrate things around. Yes, for sure.
Andrey:So Use
Kevin:the new version of the contract, not the old
Andrey:version of the contract. Yeah, exactly. And this is this is before it actually may have made it onto main. In fact, they just launched some version of this onto mainnet, as we call it, last week. So Oh, okay.
Andrey:It took us long to to actually to actually productize this. Got it. Got it. Yeah. Okay.
Andrey:But this was kind of an initial very rough proof of concept. There's, like, a lot of bash. Sure. Yeah. It was all kind of gum and duct tape.
Andrey:But anyway, so, George goes and hacks away for days and maybe a couple weeks and then gives them this thing and like takes their money. And then they do this bug bounty. And I have this this business partner that occasionally do bug bounties and and security audits. His name is Max. And we saw it.
Andrey:I'm like, oh, let's let's try to earn $50,000.
Kevin:Yeah. Absolutely. Take dirt hot's money. Yeah. Exactly.
Kevin:And so
Andrey:we kind of allocate a few days to this. We sit down. We pull the all the source of the instructions. We try running it, and there's an error. Just like right off the bat.
Andrey:Okay.
Kevin:And It's like you can't get the thing that you can't get the source code to build?
Andrey:No. It builds and it runs, but then it gives you an error. Oh, okay. My co auditor, Max, he's like, oh, I'm I'm just gonna post this error on the Discord, like, ask them what's going on, like, is this supposed to happen? And I'm like sitting there, like, wait a minute.
Andrey:If this is airing out, this might actually be a bug that is a $50,000 bug. And he just posted it on the Discord. Oh, no. And I'm like smacking him into getting to delete the message as quickly as possible. Yeah.
Andrey:And yeah. He so it turns out we're the only ones that tried to run it on live data. Okay. When they were developing it, they ran it on like a test net, basically. So it's it's a it's it's like a it's like a dust environment.
Andrey:Right. And no one really bothered to write it. And then there's certain types of transactions that didn't work with the types of proofs that it had to generate. Okay.
Kevin:Okay. So we yeah. So we basically spent
Andrey:a day or 2 debugging it and narrowing down the problem and, like, documenting it and doing like a proper security report, submitting it to Immunify and all that. Yeah, long story short, we got $50,000. $50,000
Kevin:of Trent Hudson's money. Congratulations. Yeah. Yes. Yeah.
Andrey:I mean, to be fair, he's he's, honestly, that experience has reaffirmed a lot of my my respect for him. He's obviously extremely smart. He's really good at, like, building a mostly working system extremely fast. It's extremely complicated. And, yeah, like, just like a quick summary of how it works just to kind of give you an impression.
Andrey:He built an implementation of the MIPS VM that runs on the blockchain. And you and you basically create
Kevin:So this is an older processor architecture.
Andrey:Yeah.
Kevin:So Was that an IBM? No.
Andrey:It's an old RISC. It's it's a RISC architecture that's extremely simple. I think it only has this, like like, 30 something instructions. Okay. It's it's extremely reduced,
Kevin:That's what risk stands for reduced instruction set computing. There was a big fight back in the 90s about whether Intel and the Sysk architectures were going to win or sun and Yeah, deck in the the risk architectures were gonna win. And eventually, we combined them is my understanding. I mean, it should be I mean, risk is does seem to be kinda making a very strong comeback like Well, yeah, pure pure play risk. Arm now is pure play risk.
Kevin:And it does seem like it is eating Intel's lunch with the way that Apple is deploying it and the way that arm themselves are deploying it. And it gets used in a lot of mobile stuff. And yeah, it's just good in a lot of ways.
Andrey:That Yeah. So so to to kind of give you like, a like a little taste of how the system works. So he he built a a MIPS VM. Sorry. The Ethereum blockchain already has its own VM.
Andrey:VM. Yeah. It runs the, yeah, the EVM, the Ethereum VM. So we
Kevin:have a VM and a VM. Right? Yeah.
Andrey:So he built a V MIPS VM inside of Ethereum VM. Because, one of the main Ethereum node implementations is in Go, which is able to build into MIPS. So basically, you you you could you could build the entire Ethereum node, build it into MIPS, and execute it on chain using the MIPS VM, using a binary search to have a challenge system to figure out where you disagree on an execution on any given transaction. So, basically, you you have a a challenger and a defender, and they would both do this. And in order in order to avoid executing probably millions of instructions or, like, billions of instructions, you would do a binary search of instructions, which is log n.
Andrey:So instead of billions of instructions, you would end up running like 90. And then you would kind of go back and forth until you you you agree on which instruction you disagree on, and it would only execute this one instruction on chain Okay. Which is, like, reasonably expensive. But it's just one instruction instead of which building the instructions. It's a really clever design.
Andrey:And I have a lot of respect for it. And he built this whole thing in weeks that mostly worked except for
Kevin:a small nuance. The small nuance being that the like, how do you ensure how do you ensure that you're running against the same data on
Andrey:So you like pre commit on chain 2, you like post a hash basically on chain of your data, and then all the inputs is based off of the hash.
Kevin:And so the and so the issue here then was not that like, the data was different between the different Ethereum execution. So okay, so so backing up from my understanding for just a second. So this is, we can think of this as a way kind of running Ethereum on Ethereum in the way that we would run like Windows in VMware on Windows for testing purposes, if you wanted to have a virtual Windows box, you know, for development or debugging or security auditing or whatever.
Andrey:But you're you're not running all of Windows. You're only wanting running one instruction that you disagree on.
Kevin:Okay. Yeah. Yeah. But you're but but in
Andrey:theory, you you would be able to run everything.
Kevin:You could run all of
Andrey:it, but
Kevin:you you you have this disagreement about this one instruction, which is probably the, like, commit of some block maybe or So okay, so so another kind of important thing, the way these roll ups ups work. So there's
Andrey:a few different kinds of roll ups. There's 0 knowledge roll ups and there's optimistic roll ups. 0 knowledge roll ups use this branch of really interesting cryptography called 0 knowledge cryptography to essentially prove instructions. So you can run an arbitrary set of instructions, and you can create a small proof that you can just verify, and you can have a mathematical guarantee to some amount of certainty that it was executed accurately.
Kevin:It's a way it's a way of giving me a thing that I can hand to somebody else where they're of proving that I did the computation that I say that I did is my understanding.
Andrey:Yeah. So so like imagine something, not now, but in like 15 years, Amazon Lambda, for example, that, like, runs arbitrary functions, would not only run a function, but also give you a kind of a, like, proof that you can verify that it that it ran it accurately. So that's kinda what you could do with 0 knowledge stuff. But, and then there's optimistic roll ups, which work differently. They they rely on, in order to communicate state from the roll up to the Ethereum and main network, they rely on a faultproof and a a faultproof window.
Andrey:So basically, it means because Ethereum itself can't run the whole roll up to verify that that it's it's it's running accurately, it basically has this assumption that if there weren't any fault proofs within the last week, then the transaction is by default accurate, which is kind of an interesting trick. And a fault
Kevin:proof is an adversarial sort of thing where somebody else is coming along trying to verify this, and if they find an error, they post a fault proof which invalidates the transaction or can be used to?
Andrey:Yeah. And the nature of that fault proof is exactly what we mentioned earlier. It's basically the the state route, which is kind of your like hash hash hash recommitment on the state of the blockchain as you saw it in the beginning, and also which is kind of the, like, precommitment of the execution. And and once you provide that proof, you you go into that that kind of binary search to figure out what where the disagreement is, and that only that one instruction of this agreement gets executed on chain in order to resolve the to basically the to, like, decide whether the transaction is is good or not. So, basically, I can challenge any transaction that's kind of in the inbox of of the of the optimistic roll up on chain, but I have to go through through this kind of back and forth.
Andrey:And one one side wins, one one side doesn't. But really it's it's Presumably costs money. I mean, the amount to execute a single transaction. So so Okay. Maybe a few $1,000,000 or maybe a100 bucks.
Andrey:But there's also a whole, like, bonding process. So in order to challenge, you have to put down a bond that's strictly more than how much it would cost to challenge it. And there's, like, a whole kind of economic security system because it's it's as it's cryptocurrency and
Kevin:it deals with money. So this bug that you found then where you're getting an error as soon as you tried to start executing this on live data. Was it just that it like, there were transaction types in the blockchain that it had to interact with that it wasn't expecting?
Andrey:Or Yeah. Yeah. Basically, it was yeah. It wasn't able to create a proof for certain types of transactions. And the reason the bug was important is because there's that 7 7 day window for someone to give a proof.
Andrey:And if you can break the prover, if you can basically make it not be able to execute any proofs after some transaction, that means you can you can put incorrect transactions and no one will be able to actually prove you wrong. So being able to break inject a transaction that a a, like, prover won't be able to it'll get stuck on is is actually really bad.
Kevin:Interesting. Okay. Fascinating. And this was just sort of like, again, that there, you know, there was a type of transaction that the prooper wasn't expecting, it didn't have a branch in its sort of case statement for it to handle it. And so it was just throwing up its hands being like, I don't know I don't know what to do with that.
Kevin:And that broke the whole system? So something like that.
Andrey:It was it was something to do with the the memory oracle.
Kevin:So this is a whole
Andrey:other thing. We we can go to the weeds if you like. Like. Goodness. Yeah.
Andrey:So so Oh, we got some. Okay. So because you're running a VM instead of a VM Right. The VM at the very bottom doesn't have access to all the memory you would otherwise need.
Kevin:Okay. Sure. Right.
Andrey:Like, it can't just like, be like, oh, give me memory address, this, this, and that, and the kinda load state and that's like That is
Kevin:in fact, you really don't want your VM to have access to all of the memory. That's one of the reasons you run things in VMs is so that they only have access to the memory that you give them inside the VM, and they can't touch the memory outside the VM.
Andrey:Well, the interesting thing is they don't have this particular VM has no access to any memory. It only has access to proofs of memory. Okay. So it has a a preimage oracle, which basically means, the way, like, proofs work generally is just like a it's this these, like, Merkle trees of hashes. So it's just like a a hashes of hashes of hashes and you have some kind of signature over them and then you you could prove that it exists somewhere in the street.
Andrey:So they have this might be mangling this, it's been a few years, but in order for the VM and the insight to work, it needed to anytime you need to access data, it needed to query the hash of the data rather than the data itself. And then there was, like, this pretty much oracle that would take the hash and map it do the operation, the actual data, and then kinda just give it the result, essentially. And and that was basically the way that the preimage oracle worked to generate these hashes. It wasn't working for all kinds of transactions. It, like, turned out they needed to do a fairly substantial rearchitecting to make it more more generally.
Andrey:But yeah. Oh, interesting. Okay.
Kevin:And it sounds like they had not run this on live data before they, yeah, publish this. Did they actually, like, ship this to production?
Andrey:No. No. No. No. This this is like pre pre pre pre pre production.
Andrey:This is just like George Potts being a an amazing cowboy whipping the salad in a couple of weeks, writing probably, like, 6 months of what to work in a couple of weeks, and then dumping it and then leaving. Right. Okay. Yes. Okay.
Andrey:Let's see if this works.
Kevin:Great. Okay. And it turned out that they had another 6 months worth of work to do.
Andrey:Well, they've got another another couple years worth of work. But yeah, as you said, there's like 1,000,000,000 of dollars that it's is on the line. So it has to be extremely careful.
Kevin:I guess, I mean, I guess they got the proof of concept that they wanted.
Andrey:Yeah. Yeah, exactly. Because the whole thing is they wanted to figure out an approach that they could work towards actually formalizing. And I think George helped them kind of throw them in the right direction, essentially.
Kevin:Sure. Yeah. Okay. Yeah. At least here's the thing we know works on this subset of the problem.
Kevin:And now how do we generalize it to the full problem, even if that is, I guess, several more years worth of work? They still, like, getting getting from 0 to 1 was pretty important.
Andrey:Yeah. I think I think using MIPS was was strictly his idea because I think he has a lot of experience with with with processors back from his, like, PlayStation 3 days and all that.
Kevin:Yeah, I very much think of him as like a more of an embedded person than a, yeah, application person. Okay. That's, and that is like, just from a like, technical from a from a technical standpoint from a like, you know, wild eyed kind of like hacking, like, standpoint, like the idea that you can run Ethereum and, you know, an Ethereum VM on the Ethereum blockchain by, by the way, writing a MIPS VM in Ethereum and then to run that is, yeah, kind of wild. It's like it's like it's computers all the way down.
Andrey:Well, it's such a stat, but basically, the implications of this is anything that you can build into MIPs, you can run on Ethereum now. Or at least not run per se, but you but you can actually prove an Ethereum. And then there's there's a bunch of other there's a bunch of other roll ups that do other stuff that you can prove, basically, anything like using WASM or, like, whatever. So so so kind of from, like, an abstract node sniping type of type of perspective is, like, being able to to, like, write a program and relatively cheaply have a 100% guarantee that's worth any 1,000,000,000 of dollars that it was executed accurately is something that like, any random person can do now is is really wild.
Kevin:Right? Yeah. And like, there are whole Linux distributions, which are, you know, for MIPS, like that was one of Debian's or there were I don't know if Debian still builds to MIPS, but it used to. So you could have conceivably anything that you can run-in Debian now I guess, you know, proved on the Ethereum blockchain and yeah, wild.
Andrey:It's a neat environment. And like, I think kind of at the end of the day, we will see some some like traditional kind of the AWS's Lambda and stuff offering similar guarantees eventually, but I think there's just not enough market demand for it yet.
Kevin:I feel like I'm you talked about the social, you know, controls, which help manage that. And I feel like that's where we get a lot of that kind of stuff from AWS Lambda, it would only be in really, you know, niche, narrow, sort of like extremely high value use cases around things like cryptography, around things like money, where we would want these kinds of guarantees.
Andrey:Well, I think also just for like offloading, offloading operations, like I think a lot of people are uncomfortable, for example, like, like running, AI. People like, would you trust all your AI to be run non locally? Like, what if they're they're influencing your results? I mean, clearly people do. Clearly people do.
Andrey:They do. But but it's also a really big argument around it. What other people feel okay with it, whether they they trust the results, like I I mean, I don't trust the
Kevin:results, but I don't trust the results for reasons outside of like, whether it they, you know, the computations got performed correctly. I don't trust the results because there's something higher in the stack, which is does not care about the truth value of its output.
Andrey:But once we solve that one, then we're gonna work our way down the stack. And then we're gonna have other kinds of issues.
Kevin:So yeah, we'll see. Also, like, given the amount of compute, I guess it's the compute is going as is going to training as well as to deployment, but the amount of compute that it takes certainly to train these things is like, you know, data centers.
Andrey:Yeah. Well, I mean, like just as an example is like if you wanted to, well, okay. So like one, I'm trying to think of a good kind of mainstream example. Like maybe in some games that we currently rely on client side DRM to to, like, guarantee that you're not not, like, modifying the game in some way. Instead, we could have instruction proofs, maybe.
Andrey:Right. Yeah.
Kevin:Yeah. Yeah. Right now, that seems to
Andrey:be done mostly from a client verification standpoint rather than, yeah, verifying with the actual computations that the client is performing, although. Yeah. Well, that and it's also being everything's being replicated server side as well, which if you have if you have instruction proofs, then you don't need to do that. Interesting. Okay.
Kevin:We're now getting, like, deep into the weeds. And you also get a preview of some of the stuff that if you do not live in the valley, are kind of conversations that I have around
Andrey:the valley a fair bit with people.
Kevin:But, yeah, and so there's, yeah, like, open areas of research and things to build and ideas to explore. But, yeah, very cool stuff. Any other stories to share with
Andrey:us today, Andre? That's all I got for now.
Kevin:Okay. Okay.
Andrey:I'll try to manifest some more in the future.
Kevin:Okay. Yeah. Well, yeah, it would be lovely to have you back on. And yeah, this has been real lovely.
Andrey:We'll find you online. I'm I'm Chazo everywhere. It's Chado but with a z. Great. Okay, cool.
Kevin:Twitter, Blue Sky Mastodon.
Andrey:Yeah, like Farcaster, if you've heard of it. And Chado dotnet, on Google, on Bing, it's on. Okay, cool. Yeah. On Keybase.
Andrey:Great. Love it. Got it. Oh, yeah. Gotta be
Kevin:on Keybase. You're doing crypto. Gotta be on Keybase. Yes. Awesome.
Kevin:Awesome. This has been the War Stories podcast on Critical Point. I'm Kevin Regal. This is Andre Petrov. Oh, and Andre, what is it that
Andrey:you're doing now? Like Like I mostly do a lot of random open source stuff. That's pretty I build a lot of Ethereum infrastructure stuff. I work on some Ethereum libraries. Cool.
Kevin:Yeah. Well, okay. So you've okay, so you've moved on from Python infrastructure to Ethereum infrastructure?
Andrey:Yeah, I mean, I've been working it for almost a decade now on and off but yeah. Okay. Okay. Cool. Yeah.
Andrey:Cool. Very cool.
Kevin:Yes, this has been the War Stories podcast on Critical Point. Cabrillo Andrey Petrov. Thank you so much, Andrey. It's been a ton of fun. Thank you.
Kevin:We will see you
Andrey:all next time. Take care.
Creators and Guests
