Latest Posts
2024-11-08 - Quack-quack - HID attacks with NetHunter
2024-11-06 - Flashing an OS image to your Android device
2024-09-17 - ChatGPT wrote a Rust program for me that generates an RSS feed from Markdown files
2024-09-16 - Navigating the Leap: My Journey from Software Engineering to Offensive Security
2024-08-21 - How to crash a Spacecraft – DoS through Vulnerability in NASA CryptoLib v1.3.0
2024-08-09 - Ground Control to Major Threat: Hacking the Space Link Extension Protocol
2024-07-17 - IDOR's in NCIA ANET v3.4.1
2024-05-21 - Remote Code Execution via Man-in-the-Middle (and more) in NASA's AIT-Core v2.5.2
2024-01-17 - Getting a Black Belt in Wi-Fu - OSWP Review
2024-01-16 - Exploiting the Apache Karaf Console
2024-01-12 - Exploitation of the OSGi console
2023-11-02 - XSS in NASAs Open MCT v3.0.2 - data exfiltration
2023-10-19 - My Journey to Finding My First 0day/CVE
2023-10-13 - Yamcs Vulnerability Assessment
2023-10-12 - Prototype Pollution in NASAs Open MCT CVE-2023-45282
2023-08-05 - How I Failed OSWA Exam
2023-07-23 - Mid-career Transition to Infosec 0x07
2023-03-19 - Mid-career Transition to Infosec 0x06
2023-01-16 - Mid-career Transition to Infosec 0x05
2023-01-12 - ADwalk: simple PowerShell script to enumate Active Directory
2022-12-20 - clif: simple command-line application fuzzer
2022-12-12 - nansi: simple tool for task automation
2022-09-01 - Mid-career Transition to Infosec 0x04
2022-08-10 - Mid-career Transition to Infosec 0x03
2022-04-27 - Mid-career Transition to Infosec 0x02
2022-03-10 - Mid-career Transition to Infosec 0x01
Latest Posts
2024-11-08 - Quack-quack - HID attacks with NetHunter
2024-11-06 - Flashing an OS image to your Android device
2024-09-17 - ChatGPT wrote a Rust program for me that generates an RSS feed from Markdown files
2024-09-16 - Navigating the Leap: My Journey from Software Engineering to Offensive Security
2024-08-21 - How to crash a Spacecraft – DoS through Vulnerability in NASA CryptoLib v1.3.0
2024-08-09 - Ground Control to Major Threat: Hacking the Space Link Extension Protocol
2024-07-17 - IDOR's in NCIA ANET v3.4.1
2024-05-21 - Remote Code Execution via Man-in-the-Middle (and more) in NASA's AIT-Core v2.5.2
2024-01-17 - Getting a Black Belt in Wi-Fu - OSWP Review
2024-01-16 - Exploiting the Apache Karaf Console
2024-01-12 - Exploitation of the OSGi console
2023-11-02 - XSS in NASAs Open MCT v3.0.2 - data exfiltration
2023-10-19 - My Journey to Finding My First 0day/CVE
2023-10-13 - Yamcs Vulnerability Assessment
2023-10-12 - Prototype Pollution in NASAs Open MCT CVE-2023-45282
2023-08-05 - How I Failed OSWA Exam
2023-07-23 - Mid-career Transition to Infosec 0x07
2023-03-19 - Mid-career Transition to Infosec 0x06
2023-01-16 - Mid-career Transition to Infosec 0x05
2023-01-12 - ADwalk: simple PowerShell script to enumate Active Directory
2022-12-20 - clif: simple command-line application fuzzer
2022-12-12 - nansi: simple tool for task automation
2022-09-01 - Mid-career Transition to Infosec 0x04
2022-08-10 - Mid-career Transition to Infosec 0x03
2022-04-27 - Mid-career Transition to Infosec 0x02
2022-03-10 - Mid-career Transition to Infosec 0x01
Security Articles
2024-11-08 - Quack-quack - HID attacks with NetHunter
2024-11-06 - Flashing an OS image to your Android device
2024-08-21 - How to crash a Spacecraft – DoS through Vulnerability in NASA CryptoLib v1.3.0
2024-08-09 - Ground Control to Major Threat: Hacking the Space Link Extension Protocol
2024-07-17 - IDOR's in NCIA ANET v3.4.1
2024-05-21 - Remote Code Execution via Man-in-the-Middle (and more) in NASA's AIT-Core v2.5.2
2024-01-16 - Exploiting the Apache Karaf Console
2024-01-12 - Exploitation of the OSGi console
2023-11-02 - XSS in NASAs Open MCT v3.0.2 - data exfiltration
2023-10-13 - Yamcs Vulnerability Assessment
2023-10-12 - Prototype Pollution in NASAs Open MCT CVE-2023-45282
Quack-quack - HID attacks with NetHunter
A few days ago, I decided to dive deeper into the Android ecosystem and its security aspects. I got a device that I wouldn’t mind breaking, rooted it, and was all set to begin my research. I was... but what did I end up doing instead? Naturally, I set up Kali NetHunter and started experimenting with it. Let me tell you, this thing is a lot of fun—especially features like HID attacks! I've been having so much fun with it that I decided to record an example of how it works in practice. This is a simple example of a keystroke injection attack, where an adversary connects a phone to a victim’s PC, simulating an HID device and rapidly sending a series of keystrokes. Check out the video below.
Meanwhile, I do want to learn about Android security, so I’d better get to it!
Flashing an OS image to your Android device
Introduction
I've recently started learning about the Android ecosystem from an architecture and security perspective. One of the first steps I took was to buy an old, used phone that I could root easily. I chose the OnePlus 7T, which came with Android 12 installed. Interestingly, the last official software release for this model was on August 12, 2022, with Android 11. I’m not sure why mine has Android 12, but since I plan to experiment with the system extensively (and will likely break it multiple times), it’s important to set up a baseline that I can reliably restore. Given that the Android 11 image is the latest official release available on the OnePlus website, it will serve as my baseline.
Initially, I wasn’t sure how to set up this baseline. Although the process is relatively straightforward, being new to this and finding most of the information aimed at more experienced users, I struggled at first.
The goal of this blog post is to provide a step-by-step guide on installing Android on the OnePlus 7T, in case you need to recover your device during your own exploration of Android architecture and security. While I’ll use the OnePlus 7T, I’ll try to present the instructions in a way that can be adapted for other devices. The focus will be on understanding the steps and their purpose, rather than just following a checklist.
Here’s what I’ll cover in this article:
- Downloading the software image
- Enabling OEM unlock
- Rebooting to the bootloader
- Unlocking the bootloader
- Flashing the software image
Get the right software
Depending on your phone model, there’s a good chance the build will be available on the vendor's website. For OnePlus devices, you can find the builds here.
After downloading the build, we’ll need to extract the boot.img file. To do this, you’ll first need a tool called payload-dumper-go, which you can download from this link.
payload-dumper-go payload.bin
This will extract all files into a new folder in the current directory, including the boot.img. The extracted boot.img is the image we’ll be flashing.
This step may vary depending on your phone model. For example, with the Samsung S9, you can use an application called Frija instead. Once started, we need to provide information about the model, CSC, and IMEI. This will then allow us to download the correct firmware for a specific Samsung phone.
The downloaded zip will contain a list of files which we'll then use to flash our Samsung S9 phone.
Avoid running any of these tools (except for Android Platform Tools) on your main OS. Instead, run them in a virtual machine (VM), as I can’t guarantee their safety. As with any application downloaded from the internet, exercise caution.
Unlock OEM
Warning: This will erase all data on your phone.
To flash a new OS image onto a device, we first need to unlock the bootloader. Historically, this has been challenging, as OEM vendors use it as a security measure to prevent modifications like the ones we’re attempting. However, this has changed over time, and many vendors now provide an option to unlock the bootloader.
The first step is to go to Settings > About Phone and tap the Build Number field several times. Note that this process may vary depending on your phone model or Android version. Below are some example screenshots from the OnePlus 7T.
In my case, OEM Unlocking was already enabled, and the bootloader was unlocked, so the option appears grayed out.
While we’re here, let’s also enable USB debugging:
This may look slightly different on other Android phones, but the process should be quite similar.
Reboot to bootloader
Before flashing the image, we need to reboot into the bootloader. On OnePlus devices, this is called Fastboot Mode. We can do this using adb:
adb reboot bootloader
The commands should look like follows:
On the phone, you should see something like this:
Note that not all Android phones have Fastboot mode. For example, my Samsung S9 has something called Download Mode, where you can simply drag and drop files. The Download mode on Samsung should look like this:
Unlock the bootloader
Warning: This will erase all data on your phone.
Once in Fastboot mode, we can proceed to unlock the bootloader:
fastboot oem unlock
You should see a prompt on the phone screen with the option to lock or unlock the bootloader.
Once you confirm your choice, the bootloader unlock will proceed. The command should look like follows:
On the Samsung S9, to remove that check, you’ll first need to flash TWRP and then use RMM State Bypass Mesa.
When downloading TWRP, make sure you select the version that is compatible with your device. You can find relevant references at the end of this article.
Flash the software image
To flash the image, run the following command:
fastboot flash boot boot.img
The command should look like this:
For the Samsung S9, instead of using Fastboot, you'll need to use a tool called Odin to flash both TWRP (as described above) and the stock firmware. Below you can see how this will look like with Odin for Samsung S9. As already mentioned, you can find relevant references for Samsung S9/S9+ at the end of this article.
And that’s it! We’ve successfully flashed an Android OS onto our phone.
Conclusions
As we've seen throughout this article, installing an Android system on your device can vary depending on the phone model. However, the process generally follows these universal steps:
- Get the software image
- Unlock the OEM
- Reboot to the bootloader
- Unlock the bootloader
- Flash the software image
Now that we have a way to recover our system to its original state, let's go ahead and try to break it.
Resources
How to crash a Spacecraft – DoS through Vulnerability in NASA CryptoLib v1.3.0
My research team has uncovered critical out-of-bounds vulnerabilities in NASA's CryptoLib v1.3.0, which could lead to a Denial of Service (DoS) by crashing both spacecraft and ground station systems. We demonstrated this with a Proof-of-Concept exploit that successfully crashed the Core Flight System and COSMOS within NASA’s Operational Simulator for Small Satellites. Our analysis highlights the need for improved SPI validation in CryptoLib's functions to prevent such security breaches, and we recommend specific checks to mitigate these vulnerabilities.
This security research was originally published at VisionSpace Blog
Ground Control to Major Threat: Hacking the Space Link Extension Protocol
In my analysis, I highlight that while space missions often focus on direct communication and spacecraft access vulnerabilities, a more practical threat comes from exploiting Ground Segment flaws due to their complex and custom-made nature. I delve into the security concerns of the Space Link Extension (SLE) protocol, which is crucial for mission data and ground station communication, and show how malicious actors can leverage this to execute Denial of Service attacks or intercept communications. To address these issues, I propose a mitigation strategy for the SLE protocol and outline future research directions to enhance security in space missions.
This security research was originally published at VisionSpace Blog
IDOR's in NCIA ANET v3.4.1
In my article, I detail two critical IDOR (Insecure Direct Object Reference) vulnerabilities found in NCIA ANET v3.4.1: one allowing unauthorized access to draft reports through user-controlled keys and another leading to incorrect ownership assignment. The first issue lets any user view another’s draft report by manipulating the report ID in the URL, while the second issue enables users to change the ownership of reports by modifying UUIDs in GraphQL requests. To address these vulnerabilities, I recommend implementing server-side checks to ensure that draft reports are only visible to their authors and that ownership assignments are correctly validated.
This security research was originally published at VisionSpace Blog
Remote Code Execution via Man-in-the-Middle (and more) in NASA's AIT-Core v2.5.2
In my article, I outline several critical vulnerabilities discovered in NASA's AIT-Core v2.5.2, including SQL injection, local code execution through eval, Pickle, and YAML, and remote code execution via Man-in-the-Middle attacks. I detail how these flaws can potentially lead to severe security breaches, including command injection and unauthorized access, and demonstrate the risks through various examples and exploit scenarios. I also recommend specific mitigations such as using secure query-building methods, avoiding insecure libraries, and encrypting communications to prevent these vulnerabilities from being exploited.
This security research was originally published at VisionSpace Blog
Exploiting the Apache Karaf Console
In my recent assessment, I found that the Apache Karaf Web Management Console can be exploited if misconfigured, specifically in versions v4.4.3 and Apache Felix Framework v7.0.5. Common vulnerabilities include enabling external access, using default credentials, and lacking SSL encryption, which can lead to a reverse shell attack. To mitigate these risks, I recommend restricting console access, updating default credentials, and enabling SSL.
This security research was originally published at VisionSpace Blog
Exploitation of the OSGi console
I discovered that the OSGi Console, if misconfigured, can be exploited to achieve Remote Code Execution (RCE) across various versions from 3.7.2 to 3.18. The exploit involves gaining unauthorized access via telnet, running system commands, and potentially escalating privileges to compromise the entire system. To mitigate these risks, I recommend ensuring proper configuration, limiting network access, and considering isolation of the OSGi Console.
This security research was originally published at VisionSpace Blog
XSS in NASAs Open MCT v3.0.2 - data exfiltration
While reviewing NASA’s Open MCT v3.1.0, I identified two key vulnerabilities: stored Cross-Site Scripting (XSS) and a lack of Cross-Site Request Forgery (CSRF) protection. The XSS flaw is found in the flexibleLayout plugin, where user-controlled inputs can inject malicious code. Additionally, the absence of Content Security Policy (CSP) flags increases the exploitation risk. To further compound the issue, Open MCT is vulnerable to CSRF attacks, which can be chained with XSS to compromise sensitive data. I recommended sanitizing user inputs, implementing CSP, and adding CSRF protection.
This security research was originally published at VisionSpace Blog
Yamcs Vulnerability Assessment
After performing a vulnerability assessment of Yamcs v5.8.6, I discovered several security flaws. These include directory traversal issues, stored cross-site scripting (XSS), and insecure session cookie handling. With directory traversal, attackers could access and delete arbitrary files, while XSS vulnerabilities allowed the execution of malicious JavaScript, potentially compromising sensitive user data like session cookies. I reported these issues to the Yamcs team, and they promptly addressed them. I recommended securing server configurations and restricting JavaScript execution to mitigate future risks.
This security research was originally published at VisionSpace Blog
Prototype Pollution in NASAs Open MCT CVE-2023-45282
In the article, I discuss a prototype pollution vulnerability (CVE-2023-45282) found in NASA's Open MCT. This flaw in JavaScript allows attackers to alter object prototypes, potentially leading to serious outcomes like privilege escalation or remote code execution (RCE). I explain how the vulnerability occurs in the "Import from JSON" feature, which can crash the application or lead to more dangerous exploits. Fortunately, NASA responded quickly to fix the issue, but it highlights the importance of securing deep merge operations in JavaScript.
This security research was originally published at VisionSpace Blog
Personal (still infosec)
2024-09-17 - ChatGPT wrote a Rust program for me that generates an RSS feed from Markdown files
2024-09-16 - Navigating the Leap: My Journey from Software Engineering to Offensive Security
2024-01-17 - Getting a Black Belt in Wi-Fu - OSWP Review
2023-10-19 - My Journey to Finding My First 0day/CVE
2023-08-05 - How I Failed OSWA Exam
2023-01-12 - ADwalk: simple PowerShell script to enumate Active Directory
2022-12-20 - clif: simple command-line application fuzzer
2022-12-12 - nansi: simple tool for task automation
ChatGPT wrote a Rust program for me that generates an RSS feed from Markdown files
A number of people kept telling me to get an RSS feed for my blog. It's a pretty standard feature for any content management system, but of course, because I like Rust, I use mdBook instead. As much as I like it, it doesn't automatically generate an RSS feed. There are a couple of crates I could set up as a preprocessor for mdBook, but they either don't work or don't do what I want. But hey, didn't I just say I like Rust? Yes... I did. But no... I don't want to write an RSS feed generator based on the Markdown files. If I had my own junior software developer, I could just tell them to write it for me—but I don't, do I?
Actually... maybe I do. How about ChatGPT? Isn't this exactly what it's meant for? Without dwelling on it too much, I found myself writing the following prompt:
Create code in Rust that goes through all directories recursively and reads all *.md (markdown) files. Based on those files, it creates an RSS feed stored in rss.xml. The title, publication date, author, URL and description of the RSS items should be taken from the markdown files themselves, which are stored at the beginning of those files in the following manner:
---
title: <title as string>
pub_date: <time and date as string>
author: <author as string>
url: <URL>
description: <description as string>
---
Please make the code Rust idiomatic.
Along with a detailed explanation, I got the following code back from my junior dev:
use serde::Deserialize; use std::{fs, io, path::Path}; use walkdir::WalkDir; use rss::{ChannelBuilder, ItemBuilder, Channel}; use std::fs::File; #[derive(Debug, Deserialize)] struct FrontMatter { title: String, pub_date: String, author: String, url: String, description: String, } // Function to parse front matter from a markdown file fn parse_front_matter(content: &str) -> Option<FrontMatter> { let delimiter = "---"; let parts: Vec<&str> = content.splitn(3, delimiter).collect(); if parts.len() == 3 { serde_yaml::from_str(parts[1]).ok() } else { None } } // Function to process a markdown file and extract the RSS item information fn process_markdown_file(path: &Path) -> Option<rss::Item> { if let Ok(content) = fs::read_to_string(path) { if let Some(front_matter) = parse_front_matter(&content) { let item = ItemBuilder::default() .title(Some(front_matter.title)) .pub_date(Some(front_matter.pub_date)) .author(Some(front_matter.author)) .link(Some(front_matter.url)) .description(Some(front_matter.description)) .build(); return Some(item); } } None } // Function to traverse directories and process all markdown files fn collect_markdown_files(dir: &str) -> Vec<rss::Item> { let mut items = Vec::new(); for entry in WalkDir::new(dir).into_iter().filter_map(|e| e.ok()) { let path = entry.path(); if path.is_file() && path.extension().and_then(|s| s.to_str()) == Some("md") { if let Some(item) = process_markdown_file(path) { items.push(item); } } } items } fn main() -> io::Result<()> { // Define the directory to search for markdown files let directory = "./"; // Collect markdown files and generate RSS items let items = collect_markdown_files(directory); // Build the RSS feed let channel = ChannelBuilder::default() .title("My Markdown RSS Feed") .link("http://example.com") .description("RSS feed generated from markdown files") .items(items) .build(); // Write the RSS feed to an XML file let file = File::create("rss.xml")?; channel.pretty_write_to(file)?; Ok(()) }
It looks kinda okay, but does it work? Of course not.
I tried to build it, and it didn’t even compile—I'd expect the code from my junior dev to at least compile. But okay, let's try another prompt:
I'm getting this error:
91 | channel.pretty_write_to(file)?; | ^^^^^^^^^^^^^^^------ two arguments of type `u8` and `usize` are missing
My junior dev, not thinking too much, spat out a fix:
use std::io::Write; // Import Write trait for pretty_write_to fn main() -> io::Result<()> { // Define the directory to search for markdown files let directory = "./"; // Collect markdown files and generate RSS items let rss_items = collect_markdown_files(directory); // Build the RSS feed with sorted items let channel = ChannelBuilder::default() .title("My Markdown RSS Feed") .link("http://example.com") .description("RSS feed generated from markdown files") .items(rss_items.into_iter().map(|rss_item| rss_item.item).collect::<Vec<_>>()) .build(); // Write the RSS feed to an XML file with pretty formatting let mut file = File::create("rss.xml")?; // Set indentation settings (2 spaces per indent) channel.pretty_write_to(&mut file, b' ', 2)?; Ok(()) }
Okay, it fixed the mentioned error. Does it compile now? Nope... Another prompt:
now I'm getting this error:
Compiling mdrss v0.1.0 (/home/user/dev/mdrss) warning: unused import: `Channel` --> src/main.rs:3:11 | 3 | use rss::{Channel, ChannelBuilder, ItemBuilder}; | ^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: unused `Result` that must be used --> src/main.rs:91:5 | 91 | channel.pretty_write_to(&mut file, b' ', 2); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled = note: `#[warn(unused_must_use)]` on by default help: use `let _ = ...` to ignore the resulting value | 91 | let _ = channel.pretty_write_to(&mut file, b' ', 2); | +++++++ warning: `mdrss` (bin "mdrss") generated 2 warnings (run `cargo fix --bin "mdrss"` to apply 1 suggestion) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.75s
Say what you will, my junior dev doesn’t give up. Took the prompt and gave me the fix back:
use serde::Deserialize; use std::{fs, io, path::Path}; use walkdir::WalkDir; use rss::{ChannelBuilder, ItemBuilder}; use chrono::{DateTime, Utc}; use chrono::format::ParseError; use std::fs::File; use std::io::Write; // Struct to hold the parsed front matter #[derive(Debug, Deserialize)] struct FrontMatter { title: String, pub_date: String, author: String, url: String, description: String, } // Function to parse the publication date as a `DateTime<Utc>` fn parse_pub_date(date_str: &str) -> Result<DateTime<Utc>, ParseError> { // Assuming the date in the markdown files is in RFC3339 format (e.g., "2023-09-13T00:00:00Z") date_str.parse::<DateTime<Utc>>() } // Function to parse front matter from a markdown file fn parse_front_matter(content: &str) -> Option<FrontMatter> { let delimiter = "---"; let parts: Vec<&str> = content.splitn(3, delimiter).collect(); if parts.len() == 3 { serde_yaml::from_str(parts[1]).ok() } else { None } } // Struct to hold an RSS item along with its parsed publication date struct RssItem { pub_date: DateTime<Utc>, item: rss::Item, } // Function to process a markdown file and extract the RSS item information fn process_markdown_file(path: &Path) -> Option<RssItem> { if let Ok(content) = fs::read_to_string(path) { if let Some(front_matter) = parse_front_matter(&content) { if let Ok(pub_date) = parse_pub_date(&front_matter.pub_date) { let item = ItemBuilder::default() .title(Some(front_matter.title)) .pub_date(Some(front_matter.pub_date)) .author(Some(front_matter.author)) .link(Some(front_matter.url)) .description(Some(front_matter.description)) .build(); return Some(RssItem { pub_date, item }); } } } None } // Function to traverse directories and process all markdown files fn collect_markdown_files(dir: &str) -> Vec<RssItem> { let mut items = Vec::new(); for entry in WalkDir::new(dir).into_iter().filter_map(|e| e.ok()) { let path = entry.path(); if path.is_file() && path.extension().and_then(|s| s.to_str()) == Some("md") { if let Some(rss_item) = process_markdown_file(path) { items.push(rss_item); } } } // Sort items by publication date (descending) items.sort_by(|a, b| b.pub_date.cmp(&a.pub_date)); items } fn main() -> io::Result<()> { // Define the directory to search for markdown files let directory = "./"; // Collect markdown files and generate RSS items let rss_items = collect_markdown_files(directory); // Build the RSS feed with sorted items let channel = ChannelBuilder::default() .title("My Markdown RSS Feed") .link("http://example.com") .description("RSS feed generated from markdown files") .items(rss_items.into_iter().map(|rss_item| rss_item.item).collect::<Vec<_>>()) .build(); // Write the RSS feed to an XML file with pretty formatting let mut file = File::create("rss.xml")?; // Set indentation settings (2 spaces per indent) channel.pretty_write_to(&mut file, b' ', 2).map_err(|e| io::Error::new(io::ErrorKind::Other, e))?; Ok(()) }
Nice! That at least compiles! It even highlighted the key changes. After cleaning it up a bit and removing some unused imports, I built and tested the program with my mdBook content, and it properly generated the rss.xml file. Nice indeed. So, as with any junior dev, let’s push it a bit further. Here’s another prompt:
can you now make a change to the code so that the directory path is provided as a command line argument?
Again, along with some explanation, it proudly came back with the code:
use serde::Deserialize; use std::{fs, io, path::Path}; use walkdir::WalkDir; use rss::{ChannelBuilder, ItemBuilder}; use chrono::{DateTime, Utc}; use chrono::format::ParseError; use std::fs::File; use std::io::Write; use std::env; // To access command line arguments // Struct to hold the parsed front matter #[derive(Debug, Deserialize)] struct FrontMatter { title: String, pub_date: String, author: String, url: String, description: String, } // Function to parse the publication date as a `DateTime<Utc>` fn parse_pub_date(date_str: &str) -> Result<DateTime<Utc>, ParseError> { // Assuming the date in the markdown files is in RFC3339 format (e.g., "2023-09-13T00:00:00Z") date_str.parse::<DateTime<Utc>>() } // Function to parse front matter from a markdown file fn parse_front_matter(content: &str) -> Option<FrontMatter> { let delimiter = "---"; let parts: Vec<&str> = content.splitn(3, delimiter).collect(); if parts.len() == 3 { serde_yaml::from_str(parts[1]).ok() } else { None } } // Struct to hold an RSS item along with its parsed publication date struct RssItem { pub_date: DateTime<Utc>, item: rss::Item, } // Function to process a markdown file and extract the RSS item information fn process_markdown_file(path: &Path) -> Option<RssItem> { if let Ok(content) = fs::read_to_string(path) { if let Some(front_matter) = parse_front_matter(&content) { if let Ok(pub_date) = parse_pub_date(&front_matter.pub_date) { let item = ItemBuilder::default() .title(Some(front_matter.title)) .pub_date(Some(front_matter.pub_date)) .author(Some(front_matter.author)) .link(Some(front_matter.url)) .description(Some(front_matter.description)) .build(); return Some(RssItem { pub_date, item }); } } } None } // Function to traverse directories and process all markdown files fn collect_markdown_files(dir: &str) -> Vec<RssItem> { let mut items = Vec::new(); for entry in WalkDir::new(dir).into_iter().filter_map(|e| e.ok()) { let path = entry.path(); if path.is_file() && path.extension().and_then(|s| s.to_str()) == Some("md") { if let Some(rss_item) = process_markdown_file(path) { items.push(rss_item); } } } // Sort items by publication date (descending) items.sort_by(|a, b| b.pub_date.cmp(&a.pub_date)); items } fn main() -> io::Result<()> { // Get the directory path from the command line arguments let args: Vec<String> = env::args().collect(); let directory = if args.len() > 1 { &args[1] // Use the provided directory } else { "./" // Default to the current directory }; // Collect markdown files and generate RSS items let rss_items = collect_markdown_files(directory); // Build the RSS feed with sorted items let channel = ChannelBuilder::default() .title("My Markdown RSS Feed") .link("http://example.com") .description("RSS feed generated from markdown files") .items(rss_items.into_iter().map(|rss_item| rss_item.item).collect::<Vec<_>>()) .build(); // Write the RSS feed to an XML file with pretty formatting let mut file = File::create("rss.xml")?; // Set indentation settings (2 spaces per indent) channel.pretty_write_to(&mut file, b' ', 2).map_err(|e| io::Error::new(io::ErrorKind::Other, e))?; Ok(()) }
Well, what happened to the idiomatic Rust?
are there any more places in the code where you can be more idiomatic?
Okay, that’s a bit better:
use serde::Deserialize; use std::{fs, io, path::{Path, PathBuf}}; use walkdir::WalkDir; use rss::{ChannelBuilder, ItemBuilder}; use chrono::{DateTime, Utc}; use std::fs::File; use std::io::Write; use std::env; use std::ffi::OsString; // Struct to hold the parsed front matter #[derive(Debug, Deserialize)] struct FrontMatter { title: String, pub_date: String, author: String, url: String, description: String, } // Function to parse the publication date as a `DateTime<Utc>` fn parse_pub_date(date_str: &str) -> Result<DateTime<Utc>, chrono::format::ParseError> { date_str.parse::<DateTime<Utc>>() } // Function to parse front matter from a markdown file fn parse_front_matter(content: &str) -> Option<FrontMatter> { let delimiter = "---"; let parts: Vec<&str> = content.splitn(3, delimiter).collect(); if parts.len() == 3 { serde_yaml::from_str(parts[1]).ok() } else { None } } // Struct to hold an RSS item along with its parsed publication date struct RssItem { pub_date: DateTime<Utc>, item: rss::Item, } // Function to process a markdown file and extract the RSS item information fn process_markdown_file(path: &Path) -> Option<RssItem> { // Using `ok()` and `and_then()` to chain the logic more concisely fs::read_to_string(path).ok().and_then(|content| { parse_front_matter(&content).and_then(|front_matter| { parse_pub_date(&front_matter.pub_date).ok().map(|pub_date| { let item = ItemBuilder::default() .title(Some(front_matter.title)) .pub_date(Some(front_matter.pub_date)) .author(Some(front_matter.author)) .link(Some(front_matter.url)) .description(Some(front_matter.description)) .build(); RssItem { pub_date, item } }) }) }) } // Function to traverse directories and process all markdown files fn collect_markdown_files(dir: &Path) -> Vec<RssItem> { WalkDir::new(dir) .into_iter() .filter_map(|entry| entry.ok()) // Handle invalid directory entries .filter(|entry| { entry.path().is_file() && entry.path().extension().and_then(|s| s.to_str()) == Some("md") }) .filter_map(|entry| process_markdown_file(entry.path())) .collect::<Vec<_>>() // Collect all valid markdown files } // Main function to handle command line arguments and generate the RSS feed fn main() -> io::Result<()> { // Get the directory path from command line arguments, defaulting to current directory let directory: PathBuf = env::args_os().nth(1) .map(PathBuf::from) // Convert to PathBuf .unwrap_or_else(|| PathBuf::from("./")); // Collect markdown files and generate RSS items let mut rss_items = collect_markdown_files(&directory); // Sort items by publication date (descending) rss_items.sort_by(|a, b| b.pub_date.cmp(&a.pub_date)); // Build the RSS feed with sorted items let channel = ChannelBuilder::default() .title("My Markdown RSS Feed") .link("http://example.com") .description("RSS feed generated from markdown files") .items(rss_items.into_iter().map(|rss_item| rss_item.item).collect::<Vec<_>>()) .build(); // Write the RSS feed to an XML file with pretty formatting let mut file = File::create("rss.xml")?; channel.pretty_write_to(&mut file, b' ', 2) .map_err(|e| io::Error::new(io::ErrorKind::Other, e))?; Ok(()) }
But are we done? Of course not. I actually wanted this to be a Rust library so that I can use it as a pre-processor for mdBook.
Based on the last code you provided, make a Rust library with one API function. This function should take two parameters:
- path to the directory with markdown files
- destination path to the generated rss.xml file
This is where I actually got caught by surprise. Not only did it provide the code, but also unit and integration tests. Yes, you read that right. When was the last time you got a set of unit and integration tests from your dev (without even asking for them)?
I was very excited. Although the tests didn’t work, the attitude of my junior dev was commendable. Despite some exchanges with it, it wasn’t able to fix the tests it provided, which was a bit disappointing, but maybe that was my fault. I’m a junior prompt engineer, after all.
So, after cleaning it up a bit and making it actually work, the library was done.
But I wasn’t finished yet, so I made a few more requests. Here are the prompts:
Now, how can I use this library to automatically generate rss.xml file when generating my mdBook using Rust mdBook?
How can I publish my mdrss_lib library so that I can use it with cargo install or as part of dependencies in cargo.toml?
And if I wanted to publish my mdbook-rss-preprocessor so that people can download it and use it with cargo install?
for the mdrss_lib, please create a cli application that will take two cli arguments: - path do the directory with md files - path to rss.xml
Although I'm not going to paste them here, for all of those prompts, I received fairly decent answers, with code and explanations. If you're curious, here’s the link to the entire chat exchange.
However, I now have my RSS feed generator! Here are the results:
- mdrss - A library that handles RSS generation, which has even been published on crates.io.
- mdrss-cli - A CLI application that utilizes the library, which I now use for RSS generation based on my mdBook files.
Is it production code? Is it proper, idiomatic Rust? Did ChatGPT generate it with no errors? Although the problem that ChatGPT had to solve was trivial, the answer to these questions is resounding NO. However, it was good enough for me to make quick fixes and get the functionality I needed in a matter of minutes instead of hours (note that I'm not a Rust developer). An experienced Rust developers would do a much better job and probably faster, but let’s face it, I don’t have any working for me for free. I don't think ChatGPT is ready to replace a proper software engineer. But in this particular case, the sad reality is that, if not for ChatGPT, I still wouldn’t have an RSS feed on my blog—I'm just too lazy to develop it myself. So, although I never thought I’d say this, I finally found a reason to use ChatGPT for something that is coding-related.
Navigating the Leap: My Journey from Software Engineering to Offensive Security
I've recently transitioned to infosec, a journey I documented through blog posts over time. Now, I've had the opportunity to collaborate with OffSec to write a summary of this transition, which is finally up on their website. In the article, I share my experience moving from software engineering to offensive security, discussing the challenges, the effort required for upskilling and certifications like OSCP, and the importance of community engagement. Despite obstacles, I successfully landed an offensive security role, and the experience has been incredibly rewarding. Here's a link to the full article
Getting a Black Belt in Wi-Fu - OSWP Review
So, I started digging into various security aspects of Wi-Fi. Initially, Google was my go-to buddy, but then I thought a more organized approach would be cool. Since I still had the OffSec Unlimited Subscription back then, I decided to take a shot at the PEN-210.
PEN-210
I kicked off the PEN-210 with a pretty limited knowledge of anything wireless. As I went through the training material, I was shocked at how much I didn't know – from the nitty-gritty of IEEE 802.11 standards, network setups, frequencies, encryption, to various attack vectors and the whole arsenal of tools to conquer different Wi-Fi networks. There was a good amount of reading involved, and I'll admit, I've already forgotten half of those details. It's not the kind of stuff you use every day, so it doesn't exactly stick in your brain. But now, I'm aware of these things, and I can always look them up in my notes or ask our good friend Google.
Now, I know the OffSec training library like the back of my hand, and one thing that caught me off guard was the absence of a PEN-210 lab. Instead, they recommend which Access Point and wireless card you should grab. At first, it seems like a major hurdle. If you want to dive into the exercises, you've got to get the hardware first. But when it came to actually doing the exercises, setting up the lab environment yourself (with a real Access Point and configuring it) turned out to be a pretty cool learning experience. I learned a ton, understood exactly what I was setting up, and why I was hacking it in that particular way.
Now, let's talk about the technical stuff – you know, the exciting part where you actually get to do things. You'll tackle exercises to practice wielding different tools, cracking authentication hashes, launching rogue access point attacks, going after WPS networks, WPA/WPA2 and WPA Enterprise networks, and even messing with captive portals. For a wireless newbie like me, it was a good bit of fun.
Exercise
I managed to run all the exercises in the training material using a LinkSys AC1200 router and an Alfa AWUS036NHA WLAN adapter. These aren't the exact makes and models you necessarily need, but they're surprisingly affordable and tick all the boxes for practicing for OSWP.
Since there's no lab ready-made for you, I strongly suggest putting in the effort to create your own setup, especially for the exercises in the key areas of the training. This way, you ensure that when the exam rolls around, it won't be the first time you're executing a specific attack.
Exam
Just like any other 200-level OffSec course, the OSWP exam is an open-book, proctored affair. But here's the kicker – unlike its course cousins, the OSWP exam only lasts for 3.5 hours. It throws three challenges at you (one is a must, the other two are your call), each involving cracking into different networks. Once you're in, the goal is to grab a flag from a server chillin' on another host connected to the same network.
To ace the exam, you've gotta nail the mandatory challenge and pick off one of the optional ones. Post-exam, you've got an extra 24 hours to wrap up and shoot over your pentest report, just like the drill with all the other OffSec courses.
Conclusion
Whenever I dive into a new training, my go-to move is to check out the syllabus and figure out if it's going to dish out some fresh skills. In this case, a whopping 95% of the content was totally new to me, making it totally worth my study time. But here's the thing – after chatting with some seasoned hackers, it turns out most of them already had this knowledge. I'm pretty sure they could breeze through the exam without breaking a sweat.
Right now, you can't snag the PEN-210 on its own – it only comes bundled with the Learn One subscription or some other training package. But still, unless you already feel like a Wi-Fu black belt, I'd strongly suggest giving the course pages a good read. The exam is like a bonus round to test all the cool stuff you've learned. While it's awesome to get an official badge, I get that many might skip it and focus their study time on the main course they got with Learn One.
Resources
My Journey to Finding My First 0day/CVE
I've dreamed of discovering a 0day vulnerability and getting a CVE assigned to it since I started my transition to Offensive Security. In my mind, being able to find previously unknown vulnerabilities was a way to validate my skills and abilities as a security researcher. Unfortunately, for the same exact reasons, I only started actively hunting for vulnerabilities a couple of months ago, after I changed my role, and security research is now part of my job. Almost two years passed between the time I added "finding a 0day" to my list of goals and the time I actually attempted to do it. But why? The short answer is: I didn't know that I could.
The concept of discovering a 0day vulnerability remained at the top of my goal list for so long that it became something of a holy grail for me, almost unattainable. I believed that I didn't know enough to even begin, and the idea of starting felt like a waste of time because I thought I wouldn't find anything anyway. It seemed more sensible to concentrate on studying and progressing in my transition to information security.
Initially, I felt pressured to learn quickly and formally establish myself as an information security professional before embarking on 0day hunting. However, as time passed, I relinquished that pressure and became accustomed to the idea that achieving this goal might or might not happen at some point down the road. The human mind is peculiar, and it can sometimes play tricks on you, as it did in this case, leading me to deceive myself.
Things began to change when I stumbled upon a very interesting article written by 0xBoku: Beginner's Guide to 0day/CVE AppSec Research. In this article, he described his journey and how he started hunting for 0days as part of his preparation for OSWE. By that time, I had already obtained the OSCP certification, was working towards OSWA, and had slowly begun to explore OSWE training materials. However, even as I started preparing for OSWE, I still didn't feel confident enough to venture out and search for 0days.
I started my new role almost four months ago, and for two of those months, I worked on various R&D projects in the field of offensive security. Around two months into the job, I was assigned a vulnerability assessment of a software product. At that point, I was well into my OSWE training and believed this was an excellent opportunity to put my skills to the test.
During the first couple of days of the assessment, I discovered my first 0day vulnerability in the NASA Mission Control System. It's been a few weeks now, and I've completed the assessment of NASA's system, finished reviewing another product, and currently have 8 confirmed CVEs with a few more awaiting publication.
You can probably imagine the excitement I felt after finding that first 0day. I had finally achieved a goal that had been at the top of my list for the last two years. It was indeed a significant accomplishment for me. However, now that the initial excitement has settled, I thought I'd take a moment to reflect on this journey and attempt to answer the most obvious question: What took it so long?
I've spent some time trying to retrace the steps I've taken over those two years and have summarized them into three main categories.
Lack of confidence
Some people refer to it as imposter syndrome, but I'm not a fan of the word "imposter." I believe it's important to recognize that how we feel about ourselves can influence whether we take action or not, but it doesn't necessarily reflect our ability to do something. In my case, I was convinced that I needed to reach a certain level of knowledge and experience before I could begin finding 0day in software products. It took me a very long time before I actually tried, and even then, I only did so because my boss requested it. A lack of confidence can be blinding, and despite looking at the signs indicating that I was ready, I still couldn't see it.
Apply what you've learned
One of the main reasons I decided to pursue OffSec training courses is the fact that they are highly technical and consistently require you to apply the knowledge you gain by studying the training material. I'm an advocate of this approach, and I found these courses very appealing and convenient because I could solely focus on OffSec's guidance without having to figure out how to apply the new knowledge to gain practical experience. However, for me personally, this comfort became a hindrance and led to procrastination in my 0day hunting efforts, without feeling too guilty about it. Don't get me wrong; if I had to choose again, I'd still opt for OffSec training every time. However, if I had to start over, I would be more mindful of the need to balance training with real-world application.
Hack what you know
There are many ways to get started; you can obtain software from sources like SourceCodester or GitHub and begin searching for vulnerabilities. However, I believe it would be more beneficial if you started with software that you already know or have used.
In my case, as I mentioned in my mid-career transition to infosec story, I had extensive software engineering experience in the space sector. This background was particularly helpful when I was tasked with assessing an existing Mission Control System. I had previously seen and even used this software, and I had no trouble setting it up. Since I was familiar with the space industry and the functions of the ground segment, I didn't need to spend time figuring out what the software did or how it worked. I can attribute the fact that I found my first vulnerability within a matter of hours to my prior knowledge of the software.
Of course, I consider myself fortunate because the software I'm referring to is developed by NASA and is used in various space missions and organizations. This system is an attractive target for research. You may not be as lucky, but don't worry; the key consideration when selecting a target is that the software has some user base.
That's it! I believe these are the main lessons I've learned from my incredibly long journey to finding my first 0day. If you're considering embarking on the path of 0day hunting, I hope you find this writeup helpful. I'm also interested in hearing about your experiences in this field, so please consider sharing them with me and others.
How I Failed OSWA Exam
After obtaining my OSCP certification, I considered a couple of options for my next certification. The main ones I had in mind were OSED and OSWE. However, although I was a little tired after completing the OSCP, I didn't want to take a break. Instead, I decided to relax a bit by going for something that would be easier to achieve. While browsing through the OffSec library for other 200-level courses, I came across OSWA, which seemed like a good opportunity to delve deeper into web penetration testing.
What is OSWA?
OSWA stands for Offensive Security Web Assessor, and it is a certification that validates the skills acquired during the WEB-200 course. The course focuses on Web Penetration Testing from a black-box testing perspective. It covers various vulnerability classes and provides insights into how they function from both an attacker and defender standpoint.
Training material and labs
Similar to other OffSec courses, WEB-200 includes training materials (PDFs and videos), interactive exercises that accompany each training module (where students can start a virtual machine, perform specific actions to obtain a flag, and submit it through the portal), and a set of lab machines. The interactive exercises are contextualized within the training material, while the lab machines are standalone systems with no hints about the vulnerabilities or attack vectors they expose. Each lab machine contains two flags: one displayed upon obtaining administrator-level access to the web application and the other in a proof.txt file hidden somewhere on the system. The lab environment simulates real-world web pentesting, combining challenging scenarios with CTF-like elements. The lab size keeps expanding over time, and OffSec introduces frequent small changes to enhance the course content. When I started working on WEB-200, there were 6 boxes, and by the time I finished it, there were already 8. So, by the time you read this, there might be more machines.
The exam
The OSWA exam is a standard 24-hour test with five standalone boxes to assess the candidate's skills. After completing the exam, participants have an additional 24 hours to prepare and submit the report. The exam machines are similar to those encountered in the lab, but with different vulnerabilities and exploitation techniques. The rules for obtaining the flags in the exam are the same as those in the lab environment, though they may change over time, so it's crucial to refer to the official Exam Guide pages for the latest information.
My experience with OSWA
Initially, I believed OSWA would be an easy and quick success, but I soon realized I had underestimated its difficulty. While I was already familiar with most web vulnerability classes and had some black-box web pentesting experience, the WEB-200 course introduced numerous variations and challenges I had never encountered before. The difficulty level was high, emphasizing not only technical skills but also the ability to think creatively. I approached the training with a similar strategy as I did for OSCP, starting with easy machines and seeking help from forums and the Discord community. However, I discovered that this approach was not suitable for OSWA due to the limited number of lab machines available. Asking for help too often deprived me of the opportunity to figure things out independently.
Unfortunately, I failed my first OSWA attempt, and upon returning to the lab, I realized that I had forgotten certain concepts because I relied too much on external help instead of solving challenges on my own. I paid the price during the exam. Nevertheless, I learned from this experience and scheduled a second attempt after a 3-week cooldown period (my subscription allows for a 2-week cooldown). During this time, I thoroughly reviewed all training materials and completed the lab again, this time without seeking any assistance, even tackling the new machines added later. Ultimately, I successfully passed the second attempt and can now officially call myself an Offensive Security Web Assessor. I firmly believe that if I had put more effort into solving all lab machines independently and not underestimated the course's difficulty initially, I could have passed on my first try. Lesson learned.
Now, I'm looking forward to moving on to WEB-300 and CRTO, both of which I need for work, and I'm incredibly excited about them!
ADwalk: simple PowerShell script to enumate Active Directory
One of the things that became apparent to me (which also came as a surprise) since I've started my journey with offensive security was that Windows systems and Active Directory are absolutely everywhere. Most of the systems you will ever get to hack as an offensive security professional are going to be on Windows.
Probably the best tool for AD enumeration out there is the PowerView, however, to start using it you need to first transfer it to the target machine, just to do some basic enumerations, which sometimes is not ideal and can be problematic. I've noticed that often instead, a pentester will write a small script in PowerShell to start a simple enumeration of AD, just to see if there's anything there worth the attention. I've started practicing this approach myself and I find it much quicker - once I'm on a target system with access to PowerShell, I can write a short code and run it on that system to get the basic detains about AD.
Having this in mind, I've created a small PowerShell tool, called adwalk, which allows me to do just that. The main purpose of it is to display all OUs (Organization Units) in the Active Directory you are currently connected to, but you can also supply a filter in case you're looking for something specific, like an SQL server. Here's how it works:
Here an example of how to use it:
PS C:\> .\adwalk -filter "serviceprincipalname=*sql*"
Here's a quick demo:
For more details, head to the GitHub repo.
clif: simple command-line application fuzzer
clif is a command-line application fuzzer, pretty much what a wfuzz or ffuf are for web. It was inspired by sudo vulnerability CVE-2021-3156 and the fact that, for some reasons, Google's alf-fuzz doesn't allow for unlimited argument or option specification. Since I try to practice my Rust whenever there's an opportunity to develop something that I actually might use, I decided to create my own fuzzer.
Here are a few examples of what it can do:
# throw wordlist.txt as input
clif -e my_program -w wordlist.txt
# throw wordlist.txt as -p argument
clif -e my_program -w wordlist.txt -a "-p FUZZ"
# throw numbers from range 100..100000000 as the first argument
clif -e my_program -n 100..100000000 -a "-n FUZZ"
# throw a string with length from range 10..100 as the first argument
clif -e my_program -s 10..100
For more details, head to the GitHub repo.
Here's a quick demo
nansi - simple tool for task automation
Since I've started getting into infosec, I have been using virtual machines for absolutely anything and everything. Sometimes that's because I want to have a clean setup, e.g. my Kali with some additional hacking tools; or maybe it's a Windows system on which I want to test my exploit and also needs to be pre-configured. It also happens that I simply have no other choice and have to spin up a new system, like in case of the Bug Bounty programs, which made me experience first hand the ISP response to some strange network traffic - just by blocking it.
Setting up a new VM quickly became a very boring and repetitive task, and so I decided that I need to automate this process. Here's what I need: simple command runner, quick and easy. I've tried automating the process with bash first but soon realized that with the level of control I want those commands to run, bash is not going to be the best choice. The next thing that crossed my mind was to set up Ansible, since I remember using it at some point in the past, but the moment I started setting it up I realized that this thing blew into an immense giant and using it for what I need is an overkill (not to mention the huge waste of time).
All this led me to take a step back and think what exactly do I need:
- simple command runner
- OS independent
- possibility of defining dependencies between those commands (i.e., if command D depends on command B and command B fails its execution, command D won't execute)
After a few minutes of googling and not finding anything half decent, I decided to quickly make my own. I called it nansi as 'not ansible'. It took me a few hours of figuring some things out and actually codding it. It was also a great opportunity to practice my Rust :)
Now to get me started with a new VM or a Bug Bounty target, I just need to spin up a Kali or Ubuntu on my favorite VPS provider and run one command to install all my hacking tools.
Here's a short description:
nansi is a simple tool for task automation. Its primary functionality is to execute a sequence of commands in a defined order. It was inspired by what Dockerfile is and what ansible is not.
Here's also a link to GitHub repo.
Mid-career Transition to Infosec
2023-07-23 - Mid-career Transition to Infosec 0x07
2023-03-19 - Mid-career Transition to Infosec 0x06
2023-01-16 - Mid-career Transition to Infosec 0x05
2022-09-01 - Mid-career Transition to Infosec 0x04
2022-08-10 - Mid-career Transition to Infosec 0x03
2022-04-27 - Mid-career Transition to Infosec 0x02
2022-03-10 - Mid-career Transition to Infosec 0x01
Mid-career Traisition to Infosec #0x07
In March 2022, I released the first part of this blog series. Today, 15 months and 7 posts later, I write to share the exciting news that I have recently embarked on a new chapter as a Cyber Security Engineer. In my new role, I will be focusing on offensive security and engaging in a variety of impactful activities, including red teaming, adversary simulations, and security research.
You're probably wondering now, how did it happen? Have I finished the transition and completed all the training? Have I been applying to different jobs and eventually got one? None of that has happened yet - my training is far from done, and I haven't started applying to infosec jobs. So, how did it all come about?
As I mentioned in part 005 of this series, at some point, I decided to go out and share the news about what I was up to, my goals, and the steps I was taking to achieve them. This is when I also decided to publish this blog series, talk to friends, people I worked with at that time (and those I used to work with in the past), and even my (now former) employer. I was very open and honest about my aspirations, and I would share them with anyone who would listen. Surprisingly, as soon as I started sharing my desire to move into infosec, I began receiving some job offers, and eventually, I decided to go for the one that I thought was the most suitable for me.
Of course, this would not have been possible without hard work and dedication. As you know, my approach was to obtain the most difficult certifications available, as they would prove that I'm ready for the job. However, if I had kept my goals and aspirations just to myself, I would still be stuck in my old job.
Is the transition finished?
Well, I could say that my transition is finished since I've moved into infosec. But let's be honest, I've just entered a field that focuses on life-long learning. Whatever you know today is never enough, and with new technology emerging every day, there is a constant need to hack/secure it as well.
What's next?
I'm starting the new role, so this will be my main focus, especially since I want to gain as much experience as possible, as soon as possible. I'm still going through the OffSec trainings. I aspire to become OSCE3 (by obtaining OSEP, OSWE, and OSED), so this is what I will focus on in my personal time. Although in one of my previous posts I hinted that I was starting to train for OSED, in the end, I decided to further enhance my web penetration testing skills and went for OSWA. I recently passed the exam, but I will write about it in another post. Currently, I'm preparing for OSWE.
What will happen to this blog?
I want to take this blog series and summarize it in one coherent blog post. I would like to collect all the most important bits and pieces and write some sort of guide about how to transition to infosec. Throughout my journey, I've met many people trying to get into the industry, and quite a few of them are doing this mid-career too, so I think they might find this useful. Additionally, I will continue writing here, and while these will be standalone posts, they will focus on offensive security-related subjects.
If you are still reading this, thank you for staying with me throughout this journey. Your support means a lot to me. And if you also go through a similar journey of your own, don't be afraid to reach out to me or others in the field - most of us are a friendly bunch!
Mid-career Traisition to Infosec #0x06
I got my OSCP! :)
If you have read any of my previous posts, you know that it's been a long road, but after more than a year of training and preparation, I finally manned up to schedule the exam for the 11th of March 2023. Thanks to the Internet, I had no idea what to expect - some people say it is extremely difficult and fail, some say it is super easy and pass it in 8h. It is very subjective, depending on your experience and luck. For me, it was somewhat difficult. I haven't pwned all the machines but had enough to feel confident that I passed and finished it a few hours before the deadline. I didn't have bonus points. I don't believe in bonuses, so I didn't prepare or submit the lab report. I decided to focus on learning and applying the content instead. This doesn't mean I didn't do the exercises, though. I did all of them (which was part of my learning and applying), just didn't bother to prepare the report.
Going to the exam, I remembered what most of the OffSec student mentors were saying: the exam should not take the whole 24h. You should take your time for all the other things you normally do during the day. If you struggle with this schedule, it means that you probably need more practice. Following this advice, I decided to take it easy and, instead of thinking "I have to pass", I thought "let's see if I'm good enough, or if I need more practice".
The exam started at 5:00 am (there were no normal hours available...) so obviously, I didn't get enough sleep before jumping in. It didn't matter though, because throughout those 23:45 hours of hacking, more than half of it I spent on naps, preparing the food and eating, and of course, a few nice walks with my dog. Don't get me wrong, it was both physically and mentally exhausting, and again, to me personally it wasn't easy at all. But, having the right mindset and taking care of myself helped.
What's next on my upskill plan? Since I have the Learn Unlimited subscription at OffSec (thanks to my current employer), I will go for another training. As per my previous posts, I will try to focus on security research, so I will start with EXP-301. That being said, I also got Red Team Operator training and I think that it's going to be an interesting and very useful experience (not to mention another badge on my CV).
Mid-career Traisition to Infosec #0x05
Progress Report.
Over the last couple of months, I've been going through the Offensive Security Labs and HackTheBox, and I think I'm doing pretty ok. I don't have too much trouble with the easy and medium ones. Of course, there are those exceptions where a box is marked as easy, and you just have no idea how to approach it, but again, these are exceptions. So, I finally got the courage to schedule the OSCP exam. The exam is scheduled now for March 11th. I was trying to book it as soon as possible, but there were no free slots for the weekends, which was a prerequisite for me. That's ok, there are still plenty of boxes I can go through on HTB or OffSec labs to practice, but I've super excited and can't wait for the challenge day!
There's one more thing I wanted to mention, in the context of the transition to infosec. I've recently had an opportunity to meet and chat with Ted Harrington (the guy who wrote Hackable), and he suggested something important. He said that the moment I'm sure about what I want to do, I should go out and start talking about it publicly, let people know what I'm up to and how much I want it. I started writing this blog series almost a year ago but never published it, I was waiting for the transition to be complete. Ted is the one who encouraged me to make it public immediately. He said that this way I'm letting people know that I'm serious about it and am open to new opportunities. I was skeptical about it at first, after all, I wasn't feeling strong enough to start applying for new opportunities, but I did it. I also started showing my interest on LinkedIn a little bit more, posting some posts about my tools and whatnot. I immediately noticed the interest of people, which I wouldn't even think of in this context, which was quite encouraging to stay on track and keep pushing through my upskill plan. A couple of months after when I started being more active, I suddenly started getting some job offers in infosec! Unfortunately, all of them were more on the defensive side, and since I'm interested in offensive security, I did take up any of them. But just the fact that a guy like me, with no real-world experience in the sector, is getting infosec job offers - I was shocked but it also encouraged me even more to continue. There's a shortage of infosec talent out there, but for people like me, it's good news.
Ted's advice was so simple but so powerful that I have to pass it on. If you also try to get to infosec, don't wait for your story to be successful. Go out with anything you've got now, and build upon it. Tell people what you're up to and how you plan to achieve it. There's a high chance that someone who reads it will either get inspired by what you do or even decide to help you in achieving your goal.
Mid-career Traisition to Infosec #0x04
Progress Report.
My OSCP journey takes definitely longer than I anticipated, and due to other obligations, I didn't manage to complete it within the Learn One time frame. That being said, I had extended the lab time and and now I'm going through the remaining boxes (so far I've gone through around half of them). Not planning to extend it further and attempt the exam soon after the access ends.
Throughout the last couple of months I've made significant progress in my upskill plan, not only because of the OSCP prep work but in general in the context of infosec. Improving my sysadmin (both Linux and Windows) and network skills was very helpful. Getting into PEN-200 I thought I had all the basics covered, but the reality is that I didn't know how much I don't know. All that dump of knowledge, which with practice I converted into an actual skill, significantly boosted my confidence.
Also made progress in the plan itself. Since I finally decided to go for a combination of Security Research and pantesting (or even Red Team Operations), I've signed up for the EXP-301 Learn One. Haven't started it yet because I'm still hacking the offsec lab, but I had a quick look at the content and I absolutely love it. It is gonna be an immense effort for me (I know very little technically about this subject) and so I've decided to quickly finish the OSCP and then fully focus on OSED.
I also have an update on the roles I listed in part #002 and described a little in part #003. I've recently read an interesting book, Hackable by Ted Harrington, where he explains the difference between pentesting, vulnerability scanning and vulnerability assessment. From this source I gathered that the purpose of Pentest is to find out if you can compromise the system (find a way in, escalate privileges, pivot to other machines in the network, etc. – everything they teach us on PEN-200). Vulnerability assessment is the activity of taking a product or service (that a company offers) and trying to find a vulnerability in it, usually by white-box testing. Vulnerability scanning is a brief scan of a network and services to see if you can find something that is affected by known vulnerabilities.
It is now clearer to me that Pentest/Vulnerability Assessment are what interest me (apart from the Security Research). However, it is now two people who work in infosec (which I know personally) and have experience with pentesting, said to me that although by definition Pentesting is very interesting, in reality (or what the companies implement) it can be very boring and daunting activity. Based on the definitions of Pentesting and Vulnerability Assessment I've described in one of the previous posts, practical Pentesting is more like a Vulnerabilities Assessment in respect to the number of details you have to pay attention to and report about, but without getting into too much depth when it comes to looking for vulnerabilities in a custom software. What does this mean in practice? As a pentester you probably go through all services and report your findings, even if they don't lead to getting root access. On the other hand, if there's a custom application running there (like a company's product) and you don't find any obvious issues with it (usually by back-box testing), you move on. This unfortunately sounds to me like a typical vulnerability scan and not a proper pentest, and although it wouldn't be wise to generalize it in this context, it is definitely something to watch out for before getting into Pentesting professionally.
Now back to PEN-200 lab, still a few boxes to get through!
Mid-career Traisition to Infosec #0x03
It's been a couple of months since I've written the last post here. At this point, I'm well into the second half of my yearly PEN-200 subscription. As I've been progressing, I've also been trying to pay attention to the points I listed at the end of the previous post. It was an intense couple of months of going through the training material and hacking the PEN-200 lab boxes, and I've also had the opportunity to learn and try different areas of the offensive security, which means I think I can answer some of those questions now.
1. What different areas of offensive security are out there
Based on what I've learned so far, I wasn't that much off when I listed the offensive security areas in my previous post. But I realized a few very important things which I'll discuss below:
Pentesting is very broad, but it can be divided into many different areas of testing: web, application, system (things like Linux or Windows administration, e.g. Active Directory), IoT, network, physical, people, and probably more. I believe that working as a pentester, you need to be well-rounded in many of these areas, but from what I see there's a split between testing the IT (web, network, etc.) and social (physical, people). Let's take an external pentest of a company, assuming that you have been given some initial info (e.g. website URL), you need to be able to find your way around the network and web to properly enumerate the target and hopefully get a foothold. Sometimes, however, you can't get through the web, but you see there are other services running on that host, so you enumerate those and find some exploits which you can use to get in. Imagine then that the exploit is just a PoC (proof of concept) and it is for a binary application that has a BOF (Buffer Overflow) vulnerability and is running on Windows, you need to be able to modify the exploit, so you need to know some binary exploitation (reverse engineering and exploit development) aspects. I could continue giving you examples for a while, but I think you get the point - pentesting could require from you to be familiar with one are of offensive security, but also all of them (and the latter is true in most of the cases).
All other areas are more of specializations (e.g. web pentesting, appsec, reverse engineering, etc.), which you can utilize in pentesting, or as standalone activities, e.g. if you are a security researcher with focus on finding 0-day vulnerabilities, you need to master the reverse engineering and some exploit development.
2. Which one of them do I like the most.
Since the split between different areas is not clear, and often they overlap with each other, also the answer to this question won't be clear. That being said, I've been having a great time going through the PEN-200 boxes, in some cases tearing them apart like there were small cans of tuna, in other cases spending days banging my head against the wall and not getting anywhere, but the later are the ones that teach me the most. However, I really got into binary exploitation and I absolutely love it.
3. What are the roles associated with that particular area.
I think the most adequate role associated to this area is Security Researcher. Basically, it is someone who is looking at the system and tries to find vulnerabilities in it. It sounds just like a pentester, you may be thinking, but it actually is not. The difference is that a pentester checks if it is possible to get into your system and by what means - e.g. they check if a given service is vulnerable to something or misconfigured, and if that's the case they try to exploit it. They test many services mostly in a black-box approach, and if they don't find anything, they move on. Security Researcher on the other hand is somewhat much more focused role. They pick one system, which doesn't even need to be currently in use by a customer, they look at the code (if it is a white-box type) or tear it apart (throw a bunch of weird input at it or reverse engineering it) and try to find vulnerabilities that could be exploited. In some cases, this leads to finding new vulnerabilities that aren't known, called 0-days. Every new vulnerability gets a new CVE number, which for you as a hacker is a type of trophy - what a way to build a portfolio! :)
4. What are the next steps in terms of upskilling in the area of my choice.
At this stage of my upskilling, I think I will start leaning towards a Security Researcher role. I very much like the overall idea of researching new vulnerabilities in some software and, what's also very important, I'm a software guy so should have no problem finding my way around the code. There are many different types of security research I could focus on, though, even within the software itself. For instance, I could focus on web, but also go more for binary applications. Based on what I have gotten to try so far, mainly due to my OSCP training, I can tell you that I really got into binary exploitation. There's something very appealing to me in finding a crash in an application, whether it is on Linux or Windows, which then leads to binary exploitation, e.g. exploiting the buffer overflow. So far I've had a blast attaching a debugger to that thing and going through the assembly instructions one by one figuring out what the developer wanted to do and how I can abuse it. The only trouble with that is my very limited knowledge and lack of any experience in this area. I know it's software, but I really have idea about many other aspects, e.g. reverse engineering. That being said, I've had tried enough of it to know that I want to go in this direction. I've decided to proceed with this in the same way as I did when figuring out how to start with offensive security: done some research about it and, since I want to get my feet wet as soon as possible and start practicing, I think the best approach for me is to signup for EXP-301 and get OSED (Offensive Security Exploit Development) certificate.
5. What other areas are relevant, which it is worth to explore in this context.
Reviewing EXP-301 made me realize that going for it not only will help me develop my skills towards security research and reverse engineering, but also get some foundation in the area of exploit development.
Knowing myself, I'm very much drown into the things that are difficult (and Security Research + Reverse Engineering + Exploit Development is one of those things) to the point that it clouds my judgment, and I'm no longer sure whether I like it because I like the process of doing it, or just because it's so damn hard and the reward is great. Nevertheless, I think I will strive to become a well-rounded pentester and specialize in reverse engineering and exploit development. Combining my old passion to software development with the new one to offensive security seems like a done deal, no need to look for more, I'm hooked!
Mid-career Traisition to Infosec #0x02
Every planning activity I like to start by taking a step back, trying to get the big picture, and defining in one sentence: what is that I want to achieve exactly. So, let's see.
"I want to shift my career from whatever I'm currently doing to something that is offensive security related."
That's at a pretty high level, but I think I could refine it a little by adding:
"Preferably, I would like this to be also related to software engineering since it's my background, and also I just happen to like it."
Ok, so that's more or less my goal. It is still high level, I know, but it's good enough for now.
Next, I will try to recap where I stand in achieving this goal. As I already mentioned, my background is in software engineering, so I'm not exactly an IT beginner. But what does that mean exactly? Again, let's try to refine it a little.
I'm a software engineer with 15 years of experience, 5 of which I spent on actual coding (mainly in C++ and Java) and the remaining 10 years working as a TPM. It is also worth noting that I spent the last few years running the same project using the same development stack. Although these were multiple projects, the software and most of its functionality are identical. So, although I picked up some software engineering, project management, and leadership skills, I'm not up to date with the latest tech. Of course, it's not like I was doing nothing all those years. Over time I picked up many different programming languages and frameworks, but it was primarily out of curiosity and by no means I'm an expert or even proficient enough in any of them.
Knowing more or less what I want and having a clear idea of where I'm currently at in terms of skills that could help in achieving my goal, let's try to narrow down the roles (or areas) of the offensive security which I could focus on. At this point, it would be helpful to have two lists, one in order of things that I like the most and the other by the least effort I think I would have to make to get good at (knowing my strengths and weaknesses).
Things I think I'd like to do:
1. Pentesting
1. Red Teaming
1. Exploit Development
1. Reverse Engineering
1. Security Researching
1. Application Security
I didn't get the numbering wrong; it is all exciting. Also, if you try to read the definitions or job descriptions of some of those roles/areas, they are super confusing; they often overlap with each other or, in many cases, at least complement one another - difficult to decide which one I like the most. For instance, regarding the difference between Pentesting and Red Teaming, I dare you to get a single, concise description from more than two people. The same goes for Security Researching and Reverse Engineering.
Not a good start, but let's continue. Let's now try to map this list to my skills and experience, and see if I can get a more precise outcome.
Things I think I'd learn quickly:
1. Pentesting
I think I'm a well-rounded IT professional, knowing some sysadmin stuff, networking, scripting, and software development.
2. Application security
since I have decent software engineering experience, I think I would "only" need to pick up some infosec practices.
3. Exploit Development
although different from AppSec, I think I could do a decent job developing something - I like and know how to code after all. I would "only" need to pick up the other bits and pieces (e.g., reverse engineering and deep dive into OS/kernel internals).
4. Reversing Engineering
I don't think anyone is doing just that, so I'd combine it with Exploit Development (of course, I could be completely wrong).
5. Security Researching
well, I'd need to be good in all of the above, wouldn't I?
6. Red Teaming
just the fact that no two people can give me a concise definition means that either I'm asking the wrong people, or it is another role that requires knowledge and experience in all of the above.
Writing those two lists down already made me realize how little I know about this field. Also, I'm almost 100% sure there are many more areas and roles in offensive security which I don't know about, yet. It brings me to only one conclusion, if I'm serious about all this, I won't be able to do it on my own. I need to get some guidance and a decent education. Time to split the plan into two: upskill and transition. Let's start with the upskill plan.
Upskill Plan
How do I get up to speed with all offsec-related stuff? Quick Google search, and I see a few things:
- Almost no one is considering getting a degree unless it is someone 17 years old who wants to get a degree anyway (and even then, people recommend them to get a regular CS degree and pivot later to infosec)
- Certs in infosec are huge. I initially thought it was because maybe it was just cool to have them. But diving deeper into the subject, infosec is one of few disciplines where certifications are also significant for employers. I know what you're thinking: these are for the defensive side of infosec. I remember thinking that, but I could not be more wrong.
So, it looks like the certs are very important. In fact, in the offensive security field they are sometimes more critical than a relevant degree.
In the future, I will dive deep to understand why, and I think I have an answer (it will be in another post), but for now, let's go back to building the upskill plan.
Certification
There are many to choose from, but doing some research, you can divide them into a couple of categories:
- easy, entry-level (e.g., eJPT or CEH)
- advanced (e.g. eCPPT)
- industry-standard, shiny "bling bling" - the stuff that people make a tattoo of on their back (e.g., OSCP) That tattoo thing is a joke, of course (or is it?), but you get the point.
Before I continue, a few words of caution. First, there are many more certification options, but you should probably google them and see what's best for you. Second, whatever I write next is subjective and applies to my situation only. I'm not saying that my approach was the best, what I'm saying is that it was the best for me. I will describe my thought process while choosing my first cert, and I hope it will help you make your own decision, too.
At this point, I'm still focused on learning as much as possible, not on what certifications to put on my CV. So, as you can imagine, I initially thought of signing up for the easiest one and climbing my way up to get the holy grail - OSCP. However, while I was researching about it, I noticed that all those certification bodies also offer very comprehensive study and training plans. It led me to shift my approach by 180°, and instead of looking at the certs in the order from the easiest, I turned the list upside down and started with the most extensive and difficult one. My only guideline was the list of prerequisites a student should meet before signing up.
So, since I knew I could afford it and met all prerequisites, I decided to go for OSCP. Of course, I had to make a leap of faith that the requirements were accurate and that the training materials were good enough to prepare and guide me from 0 to hero, but that was it. Next thing I know, I'm a Learn One subscriber at Offensive Security - OSCP baby! Although I signed up for it before deciding to shift to offensive security, I would do the same if I had to do it again.
I also hope that this training will give me an overall idea about what other offsec areas are out there and where to go next in terms of further education/certification. Ideally, it will enable me to kick off the transition phase by either slowly shifting internally within my organization, helping find a part-time internship, or even joining a Bug Bounty program.
To summarize, apart from all the research I've done on the subject, it looks like the actual first step I should make is to complete my OSCP, and I should also use this opportunity to answer the following questions as I go through it:
1. What different areas of offensive security are out there
2. Which one of them do I like the most
3. What are the roles associated with that particular area
4. What are the next steps in terms of upskilling in the area of my choice
5. What other relevant areas are worth exploring
That's pretty much the plan I have. Note that everything I discuss in this post is related to the upskill plan. The transition, however, is an entirely different story. I already know that it is not going to be easy and a change will have an impact on both my personal and professional life. So, I think that the best thing I can do is to look at it critically and approach it the same way as the upskill plan, hopefully with a little more knowledge about the industry. I will write about it in the future. For the time being, I'll focus on hacking the OSCP!
Mid-career Traisition to Infosec #0x01
If ten years ago you told me that in ten years I would be thinking of changing my career, I would say that you've no idea what you're talking about. After all, I've finally got into a place I've always dreamt of: a good and well-paid job in one of the world's top organizations in the space sector. Given that it took me a couple of years to get there, my mind was 100% set about it, and I was pretty sure I knew what I wanted to do until retirement.
Without getting into the details of why I decided to change (at least not at this time), I find myself writing this blog post ten years later. I think it is safe to say that the first lesson I've learned is to never say never.
But before I get into the subject of the 'mid-career transition to infosec' and tell you what my grand plan is, there are a couple of things I wanted to get out of the way.
First of all, a quick disclaimer - I haven't transitioned yet. In fact, it's been only a few months since I've decided and painted my new target, and only now I'm finally starting to have an idea (although still in an early draft) of what the transition plan will look like.
On the other hand, it's not like I'm starting just now. I'm halfway through my OSCP (which I will describe in future posts), and this post series (or at least the first couple of posts) is written partially based on the experience I have already gained.
Another thing I want to mention upfront is that I'm going to skip a few initial steps of this adventure. Those are: why did I choose infosec (offensive security in particular), what was my thought process there, what else was I considering, etc.; that's because it doesn't bring much to this conversation and, since it's a longer story to tell, I think it deserves a dedicated post.
Writing a blog is one of the steps on my transition plan and there are several reasons for that. For one, writing things down helps visualize them and I think that visualizing your goal is one of the most critical steps in achieving it. Second, it makes me go through my plan multiple times and forces me to think about whether it makes sense, what else I should think of doing, and what I should avoid doing. Future posts will summarize my progress in this endeavor, which should help me stay in check and give me yet another opportunity to review the next steps and the overall direction I'm going towards. I will approach it more like a diary where I can put my thoughts as I progress. I also don't think I will publish it immediately, but only once I make an actual progress, feel more confident that I can achieve my goals and see that what I do actually works.
So far in my journey I haven't encountered many people who have done what I'm trying to do, but that doesn't mean there are none. Although most of the stories you hear are about getting into infosec straight after university, I'm sure many people are trying (or would like) to switch their careers in their 30s or even later. If you are one of those folks, I hope this blog series will come in handy even if it doesn't provide a clear path through to reach your goal (everyone's way will look differently) - at least you know that you're not alone (and if you reach out, I will know I'm not alone either).
Lastly, one of the things I've learned about pentesting over the last few months is that there's this rule which says, "If you didn't write it down, it didn't happened." Maybe it works the other way, too: "if I write it down, it will happen."
Hey, I'm Andy and I'm an Information Security Professional with over 15 years in the space industry, working as a Software Engineer and Technical Project Manager. For the past few years, I have focused on offensive security, specializing in vulnerability research, exploit development, and red team operations. I hold OSCP, OSWA, and OSWP certifications, and have been credited with several CVEs.
This page is a collection of topics I've studied and practiced during my transition from software engineering to offensive security, including my notes from a variety of certifications (such as OSCP, OSWA, and OSWP).
The intention is to further expand this page and document new subjects as I gain more knowledge and experience in security areas.
As for the transition to the infosec, I've documented the whole journey on my personal blog - stop by and have a look.
My Infosec Trophies
Speaker
DEF CON 32, Aerospace Village, 2024
Security for Space Systems, ESA/ESTEC, 2024
Certificates
Offensive Security Certified Professional (OSCP)
Offensive Security Web Assessor (OSWA)
Offensive Security Wireless Professional (OSWP)
CVEs
CVE-2024-44912 (awaiting NVD analysis)
CVE-2024-44911 (awaiting NVD analysis)
CVE-2024-44910 (awaiting NVD analysis)
CVE-2024-38447 8.1 HIGH
CVE-2024-38446 (awaiting NVD analysis)
CVE-2024-35061 7.3 HIGH
CVE-2024-35060 7.5 HIGH
CVE-2024-35059 7.5 HIGH
CVE-2024-35058 7.5 HIGH
CVE-2024-35057 7.5 HIGH
CVE-2024-35056 9.8 CRITICAL
CVE-2023-47311 6.1 MEDIUM
CVE-2023-46471 5.4 MEDIUM
CVE-2023-46470 5.4 MEDIUM
CVE-2023-45885 5.4 MEDIUM
CVE-2023-45884 6.5 MEDIUM
CVE-2023-45282 7.5 HIGH
CVE-2023-45281 6.1 MEDIUM
CVE-2023-45280 5.4 MEDIUM
CVE-2023-45279 5.4 MEDIUM
CVE-2023-45278 9.1 CRITICAL
CVE-2023-45277 7.5 HIGH
CTFs
Tools I developped
clif
Simple command-line application fuzzer.
ADwalk
Simple PowerShell script to enumate Active Directory.
nansi
Simple tool for task automation.
fspell
CLI tool allowing for an easy browsing and searching of your favourite spells without leaving your terminal.
Other
Full list of repositories can be found on my GitHub.