Leisure in safety

Safety is a term that becomes more important each day. It is part of one of the inherent principles for the human being, wich is the principle of conservation of the species. This principle keeps humans alive and away from the constant dangers that the human could suffer and therefore, it is what allows the survival of the species along with reproduction. Security also can be applied to information and physical things.

Recently in this blog (in the spanish version) our fellows have written several posts showing some technology applications to road safety, we can consult them here: Seguridad Vial (Aitor Corchero) and Monitorizando automáticamente el tráfico (Eduardo Morrás). Actually, many companies are working on new preventive systems on mobility, traffic systems, pedestrians conduct analysis, intelligent braking system for vehicles, etc.

As a current example we want to show some recently developed by Volvo:

• Driver Alert Control that analyzes the behavior of the driver and detects if the driver has fallen asleep.
• Collision Avoidance by Auto Steering, which analyzes closer traffic in order to warn the driver and force the return to normal situation.
• Emergency Lane Assist that prevents leaving the roadway.
• City Safety that can avoid frontal impacts and alerts drivers of emergency braking situations.

New technologies have a great importance in vehicles, the reason is that we spend a large amount of time in our car and unfortunately too many people die each on the road.

Another example of the application of technology to a non-IT sectors and the reason of this post is the rumor that FAST will make use of Nintendo technology to carry out their preventive controls at airports against terrorism.

As discussed in the article, they have been thinking to use the Nintendo Wii Balance Board to capture people reactions and thus being able to detect anomalies. According to them, people with symptoms of nervousness or agitation, often balancing the body weight with more often than calm ones, which is what they would detect with the peripheral from Nintendo. However, there isn’t a secure system but this added to the current security measures, provides greater consistency in the global security systems.

IPv6 Security (IV)

The first posts about IPv6 Security [1,2,3] introduced the enlarged address space, other main features and how the security of the new Internet protocol is affected by them.

But what about the security features directly implemented into IPv6. This is what is called IPsec.

IPsec is a mandatory part of the IPv6 protocol standard and describes how a secure connection is made through an insecure network. It uses two main mechanisms to ensure security. The Authentication Header (AH) which guarantees that the communication partner is really the one he pretends to be (Authenticity). And the Encrypted Security Payload (ESP) ensuring that only the communication parter can read the information which is exchanged with him (Confidentiality). Further more the Authentication Header can be used to detect if data is altered during transmit (Integrity).

Authentication Header (AH)
Different authentication mechanisms are provided by the AH protocol to generate a checksum over included headers. The AH header is shown below and related fields are discussed in the following:


Security Parameter Index
The SPI value is checked by the receiver to identify to which Security Association (SA) the incoming packet belongs to. Basically this holds detailed information about the algorithms and parameters used for the encryption.

Authentication Data
This field holds the checksum (Integrity Check Value ICV) for the packet. The size is depending on the algorithm used for calculating this checksum; but always a multiple of four bytes.

The checksum is calculated over different fields. Basically it is calculated over all fields of previous headers including the AH Header - but only over fields which do not change during transmit to the destination. So for example the Hop Limit field of the IPv6 Header - which is decreased by every router during transmit - is not used for calculation.

Encrypted Security Payload Header (ESP)
ESP means encrypting the packet data (payload) including upper layer protocols like UDP or TCP. Everything including the ESP Header itself is ciphered. It is possible to use ESP and AH mechanisms autonomously; this is the reason why some of the following fields in the ESP Header are known from the AH:


Security Parameter Index
The SPI value is checked by the receiver to identify to which Security Association (SA) the incoming packet belongs to.

Payload Data
The upper layer protocol header (e.g. TCP or UDP Header) including payload data. The ESP Payload Data is completely encrypted.

Authentication Data
The checksum (Integrity Check Value ICV) is optional in the ESP Header. It is calculated over the ESP Header including the encrypted payload data.

The algorithm used for encryption is either manually specified or dynamically negotiated by the key exchange protocol. ESP authentication and encryption are both optional, which means either one of these two methods or both together can be used.

Only a few related parts are missing to complete the secure communication with IPv6 - this will be explained in the following post.

Clemens Kurtenbach
S21sec e-crime

Detecting ZeuS

We have been talking some time ago about our dear friend, almost one more colleague: ZeuS. It is a malware with more than 3 years of life which continues changing and evolving to hide itself better and making the fraud more efficient. But what we maybe have not mentioned yet is how to know if our little friend is here, spying all our movements and reporting all of this to its parents, because sometimes the AV software is not so effective as we expect.

There are several evidences in its different versions which mean that we are infected with ZeuS:

• Filesystem


ZeuS leaves a trace in the filesystem when it's installed in the computer, but it hides and blocks all the files it creates, avoiding that a normal user can see and delete them. The solution to find these files is using antirootkit software which will show us the hidden files.

Nowadays the usual binary name is sdra64.exe and its configuration directory c:\windows\system32\lowsec, but this can change depending on the version. We already mentioned the various names for the configuration files, so now I'll only comment the different names for binary files:



ntos.exe
oembios.exe
twext.exe
twex.exe
sdra64.exe
bootlist32.exe
userinit32.exe
bootwindows.exe

• Windows registry


Searching the Windows registry is another way to detect the infection. The trojan is able to execute itself after each reboot thanks to the inclusion of the binary path in the following registry entry:


HKLM/SOFTWARE/Microsoft/WindowsNT/Winlogon@Userinit

Thus simply opening the registry editor (regedit.exe) we could locate our ZeuS:

• Hooks


ZeuS needs to put several hooks in different functions in order to make the code injection, intercept data, etc. We can find these hooks in most of the executed processes and the most common ones are the following:



• ntdll.dll

NtCreateThread
LdrLoadDll
LdrGetProcedureAddress
NtQueryDirectoryFile

• user32.dll

GetClipboardData
TranslateMessage



To know if we have these hooks in our system we must use an antirootkit program too:

• Online banking strange behaviour


We can expect that people who use online banking on daily basis can notice some change in the application like an extra field asking for the password needed to make transactions or asking for all the positions of the coordinates card. This is what our trojan makes. Perhaps it will be harder to detect for people who use it occasionally, so the solution here is to pay attention while doing online banking and talk with the bank if there is any suspicious behaviour. This is an example of a login page before and after of ZeuS injection:

• Extra parameters (server-side)


Usually when ZeuS adds extra fields in the bank page through HTML injection these additional parameters will be sent to the bank server where, depending on the injected code, could be intercepted and being possible to warn the user of a possible infection.

• Trojan mutexes


Finally, we can detect the trojan in the system thanks to the mutexes that it creates. For example, with the OpenMutex function we can check if the ZeuS mutexes exist or not, showing the malware trace in the system. Until the moment the mutexes we have seen are:



__SYSTEM__64AD0625__
_H_64AD0625_
_AVIRA_2109
_LILO_1909
_SOSI_1909

Jose Miguel Esparza
S21sec e-crime