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