"Hackin" ATMs isn't magic ...

Over the past few weeks, not a day passed without a news outlet or an AV vendor coming up with another post or article on ATM hacking. Today was no different.

Network World published an elaborate article that drew the attention to a "mysterious" DLL (msxfs.dll) that allowed the "hackers" to interact with the ATM's pin pad.

Analyzing the code, we started wondering how the malware author knows which pin pad service name to provide to the API so that the program is able to interact with the pin pad device,” the F-Secure researchers said in a blog post, noting that Microsoft doesn’t provide any official documentation for this library’s functions. “It’s a valid question because the pin pad service name used in the code is quite unique and it is very unlikely one can figure out the service name without documentation.

Now allow me to bring us down from the lala wonderland of AV blog posts.

First things first: Microsoft does not provide any official documentation for this library's functions ... because it is not a Microsoft library. The library is a result from the CEN Workshop on eXtensions for Financial Services (WS/XFS).

The fundamental aims of the XFS Workshop are to promote a clear and unambiguous specification for both service providers and application developers. This has been achieved to date by sub groups working electronically and quarterly meetings. 

You can find their website here : http://www.cen.eu/work/areas/ict/ebusiness/pages/ws-xfs.aspx

On it you will find both the documentation of the API as well as the MSI package to install msxfs.dll on your system. Granted that most ATM vendors will integrate this into their product, it's not hard to analyze the DLL itself ... if you want to (I'm not gonna do it here for you, magazines have ads to sell and AV vendors have products to sell so I'll give them the opportunity to do just that).

Now, there is indeed little documentation available for this version of the API beyond what you need as a programmer but there is more for the Java version. To be found here : http://www.cen.eu/work/areas/ICT/eBusiness/Pages/WS-J-XFS.aspx.

The latest version of the documentation for the "base architecture" (2009has some interesting paragraphs that you can ponder on from a security point of view, specifically under point 2.17:

The access control for the device (i.e. the authorization to access a specific function in the J/XFS API) has to be controlled by the calling application and the network software. In the current CWA 12345 no support for login and user rights administration is supported. Also, it may be desirable to encrypt all data which is send over the LAN between the workstations and the server, as well as between the peer-workstations sharing a device using J/XFS. 

This is, however, also not a task defined in the CWA 12345. It is rather left to the TCP/IP installation and add-on security products to ensure that the data transfer is secure. We assume that a solution to this is or will be available for use without the necessity to change the J/XFS structure. One possible option here would be to use RMI over SSL. 

TL;DR : the main API allowing ANY application running on a box connected to an ATM machine provides NO authentication, authorization and encryption. Rather, it offloads that responsibility to the "TCP/IP installation and add-on security products".

Maybe this post can help us narrow down where the work to protect our ATMs should start and maybe ... we don't need to do weird searches on Baidu to understand what we're looking at.

Cheers,
Wim

PS : Oh, instead of vendor-specific programming guides, maybe the Kaspersky guys want to look at the official Pin Keypad Device Interface ... it's not that hard of a read once you found it ;-)

3 years flew by ... looking back and looking forward

[Note that I am speaking for myself and not for the (ISC)2 Board of Directors or (ISC)2 as an organization. I believe that 3 years after being elected, it is my responsibility to tell you what we have done and what we have achieved. Feel free to ask questions in the comments or on twitter (@wimremes). While I am restricted in what I can say, I will definitely try to answer as many questions as possible. Again, this is my personal perception and opinion.]

It's a bit more than 3 years ago that I decided to run a petition to be added to the (ISC)2 Board of Directors election slate. It's a bit more than 3 years ago that more than 500 members supported that petition and allowed me to be elected that same year. After effectively joining the board in January 2012, I went to work. After all, more than 500 members supported me on a platform of change and I was eager to follow through on that.

Today it is time to look back and see what we have done. I can't stress enough how important the "we" is in this endeavor. It isn't just me, it is me as part of a team of 13 board members. It is "we", as (ISC)2 is an organization with more than 100 employees across the globe. It is "we", as (ISC)2 has more than 100,000 members today. But it is me that made a commitment to you when I launched my petition. And it is me that owes you some feedback and reflection.

It was no secret that I joined the (ISC)2 board on a platform of change. All joking aside, it isn't easy to walk into a boardroom with a "here I am, let's change things!" attitude. I didn't do that. My first task was to understand what the board did, what the organization did and how I could help to make that better, taking into account that platform and the continuous feedback from (ISC)2 members around the globe. Today I look back and I see that I moved from being that "rogue element" to getting elected as Chairperson of the board earlier this year. This, to me, confirms that I've managed to build the bridge between the opposing voices (including my own) that supported my petition and all other walks of life and opinions within the organization and the membership. It's an incredible honor to me to lead the board and I can't be more proud of the team we are currently working with.

Since I joined the board, we truly have come a long way. We have built on what was already in the works and worked diligently to do even more. To me it started with ratifying our new member-focused strategy in April 2012. Since then, (ISC)2 has further engaged with it's membership and the security community.

A first example is found in the (ISC)2 chapters. Varying in size between more than 4000 members (South Korea) and less than 15 members (Ethiopia) they have become a platform where members (and non-members) can exchange experience and knowledge. Maybe more importantly, they have become an important source of feedback for the organization and the board. They allow us to better understand the needs of our membership and their regional intricacies. Empowering our regional offices in The UK, Hong Kong and China has, in my opinion, resulted in a better regional integration and an ability to adapt to the needs and differences.

A second example is found in the CPE opportunities. (ISC)2 has worked with several non-profit events and conferences to enable them to submit CPEs for attending members. Where it was mostly up to the member to submit CPEs manually and only large and commercial events would auto-submit, there are now Security B-Sides events that auto-submit CPEs. I believe this brings more diversity into the CPE opportunities. Additionally, we have worked with different organizations to offer even more CPE opportunities to our members. One such example, which is near and dear to my heart, is BugCrowd. If an (ISC)2 member becomes a member of BugCrowd, they will get CPEs for every bug they submit through the BugCrowd Bug Bounties. While still in an early stage, I think this is a prime example of where we are going with CPE opportunities.

A third example comes in the form of community outreach. I fondly remember taking part of the (ISC)2 team to their first 44Cafe (hat tip to Steve Lord and his amazing crew) and DC4420 (DEFCON London chapter) meeting in April 2012. Since then the organization has supported B-Sides events and other community efforts around the globe. Being there and keeping a finger on the pulse of the community once again is an incredibly valuable source of information for the organization and for the board. This too allowed us to better understand the membership and the community.

Then come our credentials. (ISC)2 has diligently worked to review and keep their credentials up to date. This will be very clear in 2015 when the reviewed versions of the CISSP and SCCP are launched. At the same time, we have launched the HCISPP (healthcare) credential and the CCFP (Forensics). The latter being the first credential that is rolled out regionally as local laws are elementary to the practice. Are we done yet? No! Are we on the right track? I certainly believe so.

Lastly I must talk about the (ISC)2 Foundation, which is effectively a seperate 501c3 organization. The Foundation grants scholarships globally to students who are focusing on information security. With the scholarships alone, we have allowed people who would otherwise not be able to fund it themselves, pursue their dream and join the information security workforce. On the same token, The Foundation allows our members to give back to their communities and society through the Safe and Secure Online (SSO) program. This program provides learning materials to teach children, teachers and parents about online security and safe use of social networks. This is possible through the donations and effort of individuals and the support of bigger organizations. You can find out more about the Foundation here : https://www.isc2cares.org/Default.aspx.

Now obviously I will be up for re-election come December. I wouldn't be more grateful if I'm allowed to continue the work we have done in the past 3 years and I'd welcome your support to make that happen. I truly believe that (ISC)2 is well-positioned to keep going on its current momentum. While the subtle tweaks on the underlying machinery are difficult to quantify and their effect only visible further down the path, I am convinced that this organization is going nowhere but up.

I come to realize that I could easily write a book about the past 3 years of being involved with this organization. I can only hope it would be the first chapter of an even longer book.

Cheers,
Wim

Can we stop losing?

To whomever this may concern,

This is a personal post in so much that I need to clear out that I am not speaking for my employer or any other organization that I may be affiliated with. It is also personal on a level where I will not go into discussions in comments, on twitter or any other forum than face to face meetings. However, I think it is important enough to put this out there.

I have lost acquaintances, colleagues, friends. I have not lost them because of fate. I have lost them for stupid reasons. I have lost peers for things that I, we, could have prevented or at least I think I, we, could have. I am DONE with losing people I love for the wrong reasons. I hope WE are done with losing people for the wrong reasons.

My experience with losing started at a rather young age. I was working at my first employer when we were all gathered in a meeting room when we came in on a fateful morning. Some of us were sure that they were going to be fired, some of us were excited because maybe we would get a raise. Nobody was prepared to hear that one of our colleagues has lost his life when he crashed his car against a lighting pole very early in the morning. I was shocked, not surprised. A few weeks prior to his death we had been on the road for an engagement in a remote part of the country. While I was driving, this guy started to roll a joint and it was his clear intention to light it. As I was the lead on this engagement I told him not to but he laughed at me and lit it nonetheless. I kindly asked him to put it out or I would have to remove him from the car. He obviously thought it was funny enough, until I stopped the car and told him to get out. After he got out I returned to the office, told my boss what hat happened and somebody went to pick him up. He wasn't fired, just reprimanded. To this day I believe I did the right thing. It's obvious that a joint didn't kill this person, not enough persons being available to him to guide him about his substance abuse did. I'm also pretty sure that it wasn't just weed. It doesn't really matter WHAT it was, I lost a friend and an awesome colleague.

We have lost enough people for stupid reasons. We have lost enough people because I, we, fail to notice subtle changes in behavior. We have lost people because they felt lost. I believe everybody has at least this one person they can think of right now and say "I wish he or she was still here. I wish I could've helped". I want this to stop.

Over the years I have also witnessed substance abuse in our community and the stupid things people do to "fit in". It doesn't get more pathetic than seeing a dude fake snorting a line of coke to make sure he remained "one of them". I've seen alcohol, weed, cocaine and heroin do things to people you wouldn't wish to your worst enemies. I've seen a lack of support and understanding do the same.

I'm the first to admit that I like to get my drink on. Damn, I got more than enough stories to fill a pretty funny book with. However, I can remember the times that I was absolutely and utterly shitfaced on one hand. In almost 22 years that I'm legally allowed to drink.

So, from here on going forward I won't stop being the guy that wants to have fun. But I will be that guy that asks if you are ok. I will also be that guy that takes you aside and says "I think you had enough". Fuck, I will probably ruin your night but only because I don't want to see you ruin your life. 

I will definitely be that guy that you can call 24/7/365 because I don't want to lose anymore. I hate losing, I want us all to win. 

The enemy within

I happened to find myself in the couch this evening. Somehow I managed to get hold of the remote control and leisurely zapped through the available channels (there's a crapload of them, unbelievable).   I don't think I was really paying attention until I heard someone speak Chinese. While rusty, my Chinese is good enough to understand a normal conversation so my interest peaked. 

The documentary I ended up watching was about the (actually very recent) history of how companies have mushroomed in the GuangDong province, especially in the ShenZhen area. Their business model has always been as simple as it was genius. With the availability of huge numbers of unskilled workers, these companies were able to deliver quality work at prices that were unparallelled. 

As rumor got out that money was to be made, even more workers travelled from the rural areas to make money. Or rather, to make a living. The money they made was used to support their families back home. Thousands of kilometers away. It was used to feed and, more importantly, educate their kids. And with that, something interesting happened. The next generation, still willing to work but more than ever aware of their value and empowered by an improved education, in their turn traveled to the south. They did not have a family back home and their interest was to make an income that supports their desires. As labor became more expensive, companies in the Guangdong province struggled to stay competitive (in the end they all do much of the same) and inventive entrepreneurs found a new Guangdong in Cambodja. Cheap labor, not many questions asked, willingness to work.

Now this doesn't really go anywhere specifically related to infosec but it hit me like a brick that the people featured in this documentary were not unlike you and me. They were normal people, with families, with responsibilities, with ambitions and with dreams. Whether you are in the US, in Europe, in Africa or in Asia doesn't really matter. As a human being (with some outliers) you want the best for yourself, for your family.

This is most probably the biggest problem I have today with the whole "ZOMG China is hacking us and stealing our sekritz"  movement (you know who you are Tao).

Over the past centuries various regimes across the world have passed blame for their failure to innovate on to larger or smaller populations. This has happened in Europe, Africa, Asia, ... It is not new and it has never worked. Many people have died there, often under gruelsome circumstances. 

The fact that companies, individuals and politicians engage in the culpabilization of more than 1/6th of the world population is -to me- a disgusting realization. While I'm sure that there is little doubt that Chinese entities have used hacking methods to gather intelligence and knowledge (or a competitive edge), I don't see a reason why the other players in this game have not done exactly the same. 

We have become our own worst enemies but instead of admitting it, we look for the next country that we agree to demonize.

It utterly sucks.

Caveat emptor 101

I try to read as much as I can. Whether it's articles, books, journals, blogposts doesn't really matter. If it is infosec related I'll soak it up and if it's any good I'll probably blend it into a corpus of knowledge I've gathered over the year.

In the past half decade our industry and community has been finding out what it takes to be relevant. A lot of relevancy is to be customer focused. Note that "customer" does not always imply that you have a commercial relation with the group or person you categorize as that. Naming the entities you deliver for "customers" helps you realize that it is your sole obligation to deliver value instead of firewall rules or anti-virus or secure code.

Caveat emptor is a very old principle (that's why it's written in Latin right?) that boils down to "buyer beware". It basically means that whenever you are in a buying position, you have to be careful that the thing you are being sold is what you asked for and not something else or worse ... something incomplete.

With that said, I introduce you to this post on the HP Enterprise Security blog.

The post is constructed around the failed interpretation of an RFP process, that in the author's experience apparently goes a little something like this :

1. Customer issues RFP
2. Customer makes purchase decision
3. Customer buys just the widget
4. Customer attempts to implement the widget themselves
5. Customer fails to leverage full capability of widget, project falls to the wayside, considered a failure or abandoned.

From this he continues to pass blame for everything that goes wrong in corporate security programs to the customer ... obviously preparing us for the next ground-breaking offering that will wipe out all of our collective sins of the past. We shall be whole again.

I take issue with may things in that premise. I'll try to address them seperately.

1. This RFP process is overly simplified for the purpose of your post. It disregards the role that both vendors and integrators/resellers play in forming the opinion of a customer, often shoving their concerns under the rug with an extra discount or a shiny presentation. 
2. It's easy to put blame on the customer and their "buying" behaviour. In various roles at various organisations in the past I have spent time on all sides of the table in RFP processes. I've written them, I've answered them and I've evaluated them. If there is one thing vendors/resellers can do it is not jumping on any opportunity for the sole monetary benefit it will get them. Honesty goes a long way, even in business. 
3. If you have any experience in running such projects at scale you will recognize the occurences where scope was suddenly interpreted differently because the reseller found out they would not deliver on time if the real scope needed to be covered. In this case it is often the customer that doesn't grasp what is happening to them and they're actively being ripped off. No worry, the project was a success and nobody noticed. 
4. Lastly there is the issue of knowledge transfer. I haven't seen a single RFP where knowledge transfer was not an item. The answers at the beginning of the process promise a unique approach enabling the customer resources to develop themselves into experts. The reality a few months later is bleak, knowledge transfer exists of a 2 page admin manual and a stock preso about the awesome features of widgetX. Box checked, project delivered, let's get drunk!

The post further elaborates on specific experience from the author. The first example (Project ADD) is an example of failure that is rooted rather in a failed project management approach than a failed infosec program approach. This is not something a "reboot of your infosec program" can necessarily fix.  

Now back to "caveat emptor". 

As old as it is, the warning still stands. If you are looking to buy a widget to protect your infrastructure or a consultancy service "to reboot your infosec program", be suspicious of the promises made. 

"Data Honesty" and why IOCs are not (yet)

In the past half decade I've been working in incident response and data analysis extensively, working on projects that helped monitor security-related data on very large networks and helping to building Incident Response capabilities that were empowered rather than paralyzed by that data. It is no secret that I have always been a big proponent of data sharing among peers to improve data quality and more importantly to build what I have started to dub "data honesty". A term I can only hope will find some level of adoption sooner than later.

"Data honesty" is, in its simplest form, the level of maturity where anybody with access to a dataset and the methodology used to derive information from said dataset will arrive at the same conclusions as you did. It is this level where you are confident to publish both your dataset and the methodology used.

There is no doubt that the Verizon Risk Team as a whole has pushed the envelope in this field for our industry. The work they have done in developing VERIS ("Vocabulary for Event Recording and Incident Sharing") is a tremendous effort that I feel our community has largely ignored. It helps to understand that the V in the acronym stood for Verizon in a previous incarnation in order to realize that this is exactly the reason why widespread adoption of VERIS among Incident Response service providers has not occurred. As with any standard, commercial organizations are only interested in the standard if there is an opportunity to OWN the standard (and thus an opportunity to exploit it for profit). It is, unfortunately, a problem that almost any standard in our industry has suffered from since forever.

All this has resulted in report after report based on, undoubtedly, real data but without any structured methodology. This doesn't mean the reports were constructed in bad faith but one always wonders how the data conveniently correlated towards a need for more services/product/... conveniently provided by the publisher of the report (or the one sponsoring it). 

All jokes aside, there has never been more interest in security-related data. To a point where industries are waiting for any data that can help make them informed risk decisions. The latest data points being thrown at us are 'Indicators of Compromise' or IOCs. VERIS covers IOCs here:http://www.veriscommunity.net/doku.php?id=iocs and frankly, I love them. They're little nuggets of information that, when related to properly analyzed incidents can turn an incident response effort upside down. But caveat emptor!

IOCs lose a lot of their value when not related to properly analyzed incidents. There probably lies their biggest weakness. Anybody can publish IOCs these days without the need to link them to any active (or terminated) targeted attack campaign and attribute them to "Wim Remes' bad-ass Belgian Hacking Team extra-ordinaire". It is no longer the thorough methodology that supports the credibility of the IOCs but the commercial power and (perceived) familiarity with the "threat du jour" of the publisher.

When respected researchers and entrepreneurs start calling for "IOC Wednesday" I would urge you to take a step back and look at VERIS first. If you can analyze and categorize your incidents based on the data YOU can gather, you won't need to wait for others to be compromised to protect yourself better. 

IOCs are, at this moment, not by definition "honest data" but you can use them to streamline the processes you build based on your own "honest data".

For those companies with a stake in Incident Response services, now is the time to set aside your egotistical reasons for not using VERIS in your analysis or reports. Any methodology will always have weaknesses but this is the one we have RIGHT NOW and for a flawed methodology, it's a pretty darn good starting point if you ask me. The RISK team deserves that credit and the industry deserves that standard.

2 million downloads and nobody cares ...

As I'm enjoying a little bit of holidays before I start my new job in 2013, I'm also having the privilege of setting up my new work machine. Some tools are must haves for anybody doing infosec work, one of them undoubtedly is 'The Social Engineering Toolkit' (SET) written by Dave Kennedy of TrustedSec.

Dave is awesome and not only for writing SET. This post is not intended to criticize Dave in any way, rather it is written to point out something I've noticed in this community for quite a while now. Everybody cheers when another free tool is released. Metasploit, SET, NMap, Wireshark, OllyDbg, ... you name it, we use it and we throw our hands in the air like we just don't ... seriously, we really don't care.

These tools are written by people, smart people who have limited bandwidth for these efforts. They spend time away from their families to give this community tools that we use to do our jobs ... the least we can do is give something back.

Now, I remember sitting in a talk by HD Moore in 2007 at FOSDEM, a conference in Brussels (Belgium) where he explained why he put so much effort in making sure that Metasploit worked on Windows. A lot of people had been commenting that pentesters shouldn't use Windows and enabling Metasploit on Windows wasn't that much of a priority. HD subscribed to another logic, if 90% of the computer using population couldn't run Metasploit, how then could it become more awesome than it already was? (It was something along those lines but maybe not literally, it's 5 years ago and HD already spoke at 500 words per minute...).

This brings me to today, where I'm setting up my new work machine, a MacBook Pro, and thus getting to the point where I check-out SET and go run "./setup.py install" only to be greeted by this message :

"Installer not finished for this type of Linux distro."

Now, we may not be the ones who invent and write the spiffy tools but if we have any sense of community we CAN be the ones who enable them to run (easily) on as many platforms as possible.

Python 2.7.2 is installed by default on OS X and so is easy_install. The modules required for SET are the following :

• pexpect
• beautifulsoup
• pycrypto
• pyopenssl
• pefile

The original setup.py file lists them under the names as they are known in aptitude so finding out those names was the hardest part of modding the setup.py script to work on Mac as well.

add the following elif to the script and it will smoothly install all dependencies:


elif os.path.isfile("/mach_kernel"):
            subprocess.Popen("easy_install pexpect beautifulsoup pycrypto pyopenssl pefile", shell=True).wait()

It uses "/mach_kernel" to identify the host as an OS X machine and then proceeds to install all dependencies using easy_install. If you paste the elif statement at line 35 of the existing script, you're done.

Update -- as I was saying...contribute:

The Grugq was nice enough to point out the platform module:

add the following line to the top of the script ( where all the other imports happen ) :

import platform

then modify my previous contribution to :


elif platform.system()==Darwin:
            subprocess.Popen("easy_install pexpect beautifulsoup pycrypto pyopenssl pefile", shell=True).wait()


Using a more standard setup.py would make life a little easier but I understand Dave for rolling his own.
End Update

Have fun with it and next time you find something that doesn't work as smoothly as you would expect and you have some time to fix it, do it yourself instead of shooting the developer an email.

Peace out.

P.S. : yes, the update was sent to Dave as well ... this post does not have the intention to document an update, it is meant to point out how all of us can work together to make things better,