During years, many different researches and attacks against digital and physical payment methods have been discussed. New security techniques and methodologies such as tokenization process attempts to reduce or prevent fraudulent transactions.
If you attack someone, they will defend themselves, but if you tickle them, they will eventually crack open. This surprisingly applies to Android apps as well! Therefore, I created AndroTickler, not to test apps against certain attacks or examine them for specific vulnerabilities, which developers would learn to avoid. However, it helps pentesters to analyze and test apps in their own style, but in a faster, easier and more flexible way. AndroTickler is a Swiss-Army-Knife pentesting tool for Android apps. It provides information gathering, static and dynamic analysis features, and also automates actions that pentesters frequently do and highly need during their pentests. In addition, it makes use of the powerful Frida to hook to the app and manipulate it in real-time.
Here is a short blog post that explains how you can make your own Man-in-the-Middle (MitM) setup for sniffing the traffic between a SIM card and the backend server. This is NOT a new research but I hope this will help anyone who doesn’t have a telco background to get started to play with mobile data sniffing and fake base stations. This is applicable to many scenarios today as we have so many IoT devices with SIM cards in it that connects to the backend.
In this particular case, I am explaining the simplest scenario where the SIM card is working with 2G and GPRS. You can probably expect me with more articles with 3G, 4G MitM in future. But lets stick to 2G and GPRS for now.
Some time ago, one of our customers contacted us with a special request. For some legitimate reason, they needed to centrally collect certain certificates including their private keys which were distributed across many client systems running Windows and stored in the corresponding user stores. Unfortunately (only in this case, but actually good from a security perspective), the particular private keys were marked non-exportable making a native export in the context of the user impossible. As if this wasn’t enough, the extraction was supposed to be executed in the context of the current user (i.e. without administrative privileges) while not triggering the existing Anti Virus solution at all. Also, the certificates needed to be transferred to some trusted system where they could not be accessed in an unauthorized way. So let’s have a look how we tackled these problems:
In one of the last pentests we’ve found an epmd (Erlang port mapper daemon) listening on a target system (tcp/4369). It is used to coordinate distributed erlang instances, but also can lead to a RCE, given one knows the so called “authentication cookie”. Usually, this cookie is located in ~/.erlang.cookie and is generated by erlang at the first start. If not modified or set manually it is a random string [A:Z] with a length of 20 characters. If an attacker gains this cookie, a RCE is quite easy – as I like to describe below.
We recently identified a security issue in FireEye AX 5400, that also affected other products. We responsibly disclosed the bug to FireEye and a fix that addresses the issue has been released with version 7.7.7. The fix was also merged into the common core and is available as 8.0.1 for other products (i.e. FireEye EX).
The git-shell is a restricted shell maintained by the git developers and is meant to be used as the upstream peer in a git remote session over a ssh tunnel. The basic idea behind this shell is to restrict the allowed commands in a ssh session to the ones required by git which are as follows:
git-receive-pack
Receives repository updates from the client.
git-upload-pack
Pushes repository updates to the client.
git-upload-archive
Pushes a repository archive to the client.
Besides those built-in commands, an administrator can also provide it’s own commands via shell scripts or other executable files. As those are typically completely custom, this post will concentrate on the built-in ones.
Note: This has nothing to do with the also recently fixed vulnerabilities in gitlab [1] [2].
This is the 3rd post in the series of Autonomic Network (AN), it will dedicated for discussing the vulnerabilities. I recommend reading the first 2 parts (part one, part two) to be familiar with the technology and how the proprietary protocol is constructed.
Initially we will discuss 2 of the reported CVEs, but later there is more CVEs to come 😉
This is the second part in the Autonomic Network series. We have introduced previously in our first part the Autonomic Network (AN), took a look about the needed configuration to run it on Cisco gear and what is the expected communication flow. In this post, we will dive deeper to have a closer look on the packets and how they are composed. Continue reading “Autonomic Networking – Part 2: Analysis”