In the last few days, many things have been called into question, chief among them, the Independent Electoral and Borders Commission’s (IEBC) network. Many experts thought that it had been hacked, a especially after a Database error was reported. The DB error was multiplying the rejected votes by  eight.

In these emotional cases, one party feels like they know better and would have offered better solutions and the other party wonders where these people were to offer solutions when the process began……the story goes on.

One of the main questions was whether the system underwent a penetration test, commonly known as a pentest, to determine whether it can be hacked. Te answer is yes…..it was pen tested and monitored. You can imagine my relief when an information security expert, who did the pen test, agreed to share findings and the process.

Here is the response I got, verbatim, I have not edited it……. My apologies if its too tech or too boring 🙂

“Last year IEBC reported that they wanted to test if their systems would be hacked, or penetrated into. Personally last year, I had a lot of issues to deal with, I wasn’t well and so I took up the task this January on the second week of the year 2013.

Having fast Internet in the house, the first objective was www.iebc.or.ke.

Like any other Pentester, I had to learn,which services the box was showing to the world,  and the first thing I realized the only port allowed to the world was port 80, not fully secured, cause I could see that it was  on a debian box.

See below

197.248.2.46:80 Apache/2.2.16 (Debian) ( Powered by PHP/5.3.3-7+squeeze14

with internal IP, 10.20.1.10

So the only thing an evil hacker would do here is to try DOS this apache, since the version is vulnerable to Remote Denial Of Server. But thats not for me, I wonna pentest, not break things for fun, like Anonymous Kenya tried to do during the Elections Week. By the way, that was really stupid, and it didn’t work!

So, I also noted that this webserver was not sitting in the same network, IEBC uses, its on a different WAN, suspected Safaricom due to the IP Address. I decided to drop this and adapt like any hacker would do. So the next thing was to look for other domains that had to do with iebc, and some interesting ones came up.

ftp.iebc.or.ke

mail.iebc.or.ke

webmail.iebc.or.ke

Now it was time to go further.

By now my target had become the mail server, since these others reflected to the domain from Safaricom. By this time I hadn’t picked the Google’s domain, vote.iebc,or.ke

So I started to focus on the mail box, and realized it was sitting in IEBC office, Anniversary Towers, Nairobi. Heck, yes, I was on the right track.

So the first thing was to know which floors, but with high security it was getting harder. Several social engineering attempts and I got near 16th floor and saw that the machines on the LAN were on Windows, and Symantec as AV.

(Am trying not go technical on this post, bear with me.)

So the first step was to get a VPS servers and upload a Malware client and prep  a Malware server, tested it on Virtual Machines at the comfort of my home for around two weeks, until i got the dropper working right. I needed to make sure I own atleast one workstation, then propagate my attack from there.

Am not going to bore you on how I got my malware into the IEBC internal network and I had a lot of time scanning and probing for services on this infrastructure, but I was in, and fully in change of the machine I had hacked into. Luckily this workstation I had got into wasn’t getting switched off at night, but I worked hard to make sure that in case the owner decides to reboot, my code would still connect back via port 443 to my VPS server in UK. A few days I was able to update my Malware server, and I was ready to test a reboot, and I ran it.

The connect-back came back just fine. This was tested during lunch hour around February, just before 14th.

Now, it was time to look for a more info, the amount of machines and infrastructure was overwhelming, but I had all the time in the world.

Below is an Internal Scan of  10.1.2.1-254 scan of SMB Service

10.1.2.2:445 is running Unix Samba 3.5.10-125.el6 (language: Unknown) (name:BVRFTP01) (domain:BVR)

10.1.2.3:445 is running Unix Samba 3.5.10-125.el6 (language: Unknown) (name:BVRFTP02) (domain:BVR)

10.1.2.4:445 is running Unix Samba 3.5.10-125.el6 (language: Unknown) (name:BVRFTP01) (domain:BVR)

10.1.2.76:445 is running Windows Server 2008 R2 Standard 7601 Service Pack 1 (language: Unknown) (name:BVRMCV01) (domain:BVR)

10.1.2.77:445 is running Windows Server 2008 R2 Standard 7601 Service Pack 1 (language: Unknown) (name:BVRMCV02) (domain:BVR)

10.1.2.78:445 is running Windows Server 2008 R2 Standard 7601 Service Pack 1 (language: Unknown) (name:BVRMCV03) (domain:BVR)

10.1.2.79:445 is running Windows Server 2008 R2 Standard 7601 Service Pack 1 (language: Unknown) (name:BVRMCV04) (domain:BVR)

10.1.2.80:445 is running Windows Server 2008 R2 Standard 7601 Service Pack 1 (language: Unknown) (name:BVRMCV05) (domain:BVR)

Just by luck, I bumped into an email, via *.PST, that had an attachment with information about the RTS, and the name of the machine in IEBC infrastructure and also the one in BOMAS and DR. I wont share the IPs of these initial machines, but the systems hostname as known by the network was results.iebc.or.ke.

Breaking into this was easy, via php vulnerabilities and also that it was still using simple passwords, and also the developers common mistakes of leaving SQL dumps on the webroot. Got in added a user on the system by end of February. Then I started going for the system at BOMAS. Lucky me, it was windows, much more easier. By this time it was almost at the start of March, and an IEBC official called me and told me to send my CV over for recruitment as a contractor.

By this time, I hadn’t told them how far I had gone with the test, but by the time I told them about it, and also with what they saw I can do, I was up for the job.

Now one thing I gotta clarify is that, when I got to Bomas on the first day, I picked some serious vulnerabilities that I couldn’t pick when I was attacking the network from remote and we realized with the set up at BOMAS any bad guy who would get a chance to hook up into the network would definitely break into the main server, and therefore mess up with how the results were getting in via APN.

I did my Internal Assessment within 48 hrs of no sleep. and did my report, and it was too late to fix some of the vulnerabilities, cause if it was attempted, there would be system failures. Next day, was elections day.

The only options was to monitor for any form of attack, within and from Safaricoms VPN. I did set up the Network Intrusion System and also Hosts Intrusion Detection systems and also changed the simple passwords, blocked the SQL server from the network and March 4th found me getting things to work. By mid 4th, all was ready.

Now, due to sensitivity of issues, I will not copy the incident report here or with any details, but I wish to specify we had two attacks, all of them ran on the initial step, reconnaissance and by the time scanning had started, I had hammered the attack, and all was okay.

The other issue, was a bug on a php script that was querying addition info to DB, and also a /var/log, that was not partitioned adequately.

So, a lot of rumors spread by some countrymen, meant to bring up chaos, (sorry it dint work, Kenyans, we are peaceful), saying that the systems were hacked were completely ridiculous, since we monitored every traffic, any binary and service that ran on both Servers and the major machines, We also monitored any laptop, computer that got hooked on the network, for any type of polymorphic type of attack, network scanning or a form of Advance Persistent Threat etc

It was a hell of a week, but we did it.”

 

Ends