İNSANSIZ HAVA ARAÇLARI ÇALIŞTAY ÇAĞRISI

Son zamanlarda birçok farklı kaynakta İnsansız Hava Araçlarına yönelik olarak dışarıdan müdahale edildiğine yönelik(Hacklenebilir durumda olduğu) bazı haberler yer almaktadır.

Yakın bir tarihte ise Anonsec hack grubunun 150gb veri paylaşması, Bu verilerin NASA’nın insansız hava aracına ait olduğunu iddia etmesi üzerine NASA iddiaları yalanlamak için resmi açıklama yapmıştır.

Yine yakın tarihte bazı haber kaynaklarında PKK terör örgütünün yakında Drone olarak tanımlanan hava araçları ile saldırılar yapabileceğine yönelik haberlerde basına yansımıştır.

Bahsi geçen kaynakların tamamının iddiaları henüz kesinlik kazanmasa da, bu alanda gerekli önlemlerin ve incelemelerin yapılmasının hem özel sektör, hemde devletimiz adına faydalı olacağına inanıyorum.

Bu sebeple bu alanda gerek akademisyenler gerekse özel sektör ile bir araya gelerek yapılabilecekleri ortaya koymak adına bir çalıştay başlatıyoruz.

1) İlgili cihazların projelendirilme, üretim ve kullanım aşamasında güvenlik denetimlerine tabi tutulmasının zorunlu hale getirilmesi.

2) Mevcut cihazlar içerisinde kullanılacak hazır elektronik kit, elektronik malzeme veya yazılımların özenle seçilerek denetimli ve kontrollü bir şekilde kullanılması.

3) Mevcut cihazlar için standart iletişim protokolleri dışında AR-GE yapılarak iletişim protokollerinin özgünleştirilmesi.

4) Mevcut cihazların alt yapı veya sistemlerinin “tersine mühendislik” gibi yöntemler kullanılarak yapısal veya iletişim odaklı alt yapı ve sistemlerinin çözülmesini zorlaştıracak, mümkünse engelleyecek yöntemlerin uygulanması.

Tüm ön görülen faaliyetlerin Akademisyenler veya Üniversiteler ile işbirliği yapılarak yarışma, ödüllü proje veya Akademik Araştırmalar yönünde desteklenmesi ve çalıştay çağrısı yapılarak fikir alışverişi yapılması.

Basit bir drone için tersine mühendislik örneği
http://www.jimhung.co.uk/?p=1349

NASA ve Anonsec grubu arasındaki konuyu anlatan haber
http://www.forbes.com/sites/thomasbrewster/2016/02/02/anonymous-claims-to-hack-nasa-drone/

Amerikanın Ulusal Güvenlik Ajansı(NSA) ve İsrail arasındaki İHA krizi
http://tr.sputniknews.com/abd/20160130/1020542988/abd-ingiltere-israil-nsa-gchq-iha.html

İbrahim BALİÇ

Embedded Device Security & Zollard Botnet Analysis

This entry was originally published on the 25th November 2014 on Balich Security Blog in Turkish. The original text can be found at http://blog.balicbilisim.com/gomulu-cihaz-guvenligi-ve-zollard-botnet-analizi/

 

Embedded Device Security & Zollard Botnet Analysis

As Balich Security we conducted a themed research on “Embedded Device Security” in 2014. Through this project we came across some interesting findings. We have concluded in this research that even router devices, that count as backbone of the Internet infrastructure and many other embedded devices are prone to threats.

 

As an example we can give the “Zollard” worm, which even it has been discovered in 2013 is still lurking around in embedded devices. During this research we think that we have also discovered a new, yet to be discovered malware in the very same devices, which evidently has shown these particular embedded devices to be an open target.

 

Therefore we would like to share our findings by exemplifying these with everyone in hopes that the people/organizations will take appropriate actions on embedded device security. We are also providing probable scenarios in hopes the risks can be comprehended clearly.

 

Before commencing with the analysis itself, we would like to start off with errors, attack vectors and exploits that facilitate these types of attacks.

 

Keywords: Embedded Device, Botnet, 0-Day

PDF Version: http://blog.balicbilisim.com/zollard_analiz_en-gb.pdf

 

 

 

Table of Contents

  1. Introduction……………………………………………………………………………………………. 3

1.1. General Overview………………………………………………………………………………… 3

  1. Attack Vectors…………………………………………………………………………………………. 3

2.1. Misconfiguration…………………………………………………………………………………. 3

2.1.1. Default Passwords……………………………………………………………………………………………………….. 3

2.1.2. Missing Patches…………………………………………………………………………………………………………….. 4

2.2. WEP Algorithm Flaw……………………………………………………………………………. 4

2.3. WPA/WPA2 Brute-Force Attacks………………………………………………………….. 4

2.4. WPS Brute-Force Attacks……………………………………………………………………… 5

2.5. WPS Algorithm Attack…………………………………………………………………………. 5

2.6. Vulnerabilities…………………………………………………………………………………….. 6

2.6.1. D-Link DSP 215 – Vulnerability………………………………………………………………………………… 6

2.6.2. Airties Air6372SO – Backdoors or Features…………………………………………………………… 6

2.6.3. ZyXEL ZyWall – Vulnerability…………………………………………………………………………………… 7

  1. Attack Scenarios……………………………………………………………………………………… 7
  2. Analysis……………………………………………………………………………………………………. 8

4.1. Background…………………………………………………………………………………………. 8

4.2. E3 Malware, Iptables Rules………………………………………………………………….. 9

4.3. E3 Malicious Code, DNS settings…………………………………………………………… 9

4.4. Zollard Worm, Arm File……………………………………………………………………… 10

4.5. Zollard Worm, bin.sh Script……………………………………………………………….. 11

4.6. Zollard Worm, Fork Hook………………………………………………………………….. 18

 

 

 

 

 

1. Introduction

1.1. General Overview

Even though, we do not seem to notice them very much, Embedded Devices have become crucial to our everyday lives; power plants, industry, your refrigerator in the kitchen, the router in your room and many more devices in various fields. Practically these devices that are being used by everyone can inherent very critical risks according to their state and capacity

 

To give an example of these risks, in recent years the use of “IP Camera Systems” which has been fairly widespread, and whose purpose is to protect its users has been rather frequently observed to become a weapon against its users through its “misconfiguration” [1] (in some devices exploits – 0-day or 1-day [2], [3]). This misconfiguration leads to remote access to these systems. Attackers who gain access in such a way can even quite easily delete recorded imagery. The most disturbing thing about these devices that we use so many of is, that users don’t even seem to remember their devices unless they have troubles with their devices.

 

Many manufacturers release “update packages” in order to improve their devices. However after we met up with a manufacturer, we have been told that unfortunately only 4 out of 10 users download these update packages. This exemplifies that user negligence inherits a very high risk.

 

During research we acquired a suspicious package and after analysing it, we established that it was the Zollard worm discovered back in 2013. The Zollard worm is specially crafted for Mips, Mipsel, Cisco and ARM architecture based CPU’s, and is an malicious code that has the ability to run on various structures. It has been observed that the Zollard worm targets Desktop PC’s, Servers, Modems and IP cameras.

 

And in the very same research we acquired another malicious piece of code that routes back to a Britain based Datacentre and established that it is closely keeping surveillance of the affected device. As we went further with our research we also established that anti-virus companies had not yet discovered the “e3” malicious code. Even though, we can say that this piece of malicious code was commonly present in modems with default password. This lead to another research, which revealed that 7 out of 10 modems had this malicious code present (70% of all modems with default password).

2. Attack Vectors

2.1. Misconfiguration

2.1.1. Default Passwords

Usually embedded systems are configured in such a manner that the user after the devices purchase, should log-in and configure it, therefore in general a very easy to guess and well known, default password is set. Even though it is brought to the end-users attention that s/he should change the default password, unaware of the threats, and lacking the required technical intellect the end-user mostly ignores this and keeps on working with the devices default password.

 

By using specially designed search engines, most devices connected to the Internet can be discovered. A 10 row run and leave Python code can be used to discover thousands of devices with default passwords within hours.

1

2.1.2. Missing Patches

As soon as security flaws are discovered, manufacturers release new versions. However, should the user not patch her/his device in order to upgrade its version, s/he could become the ideal target for attackers as the flaw might already have become public.

2.2. WEP Algorithm Flaw

Years ago it has been established that the WEP algorithm is prone to security flaws, however it is still in use with small sized companies that have invested in compatible devices. Even though it is well known that it takes mere minutes to crack passwords, it is an easy target for attackers, especially with people/organizations that carry on with the “nothing will happen to us” mentality.2

2.3. WPA/WPA2 Brute-Force Attacks

Due to the flaws in WEP, WPA/WPA2 has gained acceptance with its hard-to-crack PBKDF2 algorithm, however this has only slowed down the attackers. With the aid of powerful graphic cards the attack on these targets still continues.3

2.4. WPS Brute-Force Attacks

In 2011 Stefan Viehböck discovered the WPS brute-force attack, which allows the attacker to take over a WPA/WPA2 protocol device within 4 to 10 hours. This led to a drastic drop of the attackers demographics in means of technic knowledge and age, as it is still quite easy to get a hold of applications for testing purposes of this attack.

4

2.5. WPS Algorithm Attack

As the brute-force attacks on WPS enabled devices became more commonplace, most of the manufacturers brought a limit to the number of tries. As the cat and mouse game continues in the security world, attackers found a way to identify the produced algorithm for the WPS on the device, and hence to take over the system in one try.

5

2.6. Vulnerabilities

Vulnerabilities that are categorized as 0-day can be defined as those where the manufacturer has yet to receive information on the vulnerability and produce a patch. For attacks that stem from these 0-days there is almost no possibility to protect the users from such attacks.

2.6.1. D-Link DSP 215 – Vulnerability

One of the most dangerous vulnerabilities, buffer overflows may lead to take over of devices no matter how many protective measures are taken when the authentication binaries are exposed. It is one of the trickier exploits to prepare; however the effect is very powerful. An example for this can be given as the exploit in the D-Link DSP-215 Smart Plug.

6

2.6.2. Airties Air6372SO – Backdoors or Features

It is mostly denied by manufacturers that they have secret access passwords other than the ones described in the users manual. These “features” that are used to remotely administer devices are considered by some as backdoors, and by some as features. However should these passwords be exposed, privacy breaches and the use/administration of the device by people with ulterior motives is futile. This can be exemplified with the recent discovery of a backdoor in the Airties Air6372SO model.

7

2.6.3. ZyXEL ZyWall – Vulnerability

It would not be fair to consider all embedded devices as not secure. However some instances that we consider as security features may come across us in other ways. One of the best ways to exemplify this would be the vulnerability that allows the download of the settings file before authentication on Zyxel ZyWall Firewalls.

8

3. Attack Scenarios

There are literally thousands of ways to produce attack scenarios against embedded devices. These are certainly more effective than an attack against an individual and can create more havoc. The scale of these attacks will change according to the state of the targeted device and its position within the ecosystem. A great example for this is “stuxnet” [4].

 

 9  10  11
Fig. 1.Direct attack over Router to its attached devices. Fig. 2.Attack over IP camera to other devices in the Wi-Fi network. Fig. 3.Attack over IP camera or Router to PC to Mobile device.

 

With Router attacks, all other devices that are connected to it, ranging from USB, Ethernet, Wi-Fi, but not limited to, are becoming easy targets. To exemplify, a device of an organization with a flawed firmware version of 1.0.2.0 has an attack surface that also would include all devices that are connected to it through Wi-Fi.

12

4. Analysis

4.1. Background

During an ordinary research DNS addresses based in England caught our attention. We quickly realized that these DNS addresses embedded in the Modem weren’t setup by the user. But where did these DNS servers come from? This is where our journey started, by laying suspicious eyes on these DNS servers, our suspicions were further fuelled by the discovery of two other strange files, namely “arm” and “e3”.

 

Before we understood what happened, and our curiosity fuelled by those two peculiar files, we were already swept deep into a botnet network that was able to work on different architectures. Initially we suspected that both files were targeting devices with default passwords, however as gained more insight both of them we realized that the two files were actually independent from each other. We discovered that both files were independent from each other, and not targeting devices with default passwords.

As our investigations carried on the information that we gathered made us conclude that the file named “arm” exploits PHP vulnerabilities. However our other suspect “e3” on the other hand, had yet to be discovered by anti-virus companies. In the last stage of our investigations, we discovered that our first suspect the file named “arm” was the malicious code named “Zollard” and discovered back in 2013, and that our second suspect the file with the name “e3” was a piece of malicious code that targeted modems with default passwords. After gaining that much insight into our targets we decided to deepen our investigations and commenced static and dynamic analysis on our suspects.

4.2. E3 Malware, Iptables Rules

The first thing we noticed on the devices that we acquired were the Britain based DNS addresses. As we advanced in our researches on the “e3” malware infected devices we observed that it was using Iptables to add rules in order to give itself permission. It is clearly visible in the below shown screenshot that the malware is giving access permission to the devices administration console via telnet and httpd. It also has been observed that on some devices the Iptables rules were also used for NAT routing purposes.

13

4.3. E3 Malicious Code, DNS settings

During the research we observed that all infected devices are routing to the Britain based DNS, however we haven’t been able to establish through the binary code what it is for. Therefore our most logical assumption for this was that ISP’s dynamically assign most IP addresses and that every modem acquires a different IP address after it has been shut down, it would be very hard to track these devices. On this it sounds quite reasonable to establish a centre for tracking, as these devices would be required to send in a request to the DNS server. It would certainly facilitate the tracking process. Maybe it is as well only used to track the user, however we cannot certainly state a reason for this at the moment. Three things are certain, that all the infected devices were routing to these IP addresses, possessing the same Iptables rules and that at average 3 IP blocks belong to these assets.

14

4.4. Zollard Worm, Arm File

The first thing, when we acquired the suspicious file was to run the strings command. The output we gathered was rather appetizing. Clearly it was visible in the output that the related file was communicating through the GET method between certain IP addresses. Further, the download of 2 *.sh scripts fuelled our desire to carry on and all of our attention went towards the IP addresses.

The output that was gathered from the arm file through the strings command.

15

As we progressed with the investigation of the IP addresses, we discovered web servers that were established and broadcasted on these. As we took a close look at the server side, we discovered a pool of files that was kept under the “.niggers” folder.

We were able to identify both *.sh scripts that were downloaded earlier and various files that were named for different types of CPU architecture. Initially we got a hold of the “bin.sh” script that was loaded by the “arm” binary. Now we had the necessary script on hand to understand what the “arm” file was using it for and what it was able to do. This lead us to first analyse the “bin.sh” file.

16

4.5. Zollard Worm, bin.sh Script

When we had a look at the code of the script that we acquired, we saw that it was using a simple but effective method to hide itself.

17

To put it short, if there is an application that is running with the telnetx PID it will demise it. The IP address that we came across in the “arm” file with Busybox does download the files through that IP (e.g.: “mips”) and then makes a copy of Busybox in its own folder and writes over on the binary it downloads and then deletes the actual binary, finally it copies the copied Busybox with the same approach as telnetx. Busybox is being deleted, telnetx runs and the binary is deleted as well.

 

It might sound a bit complex but it manages to hide itself through obscurity in the device. We found it rather intelligent, and this approach, after it loads the required codes into the RAM, deletes the data on the disk and repeats the same action for architectures such as mips, mipsel and arm. Since they wouldn’t know what their target CPU’s architecture would be, they load all architecture types at once. As daft as it might sound the script is written in a manner that it will run until one of the binaries will work, which means that it is that certain type of architecture that is running on the target system. There was also another point that caught our attention. As preposterous it might sound to run such short command in such a complex way, we think that this is quite cleverly delivered. Because while code is being loaded into the RAM some information is required to be assigned to the system records, therefore it is quite wise to run with the name of a already existing command, still we couldn’t figure out why the repeating copy and delete process was for.

18

bin.sh

 

At first we assumed that the downloaded binary and its copies are created in order to change the MD5 checksum, however nothing within the script did anything to change the MD5 checksum, back to square 1.

 

From the binaries that we acquired from the Server, it was quite clearly visible that these were containing the same compiled strings, we had already established that, so we took one of these for a deeper analysis.

 

The first that came on our mind was to trace the application; luckily we didn’t come across any debugging technique and tried to make sense out of the tracer output. First it tries to connect to the 8.8.8.8 IP by sending an SYN flag and expects the SYN ACK flag to return, if a packet returns it renders it as “Internet connectivity available” and continues without sending an RST packet or Close (FD) and opens “/proc/net/route” in order to acquire the network information (interface, MAC, IP, open ports), further it tries to read all PID with /proc/<pid>/cmdline… it is obvious, that it is looking for something. The reading and closing happens at once, and in order to see the final we continue with our tracer log and see that changes occur on the 2800th line.

19

 

When the applications reads its own PID it runs the getdents system call and gets a list of folders, while running the setsid() (2813th line) function and creates a new session with the 2054 PID, our tracer starts tracking this PID. If we have a look at the actions within their respective sequence we see that it creates a hidden file with the name “.lolpid” under the /var/run folder, which under normal circumstances does not exist, however as we had a go with the file earlier we already had the “.lolpid” file established, and now it was accessing it;

 

read(3, “2041”, 4096)             = 4

 

read(3, “”, 4096)                 = 0

 

from this output we see that the value for 2041 is set and because it instantly closes the file and runs kill it is observed that this is an process ID, and in case there might be a folder or related link to it also subsequently runs rmdir and unlink and destroys all connections, through getpid() it acquires a new PID value and writes it to this newly established PID into its file.

 

The following lines show that a socket is being opened, and the opened socket requests a connection to the IP 93.174.93.52 on port 1000:

20

Note: The connect function is set to -1 as we were working on virtualized cross platform that had no Internet connectivity.

 

When we tried to port scan this IP address we saw that the ports were filtered. Therefore we decided to connect to it through the earlier discovered port number 1000, and whatever command we sent in we only received “SCANNER” and “OK” as messages. So we decided that this was a C&C server.

Logically if it is successful in establishing a connection to the server it would receive an acknowledgement message, and hence starts receiving instructions through port number 58455. We are assuming that there is a special request in the messaging mechanism and that according to the received requests DoS attacks and scans can be performed. Interestingly, something that really sparked our interest was that it also included a Bitcon (altcoin) miner. As low as its impact is, somebody had thought about adding this feature.

21

When we have a look at the system where the malware was detected, and we go into the “/var/run” folder and list the directories through “ls –a” besides the “.lolpid” file we also come across a directory called “.zollard”, in addition to its binaries 2 encrypted files were discovered. These were stripped and their header information changed, like the others, however the strings were not really well hidden and we came across a binary that was prepared for x86, when we had a look into its strings:

22

When the Kernel module is loaded, we can see that in another part in order to harvest alternative coins the “minerd” application is downloaded and a connection to the miner pool is established:

23

Until now it was rather easy to analyse the working structure of the system, now it was time to run some dynamic analysis on it. When we ran “strace –f –o trace.log ./x86” the program deletes everything that is contained within this folder and we loose our log file. When we had a look at the list of PIDs we came across two PIDs whose names were not visible;

24

Those can be seen trying to establish a connection with somewhere (177.201.16.x IP block). This malware that had infected this system was configured to welcome the system every time it started working and tried to communicate through this block. If we should get back to the analysis part, when we tried to kill this PID the process stops successfully however another unnamed PID runs and locks the system. In an unexpected move, this application won over us, this meant we needed to restart this qemu.

 

When we restarted this system this time we took the log file for this malware one folder level up and ran it.

25

26

Something that we really wouldn’t like would appear in our log file, as it can be seen a few functions calls are present [close(), prctl(), fork(), exit()].

 

Moreover the application is running perfectly, besides it also running the miner and has already started consuming the “CPU”.

 

Whereas when we have a look into the binary with IDA we can see, that in many parts of the code the “execve” system call can be found

27

 

28

29

We assumed that the things that we didn’t like at all and that appeared in our log file were due to “PR_SET_NAME” in the prctl() function and that it was calling a new thread. Our assumptions further went on by the thesis that there wasn’t the possibility of a log output if this was to be detached from the parent process. This might’ve been a new anti-debug technique, at least we think so, because we never came across of something like that before. We tried many workarounds, however with no successful avail.

 

We also took into consideration to hook the library function before the application was called, but refrained from doing so as we remembered that the code was complied static.

4.6. Zollard Worm, Fork Hook

When we realised, we weren’t able to bypass our problems we came up with some solutions in theory for the lock system calls (fork, prctl). Maybe if we could hook it, might this be a solution? Even if it would, I was fairly risky, because every time we executed the binary we would be required to restart the system, so got back to the board and tried to find the best possible solution. In the end we decided that if we could return the fork every time as Child, it would never be able to kill off the Parent process, so we went on to write an appropriate module for this technique.

 

If we should summarize this module; we would be required to bypass the page protection that is available beginning with the Linux 2.6 Kernel, find the fork address and substitute it with our very own fork function, this meant that our actual fork function from now on would be:

 

asmlinkage long yeni_fork(void){return 0;}

 

It would be working like this and return the 0 value, when we loaded our module and gave it a try this is what happened:

 

30

We saw that the fork was running successfully. Further we saw a full duplex pipe communication was used. From here, we instantly knew that an elite system programmer coded this. Even though the fork returning a 0 would be problem later on we conquered the first stage. Now the problem was that our pipes were literally breaking. Because the pipe wasn’t functioning properly the application wasn’t fulfilling its duty. What happened here was that each forks sequence was not in synch with the parent. However what we wanted was that this application should work properly and show us step by step without any disruption what it was doing, so we needed to reengineer our fork again. PR_SET_NAME was only used in place, exactly before the initial fork, therefore if we could apply the same logic only to the first fork the program would continue its normal flow and we would be able to trace it… but would we really? In order to see if this was the case, we only had to try again.

31

 

We changed the “fork” function as it is shown in the image, what we wanted to do here is to establish a static variable and force it to return 0 in its initial execution and use it as control variable for each time it gets executed, hence making it skip to the real fork. In the end we complied the module and loaded it, in the end we were able to trace the application end-to-end:

32

 

In the following parts the sched_yield’s come to our attention. When we analyse the output of the multi-thread programming function that consumes the CPU, we see that it first protects itself and then tries to download the Altcoin miner… if it is not successful it continuously sends requests to the earlier mentioned IP blocks.

 

Samples Download:  http://blog.balicbilisim.com/samples.rar

 

Rar Password: infected

 

Kenan Abdullahoğlu

kenan@balicbilisim.com

https://twitter.com/kyabd

Security Researcher

AndroidSandbox.net is temporarily out of service due to insufficient funding.

Dear AndroidSandbox Visitor

AndroidSandbox.net is temporarily out of service due to insufficient funding. Due to increasing usage of AndroidSandbox, at this point, we are unable to finance the infrastructure.

We will resume our services as soon as we should get sufficient funding.

Meanwhile please visit blog.balicbilisim.com for further information, news and announcement on Balich Security Products.

Your AndroidSandbox Team,

SSL Pinning [Eng]

SSL Pinning

For penetration tests that we provide for our customers, we always recommend them (our customers) to establish any connection between the Client and the Server through SSL (Secure Sockets Layer).

We believe that within this scope, applications that utilize SSL connections should additionally include the “SSL Pinning” mechanism, in order to establish a more secure communications control by building this feature into the application. On this, we would like to point out that this will create protection from attacks, such as Man-in-the-middle or root certificates that have been pushed manually into the device.

What is SSL Pinning?

Under normal circumstances the architecture of the secure communications model (SSL) while establishing the communication between the Client and Server, is based on the verification of the certificate authority signed for the Server as validated by the Client. The device (e.g. Tablet, Smartphone, PC etc…) checks for the trustworthiness of its root certificates (authority).

While the connection is established, the signed certificate will look up the root certificate (authority) whether it is signed for the domain in order to, or not to establish a secure connection. For these types of connections, for someone who is intervening in the connection, and in possession of a certificate with authority permissions from the Client side, can produce a certificate as requested by the application in order to establish a connection and send it back to the requesting application. The application will not check the certificate as it lacks SSL Pinning. With this approach an attacker will be enabled to decrypt, encrypted data.

The aim with SSL Pinning is to force the checking of the Client side certificate, while an SSL connection is established between the Client and Server, hence raising the security level of the connection.

Summary

We strongly recommend all of our customers to apply the SSL Pinning technique into all of their developed software, and to reconsider this approach for all of their currently in-use and “sensitive” information processed applications.

Balich IT, Security and Consulting Services

References

Certificate and Public Key Pinning:
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
iOS için örnek bir uygulama şablonu:
https://github.com/doubleencore/de-SSLPinning
Android üzerinde sertifika pinning kütüphanesi:
https://github.com/moxie0/AndroidPinning
Man-in-the Middle Attak:
https://www.owasp.org/index.php/Man-in-the-middle_attack

Gömülü Cihaz Güvenliği ve Zollard Botnet Analizi

Baliç Bilişim olarak 2014 yılı içerisinde “Gömülü Cihaz Güvenliği” başlığı altında bazı araştırmalar gerçekleştirdik. Bu araştırmalar sayesinde ilginç bulgular elde ettik. İnternet alt yapısının omurgası sayılabilecek router cihazları başta olmak üzere bir çok gömülü cihazın tehdit altında olduğunu tespit ettik.
Örnek olarak 2013 yılında tespit edilmiş olmasına rağmen halen bir çok cihaz içerisinde barınan “zollard” isimli zararlı yazılımının bulunuyor olması, yine aynı cihazlar içerisinde keşfettiğimiz ve henüz keşfedilmemiş olduğunu düşündüğümüz bir diğer tür zararlı yazılımın olması gömülü cihazların açık hedef olduğununu açıkca göstermekteydi.

Bu sebeple yaptığımız bu araştırmalar neticesinde elde ettiğimiz tüm bulguları, örnek göstererek kişi/kurum ve kuruşların gömülü cihaz güvenliği konusunda gerekli aksiyonları almaları adına, olası seneryoların fark edilerek risklerin daha net anlaşılacağını umut ederek kaynağımızı herkes ile paylaşmak istiyoruz.

Anlatıma ve analize geçmeden önce gömülü sistemleri ve bu tür saldırıları kolaylaştıran hata, saldırı vektörleri ve kullanılan zafiyetleri anlatmak istiyoruz.

Keywords: Gümülü Cihaz, Botnet, 0-Day
pdf version : http://blog.balicbilisim.com/zollard_analiz.pdf

1. Giriş
1.1.Genel Bakış
2. Saldırı Vektörleri
2.1. Hatalı Konfigürasyonlar
2.1.1. Varsayılan Şifreler
2.1.2. Yama Eksikliği
2.2. WEP Algoritma Zafiyeti
2.3. WPA/WPA2 Brute-Force Saldırısı
2.4. WPS Brute-Force Saldırısı
2.5. WPS Algoritma Saldırısı
2.6. Zafiyetler (Vuln).
2.6.1. D-Link DSP 215 – Vuln.
2.6.2. Airties Air6372SO – Backdoors veya Features
2.6.3. ZyXEL ZyWall – Vuln.
3. Saldırı Seneryoları
4. Analiz.
4.1. Hikaye.
4.2. E3 Iptables Kuralları
4.3. E3 DNS ayarları
4.4. Zollard Arm Dosyası
4.5. Zollard bin.sh Script
4.6. Zollard Fork Hook.

1. Giriş

1.1  . Genel Bakış

Her ne kadar farkında olmasak da Gömülü Cihazlar günlük yaşantımızın her alanın da hayati öneme sahiptirler. Enerji santralleri, Endüstri, mutfaktaki buzdolabından, odamızda ki router’a kadar bir çok alanda birçok farklı cihazı kullanmaktayız. Hemen hemen herkesin kullanmakta olduğu bu cihazlar, durum ve konumuna göre çok kritik riskleride beraberinde getirmektedir.

Bu riskler adına örnek vermemiz gerekirse, son yıllarda kullanımı oldukça yaygınlaşan ve üretim amacı kullanıcının güvenliğini sağlamak olan “IP Kamera Sistemleri” nde sıkça gözlemlediğimiz “konfigürasyon hatası” [1] (bazı cihazlarda ise zafiyet kullanılarak – 0-day veya 1-day [2],[3]  –) kullanıcılar için tam bir silaha dönüşmektedir. Yapılan konfigürasyon hatası sistemlere uzaktan erişim yetkisi vermektedir. Bu yetkiyi alan saldırganlar istedikleri zaman kaydedilen görüntüleri dahi rahatlıkla silebilmektedirler. Kullanmakta olduğumuz bu ve bu tip onlarca cihaz ile alakalı en üzücü durum ise, kullanıcıların bu cihazları, cihazlar sorun çıkartmadığı sürece varlığını dahi hatırlamamasıdır.

Bir çok cihaz üreticisi firma, ürettikleri bu cihazların iyileştirilmesi yönünde “güncelleme paketleri” yayımlamaktadır. Fakat üretici bir firma ile yaptığımız görüşme sonrasında her 10 kullanıcıdan sadece 4’ünün bu güncelleme paketlerini indirdiği gerçeği ile karşılaştık, bu örnekten anlaşılacağı üzere kullanıcıların ihmalleri büyük riskleride beraberinde getiriyor.

Yaptığımız araştırmalar neticesinde elde ettiğimiz şüpheli bir dosyanın analizi sonrasında, 2013 yılında tespit edilmiş olan bir zararlı (Zollard) olduğu anlaşılmıştır. Zollard zararlısı Mips, Mipsel, Cisco ve ARM gibi işlemci mimarilerinde özel olarak üretilmiş, birçok farklı yapıda çalışabilme kabiliyetine sahip bir zararlı yazılımdır. Zollard zararlısına Masaüstü bilgisayarlar, Sunucular, Modem ve İp kameraları hedef aldığı görülmüştür.

Yine aynı araştırma neticesinde elde ettiğimiz bir diğer zararlı yazılımın, İngiltere Merkezli bir Datacenter’a yönlendirerek cihazları yakın takibe aldığı tespit edilmiştir. Araştırmamızı biraz daha derinleştirdikce, “e3” isimli zararlının henüz anti virüs firmaları tarafından tespit edilmemiş olduğunu anladık. Buna rağmen default passport’lu modemlerde oldukça sık rastladığımızı söyleyebiliriz. Yaptığımız bir diğer araştırma sonucu ise her 10 modemden 7’sinde bu zararlı yazılıma rastlamak mümkündür. ( default password ‘lu modemlerin %70)

2. Saldırı Vektörleri

2.1. Hatalı Konfigürasyonlar

2.1.1. Varsayılan Şifreler

Gömülü sistemler satınalma sonrasında kullanıcının giriş yapıp kendi ayarlarını yapmasını sağlayacak, genelde çok basit ve bilinen, varsayılan şifreler ile gönderilir. Son kullanıcı, cihazı kullanmaya başlar başlamaz varsayılan şifreyi değiştirmesi gerektiği yönünde uyarılar almasına rağmen özellikle tehditlerden bihaber, teknik bilgi seviyesi düşük olan kullanıcılar cihazı mevcut şifreyle kullanmaya devam eder.

Belli başlı yöntemler kullanılarak, özel arama motorları gibi, internete bağlantısı bulunan bütün cihazlar bulunabilmektedir. 10 satırlık çalıştır-bırak tarzında hazırlanmış bir python kodu ile birkaç saat içinde varsayılan şifre kullanan binlerce cihaz bulabilir.

1

2.1.2. Yama Eksikliği

Güvenlik zafiyetleri farkedilir farkedilmez üretici firmalar yeni sürümler yayınlamaktadır. Fakat kullanıcı, cihaz sürümünü yükseltmediği takdirde, zafiyet genele yayılmış olduğundan, saldırganlar için ideal hedeflerden biri olmaktadır.

2.2. WEP Algoritma Zafiyeti

Yıllar evvel güvenlik zafiyetine sebep olduğu belirlenmiş olan WEP algoritması, özellikle uyumlu cihazlara yatırım yapmış küçük ölçekli firmalar tarafından kullanılmaya devam edilmektedir. Parolanızın kırılması için sadece birkaç dakikanın yeterli olduğu biliniyor olsa da “bize bir şey olmaz” mantalitesiyle kullanan kişi/kurumlar saldırganlar açısından en basit hedefler olarak görülmektedir.
2

2.3. WPA/WPA2 Brute-Force Saldırısı

WEP algoritmasındaki zafiyetler neticesinde kabulgörür hale gelen WPA/WPA2 protokolu kullanıldığı PBKDF2 algoritmasının zorluğu neticesinde saldrıganları yavaşlatmış olsa da, şifre kırmada kullanılan güçlü ekran kartları yardımıyla, saldırganların hedefi olmaktan çıkmamıştır.
3

2.4. WPS Brute-Force Saldırısı

2011 senesinde Stefan Viehböck tarafından bulunan WPS kabakuvvet saldırısı sayesinde saldırganlar WPA/WPA2 protokolüne sahip cihazları 4 – 10 saat içerisinde ele geçirebilmektedir. Test amaçlı hazırlanan programlara kolay erişim, saldırganların hem teknik seviyesini hem de yaşını aşağıları çekmiştir.
4

2.5. WPS Algoritma Saldırısı

WPS kabakuvvet saldırısının yaygınlaşması neticesinde birçok üretici deneme sayısına sınırlandırma getirdi. Kedi fare oyunun bitmek bilmediği güvenlik dünyasında, saldırganlar hedef cihazların WPS üretme algoritmasını çözerek, tek denemede sistemi ele geçirmeyi başardılar.
5

2.6. Zafiyetler (Vuln)

0-Day olarak adlandırılan 0-gün zafiyetler üretici firmaların haberdar olmadığı ve herhangi bir yamanın bulunmadığı zafiyetler olarak tanımlanmaktadır. Kullanıcıları bu tür zafiyetler kullanarak yapılan ataklardan koruyabilmek pek mümkün değildir.

2.6.1. D-Link DSP 215 – Vuln

En tehlikeli zafiyetlerden biri olan bellek taşmaları neticesinde, kimlik doğrulamasının yapıldığı binary dosyalarda bulunduğunda, ne kadar önlem alınmış olunursa olunsun, cihazın kontrolü tamamen saldırgana geçmektedir. Hazırlanması en zahmetli fakat sonuç olarak etkisi güçlü bu zafiyete verebileceğimiz örneklerden birisi D-Link markasının akıllı priz cihazı olan DSP-215 modelindeki bulunan zafiyettir.
6

2.6.2. Airties Air6372SO – Backdoors veya Features

Çoğunlukla inkar ediliyor olsa da üretici firmalar, kitapcıklarında yazanın dışında kendilerine özel olarak cihazlarda erişim şifreleri bulunduruyorlar. uzaktan yönetilebilmesi için kimine göre backdoor kimine göre özellik olan bu erişim şifreleri birilerinin eline geçtiği noktada, Hem mahremiyet ihlali söz konusuyken hem de ifşası durumunda cihazın art niyetli kişiler tarafından yönetilmesine olanak tanıyor. bu duruma örnek olarak, birkaç gün evvel bulunan Airties Air6372SO modelinin arkakapısı örnek verilebilir.7

2.6.3. ZyXEL ZyWall – Vuln

Gömülü cihazları topyekün güvensiz olarak nitelendirmek çok yanlış olacaktır. Fakat güvenlik sağladığı düşünülen eklentiler bazen tam tersi bir durumda karşımıza çıkmaktadır. Buna verebilecek en iyi örneklerden birisi, Zyxel markasına ait ZyWall model güvenlik duvarlarında, kimlik doğrulaması öncesinde cihazın ayarlar dosyasının indirilmesini sağlayan zafiyettir. 8

3. Saldırı Seneryoları

Gömülü cihazlar üzerinden onlarca saldırı seneryosu üretmek mümkündür. Kişilere yönelik olarak gerçekleştirilen atak seneryolarına göre çok daha etkili ve yüksek etkili tahribata sebep olabilirler. Bu tahribatların boyutlarıysa, hedef alınan cihazın durum ve konumu ile eşit orantıda büyümektedir. Bu alanda verilebilinecek en iyi örnekse “stuxnet” [4]  adlı zararlı yazılım olabilir.

 

9 10 11
 Fig. 1.
Direkt Router üzerindenBağlı diğer cihazlara yönelik saldırı.
 Fig. 2.
Ip Kamera üzerindendiğer wifi cihazlara saldırı.
 Fig. 3.
Ip Kamera veya Router üzerinden pc’ye oradanda mobil cihaz’a yönelik saldırı.

Router saldırılarında hedef alınan router dışında ilgili router’a usb veya ethernet üzerinden bağlı local cihazlar veya wifi kapsama alanındaki cihazlar kolayca hedef olabilmektedir. Örnek olarak x firmanın 1.0.2.0 firmware sürümüne sahip bir cihaz içerisinden kapsama alanındaki diğer aygıtlara(wifi kullanan cihazlar) attak yapılabilmektedir.

4. Analiz

4.1. Hikayesi
Yaptığımız genel bir inceleme sırasında İngiltere Merkezli DNS adresleri dikkatimizi çekti. Modem içerisinde ratladığımız bu DNS adreslerinin kullanıcı tarafından ayarlanmadığı anlaşılmıştı.Peki nerden gelmişti bu DNS serverlar? Bu DNS serverdan şüphelenmemiz ile başlayan serüvenimiz, modem içerisinde “arm” ve “e3” isimli iki garip dosyanın varlığını keşfetmemiz ile dahada ilginç bir hal almış oldu.

Ne olduğunu ve nereden geldiğini tam olarak anlayamadığımız bu iki dosya ile artan merakımız, bizi bir çok farklı işlemci türünde çalışabilme kabiliyetine sahip bir botnet ağına sürüklemiş oldu. ilk etapta default passwordlu cihazları hedef aldığını sandığımız bu şüpheli dosyalar, araştırma derinleştikce aslında bir birlerinden bağımsız olduklarını anladık. Sadece Default Password’lu cihazları hedef almadığını, birbirlerinden bağımsız iki farklı tür zararlı yazılım olduğu ortaya çıkmış oldu.

Araştırmalarımız sürerken elde edindiğimiz bilgiler neticesinde “arm” isimli dosyanın PHP zafiyetini sömürdüğünü fark ettik. Bir diğer şüpheli dosyamız “e3”’ün ise henüz anti virüs firmaları tarafından tanınmıyor olduğunu anladık. Son aşamaya gelindiğinde “arm” isimli bu dosyanın 2013 yılında keşfedilen “zollard” isimli zararlı yazılım olduğu anlaşıldı, “e3” isimli dosyanın ise default passworlu modemleri hedef alan yeni bir tür zararlı yazılım olduğunu anladık. Bu bulgular ışığında araştırmamızı dahada derinleştirmek üzere statik ve dinamik analizlere başladık.

4.2. E3 Zararlısı, Iptables Kuralları

Elde ettiğimiz cihazda ilk dikkatimizi çeken şey İngiltere Merkezli DNS adresleri olmuştu. Bu kapsamda başladığımız araştırmalar ile elde ettiğimiz E3 zararlısının bulaştığı cihazlarda uzak erişim için kendisine izni iptables kuralları eklediğini gördük. Cihazın yönetim paneline telnet ve httpd üzerinden erişim izni verdiği aşağıdaki çıktıda açıkca gözükmektedir. Iptables kurallarının bazı cihazlarda uzak erişim dışında NAT içinde bazı yönlendirmeler yaptığıda görülmüştür.

13

4.3. E3 Zararlısı, DNS ayarları

Zararlının bulaştığı tüm cihazlarda yine ingiltere merkezli dns serverlara rastladık, bunu yapmasındaki amacının binary içerisinde açık bir nedeni bulunmamaktadır. Fakat en mantıklı seneryomuz İp adreslerinin birçok ISP tarafından dynamic olarak atanması ve modemlerin kapandıktan sonra yeni ip adresleri alıyor olmasından dolayı bulaştığı cihazların ip adreslerinin takibinde zorlaşacağı yönünde. Bu sebeple merkezi bir haber alma ağı kurarak bu cihazların dns server üzerinden ipleri değişsede tekrardan dns için kendisine sorgu yapacağını ihtimali ile bulaştığı cihazları bu yöntem ile kolayca takip etmek için böyle birşey yapmış olabileceğini tahmin ediyoruz.Belkide sadece kullanıcıları takip etmek içinde olabilir, bundan henüz  için emin değiliz. Fakat zararlının bulaştığı tüm cihazlarda bu IP adreslerine ve Iptables kurallarına rastlamış aynı şekilde rastlamış bulunmaktayız. Ortalama 3 Ip block ‘un kendilerine ait olduğunu kesin olarak biliyoruz.

14

4.4. Zollard Zararlısı, Arm Dosyası

Elde ettiğimiz şüpheli dosya için ilk olarak strings komutunu çalıştırdık. Elde ettiğimiz ekran çıktısı merakımızı daha da fazla cezbetti.Aldığımız çıktıdan kolayca anlaşıldığı üzere, ilgili dosyanın GET yöntemi ile bazı IP adresi arasında iletişim sağladığı görülmekteydi. 2 adet .sh script’i cihaz içerisine indirmesi iştahımızı dahada fazla kabarttı ve tüm ilgimizi oradaki IP adreslerine yoğunlaştırdı.
15
arm binarysinin string komutu ile elde edilen çıktısı.

IP adresleri üzerinde yaptığımız diğer incelemelerde, Bu IP adresleri üzerine kurulmuş ve yayın yapan web serverlar olduğunu gördük. Server tarafını incelemeye aldığımızda server’da  “.niggers” klasörü altında barındırılan çok sayıda dosyayı keşfettik.

Elde ettiğimiz 2 adet “.sh” script ve farklı işlemci mimarileri için özel olarak isimlendirilmiş dosyalar gördük. İlk aşamada cihaz içerisinde elde ettiğimiz “arm” binarysinin yüklemiş olduğu bin.sh scriptine ulaşmıştık. Yani şimdi “arm” dosyasının bu script ile neler  yaptığını anlayabilmek için fırsatımız olmuştu. Bu sebeple ilk olarak “bin.sh” dosyasını analize 16başladık.

 

4.5. Zollard Zararlısı, bin.sh Script

Elde ettiğimiz script içerisinde göz gezdirdiğimizde kendisini gizlemek için basit ama etkili bir teknik kullandığını gördük.17Kısaca değinecek olursak telnetx pid i ile çalışan bir uygulama varsa onu öldürüyor. Busybox ile “arm” dosyasında rastladığımız IP adresi üzerinden dosyaları indiriyor (örnek : “mips”) ve daha sonra busyboxın bir kopyasını kendi dizinine alıyor ve indirdiği binary’nin üzerine yazıyor ve asıl binary’yi siliyor daha sonra kopyalanmış busyboxı aynı şekilde telnetx adı ile kopyalıyor. Sonra busyboxı silerek, telnetxi çalıştıryor ve binary’yi siliyor.

Biraz karmaşık gelmiş olabilir ama basit fakat karmaşık şekilde kendini cihaz içerisinde perdeliyor.Bize oldukça akıllıca gelen bu teknik ile çalışması gereken kodları ram’e yükledikten sonra diskteki veriyi siliyor aynı şeyi mips,mipsel,arm gibi mimarileriler içinde tekrar ediyor. Hedef alınan sistemlerdeki işlemci(CPU) mimarisinin ne olacağını bilemedikleri için tüm işlemci türlerini toplu olarak yüklüyor. Hangi binaryi çalışırsa  işlemci o mimaridedir tarzında hazırlanmış bir script olduğu saçma gelsede ard arda gelen komut yığınında dikkatimizi çeken başka bir nokta daha var. Kısa bir komut ile yapabileceği şeyi neden bu kadar uzattığı anlamsız olsada dosyanın adını değiştirerek akıllıca bir hamle yaptığını düşünüyoruz. Çünkü kod’u ram’e yüklenirken bazı bilgilerinide sistem kayıtlarına vermek zorunda bu yüzden sistemde halihazırda bulunan bir komutun adını almak mantıklı ama birbirini tekrar eden kopyalama ve silme olayına tam bir açıklama getiremedik.

18bin.sh

İlk başta asıl sunucudan download edilen binary ile bunun kopyalarının karşılaştırılmasını  engellemek adına md5sum değerini değiştirmek istediğini düşündüysekte scriptte gerçekleşen hiçbir şey asıl binarydeki md5 checksum ı değiştirmeyeceğinden tatmin edici bir cevap bulamadık.

Sunucudan aldığımız binaryleri incelediğimizde hemen hemen hepsi aynı stringleri barındırıyordu zaten aynı işi yapan farklı sistemler için derlenmiş kodlar olduğu açıkca anlaşılmıştı, bizde hemen içinden birini seçerek daha derinlemesine incelemeye koyulduk.

Aklımıza ilk gelen şey, uygulamayı trace etmek oldu neyse ki herhangi bir anti-debug tekniğiyle karşılaşmadık ve tracer çıktısını yorumlamaya çalıştık. ilk olarak 8.8.8.8 ip sine bağlantı yapmak için bir syn flag gönderip syn ack paketinin dönmesini bekliyor eğer paket gelirse “internete çıkışım var” şeklinde yorumlayıp herhangi bir RST paketi göndermeden yada close(fd) çalıştırmadan devam ediyor ve “/proc/net/route” u açıp bütün network bilgilerimizi alıyor (interface, mac, ip, açık portlar) devamında /proc/<pid>/cmdline şeklinde bütün pidleri okumaya çalışıyor belli ki aradığı bir şeyler var. Okunması ve kapanması bir oluyor biz de bu durumun sonlanmasını görmek için tracer logumuzdan devam ediyoruz ve 2800. satırda bi kaç değişiklik olduğunu görüyoruz:

19

Program kendi pidini okuduğu zaman getdents sistem çağrısını çalıştırıp dizin listesi alıyor ve setsid() [2813.satır] fonksiyonunu çalıştırıp  2054 pidi ile yeni bir session oluşturuyor tracer ımızda bu pidi takibe almaya başlıyor. Yaptığı işlemler sırasıyla bakacak olursak /var/run dizininin altına “.lolpid” isminde gizli bir dosyayı açtığını görüyoruz standartlarda böyle bir dosya bulunmaz biz daha önceden sistemimizde bu kodu çalıştırdığımız için .lolpid zaten oluşmuştu  şimdiyse erişim denemesi yapıyor .lolpid in içinde

read(3, “2041”, 4096)             = 4

read(3, “”, 4096)                 = 0

Çıktısı sayesinde 2041 yazılı olduğunu görüyoruz hemen peşinden dosyayı kapatıp kill çalıştırılması bu değerin process id olduğunu gösteriyor ardından bu isimde bir dizin ya da buna bağlı bir link olması ihtimaline karşı  rmdir ve unlink i çağırıp bağlantılarını yok ediyor ve getpid() le aldığı yeni pid değerini yani kendi pidini bu dosyaya yazıyor.

Takip eden satırda bir socket açtığını görüyoruz ve açılan socket 93.174.93.52 ip adresinin 1000. portuna bağlantı isteği gönderiyor:

20
NOT:
connect fonksiyonunun -1 le dönmesi internete çıkışı olmayan
sanallaştırılmış cross platformda çalışmamızdan kaynaklanmaktadır.

Bu IP adresinde port taraması yaptığımızda ise portların filtreli olduğunu gördük bizde Tespit ettiğimiz 1000. Port üzerinden bağlantı kurup neler olduğunu görmek istedik. Gerçekleşen bağlantı sonrası ne yazarsak yazalım “SCANNER” ve “OK” mesajlarını alıyorduk. Böylece bu adresin C&C server olduğu kararını verdik.

Mantıken eğer başarılı bir şekilde sunucuya bağlantı kurabilirse ulaştım raporunu veriyordu çünkü bağlantı sonrasında 58455 portunu açarak buradan emir almaya başlıyor. Haberleşme mekanizmasında özel bir istek kullandığını düşünüyoruz ve gelen emre göre dos saldırıları, taramalar yapabiliyor. Ayrıca ilginç olarak dikkatimizi çeken bir başka durum ise içinde bitcoin (altcoin) miner bulundurmasıdır. Etkisi her ne kadar düşükte olsada yine de düşünülüp içine yerleştirilmiş durumda.

21

Zararlıyı bulduğumuz sistemde “/var/run” dizinine gidip “ls –a” komutunu çalıştırdığımızda .lolpid dosyası dışında “.zollard” isimli bir dizine denk geliyoruz içinde binarylere ek olarak 2 tane de encrypt edilmiş dosyaya denk geldik. Kodlar diğerleri gibi striplenmiş ve header bilgileri değiştirilmiş ama içerisinde ki stringler iyi gizlenememiş bu dizinde binaryler arasında x86 içinde hazırlanmış bi binary e denk geldik içindeki stringlere baktığımızda:

22

Kernel modülü yüklediğini, başka bir kısımda ise alternatif coin basmak için hazırlanmış “minerd” programını indirip madenci havuzuna bağlantı kurduğunu görüyoruz:

23

şimdiye kadar sistemin çalışma mekanizmasıyla ilgili kolayca analiz yapabilmemizin verdiği cesaretle direk dinamik analize geçiyoruz. “strace -f -o trace.log ./x86” dediğimizde program çıkmadan bu dizinde ne var ne yok siliyor ve log dosyamızı kaybediyoruz. Çalışan pidleri kontrol ettiğimizde ismi görünmeyen iki pide denk geldik aynı pid numaralarını;

24

bi yerlere bağlantı isteği kurmaya çalışırken görüyoruz (177.201.16… ip bloğu). Bu zararlının bulaştığı sistemi karşılamak için konfigure edilmiş durumda program her çalıştığında bu bloktan birileriyle haber kurmak için çabalıyor. Analiz kısmına dönecek olursak bu pid yi öldürdüğümüz zaman başarılı bir şekilde process sonlanıyor ama başka bir pid ile yeni bir isimsiz program açılıyor ve sistemi kitliyor beklenmedik biçimde program bizi alt etmeyi başardı bu qemuyu yeniden çalıştırmamız gerektiği anlamına geliyor.

Sistemi yeniden başlattığımızda zararlının log dosyasını bu sefer alt dizine alacak şekilde çalıştırdık.25 26

log dosyamızda hoşumuza gitmeyecek bir çıktı bizi karşılıyor görüldüğü üzere bir elin parmaklarını geçmeyecek kadar fonksiyon çağrısı var [ close(),prctl(),fork(),exit()]. Üstelik binary düzgün bir şekilde çalıştı hatta madenci programı da çalıştı ve “cpu”yu sömürmeye başladı bile.

Halbuki IDA ile binary’i incelediğimizde bir çok yerde “execve” sistem çağrısının kullanıldığını görüyoruz.

27 28 29

Log dosyamızda elde ettiğimiz ve hoşumuza gitmeyen çıktının bu şekilde gelmesine prctl() fonksiyonunda “PR_SET_NAME” sayesinde yeni bir thread çağırıyor şüphesi uyandı. Bunu parent process ten koparıyorsa eğer bu yüzden çıktıyı alamıyor olabilir dedik. Yani karşımızda ileri düzey bi anti debug tekniği vardı. Açıkça biz böyle bir teknik varmı onuda bilmeden böyle olabilir dedik çünkü daha önce hiç karşılaşmamıştık. Bunu atlatabilmenin yöntemini aradık ve bir çok şey denedik ama hiçbirinde başarılı olamadık.

Aklımıza kütüphane fonksiyonlarını hooklamak ve programı çağırmadan önce yüklemek geldi ama kodun statik derlendiğini hatırlayınca bundan vazgeçtik.

4.6. Zollard Zararlısı, Fork Hook

Normal yollardan atlatamayacağımızı anlayınca bizde teorik olarak bir kaç çözüm önerisi getirdik kilit sistem çağrılarına (fork,prctl) hook atarak sistemin akışını değiştirmek bize çözüm sunabilirmiydi? Sunsa bile bu iş oldukça riskli duruyordu çünkü binaryi her çalıştırdığımızda sistemi yeniden başlatmak zorunda kalacaktık, üzerinde iyice düşünüp doğru hamleyi bulmaya çalıştık. Fork’un her seferinde Child olarak dönmesini sağlayabilirsek, Parent’in kendini öldürdüğü noktaya hiç ulaşamayacağını ve programın devam edeceği konusunda bir karara vardık ve bu teknik için modülü yazmaya başladık.

Modülün yapısını kısaca açıklayacak olursak Linux 2.6 kernellardan bu yana var olan page protection korumasını atlatıp syscall tablosunda forkun adresini bulup bizim yazdığımız fork fonksiyonuyla onu yer değiştirecektik, yani asıl işi gören fork fonksiyonumuz artık:

asmlinkage long yeni_fork(void){return 0;}

bu şekilde çalışacaktı ve her seferinde 0 değerini dönderecekti, modülü yükleyip denememizi yaptığımızda:

 

Başarılı bir şekilde forkun devamını görmeyi başarmıştık. Forkun devamında gördü30  ğümüz şey çift yönlü boru (pipe) haberleşmeleri kullanılmıştı. Buradan anladığımız ise bu kodun iyi bir sistem programcısının elinden çıktığıydı. Forkun her seferinde 0la dönmesi ileriki aşamada başımıza dert oluyor olsada ilk aşamayı aşmayı başarmıştık. Şimdi çözememiz gereken sorun boruların kırılmasıydı.pipe iletişimin aksıyor olması program işlevini yerine getirememesine yol acıyordu. Burada olan şey forkun içinde ki forkların takibi sırasında  parentlerin iletişiminin aksıyor olmasıydı. bizim istediğimiz ise program çalışsın ve bizde neyi çalıştırdığını aşama aşama ve herhangi bir aksama olmadan göstersin bu yüzden forkun yapısını tekrar değiştirmemiz gerekti.

PR_SET_NAME sadece bir yerde kullanılıyordu yani ilk forkun hemen öncesinde dolayısıyla bu yaptığımız şeyi sadece ilk fork için geçerli kılarsak devamında program normal akışına devam edebilcekti ve bizde izlemeyi başarmış olacaktık, gerçekten böylemi olacktı? Bunu anlamak için denemekten başka çağremiz yoktu..

31

“fork” fonksiyonunu resimdeki gibi değiştirdik burda yapmak istediğimiz şey statik bir değişken oluşturup forkun ilk çalışmasında 0 la dönmesini sağlayıp bundan sonra her çağrıldığında bu değişkeni kontrol değişkeni olarak kullanıp gerçek forka atlamasını sağlamak. Modülü derleyip yüklüyoruz ve sonuç olarak programı başından sonuna kadar izlemeyi başarıyoruz:

32

Ilerleyen kısımlarda sched_yield ler dikkatimizi çekiyor CPUyu sömürmek için kullanılan multi thread programlama fonksiyonu çıktıyı analiz ettiğimizde önce kendisini koruduğunu daha sonra Altcoin miner indirmeye çalıştığını bunu başaramayınca gösterilen ip blocklarına sürekli bir istekte bulunduğunu gösteriyor.

Samples Download :  http://blog.balicbilisim.com/samples.rar

Rar Password: infected

Kenan Abdullahoğlu
kenan@balicbilisim.com
https://twitter.com/kyabd
Güvenlik Araştırmacısı

SSL Pinning

Müşterilerimize sağlamış olduğumuz penetrasyon testlerinde, İstemci ile Sunucu arasında kurulan her bağlantının SSL(Güvenli İletişim Protokolu) üzerinden gerçekleştirilmelerini önermekteyiz.

Bu kapsamda SSL bağlantısına sahip uygulamalarda, ek olarak uygulama içerisinde “SSL Pinnig” mekanizmasının dahil edilmesini, Uygulamalar(app) için kurulacak olan Güvenli İletişimin kontrolünün kontrole tabi tutularak oluşturulmasının daha sağlıklı olacağına inanmaktayız. Özellikle Man-in-the-middle gibi attaklardan veya cihaza manuel yüklenen root sertifikalardan koruyacağını bildirmek istiyoruz.

SSL Pinning?

Normal şartlarda güvenli bağlantı modeli(SSL) İstemci ve Sunucu arasında bağlantı sağlarken, İstemci tarafında yapılan kontrolleri sunucu için imzalanan sertifikanın otorite doğruluğuna dayanmaktadır. Cihaz (tablet, telefon,pc vs gibi) üzerindeki root sertifikalar(otoritelerin) güveninirliği kontrol etmektedir.

Bağlantı sağlanırken imzalanan sertifikanın, root sertifika(Otorite sahibi) tarafından, ilgili domain için imzalanmış olması bağlantının kurulması için yeterlidir. Bu tip bağlantılarda araya giren herhangi birinin elinde, İstemci tarafında otorite yetkisine sahip bir sertifikası varsa, Uygulamanın talep ettiği bağlantı için sertifika üreterek bu sertifikayı uygulamaya gönderebilir. SSL Pinning mekanizması bulunmadığı için uygulama sertifika’yı kontrol etmeyecektir. Bu yöntemi kullanarak saldırganlar encrypted verileri decrypt edilebilmektedir.

SSL Pinnig tekniğinin amacı, İstemci ve Sunucu arasında, SSL bağlantısı oluşturulacağı zaman kontrol mekanizması içerisinde, yani İstemci taraflı (client side) sertifikanın kontrol’unu sağlanarak, kurulacak bağlantının güveninirliğini arttırmaktadır.

Özet

Müşterilerimizin tamamına geliştirmekte olduğu uygulamalarda SSL Pinning tekniği kullanmalarını, Şuan kullanmakta oldukları ve “hassas” bilgilerinin aktarıldığı uygulamalarda SSL Pinning tekniğinin kullanılıyor olduğuna dikkat etmelerini tavsiye ediyoruz.

Baliç Bilişim ve Danışmanlık Hizmetleri

Referanslar

Certificate and Public Key Pinning:
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
iOS için örnek bir uygulama şablonu:
https://github.com/doubleencore/de-SSLPinning
Android üzerinde sertifika pinning kütüphanesi:
https://github.com/moxie0/AndroidPinning
Man-in-the Middle Attak:
https://www.owasp.org/index.php/Man-in-the-middle_attack