Hey there, for those of you that roll your eyes when writing the nth Information
Disclosure Finding in a report, here is a short story of how such information
helped compromising a system.
In a recent penetration we found a hidden debug page which disclosed information
about internal parameters. Along with database connection strings and key
material there was a username and a user home parameter disclosed on said debug
page.
Birk an me basically fully disclosed a 0day in
Squirrelmail yesterday. This is a short Q&A to
answer the most common questions about the issue to calm you all down a little
bit. 😉
What is the punchline, what do I need to know?
An attacker able to exploit this vulnerability can extract files of the server
the application is running on. This may include configuration files, log files
and additionally all files that are readable for all users on the system. This
issue is post-authentication. That means an attacker would need valid
credentials for the application to log in or needs to exploit an additional
vulnerability of which we are not aware of at this point of time.
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.
Extracting or capturing data from a transaction have been studied in different
ways, and some of the most common techniques are skimming, wireless skimming,
relay attacks,
traffic sniffing or
modifying a PoS(Point of Sale)
system. In our talk,
“NFC Payments: The Art of Relay & Replay Attacks”
at TROOPERS18, we will discuss a new technique and
methodology that malicious individuals could implement to extract data.
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.
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 😉
Here is a quick overview on how our network looks like for 2 CVEs