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.
It is a pleasant surprise for many (us included) that Microsoft implemented
support for the RDNSS (RFC 8106) option
in Router Advertisements beginning with the
Windows 10 Creators Update.
Interestingly, I wasn’t able to find any official documents from Microsoft
stating this. As we are involved in a lot of IPv6 related projects for our
customers, the lack of RDNSS support for Windows and DHCPv6 for Android is a
major pain point when implementing IPv6 in mixed client segments, as you need to
implement both mechanisms to ensure that all clients do get the relevant network
parameters. I won’t beat on the dead horse, but Microsoft’s decision is a huge
step in the right direction and one can hope that one day Google finds a
“compelling use case” to implement at least stateless DHCPv6 for Android.
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
Troopers ’17 – the 10th edition – madness is over and
hopefully all of you are well rested and recovered after this special week. Of
course the rest of the world did not stand still and thus Google lifted the
curtains on a new public portal collecting and promoting the Open Source
Software projects developed by employees of Google:
opensource.google.com. There are a lot of
interesting projects that might incubate new interesting developments. And even
security oriented tools and projects (51 at the time of writing to be precise)
are publically available [1].
Given the
CfP for Black Hat US in
Vegas ends in a few days – and as
apparently somepeople have
already started to think about their TR18 submissions – I’ll quickly provide
some loose recommendations on how to write a submission here. There’s quite some
reasonable advice out there already (the BH CfP site lists
this
and
this which
you should both read as well) but some of you might find it useful to get (yet)
another perspective.
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.
Cisco’s AN protocol is a proprietary one and as far as I know, the analysis
provided here for the protocol is the first of its kind.
Puh…it’s been a long time since my
last post,
huh?
However, let’s get straight back to topic. Today, I want to issue a warning,
especially in face of upcoming
Troopers 2017 (less than two days to go,
wooo! 10th anniversary!): be careful when using wireless equipment (presenters,
mouses, keyboards,…), especially during Troopers, but also in daily use.
TL;DR Please take into account that you put your laptop at risk of being hacked
by using wireless equipment during Troopers. This
could lead to a full system compromise. Wirelessly. Attacks like keystroke
injection or sniffing of latter and mouse movements are possible. This, e.g.
applies to speakers, using wireless presenters (like Logitech R400/R800, old and
new models), as also to any attendee or crew member who might use
wireless mouses or keyboards. Be aware of this!
This is a 3-part series which introduces and analyzes Cisco’s implementation for
Autonomic Network. In the 1st part, the technology is introduced and we have an
overview about communication flow. In the
2nd part, Cisco’s
proprietary protocol is reverse engineered ? then finally in the
3rd part,
multiple vulnerabilities will be disclosed for the first time. If you’re aware
of the technology, you can skip directly to part 2 where the action begins!
At CSA, I was talking about hypervisors, breakouts and an overview of security
measures to protect the host.
(Slides)
This ranged from the basic features some hypervisors provide out of the box to
advanced features like SELinux, device domain models and XSM-FLASK.
Most of the other talks were more targeted towards management level employees,
but even as a fairly technical person I found Mike Bursell’s
talk highly interesting. After my
talk about securing the host system from a malicious guest, he dealt with the
inverse: Technologies to protect a guest from a malicious or compromised host.
Last year I encountered a slight variation of an internal port scan
vulnerability for the CrystalReports component of SAP Business Objects. The
original vulnerability was presented and disclosed by rapid7 in the talk
“Hacking SAP Business Objects”. The corresponding slides can be found
here.
Basically, the original vulnerability allowed port scanning of (internal)
systems via the URL
http://hostname/CrystalReports/viewrpt.cwr?id=$ID&wid=$WID&apstoken=ip:port@$TOKEN.
By accessing this URL, different responses were received depending on if the
port (parameter port in the URL) of the system (parameter ip in the URL) was in
the state “open” or “closed”. The original vulnerability has been fixed a long
time ago (SAP security note 1432881), but the fix did allow for a slight
variation to make the attack work again.