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.
sobota, 16 lipca 2016
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.
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.
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.
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.
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:
The main concept utilises the knowledge from the pages below:
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 get_binaries.sh. 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/kitgen.sh 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/pwn.sh 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. Pwn.sh 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 pwn.sh 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 pwn.sh 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.
DISCLAIMER
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.
Links:
*Kitgen itself:
The main concept utilises the knowledge from the pages below:
- https://twopointfouristan.
wordpress.com/2011/04/17/ pwning-past-whole-disk- encryption/ - http://code.google.com/p/
logkeys/issues/detail?id=108 - comment 11 - http://www.linux-sxs.org/
storage/fedora2ubuntu.html
Also worth mentioning are:
http://www.phrack.org/issues/68/11.html - point 5.2
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.
I am an IT security guy so now you know what to expect.
Subskrybuj:
Posty (Atom)