MPTCP Roams Free (By Default!) – OS X Yosemite

Further to the BlackHat USA Work by Patrick Thomas (@coffeetocode) and I (@secvalve).

MPTCP is enabled by default in Mac OS X Yosemite. So we can expect to see Multipath TCP on most networks, and on a total of tens to hundreds of millions of devices.

Embedded image permalink

Thanks to Ilias Marinos (@marinosi) who tripped my twitter search bot 

More to come…. We have stuff as yet unreleased that has suddenly become VERY relevant.

Shellshock bug exposes web servers, home routers

With Shellshock, the recently discovered vulnerability in Bash yet to hit full stride in exploitation, there are numerous systems and devices that are immediately at significant risk of exploitation across the Internet.  Neohapsis Labs has released advance Shellshock guidance to our clients, including immediate considerations, and short and medium term remediation steps to mitigate the impact of the vulnerability. What follows is a guest post by industry acclaimed journalist Byron Acohido on the immediate impact of this vulnerability:

Shellshock bug exposes web servers, home routers

By Byron Acohido

Yes, you should be very concerned about Shellshock, the latest software bug to arise with the potential to degrade the overall safety of the Internet by several notches.

Shellshock, also referred to as Bash, is a glaring weakness in an otherwise innocuous bit of coding that’s been around since 1987. Bash, shorthand for Bourne-Again Shell, is a program that allows you to type commands on computing devices that use the Unix, Linux, Apple Mac and Android operating systems. You’ve encountered  Bash if you’ve ever typed text commands on the black screen sitting behind the graphical interface of your computing device.

The existence of the Shellshock flaw was made public on Tuesday, riveting the attention of the global security community. It’s almost certain elite hacking groups have been aware of the vulnerability for some time prior, and have been taking advantage.

And now the rest of the cyber underground can make hay. The mad scramble is on. Much as they did earlier this year upon disclosure of the Heartbleed bug, companies of all sizes must identify and patch systems exposed to the Shellshock flaw.

“It’s at least equal to Heartbleed for sure,” says Garve Hays, software architect at NetIQ. “Heartbleed was ephemeral, you could gather personal data and move on. But with Shellshock, you can plant a backdoor on a server and stay there for years. It’s the gift that keeps on giving.”

Apache servers targeted

White hat researchers have begun probes to find vulnerable systems. The biggest, most obvious targets are Apache web servers. These Linux-based machines are used to run about one-third of the websites on the Internet.

“System administrators will be working long shifts to go through every single server, router and other piece of equipment that uses the bash shell,” says Jerome Segura, senior security researcher atMalwarebytes Labs.

Big enterprises have the resources and motivation to expedite patching. But hundreds of thousands of small and medium sized businesses will be slow to patch, or never patch at all. In the meantime, every hacker from script kiddies to spammers to account hijackers can now do simple reconnaissance to find and infect unpatched Apache web servers and related networking equipment.

“It’s a race against time,” Segura says. “The bad guys are hard at work trying to hack into affected systems.”

That’s just the first wave. Another obvious target that hacking gangs surely will triangulate are the routers used in home networks and small businesses. Up until about two years ago, Bash was widely used in Linksys, Belkin and many other brands of consumer-grade routers, says NetIQ’s Hays.

Home routers ripe for attack

So if you’re using an older router in a home or small business setting, you should assume the bad guys will soon turn their attention towards seeking out your unpatched router and taking control of it – because it’s simple and profitable to do so.

Bash also comes into play on certain Apple Macs, and certain older versions of Android handsets. Apple issued a statement saying the majority of Mac OSX users are safe from bash exploits.

Even so, it will take some time to determine the full extent of the ramifications of this flaw, says Dr. Mike Lloyd, CTO of RedSeal Networks.

“It’s relatively easy to tell whether the flaw is present, but it’s hard to tell if it’s reachable,” Lloyd says. “The maze of software and configuration interactions is too complicated for a human analyst to be able to say categorically ‘the cheese is exposed, or is not exposed, to the rat.’”

So what can individuals and companies do? Pay close heed to patches and get them installed. Tools are readily available to check whether your network is using a vulnerable version of Bash, says Jeff Schilling, CSO at FireHost.

Advised Schilling: “Step one is to figure out if you have any systems that are vulnerable. If so, how many? Step two is to figure out how to put a compensating control in place to buy time to wait for a patch. Step three, patch your systems in a methodical manner to ensure your most important servers are fixed first.”

More on emerging best practices

3 steps for figuring out if your business is secure

Encryption rules ease retailers’ burden

Tracking privileged accounts can thwart hackers

Impenetrable encryption locks down Internet of Things

Shellshock without the Shellac

A post by our exploit-herder in residence, Jason Royes

The Problem

Have you heard about Shellshock? If not, you may be living under a rock. To summarize:

If an application sets an environment variable name or value to a value that is derived from user input and subsequently executes bash (and possibly other shells), an attacker may be able to execute arbitrary code.

But WHY

When I first read the post from Robert Graham, my first thought was: “when did we begin storing function definitions in environment variables?” I scanned through the section of the bash manual dedicated to environment variables and could not find anything on the topic.

I knew I was not alone after googling and finding this on Stack Overflow. Luckily, I had an old VM handy that I never update.

Here’s bash:

$ bash --version
GNU bash, version 4.2.24(1)-release (i686-pc-linux-gnu)

So, according to the stack overflow article, what’s actually going on is that bash stores exported functions in the environment.

$ f1
f1: command not found

Let us create a file that will define a function and export it:

$ cat f1.sh
#! /bin/bash

f1() {
echo "in f1"
}

export -f f1

Now to include it:

$ source f1.sh

Voila, f1 is now defined within the shell environment.

$ env|grep -A1 f1
f1=() {  echo "in f1"
}

If you’ve already read about the Shellshock attack, the value of f1 above should look familiar.

Bash 4.2 and Exported Functions

Bash 4.2 (vulnerable) processes environment variables in initialize_shell_variables (see variables.c). What happens when an environment variable has a value that begins with “() {“? A new buffer is allocated and the variable name is concatenated with the variable’s value. This basically creates a normal bash function declaration. The concatenated string is then evaluated with parse_and_execute:

temp_string = (char *)xmalloc (3 + string_length + char_index);

strcpy (temp_string, name);
temp_string[char_index] = ' ';
strcpy (temp_string + char_index + 1, string);

parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);

Imagine an exported function named f1 that has a value resembling “() { ls -l; }”. The code above combines the name and value into temp_string, resulting in “f1() { ls -l; }”. This string is then evaluated and a function definition is burnt in memory.

The vulnerability arises because user input is being evaluated directly with the same function used to evaluate all other bash commands. If commands are appended to the end of the function definition, ex. “() { ls -l; }; ps”, they are executed. This is because they fall outside the bounds of the function declaration and so are treated just like they would be in a regular bash script. Note that anything inside the function declaration should not be executed unless the function is invoked.

The construction of temp_string also means an attacker can inject through the environment variable name. For example:

$ ./ss-name.py
total 6868
drwxrwxr-x 12 user1 user1    4096 Feb 13 17:28 bash-4.2
-rw-rw-r--  1 user1 user1 7009201 Feb 13  2011 bash-4.2.tar.gz
-rw-rw-r--  1 user1 user1      52 Feb 13 16:19 f1.sh
-rw-rw-r--  1 user1 user1      49 Feb 13 16:47 f2.sh
-rwxrwxr-x  1 user1 user1     101 Feb 13 17:30 ss-name.py
-rwxrwxr-x  1 user1 user1      96 Feb 13 16:58 ss-test.py
Segmentation fault

Whoops! Bonus segfault. Here’s ss-name.py:

#! /usr/bin/python
import os

os.putenv('ls -l;a', '() { echo "in f2"; };')
os.system('bash -c f2')

Bash 4.3 and Exported Functions

The bash patch seems fairly concise. The patch now includes a check to make sure the variable name only contains legal characters (thwarting injection through name). There’s also a new flag called SEVAL_FUNCDEF. If parse_and_execute parses a command that is not a function definition and this flag is set, an error condition results.

This seems to correct the issue, however, relying on the function parsing code still feels dicey.

Perhaps there are other ways around these new defenses yet to be revealed.

MS-SQL Post-exploitation In-depth Workshop @ ToorCon 2014!

Come join Noelle Murata and myself (Rob Beck) for a hands-on workshop at ToorCon 2014 in San Diego this October.  It’s been a while in the making, but we’re looking forward to delivering 2 days of Microsoft SQL Server shenanigans, code samples, workshops, and general database nerdery in the MS-SQL environment.  Registration is open and the workshop is scheduled for October 22nd and 23rd at the San Diego Westin Emerald Plaza!

Workshop Overview:

The MS-SQL Post-exploitation In-depth workshop demonstrates the tactics an attacker can employ to maintain persistence in a Microsoft SQL Server database, while harnessing the available facilities to expand their influence in an environment. Plenty of resources exist today that show methods for compromising SQL and SQL-dependent applications to achieve access to the environment, very few provide methods for maintaining control of a SQL instances or performing attacks against the host and environment from within the SQL service.

This course will offer attendees an understanding of the various facilities that are available for executing system level commands, scripting, and compiling code… all from inside the SQL environment, once privileged access has been acquired. Students will walk away from this two-day course with a greater understanding of:

  • MS-SQL specific functionality
  • Stored procedures
  • Extended stored procedures
  • SQL assemblies
  • SQL agent
  • SQL internals
  • Conducting attacks and assessments from inside the SQL environment
  • Methods employed for stealth inside of SQL

Upon the completion of this workshop, attendees will:

  • Be familiar with multiple facilities in the SQL Server environment for executing system commands.
  • Understand ways to execute arbitrary code and scripts from within the database.
  • Understand methods for operating with stealth in the SQL service.
  • Know ways an attacker can rootkit or backdoor the SQL service for persistence.
  • Be familiar with hooking internal SQL functions for data manipulation.
  • Harvest credentials and password hashes of the SQL server.
  • Have familiarity with the extended stored procedure API.
  • Be able to create and deploy SQL assemblies.
  • Have the ability to impersonate system and domain level users for performing escalation in the environment.

Attendee requirements for this workshop:

  • Modern laptop with wired or wireless networking capabilities.
  • Ability to use Microsoft remote desktop from their system.
  • Basic understanding of the T-SQL language and syntax.
  • Ability to follow along with coding/scripting concepts (coding experience a plus, but not required – languages include: C, C++, C#, vbscript, jscript, and powershell)
  • Ability to navigate Visual Studio and OllyDBG (previous experience a plus, but not required.)

Attendees will be provided with:

  • Hosted VMs for testing and workshop labs.
  • Training materials – presentation materials and lab examples.

Who should attend this workshop?

  • SQL administrators and security personnel.
  • Professional pen-testers and corporate security team members.
  • Incident response analysts for new methods of attack detection.
  • Forensic team members unfamiliar with SQL related attack patterns.
  • Anyone interested in furthering their understanding of SQL Server.

A Tale of Two Professionals

Phones Aren’t the Only Things That Can Get Burned

On a recent engagement I was tasked with reviewing a mobile application that provides users with disposable phone numbers. The application I was testing provided phone numbers to mobile users, permitting users to make VoIP phone calls, as well as receive SMS and picture messages; I will omit the actual application name, since it has no impact on the information being disclosed and I’m not out to shame a specific developer.  As part of their service offering, you could acquire phone numbers in various countries, as well as, various regions and cities in those countries, allowing for “local” phone calls, reducing costs for inbound and outbound regional calls.

During the initial setup of the application, new users are provided a free phone number to use during a three day trial period.  The trial period provides all features of the service including making and receiving phone calls, sending and receiving SMS messages, sending and receiving picture messages, caller identification (“Caller ID”), and voicemail.  At the conclusion of the three day trial period, users are asked to renew the phone number or acquire a different number, using extremely short-term or long-term subscriptions.  One of the selling points of the service is permitting users to create “burner”, or disposable, phone numbers that they can use for a specific period of time and for specific purposes.

Another feature of the service is the ability to have multiple phone numbers, to be used on a single mobile device.  This allows users to have multiple phone numbers, for specific purposes, in a variety of regions around the world.  As part of my testing, I navigated the various menus, going through the process of acquiring a phone number in another country.  The most important thing to note here was that after selecting my country and region/city of choice, I was presented with a list of possible phone numbers I could acquire for that area.  Not only did this allow me to enumerate possible phone numbers for this service, at least the ones not currently in use, it indicated that the service had a finite amount of available phone numbers in any area; this “feature” might be indication enough that privacy and anonymity wasn’t on the forefront of the developer’s mind.  It was only after I had selected a number that I was prompted with the various pricing models available to procure the phone number for personal use.

Because of the various pricing options, as well as the trial period, I opted to put the project on hold and move on to another application so that I could allow the trial period to expire.  This would allow me to determine pricing models following the trial period, as well as, anything else the application might want to charge me for.  I put the application in the background and went about conducting my testing on additional applications.

Fast-forward 48 hours later.  I decided to check up on the previous VoIP application to determine if there were any additional notifications for payment, warnings of trial expiration, and to begin wrapping up my testing to begin documentation.  I was surprised to see that the application had logged in excess of 20 missed calls and had a backlog of SMS messages from 10 or more random people.  If you’ll recall, I established that this service had a finite number of available phone numbers, I was provided a free phone number to test during the trial period, and this means that the number I was provided was previously used by another user of the system.

Going based solely on the contents of the SMS messages received, as well as some of the voicemails left on my trial number messaging service, the previous owner was also a specialized professional who is use to charging an hourly rate; let’s just say that her chosen profession was of a much more discreet and intimate nature.  I was presented with text upon text message asking if he/she was available, what their hourly rate was, as well as a few much more graphic explanations of specific requests the potential clients would like performed.  What was more surprising, and traumatizing, was that some of these individuals had chosen to send naughty-gram picture messages of their previous work with this professional, personal pictures in admiration of this person, and… well, you have an imagination.

None of the individuals contacting this number had any indication that the person they were trying to contact (no pun intended) had been using a burnable phone number.  The problem was made worse for them because of the features provided by this service, as previously mentioned the VoIP service offers Caller ID; I was not only receiving the correspondence from this lengthy list of previous contacts, but now I had the phone numbers they were using to reach me.

A sample of the least explicit messages received.

A sample of the least explicit messages received.

This situation now not only posed a risk to the previous owner of this phone number, permitting me access to their contacts who had reached out to her, but exposed her clients and potential clients to exposure from an unknown individual now in possession of their information.  While it would be nice to assume that the individuals attempting to correspond with the previous owner of the number were also using temporary phone numbers, this isn’t a perfect world and people rarely take the steps needed to ensure their privacy if they don’t feel that they’re at risk; after all, some amount of this sort of business is based on a level of trust and unwritten understanding between the professionals and their clients.

I’m not here to provide commentary on the nature of the previous individual’s chosen profession or hobby, to each their own, but this situation presented an extreme introduction into some of the dangers of the burner phone culture some of us have come to accept.  While many of us can see the value of having a disposable phone number and messaging, easily hopping between numbers for both legitimate and illegitimate purposes, I don’t think many people have realized the repercussions of being the recipient of a disposable resource.  Even in the age of services such as Google Voice, assumptions are made that the numbers we’re corresponding with have a reasonable time to live with the person that provided it to us.

With a minimal amount of social engineering, much more information could have been captured from these individuals.  Due to the disclosure of their phone numbers coupled with the power of Google and other search engines, the potential for extortion by a random individual who is now in possession of compromising photos is also a reality.  The next time we make a phone call, or send a SMS with questionable content, we have to ask ourselves – do we really know who is receiving this or have we also been burned?

Blackhat USA Multipath TCP Tool Release & Audience Challenge

We hope everyone found something interesting in our talk today on Multipath TCP.

We’ve posted the tools and documents mentioned in the talk at: https://github.com/Neohapsis/mptcp-abuse

Update: We’ve now also added the slides from the talk.


At the end we invited participants to explore MPTCP in a little more depth via a PCAP challenge.

Without further ado, here’s the PCAP: neohapsis_mptcp_challenge.pcapng

It’s a simple scenario: one MPTCP-capable machine sending data to another. The challenge is “simply” to reassemble and recover the original data. The data itself is not complex so you should be able to tell if you’re on the right track, but getting it exactly right will require some understanding of how MPTCP works.

If you think you have it, tweet us and follow us (@secvalve and @coffeetocode) and we’ll PM you to check your solution. You can also ask for questions/clarifications on twitter; use #BHMPTCP so others can follow along. Winner snags a $100 Amazon gift card!

Hints #0:

  • The latest version of Wireshark supports decoding mptcp options (see “tcp.options.mptcp”).
  • The scapy version in the git repo is based on Nicolas Maitre’s and supports decoding mptcp options. It will help although you don’t strictly need it.
  • The is an mptcp option field to tell the receiver how a tcp packet fits into the overall logical mptcp data flow (what it is and how it works is an exercise for the user :) )
  • It’s possible to get close with techniques that don’t fully understand MPTCP (you’ll know you’re close). However the full solution should match exactly (we’ll use md5sum)

Depending on how people do and questions we get, we’ll update here with a few more hints tonight or tomorrow. Once we’ve got a winner, we’ll post the solution and code examples.

Update: Winners and Solution

We have some winners! Late last night @cozinuzo contacted us with a correct answer, and early this morning @darkfiberiru got it too.

The challenge was created using our fragmenter PoC tool, pushing to a netcat opened socket on an MPTCP-aware destination host:

python mptcp_fragmenter.py -n 9 --file=MPTCP.jpg --first_src_port 46548 -p 3000 192.168.1.33

The key to this exercise was to look at the mechanism that MPTCP uses to tell how a particular packet fits into the overall data flow. You can see that field in Wireshark as tcp.options.mptcp.dataseqno, or in mptcp-capable scapy as packet[TCPOption_MP].mptcp.dsn.

mptcp_wireshark_column

The mptcp-capable scapy in our mptcp-abuse git repo can easily do the reassembly across all the streams using this field.

Here’s the code (or as a Gist):

# Uses Nicolas Maitre's MPTCP-capable scapy impl, so that should be
# on the python path, or run this from a directory containing that "scapy" dir
from scapy.all import *

packets = rdpcap("pcaps/neohapsis_mptcp_challenge.pcap")
payload_packets = [p for p in packets if TCP in p
                   and p[IP].src in ("192.168.1.26", "192.168.1.33")
                   and TCPOption_MP in p
                   and p[TCPOption_MP].mptcp.subtype == 2
                   and Raw in p]

f = open("out.jpg", "w")
for p in sorted(payload_packets, key=lambda p: p[TCPOption_MP].mptcp.dsn):
    f.write(p.load)
f.close()

These reassemble to create this image:

MPTCP

The md5sum for the image is 4aacab314ee1a7dc5d73a030067ae0f0, so you’ll know you’ve correctly put the stream back together if your file matches that.

Thanks to everyone who took a crack at it, discussed, and asked questions!

Rob Beck’s MS-SQL Rootkit Framework Presentation @ DefCon Skytalks 2014

SQL Gestalt: A MS-SQL Rootkit Framework will be presented by Rob “whitey” Beck (@damnit_whitey) at the DefCon Skytalks 2014 in Las Vegas, NV this year.  This talk will provide an overview of a basic framework for the creation, deployment, operation, and persistence of a MS-SQL rootkit for all versions of Microsoft SQL Server 2005 and above.

Overview

This talk illustrates the various facilities in the MS-SQL database environment for performing code execution.  Using these facilities, attendees are presented with the basis of the SQL Gestalt – A rootkit framework, utilizing various aspects of the SQL core facilities, working in conjunction to provide persistence in the database.

x

This talk benefits pen testers, forensic analysts, and database administrators by exposing methods and tactics that may not be commonly known or widely employed in traditional database compromises. Examples will be provided in a variety of languages including T-SQL, C#, C++, VBscript, and Powershell utilizing SQL facilities such as SQL Assemblies, the Extended Stored Procedure API, SQL Agent, and OLE Automation.  At the conclusion of this presentation a basic framework will be released with sample code to illustrate all of the functionality discussed in this talk.

Talk Agenda

The following topics will be discussed in the presentation:

  • Concept of the SQL Gestalt rootkit
  • Facilities for executable code in SQL
    • Overview
    • Advantages
    • Disadvantages
    • Examples
  • Module installation
    • Deployment
    • Execution considerations
  • Securing a native code execution point
  • Persistence in SQL
  • Advanced rootkit operations