The Solfa Cipher (NSEC17 Write-Up)

Share

Introduction

Between May 19th and 21st, 2017, I’ve participated to the NSEC 17 Capture-the-Flag (CtF) event held annually in Montreal, QC. As usual, the team and I had a blast spending days and nights solving challenges and drinking free beer. Among the challenges was a two-part cryptographic puzzle printed on the first and last pages of the passport of Rao’s Intricate Kingdom – the country part of the story line of the event. The challenge was divided in two parts: a Braille encoded message and the second part was encrypted using the Solfa cipher, which I had never heard of before. As such I decided to learn more about it and complete a write-up for the challenge at the same time. I’ll first quickly cover the Braille part of the challenge, then move on to the Solfa part of it and the decryption process.

The Second Half of the Flag

Upon entrance at the NSEC competition this year, participants received a passport designed to be stamped based on events happening during the CtF. The back of the front cover contains a sequence of dotted symbols which can be recognized quickly as Braille as shown in the figure below:

Braille-encoded message in Rao's Passport
Figure 1: Braille-encoded message in Rao’s Passport at NSEC’17

As most of you probably know, the Braille writing system was developed for the blind and visually impaired individuals to be able to read using touch. Examples of braille can often be found on elevators. The system is based on a matrix of 3×2 dots which can be blank or filled. Each dot is numbered from 1 to 6 as shown below:

Braille Matrix Numbers
Figure 2: A matrix of the 6 dots representing an individual character Braille

Each character of a natural alphabet can then be associated with a specific matrix configuration. For example, a simple Braille-English translation is shown below:

The Braille Alphabet
Figure 3: The Braille Alphabet (linked from pharmabraille.com)

Additional “shortcut” symbols are used for specific sounds, punctuation, symbols and words. The figure below shows some examples of common words in Braille:

Braille for words and abbreviations
Figure 4: Braille for words and abbreviations (from the Tennessee Council of the Blind)

Additional abbreviations can be found in [1]. Going back to the passport, we can obtain the transcription using Unicode:

⠠⠮⠀⠎⠑⠒⠙⠀⠓⠁⠇⠋⠀⠷⠀⠮⠀⠋⠇⠁⠛⠀⠊⠎⠀⠮⠀⠘⠺
⠠⠏⠇⠁⠞⠽⠏⠥⠎⠲⠀⠠⠁⠙⠙⠀⠭⠀⠁⠋⠀⠮⠀⠋⠌⠀⠓⠁⠇⠋⠀⠞⠕
⠕⠃⠞⠁⠔⠀⠁⠀⠉⠕⠍⠏⠇⠑⠞⠑⠀⠋⠇⠁⠛⠲⠀⠠⠛⠇⠕⠗⠽⠀⠞⠕
⠀⠠⠠⠗⠁⠕

We then translate into English and obtain the following translation from Braille to English.:

(Cap) THE S E CON D H A L F OF THE F L A
G I S THE  (Cap) P L A T Y P U S
. (Cap) A D D X A FTER THE F IRST H A L F
T O O B T A  IN  A  C O M P L E T
E F L A G . (Cap) G L O R Y T O
 (Cap) R A O

Table 1: Resulting message from translating from Braille to English.

Putting everything together, we obtain the first part of the flag included in the passport:

The second half of the flag is the word Platypus. Add x after the first half to obtain a complete flag. Glory to Rao

First Half of the Flag

The second part of the flag is much more obscure and less documented than the first one. The inside of cover page contains a small partition holding a total of 4 staves: the first one appears to be a chord while the last 3 are simply a sequence of notes. We noticed that the first staff contains a treble clef, the label “KEY-997” and is shorter than the other staves. Furthermore it contains the type of notes

Music Sheet in the Rao's Passport
Figure 5: Scanned copy of the lullaby on the last page of Rao’s passport.

Clearly, there is something in there, but how do we extract a flag out of this? My knowledge of music theory is extremely low and was basically non-existent prior to this challenge. As such feel free correct me in the comments if I misrepresent a musical concept or term.

The Cipher

Googling for words relating to music and cryptography will return a limited set of relevant sites, the first relating to musical cryptograms, which is not quite was we are looking for at the moment. The second page is about the Solfa Cipher. Once you’ve found the latter website, you’re almost at the solution, but let’s take a better look at it.

The Solfa cipher is a substitution cipher, but rather than using an alphabet to encode keys and cipher text, it uses musical notation. The encryption/decryption key is defined using a clef, a tonic, a mode and a rhythmic unit. The links will provide a much better definition of each different item than I could ever do in this article. However, be aware that the 4 elements mentioned above can have the following values:

Clefs Tonic Mode Rhythmic Unit
Treble C, C# Minor 1/4 (Quarter)
Alto D♭, D Major 1/8 (Eighth)
Bass E♭, E Phrygian 1/16 (Sixteenth)
F, F# Dorian
G♭, G Lydian
A♭, A Mixolydian
B♭, B Locrian

Table 2: Valid values for the properties of the Solfa key.

Like any symmetric cipher, a key is needed to encrypt the message, which will have to be shared with the intended recipients of the message. In this case, the key is in musical notation rather than a sequence of characters or bytes. The first staff of the page represents the key of the cipher, as the label clearly shows. The encryption key is composed of the four elements mentioned above: a treble clef, in C minor, using 1/8 as the rhythmic unit:

Solfa Cipher Key used in NSEC17
Figure 6: Solfa Cipher Key used in the passport at NSEC ’17: treble key in C minor with a 1/8 rhythm is used.

Each note is linked to a the seven pitches of the solfege, i.e. Do (D), Re (R), Mi (M), Fa (F), Sol (S), La (L) and Si (T). The “KEY-554” is only a randomly generated label and has no significance in the algorithm. With the key known, this puzzle becomes a chain of translations from musical notes to a list of tuple of tones and rhythms using the standard matrix below:

Do (D) Re (R) Mi (M) Fa (F) So (S) La (L) Ti (T)
1:  T I A S E N O  :1
2:  K Z X J Å Æ  :2
3: R C H M D L U  :3
4: F Y G P W B V  :4

Table 3: English language translation matrix usually used for the Solfa cipher.

The columns represents the pitch, while the rows represent the duration of the note (1, 2, 3 or 4).

Let’s go through a complete example to better understand the process. Consider the staff below:

Example of a Solfa-encrypted message
Figure 7: The word “SOLFA” encrypted using the Solfa Cipher

In this case, we assume that we are using a 4/4 meter i.e. the length of a single measure.  That means that each measure has a duration of 4 units. The key used to generate this melody was in C major, with a clef of Treble and a rhythmic unit of 1/4 (Quarter). The first note is Fa and starts at the first time unit, i.e. 1. Therefore the first note can be translated to (F, 1). The Fa is 4 units long, meaning that the second note, Si, also starts at time 1, translating to (T, 1). However this time, the note is only 2 time units long and thus the third note – Sol – starts at 3 and lasts only 1 time unit. Thus the third node is translated to (S, 3) while the fourth one will be translated to (D, 4). Finally, the last note is a Mi and starts at 1 and thus is translated to (M, 1). Putting everything together we have (F, 1), (T, 1), (S, 3), (D, 4) and (M, 1). Using the matrix above, we obtain (F, 1) = “S”, (T, 1) = “O”, (S, 3) = “L”, (D, 4) = “F” and (M, 1) = “A” and thus the plain text is the word “SOLFA”. This process is better represented in the figure below:

Decryption of the Solfa-encrypted word "SOLFA"
Figure 8: Decryption of the word “SOLFA” by reading the notes and their duration.

Going back to the NSEC challenge, we have a much larger melody to decrypt. Luckily, we have the key and the same process as the one we used to decrypt the cipher text in figure 8 applies.

Solfa-encrypted Message from the Passport
Figure 9: Solfa-encrypted Message from the Passport in NSEC ’17

Let’s take the first 9 notes listed in the figure above. For each of the note, we first determine its pitch (do, re, mi, …) and then its duration. The key given specify a 1/8 rhythm, as such a Eighth note will be worth 1 time unit, a Quarter note will be worth 2 time units and the half note will be worth 4 time units. Unless specified otherwise, the meter is 4/4, i.e. a measure is 4 time units long.

First 9 notes of Solfa encrypted for NSEC
Figure 10: The first 9 notes of the Solfa-encrypted message and the initial tempo of the melody.

Using the figure above, we can then extract the notes and their time from the partition:

The note is used as the column and the time as the row to read the corresponding value defined in the translation matrix. We can put a quick script what will read these notes and find the corresponding characters. Using table 3, the notes above will be translated to

d, 1 m, 3 s, 1 d, 4 r, 1 d, 3 m, 4 d, 1 m, 3
T H E F I R S T H

Table 4: First 9 characters decrypted from the partition at the back of the passport.

Applying this process to every note in the figure 9, we obtain the following message:

THEFIRSTHALFOFTHEFLAGISTHEWORDSUBDERMALCONCATENATEWITHTHESECONDHALFTOOBTAINACOMPLETEFLAGGLORYTORAO

Or with spaces and punctuation added: “The first half of the flag is the word subdermal. Concatenate with the second half to obtain a complete flag. Glory to Rao“. Mixing the 2 halfs of the flag, we get the string “SUBDERMALxPlatypus” and get 5 points out of it.

In case you are wondering what the melody in figure 9 sounds like, you can download the resulting MIDI file here: A Revolutionary Lullaby.

Conclusion

Braille and Solfa are quick and fun ways to encode/encrypt data in unusual ways. While they obviously should not be used for serious application, they could potentially be used as novel ways to exfiltrate data and bypass some filters. For example, a text file could be Base32 encoded and the padding character (“=”) could be replace with the number 1 for example. Then the resulting string could be encrypted using the Solfa cipher, transformed into a MIDI file and then uploaded to a remote location. I highly suspect that most network security appliances would not pick up on MIDI file being uploaded, although it would probably strike a careful analyst as suspicious. Feel free to experiment with it. A partial Python implementation can be found here.

References

[1] Simpson, C,  The Rules of Unified English Braille, Second Edition, 2013, International Council on English Braille, https://www.pharmabraille.com/wp-content/uploads/2015/11/Rules-of-Unified-English-Braille-2013.pdf, Visited on 2017-06-05

[2] Chambers, John, An ABC primer, http://trillian.mit.edu/~jc/doc/doc/ABCprimer.html, Visited on 2017-06-04

[3] Solfa Cipher, 2013, http://www.wmich.edu/mus-theo/solfa-cipher/index.html, visited on 2017-06-06

Additional Readings

Schneier, Bruce. Applied cryptography: protocols, algorithms, and source code in C. john wiley & sons, 2007.

Carter, Nicholas. Music Theory: From Absolute Beginner to Expert: The Ultimate Step-by-step Guide to Learning Music Theory Effortlessly. United States: CreateSpace Independent Platform, 2016. Print.

The Byte-BOS Real-Time Multitasking Operating System

Compared to operating systems in general computing, the world of embedded devices remains a world to be discovered by security analysts and hackers alike, and it offers much to explore. While reverse engineering of many newer appliances is revealing well known operating systems such as Windows or Linux, others remains fairly unexplored, such as TinyOS or μOS. Legacy devices, still in used across many industries, also provide a rich variety of unknown software and architectures. One of them is the Byte-BOS Real-Time Multitasking Operating System (RTMOS).

Share

Introduction

Compared to operating systems in general computing, the world of embedded devices remains a world to be discovered by security analysts and hackers alike, and it offers much to explore. While reverse engineering of many newer appliances is revealing well known operating systems such as Windows or Linux, others remain fairly unexplored, such as TinyOS or μOS. Legacy devices, still in use across many industries, also provide a rich variety of unknown software and architectures. One of them is the Byte-BOS Real-Time Multitasking Operating System (RTMOS). This short article attempts, based on limited information, to detail this little known system, explore its history, usage and basic composition.

History

The Byte-BOS RTMOS was initially developed in 1994 by Numerical Services Inc. The company, defunct since 2004, sold the full C source code of the RTMOS to customers for 7495 $USD. Possession of the source code allowed the buyer full customization of the operating system according to the device being designed. The system supported a restricted set of microcontrollers (see table 1) including the Intel x86 and Motorola M68000. Other lesser known microprocessors supported included architectures from Hitachi, Mitsubishi and Texas Instruments, which were used in embedded devices within the medical, industrial and telecommunications sectors. Due to the long life-cycle of these devices, it may still be possible to identify devices leveraging the Byte-BOS RTMOS. Development and support for the RTMOS ceased around 2004. As such, documentation is very scarce, and remnants of information are available only via the Internet Archive [1]. At the time of writing, the domain “www.bytebos.com” resolves to “Scheumacher Engineering”, owned by the original developer of Byte-BOS. However the website is nothing more than a single page which was last updated in 2013.

Table 1 – Microprocessors supported by the Byte-BOS RTMOS.
Intel 80×86 Coldfire Mitsubishi M16C Texas Instruments
C2x/C5x DSP
Intel 80188/86 Motorola 68000 Mitsubishi M32D Texas Instruments
C3x/C4x DSP
Intel 80×86 (32bit) Motorola 68HC11 Hitachi H8300 ARM/THUMB
Intel 8096 Motorola 68HC16 Hitachi H8300H
Intel i960 Mitsubishi
M37700
Hitachi SHX

Description

The Byte-BOS RTMOS is a minimal operating system providing task scheduling management for user applications, along with typical OS activities such as interprocess messaging, memory allocation and prioritization. It performs pre-emptive and non-pre-emptive scheduling of an unlimited number of queued tasks. The system enforces scheduling via interrupt service routines (ISRs) which can suspend and/or resume tasks based on events and their priority. When multiple tasks with a similar priority are requesting resources, the RTMOS assign the resources via a round-robin selection method.

As other operating systems, memory allocation appears to follow a standard process by keeping track of used and free memory chunks via a heap implemented by a double-linked list, which is the data structure used across the RTMOS to store unlimited numbers of objects. Tasks can dynamically allocate and free memory as needed. It also manages events and interaction with devices on behalf of user applications by abstracting the underlying hardware via a Device object (see figure 1). Byte-BOS also provides inter-tasks communications mechanisms for synchronization amongst tasks such as messages and semaphores.  In terms of data structures the double linked list and buffer objects appear to be the main structures used across the RTOS. Memory chunks, tasks and most of the other objects are all managed via the List object.  It also supports the queue structure used to manage tasks. A software stack is also provided and used by tasks to run.

Security-wise, Byte-BOS does not have any authentication or specific security methods for access to memory or special “kernel” functions; all tasks have the same level of authority than the RTOS. Basically, Byte-BOS is completely flat.

Architecture

The RTMOS is written in C or specific variety of C specification depending on the targeted microprocessor. The 10 main components of the operating systems are represented in figure 1 and provide an excellent overview of the functions accomplished. A simulated “this” pointer to the various “struct”s is made available to the developer to give an Oriented-Object Programming (OOP) feel. This section describes briefly the main components of Byte-BOS, along with some of the features marketed by the original developer.

UML Representation of the different objectsfooun in the Byte-BOS RTMOS
Figure 1 – UML Representation of the different objects defined in the Byte-BOS RTMOS

The Task Object

The main object of the RTMOS is the Task object, which is very similar to the similar concept modern software development. Just as in any C/C++ object, a constructor is initiated prior to executing the body of the task, which is defined by the developer to conduct a specific task. Data of the task is allocated and accessible via the this_data pointer. Tasks also allocate sub-objects, opens required devices, initialize variables and synchronize state machines. Once constructed, the task runs its main function until it returns or is removed. Access to a task is done via the this_task pointer. Both pointers described are always in scope and usable within the task. Once the main task completes, the destructor of the structure is called, which frees memory and pointers of sub-objects. It also terminates any internal state machine.

The Memory Object

This object manages the memory heap and stores the pointer to the heap, the block size and the number of memory blocks. It also exposes various functions for memory management, mainly alloc_fmem and free_fmem. The heap is implemented using a double-linked list in which each node contains metadata about the memory blocks. While details are not available, it can be assumed that the size of the block, its status (free or allocated) and a pointer to the next block is included.

The Semaphore Object

As its name implies, the Semaphore is used for signaling and control between multiple tasks by either being in the Up or Down status. A timeout can be defined as needed.

The MessageBox Object

The MessageBox acts as a central repository for tasks to exchange data. Tasks and ISRs can create messages to initiate other tasks or exchange . The MessageBox basically provides two functions: put and get. When a new message is created, memory is allocated. Similarly, the memory is freed when retrieved from the box.

The Timer Object

Similar to any standard timer in other system, this object is used to create timeouts and schedules of tasks and events.

The Event Object

Events are created by tasks and ISRs to schedule other tasks.

The Device Object

This item abstracts interaction between the user application and the hardware device. It does so by pointing to the memory blocks used by the device and managing input/output to the area.

The List, Queue and Buffer Objects

These objects, as their name implies, are implementation of a linked list, a queue and buffer data structures.

Features

Byte-BOS boasted the following additional features on their website from 2000, providing some extra insight on the internals of the system.

Interrupt Handling

ISRs can make operating systems calls and schedule tasks by including the ENTER_ISR and EXIT_ISR macros at the beginning and end of the routine. Most services are available to ISRs, giving them considerable access over the entire OS.

Critical Section Handling

Byte-BOS provides critical section handling by protecting non-reentrant code sections from both interrupt and task pre-emption. Protection of critical sections appears to be done via the following mechanisms:

  • Disabling interrupts
  • Locking and unlocking code sections
  • Prioritization of tasks

Task Execution Trace

Tasks are provided with a trace buffer configurable at both compile time and run time. The trace buffer contains information about the sequence of calls, the parameters passed, and the return value of the called function. The tracing option is extremely useful for debugging purposes.

System Requirements

The Byte-BOS RTMOS requires very little in terms of resources. While the requirements varies depending on the underlying processor, the size of the kernel is a few kilobytes, while the RAM requirements are less than 100 bytes of globally accessible memory and less than 100 bytes per task and ISR. The detail figures are listed in table 2.

Table 2 – Memory requirements for the Byte-BOS RTMOS according to microprocessor
Microprocessor Minimum Kernel
Size (KB)
Maximum Kernel
Size (KB)
RAM Requirement
for Global Variables
(bytes)
RAM Requirement
per Task (bytes)
Intel 80×86* 4 10 28 30
Intel 80×86
(32bit)*
6 15 48 58
Intel 80188/86* 2 10 28 30
Intel 8096 2 8 20 20
Motorola 68000 1.5 12 50 70
Motorola 68HC11 1.2 8 28 20
Motorola 68HC16 2 8 28 20
Mitsubishi M37700 2 10 28 20
Mitsubishi M16C 2 12 64 48
Mitsubishi M32D N/A N/A N/A N/A
Hitachi H8300 1.2 8 28 20
Hitachi H8300H 2 10 38 40
Hitachi SHX 7.8 19.5 72 60
Texas Instruments
C2x/C5x DSP
1.2 8 28 20
Texas Instruments
C3x/C4x DSP
2.3 19.5 28 words 20 words
ARM/THUMB 4 15 50  70

* For Intel-based architecture, the memory footprint reported above is based on usage of the Borland C++ compiler.

Additional volatile memory is required for objects created dynamically. As such, the numbers provided above do not represent the total amount of memory consumed by Byte-BOS.

Compilers Supported

In general, Byte-BOS supports the development tools and compilers provided by the semi-conductor manufacturer. For Intel-based processors, the Borland C/C++ compiler was supported. The complete list of supported compilers is provided in table 3.

Table 3 – Supported compilers by the Byte-BOS RTMOS.
Microprocessor Supported Compilers
Intel 80×86 Microsoft C/C++ (large model)
Borland C/C++
Watcom C/C++
Intel 80×86(32bit) Watcom, Metaware and most of C compilers
Intel 80188/86 Microsoft C/C++ (large model)
Borland C/C++
Intel 8096 IAR
BSO Tasking Compiler
Motorola 68000 Cross-Code
Intermetrics
Introl
Microtec
Motorola 68HC11 IAR
Introl
Cosmic
Motorola 68HC16 Introl
Cosmic
Mitsubishi M37700 IAR
Microtec
Mitsubishi M16C IAR
Mitsubishi Compiler
Mitsubishi M32D N/A
Hitachi H8300 IAR
Microtec
Hitachi H8300H IAR
Hitachi SHX GNU
Green Hills
Texas Instruments
C2x/C5x DSP
Code Composer /
Texas Instrument Compiler
Texas Instruments
C3x/C4x DSP
Code Composer /
Texas Instrument Compiler
ARM/THUMB  ARM

Identification

Devices using the Byte-BOS RTMOS can be identified by looking at ASCII and Unicode strings in their firmware. In almost all cases, if not all, the firmware will contain a copyright notice identifying it as well as the target microcontroller it was compiled for. For example, by extracting the strings from the firmware for the Seagate Cheetah 10K.6 Disc Drive, either using the simple strings.exe (or strings in Linux) or IDA, the copyright notice string “Byte-BOS 8096 Multitasking Operating System — Copyright 1990 Numerical Services Inc.” can be observed (see figure 2).

Byte-BOS Copyright Notice into the Firmware of the Seagate 10K.6 Disc Drive
Figure 2 – Byte-BOS Copyright Notice into the Firmware of the Seagate 10K.6 Disc Drive

While appliances posterior to 2004 will likely use modern RTMOS such as Linux , Byte-BOS can still be found on legacy devices. One such example is the Baxter IPump pain management medical device, which refers to its usage in the manual [2]. Of note, the manual refers to the detection of stack overflows within the Byte-BOS RTMOS. Industrial controls, aircraft, telecommunications systems and other systems designed prior to the 2000s may still harbour this little known RTMOS.

Conclusion

The Byte-BOS RTMOS will likely disappear as legacy embedded devices are life-cycled for newer systems with more processing power and extended memory. Until that moment, for developers of these systems, or simple hobbyists, information remains scarce and limited. While we provided a brief overview of its architecture and features, details about creating user applications remains obscured by the lack of online information such as an API description, code examples or more importantly, the source code. Such data would greatly ease development and engineering efforts of legacy systems.

References

[1] “Bytebos Home Page.” Bytebos Home Page. Internet Archive, 20 Oct. 2000. Web. 01 Nov. 2015. <https://web.archive.org/web/19990208011926/http://www.bytebos.com/>.

[2] Baxter IPump Pain Management System – Service Manual, Baxter Healthcare Corporation, Chapter 4 – Troubleshooting, p.4-8. 2007. Web. 01 Nov. 2015. <Link>

Starting in Exploit Writing – Day 06

Share

Time for tutorial 6 (yeah I skipped #5, as I got the gist of it). After 6 days, I really got the hang of buffer overflows…too bad they aren’t much in use anymore, but everyone has to start somewhere. So below is EIP and SEH being overflowed with 0x0041, indicating that our “A” where translated to Unicode characters.

Buffer Overflow in Trilogic Player
EIP is being overflowed by 0x0041, indicading a buffer overflow with Unicode characters

Mona locates the Metasploit pattern overwriting SEH at 536. So our payload will be something like

And everything falls in place;

Overwriting nSEH and SEH in Trilogic
Both nSEH and SEH are overwritten with the expected values.

This is where it gets tricky. When following the tutorial, I was never able to see that EIP contained 0x00440044. It actually contained 0x00440045 after moving after the Access Violation exception. I can clearly see that SEH has been overwritten with 0x00420042 and 0x00430043. Fortunately according to one comment, I’m not the only one. When I tried to put 534 bytes of junk rather than 536, I end up with 0x0042004D in EIP (difference of 8). I don’t get why it does that.

At least I’m confident I understand the concepts, but that’s pretty much useless if I cannot put it into practice. For this example, mona can find POP-POP-RET addresses that will work when translated to Unicode. From my understanding, [nSEH] will be useless in Unicode-based exploit, simply because there’s no easy way to have a jump matching Unicode encoding. As such, we’ll need to jump to a register which contains a address close to our shell code and either 1) make sure no instruction between the address and shell code will break the exploit or 2) modify the register (add/sub) to have it jump into a NOP slide to our shell code…and then we have to figure out the shell code, but from what I read, talented people have already took care of this for us.

Useful sites (a.k.a shit I need to read):

  1. http://ref.x86asm.net/coder32.html
  2. http://www.blackhat.com/presentations/win-usa-04/bh-win-04-fx.pdf
  3. https://www.corelan.be/index.php/2009/11/06/exploit-writing-tutorial-part-7-unicode-from-0x00410041-to-calc/

Starting in Exploit Writing – Day 05

Share

Today we’ll be studying “egg hunters” as of part 4 of the FuzzySecurity tutorials. Basically this technique is useful when the buffer remaining for your shell code is too small to do anything useful. So far we’ve been lucky and we had huge buffers to inject the shell code, but some time, you may be left with a couple of bytes only. With a “egg hunter”, instead of storing your shell code, you store a small function that will look for “magic bytes” in memory. Your shell code somewhere else in executable memory and tagged with these “magic bytes” so that your egg hunter finds it and executes it. Pretty straight forward.

Exploiting Kolibri Web Server

So my goal today was to test out the egg hunter example from the tutorial. However I got cocky and try to exploit the web server by smashing SEH rather than a normal buffer overflow. Everything went fine until I had to call the address containing the POP-POP-RET.

SEH Exploitation of the Kolibri Web Server
Exploitation of Kolibiri Web Server using the SEH Techique

The problem I’m running into is when looking for a “POP POP RET”, all the results are within Kolibri.exe, and all addresses starts with a null byte, i.e. “\x08\x89\x51\x00”. That means our payload will terminate at the null byte. I thought this wouldn’t be much of a problem, since [SEH] is an address anyway, the only difficulty would be that I may have to put the payload in the buffer prior to the [nSEH], and have a short jmp into the buffer placed into the [nSEH]. Now for some reason, it seems that SEH catches the exception, but never jumps to my POP-POP-RET address; it just terminates the program.

Pop-Pop-Ret Instructions from Kolibri Web Server
All the Pop-pop-ret instructions are located in Kolibri.exe and contains a null byte.

So I got stuck here for today. More to follow tomorrow

Sending mail directly using SMTP

Share

Since this is another thing I keep forgetting, I’ll just note it here. To send send emails by connecting directly to the SMTP port of a mail server with telnet, use these commands;

  1. telnet open.mailserver.com 25
  2. HELO domain.com
  3. MAIL FROM: whatever@domain.com
  4. RCPT TO: target@localhost.com
  5. DATA
  6. Subject:
  7. Cc:
  8. Reply-To:
  9. <message>
  10. MIME-Version: 1.0
  11. Content-Type: <content>; boundary=”<bondary>”
  12. Base64 encoded attachment
  13. <CR-LF>.<CR-LF>
  14. Quit

Since I’ll likely forget again, I’ve script some Python for it:

A small and quick introduction to ARP poisoning

Share

This article won’t be about something new nor something extraordinary for any experienced computer security or even the average hacker, but since I’ve been ask this question quite often by some of my friends, I decided to explain how to sniff passwords from a network.  Moreover, I’m well aware I haven’t been writing anything for a while, and I want to get back to it once all my personal matters are resolved. I’ll concentrate on WEP wireless networks since they are almost certain to be cracked easily. Although those a deprecated, there are still used in many household as the out-of-the-box default configuration, so it’s still pertinent in my opinion. Then I will explain the ARP (Address Resolution Protocol) poisoning attack, which will be used to intercept packets between the target and the Internet.

Attacking the WEP wireless network

Packets in a WEP network are encryted, so in order to sniff packets off from it, you’ll first need to acquire the WEP key. This can be done easily with a wireless network adapter that supports monitor mode and the aircrack suite. For the adapter, I’m using the Linksys  Compact Wireless-G USB adapter, model no WUSB54GC. Plug your adapter into a USB connector and boot up your machine. Once you have booted up, make sure Backtrack or any other distribution has detected your adapter:

ifconfig rausb0 up

and then put the adapter in “Monitor Mode”

iwconfig rausb0 mode monitor

The goal of a WEP attack is to capture as many initialization vectors (IVs) as possible. IVs are random numbers used with a either 64, 128 and 256-bit key to encrypt a stream cipher. Those are used so that two exact same plain text do not produce the same ciphertext. The problem with WEP is that IVs are very short, and on a busy network, the same vectors get reused quickly. The IV is 24 bit long, therefore there are 16 777 216 possibilities1. Moreover, changing the IV for each packet is optional. The keys are also quite short, therefore opening the possibility of finding the key with some brute force calculation. No matter what is they key length, you will just need more packets.

The WEP protocol then use the randomly generated IV, the WEP key and pass it throught the RC4 cipher to produce a keystream. The keystream is then XORed with the plain text stream to produce the cipher text, as shown in the picture below:

WEP Encryption Schema
WEP Encryption Schema (from Wikipedia)

So basically, if you get many packets with the same Ivs, different ciphertext, you can now try to brute-force the WEP key. And to get those packets, you need traffic on the network. Now if there are already some people connected and surfing the web, you can easily capture packets and replay them to get more IVs, otherwise, you need to generate the traffic yourself.

Once you’ve tell airodump to capture IVs, we will use aireplay to generate more traffic, and therefore capture more IVs quickly. If you look at the airodump screen, you’ll see it capturing packets.

Once you have the key, you can finally start the poisoning process. As you have seen, I have not detailed how to crack a WEP network as it is widely described all over the net. You can find find good video tutorials from InfinityExists here and here. The last 2600 issue also had a good article about it.

The ARP poisoning attack

The concept behind this is simple. ARP is the protocol that maintains network devices tables up-to-date by associating an IP address with a MAC address. The problem with ARP is that it doesn’t really care about who answered, it will gladly update the tables from whoever says so. Most of the time, it won’t even ask. So the idea behind the attack, is to send the client an ARP answer saying “hey, I’m the gateway, send stuff to me” and a second ARP answer to the real gateway saying “hey there, I’m this guy, send me his stuff”. Then you just have to relay the packets between the victim and the gateway.Those schemas are more simply to understand:

Schema of an ARP Poisoning Attack
Schema of an ARP Poisoning Attack

In Linux, the rerouting can be done using the following iptables commands:

iptables -t nat -A PREROUTING -i <interface> -p tcp –dport <port> -j REDIRECT –to-port <redirection port>

iptables -t nat -D PREROUTING -i <interface> -p tcp –dport <port> -j REDIRECT –to-port <redirection port>

I’m showing those commands because you can do a lot with those. Many web applications such as some Flash applications use RTMP (Real-time messaging protocol) to control web applications, which run locally.  Flash server send commands to the application using message. Using those commands, you can filter the packets send or receive from the Flash server. Simply use a sniffer first, then locate which packets you wish to drop, alter or whatever.

For example, some sites gives you samples of live music or videos for 30 seconds, then nag you to pay. Using a sniffer, analyze the traffic and find that RTMP Invoke packet that closes the connection with the server. Code a quick proxy that will let all packets go to the flash application except for the connection closing RTMP packet. Then use the commands above to redirect traffic to your proxy.

00 03 0d 4f c0 6d 00 11  20 a8 32 8b 08 00 45 00 …O.m..  .2…E.
00 b2 7e 52 40 00 78 06  d0 a1 50 4d 74 05 43 c1 ..~R@.x. ..PMt.C.
ab 3e 07 8f d0 d8 9b a6  b0 eb ea 61 49 3d 80 18 .>…… …aI=..
fe 4a 76 52 00 00 01 01  08 0a 00 ef a6 d0 02 43 .JvR…. …….C
f4 32 43 00 00 00 00 00  76 14 02 00 0f 63 6c 6f .2C….. v….clo
73 65 43 6f 6e 6e 65 63  74 69 6f 6e 00 00 00 00 seConnec tion….
00 00 00 00 00 05 02 00  57 32 30 38 20 46 72 65 …….. W208 Fre
65 63 68 61 74 20 61 63  74 69 76 69 74 79 20 74 echat ac tivity t
69 6d 65 6f 75 74 2e 20  49 66 20 79 6f 75 20 77 imeout.  If you w
65 72 65 20 61 20 6d 65  6d 62 65 72 2c 20 74 68 ere a me mber, th
65 20 66 72 65 65 20 63  68 61 74 20 77 6f 75 6c e free c hat woul
64 20 6e 6f 74 20 74 69  6d 65 20 6f 75 74 21 20 d not ti me out!

Example of a RTMP Invoke packet to close a connection.

Of course you could just use Ettercap, which does exactly what have been mentioned above. Start Ettercap with the following:

sudo ettercap -G -W 128:p:25AAAAC18DEADDADA433332B65

This will open the graphical interface (-G), that is if you have installed the GTK interface to Ettercap. -W specify to listen for wireless networks and to use a 128-bit key with key found earlier. I don’t know what the p is really for. You can also use the text mode.

Ettercap
Ettercap

Then select Sniffing > Unified Sniffing > select on which interface you want to sniff. Then start the sniffing: File > Start Sniffing. Now let’s specify which targets you wanna sniff. Go to Hosts > Scan for hosts. That will locate the hosts on the current network. Then popup the hosts list, Hosts > Show Hosts List.

Ettercap - Hosts Found on the Network
Ettercap - Hosts Found on the Network

On the list, add the router to target 2 and the hosts you wanna sniff to target 1. Only one step left: MITM > ARP poisoning.  Select Sniff Remote Connections > OK.

Ettercap ARP Poisoining Options
Ettercap ARP Poisoining Options

Then you wait for users to connect to pages like MySpace or Hotmail etc…and Ettercap will find out the sensitive information for you.

See also:

Wireless Networking, Praphul Chandra, Alan Bensky, Ron Olexa, Daniel Mark Dobkin, David A. Lide, Farid Dowla

RFC 826 – Ethernet Address Resolution Protocol, David C. Plummer, November 1982, http://www.faqs.org/rfcs/rfc826.html

Wired Equivalent Protocol, Wikipedia, http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

Ettercap, http://ettercap.sourceforge.net/

U.S Army Infected by Worm

Share

Wired reports that the U.S Army network is under assault by a variant of the SillyFDC worm called Agent-BTZ [1]. In order to restrain the infection, the U.S. Strategic Command has ban the use of every portable media on its network, this include USB keys, CDs, flash cards, floppies etc… Both the SIPRNet and NIPRNet are affected by this directive.

The SillyFDC worm infects systems through replication, i.e. by copying itself to various locations such as these folders[2]:

  • %System%
  • %Windir%
  • %Temp%
  • %UserProfile%
  • %ProgramFiles%
  • %SystemDrive%
  • %CommonProgramFiles%
  • %CurrentFolder%

Computer Virus Looming
Computer Virus Looming

It will also try to copy itself to any drive connected to the machine by scanning drives A:\ to Z:\, which is why the U.S Army is banning the use of portable media for the time being.  According to F-Secure who first discovered the worm[3], the variant in question will also create these files[4]:

  • %windir%\system32\muxbde40.dll
  • %windir%\system32\winview.ocx
  • %temp%\6D73776D706461742E746C62FA.tmp
  • %windir%\system32\mswmpdat.tlb

It will then install itself into the registry to make sure the worm starts every time the computer is booted. It will also attempt to download a JPG file from http://worldnews.ath.cx/update/img0008/[REMOVED].jpg and create an AUTORUN.INF file on each drive on the computer, which contains the following:

[autorun]
open=
shell\open=Explore
shell\open\Command=rundll32.exe .\\[RANDOM].dll,InstallM
shell\open\Default=1

[RANDOM] is a randomly generated filename for the malicious DLL. Each time a new partition or a new drive is plugged in, Agent.BTZ will infect it immediately.

The SillyFDC worm doesn’t have any payload, as it only replicates itself through systems it finds using physical medias only. But its variant, the Agent.BTZ is a known Trojan dropper. A dropper is the kind of Trojan that will look to download and execute other malware. It’s surprising that it found its way into the U.S Army network. So that might be a tip for any worm/Trojan writer: add physical media replication to your malware like in the good ol’ days before e-mail, as it seems sending it by e-mail or click jacking is pretty well filtered in military networks, but peripherals such as USB keys are still often used by personnel. And this will surely open the eyes of the network admins of the U.S Army: scan anything plugged into the network.

Also, Graham Cluley, senior technology consultant at Sophos advises:

“… that users disable the autorun facility of Windows so removable devices such as USB keys and CD ROMs do not automatically launch when they are attached to a PC”

With whom I agree.

Update:

Since so many people asked me about this worm, I looked deeply into Internet and found this code, which seems to be part of the script of the Silly FDC worm (that’s the best I could do for now). This script basically copy files from one directory to another, renames the core of the worm and put it into another directory and add registry keys. I cannot confirm this as I found this on an Indonesian blog, so if anyone can look into this, please let me know. Thank you. Blog : http://morphians.wordpress.com/category/uncategorized/

See also:

“US Army bans USB devices to contain worm”, John Leyden, The Register, November 20, 2008, http://www.theregister.co.uk/2008/11/20/us_army_usb_ban/ (accessed on November 20, 2008)


[1] “Under Worm Assault, Military Bans Disks, USB Drives”, Noah Shachtman, Danger Room, Wired, http://blog.wired.com/defense/2008/11/army-bans-usb-d.html (accessed on November 20, 2008)

[2] “W32.SillyFDC”, Symantec, http://securityresponse.symantec.com/security_response/writeup.jsp?docid=2006-071111-0646-99&tabid=1 (accessed on November 20, 2008)

[3] “Troj/Agent-EMB”, Sophos, http://www.sophos.com/security/analyses/viruses-and-spyware/trojagentemb.html (accessed on November 20, 2008)

[4] “F-Secure Malware Information Pages: Worm:W32/Agent.BTZ”, F-Secure Corporation, http://www.f-secure.com/v-descs/worm_w32_agent_btz.shtml (accessed on November 20, 2008)

High-tech Cheating

Share

One man and a woman, Steve Lee and Rong Yang, were convicted last week to eight months of prison after helping two Chinese men cheat their immigration exams, according to a news report from the Metropolitan Police Service[1].  The duo was monitoring the examination from a vehicle outside the building with laptops, transmitters and other equipment.

“Lee and Yang were clearly involved in a sophisticated operation using some of the best surveillance technology available worth thousands of pounds. When we first arrived at the scene it was very confusing as to what exactly was going on.”

It’s hard to tell what was the “best surveillance technology available worth thousands of pounds” since no detailed equipment list was given, but we might expect this to be largely exaggerated. The report states that Zhuang, the examinee, was given “tiny buttonhole cameras sewn in, a microphone and a small ear piece”. With this equipment, the information was transmitted back to Lee and Yang, who told Zhuang the answers to the questions.

“Best surveillance equipment” found into the car
“Best surveillance equipment” found into the car

I decided to look the equipment needed to conduct such an operation. The following material can be found without looking very hard on the net:

· Wireless Button Camera – £226.37

· Wireless Microphone – £133.13

· Wireless Earpiece – £134

· Laptop – £429

· Wireless Router – £51

Total: £973.5

Unless I’m forgetting something worth more than £1000, this is far from being “thousands of pounds”. And I’m quite sure you can get these items cheaper if you look on eBay.

Anyway, the cheaters were caught after a member of the public reported seeing them sitting Lee and Yang in a silver BMW with wires running from under the hood to the inside the car.

According to Sergeant Dominic Washington who first responded to the call from the public, said:

“However, working with colleagues from across the borough and the Met we believe that we have uncovered an established criminal enterprise that may be in operation in other parts of the country.”

No, I don’t think so… but this might give ideas to the others. And why were there wires under the car?


[1] “Two convicted for immigration test scam”, Metropolitan Police Service, November 14, 2008, http://cms.met.police.uk/news/convictions/two_convicted_for_immigration_test_scam (accessed on November 17, 2008)

Survey Points to Energy Sector at Risk of Cyber Attacks

Share

A survey of 200 leaders from the critical infrastructure industries revealed that the energy sector is the most likely to be victim of a cyber attack. The survey was completed by IDC was conducted in August and October in Canada, the U.S and Europe[1].

The reasons to explain this phenomenon are the cost, apathy and government bureaucracy according to the survey. Also, industries are adding more and more possible access points to the internal network by connecting new sensors, meters and other equipment to their networks.

“]Percentage of respondents prepared and not prepared by industry sectors

Of course, energy industries networks are valuable targets, and would probably be the first victims in a case of a full-scale cyber attack. And as the events of 2003 shown[3], only a few power plants need to go down in order to create chaos on a wide region.

If costs are the main factor to wait before securing networks, security is not likely to be in the priorities of managers during the economic crisis that’s coming on the horizon. Unfortunately, those who take the risk of not hardening their security now may pay the price later…And according to Rick Nicholson, research vice president for IDC’s Energy Insights:

“Most utility CIOs [chief information officers] believe that their companies will be compliant with relevant standards, but still have a long way to go before being adequately prepared for all cyber attacks.”

Another interesting point, all these news come right after a newly president-elect enters the Whitehouse… see Whitehouse Hacked by Chinese Several Times, Both U.S Presidential Campaigns Hacked.


[1] “Survey: Critical infrastructure risks cyber attack”, Miya Knights, IT PRO, November 10, 2008, http://www.itpro.co.uk/608067/survey-critical-infrastructure-risks-cyber-attack (accessed on November 11, 2008)

[2] “Energy industry at risk of cyberattack, survey says”, Elinor Mills, November 11, 2008, http://news.cnet.com/8301-1009_3-10094382-83.html?part=rss&tag=feed&subj=News-Security (accessed on November 11, 2008)

[3] “Blackouts cause N America chaos”, BBC News, August 15, 2003,  http://news.bbc.co.uk/2/hi/americas/3152451.stm (accessed on November 11, 2008)