the
last post was
about a fuse filesystem which provides a read-only access to the proprietary
bluecoat filesystem. After some further investigations based on the
possibilities this offered us, I started to implement a tool which allows to
modify parts of the filesystem.
Protection Mechanisms
Since last time, the discovered filesystem structures still had unknown fields.
Some of those fields could be reconstructed and their purpose in the whole
construct. The format of the Partition-Header for example could now be
described as
You may remember
our last post regarding
the SGOS system and the proprietary file system. Since then, we got access to a
newer version of the system (6.6.4.2). Still not the most current one (which
seems to be 6.7.1.1) nor of the 6.6.x branch (which seems to be 6.6.5.1) though.
As this system version also used the same proprietary filesystem (although it
initially booted from a FAT32 partition), I decided to take a deeper look into
this.
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.
As a part of our research time here at ERNW, last week we had an interesting
time looking at one of the widespread and commonly adopted proxy appliance by
many organizations Blue Coat Secure Gateway.
Introduction
The Blue Coat proxy Secure Gateway (SG) has been already in the market since
2001 [1]. The main aim of introducing the appliance was to achieve the
following goals [2]:
• High performance optimization.
• Increasing the security measurements, by introducing malware/spyware
protections, web based filtering, virus scanning and more.
• Flexible Access Control capabilities.
Sorry about the larger delay between the previous post and this one, but I was
very busy the last weeks.
(And the technology I wanted to show wasn’t completely implemented in radare2,
which means that I had to implement it on my own 😉 ). In case you’re new to
this series, you’ll find the previous posts
here.
As you may already know, we’ll deal with the third challenge today. The purpose
for this one is to introduce
some constructs which are often used in real programs.
Some of you (especially the .Net guys) might have heard of the query language
Linq (Language Integrated Query) used by Microsoft .Net applications and web
sites. It’s used to access data from various sources like databases, files and
internal lists. It can internally transform the accessed data in application
objects and provides filter mechanisms similar to SQL. As it is used directly
inside the application source code, it will be processed at compile time and not
interpreted at runtime. While this provides a great type safety and almost no
attack surface for injection attacks (except from possible handling problems in
the different backends), it is extremely difficult to implement a dynamic filter
system (e.g. for datatables which should allow users to select the column to
filter on). That’s probably the reason why Scott Guthrie (Executive Vice
President of the Cloud and Enterprise group in Microsoft, also one of the
founders of the .Net project)
presented the
System.Linq.Dynamic package as part of the VS-2008 samples in 2008. This library
allows to build Linq queries at runtime and therefore simplify dynamic filters.
But as you may know, dynamic interpretation of languages based on user input is
most of the time not the best option….
Last week, we decided to take a look onto the EMET library provided by
Microsoft. This library is intended to introduce several security features to
applications which are not explicitly compiled to use them.
It also adds an additional layer to protect against typical exploiting
techniques by filtering library calls, preventing usage of dangerous
functions/components and inserting mitigation technologies.
As EMET is already a target for many researchers, we currently only started to
get an overview of it’s structure and how the different components are
interacting with each other. Today we would like to share some of our results
with you.
Welcome back to the radare2 reversing tutorials. If you’ve missed the previous
parts, you can find them here and
here.
Last time we’ve used the rabin2 application to view the strings found inside
the challenge01 binary to find password candidates. Based on the results we
looked into the assembly to find the correct password. In this post, we’ll go
through the next challenge and try out some of the features provided by radare2.
Welcome back to the radare2 reversing tutorials. If you’ve missed the intro, you
can find it here.
The last time you got the challenge01 binary and your goal was to find the
password for the login. Let’s see how the application looks like:
$ ./challenge01
##################################
# Challenge 1 #
# #
# (c) 2016 Timo Schmid #
##################################
Enter Password: test
Wrong!
The first and simplest step would be to look for strings inside the binary. We
could do this either by using the unix utility strings or the binary analyzing
binary from radare rabin2:
As some of you may know, there is a “new” reverse engineering toolkit out there
which tries to compete with IDA Pro in terms of reverse engineering. I’m talking
about radare2, a framework for reversing,
patching, debugging and exploiting.
It has large scripting capabilities, runs on all major plattforms (Android,
GNU/Linux, [Net|Free|Open]BSD, iOS, OSX, QNX, w32, w64, Solaris, Haiku,
FirefoxOS and even on your pebble smartwatch 😉 ) and is free.