r3dey3

Backup Implementation

Kenny K — Thu, 14 Sep 2017 02:06:03 GMT

I figured it's been a few weeks since I put my thoughts to keyboard regarding various backup solutions and since I've decided on a one and it's been in use for a week or two now it's time to write up what I went with.

The short answer is Restic, Arq and Rclone for software and Backblaze B2 for cloud storage.

Systems

I have multiple systems that need backed up:

My parents' laptop (at their house)
My parents' desktop (at their house)
My local fileserver
My laptop
My wife's surface pro
My two Linode servers

I also have a server that is used to store backups at my parents house. It doesn't do any backups itself, but will be used for syncing.

The ultimate goal for all backups is to have three backup locations for critical data in addition to the original source:

Fileserver at my house
Fileserver at my parents
Cloud storage

Arq

This is probably the simplest to describe as it's almost an all in one solution.
Configuration:

sftp destination to the local fileserver at each location, using a per-laptop user account and strong password.
Email notification on errors using a gmail account I have on my domain for such purposes.
For my parents' systems - every 4 hours
For my wife's every hour
Prune hourly/daily/weekly/monthly option to hopefully limit the amount of space empty backups use.
All systems backup c:\users and c:\programdata. I spent a little bit of time removing things that generate a bunch changes even when the system isn't in use (e.g. Cache, Antivirus)

While using the local fileserver as a backup destination means the systems will not be backed up when outside of the house, it is very rare that those systems are used outside of the house.

Restic

I chose restic because it seemed to be the fastest solution that supported cloud destinations that I could find during my trials.

Originally I performed a full backup of my fileserver to Backblaze B2 but upon thinking about how I wanted to sync I decided to backup to a local path instead. So I spent a few hours downloading the archive using rclone. I then configured my laptop to backup to the same location over sftp. This means that the deduplication is effective when I move data from my laptop to my fileserver for permanent storage.

I then configured the restic rest-server for my two Linode servers. I made a simple modification the the server to enable append-only mode, meaning while the servers can create new backups they cannot remove or modify existing backups; providing "hack" protection of sorts as the credentials to access the backup are on the servers. To provide a simple implementation I added a sub-domain to one of my domains for backup and configured one of the servers to reverse proxy the connection over a vpn to my local fileserver. This means that the backups are stored on my local fileserver, but the destination is accessible at a fixed hostname over ssl (thank's letsencrypt).

After a few days I ran into an issue with my local fileserver and laptop backups due to linux permissions. The fileserver was using the root user for backup (yah, yah.. I'm lazy) but the laptop used a non-root user for stfp. I eventually configured two different rest-servers; one that listed on localhost and another that listens on the local interface in append only mode.

Scheduling

As restic is a simple app that does not implement its own scheduling I fell back on a simple cron script to do the backup. I first configured postfix to use mailgun using a tutorial on digitalocean. I then installed cronic to curb the amount of email as I only need notification when something fails. For my fileserver I just added a new line in cron to run my backup script, but for my Linode servers and laptop, I wanted to just drop a script into /etc/cron.daily to run. In order for the script to run through cronic I had to do a bit of magic at the start

in_cronic=$1
if [[ "$in_cronic" != 'in_cronic' ]]; then
	exec cronic $0 in_cronic
fi

set -xeu

rclone

The last feature I wanted was to sync the backups to the other locations. Using rclone I configured a Backblaze B2 endpoint, and then used the copy command to sync the backups. I might eventually switch to the sync command for the Arq destinations if I notice the space growing significantly.

Another feature of rclone I took advantage of is the ability to sync Google Drive. I configured endpoints for both my wife and my accounts and now sync them on the fileserver prior to performing the backup; never hurts to have extra copies of stuff.

One thing I ran into while trying to push the backup to my parents house was their slow internet speed; so I spent $70 on an external hard drive to copy the backup to and then snail-mail to my parents. This turned out to be way faster than doing the sync over the internet as the speed would be limited to approx 1Mbit/s. With my 1.3TB of data it would have taken over 100 days. Whereas I was able to get the data transferred to the hard drive and mailed and transferred off in less than a week. I then copied their data onto the hard drive and then they mailed it back to me.

Backup Search Results

Kenny K — Sun, 27 Aug 2017 16:03:54 GMT

Just my thoughts on the various backup packages - updated as I evaluate them more.

Spideroak One

Super simplistic interface.
No way to start/stop backups, only able to run them on schedule
couldn't tell if there was archival of versions
proprietary storage server
linux install is just untar a file onto / (NOT the way to go)

iDrive

No UI for linux; I don't feel like figuring out the scripts for

Duplicity

Slow as dirt
incremental downloads rely on last full?
linux only

Duplicacy

CLI isn't very self documenting
cli only (linux)
couldn't figure out how to get it to not prompt username/password

qBackup

Java
Just loading the UI used 300MB of memory. Scanning my home directory used over 1GB
Expensive
No built in scheduler

GoodSync

Looks annoying to configure - no ui on linux

CloudBerry Backup

no free version
filenames/paths are not encrypted on destination
no stfp support
~300MB of memory used to backup 7GB
completion and failure emails
installs all the directories as 777
storage is a full path and filename as a directory (with a : at the end) and then files that are named based on timestamp. (doesn't encrypt filenames)

UrBackup

no crypto
more enterprisy
requires server
requires opening ports on the client to be discovered

CloudBacko

Java
refuses to install or run as a user on linux
scheduler uses 120MB of memory with nothing configured

duplicati

Web UI
.Net/mono
"beta"
175MB of memory used to backup 7GB
"proprietary" storage format (but open source)

Arq

Windows/Mac only
easy to configure; supports s3/b2/sftp
runs a service to backup

Resilio

primary sync; used to be btsync and i nixed that one a while ago

SyncBackPro

windows only
pain to configure versioning
couldn't get it to work with minio (it would get buckets, but fail to actually backup)

rclone

simple rsync like interface for s3/b2
good for syncing from one 'server' to the cloud

restic

requires a backup to complete before you can restore
can backup multiple hosts to same archive (does dedup across all)
operates a lot like git - files are referenced in snapshots
able to saturate my 20Mbit up with an 7 year old intel atom cpu.
no integrated scheduler

Result

I decided to go with Arq for windows to just backup to local servers via sftp. For my fileserver I decided on restic to B2, i tried duplicati but it was very slow at backup. Setting up a cron job to backup won't be so hard, plus it will be nice to be able to different level of backups on different folders, all going to the same archive.

To provide redundancy I'm going to use rclone to push the local backups to B2.. and once there pull them down on the other side.. even though this will cost a bit of money the first time it shouldn't be too much (maybe $30-40).

The hunt for a new backup solution

Kenny K — Tue, 22 Aug 2017 19:06:25 GMT

For about 2 years now I've been using CrashPlan Family Unlimited (no link because I'm mad at them) to handle backing up my data. I liked the solution well enough - it had Peer2Peer backups which meant I could install it on some less-tech-savvy friends' & families' computers and they would have backup. It also supported Linux and allowed multiple computers (any OS) to use the same account which meant I could back up all my stuff and my wife's (6 computers, split 3 win/3 linux). Well they recently announced they are no longer going to offer their crashplan for home service. Their solution is to either offer a deal with Carbonite (no linux support) or their CrashPlan for small business. They are offering 75% off for 1 year for their small business plan, which comes out to the same price as the old $150/yr for the family unlimited plan for the first year.. afterwords it's 4x the cost. So I've decided they are no longer going to get another penny from me.

I'd love to switch to Backblaze, but they don't offer a Linux client, no peer2peer and the cost would be more than what I was paying previously ($50/yr/computer). So I just spend the last hour or so (so much for getting work done... thanks for nothing CrashPlan) looking at various solutions that support Windows and Linux as well as peer2peer.

I've narrowed my search down to the following products. I haven't had a chance to evaluate them other than looking at their web pages.

Spideroak One

This is the only product I found that provides the cloud storage as well as the software. It supports Windows, Linux, OS X, Android and iOS (not sure if it does the backup on the mobile stuff or just access). Pricing for my storage needs would be $279/yr and it doesn't support peer2peer.

The rest of the solutions all use a cloud storage provider such as Amazon Glacier, Backblaze B2 or Google Coldline.

Duplicity

Linux only, rsync like backup solution. Free, GPL. I only include this one in case I decide to go with a Backblaze for the Windows backups. Duply is a front end. I found a guide on doing Encrypted backup to Amazon S3 (2014) using duply so that might be a good starting point.

Duplicacy

While similar in name to the previous one, it's not. This one supports backup to cloud storage as well as sftp so it has at least partial peer2peer support. For personal use, the CLI version is free for any OS, while the Windows/Mac GUI Pricing is reasonable at an initial $20/computer for the first year and then $5/computer after the first year. The source code for the CLI is available, but not sure of the exact license (not a standard OpenSource license). It's written in go so it shouldn't be as much of a memory hog I hope.

qBackup

This too support sftp and cloud storage. Pricing is $29.99 per windows/mac computer and $99.99 per linux. This is definitely a pricey option but it looks like it's only a one time fee.

GoodSync

I'm really turned off by their web page, and it's hard to find the information I want, but I'm willing to give them a try. They do have their own peer2peer implementation in addition to sftp, but it's restricted to the same account. Pricing is $29.95 for windows/mac and then $39.95 for the linux cli. They also have a Linux/Windows server, but I think that's for their management solution.

CloudBerry Backup

No idea if they have a peer2peer solution or sftp support. For upgrades after the first year, it's 20% of the original price. The offer a free version but it doesn't allow for custom retention, scheduling, compression, or encryption. Pricing is $29.99 per computer, with a volume discount on linux computers at 2+ for $24.99.

UrBackup

This product is an opensource client/server backup system. It looks like I'd have to run the server somewhere and then configure the clients to backup there. In order to get block-level changes on windows a lices would been to be purchased at $17 per windows client. There may be a way to archive to Amazon Glacier via S3, but I'm not entirely sure.

CloudBacko

They offer a free Home version that looks like it supports Windows and Mac. They also offer a free mobile version which backs up to Dropbox, Google Drive or OneDrive. They also offer a Lite version ($19 per install) that offers the ability (for $9) to do a cloud2cloud backup, e.g. backup dropbox or google drive. I think combined with the mobile version might be a good way to backup phones. The lite version also offers the ability to backup the full windows install instead of just the data. In order to get Linux Support (right now?) you need to purchase the pro version at $149 per install, in addition, Ubuntu is not listed as supported - only RHEL and CentOS.

duplicati

(added after initial post). Not much info (very little documentation even!) on the site, LGPL, supports Windows, Mac and Linux. Writing in .Net. Supports S3, sftp and Backblaze B2.

rclone

This isn't really a backup solution, but I'm including it here because it'd be a good way for me to backup things that don't change (music/videos)

Edit @22:00 because somebody pointed out I missed iDrive. Adding details here for completeness.

iDrive

Windows and Mac are supported with their personal plan, which is definitely cheaper than Crashplan was if you had less than 5TB. In order to get linux support you'll need to switch to their business solution which can get very pricey as you go up in storage requirements.

Edit 8/23 1300:
Apparently iDrive personal does support linux - I swear when I looked last night the Linux was not supported in personal. Guess I need to try them out as well. Lots to look at.

Edit: 8/26

Arq

Arq is another program that can use S3 or Backblaze B2 as it's storage. It's only Windows & Mac. It costs $49.99/user or server.

Syncrify

Syncrify appears to be a custom client/server backup solution which supports Windows Linux and Mac. Personal edition is free but doesn't support file versioning, nor encryption. Single Pro license is $49. discount after 5 licenses. Licenses are per client.

BuddyBackup

Looks like a P2P only backup. Free; only supports windows. Blog hasn't been updated since 2014.

Resilio

Looks more like a dropbox like sync program vs backup. Supports windows, linux, mac. Home version is $59.99; Family version (5 users) is $99.99. Used to be BitTorrent Sync

SyncBackPro

Windows only; $54.95. interface looks like ui hell.

Restic

Cross platform, cli only, open source, written in go.

And a whole lot more

I found this list written by the author(s) of restic. It mostly contains linux only software.. but it's definitely something I'll look at.

Backend Service

One choice with all this is which service to use for storage. Primarily I'm interested in archive type storage, so things like Amazon S3, Google Cloud Storage or Azure Storage are probably too pricey. Instead I'm interested in things like Amazon Glacier, Azure Sttorage LRS Cool, or Google Cloud Storage Coldline.

A few new ones I found in similar price point are Backblaze B2 and Wasabi. Unlike typical Cold Storage, both Backblaze B2 and Wasabi offer instant download instead of having to wait 2-4 hours for availability. Wasabi has cheaper storage at $0.0039/GB/Month (min 1024GB) vs Backblaze's $0.005/GB/Month (no min); but Backblaze B2 offers the first 1GB downloaded per day free, with other downloads at $0.02/GB while Wasabi is $0.04/GB download. The qBackup page has a decent comparison of cloud storage providers though they don't list everything available.

(edit 22:00) Oracle also offers an archive storage service which looks to be pretty competitive with pricing at $0.001/GB/month but I'm not sure the exact costs to get the data out (they have a retrieval and transfer price listed.. it may be $0.125/GB total for up to 10TB). They also have a small read/write fee for items less than 10MB of $0.05 per 1000 requests.. so that could increase the cost depending on how the backups are done.

DEF CON 25 CTF Quals - insanity

Kenny K — Sat, 13 May 2017 04:08:45 GMT

Overview

Problem:

Are you a chicken?
:
https://2017.notmalware.ru/90ac48d8e27c81628dd56a6e3926a18cd6a399c3/insanity.tar.bz2

Unlike my last write up - I did a lot of the work in solving this challenge so this write up will be a bit more detailed. In this challenge we were given a tar.bz2 (that was really an xz compressed file). This file contained an x64 binary (insanity) and 2 shared objects (libpocketsphinx.so.3 and libsphinxbase.so.3).

I started by searching for pocketsphinx to get an idea of what the shared library implements and quickly discovered the github page indicating that it does speech recognition. This tells me that at some point I will most likely need to send an audio file to the service to do something.

model

The first step was getting the program to run more than printing an error Failed to create recognizer, see log for details. Of course there's no log, but looking at the git repo for pocketsphinx and the code

  v4 = cmd_ln_init(
         0LL,
         v3,
         1LL,
         "-hmm",
         "./model/en-us",
         "-lm",
         "./model/en-us.lm.bin",
         "-dict",
         "./model/cmudict-en-us.dict",
         0LL);

shows that I need some sort of model files. Luckily the git repo has the files that worked. Doing a ln -s pocketsphinx/model/en-us/ model fixes the problem and lets the program start.

Audio

The next step was to get some audio to feed into the program and determine the proper format. I searched for some text 2 speech websites and found http://www.text2speech.net that I was able to use to create some audio mp3s (the site has changed format a bit since the competition, previously you could set volume level and voice).

pre-processing

The next step was getting the file into the application. A 4 byte length is read, then that amount of data is read and fed into inflate - so the data is compressed with zlib. The next step is to figure out what a block of simd instructions was doing:

*((_QWORD *)&v63 + 1) = 0x8000800080008000LL;
*(_QWORD *)&v63 = 0x8000800080008000LL;
v15 = _mm_stream_load_si128((__m128i *)&v63);
do
{
	v16 = _mm_stream_load_si128(v12);
	v17 = _mm_stream_load_si128(v12 + 1);
	_mm_stream_si128(v13, _mm_xor_si128(_mm_unpacklo_epi8(0LL, v16), v15));
	_mm_stream_si128(v13 + 1, _mm_xor_si128(_mm_unpackhi_epi8(0LL, v16), v15));
	_mm_stream_si128(v13 + 2, _mm_xor_si128(_mm_unpacklo_epi8(0LL, v17), v15));
	_mm_stream_si128(v13 + 3, _mm_xor_si128(_mm_unpackhi_epi8(0LL, v17), v15));
	v13 += 4;
	v12 += 2;
	--v14;
}
while ( v14 );

To do this, I set a breakpoint before this block of instructions and took a look at the input and then a breakpoint at the end, and compared the input to the output. Looking at the difference, an input of 0x41 0x42 0x43 0x44 was converted to 0x00 0xc1 0x00 0xc2 0x00 0xc3 0x00 0xc4. At first I just assumed looking at the xor value that it was only xoring with 0x8000, but it turns out it's taking an 8 bit value and essentially multiplying it by 256 (turning it into a 16 bit value) and then xoring it with 0x8000.

speech 2 text

The next step was to figure out the correct format for the data. Looking at the tutorial we see that it needs to be a single-channel (monaural), little-endian, unheadered 16-bit signed PCM audio file sampled at 16000 Hz. So the next step was converting it. Luckily linux has command line utilities for just about everything and a quick google search (or dozen) lead to the magic command line of:
ffmpeg -y -i "$in" -f s8 -acodec pcm_s8 -ar 16000 -ac 1 $out.raw to convert an mp3 into a raw file with the correct format. I wish I could say that I immediately knew that I needed to do 8 bit because of the pre-processing done but there was a lot of trial and error in getting the correct format (including sending the sample files in the pocketphoenix repo)

text processing

The next step was to figure out what it was doing with the text processing:

insanity_count = 0;
input_idx = 0;
decoded_text = ps_get_hyp(v5, &v61);
while ( *(_BYTE *)(decoded_text + input_idx) && (unsigned int)(data_idx - 2) <= 1000 )
{
	if ( !memcmp((const void *)(decoded_text + input_idx), "insanity ", 9uLL) )
	{
		++insanity_count;
		input_idx += 9;
	}
	else
	{
		if ( memcmp((const void *)(decoded_text + input_idx), "insane", 7uLL) )
			goto reloop;
		v22 = insanity_count;
		input_idx += 7;
		insanity_count = 0;
		opcode_buf[data_idx++] = v22;
	}
}

as we can see it is counting the times the word insanity appears and then when the word insane appears it stores this count into some buffer. So the next step was putting together an audio file of insanity and insane. Luckily with the help of that text2speech website and ffmpeg getting the speech2text for a single word went pretty quick. The next step was putting together a "sentence" that would properly decode.

Luckily silence is a simple as adding a bunch of zeros into the input stream so adding a pause was very simple: we just had to add some zeros between the words. knowing that the sample rate was 16000 hz, adding 4000 zeros would be a 1/4 second pause and that was plenty for the library to recognize distinct words.

much insanity

The next problem came when trying to add more than a few 'insanity's. The library would mess up and change an insanity to 'been to too' or some other nonsense. Looking at the code, the initial buffer read size of compressed data was limited to 64k chunks, but we weren't hitting that - after all, a 4000 zeros compressed really well, we were barely at 16k. So the next step was looking at how the data is decompressed.
Looking at the decompression buffer, it turns out that inflate is given a 64k buffer (aka 4 seconds worth of samples) to decompress into. That buffer is fed to the speech to text; and then inflate is called again, and then the next chunk of decompressed data is it fed to speech2text and so on. So after a bit of thought I reasoned that when the speech2text is fed part of a word in one round and then part the next it doesn't process it correctly.

So first I tried padding out the silence ('\x00') between 'insanity's to make sure that 3 would fit in a single 64k buffer (so ~1/3 a second between words as the word was slightly longer than a second).. This got me further but it would still mess up at around 8 or so.
Then I took a look at the hexdump of the insanity raw file.

00000000  00 ff ff 00 00 ff 00 00  00 00 ff ff 00 00 00 ff  |................|
00000010  00 00 00 ff 00 ff 00 00  00 ff 00 00 00 00 00 00  |................|

and I see that it starts with a \x00 ... so I started thinking, i wonder if the zlib is including that first \x00 in with the silence and not extracting the ending silence in a block because that \x00 doesn't fit in the buffer (since I was padding the decompressed data to exactly 64k).

I tried changing the amount of silence and the value used to '\x01' and between words to '\x03' and that worked; I could successfully send a sentence with a whole bunch (i think i tried 80) 'insanity's.

I'm going insane

So now we can decode a single sentence and store a byte into what I eventually called the opcode_buf. The code would continue to read a length and audio data, decode and store a byte until a length of 0 was sent at which point it would go to the emulator portion.

Emulator

The opcode_buf consisted of an array of qwords, with the first 2 initialized; index 0 was set to the address of the opcode_buf (or'd with 0x8000000000000000) and index 1 was set to the last decoded text (or'd with the same value). And then the values stored with insanity/insane-ness were added starting at index 2.

Looking at the operations it was easy to see that when the high bit is set, the value is treated as a pointer or string, and when it's not set it's treated as a numeric value (this also means no negatives with math).

I was quickly able to identify the operations:

0 - exit
1 - push value
2 - add or strcat
3 - subtract (numbers only)
4 - multiply (numbers only)
5 - divide
6 - load
7 - store
8 - jump (if nonzero)
9 - convert numeric to string (single byte only)
other - push value = (op_code - 10)

The pc started at index 2 - the first value stored using the speech 2 text. and the data stack started at 1 greater than index of last value stored (a 0 was pushed on in that position). This meant that depending on the operations you could get the pc and data_index to cross.

Every operation that used data values would 'pop' them off, then push the result.

Easier Code

The first thing I noticed is that the jump instruction did not validate that the target was within the 1000 qword opcode buf.. this meant that we could jump to other data... and since almost everything (compressed & uncompressed buffers and opcode_buf) were stored on the stack we could jump to data we sent without having to do the speech2text for everything.

The first step was to figure out how to get data onto the stack without inflate failing (which causes the program to bail) and the speech2text to return something valid (but not necessarily insanity/insane) as when it failed it returned NULL and the program crashed.

I settled on sending the word no followed by the data I wanted to send. When the speech2text decoded no, and it was checked for insanity/insane the program would just go back to the read length part and as long as I sent 0, the extra data would still be in the decompression buffer on the stack.

So now that I knew how to get data onto the stack the next step was getting the emulator to jump to that location. I figured out how far opcode_buf was from the uncompress buffer (not the xor masked buffer.. because I didn't want every other byte to be 0) using gdb. It turned out I needed a jump of over 128k bytes to just get to the start of the decompress buffer, then some to get over the 'no' audio. So I needed to figure out how to get a really large value in the data stack to use as a jump target.

Luckily we have a multiply instruction and doing some root calculations and guessing, we determined that 11*11*12*13 would get us far enough into the decompress buffer to get past the no.

So the instruction sequence to get opcodes to execute in the decompress buffer instead of the opcode buffer (so we can use larger values, and less insanity) turned out to be: (remember we had to send this with the multiple 'insanity's and a single insane audio to get the value we wanted)

add (2)
mult (4)
mult (4)
mult (4)
mult (4)
jmp (8)
1 #truth value for jmp
13
12
11
11

The add instruction was necessary because after finishing reading a 0 was pushed onto the stack as the last data value and multiple would just cause 0's to propagate up.

This sequence would cause the pc to be set to 18883, which was 11976 bytes into the decompressed buffer (1896 bytes larger than the no.raw). Which was perfect.

rip control

Now that I could store large values it was time to figure out how to get execution. We quickly realized that the load and store operations also did not check bounds.

The store operation would load a value at a specific index in opcode_buf, the index and value were pulled from the data stack and as long as the index wasn't negative it would store the value at opcode_buf[index]. This allowed us to have a very simple stack overwrite with whatever we wanted. Given that we knew the relative location of opcode_buf to the return address (-0x41f98 *8 bytes) it was simple to overwrite the return address.
Load worked slightly differently, it actually took a parameter and a data value. The parameter could be either 0 or 1, 0 to load from the opcode buf, and 1 to load from the decoded text. Technically, it used the address stored in index 0 or 1 of the opcode buf. This address had to have the high bit set as if it was a string.
With this load we could read the return address (same offset as before), and then do emulator calculations to figure things out.

drip drip drip - leaking data slowly

Since the entire program was written inside of main, the return address was that of the call to main inside __libc_start_main. We need to leak some addresses in order to determine which libc was in use. Luckily the program printed the top value on the data stack (current item) when the exit instruction was used; if the high bit was set it printed a string, otherwise it printed the value in hex.

Leaking the __libc_start_main return was easy, we just had to load the return address into current data item and exit. However this address wasn't quite enough to get use an exact libc match. In order to leak other addresses finding the GOT would be most helpful. Luckily main calls other things and the return address inside of main is available. And it just so happens there is one call that happens every time before the emulator is run.

Knowing the offset of the bottom of main's stack frame to opcode_buf we can figure out that what index (-29) we need to load (which didn't have negative or positive bounds checks!). Loading this gave us the actual return address pushed by the call to write at 0x1369 in main(). We could then add the offset to the appropriate entry in the got to get the actual address. We couldn't just store this address in offset 0 of opcode_buf because it didn't have the high bit set and that would cause a subsequent load operation to fail (due to checks).

Since setting the high bit with an or operation is the same as adding the same value (since we know the high bit isn't set) we can use the add operations... however we cannot just add 0x800000000000000 as that is a negative number and add cannot be used. instead we first add 0x101 and then add 0x7ffffffffffffeff. The 0x100 is to account for any oddities that could arise with the push_value instruction (which I don't think there are any after looking at the code again during this write up).

The final trick was storing the value in index 0 and then doing another load operation to read the value and exiting.

system()

So now that we knew addresses of a few glibc functions we could look for the bin/sh single instruction gadget in libc. However after talking with some teammates they mentioned that this would not work because sh was busybox and it requires argv[] to be set... so plan 2.

Since we had libc, and knew were system was, and we can find the "/bin/sh" string, all I needed to do was load the address of "/bin/sh" string into rdi and call system. So I found a pop rdi gadget at 0x22b1a in libc, and the bin_sh string at 0x17ccdb, with system() at 0x46640. Now we could use those addresses as well as the address of the call main in __libc_start_main (0x21ec5) to write some emulator instructions to overwrite the stack.

The full chain is a little annoying, but it basically broke down into the following steps:

Load main's return address (__libc_start_main)
Add the offset for system
store the value at main's return rsp + 0x10
Load main's return address (__libc_start_main)
Add the offset for "/bin/sh"
store the value at main's return rsp + 0x8
Load main's return address (__libc_start_main)
Add the offset for pop rdi gadget
store the value at main's return rsp
exit instruction

The hardest part for us was finding the correct libc. Even when we found it, for some reason (not sure why) I couldn't run the program locally with that libc. But the address worked and we were able to capture the flag. (sorry I didn't save what it was)

Files:

Other Bugs

I'm just going to list the various other bugs found in the emulator as there were quite a few.

The strcat operation set the high bit on the result (no longer an address type)
The strcat operation will free a value even if it wasn't necessarily malloc'd
The push value would allow pushing of an address

These are probably not useful with a one-shot chance through the emulator.. but ya never know.

DEF CON 25 CTF Quals - reeses revenge

Kenny K — Sat, 06 May 2017 01:19:37 GMT

Overview

This problem is a rehash of the reeses problem from DEF CON 21 CTF Finals. In this case the problem is compiled for x64 instead of ARM. We were provided with a binary and 4 sample files.

Let me start by saying that I only had a small part in solving this problem during the competition and my teammates did a huge majority of the work. I vaguely remember this problem from DEF CON 21 CTF, and back then I think that I may have identified it was an MIPS emulator, but we were never able to get execution (MIPS nor ARM).

The problem starts by reading a 4 byte length and then a buffer of that size, as long as it is less than 100,000. This buffer is then processed as a custom executable file format which includes an RSA signature. Not having the private key means that the only binaries that can be loaded are the 4 sample programs included with the challenge.

File format

The file format is rather simple with a structure similar to an elf header with a count and offsets of the number of sections and number of register initializations.

struct file_header {
   uint32_t unk1;
   uint32_t unk2;
   uint32_t unk3;
   uint32_t section_info_offset;
   uint32_t reg_init_info_offset;
   uint16_t num_sections;
   uint16_t num_reg_init;
   uint32_t sig_offset;
   uint32_t entry;
}

The header had the following validations:

sig_offset had to be file_size - 256.
a max of 100 sections
a max of 33 reg inits
each section info was 20 bytes
each reg init was 8 bytes

The sections headers were fairly simple:

struct section_info {
   uint32_t load_addr;
   uint32_t unk;
   uint32_t length;
   uint32_t offset;
   uint32_t unk1;
}

And the register initialization was even simpler:

struct reg_init_info {
   uint8_t reg_num;
   uint8_t pad[3]
   uint32_t value;
}

Even though the file header has an entry, the emulator actually used register '32' as the entry (this doesn't matter because the samples had both values equal). One of my teammates took the time to write a loader script for IDA to be able to load programs with this file format.

MIPS

The emulator handled a few system calls:

Read
Write
Malloc
Time
Rand
Exit

Read and write were restricted to stdin and stdout respectively; and due to the lack of open this meant that not only would we need to get MIPS code execution, we would need to find a vulnerability in the emulator to get x64 code execution.

The problem included 4 sample programs. Each was signed appropriately to be loaded into the emulator. My teammates started by looking at sample1, which was lucky because sample1 is the one with the vulnerability that enables MIPS code execution. I quickly identified what the other 3 samples were doing while writing this (for completeness)

sample1 - compression/decompression
sample2 - echo service
sample3 - encrypt/decrypt service
sample4 - sha256 service

Sample1

Sample1 reads a single byte for the operation type and then a 4 byte length. The length must be less than 0x4001. After reversing it for a while sample1 was identified as performing compression or decompression based on the operation (0 or 1 respectively).
The compression algorithm was identified as lzss, however it did not use the standard parameters - EI was 13 and EJ was 5. My teammates quickly modified a version of lzss.c they were able to find to have the adjusted parameters.

I'm not sure if testing or reverse engineering lead to the realization that the uncompress operation does not properly bounds check. My teammates were able to identify that the uncompress buffer would eventual run into the current stack area enabling an overwrite of the saved ra value, so that when the uncompress function returns we would have control of the pc.

It turned out that the offset into the uncompressed buffer for this saved ra was 0x25edc. As long as the payload would compress to less than 16k, we were able to control MIPS execution. They were also able to identify that the buffer is uncompressed to 0x40a0b8, and due to the lack of ASLR and NX, we could include our MIPS shellcode at the start of the buffer and return to it.

X64 control

So now that we had control of the MIPS execution environment, the next step was to get control in x64 context.

One of my teammates identified that the the Halt and Spontaneously Combust instruction had a s64 simple stack overflow when executed in the branch delay slot. It would copy the registers onto the stack overflowing the return address. The exact opcode for the instruction had to be 0xcfe00000 in order for the overflow to occur. In addition in order for the exception handler to not exit, register $20 had to be 100 so that when copied the parameter passed would cause the handler to process it as an unknown exception.

Where to go?

Now that we can control rip, the question lies as to where to point it. reeses_revenge was compiled with full PIE and NX, and ASLR is enabled, meaning there are no known fixed addresses and a memory leak or other known address is needed.
This is the part where I started helping.. and sadly it took me far to long to finish. I think I looked at the implementation of every MIPS instruction in the code at least 3 times. My teammates also identified a bug in the system call instruction in that it was possible to use a negative index into the system call table - system calls were 4000 through 4015, but the check for range was val-4000 < 15 and it was a signed check. So system calls less that 4000 would use other memory locations for the information. I tried looking at all possible combinations of using that to leak information, but due to differences in how the system calls were done compared to instructions this proved useless.
I then investigated the coprocessor instructions. After reversing the two supported instructions I was able to determine that they implemented rc4, with one being the set key operation and the other being encrypt/decrypt. It turned out that the encrypt/decrypt could be called without calling the set key one, and it would use unitialized memory as the keystate, but the values leaked were not very helpful as it wasn't the full value of any addresses as the rc4 key state is only byte values.

Eventually I looked at the malloc system call again and realized that not only did it allocate an RWX page, it also used the internal random function to generate the address. So the next step was to figure out if we could predict the value returned by random. This is eventually what lead us to success.

allocate_page() { //0x4b60
  ...
  v8 = do_rand();
  v9 = mmap((void *)(((unsigned __int64)v8 << 12) | 0x400000000000LL), 0x1000uLL, 7, 50, -1, 0LL);
  ...
}

In order to predict the value for rand we need send some rand values back from our MIPS code:

.set noreorder
main:
# assemble with mips-linux-gnu-as -O0 --EL -o mips_sc.elf mips_sc.asm ; mips-linux-gnu-objcopy -O binary -j .text mips_sc.elf mips_sc.bin; mips-linux-gnu-objdump -d mips_sc.elf;

#ra contains the address of main
	add $s7, $ra,0

leak_data:
	add $s1, $s7, 0x1000
#time systemcall
	li $v0, 4013
	syscall
	sw  $v0, 0($s1)
	add $s1, 4


#leak 0x10 RAND values
	li $s2, 0x10
rand_again:
	li $v0, 4005
	syscall
	sw  $v0, 0($s1)
	add $s1, 4
	sub $s2, 1
	bne $s2, 0, rand_again
	nop

#WRITE leak
	li $v0, 4004
	li $a0, 1
	add $a1, $s7, 0x1000
	li $a2, 68
	syscall

Once we had the rand values we needed to both determine the rand algorithm and the seed value used. Reversing the algorithm was pretty easy, and I implemented it in python. The seed calculation was pretty simple to find as well.

main() {
  ...
  v4 = time(0LL);
  srand(((unsigned __int64)&printf >> 12) ^ v4); //0x54c2
  ...

One thing to note is that even though the address is treated as a 64 bit value, srand only uses 32 bits for the seed. At first I missed the shift right operation and thought that because the bottom 12 bits are not randomized and that because we can get the time it will be pretty simple to brute force the entire randomized space (20 bits). However when trying this I realized there was the shift 12... oops.

When looking at ALSR addressed of printf with the shift 12, it's usually 0xfxxxxxx or 0xexxxxxx with a high probability (in my testing) of 0xfxxxxxxx. And then when looking at the current unix time, it's around 0x59xxxxx, so combining these two things the seed is likely to be between 0xa0000000 and 0xafffffff.

Instead of just searching the space, which we would not have enough time to due to alarm(), I used random.randint to just try various seeds, and then would compare the first four values against what was leaked. . If they matched, the 17th random value would be calculated, and the same operations in malloc_page would be done (val <<12 | 0x400000000000) and then this value as well as the length of our x64 shellcode would be sent to the MIPS shellcode.

The MIPS shellcode would read those values, allocate a page of memory, and read the x64 shellcode into that newly allocated page, which thanks to the rand calculations we know the address of. The MIPS shellcode would then setup the x64 stack overwrite to return to that known address and perform the overwrite which would then give our x64 shellcode execution. Simple /bin/sh shellcode was used.

Because the brute force was a random try, I just ran the script in a loop until it found a successful match.

Full python script

Full mips shellcode

Honeynet Project - Forensics challenge 14 - Weird Python

Kenny K — Mon, 20 Apr 2015 05:00:00 GMT

This is my writeup for the Honeynet Project - Forensics challenge 14 - Weird Python there were multiple SSL and HTTP connections.

I initially opened the pcapng in Wireshark and saw that there were multiple SSL and HTTP connections. Rather than combing through wireshark looking at each one I went investigating tools that would analyze HTTP traffic from a PCAP.
I stumbled on pcapperf - a pretty nice web based analyzier. It shows results similar to the network tab in chrome's inspect interface. The site does not operate on pcapng format, so I converted it to pcap using wireshark's save feature.

Using this I was able to see the various sites visited, and also the method the attacker used (Questions 1, 2, 3, 5). Using wireshark I extracted the downloaded game from the fake website.

Answers to the various questions follow.

1) BYOD seems to be a very interesting topic. What did your boss do during the conference?

Visited Google.fr and Google+
Reddit.com
Searched reddit for "byod"
9gag.com
thewayoftheninja.org -> to download n

Links followed:

2) What method did the attacker use to infect your boss? Which systems (i.e. IP addresses) are involved?

Spoof'd the DNS response for "www.harveycartel.org" to be 81.166.122.238
ninja-game.org also resolves to this IP

3) Based on the PCAP, which files were exfiltrated? List the filenames.

C:\Users\admin\Desktop\sensitive+documents.doc
C:\Users\admin\Desktop\Tools\odbg201\help.pdf
C:\Users\admin\Documents\private\affair\holiday\EmiratesETicket1.pdf
C:\Users\admin\Documents\private\affair\holiday\EmiratesETicket2.pdf

Exfiled to http://ninja-game.org/submit_highscore

Using a combination of wireshark and https://pcapperf.appspot.com/view?hash_str=5349ea30533d7fbdc03257d27e301ed8

4) Can you sketch an overview of the general actions performed by the malware?

The initial download pretends to be the game the user downloaded. It's a self extracting rar that does 2 things

Runs the python dropper main.pyc
Runs an older version of the game

The dropper retrieves a payload which then exfils all *.pdf, *.doc, *.docx, *.xls, and *.xlsx files in the current user's home directory.

Used:
Python source
IDA Pro
unwind - https://github.com/evanw/unwind
uncompile 2 - https://github.com/wibiti/uncompyle2

Modified unwind to take into account the modifications that were made to the python's marshaling code.

5) Do you think this is a targeted or an automated attack? Why?

Targeted to visitors who download the game; an older version of the game was included, not the one download.

6) The malware seems to be written in Python. Is this "normal" Python? What's different?

It's fairly normal.. once you get past the bytecode obfuscation.

-- All code objects had a fake 226 byte code object:

import sys
sys.exit('\r\ndebugger detected.\r\nsignature: 233f3f3b7164642c2424652c276431723a7d021e')

added to stop debugging/reversing without using the embedded python interpreter

Also, all string objects (which included the bytecode) were masked with a rolling xor pad.

i = len(s) - 1
cur = 43
while i >= 0
  s[i] = s[i] ^ cur
  cur++
  i--

7) What does main.pyc do? (Bonus: Can you provide a decompiled version?)

It reads the USERNAME environment variable, and makes a request to http://ninja-game.org/highscores?{USERNAME} to retrieve the main payload.

The main payload is masked using some algorithm

{% include_code lang:python weird_python/dropper_main.py %}

8) How is the final payload protected? How is it decrypted by the dropper? (Bonus: Can you provide a decompiled version?)

{% include_code lang:python weird_python/payload.py %}

The final payload in protected with a simple substitution cipher.

9) Why did Pete leave the company?

His wife has a ticket on the same flights as the boss

10) Your boss mentioned he's going to the Honeynet Workshop in Stavanger, but you're not allowed to join him. Why so?

He's actually going to Dubai

11) Bonus: There are five superheroes hidden in the challenge. Which of them did you find?

12) Optional: Please provide some feedback on the challenge! What did you like/dislike?

Choosing sync/cloud software

Kenny K — Thu, 05 Mar 2015 22:33:00 GMT

There's a few new computers in my circle of family - my parents just bought one and my wife's laptop and phone - and I need a better solution for backing up everything.

My previous solution CFTBackup was no longer working for windows computers as they were reinstalled or replaced. And I never got the whole part of the offline sync working; plus after using a simple rsync for almost 4 years, I've determined that the 150Kbit/s limit was more than adequate to back things up in a timely fasion and a lot less hastle.

So it's time for a new solution. I recently bought two new HGST Deskstar NAS 4TB hard drives as space was starting to get full on my 1.5TB (at my house) and 1TB (my parents house) drive's.

For refresher the hardware the drive is going into:

Intel BOXD510MO - An Intel Atom based board; populated with 2GB RAM
Mini ITX Case

Now I needed to find a better solution to sync the two backup systems and backup the files off the desired systems.

Requirements

Files are stored on the backup system in the same hierachy as on the target systems. I don't want to be tied to a particular software platform. This means no binary blobs of random names.
Client should exist for Windows and Linux (at a minimum) and preferably Android
- Automatic startup on windows and linux
- Ease of use
I shouldn't need to have a copy of everything everwhere. E.g. I don't need my parents data on my laptop.
The solution should support some form of versioning so that I can restore an older version of a file (up to some point in time)
Some level of access control; not necesarily by username/password
Ability to have multiple "servers" with copies of the data. I should be able to configure it so that files are only sync'd to one location if I desire.
"Headless" mode as a full feature. Not some hacky solution
Ability to handle 350,000 files; approx 1TB right now.
Free
Preferably open source

Things it doesn't need:

Enterprise level number of users
Git integration
Cloud based backup

Other things that would be nice

Ability to share a file publicly
Ability to have a append only backup
- E.g. I pull pictures from my camera onto my laptop, once they are backed up and I'm done with them, I want to delete them from my laptop, but have them still be on the server.

The Products

I've basically found three categories of products so far:

Cloud Backup Solutions
Cloud Storage Solutions - (think DropBox)
P2P Sync Solution

Cloud Backup Solutions

The only product in this category that I found with a linux client was CrashPlan.

Crashplan

Pros:

Easy setup
Has Windows, Linux & Android Clients
Easy setup, ability to share space with not just yourself, but friends
Cloud backup option
Not tested, but you can have multiple backup locations
Has versioning, but limited to Week old, 90 day old, 1 year old, and 2 years old

Cons:

Requires java
The headless mode isn't supported, but is possible because it takes advantage of how the management is client/server
All backups are in a proprietary binary format
Not open source
Not real time backup (only backs up on interval)

Cloud Storage Solutions

I found a few in this category, along with some that are no longer maintained. One of the requirements for this category was that I need to be able to run my own server.

It turns out I didn't look at any of these solutions for the backup portion for the following reasons:

Lack of multi-server support (with distint storage, not just load balancing with shared storage)
Data is stored in binary "proprietary format"
Poor performance reviews

P2P Sync Solution

This solution is closest to what I was using with my rsync setup. By definition it copies files in the same directory tree as the source.

Both of these programs are very similar in that all they do is attempt to keep two folder in sync.

Both use a cryptographic key to identify peers
Both are a pure sync and do not have the ability to share a file publicly
Both can add a device to an android phone using a QR code
Both have upload and download limits

BitTorrent Sync

Pros:

Windows, Linux and Android Clients
Can place placeholder files in a directory, showing that they exist, but not downloaded
Can work through NAT firewalls as it uses a public tracker

Cons:

Not open source
No versioning
When trying it out I somehow managed to create two identities and didn't know how to delete one on my android device.
- I think identities see everything shared from every computer, but you can share between identies.
Shows up using CPU even though no files are changing. (1-5% on windows)

Syncthing

Pros:

Open Source
Can control which shares are shared with what computers
Can set a folder as a "Folder Master" which means it's essentially read-only to other computers - changes on other computers are not synced to this computer
Supports two types of file versioning
- Simple versions, with a max count
- Staggered versions up to a set time. A version up to every 30 seconds the first hour, Every hour up to 30 days, and then a week after that - Similar to a Grandfather-father-son type backup. Can keep versions forever
Has ignore patters to ignore syncing of certain files/directories - e.g. Can ignore .git directories!
Maxes out my upload if I let it.

Cons:

Requires opening firewall (UPnP or by hand) for communication - not an issue as I have a VPN configured between the backup systems
Windows automatic startup requires a separate program
Any configuration change requires a restart of the services, which breaks all connections
Android app is VERY alpha.. (not even beta)
Folders are identified by name only. So if computer one shares a folder named "Photos" and shared with Computer 2, it will be treated the same as a folder named "Photos" shared by Computer 3

Meh's (for me.. might be Cons for a lot of people):

No concept of users - every computer/installation is unique.
If a folder is shared with one computer, that computer can share it with others.

Decision

I think I'm going to try Syncthing for starters. I will probably continue to use rsync for my Pictures backup (and probably most of the the things from my laptop). Unrelated, I plan on using Gitolite for keeping a copy of my code and using it's mirror feature to back up my repositories.

If I find I absolutely need file sharing, I've played around with Pydio a little bit and it looks like you can have a standard filesystem be the backing (with a normal tree layout) and configure it to just do sharing. Though that seems like overkill for something so simple that I want to do.

BkPctf - Alewife

Kenny K — Mon, 02 Mar 2015 17:00:00 GMT

The name of the file should have given us a hint as to the nature of the problem.. but it took me a while as I just started working on it and didn't pay attention to the name (nor see the problem description text).. and of course my modus operandi is to reverse engineer things to find a vulnerablity, so I didn't connect but just dove into the reversed binary so I didn't pay attention to the ArrayOps string.

The problem was a pwnable, which meant that there was a vulnerability somewhere. My job was to find it. But first I had to understand what the program was doing as the only output strings were:

"**:"
"***:"
"ii:"
"iii:"
"ss:"
"sss:"
"ArrayOps\n"
"--:"

The input to the program is through three functions (as I named them), after printing a prompt they do their respective action.

GetUint (0x400960) - gets up to 0x3f bytes into 0x40 sixed cleared stack buffer, then calls strtoul
GetInt (0x40097f) - gets up to 0x3f bytes into 0x40 sized cleared stack buffer, then calls atoi, returns value
Get_0x3f (0x400a04) - gets up to 0x3f bytes with a single read into a malloc'd buffer

Sadly, none of these were vulnerable to any overflow, so the bug had to be somewhere else.

After a while reversing we determined that the code allowed you to manage three types of arrays:

Mixed String/Integer arrays.
Integer arrays
String arrays

Each array was a fixed size of up to 256 elements, and you were limited to 32 of each type. The main function was a loop that allowed you to select the type of array, and then perform an action. After reversing we discovered the menu tree:

1 - Mixed Arrays
- 1 - Allocate a new array
- 2 - More operations
  - 1 - Add integer(s) to array
  - 2 - Add string(s) to array
  - 3 - Remove last element from array (decrement count)
  - 7 - Subtract two integer values
  - 8 - Add two interger values
  - 9 - Concatenate two string values
- 3 - Clear an array
- 4 - Print the array
- 5 - Copy the array to a non-mixed type
2 - Integer Arrays
- 2 - More Operations
  - 1 - Replace array elements
  - 3 - Sort array
  - 4 - Remove the last element (decrement count)
- 3 - Clear Array
- 4 - Print Array
3 - String Arrays
- 2 - More Operations
  - 2 - Replace array elements
  - 3 - Sort arry
  - 4 - Remove last element
- 3 - Clear Array
- 4 - Print Array

All of the functions that would take an index verified the index was >= 0 and < 32. As you may have noticed, there is not a way to directly allocate a single-type array, you have to use the copy function, which requires all elements to be of the same type.

Each of the arrays used a structure:

//Structure for mixed array
//int is an 8 byte type
struct mixed_element {
	char type; // 2 = number, 3 = string
	char pad[7];
	struct {
		int value;
		FUNC_PTR to_str;
		FUNC_PTR add;
		FUNC_PTR subtract;
	} number;
	struct {
		char *ptr; //Pointer of the string from the user, allocated in heap as read by Get_0x1f
		FUNCPTR to_str;
		FUNCPTR strcat
	} str;
}

struct MixedArray {
	char allocated;
	char pad[7];
	mixed_element data[256];
	int numElements;
	FUNCPTR printFunction;
}

//Structure for Integer and String Arrays
struct array {
	char initialized;
	char pad[7];
	DATA_TYPE data[256]; //DATA_TYPE is int for integer arrary, char* for string arrays
	DATA_TYPE *pData; //Pointer to the start of data.
	int numElements;
	FUNCPTR printArray;
	FUNCPTR sort;
}

// Layout of BSS
MixedArray mixed_arrays[0x20]; // 0x602ec0
array int_arrays[0x20]; // 0x6831c0
array str_arrays[0x20]; // 0x6936c0

There's nothing there for type confusion as the values in the mixed array do not overlap, and the integer and string arrays are separate. But what does stand out is the pData member of the integer and string arrays, why is it needed if the array contents are statically allocated, if we could somehow get something into this pointer we could have a potential arbitrary write.

The print, to_str, sort, add, and subtract functions all looked ok. The strcat had a bug with it's use of realloc - if you passed in the same index to copy, it would free the data pointer (with realoc), but sadly, there wasn't a way to re-use the pointer as every read malloc'd a new buffer.

So I then started looking at other functions. When I found get_int_array

int get_int_array() {  //0x400cd3
	int result;
	array *c;
	int idx;
	
	for (idx = 0; idx < 0x20; idx++) {
		c = &int_arrays[idx];
		result = is_initialized(c);
		if (!result) {
			int_array_ctor(c);
			return idx;
		}
	}
	return result;
}

//for completeness
int is_initialized(array *a)  { //0x400c5a
	return a->initialized;
}

void int_array_ctor(array *a) { //0x4021db
	a->pData = &a->data;
	a->numElements = 0;
	a->initialized = 1;
	a->sort = SortIntArray;
	a->print = PrintIntArray;
	memset(a->pdata, 0, 0x256 * 8);
}

So it looks like that function always will return an empty freshly initialized array... but what happens if all the arrays are in use?
It returns the value of the last is_initialized() call, which happens to be 1. Which means that whatever function was calling this that thought it was getting an empty array isn't. I had found the bug. But now how to use it as all the read functions from the user verify that we're not sending more than 256 values.

It turns out this function was only called in the copy_to function.
The basic layout of the copy to function was:

int copy_to(mixed_idx, type) { //0x4016e2
	if 8mixed_idx > 0x1f) 
		return -1;
	if (type == 2) {
		to_idx = get_int_array();
		if (copy_to_int(&mixed_arrays[mixed_idx], &int_arrays[to_idx]) != 0) {
			memset(&int_arrays[to_idx], 0, sizeof(array));
			return -1;
		}
	}
	else if (type == 3) {
		to_idx = get_str_array();
		if (copy_to_str(&mixed_arrays[mixed_idx], &str_arrays[to_idx]) != 0) {
			memset(&str_arrays[to_idx], 0, sizeof(array));
			return -1;
		}
	}
	return to_idx;
}

Not much there.. but if we looked at the individual copy to function:

int copy_to_type(MixedArray *mixed, array *ar) { //copy_to_int @ 0x400b69
	i = 0;
	if (mixed && mixed->numElements <= 0x100) {
		type *pData = ar->pData;
		while (i < mixed->numElements) {
			mixed_element *c = &mixed->data[i];
			if (c->flag != TYPE) { //TYPE == 2 for int, 3 for string
				return -1;
			}
			pData[i] = mixed_element->type.value;
			ar->numElements++;
			++v5;
		}
	}

Did you notice something above in copy_to_type? Even though the copy starts at element 0, the number of elements is never reset.

So it looks like we could make numElements greater than 256, however we can't just write arbitrary values.. as copy_to is always starting at index 0, and the replace array functions validate that we aren't sending more than 256 elements. But it turns out we have a very useful function, sort! All we need to do is inrease numElements and then sort the value we want into pdata.

One issue is that in order to use sort, I either need to have my desired pData be greater than the current value (meaning it's just pointing at other data or heap), or the function pointers get sorted to a bad value as they are less than the original pData. If all I needed was an arbitrary write that would be ok, but I need an info leak in order to make the exploit easier. I chose to two a two stage approach by first setting pData to iself, then changing it to my final desired value and restoring the function pointers in the first arbitrary write. Then leaking my information and finally getting execution control.

So now for the exploit (high level, as the implementation is left as an exercise for the reader)

Create a new mixed array #0
Fill it with [0]*254 + [0xfffffff]*2
Copy the array 20 times to fill up all integer arrays
Create a new mixed array #1
Add some integers to the new mixed array. These values will be what we sort into pData
- I added 4 copies of &int_arrays[1].pData
Copy mixed array #1 (it will go into int_array[1], and increase num_elements to 260)
Then sort the 2nd integer array (idx 1)
- it's pData member now points to itself!
Create a new mixed array #2
Add the values [ &GOT, 0x40, &PrintIntArray, &SortIntArray ]
Copy the values from mixed #2; this will copy them to array idx 1 again, changing pData to point to the GOT, and restoring the function pointers (and making the size sane)
Call print int array with idx 1 to leak information about libc
Change the atoi entry in the GOT addresses we received to the address of system() based on the information we just leaked
Create a new mixed array #3
Put the updated GOT values into mixed #3
Copy mixed #3; which will overwrite the GOT
Now any value we send for a command is executed via system()
Run a shell!

The final flag was: Because_C++_is_t00_hard!!!

BkPctf - Kendall

Kenny K — Mon, 02 Mar 2015 03:01:00 GMT

I was going to write how to solve Kendall, a "pwn" challenge, but the author posted a nice write up

I probably spent a good hour and a half looking at the binary trying to see if something is exploitable (good job!) before I managed to figure out the DNS request part. I only managed to find two bugs:

You could remove the null terminator on the IP address by writing an address of exactly 16 bytes (eg "1111111111111111")
If you made the Source, Dest, and netmask all 16 bytes, and the Nameserver 3, the renew_client would print an error. This was due to the snprintf before the system being truncated.

I did learn an important lesson. If there's an opportunity to put a hostname or ip somewhere PUT IN AN IP YOU CONTROL

I ended up using dnsmasq for dns as I had a server that wasn't running dns. I'll have to take a look at minidns for next time. I ended up using python's SimpleHTTPServer:

python -m SimpleHTTPServer 80

And a real simple HTTPs server I found on the web

import BaseHTTPServer, SimpleHTTPServer
import ssl
 
httpd = BaseHTTPServer.HTTPServer(('0.0.0.0', 443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='./server.pem', server_side=True)
httpd.serve_forever()

BkPctf - Wood Island and Orient Heights

Kenny K — Mon, 02 Mar 2015 02:18:00 GMT

This weekend was the Boston Key Party Ctf. There were a bunch of challenge, and my team did pretty well (top 10) even though we didn't have a lot of our regulars. Two of the problems involved signing a string "There is no need to be upset" using Elgamal signing.

The TLDR version is both failed in the duplicate checks.

Both problems required "proof of work" prior to the signing test:

Server reads 9 bytes of random data and generates a base64 encoded version
Sever sends the base64 to client (12 bytes)
Client adds up to 8 bytes
Server then verifies first 12 are the ones it sent
Server computes SHA1 hash of all 20 bytes
Hash must end with 24 bits of 0 to pass

Once you passed the proof of work you had to send the message ("There is no need to be upset") and signature (r and s). The format of the message and signature was json with Wood Island, and asn1 with Orient Heights. If the signature passed you were rewarded with the key.

Along with the server script and the key information, we were given a collection of valid signatures, lest we had to brute force up to a 1024 bit private key. However, even though the message that the server wanted was in the example signatures, the server checked that we weren't sending a duplicate signature.

Here in lies the flaw we used. Wood Island used the python json library to decode the string into a dict and the duplicate check was a simple "user_dict in list" check. Adding a field to the json was enough to pass the check. Orient Heights just compared the binary ASN1 encoding; once again adding a field caused it to fail.

Now for how you are supposed to solve them... Looking at the list of signatures, we noticed that there was a few that used the same value for r. Elgamal signing has a known issue that if you use the same value for r (really the random k), then you can compute the private key using Linear Congruence. There's a nice question and answer on cryto.stackexchange on how to do it. Of course I wasn't quite up to speed on my Linear Congruence, so I found a helpful page on how to solve them.

#!/usr/bin/python

from dsa_key import *
import dsa
import hashlib
from dsa_prime import *
from dsa import elgamal_verify as verify
import code
import json
DUPLICATES = open('sigs.txt', 'r').read().split('\n')[:-1]
DUPLICATES = map(json.loads, DUPLICATES)

#Read the signatures
with open("sigs.txt", "rb") as f:
	lines = f.read().split('\n')[:-1]

d = map(lambda v: json.loads(v, encoding="utf8"), lines)
# Find only have valid
#working = [i for i in d if verify(**i)]

# I saved them off in a single json file to make things faster
working = json.load(open("working"))
d = working

# expected value
expected = "There is no need to be upset"
# The function to convert a string message into the hash for signing
hash_val = lambda m: int(hashlib.sha384(m.encode("utf8")).hexdigest(), 16)
e_hash = hash_val(expected)


r_list = [ i["r"] for i in working ]
dup_r = [ i for i in r_list if r_list.count(i)>1][0]
 
dups = [ i for i in working if i["r"]==dup_r]
import gmpy
from gmpy import mpz
from gmpy import gcd

g = mpz(GENERATOR)
p = mpz(SAFEPRIME)

s = [ mpz(i["s"]) for i in dups ]
r = [ mpz(i["r"]) for i in dups ]
m = [ mpz(hash_val(i["m"])) for i in dups ]


# SOLVING k(s[0] - s[1]) = (m[0] - m[1]) mod p-1
# ka = side2 mod p-1
a = s[0] - s[1]
side2 = m[0] - m[1]

num = gcd(a, p-1)
num = int(num)
print num

k_ = gmpy.divm(side2/num, a/num, (p-1)/num)
for i in range(0,num):
	k = k_ + (i*(p-1)/num)
	r_ = pow(g, k, p)
	if r_ == r[0]:
		print "FOUND K"
		break

# solve xr  = (m0 - ks0) mod p -1
side2 = m[0] - k * s[0]
num = int(gcd(r[0], p-1))

x_ = gmpy.divm(side2/num, r[0]/num, (p-1)/num)
for i in range(0, num):
	x = x_ + (i*(p-1)/num)
	y = pow(g, x, p)
	if y == PUBKEY:
		print "FOUND x"
		break

def sign(m_str):
	if type(m_str) in [str, unicode]:
		m = hash_val(m_str)
	else:
		m = m_str
	
	k = 55
	r = pow(g, k, p)
	s = gmpy.divm(m - x*r, k, p-1)
	return {"s": s, "r":r, "m":m_str}

LED Tie Bar - Software

Kenny K — Wed, 31 Dec 2014 00:45:00 GMT

The software isn't my best work. I did try to make the effects and color generation abstract, which is why I ended up using a Teensy vs an Trinket Pro or similar. I just needed more processing power.

The software that was loaded when I gave them out as gifts is available at https://github.com/r3dey3/led/tree/tie_bar_v1

One of the neat things I did, was instead of using a ground pin for the inputs (button, and jumper) I simply set on of the pins as an INPUT_PULLUP and the other as an output set to LOW. This isn't an issue for the button, as it's only momentarily pressed, but in order to not waste power through the pullup to ground (I know, it wouldn't be that much) I just check the status of the jumper at startup after setting the state of both pins, waiting, then set both pins to tri-state by setting them to INPUT)

bool ColorsEnabled() {
	//Check if jumper is in place
	
	pinMode(17, OUTPUT);
	digitalWrite(17, LOW);
	pinMode(19, INPUT_PULLUP);
	delay(5); //give things a slight chance to stabilize 
	bool enableColors = digitalRead(19);
	pinMode(17, INPUT);
	pinMode(19, INPUT);
	return enableColors;
}

There will be more written here hopefully after the honeymoon. Just ran out of time write stuff.

LED Tie Bar - Hardware

Kenny K — Wed, 31 Dec 2014 00:44:00 GMT

Parts list

For each:

Generic Metal Tie Bar - http://amzn.com/B00E5YW8L6
Teensy 3.1 - https://www.adafruit.com/products/1625
NeoPixel Stick w/8 Pixels - https://www.adafruit.com/products/1426
Micro Lipo Charger - https://www.adafruit.com/products/1304
500mAh LiPo Battery - https://www.adafruit.com/products/1578
JST-PH 2-Pin Breakout Board - https://www.adafruit.com/products/1862

Other parts used:

Tactile Switch (6mm slim) - https://www.adafruit.com/products/1489
Extra long break away male header - https://www.adafruit.com/products/400
Silicone Cicoil wire - 4 pin, 24 AWG - https://www.adafruit.com/products/1437

Shematic

This is going to be described as I don't have a picture and it's pretty simple. The picture shows almost all the connections. What you don't see are the power and ground coming from the breakout to the silicone cable.

Power and ground from the JST Breakout goes to both the Teensy and the NeoPixels
The button is soldered onto the Teensy between pins 20 and 23
The jumper is soldered onto the Teensy between pins 17 and 19
The Input of the NeoPixels is soldered to pin 7 of the Teensy

Electronics Assembly

Sadly I don't have any pictures during assembly. I ended up doing things in assembly line fassion as I was making 10 of them. It really helped me hone my process.
The image to the right shows how the silicone cable is soldered to the underside of the JST breakout, which after trial and error seemed to be the best way to connect the power and cables to keep everything as compact as possible.
The steps that I ended up taking were:

Solder the button to the Teensy
Solder the jumper to the Teensy, on the ones for gifts I used an extra long header that I bent into a U shape to go between the pins
Solder a standard size male header pin to the outside ground pin on the JST breakout, long side sticking out the bottom
Solder a extra long male header pin to the outside positive pin on the JST breakout, on the TOP
Trim the silicone wire so that two wires are shorter, and the other two have enough to reach to pin 7
Strip the short wires
Solder the short wires to the bottom of the JST breakout (both + and -), so that the extra wires are on the + side
Cut back the 4th wire from the silicon (if what was soldered to the minus side of the JST breakout is now the 1st)
Strip the 3rd wire and solder it to Teensy Pin 7
Add an extra black spacer to the long header breakout that is in the + side of the JST heder
Bend said header over so it will reach the + pin of the Teensy
Solder both the - and + on the Teensy
Strip all 4 wires of the other end of the silicone cable. What I found works best is just taking an x-acto knife and pressing it to each flat side of the cable and pulling the piece off, stripping all 4 at once
Tin all 4 wires
Solder the 4 wires to the back of the NeoPixels
Sand the surface of the tie bar to expose raw metal
Tin the surface of the tie clip
Solder the Neopixels through the mounting screw holes to the tie clip. I made a little jig to hold the tie clip (because it got HOT) and the Neopixels in place so every one was very close to the same position. This required a lot of solder to bridge the gap

LED Tie Bar - Overview

Kenny K — Wed, 31 Dec 2014 00:43:00 GMT

For my groomsmen gift for my wedding, I decided to do an LED tie bar. I think it turned out pretty well. Hopefully they will all like them (and they don't see this before they get them!)

The bar is a metal tie bar with a 8 NeoPixel (WS2812B) LEDs on it. There is a microcontroller with a push button switch on back for changing the effects and colors. However, as the wedding colors are blue and silver, there is a jumper in place that limits the colors to blue. Cutting this jumper will enable the full range of colors.

The effects are:

Fickering
Cylon
Theater chase in one direction
Theater chase in the other direction
Fade between dim and bright and back
Fade between on and off
Fade between on and white
Sin mix between color and black (like Cylon, but only one direction)
Sin mix (black) in other direction
Sin mix between dim and bright in either direction
Sin mix between on and white in either direction
Blinking
On Dim
On Medium
On Bright (very very bright)

Once the jumper on the back is cut, the full list of colors is:

Blue
Purple
Red
Yellow
Green
Cyan
Rainbow (each led a different color)
Rainbow cycle slow (bar is a solid color, but it cycles through the HSV spectrum by hue)
White
Rainbow cycle fast

DEF CON 2014 Finals – wdub v2

Kenny K — Wed, 13 Aug 2014 16:00:00 GMT

Once again I’m gonna talk about the 2nd version of a service from DEF CON 22’s CTF finals. This time it’s wdub; a simple HTTP server.
Version 1 had an integer overflow which lead to a stack overflow.
(edit: DEF CON CTF Challenges available @ http://shell-storm.org/repo/CTF/Defcon-22-finals/)

It turned out version 2 had two bugs. A use after free, and an integer overflow buf. To start with version 2 added a new http method – EVAL, where it ran something over the POST contents (with optional decompression), it also made POST requests to a file ending in ydg a script type page with

I spent the first bit of time reversing the new command to figure out what it was doing as I didn’t have an SLA check network traffic yet. The first part was figuring out the language. It turned out to be a simple

var = command arg1 arg2 ...  
OR 
command arg1 arg2 ...

Depending on if the command allocated a new variable.

The commands:

[name]=gimme [size] - allocate item
  - first 4 bytes of data is size... 
Yo [name] - lookup item:
  switch field8
    if 1,2,3 copy 0,1,3 btytes of databuf to output
    else copy *databuf (int) bytes to output
putitin [item1] [item2]  [item3 or num] - FIXED SIZE ONLY
	offset = item3.data or num
	memcpy(item1 + offset, item2, item2.size)
pullitout [item1] [item2] [item3 or num] - FIXDED SIZE ONLY
	offset = item3.data or num
          memcpy(item1, item2+offset, item1.size)

nomo [item] - free item
[name]=dupme [old_name] - duplicate item
[name]=shebewalkinfunny [number] - new 4 byte number
[name]=datbetta [number] - new 2 byte number
[name]=pobastard [num] - new 1 byte number
[name]=makeit [num] - expand buffer

bonut [name] [offset] - bit invert
  if not 1,2,4 byte value: bit flip byte at offset (+4)
oudahere [name] [num1] [num2] - delete num2 bytes at num1 from name; no check on type of item (arb length or fixed length)**

putdatader [name1] [name2]  - append item2 to item1 (arb data only)
slipitin [item1] [item2] [offset] - insert item2 into item 1 at offset (arb data only)
slapitup [item1] [item2] [item3_or_offset] - copy item2 into item1 at offset (overwrite) (arb data only)

[name]=moagin, eatdata, splitdat, screwdat [item2_or_num] [item3_or_num];
  +, -, *, / 
  name = num1 OP num2
  if item1 doesn't exist, creates 4 byte item

exite, bandit, borit [item1] [num] - for fixed size items
  xor, and, or
  item = item1 OP num
exite, bandit, borit [item1] [offset] [num] - for var size items
  xor, and, or
  item[offset] OP= num (byte)

deyseme ... bit shifts
 >>, <<, ror, rol

The use after free bug is due to the dupme command not doing a deep duplication. It only duplicates the data storage structure of:

char* name
char* data; //if a buffer it's a pascal style string buffer with the length being the first 4 bytes, otherwise it's a pointer to a 1, 2, or 4 byte buffer
int type; //0 - buffer, 1- char, 2 - short, 3 - dword

However the bug I went after was in the putitin command – something that would copy a 1,2,4 byte value into an offset location in a buffer. It turns out the check for if this size of the buffer is large enough was written like:

if (offset + 4 <= *(uint32_t*)(dest->data)) ...

Now if you can notice here.. if offset == -4, then offset+4 will be 0.. and 0 is < = any unsigned value. So good.. we can overflow the offset.. well what happens with that.. it turns out the copy to copy the data is:

memcpy((dest->data)+4+offset, src, 4)

And from the fact that the “size of buffer” is stored at the first 4 bytes of the data pointer (eg pascal strings) we can set the size to whatever we want.. which means if we set it to -1, we can then write ANYWHERE in memory.

Well that’s great.. ASLR is enabled.. well .. looking at the structures used, it turns out that the eval structure, has an field for length written (using the Yo command to write).. well we can change that length as we know the relative offset of that field to our allocated data (deterministic heap ftw)

Structure used to store eval results:

struct eval_result
char *outBuf;
uint32_t bytesout;
...

The outBuf is set by the function calling into the eval, and is a stack variable. it then uses the bytesOut to send the data at that location to the client. Well now we can leak addresses…

So we now know where the stack is. And since we can write anywhere, we can change the address of the data pointer in our buffer once we change the size… then we can change the stack..

So the final sequence is:

"b=gimme 4"
"c=shebewalkinfunny -1"
"putitin b c -4" #enable write anwhwere
"d=shebewalkinfunny 1024" #how much we want to leak
"putitin b d -424" #offset of data point to bytesOut

DEF CON 2014 Finals - imap v2

Kenny K — Mon, 11 Aug 2014 16:00:00 GMT

This year, like last LegitBS released updated services part way through the competition with the old vulnerabilities fixed and new ones. The first imap service (implements the IMAP protocol) had a bug in the SELECT command that would overflow the mailbox name, allowing one to change the username to “.” which would then allow listing/reading all users mail (things were stored in a directory per user)

(edit: DEF CON CTF Challenges available @ http://shell-storm.org/repo/CTF/Defcon-22-finals/)

But in v2, this bug was fixed… instead it was MUCH more evil. instead of being stored in plain text, messages were base64 encoded. Not a huge deal, but what was weird was the message was base64 decoded in the STORE handler. This command only updates message flags, there’s no need to decode the contents… Encoded messages were limited to 1000 bytes, which means that a decoded message could be 750 bytes large… turns out the buffer that the message was decoded in was only 740 bytes… this allowed us to overflow whatever came after the buffer. It turns out this was a pointer to the flags, which were written right before the function returned. It’s only a 1 byte write … with only control over bits 1-6 (0-7 numbering). Bit 7 was always 1, and you could either leave bit 0 as is, or clear it. The basic pseudo code was:

    update_flags(aMode, aFlags) {
    int len;
    int new_flags;
    uint8_t flags;
    char decoded_buf[740];
    uint8_t *pFlags;
    char encoded_buf[1000];
    get_message(&buf, &flags, len);
    base64_decode(encoded_buf, len, decoded_buf);
    new_flags = parse_flags(aFlags); // bit or of result of parse with 0x80
    if (mode == SET_ALL) // command option is FLAGS
        *pFlags = new_flags;
    if (mode == SET) // command option is +FLAGS
        *pFlags |= new_flags;
    if (mode == CLEAR) //command option is -FLAGS
        *pFlags ^= new_flags; //xor
        *pFlags |= 0x80
    store_flags(...);
}

Now the question is what to write.. luckily there was also an info leak .. Messages were given a unique id that was randomly generated when the mailbox was created. It so happened that the random numbers were not actually the result of calling rand.. (intentional…) one turned out to be the stack canary, the other was an address on the stack.. So now we know the address of the stack, and the stack canary for our fake stack frame… now how do we get a stack frame where it’ll be used. This was the hardest part.. now luckily the stack was executable.. but we couldn’t just change a return address because we didn’t know the value present and we couldn’t write the low bit and stacks are all in high memory..

It turns out that main uses r7 as a frame pointer, and the update_flags function stores this variable on the stack for us. we could change main’s frame pointer, and when it goes to return it may read from space we have control over.. well first I just tried moving r7 by a small amount, that way the previous command input would be used as the stack.. however this has a problem – if we only change r7 by a small amount (512) we are still close to sp.. and when main would call bzero, the data buffer that was being cleared was part of the stack frame for bzero, which would mean r7 was cleared and main would then crash. Eventually I found the function that handles the FETCH command. it has a very large stack frame and the decoded message is read info a buffer.. I could move r7 to point to an address that when used by main to return would point to the message data.

So that was the “easy” part..the next part was dealing with ASLR.. not only was simple ASLR turned on where the page address changed, but the stack randomization was turned on as well. which meant that the stack was aligned at 256 byte boundaries (meaning 24 bits of random).. and I was trying to reduce the frame by an order of 3000 bytes.. I needed to calculate not only the necessary flags (stored as bitfield) to change r7, but also the new return address (luckily stack was rwx), offset of the stack canary and return address in my message that will be used as the stack frame

So final sequence was:

Create mailbox
Leak stack canary and stack address with EXAMINE command
Calculate address of various things on stack
Determine a valid address i can set r7 to that will put the return address of main into my buffer, not the offset of the frame end
Create messages that will allow me to set low two bytes of r7
Create message – main’s new stack frame, using the offset calculated
Send STORE to update 2nd lowest byte of r7 (jump far away first, as main does bzero and we don’t want to overwrite stored stack frames)
Send STORE to update low byte of r7
Send FETCH to retrieve stack frame
Return from main

Actual implementation is left as an exercise to the reader. Sadly I wasn’t quite able to get this done during the competition.. going on no sleep Saturday night was a little hard.. I was close, I just failed to use my calculated offset in the calculation of the return address.. everything else was in place.. of course then getting shellcode to find the key in the messages was the next step.. and that wasn’t done.