Tested SGOS Version

The appliance that we already assessed during the last week belongs to the Blue Coat SG510 Series, and is equipped with an OS version SGOS 5.4.3.2. This version of the Operating System is quite outdated (there are CVEs dated back to 2010), but it’s rather complicated to get a hold of a firmware update w/o a running support contract. That’s why we decided to still investigate on this, so we could get a feeling for the used technologies.

Services and Management Interfaces

The Blue Coat appliance typically needs to be configured via a serial interface. This allowed us to set general settings like network addresses and the administrative accounts for the web and command line interfaces.

These interfaces provide the actual configuration to the administrators. The webinterface itself consists of two parts, a flash based interface and a java based one. The flash interface contains a subset of the available features of the java interface and might be used by read-only accounts. Both of them communicate with the web server by sending CLI commands in a multipart encoded post request.

If one connects to the SSH server with the configured credentials, he will find a command line interface comparable to cisco management shells. After enabling the administrative area, the same commands were available as sent by the web interfaces.

This suggested that the logic behind the web and command line interfaces is based on the same library or the same executable.

SGOS overview

To rise the technical portion of this post a bit, we want to share some of the collected information with you.

The SGOS (at least in this particular version) uses a custom filesystem to store it’s executables and files. After creating an image from the disk, we were able to take a deeper look of what’s going on during boot.

As no standard file system was used, a custom bootloader has to trigger the actual boot. The bootloader found performs the usual steps (copying itself at a specific region in memory, reading data from disk), the data read is a PE file starting from sector 664 or byte offset 339968 if (as usual) 1 sector = 512 bytes. Moving to this location, we found a 16-bit PE executable which seems to be the 2nd stage bootloader. This bootloader looks for a “boot record” at sector 4096 which consists of the following data

 0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
5f43 505f 2800 0000 0010 0000 4243 575a  _CP_(.......BCWZ
0010 0200 0000 0000 0000 0000 0000 0000  ................

The first 16 bytes seemed to be some sort of magic bytes, especially the first and the last 2 of them (_CP_ and BCWZ). The next four bytes specify where the next (“partition directory”) record is located (at offset 0x21000 in this case). This record also contains a magic bytes line like mentioned above:

 0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
5f43 505f 0c00 0000 0002 0000 5248 4450  _CP_........RHDP
0020 0000 0c00 0000 0300 0000 0000 0000  . ..............

It seemed that the first 4 bytes (0x2000) denote the size of the header (+ data?) in sectors. The meaning of the next 4 bytes is currently unknown, but the bytes starting at offset 0x18 seemed to indicate the number of available partitions. Based on this information, the actual partition records can be discovered.

 0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
5f43 505f 2800 0000 0002 0000 5945 4450  _CP_(.......YEDP
0020 0000 0100 0000 0100 0000 0000 0000  . ..............

Again, after the magic bytes, there is a 4 byte field containing the size (0x2000) and the purpose of the partition. It seemed like type 4 is used for the boot partition.

That’s were the current analysis regarding the file system ended (but may be continued…). During the analysis, we also recognized that the actual binaries were most of the time PE32 binaries, but also some ELF binaries were found. Due to the fact that a lot of these binaries were aligned to the offset 0x040 in the image, we simply extracted all data starting with a DOS header at these offsets. This resulted in approx. 580 dlls with more or less 120 unique samples. Most of them contained references to debug symbol files which allowed us to reconstruct their original name.

One of our first observations was that almost any functionality was written in C/C++ and additionally most of the programs seemed to be written by blue coat itself (very few third party libraries were found). Whilst this might introduce a higher probability of errors (depending on the level of coding guidelines), it simply doesn’t allow to exploit known vulnerabilities in widely used libraries. On the other hand, found vulnerabilities might be circulating in black markets without one ever noticing, as it’s more complicated to estimate the possible attack surface when only custom structures are used.