Guest Post: End of Windows XP Support and the Zero Impact it has on ATM machines

I write to demystify the above subject matter. I’ve read (ooh yes I read a lot of geek stuff) enough articles from Kenyan bloggers and columnists as well as international media.

We all know that I’m neither the inventor of the ATM nor the inventor of applications both the ATM and banks run. But I can pride myself in having interacted with both the systems and the ATMs.Windows XP end of life has come to an end, but to both the geek and the layman, that does not mean that it has ceased running on our cobweb infested Pentium Twos and Threes; it barely means that Microsoft has ceased giving patches and critical updates to the Windows XP version.They say upto 95% of ATMs run on windows XP and any person who regularly uses an ATM must have at some point come across that familiar screen when XP is booting up or the legendary wallpaper.Well, I’ll neither dispute that ATMs can be compromised to dispense cash simply because it cannot be done nor because it’s possibility hasn’t been demonstrated but rather because of the following factors that come into play.

While Windows XP support has been discontinued, lets face it, most of the computers running this version of the Windows Operating system have never seen a single patch or update since the initial install. I can bet you that most users don’t even know that service pack 3 of Windows XP did exist. The same applies to the ATMs. Since NCR (NCR has the largest share of ATMs in operation worldwide) installed these machines on their respective sites, they’ve never been updated either with the necessary applications nor the Operating System updates. The best service most of these ATM have had is dusting and replacement of parts that wear out.

There are several cases where demonstrations have been done to show that ATMs can actually be compromised to dispense cash. One of the hacks was achieve by a standard sms via a tethered mobile phone and the other using USB sticks.

Well, I won’t delve into the heart of the two methods but I’ll just mention that they both require USB devices to be physically plugged into the ATM computer. Lets forget the world for a while and focus on Kenya. Of all the ATMs you know of, how many can you think of that reside in an area where they are not well secured such that you can break into them without being noticed? I know of one at Nakumatt Lifestyle owned my Pesapoint and which is located on a busy corridor full of high school kids ‘hanging out in the mall’. All the other ATMs are mostly located inside walls with only the customer- facing screen visible. 

How would you manage to insert a USB device (cable or disk) into the computers managing these machines? Your guess is as good as mine. The only way possible is through the use of bank staff and just to let you know there’s a principle called ‘Dual Control’ when it comes to banks. At least two people will operate the ATMs when it comes to maintenance and replenishment of cash meaning if one of them became compromised and agreed to defraud from the ATM, the other person would most probably not be in on it and would discover any foreign devices on the ATM.

Lets assume the two individuals above did actually participate in the theft which in more than one way is possible, the fraud would be detected in less than two days since most ATM reconciliations (yes, for the noob, everything that goes in or out of a bank account has to be counter checked by a human other than the one who made the entry after a specific period of time. They call them teller logs or transaction lists).Now imagine going through all this pain to steal in most cases less than a million shillings from an ATM? It will simply cost you less to learn and work on card skimming (Well not anymore since EMV is finally here.)

The final scenario I can think of is of a hacker attempting to attack the ATM by compromising the target bank’s network. Banks (even Kenyan banks) may not be the best in use of modern technology but you can rest assured that they've invested heavily or at least tried to invest heavily on security systems. So, if you think you can hack into an ATM to steal a few millions, why not hit the jackpot that is the core banking system of your target financial institution?I think you as the reader should be more worried of the Heart Bleed bug but than end of support for windows XP and the ATM saga!

But not everything will be negative, at least not for all of us. All this noise about end of support will generate enough sales for Microsoft and their regional partners.

------
John Macharia is a Systems Analyst with one of the banks and shares insights from a systems implementation point of view in various forums.

Aircraft Tracking with the USRP

Been a while since I posted. Just swamped with loads of stuff to do and maintaining my unix beard :-)

Anyway, I had promised to post about the above topic a while back. Here is brief background. Recently security researcher Hugo Teso gave a presentation on how to "hijack planes" using a mobile phone. Well there was all manner of hue and cry from people alleging how misguided the research was and how impractical it is to actually achieve the hack.

What I know is you can track planes using reprogrammable hardware using the Realtek RTL2832U USB TV tuner which is super cheap or the expensive USRP ( yes i would know it is expensive).

The key however is to have a good antennae and appropriate height to receive stray ADS-B Mode S signals from the plane. Pipe the output of the script to a KML file (for Google Earth display) and viola!

You can track a plane as it lands or takes off, complete with the coordinates, speed etc. Ofcourse there are free services that receive this signals and pass them to an application either on a website or a phone but that's the fun in that?

Here is a snippet of my capture.

-ty

IEBC Bug: Expanding the scope

Picking up from where we left last time, the 'buggy code' in the IEBC vote tallying system seems to have gone the way of the dodo. No one is actively pursuing that angle anymore.
Nonetheless, let me put into perspective what the above 'hitch' could mean for our ICT landscape.

Kenya is well known for innovation in the mobile space. Most if not all banks are now running different mobile banking solutions which have among other benefits, make banking convenient. Since majority of the banks contract 3rd party vendors to execute their mobile banking strategies, the end customer has very little or no knowledge of what checks and balances have been employed by their bank. It is all a trust based on the fact that "since my bank always takes care of my finances, this solution shouldn't be any different." Banks will probably enforce their information security procedures (PCI/DSS or ISO 27001) to ensure the mobile banking platform meets the baseline requirements. If at all they exist anyway because I know just a handful of banks are ISO 27001 compliant. However, this leaves a gap in ensuring that the said bank also ensures the vendor also has a minimum baseline requirement to handle the customers data. This leaves every other vendor running off to develop and deploy their own solution based on their own understanding of what "security" is. The bank could also contract an external audit firm be for go live just to ensure that all loop holes are sealed. However this presents an interesting challenge. Locally, most audit firms come from a financial background and therefore perform systems audits based on templatized methodologies which are not exhaustive enough. Mobile banking hasn't been in the scene for a very long time so some of these audits barely look at the entirety of the ecosystem and the players involved and instead focuses on a few facets perceived to be risk factors. With this in mind, I know some banks which have paid dearly for failing to perform an exhaustive risk assessment prior to go live and interestingly enough, the compromises have all been internal.

To tie it all together, if the above system isn't open for scrutiny from a holistic risk approach, taking into consideration all the dynamics introduced by mobile commerce, then you can see how compounded the IEBC "multiply by 8" factor could cost financial institutions. It also paints a rather tainted picture of how Kenya's software development ethic is highly in question.

However, the Government hasn't turned a blind eye to this and after a successful launch of the National Cyber Security Master Plan
 http://www.cio.co.ke/news/main-stories/kenya-launches-national-cyber-security-strategy-and-master-plan I can comfortably say that standards in development methodologies will be harmonized.  The CBK also introduced stringent measures for banks
 http://www.centralbank.go.ke/index.php/news/245-issuance-of-revised-prudential-guidelines-and-risk-management-guidelines-for-banks which came to effect in January. This means that most software houses will have no choice but to adopt existing Information Security standards.

As I conclude, I seemingly have a rather skeptical feeling that banks will embrace the above standards because from my interaction with some of the key banks around, only 3-5 are receptive. This applies to the Internet banking frontier as well. I have performed closed disclosures to some banks and they simply brushed it aside probably citing falsified assessments or otherwise. However, others have been very receptive and I guess it is just a matter of time before we can see any substantive progress in that direction.

So the IEBC bug isn't new to the infosec scene. It just metamorphosed into a national scale butterfly.

-ty 

IEBC: Security Compromise or Poor Project Management discipline

I remember reading this article while in a hotel somewhere in the far east http://www.nation.co.ke/News/politics/IEBC-to-invite-hackers-to-invade-its-systems/-/1064/1449152/-/uko5x7z/-/index.html. I thought to myself, "Hmmm, this is interesting. Challenge accepted, maybe?"

This led me to ask a dozen questions on how prepared we are in running a system of national interest under such a short period of time. In light of what Kenya has experienced in terms of cyber security exposure within the last one year, I cringed at the bold assertion by Oswago "We are confident that our system is tamper-proof. However, sometime in November we will invite those who think they can hack into the system to do it. "

You don't make such a proclamation unless you are 100% +1 sure of what you are talking about. I have audited lots of systems and even after go live, I still have the nudge to continuously test and retest for any loop holes I may have missed. My deepest fear is being blind sided by that 0-day exploit, a stray misconfiguration which leads to compromise. Perhaps Mr Oswago knew something I didn't know; after all he is the CEO. However, I felt that was an ambitious remark and if they indeed would invite "hackers" I would be most humbled to give it a go at the system which would be used in our election.

Many months later, the invite hadn't been sent out. Constantly, I would visit the IEBC website just incase they posted the invite there. So incidentally a few months before the above "invite", IEBC had put out a job advertisement for very specific roles, found here http://www.kenyancareer.com/2012/03/latest-government-jobs-iebc.html

• Information Systems Auditor
• Operation Systems Auditor
• Compliance Risk Officer

Very specific roles in ensuring that a system of this nature is well audited and that every cog moves in sync with all other operational tasks. So question 1: Can the people who filled the above roles please stand up?

Now look at this link : http://elections.nation.co.ke/news/IEBC-invites-political-parties-to-test-results-kit/-/1631868/1688848/-/kxyja8/-/index.html

In slightly above 30 days to the general election, IEBC now invites "IT Experts" from the various parties to come and assess the system to their satisfaction. Here again not only dont we see a lapse in project management skills but also a clear indication that the system albeit having been tested, wasn't really pushed to it's breaking point. A paramount question is where is the evidence of any sign offs from the above "experts" of course assuming this was run with the project management discipline as we know it? Even more interesting, they commissioned the system for go-live having satisfactorily tested it. So where does the question of "server crashed due to load" come into play?

Let's move to the 20th-22nd Feb. I recall seeing a snippet in the Daily Nation regarding the IEBC having contracted an independent information security auditing firm to conduct one last audit of the system. In an interesting rejoinder to the interviewer I guess, IEBC preferred to keep the name of the firm and/or the auditor secret due to the nature of the task. Bear in mind this is just under 11 days to the polls. 

March 4th and the system is seemingly working flawlessly up until there was a slight glitch. Numbers stopped moving, the rain was hampering the transmission of feeds to the media houses, tension! In a presser held by the Hassan, chairman of the IEBC, he stated that yes there was a technical issue with  the server but they had resolved the issue. However, 3 days later, the chairman was on stage once again, admitting that there was indeed a bug in the system which was purportedly multiplying rejected votes by a factor of 8! How that line of code found it's way into the system is any ones guess. So let us take a step back. When was this line of code discovered? When was it introduced? Did they have an iron clad change management system which forbid anyone from accessing the production system? If the auditors called in on the between the 20th-23rd Feb did their job, were they so unqualified to miss a rogue line of code? Where are the audit results?

As you ponder on these facts, i'll be back with part two of how this affects both you and I in ways we cannot escape with real examples right here at home...

-ty

GSM FPGA boards for real time interception

Here are some photos of the new boards and it's chassis . Notice that it covers the 1800Mhz and 900Mhz bands.

Will be testing it in a few.

Happy New Year folks.
Got too lazy but I'm back with some even better news. Managed to acquire a more powerful FPGA board from National Instruments among other interesting boards. It is capable of a full GSM spectrum interception, both uplink and downlink.
The interesting bit about this acquisition is that it will enable me pursue GSM interception as I work on real time deciphering of A5/1 and A5/2 which are the de facto algorithms used by MNO's. The other challenge will involve getting GPU's which will enable real time decryption bearing in mind that currently the open source way of doing it using the 2TB Rainbow tables takes about a month or so...not very sure.

Nonetheless, this is an interesting step bearing in mind I haven't even blogged about the experimental stage using the USRP2.

Ill keep you posted on this development. Oh yes, post on airplane tracking using python and Google Earth + USRP2 coming up in the next few days.


Keep hacking..

-ty

Radio Frequency Exploitation using GNU Radio + USRP2: Part 2

Hi folks.
Welcome to part two of this topic.  Picking up from where we left from, we have our USRP + Gnuradio glued together neatly and so where do we go from here?

Well, like I had stated before, the potential for this sort of 'hackery' is incredible and today ill demonstrate just that.

There is no plug and play radio interceptors though some folks have been kind enough to make work easier. Gnuradio is ideally an SDK in itself with loads of libraries which assist one to develop their own fancy tools to play with the radio interface. Also of interest is the GNU Radio Companion which provides an environment to develop your own Flow Graphs and also Flow graph source code. It's pretty neat and I would recommend this site http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials for anyone who is starting off with SDR( Software Defined Radio).

GRC comes with examples of basic receivers and transmitters. These include a basic wide band FM receiver (wfm), tv receiver, narrow band FM receivers, etc. Again there are tonnes of material out there on how GNU Radio works coupled with the various sinks included. However, this guy  has some neat implementations which with a bit of tweaking makes signal process programming quite easy.
I borrowed some of his implementations and tweaked them to suite my environment especially for the WFM, NOAA and APT receivers. Please note ill just demo on reception since I dont possess a license to transmit. CCK will be hot on my heels so let's stick to what is publicly available.

This video will show you how with the right antennae and of course with allocated frequency bands well advertised on the CCK website I thought to myself why not? Besides, it simply goes to show that law enforcement communication isn't encrypted and it begs the question why it isn't. Besides, there exist HF encryption technologies to prevent such kind of interceptions like the Project 25(P25 or APCO-25) which is a standard that defines digital radio communication.

In a nutshell, the receiver used in the clip is an FM receiver coupled with the USRP communicating via UHD. Notice the FFT (Full Fourier Transform) and the peak hold indicating the top frequency range for the communication.

 These by the way are different police allotments; Traffic and General Police.

Have fun... see you in Part 3 where we shall look at Air Traffic interception.

-ty