Comments (5)
@Ifex370 can you give me more information about the error? Please provide me with the following information:
- Does the segmentation fault happen when the rootkit is active, or just during the normal execution of a program?
- I need info about your Linux version. Please execute
uname -a
andlsb_release -a
and paste the output.
from triplecross.
@Ifex370 can you give me more information about the error? Please provide me with the following information:
- Does the segmentation fault happen when the rootkit is active, or just during the normal execution of a program?
- I need info about your Linux version. Please execute
uname -a
andlsb_release -a
and paste the output.
1. Does the segmentation fault happen when the rootkit is active, or just during the normal execution of a program?
Yes, it happens when the rootkit is active, and by active I mean when I ran the deployer.sh script.
After modifying the deployer.sh
script. This is the image of me running it
Then, on a different terminal.
2. I need info about your Linux version. Please execute uname -a and lsb_release -a and paste the output.
My linux version is the same as the one specified in your project write up. Except the Kernel version where mine is slightly higher. (5.13.0-52)
from triplecross.
Alright so it seems that the GOT hijacking technique succeeds, but the shellcode faults while running before calling the malicious library. This can be because of multiple reasons.
Different glibc version
Firstly, you are using Ubuntu 21.10 (I tested 21.04) which may include a different glibc version. This may lead eBPF into detecting the GOT section wrongly. Please check your glibc version (ldd --version
) and I can tell you more information about this.
Different library path
Secondly, the shellcode is generated dynamically but, since it is a PoC, it is prepared to work under a specific environment. In particular, the shellcode calls the malicious library /home/osboxes/TFG/src/helpers/injection_lib.so, meaning that since yours is under /home/ubuntu/Desktop/TripleCross/src/helpers/injection_lib.so, you will need to modify the shellcode yourself (or store the malicious library under the same path as I did). Please check page 214 of the thesis document. In there, you will find the following:
That shellcode there loads the path of the library (/home/osboxes/TFG/src/helpers/injection_lib.so) to the heap so that it is called later. What you will have to do is modify the bytes that are getting loaded so that it corresponds to your library:
You would then load the bytes into the heap just as I did, with mov instructions, taking endianness into account. Taking the bytes I showed you in the screenshot before, the first instructions in your case should be the same as mine:
mov dword [rax], 0x6d6f682f
mov dword [rax+0x4], 0x736f2f65
And so on.
Then, you need to get the x86_64 assembly opcodes corresponding to these instructions, which I wrote as comments in the screenshot of the document I shared. In order to do this you can use your favorite method, I personally used nasmshell. Remember to set the 64 bits mode:
mov dword [rax], 0x6d6f682f
--> 0xC7002F686F6D
Once you have all the opcodes you must include them into the rootkit. You can find the shellcode at src/common/constants.h:
The highlighted part corresponds to the assembly code where we load the path of the library into the heap. That is the one you should be modifying in the end. If your shellcode for loading the library path is larger than the original, you have to modify the constant CODE_CAVE_SHELLCODE_ASSEMBLE_2_LEN accordingly.
from triplecross.
Alright so it seems that the GOT hijacking technique succeeds, but the shellcode faults while running before calling the malicious library. This can be because of multiple reasons.
Different glibc version
Firstly, you are using Ubuntu 21.10 (I tested 21.04) which may include a different glibc version. This may lead eBPF into detecting the GOT section wrongly. Please check your glibc version (
ldd --version
) and I can tell you more information about this.Different library path
Secondly, the shellcode is generated dynamically but, since it is a PoC, it is prepared to work under a specific environment. In particular, the shellcode calls the malicious library /home/osboxes/TFG/src/helpers/injection_lib.so, meaning that since yours is under /home/ubuntu/Desktop/TripleCross/src/helpers/injection_lib.so, you will need to modify the shellcode yourself (or store the malicious library under the same path as I did). Please check page 214 of the thesis document. In there, you will find the following:
That shellcode there loads the path of the library (/home/osboxes/TFG/src/helpers/injection_lib.so) to the heap so that it is called later. What you will have to do is modify the bytes that are getting loaded so that it corresponds to your library:
You would then load the bytes into the heap just as I did, with mov instructions, taking endianness into account. Taking the bytes I showed you in the screenshot before, the first instructions in your case should be the same as mine:
mov dword [rax], 0x6d6f682f
mov dword [rax+0x4], 0x736f2f65
And so on.Then, you need to get the x86_64 assembly opcodes corresponding to these instructions, which I wrote as comments in the screenshot of the document I shared. In order to do this you can use your favorite method, I personally used nasmshell. Remember to set the 64 bits mode:
mov dword [rax], 0x6d6f682f
--> 0xC7002F686F6DOnce you have all the opcodes you must include them into the rootkit. You can find the shellcode at src/common/constants.h:
The highlighted part corresponds to the assembly code where we load the path of the library into the heap. That is the one you should be modifying in the end. If your shellcode for loading the library path is larger than the original, you have to modify the constant CODE_CAVE_SHELLCODE_ASSEMBLE_2_LEN accordingly.
Different glibc version
Please check your glibc version (ldd --version) and I can tell you more information about this.
Different library path
I'm sorry Assembly might not be my first, second even fifth language so you will find me struggling a bit. From the endian topics from university, I knwo how you got this
mov dword [rax], 0x6d6f682f
I'm not particularly sure as to how you arrived at this second shell code
mov dword [rax+0x4], 0x736f2f65
and also generating the opcodes using nasm wasn't so good as well.
Bottomline is I will retry with the exact ubuntu version. I just want to see the exploit in action so I can can study the way the system responds to it, and that is where the work begins for me.
from triplecross.
Different glibc version
Please check your glibc version (ldd --version) and I can tell you more information about this.
Alright thanks, we used 2.33, which is fairly close, and by your output it seems that it is recognizing the GOT section, so it does not seem to be the problem here anyway. Still, for anyone reading this, if you seek to make the rootkit work with other glibc versions, you may have to check that the instruction opcodes at the glibc function to hijack are the same as in 2.33, or otherwise update them. You can see page 86 of the document how the function at glibc looks like:
If yours looks different, you may have to update the opcodes at function check_syscall_opcodes
at src/ebpf/include/bpf/injection.h
, which are used by the eBPF program to detect the function at glibc.
Different library path
I'm not particularly sure as to how you arrived at this second shell code
mov dword [rax+0x4], 0x736f2f65
Oops, sorry about that, you are right, it should have been mov dword [rax+0x4], 0x62752f65
. You got it then!
and also generating the opcodes using nasm wasn't so good as well.
That's why I mentioned the 64 bits mode, you can see that after setting it, it works:
Bottomline is I will retry with the exact ubuntu version. I just want to see the exploit in action so I can can study the way the system responds to it, and that is where the work begins for me.
Alright it may be faster, in case you just want a quick PoC, to use a Linux version with the following setup I wrote in the README:
DISTRIBUTION | KERNEL | GCC | CLANG | GLIBC | |
---|---|---|---|---|---|
VERSION | Ubuntu 21.04 | 5.11.0 | 10.3.0 | 12.0.0 | 2.33 |
If you download Ubuntu 21.04 instead of Ubuntu 21.10 it should come with those versions.
Then, create an user called "osboxes", storing the malicious library under a directory called /home/osboxes/TFG/src/helpers/lib_injection.so. Essentially, download the rootkit and check the directory name to "TFG" rather than "TripleCross".
I know this is not the best, we created this PoC to showcase a specific functionality under a strict set of conditions (specific glibc, a specific path, etc), so the library injection module does not currently work under all conditions or out-of-the-box (such as the backdoor).
I can update the module to make the library injection work under any arbitrary path, since that truly seems unnecessarily restrictive. I will leave this issue open and close it once it works under any library path.
from triplecross.
Related Issues (20)
- Final C2 version
- Update C2 V1 to work with complete protocol (shown in image sent by email)
- Update library for new hidden protocol with packet splitting
- TFG documentation writing
- Scanning and writing module at processes memory
- Use openssl to create secure channel connections
- Enhancement: try to hide used space from df and other userspace tools
- make all error~ HOT 12
- segmentation fault when execute_command and the stack overflow caused by parameters HOT 5
- TC program compilation __stack_chk_fail not supported HOT 4
- user/kit.c:395:40: error: ‘XDP_FLAGS_REPLACE’ undeclared (first use in this function) HOT 1
- Makefile 102row -lbpf? how do i install it HOT 3
- When run deploy.sh, i meet loadbpf: load bpf program failed: Permission denied.
- Cannot injector to victim with -c option HOT 5
- libssl.so.1.1: cannot open shared object file: No such file or directory
- make with libbpf 1.0.1: undefined reference to `bpf_get_link_xdp_id' HOT 1
- Permission Denied: classifier_egress not load HOT 10
- Verifier issue when running XDP module HOT 1
- error: unknown target triple 'bpf', please use -triple or -arch
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from triplecross.