...But Doesn't Rails Take Care of Security for Me?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 9 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31587 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 20169 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
Information securityCASE <Informatik>Multiplication signQuicksortVulnerability (computing)Lie groupInternetworkingElectronic mailing listSlide ruleEmailTwitterMereologyException handlingSimilarity (geometry)Revision controlGoodness of fitTheory of everythingWeb 2.0Bit rateWebsiteDifferent (Kate Ryan album)Presentation of a groupReal numberProduct (business)Sound effectElement (mathematics)HypermediaComputer animation
03:30
Information securityOperations support systemInteractive televisionTwitterMathematical analysisFluid staticsDefault (computer science)CryptographyMobile appObject (grammar)Directed setTraffic reportingProxy serverAndroid (robot)CodeFormal languageNumberDatabase transactionInjektivitätShared memoryUniform resource locatorDefault (computer science)Information securityMobile appRow (database)Computer programmingNumberComputer-assisted translationTouchscreenRight angleSlide rulePlastikkarteWebsiteTerm (mathematics)Execution unitCartesian coordinate systemProjective planeTwitterBitValidity (statistics)Web 2.0Electronic mailing listMultiplication signMereologyKey (cryptography)InformationTraffic reportingInsertion lossRevision controlComputer configurationMetropolitan area networkAutomatic differentiationSoftware bugParameter (computer programming)SummierbarkeitControl flowObject (grammar)CASE <Informatik>Open sourceQuicksortLink (knot theory)FrequencyDatabaseFront and back endsProper mapReal numberTurtle graphicsData miningMathematicsCodeComputer animation
12:57
Order (biology)Dependent and independent variablesAsynchronous Transfer ModeSineVideo gamePasswordCryptographyCodeHash functionAlgorithmFacebookPasswordMobile appLoginIterationDatabase transactionPlastikkarteFacebookQuicksortCore dumpVideo gameDifferent (Kate Ryan album)Key (cryptography)CodeSource codeArithmetic meanHash functionInformation securityDatabaseMoment (mathematics)Coprocessor1 (number)FlagLink (knot theory)FreewareOrder (biology)State of matterNumberCASE <Informatik>Direction (geometry)Server (computing)Client (computing)LaptopMereologyGroup actionInformationPhysical systemFourier seriesRight angleProcess (computing)EmailSpecial unitary groupPatch (Unix)Multiplication signInterior (topology)Set (mathematics)AlgorithmCartesian coordinate systemReading (process)WordEndliche ModelltheorieDivisorLine (geometry)Total S.A.Functional (mathematics)LogicWeightArchaeological field surveyValidity (statistics)Computer animation
22:24
CodeEmailInformation securityMassFacebookLimit (category theory)Bit rateHacker (term)WebsiteVulnerability (computing)Expected valuePasswordNumberBeta functionCodeType theoryMultiplication signPoint (geometry)Digital photographyForcing (mathematics)Bit rateInformation securityFacebookDataflowLimit (category theory)Software bugDigitizingVotingEmailCASE <Informatik>Medical imagingWave packetSystem callComputer animation
25:09
VideoconferencingFunctional (mathematics)WordVideoconferencingUniform resource locatorYouTubeCASE <Informatik>WebsiteDisk read-and-write headComputer animationLecture/Conference
25:47
Coma BerenicesClient (computing)String (computer science)Motion captureFile Transfer ProtocolFreewareCodeHTTP cookiePasswordSummierbarkeitDenial-of-service attackSystem administratorServer (computing)Software bugInformationString (computer science)Gastropod shellInternetworkingKey (cryptography)CuboidBitBlogFunctional (mathematics)Sign (mathematics)ChainOpen sourceInformation securityCodeNumberSource codeWordRemote procedure callMereologyMobile appEmailCartesian coordinate systemWeb applicationRight anglePoint (geometry)Slide ruleProxy serverWeb 2.0DatabasePasswordRevision controlMultiplication signSoftware repositoryCommunications protocolMathematicsCausalityRule of inferenceScaling (geometry)ArmHTTP cookieMedical imagingDistanceFlow separationFile Transfer ProtocolLink (knot theory)CASE <Informatik>Uniform resource locatorAreaToken ring
34:26
Server (computing)Key (cryptography)Source codePasswordGroup actionElectric currentFormal verificationAlgorithmClient (computing)Bit rateLimit (category theory)Information securityGUI widgetPrice indexAreaPasswordInternetworkingSoftware bugWeb 2.0CuboidElectronic mailing listMereologyMultiplication signInheritance (object-oriented programming)Key (cryptography)Point (geometry)System administratorFacebookSource codeServer (computing)Exception handlingTime zoneRevision controlData storage deviceSlide ruleQuicksortInformation securityBit rate1 (number)Group actionProduct (business)Goodness of fitLimit (category theory)Web browserForcing (mathematics)CodeVulnerability (computing)Projective planeComputer programmingChecklistOpen sourceCodeRight angleLine (geometry)State of matterCartesian coordinate systemNumbering schemeSequenceComputer fileWater vaporInsertion lossClient (computing)Generic programmingGame controllerTheory of relativityService-oriented architectureAlgorithmWordRenewal theoryLevel (video gaming)Computer iconArithmetic meanCASE <Informatik>Computer animation
43:05
Lecture/ConferenceComputer animation
Transcript: English(auto-generated)
00:11
We have three minutes before we're supposed to start, but who was here for Mike's talk just a few minutes ago? Okay.
00:20
So this is part two, just when you thought it was safe to go back on the web. So Mike, he covered some specific problems and then some breaches that have happened. And when I, this was like a week ago or so, I saw, like I knew he was speaking and I've
00:45
known him, we use their product. So I sent him an email and I was like, hey, actually your talk sounds really similar to my talk. You're like talking about breaches that have happened and I thought I'd go through some real things that have been found and I was like, here's my list of things
01:03
that I might talk about. Does this conflict with anything you're talking about? And I couldn't believe it. He wrote me back and he's like, I'm not talking about any of those. Although he did kind of lie because he mentioned Ashley Madison, but he didn't really talk about it. So if you were in that talk, this is kind of like a similar talk except sort of
01:23
the details of vulnerabilities that have been found in different people's sites. So if you were, in case you were curious about this talk versus that talk. Also I just like to talk, so when I get up here I like to talk.
01:41
We have one minute before we're officially supposed to start. I like to use vacation pictures now for my title slides and this is Meteor Crater in Arizona. It's actually the first crater that anyone actually figured out came from a meteor. In fact for a long time they thought it was like a volcanic thing.
02:01
So yeah, this is, in case you're wondering, it's pretty big. I don't remember exactly how big, but it's pretty big. There you go.
02:28
No, no, it's not that big. Well, so you would have to have detection, right?
02:40
And then you would probably have to have some way of avoiding it or deflecting it. Alright, so I should start the real talk. My name is Justin Collins, at PresidentBeef on Twitter and most of the internet.
03:02
I wanted to give this talk. I've actually heard people say phrases very similar to this. In fact I heard at least one person say it this week. Not quite like, you know, I believe Rails is gonna do everything for me, but sort of that question of like, well but isn't Rails pretty good at security? Doesn't it kind of do a lot of stuff for me?
03:20
And so I thought it was a good title for this talk. And so the question is, doesn't Rails take care of security for me? The answer, no, it doesn't. And that's all I have, thank you. This is, I would have put up pictures of my cats,
03:42
but everyone does that and mine are not as funny looking as Aaron's, so here's my turtle instead. Okay, so some more details I would guess. I hate doing these slides, but it's somewhat relevant. This is, I believe Snapchat shows you your soul,
04:03
so this is what my soul looks like. I've been doing application security for about six years, and working on Brakeman open source project for essentially the same amount of time. Last couple years working on Brakeman Pro,
04:21
if you just need to be more professional about your security tools. If you really like Brakeman, but you don't feel like you need the pro version, but you want to support Brakeman, you can buy licenses for Brakeman Pro, and you don't have to use them, but you can buy them, and that will support the open source project.
04:42
Okay, so that's all I'm, that's the sales pitch. Okay, so this talk, I already told you what it was, but if you're looking for what Rails does give you and what Rails does not give you, I gave a talk last year, that was the vacation to the Grand Canyon, about the security things
05:03
that Rails does well, things it doesn't do well, things I wish it would do better, and then Brian Helmkamp, a couple years before that, gave a talk about Rails insecure defaults, some of which have changed in the meantime, so that's good. So if you're interested kind of in that topic, which is not what this talk is about, you could watch those.
05:24
Like in between those two talks, I did a talk with Aaron Bedra and Matt Conda, where we kind of did like a hypothetical scenario, where we acted out like, oh, we're developers, and we wrote really bad code, and these are all the things that are happening
05:41
because of it, and I don't know how well that went over, but this talk is kind of like that, except this is all real. And these all come from public disclosures, mostly from bug bounties, sometimes from people who didn't necessarily get a bounty out of it.
06:01
I'm not picking on these companies at all. I like most of these companies, and I'm sure they're great, especially Twitter since I work there. But these are just like the well-done write-ups that I could find so that I could share with you
06:21
not just like, not pick on Mike, but not just like there's SQL injection, but like what actually happened, and none of these are things that Rails will save you from, essentially. Okay, let's start with Twitter. Like I said, I work there, so I feel like I can share this.
06:42
It's public anyway, but just letting you know I'm not picking on them. Okay, so let's get into it. A researcher was looking around on our ad site, and he noticed something that when you put in a credit card and we check it and we go, oh, that's not a valid credit card, you get this little modal, and it's like,
07:02
oh, you know, we weren't able to approve that card. And then you have two options of what to do with it. One is try again, and the other one is dismiss. And he noticed what happened when you hit dismiss. There's a method that gets, or a URL that gets hit, and you can see there's like the account ID,
07:23
and this is actually the bug bounty researcher's account, and then payment methods, handle failed, and then an ID. So I'm starting off the talk. This is a Rails app we're talking about. And so you know that thing at the end is probably the ID for the payment method.
07:42
And he noticed what would happen is the payment method would go away, right? So he's looking at this number. He's thinking, this is probably the ID of the payment method. What if I just like changed it? Does that still work? Is that gonna delete that payment method?
08:02
Well, it turns out in the back end there was code that looked something like this, where it looks up the payment method from the ID parameter, and it deletes it. I still think, like when I was making these, I'm like, that's so weird that dismiss deletes it, but that's another thing.
08:21
So this is exactly what was happening. And in the sort of web security world, this would be considered an insecure direct object reference. It's a direct object reference because that ID is the row in the database. And it's insecure because we're not checking that the person who's deleting that row
08:40
actually owns that row. There's another term for this exact thing right here, which is an unscoped find. And I don't think I came up with this term, but then I searched, and it doesn't seem like anyone else uses it. But in Rails, you can scope your finds, or you could not scope them, or you could unscoped them.
09:01
So this is kind of like a find that wasn't scoped properly. So the way you should do this is to scope it to the current user, and then do your find for the payment method, and then delete it. Okay, so for this, we paid out $2800. I'm fairly certain that was our largest bug bounty payout to date, why?
09:21
Because someone could delete all of our customer's payment cards, and that's how Twitter makes money, is from people paying for ads, and you can imagine that would be a huge loss for us. So thankfully, they reported it to the bug bounty, we paid them $2800. All right, next up, United.
09:42
And I put the links for later, if you wanna read the write-ups from the people who found these. So in this case, there's a guy. United launched a bug bounty program kind of famous because they're like, we'll reward you and reward miles,
10:02
which is kind of, not a lot of companies give you that, but then you have to fly United, so. So anyways, he was looking, and what he was doing, he was just proxying the traffic from the mobile app, just to see kind of what was going on,
10:21
and he noticed there was a request. Is that on the screen for you? Oh, sorry, it's a little bit off. The details don't really matter. It's making a post request, I cut out some stuff, but he noticed in the request, there's MP number. So United, they have mileage plus or something like that.
10:43
Yeah, okay, I don't fly them. So mileage plus number, and he thought, oh, that's kind of like my user ID. What if I change that? You might notice a trend here, right? So he's just like, what if I changed it to someone else's number? What would I get back?
11:01
And he got back a whole bunch of information, I know this is kind of small, but I'm gonna zoom in, including what flight they're on, or what flight they're booked for, their name, where they're going, is it late, like when's it coming, when it's going, every leg of the trip, there was a whole bunch of more information. Well, he noticed in particular,
11:23
there's a record locator, and there's a last name. Any guesses as to why those might be important? Yes, exactly. So what do you do when you check into a flight? What do you do when you need to look up a flight and you didn't create an account on the airline's website
11:43
you put in your record locator and your last name. So the reporter who found this, hey, you can kind of see that, he noticed that, yeah, you can go on, all you need is that number and last name, and there's a list here of all the things you can do,
12:00
look at your reservations, change it, cancel it, get a receipt. Another thing he mentioned is you can see the person's emergency contact information, so whoever they put in for their emergency contact, you can see that. All you need is a confirmation number, last name, and you can look that up for any mileage plus member number.
12:24
So that's pretty bad. There was some drama because he reported it to them and they didn't fix it for a long time, and then he threatened to publicly disclose it, and then suddenly it was fixed, and they're like, no, no, no, we were working on it the whole time, and by the way, your report was a duplicate, so we're not giving you any money,
12:41
which happens a lot in bug bounty, and being on the other side, it just happens, but he didn't get any money for that. I guess it was a pretty obvious thing that other people found. All right, Domino's Pizza. I don't eat a lot of Domino's, but I seem to recall the name came from them
13:02
having rectangular-shaped pizzas, which, do they even have those now? I don't think I'm that old that you don't remember square pizzas, and I do. Not that old, for sure.
13:20
Okay. Okay, so again, someone was, actually in this case it was kind of interesting because he was actually looking for something else. He was curious how they generated, apparently sometimes on the mobile app they would give you a random coupon for $10 off or something, and so he was actually looking for that, but what he found instead
13:40
is the way the payment system worked was the phone was actually, the phone actually handled the payments, so you put in your credit card number. It would send it to the payment processor, and payment processors look like this. You just kind of shove your credit card into your laptop screen, and then it would send back,
14:03
okay, that was successful, and here's sort of the transaction ID or the reference number for that credit card transaction, and then the app would send it to Domino's with your order, and then they would make your order for you, so he thought, right, and if there's a failure it just doesn't send it to Domino's, right?
14:23
So he thought, oh yeah, I gotta tell you that there's some XML ahead. If you need to avert your gaze, it's fine. It's not that bad though, so this is what would come back from the payment processor if it failed. Let's say not authorized, and then there was a reason, it was declined,
14:41
and then a status number, and we assume seven means declined for some reason, so he thought, what did he think? What if I changed it? Yes, catching on. What if I just set that to success? As far as I know, he didn't change anything else. Just change it to success, and then I'll send that on to Domino's,
15:04
so it kind of looks like this. It failed, but we're gonna just change that to success, send it to Domino's, and then he's like, he had no idea if this would work, of course, so he checked his app, and he sees, well, it says they're working on it,
15:21
but you know how mobile apps are. Maybe it's just like a UI thing or something, so he called them and said, hey, did you get an order from me? And they're like, yeah, we're working on it. We'll get it to you in 30 minutes, whatever it was, and he felt kind of bad about it.
15:40
He felt kind of bad about it, so he did pay for it. Like, when the guy showed up, he was just like, oh, I think there was a mistake. Like, here's the money for it, so he didn't actually get a free pizza out of that, but in this case, it's simply that the server didn't check that what the client told it was true.
16:01
It had the reference number from the payment processor. All it had to do was ask the payment processor, hey, I got this ID. Was it successful? If they had just done that validation, no problem, and so a theme in the security world, really, is that you shouldn't trust anyone,
16:22
and I was thinking about that because I thought I would just tell you, don't trust anyone, but when you're building an application, you actually do have to trust some of the things that are sent to you, depending on where it comes from, so the main thing is you need to know, think about who you're trusting and what you're trusting,
16:42
and if you should, right? So, unfortunately, you can't just trust no one. All right, so talk about Ashley Madison. I included their motto or tagline here because I think it's like a total logical fallacy.
17:01
Life is short, so have an affair. It's like, well, life is short, so make your life even worse by ruining it. So they had a whole bunch of information stolen. I don't know how it was stolen. I'm not talking about how it was stolen, but part of what was stolen, database dumps and source code,
17:25
but interestingly, not just source code, but Git repos, which is very interesting, right? It'll become apparent in a moment why that's interesting. So in that, about 36 million passwords. However, they were hashed with bcrypt,
17:41
which is maybe not top of the state of the art, but pretty much recommended, use bcrypt with decent work factor, which they were doing, so that was good, and at the time, not that long ago, but at the time, a lot of people were like, oh, okay, we gotta start trying to crack the bcrypted hashes so we can get the passwords, but there was a group that took a different approach.
18:05
I gotta warn you, though, again, even worse than last time, there is some PHP code ahead, but it's not that bad. I think you will survive. I almost rewrote it in Ruby, but it was actually kind of longer, and I wanted to fit it on, so they found some code,
18:23
and it's calculating this login key, and we actually don't care what that was for. All we care about is the login key was in the database associated with a user, and so they saw this code, and they say, okay, well, it's an MD5 hash. That's a red flag.
18:40
It's got the username, and it's got the password in it, and for some reason, they're lower-casing both of those, which just makes this whole thing worse, but they're encrypting it first, so now we're dealing with the hash of a bcryptid password, so that's not very useful if I'm trying to crack the passwords. So then they looked in the git history,
19:02
and they found that this code used to look like this, so it used to just hash the lower-cased password directly. So that was pretty interesting, because they knew the username, and they knew the login key, and they know how it's constructed, so now you can calculate,
19:21
I believe it's billions of MD5 hashes a second, so this was a good place to start. There was another piece of code, though, and here, LC means lowercase, where they were doing, and weirdly, this was also to calculate a login key,
19:40
so who knows what was going on in the code base, but in this case, they had username, password, email, and then this secret key, but remember, we have all their database and all their source code, so the key is not secret, username's not secret, password's not secret,
20:00
the only secret is the password, so this was another avenue that they decided they could use to try to crack these hashes. So they started doing this, about two and a half million passwords were cracked, they didn't say exactly how long, but they said in a few hours, they had this, and remember, there were all these other people
20:21
who were trying to crack the bcrypted passwords, which would probably take years and years and years, so in a few hours, they had two and a half million passwords, in a few days, I didn't follow up with all of it, but the second post they did, they said they had almost 12 million passwords
20:42
that they had cracked, to be fair, and I don't have a link to that post, but you could probably find it, most of those passwords were pretty awful passwords. So I think this is an interesting story, because they were doing the right thing,
21:01
they were using bcrypt for storing their passwords, but then on the side, they were doing something with a much weaker hashing function, and that led, I mean, I guess I should say researchers, not attackers, to be able to crack the ones that were using the much stronger hash, and if you're paying attention,
21:21
yes, they were lower-casing the password, but most of the passwords were lower-case, but as the researchers were cracking them, if they found a hash that worked, then they would just try a few iterations of different capitalization, and they could pretty much get it fairly quickly, and then they compared those,
21:41
to make sure they compared those with the, they could calculate the bcrypt hash, and so they could be like, yeah, these are actually the passwords. So don't use weak hashing algorithms. I know this is, this example with the picture is not actually a hashing algorithm, but it's the idea, right?
22:02
You're trying to hide something, and you kind of feel like you hid it, but you didn't really. So just avoid using MD5, avoid using SHA-1, use SHA-256 for this kind of thing, well, not for passwords, but for things other than passwords. All right, Facebook.
22:22
This one will be really quick. So you want to reset, or you forgot your password on Facebook, so you go in and they say, okay, we're gonna send you a six-digit code. You type in the code, we'll reset your password, or actually, I don't know what happens after that, but we'll get you into your account.
22:42
So six digits, how many possibilities is that? Yes, very quick. One million. So that's actually a reasonable number to just try all of them. So a researcher, just to let you know, for Bug Bounty and probably other security researchers,
23:04
the forgot password flow is often a weak point in websites, because you're basically saying, I don't know the true credentials that I should be using to get into your site, so give me some other way to get in. And a lot of times, there's flaws in that.
23:21
So he's looking at this, and he hid it, and I don't know how many times he hid it, but it was rate limited. So he's like, well, okay, that's expected. But then he went over to another site that he happened to know about, which was Facebook's beta site. Well, it just happens to turn out
23:41
that they did not have rate limiting on that site. So essentially, for any account that he knew, the user name, email, or phone number, he could get into their account, because he'd just request the code. It doesn't matter what the code, wherever that went, it doesn't really matter.
24:01
And then you just sit there trying, at most, a million times in the absolute worst case, which you could do relatively quickly, especially compared to trying to brute force a password. So in this case, it's just straight up missing rate limit. Should have been a rate limit, there wasn't one.
24:21
And interestingly, this is probably the simplest of all these examples, and yet, he got the most money, because the impact is, well, gee, I can get into anyone's Facebook account.
24:41
Does anyone know how to pronounce this? So I say Imgur, I don't know. So Imgur, you upload photos or whatever, and people look at them and comment and upvote or whatever.
25:04
I'm saying that very casually, but I spend a lot of time on this site. Anyhow, they have this functionality where you can give them a URL to a video, and then they convert it to a jif.
25:24
I gotta be honest, I'm a real introvert, I don't talk to a lot of people, so most words I only pronounce in my head, and then I have to get up and be like, talk about something, and I say jif, I'm sorry. So in any case, you point it at a video like YouTube or something, and it'll convert it to a gif.
25:43
And then you can show it on the site, right? So a researcher was looking at this, he noticed how it works, it hits some endpoint, and it passes in a URL, and then it goes and fetches that URL, of course.
26:01
I mean, it's pretty simple functionality. Something like this, so you give Imgur a URL, and then it hits it, like maybe bit.ly or something, and this is called server-side request forgery, because you're basically asking a server, like Imgur servers, to go and make a request to another server, essentially on your behalf,
26:23
and you can use this for things like denial of service attacks, or any kind of attack where you'd kinda like to hide behind someone else, or maybe they have way more bandwidth than you do, or maybe they have a trust relationship between the servers that you don't have.
26:42
But that's not exactly what this is about. So the researcher was like, what if I changed that? What if instead of HTTP, I use SFTP? And I'll just set up a server, not bit.ly, but I'll set up some server where I can see
27:00
the request that comes into my server, and just see what happens. So I set up, using Netcat, he's like, just listen on this port, see what comes in. One of the things that came in was, hey, I'm coming to do my SFTP or whatever. First string that comes in is like, oh, I'm a libcurl, and this is my version number.
27:23
That's pretty useful information. And so what he did was he basically started trying all these different protocols, and essentially Imgur would just, whatever you gave it, it would just go and do. And I didn't go through the whole example, because from a security point, it's not that interesting.
27:43
But if you go read the post, which again, I linked, and of course the slides will be available. He set up a server that it would hit with, I think it hit it with SFTP,
28:00
but then he redirected them to a gopher URL, and tricked them into sending an SMTP request to another server. So he was actually using them to send mail through, I think it was mail.ru. So it was just like, kind of a overcomplicated example of what you could do with it.
28:20
The main thing is you can make these requests and essentially use them as a proxy. He got $2,000 for that. And I don't think I put the slide, but basically, if you're not expecting to make these kinds of requests, you should be checking that you're not making these kinds of requests.
28:41
So he got $2,000 for that. All right, last example. I realize this is also Facebook, I'm not picking on them. So this came out a little bit ago. There was a lot of drama around it. I'm not gonna talk about the drama, or the causes, or who may or may not have been at fault.
29:02
I'm just gonna talk about what he did because it's just such a really interesting example of going from having some little bit of information, research, well anyways, why did I have to tell you? I'm gonna tell you what happened. It's just a very interesting chain.
29:21
So he's a bug bounty guy, he's a security researcher. Someone tells him, hey, I saw on Instagram, they seem to have some kind of admin panel that's on the internet. That's all I really know about it, but maybe you can check it out. So he starts, he goes, he starts looking around like,
29:41
what is this, you know, whatever. He ends up on GitHub, and he notices that this admin panel is actually open source. And you may notice something, which is, this is totally a Rails app, right? We're at RailsConf, I'm bringing it back.
30:01
Started with a Rails app, ending with a Rails app. So this is a Rails app. So he pokes around, there are well-known issues with the Rails apps, and he finds this. So you're well aware, so he finds the secret token,
30:22
and honestly, is it bad that this is here, yes, but probably the point to take away here is that if you're using an open source Rails application somewhere in your infrastructure, you should go and change this value, right? Okay, so he sees this, so he's like,
30:42
well, that's pretty good. And also, this is running Rails 3.2.14, which is, I believe, from 2013, so pretty old. And he does some more research, it doesn't really matter, because we know, in this room, that Rails 3.2
31:04
is a session cookie, is signed, but it's code that has literally been marshaled to a string, but it's signed. And usually the signed part is kinda what keeps us safe, but he has the signing key. And when you un-marshal code, it's possible to execute
31:23
code, where probably, if you've been around for a couple years, you probably remember 2013. So, session cookie, signed, marshaled code, and if you have the signing key, you essentially have remote code execution.
31:41
Now, if you read his blog post, I actually got a little confused, because the exploit he used was for Rails 3.2.11, or no, no, 3.2.10, which was supposed to be fixed in 3.2.11, but then he used it on 3.2.14, so I have no idea what that means, but I'm just letting you know.
32:00
But in some case, however he did it, he was able to create a forged session, server accepted it, because he signed it with the correct key, they hadn't changed it from the open source repo, and he got a remote shell on the box. So at this point, honestly, he was done,
32:22
and again, I'm not talking about the drama, but this is where it begins. So he has the remote shell, that's awesome, but what can he do? So he decides, well, there's a database
32:40
for the web server, I'll just connect to it through my shell, and see what's there, and what is there. Passwords are there, that's awesome. However, they're recrypted, okay. Now there isn't like an MD5 bypass this time. Instead what happens is he's like,
33:01
well, whatever, I'll try cracking them anyway. You know, long shot, but I'll just try it. Well, like jackpot. So six of the passwords were just change me, so probably someone set up an account for someone and then they never changed their password. Three of them were the same as the username.
33:20
Two of them were just the word password, and one was the word Instagram, which makes me believe probably when he set up his cracking tool, he seeded it with some of this information, right. So that's bad. He logged in just to show that he could, but then he's like, this isn't actually that interesting as a web app.
33:41
He was talking about like, well, maybe I could like set off some pager duty alerts, but you know, not that interesting as an attacker. So then he starts poking around, and he notices on that box, there are keys for AWS. And so he goes to that box, and on that box there are more keys to other S3 buckets.
34:02
And then he starts looking around, and again, not talking about the drama, but you can see where some drama would come from. He starts seeing like, wow, there's like tons of stuff. Anything you could kind of imagine, I can probably access. And this is all from using an open source Rails app
34:21
that had the secret token in the source code. Yep, secret in the source code, really old version of Rails. There were weak passwords, which he didn't use for anything except for logging in, but weak passwords. And then the keys were sitting on the servers, which like, how you solve that,
34:43
I think that's like the worst, or the least bad thing on this list, really. So he got, he did get $2,500. I don't know if it was worth the drama that he went through. Again, you can read that on the internet.
35:00
All right, so just to kind of summarize here, of like, oh I'm sorry, it's kind of off to the side, but things you should do. Okay, so verify that the current user can do the thing that they're asking to do, that they can access the data they're asking to access. And I want to point out that this is not just
35:21
from the web browser necessarily, if you're in a service-oriented architecture, you gotta think about that too, because again, think about who you're trusting, think about who they're trusting, and never trust the client. So think about those trust relationships.
35:41
Always try to use strong hashing algorithms, and I know there's a strong temptation when you're like, well this doesn't really matter, like I'm just using it for this, or like I'm not really hashing their password, or something along those lines. You can use SHA-256, it's like super fast and strong.
36:01
So just use that. For important actions, like logging in, confirming codes, any kind of action that is either someone can brute force something, or even if it just causes you financial loss, put a rate limit on it.
36:22
Don't put your secrets in your source code. And it's kind of a hard thing, because you're like, well, but my source code's right here, and then like, well where do I put my secrets, and so on. The thing is, if you have someone steal your source code, which happens, because it happened to Ashley Madison,
36:40
you don't want to have your secrets right there in the code. And certainly don't put them on GitHub, which it happens like all the time. So if you just don't have them in your source code, it's just not a problem. And then finally, I know it seems like such generic security advice, like always use strong passwords,
37:00
but think about when you're at work, and they're like, oh, we just set up this admin panel, and like, you know, here's a password, or whatever. What if that admin panel ends up on the internet? You don't want to be the person who's using the password password. You're not gonna feel good when your security team comes to you and says, by the way, someone just logged in with your account,
37:22
and your password was password. It's not a good time. Okay. People always ask about resources. I know people are asking Mike. He probably actually knows better, but if you're totally new to web vulnerabilities, check out the OWASP top 10. It is a good list.
37:40
It's very good reference. If you're looking for like, what should I do, as opposed to what should I not do, there's a new OWASP top 10 of proactive security controls, which sounds very formal, but actually the documentation, it's very good to go through, and it tells you things like, think about who you trust, and protect stuff, and encrypt stuff.
38:02
It's just kind of like a good checklist to go through. If you're looking for hands-on, trying stuff out, the last two are actually from Invisium, but RailsGo is an OWASP project. It's like a purposely vulnerable Rails application, but it also gives you hints of like,
38:21
maybe you should try this or that, and if you really want to, it'll walk you through things, so it's a good resource. Then, also Invisium has these SecCasts, which you do have to sign up for, but they're free, and they're a pretty good resource for Rails security, and security in general, both on like, sort of defending against things,
38:41
and also trying to hack into stuff. All right, okay, so I made this slide. So like, I believe almost everyone at this conference is packing stickers to give away, so if you would like one of these three, I have them with me.
39:02
After the next talk, we're gonna have a security birds of a feather. I don't know where, does anyone know where those are? Say that, oh, the lunchroom? Okay, so, okay, great. So it's in the lunchroom, zone A, right after the next talk, so if you wanna come and talk to us
39:22
about more of this stuff. And if you live in the San Francisco Bay area, well, not if you live there, but if your company lives there, feel free to contact me if you want me to come and talk at your company. I'm happy to do that, and this is where you can find me on the internet. Thank you.
39:48
Yeah, so the question is, aren't those bug bounty payouts kind of low? And there's like, I can talk forever about bug bounties, because it's a hard thing.
40:02
Like, what are things worth? And I mean, yeah, maybe you think it's low, maybe they think it's high. You have to also consider, like, what's their budget for bug bounties? Of course, Facebook has a ton of money, so. And yeah, I mean, the guy, the other guy that did the Instagram thing,
40:22
his whole thing was like, they should have paid me like a million dollars for this. So yeah, it's tough, honestly, because I've been a part of a couple bug bounty programs on the receiving side, and it's very hard to think through, like, what's this worth? How much do we pay? How does it compare to other things that we've seen?
40:42
And I mean, the thing is, well, this could destroy our business, like, can you really go to your finance department and be like, we'd like to pay them like half a million dollars. Like, no one's gonna go for that, right? Even if it could have wiped out their whole business. Yeah, so the question is, where do you put your secrets? Because someone has to actually use them at some point.
41:03
I mean, there are products that will do it for you. Essentially, you want to store them somewhere and make sure that only the servers that actually need certain keys get those keys. That's basically the best you can do.
41:20
And then, you know, you protect that store of keys. And the nice thing, though, is if you automate all that, then you can rotate them really easily, which is nice. But yeah, you basically just, you know, you gotta put them somewhere, and then make sure they're encrypted there, and then make sure they only go to the boxes that need them, and that access to that,
41:41
you know, like, you don't want someone using the Rails CVE that Mike mentioned to read those files, if you can help it. Yeah, so the question is, even when you're doing it that way, like, how do you securely transfer them between servers? I mean, I gotta say, like, at some point, you reach a point where you're like, okay, like, it's safe enough, you know?
42:03
Because really, the main thing is them sitting on servers where they shouldn't be, or being too widely available. You don't want everyone in your company to have access to the main keys. Of course, when you are transferring them, I mean, you could just use SCP or something, and you'd have keyless,
42:22
I mean, you'd be using SSH keys on the servers, yeah. Or, I mean, if you want, you can encrypt them, and send them over SSH, and decrypt them on the box, I mean, you know, but then you have, like you said, the next level, like, well, but then we have to share the key to decrypt it, and, yeah.
42:41
Like I said, there are, like, kinda commercial solutions. There are also open source solutions, actually, you can look into, but, yeah. Honestly, it's just a hard problem, and I think you just have to get to one where you're like, this is not our weakest point anymore. There's a question over here, I thought? No?
43:00
Okay, all right, well, thank you very much. Thank you.