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.