If you missed the first part of this series, where you can read about what is a shellcode and how it works, you can find it here: Part I. In this part, I will cover required information in order to be able to properly write a shellcode for Windows platform: the Process Environment Block, the format of Portable Executable files and a short introduction to x86 Assembly. This article will not cover all the aspects of these concepts, but it should be enough in order to properly understand shellcodes.
Process Environment Block
Within Windows operating system, PEB is a structure available for every process at a fixed address in memory. This structure contains useful information about the process such as: the address where the executable is loaded into memory, the list of modules (DLL), a flag specifying if the process is being debugged and many others.
It is important to understand that the structure is intended to be used by the operating system. It is not consistent across different Windows system versions, so it may change with each new Windows release, but some common information has been kept.
This article contains an overview of shellcode development techniques and their specific aspects. Understanding these concepts allows you to write your own shellcode. Furthermore, you could modify existing exploits that contain already made shellcode to perform custom functionality that you need.
Let’s say you have a working exploit in Internet Explorer or Flash Player that opens calc.exe. This isn’t really useful, is it? What you really want is to execute some remote commands or to do other useful functionality.
In this situation you may want to use standard existing shellcode as the ones from Shell Storm database or generated by from Metasploit’s msfvenom tool. However, you must first understand the basic principles of shellcoding so you can use them effectively in your exploits.
For those who are not familiar with this term, as Wikipedia says:
“In computer security, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability. It is called “shellcode” because it typically starts a command shell from which the attacker can control the compromised machine, but any piece of code that performs a similar task can be called shellcode… Shellcode is commonly written in machine code.”
During a recent penetration test we have experienced the situation where we’ve gained remote code execution with limited privileges to a web server and had to pivot to other hosts from the internal network.
For this, we had to find a reliable method to forward our traffic from our local machine to the internal host via the compromised server. This blog post describes how we solved this situation – for future reference.
Our scenario is best described in the diagram below:
Achieving our goal was not that straight forward since the compromised server was behind a firewall and only ports 80 and 443 were permitted inbound. Furthermore, we were executing commands as www-data user and our non-interactive shell (PHP passthru) was pretty limited.
Ionut Popescu, Senior Security Consultant @ KPMG Romania has been accepted as speaker at the prestigious DEFCON conference. He will present one of his projects: NetRipper tool, developed especially to be used in penetration testing projects.
The conference will be held in Las Vegas, Nevada, between 6-9 August 2015.
NetRipper – Short description
The post-exploitation activities in a penetration test can be challenging if the tester has low-privileges on a fully patched, well configured Windows machine. This work presents a technique for helping the tester to find useful information by sniffing network traffic of the applications on the compromised machine, despite his low-privileged rights. Furthermore, the encrypted traffic is also captured before being sent to the encryption layer, thus all traffic (clear-text and encrypted) can be sniffed. The implementation of this technique is the tool called NetRipper which uses API hooking to do the actions mentioned above and which has been especially designed to be used in penetration tests, but the concept can also be used to monitor network traffic of employees or to analyze a malicious application.
And we will be waiting to share his experience at the conference in the next article.
Mobile phones have become an indispensable part of our daily life. We use mobile phones to communicate with our loved ones, for quick access to information through the Internet, to make transactions through mobile banking apps or to relax reading a good book.
In a way, a big part of our private life has moved into the digital environment. Mobile phones seem to be a pocket-sized treasure of secrets and information, hiding our most valuable photos, mails, contacts and even banking information. There’s no wonder why we need mobile phones to have bullet-proof security.
Android is the most common operating system for mobile devices and is particularly interesting from the security point of view. It is very permissive, allowing its users to customize about anything, administrative privileges (a.k.a. rooting) can be unlocked on most phones, it has a very fuzzy system for the permissions required by applications and it features different ways for one application to interact with other applications.
In this blog post, we are going to focus on how Android apps can interact with each other and how the security of those interactions can be tested.