Breaking the Back End Sometimes it's Just Bad Design
CC Attribution 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 purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Pickett, Gregory
Reverse engineering is critical to exploitation. However, going through the process of reverse engineering can often lead to a great deal more than just unco...
 So welcome to the last Track Speaker here for Track 3 for Friday. We've got Gregory Pickett going into breaking the back end. So here you go, Greg. All right. It's breaking the back end. DefCon 27. Got the number right. All right. Long day. My name is, as you said, Gregor Pickett with Hellfire Security. I'm here with the Cyber Security Operations Group. Our talk today, the transit system, our target. Reverse engineering, the target. The discoveries that I made, reverse engineering it. Then, of course, the exploit that I developed with what I discovered. And of course, the lessons to be learned. Always lessons without the lessons. What's the point? Right? All right. How is this different? We're sneaking into the station. We're hacking the terminals. We're not socially engineering anyone. We're hacking the wire to wireless network. It's not about the hardware. We're going to be breaking an encryption. We're going to be cloning Magstripes and NFC cards. This is about flaws and application logic. There is some cloning involved, but it is not the vulnerability exploited. Instead, we're using AppSec to attack a complex, multi-layered, real-world solution. Our target, the elevated train, is the Bangkok Mets transit system. It's the elevated train in Bangkok, Thailand. There's a great Bangkok area. I think at the time that I started this, 43 stations along two lines, but I believe there are more now and actually more being added as we speak. That transit system uses two different types of tickets. Store value card using NFC and then in all day pass in a single journey using a Magstripe. The Magstripe that we're going to look at. Those tickets have two Magstripes. There is a hole through one of the Magstripes and it is only 0.27 millimeters thick. Picture there. At the top is the single journey ticket. The bottom is the all day pass. You can get the mouse over there. You can see the little hole right there. You see how thin it is. You are not going to be opening up a catalog and ordering it. You aren't going to be able to go down to the store and ask for it. Of course, the first thing you're going to do is read it. The equipment there. Standard reader, writer, manufacturer in China before the tariff. So not quite as expensive as it could have been. Standards or raw read. It would take the data and then decode according to standards or just dump the data in a raw read. Errors are rare. It was able to handle that hole which I originally thought was a 1980 style copy protection. You are not familiar with that. They used to damage a sector on the disk. If you attempted to copy it, it would error out. And of course you couldn't copy it and pass on the copy to a friend. Turns out that hole is just to make sure that the ticket is properly lined. Turned up the right direction and facing the other direction. So it would go into the theater properly. And then it was reliable performance. If you are going to start analyzing any data, you want to make sure that the data is reliable otherwise you can't perform that analysis. It's not reliable. First thing you do is sit down in a lab and you attempt to decode this according to standards. Using the international organization for standardization. There's a lot there actually. But it boils down to six-bit and four-bit characteristics, some with parity and some without. I attempted to decode this both forwards and backwards. I am a perfectionist. Somewhat anti-retentive I think was the term they used to use. So I'm going over and over again to make sure that now there's a software not making a mistake but I'm not making a mistake. Because I did do it with the software and I'd also then would do it manually. So I finally decided after doing this again and again and again that it wasn't using the standards. And maybe it's not encoded at all. Maybe just raw data. So we'll see. So looking at the data. It's encrypted. There are sections that repeat. It's repeating. It's not encrypted. No parity checks. If you break up the bits, you calculate parity and then you check the ticket to see if it's represented that way there on the ticket. It's not, so no CRCs, LRCs and no timestamps. If you buy a ticket and you wait 10 seconds, nothing increments by 10. So I think after this we can say that it is just raw data. But what does that data mean? Well, that's the field work. You run that ticket through the system. You can vary the input each time. And then you're going to see how the data changes. It's going to use those changes to identify the meaning. Now before you do that analysis, you want to try to reduce your workload. Less work, you have to do the better. So I talked about duplication or duplicated sections. The yellow sections up there were essentially duplicated. You didn't need to look at them. You just dump them out. There are sections that had a utilitarian use. This data actually sits in zeros. It gives the ticket a chance to line it properly in the reader. So there's basically a delay with those zeros. Well, that's a start set. A function is a start set. It's a single bit saying data is now coming. So I don't really need to analyze that. I knew it just by looking at it. That's another benefit of going over the data again and again earlier is that you have some insights later on. The 7.826, which is the red, you can't see that probably very well. When I was buying tickets and taking a look at them, I would have one particular value for the single journey and then I have a different value for the all-day pass. So quite obvious at that point in time that that's a ticket type. This here, these two nipples there end up being 100 plus the ticket price. So all that jumped out. I mean, I don't really need to do any deeper analysis on that. That leaves me with four sections. This one here, this one here, this one here, and this one here. So that's a lot less work. Now each of these, of course, is different from ticket to ticket. It's important to note also that this here, and you probably can't tell that, but it's blue, that it actually changes as the ticket is used, as it goes through the system. All right, so after I observe those changes, this is what I found. Each ticket has a GUID associated with it and a location. Initially, it's in a dispenser and it's a GUID associated with its arrival there. When the ticket moves, the location is updated to a turn style. There it is. And a GUID associated with its arrival there. When the ticket moves, it also changes state. It goes from issued to used to collected. When you buy it, it comes out of that dispenser. It's in the issued state. You go ahead and use it to enter. It goes through the turn style. It's now in the use state. Then when you exit, it gets captured by the turn style and it's then in the collected state. There are also some handling rules. To enter, the ticket must have previously been in the collected state, meaning it was just sitting in a turn style somewhere, previously in the collected state, coming out of the dispenser now, currently in an issued state. That's what the object was, where it was, and where it is now, then of course you can use it to enter. To exit, the ticket now must be in the use state. So we're going to look to exploit the system. I'm going to cover briefly what we've learned so far, kind of summarize everything up. Talk about system safeguards that become evident as you examine the system. The assumptions that they must have had when putting it together to the safeguards. Then we'll talk about attacks against the assumptions and then of course, obviously this is why I'm here, there was an epic fail there. We don't have regular fails here at DefCon. We have epic fails. All right. So what we've learned so far, it's an object-based system. It's a physical object and a day-based object. I know this one because, well, primarily you go ahead and try to modify any of the data on the ticket and the little screen at the turn style says go to the office. It's like school. You do something wrong and you go to the office. Now I knew there was a database representation, a day-based object, because there was no integrity checking on that ticket. So they had to be an external reference and it's typically a database. And each of these objects, whether it's a physical object or a database object, has properties. There's identification. There's a type, a value, and a location. So they're actually rather different than most systems that are transaction based. This is more of an object-based. All right, so these objects also have states. Issued, used, collected, and a history. Now there's some system safeguards that become evident. Ticket composition and ticket design. There was mirrored physical object and a database object. There were handling rules. And there's a life cycle. It was only good for 24 hours, basically. And this ticket would be collected after you used it. There are assumptions. And using these particular safeguards is that no one, right, no one will be able to reproduce their ticket. And their system has the only valid objects. Handling rules will prevent concurrent use. I can't hand this to my buddy. I go through and then hand it back to someone. No one can do that. That was their assumption. Damage is limited to life cycle, right? So if somehow someone is able to bypass these safeguards, well, what damage could they do in 24 hours? And finally, after use, the ticket will be in their possession, right? You have it in your possession. Now you feel safe. Tax against those assumptions. First one, right? Acquire a suitable ticket. They say or they believe that they, no one else can make these tickets. Let's find out that's true. Capture a valid object. Bypass those handling rules and then extend the tax to increase the damage. Get beyond that 24-hour, it's probably a little shorter than that, window. It was indeed an epic fail there. I did find someone to make blank tickets. It took me a really long time. Most companies said you couldn't do it, but I was persistent. I also had Alibaba. Anyone out here ever use Alibaba? Yeah, it's great, right? And now I did copy a shit ton of the objects and I feel comfortable to say that here, shit ton. In the issued state. And I just found a flaw in the handling rules. What I found was the collected state found in a current life cycle, overrides all other states. So the object is always seen as recently collected. You run that original ticket through that recently collected gets stuck in there. So it doesn't matter if you have all these other tickets currently in use, it doesn't see that. It doesn't see that as a previous state. It doesn't see that there's concurrency going on. It just sees that one collected. It's stuck in there. And so any of these other copies you use out there, they're all valid. I'll demonstrate that. It's really simple. It's a very simple attack. You just have to look at it, but it's very effective. So in the normal circumstances, if there's concurrency, multiple tickets or copies being used, you attempt to use one of them. And it's just seen one in the used state. So now it sees it in the issued state and it says, no, that does not follow my handling rules. So none of the copies would work. But if you let it run through. Now try to just hand it back to your buddy, let it go all the way through. And every single copy then becomes valid. It doesn't see concurrency. You could have three tickets, four tickets, five tickets, all the same ones. It doesn't see that. It doesn't see that they're being used right now. It just sees that one I was previously collected and I'm now in issued. Go ahead and go through it. So one, two, three, five, 20. It doesn't matter. All these people go through with the same ticket. Of course, you can't just say this. You have to have some data that backs it up and I'll have a video here in just a second. So we have at the top there. This is all the same ticket. This is an original and two copies. Have all the same good coming out of the same dispenser and at the very same instant because it's the same ticket. So it's got the same good. And you can see it's actually used three separate times. It's very hard to make that outright. It's very small, but you can see that it's different. So we had the same ticket being used three separate times, three separate turnstiles. Actually, I believe in one instance, different station altogether with different goods. And same thing here for these all-day passes. It's actually the same all-day pass. It's used two separate times in two separate stations, entered with two separate turnstiles and two separate instances of the goods. And a video. I have to get it over there, though. I had to, it's only 20 minutes. Originally it was a 45-minute talk and there was a lot more about Thailand. This is where the research was done, obviously in Bangkok. They are currently, they were the time and they're currently still, can I get the button there, the country's run by a junta, military dictatorship. Guys with machine guns. No questions asked. You want to be arrested? Okay. Disappear. So I was a bit skittish. Do we have an air message? I can't really see that. Let me have a few minutes. Let me go and drag this back over here. We can't. All right, I don't know where to go. You guys know where this stuff's at? We're good on time, so, you know, we can make mistakes. It didn't bring it up. It just, we can't play it. It's not too bad because it's most, most of it's my feet. Yeah. Let me pause that. Yes, there's a lot of the ground in my feet. There we go. Great sandals, right? There we go. So yes, at the time this research was done, ooh, I forgot about the audio. Quinta is in charge, guys with machine guns. So I was a little worried I could be disappeared. As a frang, it's white man, white guy in Thai. Lots of privileges but no rights, which means that. And you combine that with Quinta, yeah, it's quite easy. It would be easy for them to make me disappear. You'll see that. There we go. There we go. As I said, that was mostly my feet because I was worried about being put in jail, disappeared. So I kept the phone by my side, as you can tell, and then of course when it was time, for the money shot I pulled it up and let it see that you guys could, anybody could see that it was not a genuine ticket, it was in fact a counterfeit. And you could run around with five of these, ten of these, twenty of these, the system would let all of them through at that point. Okay. So that was fun, right? But to turn this into an exploit, from an exploit to an attack, you have to have those blank tickets and you have to have a plan. Because we actually have one more safeguard, right? Get beyond that 24 hours. So I did find someone, as I said, to make these tickets. It took a long time, many, many months with vendors talking to them, trying to get them to understand what I wanted and then try to get them past the know we can't make it. So there were the tickets there. So the plan is by, did it pass? You copy that ticket and you're going to go ahead and use the original and put that in that state. And you have the copies to have fun. Now you can do that yourself, you can do that with your friend and your pastor, your monk, whatever, everyone can ride. But they're actually, it can turn into something more. You can go beyond just a couple of your friends there, you know, five of you. You can go ahead and instead make ten or twenty or a thousand. Next time you run the attack, it's about $3 for all they pass. You're buying your blanks for about $100. So $105 to do damage to the organization of about $5,000. That's the first thing, but they're all they pass. You get to keep the all they pass. It actually, you have to use it all day, right? We'll just keep it with you at the end of your day. Don't bring it back. End of your day a little early. And so you use it again the next day. So each self-sufficiency attack is about $3 to do about $5,000 for the damage. And you can, of course, do a whole lot more. If you're going, I hate to say cyber warfare, but if you're talking about undermining a country, start making their structure unreliable, reducing trust, right? Trust in these sorts of things that people rely on. You could just do this with a group of people. You could do this over years. You can very cheaply do $3 every day, right, to end up doing about $8 million for the damage. You can mind that with other operations. And you start looking at really hurting the company to the point where they can't make the repairs they need to make where the system becomes unreliable. You could do the opposite. You turn to a PR nightmare where you decide to go out with 10,000 things and start handing them out. And after that, of course, then the system shuts down because they have to stop everyone to take a look at their tickets. People can't get to work. It's a huge PR nightmare to do it that way. So a lot can be done with this. So yes, you can extend the tax beyond the 24-hour window. You can do a lot more damage than I think they realize you could do. So obviously, to avoid their fate, test all layers of the solution. Not just hard, despite the fact that that's your interaction, passing this ticket through a hardware system, it's not just hardware. It's software and they're somewhere. So you're going to have to, at some point in time, test for application solutions. And more importantly, check your assumptions. I suspect that many years ago, when this was first implemented, the assumptions were mostly true, mostly. But things have changed. And so you have to check. That's why I think, you know, good idea, right? Do PEN tests every single year. Do some sort of assessment every single year to make sure your assumptions are correct. Your assumptions are still valid. And then compensating and mitigating controls. I did this on and off because I spent a lot of time in Asia. I was doing this on and off for two years. All right? I think that if they were watching, if they had any sort of monitoring going on, they would have noticed. They would have found the problem. They would have resolved it. Since they didn't, they must not have done any sort of monitoring, any sort of oversight of their own enterprise, their own system, right? And it's a very bad, bad idea. Because we all know people eventually get in, so we have to be ready when they do. So it's obvious that they were not using compensating and mitigating controls. So it's important that we, as practitioners, recommend and do that so ourselves. Don't end up like them. And then links. There's lots of information that you can learn about from the hardware. I use the standards involved in, I don't think I have any, but I do. So the hardware involved, the different talks prior to this, that section also got cut with different talks, other ways to looking at the transit systems and attack them. There is information about our friends at the BTS, right? And I say it's important to look at these sorts of things because this actually was what I got today from, so he's a Magstrup. Lots of places are losing Magstrup. So learn about it. Look at other Magstrips that are out there. This came from, does anyone recognize it? Monorail, right? I want to know what this is on this, right? I want to look at this, right? I'm tempted to start carting my Magstrup reader everywhere I go just because you've done it by seeing all these things. There's lots of opportunities. That is the talk. That's everything. I think I met over earlier, right? Yeah. Thank you.
 So welcome to the last Track Speaker here for Track 3 for Friday.  We've got Gregory Pickett going into breaking the back end.  So here you go, Greg.  All right.  It's breaking the back end.  DefCon 27.  Got the number right.  All right.  Long day.  My name is, as you said, Gregor Pickett with Hellfire Security.  I'm here with the Cyber Security Operations Group.  Our talk today, the transit system, our target.  Reverse engineering, the target.  The discoveries that I made, reverse engineering it.  Then, of course, the exploit that I developed with what I discovered.  And of course, the lessons to be learned.  Always lessons without the lessons.  What's the point?  Right?  All right.  How is this different?  We're sneaking into the station.  We're hacking the terminals.  We're not socially engineering anyone.  We're hacking the wire to wireless network.  It's not about the hardware.  We're going to be breaking an encryption.  We're going to be cloning Magstripes and NFC cards.  This is about flaws and application logic.  There is some cloning involved, but it is not the vulnerability exploited.  Instead, we're using AppSec to attack a complex, multi-layered, real-world solution.  Our target, the elevated train, is the Bangkok Mets transit system.  It's the elevated train in Bangkok, Thailand.  There's a great Bangkok area.  I think at the time that I started this, 43 stations along two lines, but I believe there  are more now and actually more being added as we speak.  That transit system uses two different types of tickets.  Store value card using NFC and then in all day pass in a single journey using a Magstripe.  The Magstripe that we're going to look at.  Those tickets have two Magstripes.  There is a hole through one of the Magstripes and it is only 0.27 millimeters thick.  Picture there.  At the top is the single journey ticket.  The bottom is the all day pass.  You can get the mouse over there.  You can see the little hole right there.  You see how thin it is.  You are not going to be opening up a catalog and ordering it.  You aren't going to be able to go down to the store and ask for it.  Of course, the first thing you're going to do is read it.  The equipment there.  Standard reader, writer, manufacturer in China before the tariff.  So not quite as expensive as it could have been.  Standards or raw read.  It would take the data and then decode according to standards or just dump the data in a raw  read.  Errors are rare.  It was able to handle that hole which I originally thought was a 1980 style copy protection.  You are not familiar with that.  They used to damage a sector on the disk.  If you attempted to copy it, it would error out.  And of course you couldn't copy it and pass on the copy to a friend.  Turns out that hole is just to make sure that the ticket is properly lined.  Turned up the right direction and facing the other direction.  So it would go into the theater properly.  And then it was reliable performance.  If you are going to start analyzing any data, you want to make sure that the data is reliable  otherwise you can't perform that analysis.  It's not reliable.  First thing you do is sit down in a lab and you attempt to decode this according to standards.  Using the international organization for standardization.  There's a lot there actually.  But it boils down to six-bit and four-bit characteristics, some with parity and some without.  I attempted to decode this both forwards and backwards.  I am a perfectionist.  Somewhat anti-retentive I think was the term they used to use.  So I'm going over and over again to make sure that now there's a software not making a  mistake but I'm not making a mistake.  Because I did do it with the software and I'd also then would do it manually.  So I finally decided after doing this again and again and again that it wasn't using the  standards.  And maybe it's not encoded at all.  Maybe just raw data.  So we'll see.  So looking at the data.  It's encrypted.  There are sections that repeat.  It's repeating.  It's not encrypted.  No parity checks.  If you break up the bits, you calculate parity and then you check the ticket to see if it's  represented that way there on the ticket.  It's not, so no CRCs, LRCs and no timestamps.  If you buy a ticket and you wait 10 seconds, nothing increments by 10.  So I think after this we can say that it is just raw data.  But what does that data mean?  Well, that's the field work.  You run that ticket through the system.  You can vary the input each time.  And then you're going to see how the data changes.  It's going to use those changes to identify the meaning.  Now before you do that analysis, you want to try to reduce your workload.  Less work, you have to do the better.  So I talked about duplication or duplicated sections.  The yellow sections up there were essentially duplicated.  You didn't need to look at them.  You just dump them out.  There are sections that had a utilitarian use.  This data actually sits in zeros.  It gives the ticket a chance to line it properly in the reader.  So there's basically a delay with those zeros.  Well, that's a start set.  A function is a start set.  It's a single bit saying data is now coming.  So I don't really need to analyze that.  I knew it just by looking at it.  That's another benefit of going over the data again and again earlier is that you have some  insights later on.  The 7.826, which is the red, you can't see that probably very well.  When I was buying tickets and taking a look at them, I would have one particular value  for the single journey and then I have a different value for the all-day pass.  So quite obvious at that point in time that that's a ticket type.  This here, these two nipples there end up being 100 plus the ticket price.  So all that jumped out.  I mean, I don't really need to do any deeper analysis on that.  That leaves me with four sections.  This one here, this one here, this one here, and this one here.  So that's a lot less work.  Now each of these, of course, is different from ticket to ticket.  It's important to note also that this here, and you probably can't tell that, but it's  blue, that it actually changes as the ticket is used, as it goes through the system.  All right, so after I observe those changes, this is what I found.  Each ticket has a GUID associated with it and a location.  Initially, it's in a dispenser and it's a GUID associated with its arrival there.  When the ticket moves, the location is updated to a turn style.  There it is.  And a GUID associated with its arrival there.  When the ticket moves, it also changes state.  It goes from issued to used to collected.  When you buy it, it comes out of that dispenser.  It's in the issued state.  You go ahead and use it to enter.  It goes through the turn style.  It's now in the use state.  Then when you exit, it gets captured by the turn style and it's then in the collected  state.  There are also some handling rules.  To enter, the ticket must have previously been in the collected state, meaning it was  just sitting in a turn style somewhere, previously in the collected state, coming out of the  dispenser now, currently in an issued state.  That's what the object was, where it was, and where it is now, then of course you can  use it to enter.  To exit, the ticket now must be in the use state.  So we're going to look to exploit the system.  I'm going to cover briefly what we've learned so far, kind of summarize everything up.  Talk about system safeguards that become evident as you examine the system.  The assumptions that they must have had when putting it together to the safeguards.  Then we'll talk about attacks against the assumptions and then of course, obviously this is why I'm  here, there was an epic fail there.  We don't have regular fails here at DefCon.  We have epic fails.  All right.  So what we've learned so far, it's an object-based system.  It's a physical object and a day-based object.  I know this one because, well, primarily you go ahead and try to modify any of the data  on the ticket and the little screen at the turn style says go to the office.  It's like school.  You do something wrong and you go to the office.  Now I knew there was a database representation, a day-based object, because there was no integrity  checking on that ticket.  So they had to be an external reference and it's typically a database.  And each of these objects, whether it's a physical object or a database object, has  properties.  There's identification.  There's a type, a value, and a location.  So they're actually rather different than most systems that are transaction based.  This is more of an object-based.  All right, so these objects also have states.  Issued, used, collected, and a history.  Now there's some system safeguards that become evident.  Ticket composition and ticket design.  There was mirrored physical object and a database object.  There were handling rules.  And there's a life cycle.  It was only good for 24 hours, basically.  And this ticket would be collected after you used it.  There are assumptions.  And using these particular safeguards is that no one, right, no one will be able to reproduce  their ticket.  And their system has the only valid objects.  Handling rules will prevent concurrent use.  I can't hand this to my buddy.  I go through and then hand it back to someone.  No one can do that.  That was their assumption.  Damage is limited to life cycle, right?  So if somehow someone is able to bypass these safeguards, well, what damage could they do  in 24 hours?  And finally, after use, the ticket will be in their possession, right?  You have it in your possession.  Now you feel safe.  Tax against those assumptions.  First one, right?  Acquire a suitable ticket.  They say or they believe that they, no one else can make these tickets.  Let's find out that's true.  Capture a valid object.  Bypass those handling rules and then extend the tax to increase the damage.  Get beyond that 24-hour, it's probably a little shorter than that, window.  It was indeed an epic fail there.  I did find someone to make blank tickets.  It took me a really long time.  Most companies said you couldn't do it, but I was persistent.  I also had Alibaba.  Anyone out here ever use Alibaba?  Yeah, it's great, right?  And now I did copy a shit ton of the objects and I feel comfortable to say that here, shit  ton.  In the issued state.  And I just found a flaw in the handling rules.  What I found was the collected state found in a current life cycle, overrides all other  states.  So the object is always seen as recently collected.  You run that original ticket through that recently collected gets stuck in there.  So it doesn't matter if you have all these other tickets currently in use, it doesn't  see that.  It doesn't see that as a previous state.  It doesn't see that there's concurrency going on.  It just sees that one collected.  It's stuck in there.  And so any of these other copies you use out there, they're all valid.  I'll demonstrate that.  It's really simple.  It's a very simple attack.  You just have to look at it, but it's very effective.  So in the normal circumstances, if there's concurrency, multiple tickets or copies being  used, you attempt to use one of them.  And it's just seen one in the used state.  So now it sees it in the issued state and it says, no, that does not follow my handling  rules.  So none of the copies would work.  But if you let it run through.  Now try to just hand it back to your buddy, let it go all the way through.  And every single copy then becomes valid.  It doesn't see concurrency.  You could have three tickets, four tickets, five tickets, all the same ones.  It doesn't see that.  It doesn't see that they're being used right now.  It just sees that one I was previously collected and I'm now in issued.  Go ahead and go through it.  So one, two, three, five, 20.  It doesn't matter.  All these people go through with the same ticket.  Of course, you can't just say this.  You have to have some data that backs it up and I'll have a video here in just a second.  So we have at the top there.  This is all the same ticket.  This is an original and two copies.  Have all the same good coming out of the same dispenser and at the very same instant because  it's the same ticket.  So it's got the same good.  And you can see it's actually used three separate times.  It's very hard to make that outright.  It's very small, but you can see that it's different.  So we had the same ticket being used three separate times, three separate turnstiles.  Actually, I believe in one instance, different station altogether with different goods.  And same thing here for these all-day passes.  It's actually the same all-day pass.  It's used two separate times in two separate stations, entered with two separate turnstiles  and two separate instances of the goods.  And a video.  I have to get it over there, though.  I had to, it's only 20 minutes.  Originally it was a 45-minute talk and there was a lot more about Thailand.  This is where the research was done, obviously in Bangkok.  They are currently, they were the time and they're currently still, can I get the button  there, the country's run by a junta, military dictatorship.  Guys with machine guns.  No questions asked.  You want to be arrested?  Okay.  Disappear.  So I was a bit skittish.  Do we have an air message?  I can't really see that.  Let me have a few minutes.  Let me go and drag this back over here.  We can't.  All right, I don't know where to go.  You guys know where this stuff's at?  We're good on time, so, you know, we can make mistakes.  It didn't bring it up.  It just, we can't play it.  It's not too bad because it's most, most of it's my feet.  Yeah.  Let me pause that.  Yes, there's a lot of the ground in my feet.  There we go.  Great sandals, right?  There we go.  So yes, at the time this research was done, ooh, I forgot about the audio.  Quinta is in charge, guys with machine guns.  So I was a little worried I could be disappeared.  As a frang, it's white man, white guy in Thai.  Lots of privileges but no rights, which means that.  And you combine that with Quinta, yeah, it's quite easy.  It would be easy for them to make me disappear.  You'll see that.  There we go.  There we go.  As I said, that was mostly my feet because I was worried about being put in jail, disappeared.  So I kept the phone by my side, as you can tell, and then of course when it was time,  for the money shot I pulled it up and let it see that you guys could, anybody could  see that it was not a genuine ticket, it was in fact a counterfeit.  And you could run around with five of these, ten of these, twenty of these, the system  would let all of them through at that point.  Okay.  So that was fun, right?  But to turn this into an exploit, from an exploit to an attack, you have to have those  blank tickets and you have to have a plan.  Because we actually have one more safeguard, right?  Get beyond that 24 hours.  So I did find someone, as I said, to make these tickets.  It took a long time, many, many months with vendors talking to them, trying to get them  to understand what I wanted and then try to get them past the know we can't make it.  So there were the tickets there.  So the plan is by, did it pass?  You copy that ticket and you're going to go ahead and use the original and put that  in that state.  And you have the copies to have fun.  Now you can do that yourself, you can do that with your friend and your pastor, your monk,  whatever, everyone can ride.  But they're actually, it can turn into something more.  You can go beyond just a couple of your friends there, you know, five of you.  You can go ahead and instead make ten or twenty or a thousand.  Next time you run the attack, it's about $3 for all they pass.  You're buying your blanks for about $100.  So $105 to do damage to the organization of about $5,000.  That's the first thing, but they're all they pass.  You get to keep the all they pass.  It actually, you have to use it all day, right?  We'll just keep it with you at the end of your day.  Don't bring it back.  End of your day a little early.  And so you use it again the next day.  So each self-sufficiency attack is about $3 to do about $5,000 for the damage.  And you can, of course, do a whole lot more.  If you're going, I hate to say cyber warfare, but if you're talking about undermining a country,  start making their structure unreliable, reducing trust, right?  Trust in these sorts of things that people rely on.  You could just do this with a group of people.  You could do this over years.  You can very cheaply do $3 every day, right, to end up doing about $8 million for the damage.  You can mind that with other operations.  And you start looking at really hurting the company to the point where they can't make  the repairs they need to make where the system becomes unreliable.  You could do the opposite.  You turn to a PR nightmare where you decide to go out with 10,000 things and start handing  them out.  And after that, of course, then the system shuts down because they have to stop everyone  to take a look at their tickets.  People can't get to work.  It's a huge PR nightmare to do it that way.  So a lot can be done with this.  So yes, you can extend the tax beyond the 24-hour window.  You can do a lot more damage than I think they realize you could do.  So obviously, to avoid their fate, test all layers of the solution.  Not just hard, despite the fact that that's your interaction, passing this ticket through  a hardware system, it's not just hardware.  It's software and they're somewhere.  So you're going to have to, at some point in time, test for application solutions.  And more importantly, check your assumptions.  I suspect that many years ago, when this was first implemented, the assumptions were mostly  true, mostly.  But things have changed.  And so you have to check.  That's why I think, you know, good idea, right?  Do PEN tests every single year.  Do some sort of assessment every single year to make sure your assumptions are correct.  Your assumptions are still valid.  And then compensating and mitigating controls.  I did this on and off because I spent a lot of time in Asia.  I was doing this on and off for two years.  All right?  I think that if they were watching, if they had any sort of monitoring going on, they  would have noticed.  They would have found the problem.  They would have resolved it.  Since they didn't, they must not have done any sort of monitoring, any sort of oversight  of their own enterprise, their own system, right?  And it's a very bad, bad idea.  Because we all know people eventually get in, so we have to be ready when they do.  So it's obvious that they were not using compensating and mitigating controls.  So it's important that we, as practitioners, recommend and do that so ourselves.  Don't end up like them.  And then links.  There's lots of information that you can learn about from the hardware.  I use the standards involved in, I don't think I have any, but I do.  So the hardware involved, the different talks prior to this, that section also got cut with  different talks, other ways to looking at the transit systems and attack them.  There is information about our friends at the BTS, right?  And I say it's important to look at these sorts of things because this actually was  what I got today from, so he's a Magstrup.  Lots of places are losing Magstrup.  So learn about it.  Look at other Magstrips that are out there.  This came from, does anyone recognize it?  Monorail, right?  I want to know what this is on this, right?  I want to look at this, right?  I'm tempted to start carting my Magstrup reader everywhere I go just because you've done  it by seeing all these things.  There's lots of opportunities.  That is the talk.  That's everything.  I think I met over earlier, right?  Yeah.  Thank you.
Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_0_251.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_252_1547.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_1548_11543.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_11544_12875.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_12876_14159.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_14160_18947.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_18948_22379.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_22380_22607.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_22608_25415.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_25416_25643.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_25644_26087.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_26088_26339.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_26340_26459.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_26460_26543.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_26544_26699.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_26700_26831.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_26832_32063.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_32064_34055.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_34056_34715.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_34716_34883.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_34884_35675.png Gregory_Pickett_-_Breaking_the_Back_End_Sometimes__z5cXNLeTn9U_35676_35847.png