>>Without further adieu ‑‑ ‑‑ near and dear to our security information hearts. Point and sales systems. Here to talk about it today is gentleman Nir Valtman. >> Hi. Glad to be here today >> I'm sorry. Are you a new speaker? Oh excellent. I just didn't want them to get too much in to it. >> Okay. Guys. It'll be fun. >> wait wait wait. (Laughing) I've been doing this all day. (Laughing) love for the new speaker! (Applause.) >> I'm Russian by the way. So doesn't really matter. (Laughing) . >> That's all we have time for, thanks everybody for coming. DEF CON is cancelled. (Laughing) . >> You have the bottle? >> We're not leaving the bottle! >> Okay. So umm, I'm Nir and I'm going to speak to the point of sales. I do a introduction and then I'll get into the the details. So first of all, that's the thing when I say to all the people what I do. Well obviously I'm not the Batman here. Actually, I'm working as a enterprise security architect, solving a lot of problems in the retail like business. But actually I do only for these guys. I had a refew researchers about this this and at least open source two. But I'm here today to speak about the last year research that I've done and a lot of, and the result of meeting with a lot of start up companies and enterprises in order to protect point of sales. So before we begin, I just want to show you that the view of why point of sales is so targeted. So today when we want to buy credit cards, there's still something for a dollar. And I saw that it's really easy to find credit cards and get them with pay low prices. But when we want to get little bit more information, we can get full dumps. Full dumps like this is something it's stolen from POS. Different from other scenarios where like Ecommerce or M commerce web sites. Then they're ‑‑ you store fans which is the card numbers and the expiration date. So here we have a little bit more information. And we will compare a little bit about what should be attacked more. You'll see that although E commerce is pretty easy to try to attack this vector, point of sales have the same things, but also the full dumps. The full dumps by the way, it's Track 2 data. And sometimes it can also contain the pin number. So umm, before getting to the security stuff, I just want to talk about what is point of sale because some reason, we just think about these things. Which is, this is the point of sale, but this is only for the retail stores. The simple assumptions about point of sales in the retail store is that it can be stolen or at least it can be tampered. Is these ones. Fuel pumps. Fuel pumps ‑‑ fuel pumps, well they're public. It's pretty easy to tamper them as they do ATMs. They just put skimming devices there. That's fine. It will work. But the next point of sale, is kind of the new point of sale. It's mobile POS or M POS. Umm, the ideal M POS is to shorten the queues from the retail stores. That means just for a queue busting. But the fact is that since it has no wires, it has card reader, can be replace easily. And also, I don't know if you see the right bottom corner, you see kind of scanner, it's a blue tooth scanner and contains all the risks of connecting bluetooth devices to the point of sale. But in fact, we're attacking point of sales. We shouldn't attack point of sales. This picture, by the way, means that there is no spoon. Because point of sales is not exactly the thing that you attack. The thing that's attack is the payment application. This is something that can be inserted as part of another deal ahead of POS. Or it could be an external exit load. And this should be the thing that should be attacked. Just to give you some over view about how it works in retail stores, so generally, we have a store and without the payment processor data center, obviously we have the store. We have head quarters try to simplify that a little bit. So if we go to store, we see that any POS has application. The POS manager identities like cashiers and tabs and loyalties. But it doesn't manage any data. The only thing it can manage is authorization code we get back from the processor. We also have the payment client which is the responsible for processing the credit card and all of this data somehow stored in the database or file system and obviously in the ram at that point in time. The PA Client communicates with point of production or pin pad or magnetic card reader. Then accesses the credit card numbers to a PA server. Honestly, there maybe point of sales server in other places, head quarters. But again, we simplify them. So we have a store server. Probably the store server is going out the processor. This payment server is umm credit cards, again, at least ‑‑ it's a specific point of time. And then it goes to the process. So let's just understand where our credit cards ‑‑ because when we speak about the risks and explaining how to exploit everything just need to understand where to exploit. So it will look at the data address, probably to see on file or on databases. And it's pretty weird 'cause why do we have to store credit cards in a database? So this is pretty simple. Let's say that the store is disconnected from the center or from the processor. So the store can sell? It can sell. It just stores the credit card somewhere. Can be in the database and the file system. So then we have the data in transit. And here, we understand the data in transit is not only something that we can ‑‑ or need to see through the Wireshark. Sometimes the data in transit is from the pin pad to the PA Client and it can be done through two two three and can be done through USB. So umm, that's the options. As for the memory, which is the most common way of attacks on point of sales, which have it in the ram. Just to connect it to the way we work today and we see retailers, let's say the retailers don't have only point of sales in the stores, they also have an E commerce. And if they have E commerce, probably, they have a PA server. A payment application server. So if they have a payment application server, they have an M commerce, D commerce, doesn't matter. But somewhere there are credit cards as well. So if we look at data address and probably be in the same place as for the data that it transits over the wire here. But then we have the data in memory. And we have it also in the presentation server. Which is pretty easy to have the data there. It's exploitable. The thing that we never thought about storing credit cards or at least looking for credit cards there is the mobile app. So the mobile app can also take credit cards. So there are ways to somehow remove this credit card from all this places and this can be done by just storing all the keys in a specific server, called token server is the concept. That means that this is pretty simple server. It contains the table. Credit cards. A token. And then when we pay, we just pay by token. We don't pay by credit card. And then it means the presentation server don’t need to have, actually, credit cards there, and application server neither. On the other hand when we have a wallet, somehow we need to register a credit card there. So when we do that, it is in the memory. So we don't have a solution for everything. But the system solved here for the PA server, no problem. So let's just understand something about what the retailers think when they deploy the point of sales. Okay. So the first thing ‑‑ yeah? No one cares really? PCI? Well it's a marketing thing. So the next thing is the fact that retailers actually deploy the point of sales on embedded device, it's windows embedded. So it doesn't mean that windows embedded is secure. >> (Inaudible). >> Yeah, it's not as bad as a regular windows seven, but it doesn't mean that it’s secure enough. And then, part of them tell that, well we have patches. We all know that no one cares about patches. Yeah. And you know what ‑‑ yeah. Do you know why the retailers are not vulnerable to Heartbleed? That's pretty easy. Because most of them don't have even SSL. (Laughing) yeah. So another assumption is that they're not connected to the internet. Well actually, they're not connected directly to the internet. They have the store. They have the head quarters. But somehow they need to go to the internet. How they have patches. Okay. So all of them connected to the internet, this is just a fact. Another fact is that retailers believe that the cashier can be hacker. So the cashier can be a hacker, but is his USB stick can be a hacker? Probably. And it happens. The next thing is is something pretty odd. I asked one of the retailers. Hey guys, do you log? How do you know you don't have fraud on the POS? And they told me, well we have cameras and we see if the cashier just gets the money from it. So we don't have fraud. We have physical security. No one cares. But these are only assumptions, in fact there are a few Achilles tendons in the recent environments. This the first one. Whoops. This is the one. The RAT. The fact is that on most retailers, they have a lot of sites. And it's really hard to put IT guy on each side that they, say more than one K sites. And then they just install the VNC. Okay. So it's also vulnerable. And again, this is a fact that most of the retailers can't handle. Another thing is, who can access the POS. Sometimes ‑‑ ‑‑ any user can log in to this machines. Actually they are. Another fact is that no one really knows how to harden the systems. So the point of sales run with local admin access control, so you don't have to manage permissions. I know that PCI requires managing permissions. But I’m Admin, who cares. So let's talk about the threats, because well, there are many threats on the point of sales. And we need to solve at least part of them. So the first threat with the low hanging fruit is the permissions on the point of sale. So like I said, if we had admin, that's good. But yet, if we don't have the the admin access and we have a regular user, we have specific permission to the application. So for instance, if we have a pin pad, probably will need to manage the permissions managing the driver. Okay. Another thing is permissions for the process. Do you know that if I run the process as a logged in user, it doesn't matter which process I run, I can read it. If I run a point of sale with a logged in user, I don't even need to exploit the operating system, I just need to run a memory scraper. It's pretty easy because I have the permission. Again, the file system access the point of sales write logs when there's write logs and we can change them. We can probably do fraud or sometimes be exposed to credit card numbers in the logs. That's a bug ‑‑ by the way, every retailer that you see that there, it's not by design. But somehow, all of them design this bug. So umm, another fact is that in many point of sales you'll have the database on the point of sales. Because sometimes we work in offline mode. So you have the database on the point of sales. So hey guys, you don't need to hack the point of sales. You can just take the MDF file. That's fine. Another threat is something pretty common on browsers. On browsers, when you go to a URL with HTTPS and then the Cert is not correct, probably you get a warning, right? The point of sale is not a browser. Point of sale can do whatever ‑‑ point of sale can't ignore HTTPS error if they have HTTPS. So I can actually put any certificate I want in the middle because no one cares if it's trusted and open SSL connection and it will work. As for the business perspective for paying through the point of sale or paying application, we actually have pretty long flow until we get authorization from the issuer. So we have the point of interaction which is the pin pad the pass the data to the application. And then processor and then issuer. But the main thing we must understand here that this part is pretty protected. And that means that pretty hard to exploit. I'm not saying impossible, I'm saying this is not a point of sale code. The left side is the side is the side we need to exploit ‑‑ but hay I'm just stealing data from the memory. I can consume sometimes and sometimes when I try to do some number scraping, it consumes ‑‑ I can say a lot. But it consumes the resources from the point of sale and jus to explain you how weak is the point of sale, it's pretty old. So if it's Pentium4, probably you see a memory scraper. You see the performance goes up. And it will be much difficulter to get the data because we just need to wait a lot of time until we get all the credits cards that we want. On the other hand, there is settlement flow. The settlement flow just stores the credit card somewhere. It can be on the POS it can be on the store server. It really depends on implementation. So again, we have something specific that is protected, but yet, the credit card stored somewhere. That means not in the memory, they're on a disk. So that's easy. I just need to go to the disk and get the file. That's fast by the way. This is pretty common on point of sale. I just want to do short demo to show how it works. Okay. So I have here windows machine. And I have here kind of application, very simple application a few of my students wrote and I was supervising it. This memory scraping does a single thing, goes to the process we choose and gets the memory from it and translate it to a string and then tried to find credit card based on our regular expression. So let's say that this is our POS. Pretty nice POS. I'll just set the pan for a moment there. Just like this. So now we'll go through the process. And with we'll choose credit cards. When you see that, you see that I just started the scan. Nothing's there. When I set the credit card ‑‑ woo, it worked. So when I set the credit card, I can see that in a moment, I get it. Memory scrapers don’t work in one iteration, we just need to open few threads and refresh them every five, ten, 30 seconds depends on how much credit cards we want to get. This is pretty simple to get the credit card. So I'm again going to the demo. This is user named Foo not admin. Now I can run again, the point of sale. And let's just try to get something from this one. So I just injected the DLL into the the point of sale. Used the Framework injection, i t's an open source frame work it allows DLL injection. I just added something to the point of sale try to scrape the memory from it. And then I get the log. Obviously, I can't see ‑‑ whoops. Didn't remove the old one. I need to close that one out. Right. So umm, now I have the memory on the point of sale and I just inject the DLL in there. Probably I won't see any credit cards there. Because there are no credit cards set here. Yet. Nothing. And again, if I’ll set the pan. I'll delete this one. Let's do it again. We have the credit card. So that’s just injecting the DLL and POS, just get through the process and do whatever we want. Getting access to the process. We'll do the questions later? So this is the number scraping, pretty easy things. Didn't take so long to do it because you'll find great process memory, well documented memory. So there are other things that can be done on the POS. We can actually steal credentials. It could be sheer credentials or user credentials. Because sometimes on retail stores, you just register to the store through E commerce and it's stored somewhere. And when you just buy something in the retail store, you have a loyalty card. And sometimes the card is connected to the user and password. So if you can just scrape something else from the memory, you'd probably able to get the login credentials. And then use them on other web sites. Another thing that you probably be able to do is to get the PII data on the point of sales. Because point of sales store PII data. Because we have, well, your address, telephone numbers, E mail sometimes. And this is data that costs a lot of money for the ones that steel it. Another thing, another fact on point of sales is that no one really deploys a thin point of sales. That means no one really deploys only to presentation layer, all of them deploy, a thick point of sales and that's the picture, because we didn't find a thick one. So umm, the fact is that all the business logic and the database, everything installed on the point of sale. There are retailers that are brave enough to duplicate their net work line and then if one net work line just fails, they have the other one. But that's pretty expensive. So just prefer to run it. The way we steaal the credit card, we have actually two scenario, probably you hear about one of them. The most common way to steal credit card is using online approach. That means that I'll find a way to get from the POS to the internet, somehow I'll find this way. It could be done through a proxy, another FTP server, et cetera. Somehow it'll get to the server in the end. But as I said, not all retailers actually have access or direct access to the internet and it's not really easy to do it on all times. So if I'm a cleaner, in a retail store, I could just take a USB. Put it somewhere on the PA server and run the memory scraping. But then the exfiltration of the data will be a specific ID of the USB key and I just connect it to the point of sale, then I'll get the credit card back to the storage. So this our two approaches. So I check the solutions of how retail to protect the point of sale. So I thought about, well, before going to solutions and trying to purchase software to protect point of sales, maybe we could code something. So I thought, maybe I could use ‑‑ by the way, something specific for dark net, but probably you'll see for any other managed code. I just thought maybe we can use another way to include the credit card in the memory. So there is a class, in .NET. It’s called stream class. Umm, this is a managed class of stream, yeah. It means that if it's managed, maybe we can bypass it. And again, we have another demo. Okay, so, we have another secure stream point of sale that's pretty cool. But then. Nothing to show because it can't show me the string. The secure string. As I said, it's a managed code. So if it's managed, we can just decrypt it. It's done easily by marshalling the secure string using .NET. No need of course for specific knowledge here, just go to the internet and get this five lines of code. And again, if we'll do the memory scraping here, and obviously, we can do the memory scraping and calling this function to the grid, probably we'll see here, the credit card. Yeah come on. So that's the idea of secure screen. I figured out that coding won’t here. And obviously I won't be able to change all the point of sale. So I thought about other solutions. And then I investigate, maybe firewall will help here. Well, it doesn't matter which firewall next next next next generation will it be. Because ‑‑ well most of the point of sale, they work with HTTP. So if they work with HTTP. It doesn't matter what next generation they have there. And even the antivirus malware and all the other curses we have, it won't work. 'Cause you know what, it's Pentium4. How we will we run the whole end point security solution on them? It's pretty hard. And then I thought, maybe there might be data loss prevention products will help. Because I really don't care if someone infect the point of sale. I care if someone exfiltrate it is data. Well, it's pretty easy. If I have a memory scraper off malware, I'll include the credit card. So I'll be the only one able to decrypt them. So if I encrypt it, how will data loss prevention on it can be done. But the last product is the product that's widely used on point of sale. A lot of companies just decide a white listing product. On the point of sale, well a wide listing product allows only specific products to run on operating system. That's great. Especially when using MD5. Because MD5 it's one built for collisions. And then when someone decides to use a little bit past ‑‑ let's say SHA256, it becomes problematic in terms of performance. So no one really can have this way ‑‑ way it work. So I just thought about the correct solution. Because there are any other incorrect solutions than I just thought it’s a long list. I I wanted to put on a side and tell you what did I think that can work for point of sale. So this approach is not technical at all. We just need to look for a little bit of intelligence before someone attacks us. So I just that you bring out really can explain why things are good. So this is a screen shot is something that we got from the forums. And I saw that someone just looks for info about how can I access the point of sale in the U.S. And what is the best malware I should use to get the data from it. That's pretty easy. Some recommend BlackPOS. On a lean nah. And then someone just gives the whole information because it's pretty easy. In a moment you can get the data. So if you infect the firmware of the terminal, you can do this that, track 2 data. And you have also another extended information that tells you okay from this specific POS terminal, maybe you won’t be able to get the PINs. That's enough information for the one that want to hack. Another scenario is selling the malicious firmware for veriphones point of sale. So they say that it leaks dumps through GPRS which is pretty nice because no firewalls. No next, next firewalls. So this is pretty nice. Just for $700, probably will get, we don't have investment pretty fast on that. Our next thing is kind of an offer. No one wants to sell this because it's too cheap, it's $700 at the point of sale. So the business offer is do grabbing sharing. Okay, the last one is kind of requesting for information. So umm, here's someone just tells ‑‑ hay guy I just couldn't find specific data I want and can get them. So this is a PIN pad that you really can get the pin from there. But hay, hackers have a lot of creativity. So they said, okay, we'll just thermal imaginer. They can see where they're actually press when you pay with a pin pad and that'll give the number. So this, this is just one option that can work. Other option, if it's only limited to the specific point of sale and specific application, I believe sand box can work. And I know this is something that bypassed a lot of times. This is something specific not a browser, something that runs only to the point of sale may work until now, it works. Umm, the next thing that you should know about point of sale is that point of sale are pretty static. Except the fact that patches install on the point of sale. Nothing else changes. So that means if you can do the profile for the whole point of sale system, or systems, then probably will be able to find abnormal behavior, then get the information about the one that already infected. The problem is that if we just deploy it after infection, then everyone is normal. Next thing is going to operating system anomaly detection. This is the 0day products. The nice thing here is things point of sale works with a lot of drivers, native drivers. We can actually inject a new one drivers as part of this product and it will be much easier to understand if someone tries to ‑‑ just an example change the driver of the pin pad and then get the numbers back. So that's pretty nice approach. But all of this, this is products you already heard about. So this is something that probably most of you have didn't hear about. Here ‑‑ I met with some other company, really cool. They say they do run time obfuscation. This is translated into my words, they do an operating system obfuscation. And that means that they can change all the windows system calls, they can change the names of all of them. for instance if we have a malware, this malware will probably try to open a socket or HTTP connection. Great. The name is incorrect. So the malware won't be able to work. And this obfuscation works specifically for each operating system. So that means that if one operating system is infected and they found the naming convention, it probably won't go to the other point of sale. Which is pretty cool. But yet, no harm to send. We have products. That's nice. But it's not all. Because sometimes we'll need to add a little bit security architecture to the point of sale. And most of it is IT problem. So the defense is window's hardening which is a common thing that should be done. It's not done, by the way. Most the retailers, at least the mid size doesn't, it doesn't work. Obviously, the ones that are enterprise level, they have certain hardening. The next thing is ‑‑ well actually part of the hardening let's say logs. Audit trail. Really? Thank you for. No one can enable just auditing. It won't work. When you go to the store and you have an item, you just hear the beep. That's your coke, yeah. And if you hear [beep], you don't have to pass the code and then wait a few seconds and then [beep]. It won't work. Next thing is on assembly signing, this is common for software. Probably, it can work for point of sale. And I know it could be also bypassed, but yes, this is another layer of security. And actually, the fact that we have point of sale that are deployed as peak point of sale. So we have the whole business logic on the point of sale. So probably we need to obfuscate the code to let hackers work a little bit harder. It doesn't mean they won't by pass it. Another thing I thought about, is ‑‑ well it's pretty simple solution. If you’ll just try to isolate the process with a few users. Let's say we have a simple user and another user. And if the process, the point of sale rises on the user, the log in user won't be able to read the process memory of the other user. And so that, again, I have a demo. So, I'm just closed here, there's everything, remove the log. Let me just run this point of sale with another user. I have another user named BAR, also a weak user. It will look at the process monitor, we'll be able to see that we have memory swiping process that runs as BAR and not FOO. And now let's try to inject it. Nothing. Won't work. Well, this is a simple injection, probably if you tried to do it a little bit harder. You may succeed. But the original way that the operating system works, is it does not allow any reading of process memory that runs with another user. So umm, generally, these aren't just solutions. So what's coming next? I don’t know I have a few ideas. Lets say you need to steal a POS. Who ‑‑ well raise your hand if you steal the point of sale the right one. No one steals the right one? Okay, not too much. Who wants to steal the left one? Everybody right? That's what I would do. Dang. So umm, probably if, it will be able to sale steal the models on the sale. Will be able to steal the business project on the model point of sale. That's nice, because we can steal it and bring it back in the morning. Next thing which is brief challenging is memory scraping for the model point of sale. Well, I suppose that we'll be able to see another skimming devices attached to the point of sale or maybe exploiting other ways to read the process memory. I know this is pretty hard on the iOS. But the Android, I think that maybe possible. Next thing is umm taking the assumption the cashier is actually hacker. Because I already saw a post of a cashier that just publishes something that says, okay guys, I can give you VNC access to point of sale, just pay me. Okay. Maybe probably someone got it. Next thing is rubber ducky. I suppose that even if point of sale will stop all the USB storage communications, rubber ducky can do nice things on the point of sale. I still didn't see it, but I believe it will be pretty easy to do it. So as a summary, everything we discussed and our session, so we have security through obsecurity. The retailers believe that the fact that we don't know about retail, probably we won't be able to hack it. That's a lie. Now they know that we know. It's simple to exploit the systems. And again, this is as a result of the assumptions we got from this session and it's really hard to protect the point of sale because as you probably understand there is no one solution. We need to take a little bit security architect. Or take a few products and then combine everything together to get a not bullet proof solution yet. But as for you guys, you're not a business, you're just the ones that buy on the point of sale, don't worry, you have insurance on your credit cards. So that's fine. Thank you and if you have any questions, that's the time. (Applause.) >> (Inaudible). >> That's the mic? >> (Inaudible). >> The memory scraping you showed up there was just the pan. But with POS systems, do most of the retail systems store pans or track one track two? >> So you're asking if they store pans? >> Yeah when it's pen pad based POS system, does the software save it as a pan? ..It depends on the implementation. Because pin pads, you have the driver, you can set the set for the pin pad to not encrypt anything, just pass all the data. Although if you have the direct connection to the issuer, probably you won't see it on the POS anyway. >> Okay thank you. >> Okay. >> For all these attacks out here, why no mention of Point to Point encryption or encryptioning the pan at the card swipe and let the OS out of the equation entirely? >> Well this is correct. I didn't mention implement encryption. I suppose you meant the Pooint to Point encryption. >> The P to P tokenization. >> So P to P is something that's specific for the pin pad and also for the payment application. So therefore it's not in the scope. But that is correct, point of points encryption on pin pads can actually work. Again, it's not the point of sale. >> All right thank you. >> I am very sad that your evaluation on the point of sale system doesn't seem like we have much as a consumer. What can be done retro actively? There are literally millions of systems. Target for example, what can Target do or Macy's do now instead of protect in the future? >> Well umm, let me understand if I understand it correctly. You ask how can the ‑‑ >> What can be applied to the existing systems to protect them? >> Well, today the way to protect point of sale systems is using white listing. But following few bridges you saw over the internet, they just looking for new approaches to protect the point of sale. So it starts with vendor security and then it goes to the operating system security. So they try to layer the approach. But there's no standardized solution following the type of the breeches that you hear. >> Thank you. >> So you say point to point encryption doesn't involve the point of sale, but that's sort of the point. If you have point to point through all the way through the payment application, through the processor, even the payment application at that point doesn't have it. >> Exactly. >> So why is that not covered? >> Well retailers, that's a good question by the way. Retailers, why shouldn't they just use point to point? Well it cost a lot of money. Assume that you have thousands of point of sale and pin pads. And your pin pads does not support point to point encryption. Because you need a hardware encryption. So you have point to point encryption on hardware, and it will cost you a few hundred millions or you have the software solution. What will you choose? >> Well yeah, target costs ‑‑ they figure it costs them about a $148 million to deal with the fall out, I think they could probably afford a few pin pads that handle point to point encryption. >> (Inaudible). >> Yeah. (Laughing) . >> This might be a naive question, but can you help me understand how chip and pin if it does show up if it does change the login. >> Chip and pin doesn't really help. That just means that, you just use pin pads to verify the chip in order to prevent fraud. But it doesn't mean you can't steal credit card. It's only an issue of the driver that's accessing the point of sale. >> I think the assumptions that you went with in the beginning are pretty crazy because I've personally exfiltrated tons of credit cards information from NCR terminals, and in no situations were those assumptions generally true. With small merchants, especially, they don't have IT shops, they don't have people who are in the know, what is NCR specifically doing to improve that, to force ‑‑ I mean listen, if they're retailers, they don't to do the right stuff. We all know that. We have to meet them half way right. What do you guys do at NCR to bridge that gap and thank you. >> So, as an NCR, as I said, there's a lot of product that probably need to engage together to protect the point of sale. So if it's not the point to point encryption solution, then we're just looking for business partners, and then recommending to our customers to use the specific products in order to protect their environment. 'Cause hey, we can protect everything. We can just protect our scope of the product of the vendor. Okay? >> Thank you. (Applause.) >> Okay. So all this is really good. I wanted to talk about one of the hacks I found for payment systems. You were talking about ‑‑ sorry my voice is lost. But you're talking about payment applications, in over the last year, I did a lot of payment testing of these APIs. And one thing I found out, that was easiest we hacked. If you could get on the same network segment of the point of sale system, you could forge the HTTP request response to trick the point of sale system into believing a purchase was successful, even if the card or payment never went through. So what I did, I had some retailers that hired me. I basically tricked the point of sale into printing out receipts saying I paid cash for whatever merchandise. And I would grab the merchandise off the self‑and take it to another cashier and say I want my money back. And then I give the cash in the logs on the point of sale system ‑‑ >> (off mic). Not that you actually did this right? >> No I was hired to do it. It was all legal. But it was interesting because on the point of sale system, everything checks out. All the logs look normal. The sale looks normal. Because the cashiers aren't trained to know. They just say, oh, the point of sale says this purchase was successful. Here's the receipt, here's the merchandise.  ‑‑ ‑‑ all good and anyways, so I thought it was interesting different angle than like anything you've talked about here. But it's something that made me think about is really securing the payment application the API in addition to the the system itself. The network segment and the other things we talked about. I just wanted to share that. >> Thanks for sharing. (Applause.)