The Walkthrough – Brainpan2 Written & Solved by @Vinicius777_ Challenge Designed by @superkojiman Dec 2013 Brainpan2 is the challenge designed by superkojiman, which have been solved by me, reach vinicius777 [at] gmail for questions and review. The challenge is full of tricks and interesting stuff. Frustration was part of the process as well. From the beginner to the end, Brainpan2 is one of the most fun challenges ever made. Down bellow I will write the walkthrough narrative and methods adopted by me, remembering, brainpan2 may have others methods on getting the flag file. I considerate The End once I got /root/flag.txt Have fun ;) Tools and Frameworks Utilized ! Arachini Web-­‐Scanner Framework: Arachini web-­‐scanner present on Kali Linux repositories was used as web scanner to encounter common directory and possibles knowing vulnerabilities. ! NetCat: As an indispensable tool, nc was used several times. ! Strings: also present on Kali Linux repositories strings is useful when auditing non-­‐text files for determining their contents. Pag. 1 ! GDB: a well knowing Linux Debugger. ! Nmap Scan: A powerful port scanning. NOTE: Additional tools and others piece of code may not be listed in here. However, all additional code used to exploit will be listed on appendix on the end of this document. Attack Narrative Upon nmap port scanning were identified 2 open ports, 9999/TCP an unknowing application banner retrieved also 10000/TCP was running with SimpleHTTP Server 0.6 (python written) application. When first accessed a graphic image contented a statistic number of attacks over the web was displayed. Arachini also found a /bin directory with a single file called brainpan.exe. Once downloaded the file, a file Linux command identified the header as a JPEG, differently than the extension .exe suggests to be. When renamed brainpan.exe to brainpan.jpg the following image was displayed. On port 9999, a different application was running and accepted login as “GUEST” and “DEBUG” users. Pag. 2 “TELL ME MORE” listed possible commands that could be executed by the application and helped to gain the first shell connection once piped the command VIEW due to not properly filter user data input. Once gained shell connect the enumerate process conducted to a SETUID file (Set User ID upon execution) presented on /home/reynard/ directory owned by the user root. NetCat was used to copy the msg_root from brainpan2 to attacker machine and audited with the strings Linux command. Pag. 3 The msg_root usage indicated two user data input and the “username” and “message”; username field was buffer overflow vulnerable due to use the incorrect call strcpy (vulnerable) instead of strncpy call on message field for example. By using GDB Debugger as priority of identifies in exactly number of bits the application crashes, 14 bits were sent and the next bit overwritten EIP instruction proofing the buffer overflow. Remembering, there is no GDB access on the brainpan2 shell yet and place any shellcode in memory would be a difficult task as memory address on attacker machine are totally different then brainpan2 addresses. The solution was researching about small buffer overflow attacks and an amazing paper came up written by Aleph One, located at http://insecure.org/stf/smashstack.html, the paper advises to place the shellcode into Pag. 4 the Linux environments and point the respective memory address on EIP to completely code execution. Two exploits were used, one to loaded the shellcode on linux environment ($EGG) and other one used to retrieved the exactly memory location of $EGG env. NOTE: Both codes are provided on appendix section at the end of this document. Eggcode and findeggaddr were both compiled (gcc eggcode.c -­‐o eggcode && gcc findeggadd.c -­‐o findeggaddr) on attacker machine and downloaded through wget. The memory address 0xbffffd6e corresponds to $EGG shellcode env already loaded by the eggcode C program. Always worth double checking the shellcode if is completely loaded by typing a set linux command. The 512 NOPs printed were expected and by looking at the end of the screenshot It’s also possible identified the shellcode completely loaded! Pag. 5 Once the shellcode is completed executed a new bash shell should pop-­‐up, giving the attacker machine root access as the msg_root holds a SUID owned by user root. Let’s execute the shellcode on msg_root application by sending those 14 bits plus the memory address where pointed to the evil shellcode located at $EGG env. Code execution worked!! However, root user has an uid 104… Huh? Does it seem normal to you? Neither to me! What if I told you … The brainpan2 isn’t finished yet!? No root privileges gathered as user root is different than user “root “ (space at the end) as indicated on the screenshot above uid and gid differents. Code execution gaves privileges, but not enough to see the flag.txt, so enumeration process continuous… Other SUID file encountered which may leads to an web application, although stick-­‐bit settled on the file as owned by puck user and has nether privileges but the efforts in seeing what is inside of the /home/puck directory might be worthy. Pag. 6 As screenshot above indicated, the brainpan.cfg file has been updated with the VM IP to provide access from “outside” (attacker machine), once the changes are made brainpan-­‐1-­‐8.exe would be executed for the next netcat connection on port 9333 as specified on cfg file. Application provided by brainpan-­‐1.8.exe seems to be the same one as previous exploited. Same method was used to gain a new fresh connection on port 443 reversely. The reverse connection worked as puck user privileges and the first task was to browsed inside puck’s home directory seeking for interesting files. Pag. 7 Puck user directory contented a .bash_history which correspond to the list of commands executed by the puck users, although the file was empty. Also, a hidden directory .backup had the same content, .bash_history, with 395 bits long, displayed on the screenshot on the right side. The highlight line refers a ssh attempt as “root “ user which corresponds to super user (UID 0) definitely this SSH attempted got fully of attention as the SSH server is active and listening locally on port 2222. Brainpan2 had all files required to SSH connect as user on .ssh directory present on .backup and a double check on /etc/ssh/sshd_config file was also required to make sure if the SSH Server would accepts RSA as authentication ans both were settled with “yes”. To the authentication with keys works without prompted the password, known_hosts, id_rsa and id_rsa.pub needed to be copied somewhere else to be placed into /home/anansi/.ssh directory by the anansi user, which is the right user to attempt the SSH connection as all opened sessions are derivate from anansi user. Pag. 8 All 3 files required have been copied to /tmp using puck user SUID session to be retrieved by the user anansi and finally placing on the right directory. Once copied all 3 files to /tmp a step back to anansi user session (first gained shell) was needed to copy all 3 files again on the right place at /home/anansi/.ssh directory as only anansi user would have access to. When copied, SSH would also required a permission adjust (chmod 600) on id_rsa file to be accessible only by the user whom created it, in this case, anansi user. Files were in the right place and finally anansi user was ready to attempt the SSH connection using “root “ as indicated the .bash_history file encountered. If works, the SSH connection would allow the key authentication by not prompting any password input and finally connecting as uid 0 allowing me to read the flag.txt file. NOTE: -­‐p 2222 indicated the port where SSH is listening and –t –t parameters indicated a forced connection from a non-­‐valid-­‐terminal. Pag. 9 W00t! W00t! W00t! W00t! W00t! W00t! W00t! W00t! W00t! W00t! W00t! W00t! W00t! flag.txt is accessible! THE END! Appendix ! EGGCODE.C – Used to loaded the shellconde into the env. /* eggcode.c */ #include <unistd.h> #define NOP 0x90 char shellcode[] = "\x31\xc0\x31\xdb\x31\xd2\x53\x68\x55\x6e\x69\x0a\x68\x64\x55" "\x55\x4d\x68\x41\x68\x6d\x61\x89\xe1\xb2\x0f\xb0\x04\xcd\x80" "\x31\xc0\x31\xdb\x31\xc9\xb0\x17\xcd\x80\x31\xc0\x50\x68\x6e" "\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x8d\x54\x24\x08\x50" "\x53\x8d\x0c\x24\xb0\x0b\xcd\x80\x31\xc0\xb0\x01\xcd\x80"; Pag. 10 int main(void) { char shell[512]; puts("Eggshell loaded into environment.\n"); memset(shell,NOP,512); /* fill-­‐up the buffer with NOP */ /* fill-­‐up the shellcode on the second half to the end of buffer */ memcpy(&shell[512-­‐strlen(shellcode)],shellcode,strlen(shellcode)); /* set the environment variable to */ /* EGG and shell as its value, rewrite if needed */ setenv("EGG", shell, 1); /* modify the variable */ putenv(shell); /* invoke the bash */ system("bash"); return 0; } ! FINDEGGADDR.C – Used to retrieved the memory address where the shellcode is point to /* findeggaddr.c */ #include <unistd.h> int main(void) { printf("EGG address: 0x%lx\n", getenv("EGG")); return 0; } Pag. 11