This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification."
http://securitytube-training.com/online-courses/securitytube-linux-assembly-expert/
Student ID: SLAE64-1434
Target Operating System: 64 bit Linux (x86_64 GNU/Linux)
This blog post is part of Assignment 6: http://a41l4.blogspot.ca/2017/03/assignment-6.html
The Original Version: http://shell-storm.org/shellcode/files/shellcode-77.php
My Version:
GitHub Link: https://github.com/rtaylor777/nasm/blob/master/PolySetuidExecve1434.nasm
Published: https://www.exploit-db.com/exploits/41498/
Original Shellcode bytes = 49
My version:
Number of bytes = 31
Number of nulls = 0
PolySetuidExecve1434.nasm
The purpose of calling setuid(0) is, suppose that you have managed to inject this shellcode into an executable that is Set-UID root. If the /bin/sh link actually runs BASH, BASH has a security protection where it will automatically downgrade its privilege if it is executed in a Set-UID root context. Running setuid(0) first turns the current Set-UID process into a real root process. Then running BASH will retain root privileges.
The execve section looks a little different not only because the string to execute is moved but because the code to zero registers is different. Compare with my ExecveStack1434 version: http://a41l4.blogspot.ca/2017/01/execvestack1434.html
Overall this produces bytecode that would generate a different signature, and defeat signature based detection. Additionally since my shellcode size is 18 bytes smaller than the original, there should be no confusing this shellcode for that one.
Assuming you have the NASM assembler ( http://www.nasm.us/ ):
Assemble:
nasm -felf64 PolySetuidExecve1434.nasm -o PolySetuidExecve1434.o
Link:
ld PolySetuidExecve1434.o -o PolySetuidExecve1434
Execute:
./PolySetuidExecve1434
The PolySetuidExecve1434 shellcode.c
If you missed it from my previous blog posts the shellcode.c file is auto generated by my helper scripts. See: http://a41l4.blogspot.ca/2017/02/slae-helper-scripts.html
Sample of running the resulting shellcode executable:
Something to note with the original version of this shellcode, besides the fact that it is 18 bytes larger.
The author failed to set RAX to zero before he used the instruction:
mov $0x69,%al
The result is that if the RAX register is set to something larger than a byte when his shellcode starts, this shellcode fails the setuid(0) call silently and still successfully runs the execve call. This would probably be very confusing in a real usage situation. I verified the fault using GDB together with my usual process of setting the main registers to 0xffffffffffffffff as you see in the original.c file above.
If you wish to learn more about assembly language, I highly recommend the "SecurityTube Linux Assembly Expert course and certification."
http://securitytube-training.com/online-courses/securitytube-linux-assembly-expert/
http://securitytube-training.com/online-courses/securitytube-linux-assembly-expert/
Student ID: SLAE64-1434
Target Operating System: 64 bit Linux (x86_64 GNU/Linux)
This blog post is part of Assignment 6: http://a41l4.blogspot.ca/2017/03/assignment-6.html
The Original Version: http://shell-storm.org/shellcode/files/shellcode-77.php
My Version:
GitHub Link: https://github.com/rtaylor777/nasm/blob/master/PolySetuidExecve1434.nasm
Published: https://www.exploit-db.com/exploits/41498/
Original Shellcode bytes = 49
My version:
Number of bytes = 31
Number of nulls = 0
PolySetuidExecve1434.nasm
Intro
This shellcode when executed will first setuid(0) and then execute /bin/sh and provide you with a shell.The purpose of calling setuid(0) is, suppose that you have managed to inject this shellcode into an executable that is Set-UID root. If the /bin/sh link actually runs BASH, BASH has a security protection where it will automatically downgrade its privilege if it is executed in a Set-UID root context. Running setuid(0) first turns the current Set-UID process into a real root process. Then running BASH will retain root privileges.
Polymorphic
In order to confuse what is going on, the /bin//sh string is rotated left by 1 bit to hide what it is and loading this value into rbx happens in the setuid(0) section. Notice also that the null terminator for it was also pushed onto the stack within the setuid(0) section.The execve section looks a little different not only because the string to execute is moved but because the code to zero registers is different. Compare with my ExecveStack1434 version: http://a41l4.blogspot.ca/2017/01/execvestack1434.html
Overall this produces bytecode that would generate a different signature, and defeat signature based detection. Additionally since my shellcode size is 18 bytes smaller than the original, there should be no confusing this shellcode for that one.
Testing
Download: https://raw.githubusercontent.com/rtaylor777/nasm/master/PolySetuidExecve1434.nasmAssuming you have the NASM assembler ( http://www.nasm.us/ ):
Assemble:
nasm -felf64 PolySetuidExecve1434.nasm -o PolySetuidExecve1434.o
Link:
ld PolySetuidExecve1434.o -o PolySetuidExecve1434
Execute:
./PolySetuidExecve1434
The PolySetuidExecve1434 shellcode.c
If you missed it from my previous blog posts the shellcode.c file is auto generated by my helper scripts. See: http://a41l4.blogspot.ca/2017/02/slae-helper-scripts.html
Sample of running the resulting shellcode executable:
The Original
The Original Shellcode original.cSomething to note with the original version of this shellcode, besides the fact that it is 18 bytes larger.
The author failed to set RAX to zero before he used the instruction:
mov $0x69,%al
The result is that if the RAX register is set to something larger than a byte when his shellcode starts, this shellcode fails the setuid(0) call silently and still successfully runs the execve call. This would probably be very confusing in a real usage situation. I verified the fault using GDB together with my usual process of setting the main registers to 0xffffffffffffffff as you see in the original.c file above.
Summary
The PolySetuidExecve1434 shellcode first calls setuid(0) to switch from a Set-UID process into a real root process and then calls /bin/sh. Additionally this version is polymorphic in that it is a bit more confusing to follow the code and it is very different bytecode than the original so it would not be in a signature database of a malware detection software. This version is also 18 bytes smaller than the original.If you wish to learn more about assembly language, I highly recommend the "SecurityTube Linux Assembly Expert course and certification."
http://securitytube-training.com/online-courses/securitytube-linux-assembly-expert/
Comments
Post a Comment