Category Archives: InfoSec

Chip and Pin Verification Flawed … Will you be out of pocket?

Steven J. Murdoch, Saar Drimer, Ross Anderson, Mike Bond from Cambridge University have been researching chip and pin that we are all familiar with in this country on our payment cards. EMV (Europay, Mastercard and Visa came up with the standard) is the protocol used with payment cards worldwide, but they are most common in europe.

EMV is used to secures the payment card transactions by authenticating the person and card. This is done with a combination of the authorisation codes, digital signature, and of course then the pin entry. Chip and Pin was introduced to reduce fraud with card payments, that previously relied on the signature on the reverse of the card for person verification.

They work of the guys at Cambridge University have identified and documented a flaw in the EMV process that allows a fraudster to make payments with a genuine card, without knowing the correct pin.

This obviously is a significant issue, and is not something specific to the issuing bank, but the card process in general.

Cambridge University have released a paper with information on their study, and it makes for an interesting read. Obviously it does not disclose the specifics, but I think a few of us will have some idea of how this functions.

Document Conslusion Extract:
In this paper we have shown how the PIN verification feature of the EMV protocol is flawed. A lack of authentication on the PIN verification response, coupled with an ambiguity in the encoding of the result of cardholder verification as included in the TVR, allows an attacker with a simple man in-the-middle to use a card without knowing the correct PIN. This attack can be used to make fraudulent purchases on a stolen card. We have demonstrated that the live banking network is vulnerable by successfully placing a transaction using the wrong PIN. The records indeed falsely show that the PIN was verified successfully, and the money was actually withdrawn from an account. Attacks such as this could help explain the many cases in which a card has supposedly been used with the PIN, despite the customer being adamant that they have not divulged it. So far, banks have refused to refund such victims, because they assert that a card cannot be used without the correct PIN; this paper shows that their claim is false. We have discussed how this protocol flaw has remained undetected, due to the public specifications being not only complex, but also failing to specify security-critical details.
Finally, we have described one way in which this vulnerability may be fixed by issuer banks, while maintaining backwards compatibility with existing systems. However, it is clear that the EMV framework is seriously flawed. Rather than leaving its member banks to patch each successive vulnerability, the EMV consortium should start planning a redesign and an orderly migration to the next version. In the meantime, the EMV protocol should be considered broken.

Obviously this is not good, it is however concerning to read that people who fall victim to these sort of attack are not being reimbursed for their loss.

These guys have done some good interesting work, I just hope the industry takes this on board and makes the appropriate improvements.

In this paper we have shown how the PIN verification feature
of the EMV protocol is flawed. A lack of authentication
on the PIN verification response, coupled with an ambiguity
in the encoding of the result of cardholder verification as
included in the TVR, allows an attacker with a simple manin-
the-middle to use a card without knowing the correct PIN.
This attack can be used to make fraudulent purchases on
a stolen card. We have demonstrated that the live banking
network is vulnerable by successfully placing a transaction
using the wrong PIN. The records indeed falsely show
that the PIN was verified successfully, and the money was
actually withdrawn from an account.
Attacks such as this could help explain the many cases in
which a card has supposedly been used with the PIN, despite
the customer being adamant that they have not divulged it.
So far, banks have refused to refund such victims, because
they assert that a card cannot be used without the correct
PIN; this paper shows that their claim is false.
We have discussed how this protocol flaw has remained
undetected, due to the public specifications being not only
complex, but also failing to specify security-critical details.
Finally, we have described one way in which this vulnerability
may be fixed by issuer banks, while maintaining
backwards compatibility with existing systems. However, it
is clear that the EMV framework is seriously flawed. Rather
than leaving its member banks to patch each successive
vulnerability, the EMV consortium should start planning a
redesign and an orderly migration to the next version. In the

Social Engineer Toolkit – Website Attack How To

You are hopefully familiar with the Social Engineer Website, if not then your missing out to go visit.

They have put together excellent information on the art of social engineering, and have formed an awesome framework with input from many great people. I am sure alot of people have read it, as I have heard people in the industry talking about it, but I dont often hear people talk about the Social Engineering Tools.

In particular I am talking about SET (Social Engineer Toolkit).

The Social-Engineering Toolkit (SET) is a python-driven suite of custom tools which solely focuses on attacking the human element of penetration testing. It’s main purpose is to augment and simulate social-engineering attacks and allow the tester to effectively test how a targeted attack may succeed. Currently SET has two main methods of attack, one is utilizing Metasploit[1] payloads and Java-based attacks by setting up a malicious website that ultimately delivers your payload. The second method is through file-format bugs and e-mail phishing. The second method supports your own open-mail relay, a customized sendmail open-relay, or Gmail integration to deliver your payloads through e-mail. The goal of SET is to bring awareness to the often forgotten attack vector of social-engineering.

I have heard good things about the tool, and ReL1K (David Kennedy) has done a cracking job of putting a nice tool together.

So if your running a Linux distro and you want the tool, you can get it by simply fetching it “svn co http://svn.thepentest.com/social_engineering_toolkit“. For this basic demo I am using Backtrack 4 Final, so its already good to go. SET has various options, and can be configured in various ways. If this post is popular I will put something together to show this. However this post is just to demonstrate a basic function, and to show how well it works, and how simple it is to use, so that others are encouraged to give it a try.

So this is the situation. We are going to replicate a website, in this case I am going to use Twitter as an example, we then will use some social engineering techniques (not demonstrated) to encourage our target to visit a site / ip we have setup, and then we are done. There is spear phishing capabilities in the SET which will obviously provide a more automated attack vector, but for this demo we will assume its done manually, or verbally influenced / encouraged.

So we are in our chosen Linux distro, connected to the Internet / Network, and we make sure we have an IP address assigned. I am demonstrating this in my virtual lab with a BT4 Final Box and XP Sp3. I have also tested this same method on a physical BT4 box and a W7 box, with the same results.

So I assign an IP via DHCP.

Then we navigate to our folder that SET is installed to. In my case its /pentest/exploit/SET/

Next its always good practice to make sure everything is up to date. ReL1K is an updating machine, so it pays to check 🙂 So we simply type ./update_set and its confirmed I am good to go. You can also update within the SET tool, and as metasploit is also used here, its worth making sure you are all up to date there also.

Now its time to get down to business and kick of SET. We simply type ./set and away she goes.

As we can see SET has a few options at its disposal. We are going to take a look at the Website Attack Vectors, so we want option 2.

Again more options are available. Because we are lazy we will let SET do the hard work and clone and setup a fake website. So again option 2.

We now need to select our attack vector. I know my lab machines are fully patched, so a browser exploit will most likely not be successful. So we go with option 1 and a Java Applet Attack method. Then remember we said we shall clone Twitter, so we input www.twitter.com also.

Its now time to get our payload selected. I am a fan of reverse TCP meterpreter, so time for option 2 again.

Now we have the fun of encoding our payload to bypass AV. Shikata ga nai is an excellent encoder, but now with have the multi encoding option, I have found in my tests it can be more successful at bypassing the AV. So you guessed it, option 15 please 🙂 We will also need to define our listener port, so we will go within something creative. 4321

The encoding mojo does its thing.

We are asked if we want to create a Linux / OSX payload, but we dont need this here. So no thanks. The tool then goes ahead and sets up our fake site, and gets our listener up and running.

So now we have cloned a site, defined a payload, encoded it for AV bypassing and setup a web server for our cloned site. Simple huh. So now we are ready and waiting. So now we just need someone to go to our cloned site.

So I convince myself 🙂 It would be a good idea to go to Twitter on a strange IP.
So we enter the IP of our SET hosting machine, and oh look its Twitter. Damn I need to install some Java stuff (I believe this can be customised for a better convincer, remember we are doing basics here 🙂 It involves some more work and configuration.)

So we say yes, and assuming the AV bypass does its thing, we can see a session is created, and we are directed to the real Twitter site.

We connect to our session, and voila we have shell. The games begin.

So there we have it,  a doddle right. A great job has been done on this tool to make it effective and childsplay to use. I think it has a place as part of a pentest engagement, but also an effective awareness tool in anyones organisation to demonstrate how these things happen in reality.

It is of course worth mentioning, that not all AV’s can be bypassed by all encoded payloads. In my testing I found that I was able to bypass Avast, but Microsoft Security Essentials was picking this attack up. I didn’t mess about to much with different encoding variations, but you get the idea.

To demonstrate this to hopefully some better effect, I uploaded the file to Virus Total for analysis and you can see the results below. Less than half of the AV’s used can make the detection.

File java.exe received on 2010.03.02 20:51:30 (UTC)
Antivirus Version Last Update Result
a-squared 4.5.0.50 2010.03.02 Trojan.Win32.Rozena!IK
AhnLab-V3 5.0.0.2 2010.03.02
AntiVir 8.2.1.180 2010.03.02
Antiy-AVL 2.0.3.7 2010.03.02
Authentium 5.2.0.5 2010.03.02 W32/Rozena.A.gen!Eldorado
Avast 4.8.1351.0 2010.03.02
Avast5 5.0.332.0 2010.03.02
AVG 9.0.0.730 2010.03.02
BitDefender 7.2 2010.03.02 Gen:Trojan.Heur.TP.cqW@bG50SGgi
CAT-QuickHeal 10.00 2010.03.02
ClamAV 0.96.0.0-git 2010.03.02
Comodo 4091 2010.02.28
DrWeb 5.0.1.12222 2010.03.02 Trojan.Packed.447
eSafe 7.0.17.0 2010.03.02
eTrust-Vet 35.2.7335 2010.03.02
F-Prot 4.5.1.85 2010.03.02 W32/Rozena.A.gen!Eldorado
F-Secure 9.0.15370.0 2010.03.02 Gen:Trojan.Heur.TP.cqW@bG50SGgi
Fortinet 4.0.14.0 2010.02.28
GData 19 2010.03.02 Gen:Trojan.Heur.TP.cqW@bG50SGgi
Ikarus T3.1.1.80.0 2010.03.02 Trojan.Win32.Rozena
Jiangmin 13.0.900 2010.03.02
K7AntiVirus 7.10.987 2010.03.02
Kaspersky 7.0.0.125 2010.03.02
McAfee 5908 2010.03.02 Downloader-CCK
McAfee+Artemis 5908 2010.03.02 Downloader-CCK
McAfee-GW-Edition 6.8.5 2010.03.02 Heuristic.LooksLike.Trojan.Rozena.H
Microsoft 1.5502 2010.03.02 Trojan:Win32/Swrort.A
NOD32 4910 2010.03.02 a variant of Win32/Rozena.AB
Norman 6.04.08 2010.03.02
nProtect 2009.1.8.0 2010.03.02
Panda 10.0.2.2 2010.03.02
PCTools 7.0.3.5 2010.03.02
Prevx 3.0 2010.03.02
Rising 22.37.01.04 2010.03.02
Sophos 4.50.0 2010.03.02
Sunbelt 5729 2010.03.02
Symantec 20091.2.0.41 2010.03.02 Suspicious.Insight
TheHacker 6.5.1.7.218 2010.03.02
TrendMicro 9.120.0.1004 2010.03.02
VBA32 3.12.12.2 2010.03.02
ViRobot 2010.3.2.2208 2010.03.02
VirusBuster 5.0.27.0 2010.03.02

Microsoft Browser Choice Screen for European Users.. Coming to a screen near you!

So we know its been on the cards for a while, and now its happened. What am I on about, the Browser Choice Screen for XP, Vista and W7 users in Europe.

Microsoft ships its OS with Internet Explorer, and some people are not happy about this, so things need to change. The answer is a selection screen so users can choose from a selection of other browsers easily.

So if you keep your machine up to date your going to see this High Priority Update (KB976002).

Once this update has been applied and you reboot your machine and you open your beloved Internet Explorer (assuming its your current default browser) you get taken to http://www.browserchoice.eu/BrowserChoice/browserchoice_en.htm where you get presented with various options of browsers to install and use. Its not clear to me how this will be displayed on all users machines, so this is just my experiance.

The browsers up for grab are – Avant, Chrome, Firefox, Flock, Green Browser, Internet Explorer, K-meleon, Maxthon, Opera, Safari, Sleipnir, Slim.

Personally I dont think this is going to make a great deal of difference. Most people who are tech savy will be using another browser if it suits them, and those that are not will most likely stick with what they know given the choice.

Time will tell in the future, once more stats come out in the next few months.

Security Essentials 2010 is not good for your computers health.

Most of you who visit my blog on a regular basis will be familiar with Microsoft Security Essentials, its Microsoft’s free AV & Malware scanner and its not half bad.

Well now there is another version… Security Essentials 2010. Its not so much about cleaning up your system, its more about the screwing up your computer and charging you for the privilege. Its the usual scamware type software we have seen before on the AV front, but this one seems to be rather successful with such a similar name to Microsoft’s offering.

Below are some screen shots of the scamware, and the real Security Essentials offering to help you tell the difference. Remember, if its asking you to pay, then step away.

The real Microsoft Security Essentials:

Fake Security Essentials 2010:

If you have been unlucky enough to install this scamware, then you may notice you are unable to visit any of the common legitimate AV software vendors to help clear up your system, as well as other popular sites that you may visit. I would recommend you use another computer to download a free AV solution like Microsoft Security Essentials or Avast and then install on your computer to clean it up.

So for now, remember if its to good to be true, it usually is.

Security Bloggers Meet Up, proposed 27th April near Earls Court London

Security Bloggers Meet Up Website.

If you going to be in the Earls Court London area on the 27th April, and your a security blogger, then the Security Bloggers Meet Up is going to be the place to be.

An excellent time was had by all last year around the same time as RSA, and I hope this event to be as good if not better.

So if your interested, check out the site and follow as this progresses and register your interest.

Hopefully see you there.

Information Commissioners View on using Personal data for system testing

Following on from my recent post on “Doing the right thing when testing with production data“, I was discussing my frustation with a colleage at work and they told me to take a look at a copy of the the “Data Protection: Guidelines for the Use of Personal Data in System Testing” document. We had an old copy, and this is a statement from the ICO, in 2003 I believe. There is an updated 2009 version, but I dont have access to this, so I am unable to comment. Either way its a useful snip it to share with everyone.

The Information Commissioner’s view
The ICO advises that the use of personal data for system testing should be avoided. Where there is no practical alternative to using ‘live’ data for this purpose,
systems administrators should develop alternative methods of carrying out system testing. Should the Information Commissioner receive a complaint about
the use of personal data for system testing, his first question to the data controller would be to ask why no alternative to the use of ‘live’ data had been found.
Key risks in system testing There are a number of general risks that exist whenever system testing is undertaken using live data and/or a live environment.

These are as follows:
• unauthorized access to data;
• unauthorized disclosure of data;
• intentional corruption of data;
• unintentional corruption of data;
• compromise of source system data where appropriate;
• loss of data;
• inadequacy of data;
• objections from customers.

There will of course also be sector-specific risks peculiar to each individual business, each type of business and each particular system.
Before commencing any system testing, it is advisable for the data controller to undertake a risk assessment identifying the nature of the risks that apply, their
possible impact and planned handling strategies.

A cautionary tale
The view is sometimes expressed that system testing poses no real data protection problem, as it takes place all the time with little apparent detriment
to individuals. The following case study, which is based on a true complaint received by the Information Commissioner’s Office, shows that the use of ‘live’
data to test systems can indeed cause very real problems for individuals. A pupil was away from home at boarding school. The pupil’s parents received a
letter from the local hospital informing them that their daughter had been involved in a road accident. In fact, there had been no accident, but the hospital
had been using live patient data to test a system for sending out letters to patients.