In the context of a customer project, we examined a new variant of the Locky
ransomware. As in the meantime stated by a law enforcement agency, this has been
part of a large wave of attacks hitting various enterprises in the night from
Tuesday (2016-07-26) to Wednesday.
As an initial attack vector, the attackers use emails with an attachment that
probably even uses a 0day exploit, that enables the payload to be executed
already when displayed in the MS Outlook preview.
As shown in previous blogposts we regularly work with GSM/GPRS basestations for
testing devices with cellular uplinks
or to simply run a
private network during TROOPERS.
Here the core difference between a random TROOPERS attendee and a device we want
to hack is the will to join our network, or not! While at the conference we hand
out own SIM cards which accept the TROOERPS GSM network as their “home network”
some device need to be pushed a little bit.
Every SIM card has it’s own home network, which is encoded in the fist five
(European standard) or six (North American standard) digits of its IMSI –
International Subscriber Number. The first three digits are the MCC, the Mobile
Country Code, the next two/three the MNC, Mobile Network Code. International
network overview are publicly available and for example
can be found >here<.
For instance, Germany has the MCC 262 and Vodafone Germany uses MNC 02. So a SIM
card with an IMSI starting with 26202 belongs to them.
Sticking to the settings in its own SIM card a device will always prefer to
connect to it’s own home network above all others. If the home network is not
available it will usually go for the strongest signal. To protect users from
unnecessary costs, an operator will usually add certain rules to prevent the
device from connecting to other networks in the same country. So if you’re an O2
customer in Germany, visit a shopping center and only have reception for a
T-Mobile cell, your phone will not directly jump into this network, even though
it’s the strongest signal source.
The moment, when your team leader asks you to cheat at Pokémon GO…everyone knows
it, right? No? Well, I do 😉
GPS Spoofing Setup
As I’m not a gamer, the technical part was of much more interest – that’s the
real gaming for me.
So, challenge accepted!
In the past I was often fiddling around with SDR (Software Defined Radio),
started with DVB-T sticks some years ago. When I came to ERNW in 2014 I got in
touch with
Michael Ossman’s great HackRF One for
the first time, and subsequently my thesis was based on SDR.
Jenkins is a continuous integration server, widely
used in Java environments for building automation and deployment. The project
recently disclosed an unauthenticated remote code execution vulnerability
discovered by Moritz Bechler. Depending on the development environment, a
Jenkins server can be a critical part of the infrastructure: It often creates
the application packages that later will be deployed on production application
servers. If an attacker can execute arbitrary code, s/he can easily manipulate
those packages and inject additional code. Another scenario would be that the
attacker stealing credentials, like passwords, private keys that are used for
authentication in the deployment process or similar.
On the 8th of March SAP released the security note for a vulnerability we
reported during an assessment of a SAP landscape. The issue affects the SAP
NetWeaver Web Administration Interface. By knowing a special URL a malicious
user can acquire version information about the services enabled in the SAP
system as well as the operating system used. We wanted to share some details on
the issue.
The vulnerability is a bypass of the HTTP Basic Authorization for the
SAP Web Administration Interface.
It discloses version information about the system respectively operating system,
a brief SAP patch level overview and running services including their
corresponding ports.
In our talk
IMSEcure – Attacking VoLTE
Brian and me presented some theoretical and practical attacks against IP
Multimedia Subsystems (IMS). Some of the attacks already have been introduced in
a former
blogpost
and Ahmad
continued
with a deeper analysis of the Flooding and targeted DoS scenario. But still,
there are some open topics I’d like to continue with now. The methods I am
demonstrating here also help to get a better understanding of VoLTE/IMS and how
it is implemented on modern smartphones.
Security Assertion Markup Language (SAML) is an XML standard for exchanging
authentication and authorization data between a Service Provider (SP) and an
Identification Provider (IdP). SAML is used in many Single Sign-On (SSO)
implementations, when a user is authenticated once by IdP to access multiple
related SPs. When a user requests to access a SP, it creates a SAML
Authentication Request and redirects the user to IdP to be authenticated
according to this authentication request. If the user is successfully
authenticated, IdP creates a SAML authentication response and sends it back to
SP through the user’s browser.
Some of you might have noticed the
articles, or
the leaked
manual itself,
about a tool called ULIN. ULIN is a “bleeding-edge spy tool” for mobile
communication networks. According to the manual, it is aimed to be a
surveillance software for agencies (or others with enough money) for tracking
and intercepting the Voice Calls and SMS of arbitrary phones. They call this
“remote recording and geolocation of mobile handsets using 2G/3G/4G networks”.
Recently I’ve started some research on MikroTik’s RouterOS, the operating system
that ships with RouterBOARD devices. As I’m running such a device myself, one
day I got curious about security vulnerabilities that have been reported on the
operating system and the running services as it comes with tons of
features. Searching
for known vulnerabilities in RouterOS on Google doesn’t really yield a lot of
recent security related stuff. So I thought, there is either a lack of (public)
research or maybe it is super secure… 🙂
As you may have already noticed, Cisco released an urgent
security advisory
describing an IPv6 Neighbor Discovery DoS Vulnerability in several flavors of
Cisco’s operating systems. Currently IOS-XR, XE and NX-OS are affected while ASA
and “classic” IOS are under investigation. At first glance, it might look like
yet another IPv6 DoS vulnerability. Looking closer, Cisco is mentioning an
unauthenticated, remote attacker due to insufficient processing logic for
crafted IPv6 NDP packets that are sent to an affected device. Following the
public discussion about the vulnerability, it seems that these packets will
reach the, probably low rate-limited,
LPTS filter/queue
on IOS XR devices “crowding” out legitimate NDP packets resulting in a DoS for
IPv6 traffic, or in general a high CPU load as these packets will be processed
by the CPU. More details are currently not available, but this might indicate
the affected systems aren’t doing proper message validation checks on NDP
packets (in addition to the LPTS filter/queue problem).
