Wednesday, July 22, 2015

Never trust a subcontractor

It all started with a phone call. "The whole network at [customer redacted] is down and they have no power - they need your help."

My blood ran cold. The engineer calling me sounded panicked, and for good reason. [Customer redacted] has an enormous natural gas facility in South Texas, too far from civilization to get enough power off of the grid. We designed and built an onsite natural gas power plant for them - a big one, capable of supplying 40+MW of power at peak load. They could run the facility for a short while without the power plant, but not long - and shutting down the facility meant losing 7 figures per hour. By the time I was informed, they had 6 hours until they had to shut down.

As the guy who had designed and installed said network, I was naturally the guy to call when it had problems, which had never happened before. It was a pretty simple network, honestly - just switches, cat5 cables and fiber. Since this was the network all the PLCs, relays, meters and whatnot ran on, it was airgapped & isolated, no routers. Not much to go wrong.

I quickly get on the phone and walk the guy on their end through plugging in a laptop and running
some simple tests. Check lights on things, ping this, ping that. Everything seems good, though. The network is emphatically not down. So I send him a remote app and take control of his laptop to see for myself.

Log into switches, check things, nope, the network's not down. When I log into the HMI system, though, I see a big red error message: "Network Error: Cannot connect to database". The database server is up, though. I log into the database server (Windows Server 2012 running MSSQL) and that's where I find the problem: SQL isn't running. I try to start it and it immediately shuts back off.

Monday, July 20, 2015

Hacking Team Uses UEFI BIOS Rootkit

The dissection of the data from the Hacking Team leak has yielded another critical discovery: Hacking Team uses a UEFI BIOS rootkit to keep their Remote Control System (RCS) agent installed in their targets’ systems. This means that even if the user formats the hard disk, reinstalls the OS, and even buys a new hard disk, the agents are implanted after Microsoft Windows is up and running.

They have written a procedure specifically for Insyde BIOS (a very popular BIOS vendor for laptops).  However, the code can very likely work on AMI BIOS as well.

A Hacking Team slideshow presentation claims that successful infection requires physical access to the target system; however, we can’t rule out the possibility of remote installation. An example attack scenario would be: The intruder gets access to the target computer, reboots into UEFI shell, dumps the BIOS, installs the BIOS rootkit, reflashes the BIOS, and then reboots the target system. We’ve found that Hacking Team developed a help tool for the users of their BIOS rootkit, and even provided support for when the BIOS image is incompatible.

Blocklist for Transmission

Transmission is, in my opinion, light and the best BitTorrent client for OS X so far [and did you know there’s even an unofficial Windows version too?]. Why? Because it’s super easy to use and configure and it’s not resource-hungry like some other BitTorrent client.

Looking for a nice and complete blocklist for Transmission can be a pain, especially if you’re not sure of which one to pick. In fact there are a ton of lists all for different purposes and no one will give you complete bad-peer protection since one will shield your client from spammers, one from the US Government [really?] and no one from all those things combined.

If you search on Google you will find people recommending this website, called iBlocklist, which collects various block lists but there are to many of them and they all have the same problem I said before: no complete 100% protection.

Luckly John Tyree, a user from quora.com, created a GitHub project which combines all those iBlocklist lists in to a single one and he hosted the result here. Simply add this URL in the Transmission preferences.

Good luck!

Monday, July 13, 2015

Magsukul Sapura (thank you Sapura)

السَّلاَمُ عَلَيْكُمْ وَرَحْمَةُ اللهِ وَبَرَكَاتُهُ and Good Afternoon,

بِسْمِ اللّهِ الرَّحْمَنِ الرَّحِيْمِ

اَلْحَمْدُلِلّهِ, today is my last day working at Sapura Secured Technologies as Systemic Security Manager for Sapura Defense Sdn Bhd. Once again, I've been given opportunity by Allah S.W.T. to share knowledge and experience for the industry and Information Warfare community. Although I have my own plan, but I know Allah also plans, and Allah is the best of planners. I know who I will be, and I know where I will be, but I know that Allah will choose what’s good for me.


I wanted to wish everyone happy trails. My colleagues have been nothing short of amazing, the knowledge, experience, and the quality of discussions is incredibly stimulating. In the last 7 years with Sapura, Allah S.W.T has shown me a form of great challenges which almost took me down to the ground and taught me a unique knowledge through people around me. I learned a great deal, building skills, relationships and challenges that I never think of.

Thursday, July 9, 2015

How to use SSHFS

Introduction
In computing, SSHFS (SSH Filesystem) is a filesystem client to mount and interact with directories and files located on a remote server or workstation over a normal ssh connection.[1] The client interacts with the remote file system via the SSH File Transfer Protocol (SFTP),[2] a network protocol providing file access, file transfer, and file management functionality over any reliable data stream that was designed as an extension of the Secure Shell protocol (SSH) version 2.0.

In many cases it can become cumbersome to transfer files to and from proprietary and customized operating system. This can become quite a hassle in a very short period of time. Luckily there is a way to mount remote file system to local computer without NFS, SAMBA or other remote filler protocols. In this article, I will show you how to do exactly that.

Wednesday, July 8, 2015

HackingTeam become Hacked Team

An ‘enemy of the internet’ that helps governments spy on citizens has been hacked
The (ironically-named) Hacking Team is an Italian security firm with a history of supplying surveillance technology to governments around the world, including some unpleasant regimes. It’s now been hacked itself.

As CSO Online reports, the source of the hack isn’t clear yet, but a torrent file with 400GB of internal documents, product source code and email archives is now public. There’s no shortage of glee online about the development, particularly from privacy activists. Campaign group Reporters Without Borders lists Hacking Team on its Enemies of the Internet index. Most of the strong criticism directed at the company is down to its surveillance tool Da Vinci, which it says can be used to break encryption on emails, files and IP calls.

In the last, Hacking Company has denied any allegations of selling tools to the governments but the leaked emails show that company has done some pretty good business with the oppressive regimes in Sudan, Saudi Arabia, and Bahrain.

The unknown hackers have posted various file links on file sharing websites and replaced the company logo that read “Hacking Team” to “Hacked Team”  on Twitter. Many companies are known to develop highly sophisticated software and help the governments to monitor the people’s smartphones and personal computers.

Monday, June 29, 2015

Path MTU, IP Fragmentation and MSS

Last few weeks, I've been involved troubleshooting high latency on SATCOM and 3G infrastructure. Long story short, I found that when in UDP, the "Dont Fragment (DF)" bit is set to 1. Therefore, I would like to write about Path MTU discovery and IP Fragmentation in this post and the relation between them.


As per example topology above, if the host LINUX1 is sending a packet to LINUX3 device. Packet has to go through a path in which there are various MTU sizes involved.

Path MTU is; assume packet, which is leaving LINUX1 has total length of 1450 bytes. Because the link between LINUX1-LINUX2 has 1500 bytes limit, there is no problem. However, once LINUX2 receives the packet, it sees that the link that it must use to forward this packet has a lower maximum packet capacity than the packet it has. Under normal circumstances, LINUX2 sends back an ICMP notification to LINUX1 and says that “Hey dude, I can’t forward this packet as I have a link having 800 bytes MTU on the way, do something and lower your packet size”

LINUX1 gets this ICMP and lowers its further packets’ maximum sizes to 800 then the packets flow through. Why doesn’t it occur? This is what documents say if the next link MTU is lower than the packet being forwarded, packets are fragmented.

Now the Path MTU discovery comes in: