#securityblogs

That was Thomas Hesse, then president of Sony BMG's Global Digital Business (2005) responding to Sony’s DRM scam.

So what happened? In 2005, Sony released a set of CDs which secretly installed rootkits on the computers that runs these CDs which lets them know if you are trying to copy the CDs. It can’t be removed without damaging Windows. When this was discovered, most antivirus systems offered a fix that could remove the cloaking but not the rootkit itself which possibly indicated that the antivirus companies were colluding with Sony. This is said to have infected around half a million systems around the world and while it did have phoning home (behavior of security systems which report network location, username, or other such data to another computer) capabilities, the company well, denied. 

Some other rootkit invasions:

Stuxnet: Believed to be jointly developed by America and Israel, Stuxnet is believed to control programmable logic controllers which allow the automation of electromechanical processes such as those used to control machinery and industrial processes (Wikipedia). It ruined almost one fifth of Iran’s nuclear centrifuges and infected over 20000 computers and caused 1000 machines to physically degrade. Introduced to the target via an infected USB flash drive. "The worm then propagates across the network, scanning for Siemens Step7 software on computers controlling a PLC. In the absence of either criterion, Stuxnet becomes dormant inside the computer. If both the conditions are fulfilled, Stuxnet introduces the infected rootkit onto the PLC and Step7 software, modifying the code and giving unexpected commands to the PLC while returning a loop of normal operations system values feedback to the users.” 

UEFI rootkit: This was believed to be developed by the Kremlin spies to prowl into European governments. A UEFI rootkit starts up before the operating system and antivirus thus burying itself deep in a machine, undetected but with high access privileges. The code then runs LoJax, which connects the home computer to a back end server, thus silently revealing its location. 

Rootkit is a word that is thrown around everywhere, but honestly, apart from knowing that it could be malicious, I didn’t know much about it. Well, it isn’t always malicious either, so I was wrong about the one thing I knew. I’m hoping there would be somebody like me out there and this blog post is a reflection of what I have learnt about rootkits this week.   

As always, let's start with the age old question - what exactly is a rootkit? Interestingly, the term ‘rootkit’ comprises of the two terms ‘root' and ‘kit', where root refers to the admin account on Unix and Linux systems and kit refers to the software components that implement the programs that enable admin level access to a system or network. In simple words, a rootkit is a computer program that can hide its presence in a system. Doesn’t seem so bad, does it? Well..can’t be so sure about that, because what they do is use this obscurity to their advantage, and install a set of tools that can ensure continuous remote access to the infected computer. These set of tools can essentially include a keystroke logger, a DDoS attack bot, a module to steal passwords or credit card information or even a functionality that disables the security software! But as I told above, not all rootkits are malicious. It’s like using an axe - depends on what you use it for. One major advantage is remote end-user support (VNC). This allows the end user’s system to be virtually controlled by the technical team in case of any technical issues. Another would be copyright protection, which backfired in case of Sony though. Sony placed a Digital Rights Management (DRM) software through CDs that installed a rootkit on their computers - so basically its like giving an attacker a free access to your computer. This apparently infected more than half a million computers world wide (More about the Sony rootkit coming up in future blogs!) 

Lets now see how rootkits propagate. So a rootkit actually comes as a pack of 3 - a dropper, loader and the rootkit itself. A dropper is mainly a malicious link that requires human intervention which activates the dropper which in turn activates the loader program. The loader exploits vulnerabilities of the system to ensure that the rootkit can load itself into memory. It then proceeds to delete itself (cool, eh?).    

Even though there are a wide variety of rootkits out there, the most basic and the widely propagated ones are user-mode rootkits (most common) and kernel-mode rootkits. User-mode rootkits run by hijacking the application processes run on the system or by overwriting the memory used by applications. The kernel-mode rootkits on the other hand run at the lowest level of the OS and gives the attacker complete control of the system. In recent years, there’s a new kid on the block - mobile rootkits. These target the smartphones, mainly Android and is installed when the user downloads a malicious application. Why exactly is a rootkit invisible? This is the interesting part. Most of the less advanced anti viruses work on a higher level of the OS and doesn’t actually delve deep into the OS. Even if an antivirus detects a rootkit, a malware could possibly deactivate the protection itself and delete some important components. The smarter rootkits creates a special file to be detected by the antivirus, once it is detected, it shuts down the anti virus and prevents it from running again! 

And because of this, rootkit detection and deletion is not easy. It should be carried out as a three-phase process - rootkit detection, antivirus self-protection, rootkit neutralisation. There are rootkit scanners that detect and delete user-mode rootkits. But the problem with kernel-mode rootkits is that they can only be run when the rootkit is inactive, ie the system has to be in boot mode and all the system processes have to be stopped. So using a single detector might not be effective. The safest way would be backing up your data and then wiping the device. Users should be aware of malicious links and should stop themselves from clicking on suspicious links. The softwares should be uptakes regularly and the vulnerabilities in applications and OS should be looked into. Rootkits can be identified by close inspection of the network logs which might indicate a rootkit communicating with a remote control centre. Analysing the behaviour of the system by checking for patterns of CPU usage might also help in its detection.

   Well, that’s been a long post, I will try to post another one in the next couple of days about some infamous attacks initiated by rootkits. I’ve started the bandit level on overthewire and I’m done till level 5. Not bad for a lazy week 😄 

After looking at the pictures of the location,  this is what I came up with.   

2 people are required to carry out this operation. This would be done in the evening, maybe an hour or 40 mins before the closing time. Once you get to the location, go over to the edge where there is a direct connection to the cave like structure in the centre. 

Hey guys, its week 3 already and honestly, I have been slacking off a bit (I blame it on the weather), but finally I decided to get the tute post done. So this week’s tutorial was about airplane doors. The case study was based on different mid - flight airplane accidents and we were asked to come up with some recommendations/practices to ensure the security of flight crew compartments.  

Since most of the accidents occurred in the absence of a co - pilot / pilot, ie when only one person was present in the cockpit, a major recommendation was to ensure that two people are present in the cockpit at all times. So maybe a third crew member (head air hostess) could take the pilot’s/co-pilot’s place if they wanted to step out. The was also a suggestion to design cockpits with toilets but then realised that that wouldn’t necessarily be a solution as one pilot is again left alone.   

Before each flight, the pilots should go through a fitness test to ensure that they are not suicidal and are fit for flying - both physically and emotionally.   

The cockpit entry needs to have a multilayer of security - a password plus finger print. The password can be changed before every flight and is only known to the pilots and the airplane crew head.   

Another week and yet another interesting topic to research and think about - events with low probability and high impact. These are the type of events that might have happened very few times or might not have happened at all and hence the information about these events are very limited. And because of this, it is very difficult to predict their occurrence beforehand. However, they are of high impact which implies that the risk associated with these events are usually very high. So normal examples of these events include terrorist attacks, plane crashes and natural disasters.   

So for those who haven’t heard, there was a blackout on June 16, 2019 that affected the whole of Argentina (yes, a whole country!) and parts of Uruguay - that’s nearly 50 million people! Public transport was halted, internet connections and phone lines obstructed, water supplies cut off, shops forced close, patients surviving on medical equipments forced to shift to hospitals. Reports say that somewhere along the transmission between two hydroelectric power plants, the line was damaged or couldn’t handle the load, possibly because of a tree or a lightning strike. But the plants kept generating power which caused an overload, which then tripped circuits that protect the generators, and finally shut them down. This tripped the protection circuits on the rest of the power plants and brought down the entire nation’s grid.   

Attempts should have been to isolate the damage rather than let it spread to the whole of a nation. Most power systems have sensors that can sense power surges or shortages, even software that can take generators offline or reroute electricity. But in case of Argentina, this obviously did not happen - the system did not react fast enough. Even if Argentina did have the sensors and softwares, it obviously isn’t working. So update them and train the operators to take immediate measures to isolate the problem. Upgrade the outdated substations and cables. Moreover, the transmission and power plant companies could constantly keep track of demand and supply and see if they are balanced. The trees near transmission lines should be trimmed regularly. In addition to this, it would help greatly if consumers were mindful of the electricity usage. In a country where blackouts aren’t rare, better planning is extremely essential. And finally what does the government have to say about all this?   

So what can you figure about a person after going through the contents (or trash) of his/her car? Everything! 

As part of this activity in week 2, we were given pictures of a few items from a person’s car and we had to find out all the information about this person. Here is what I found: 

So this week’s lecture had an interesting topic to ponder upon - Type I and Type II errors. Richard basically gave us two scenarios of these error types. The first one was a person being diagnosed incorrectly with a disease (type I) and not being diagnosed when he actually had the disease (type II). The second example was to incorrectly charge an innocent person with murder charges (type I) and the type II scenario being letting go of a guilty person thinking he is innocent.   

When do these types of errors occur? Both these errors are part of hypothesis testing. Type I error is what we call a false positive, that is incorrectly rejecting a true hypothesis and Type II error is a false negative, which means not rejecting a false hypothesis. The chances of committing these two errors are inversely proportional and in most cases one type of error can be more severe than the other. So I have been thinking of various scenarios where we could think of these two types of errors and I came up with quite a few examples.   

Suppose you check the contamination level of water in pool in order to determine whether it has to be closed for maintenance. In type I error situation, the pool will be closed even if it doesn’t have to be because the tests would falsely show the contamination level as that above the threshold. In type II error situation, the pool is open for public when it has to be actually closed due to high level of contamination. In a case like this, a type II error is more dangerous than a type I error because it can be dangerous. 

Another scenario that I could think of is when we test a new drug for a disease and rejecting it thinking it is ineffective or approving the new drug when it is not actually effective. Here, the former is less severe than latter as people may take the drug thinking it is going to be effective but in reality, it is not so and can result in not treating the disease properly at the right time. In case of application development/testing, to falsely reject an application thinking that it doesn’t perform a specified functionality and accepting an application falsely thinking that it actually does perform a specified functionality is another scenario where type I and type II errors pop up.