Security Research

Home » Security Research

Hunting for DoublePulsar in your networks

in Incident Response, Network Visibility, Security Research, Threat Detection by Mike Spohn Leave a comment
The recent release of the Equation Group’s (NSA) FuzzBunch software by the Shadow Brokers has caused quite a stir in the security community. The volume of files released, (6,547 in one of the dumps), is an extraordinary collection of malicious software including many zero-day exploits.

One of the binaries that caught my interest was DoublePulsar. This is the main tool used by the Equation Group to compromise Windows hosts using a SMB and RDP zero-day exploit.

Although the attack surface is complicated, my fellow researchers at zerosum0x0.com did a highly competent job of describing it. To me, the most interesting step in the attack is the patching of the function dispatch table of the device driver Srv.sys in memory. Slot 0x20 (14) in this table originally pointed to the SrvTransactionNotImplemented() dispatch function. It is hijacked by the malware.

Why is this interesting? Because even though the implementation of this attack is quite brilliant, it is trivial to identify this attack in your network.

I refer you to page 426 of (Microsoft’s Common Internet File System (CIFS) Protocol) protocol document:

2.2.6.15 TRANS2_SESSION_SETUP (0x000E)
“This Transaction2 subcommand was introduced in the NT LAN Manager dialect. This subcommand is reserved but not implemented. Clients SHOULD NOT send requests using this command code. Servers receiving requests with this command code SHOULD return STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc).”
The CIFS/SMB TRANS2_SESSION_SETUP subcommand was never implemented by Microsoft. The standard states that any call to the command by a Windows client should return a STATUS_NOT_IMPLEMENTED reply. Once DoublePulsar redirects the Srv.sys SrvTransactionNotImplemented[] function pointer to its own code injected in memory, any SMB call to a NOT_IMPLEMENTED SMB subcommand will end up calling the DoublePulsar code.

Knowing this, is it possible to identify DoublePulsar in your network by simply looking for SMB requests for NON_IMPLEMENTED subcommands, or even simpler, any SMB STATUS_NOT_IMPLEMENTED response? Yes.

To illustrate this, look at the WireShark screenshot below that shows a SMB call to the TRANS2_SESSION_SETUP (0x000E) subcommmand.

Figure-1: TRANS2_SESSION_SETUP (0x0E) Request

Read more

Lowering The Poverty Line Of Incident Response

in Incident Response, Security Research by Patrick Kelley Comments are off

Over the years I’ve been part of monumental projects using several forms of technology, including SIEMs, in attempts to offset the talent gaps that plague the Information Security industry and shorten the “dwell” timeframe of attacks.  Taking a moment to define the anticipated goals and define the problem space, I find it necessary to state that properly launching a SIEM and similar technologies isn’t trivial and gaining a meaningful return on the investment is a significant challenge. Personally, I determine that return on investment to be a reduction in MTTD (Mean Time To Detection) and MTTR (Mean Time To Remediate).

The ultimate goal is revealing actionable intelligence that takes into consideration the true risk posed to the business and weights the alerts in that light.  This task cannot be achieved by leveraging and applying “threat intelligence” feeds as the primary form of correlation. Instead, it requires developing context around the core assets, networks, and layers of security controls that comprise the network.

In and of itself, this isn’t an easy problem to solve as businesses and their networks develop organically, as opposed to the more traditional networks created in the past.  This matters as demand for an urgent business needs drives the need for additional computing resources, leaving security as an afterthought.  This makes building contextual solutions around security problems a near impossible feat for most organizations.

Coincidentally, this is where SIEM implementations often fail. The concept of the SIEM is sound, but most implementations make decisions based on single, atomic events that are universally weighted.  This could be the match of an IP address or similar. This fails as security incidents are not singular, but more often contextual and long-playing.  Often I’ve been asked, “If we had signatures for Pass-The-Hash attack binaries and we used UAC, why were we breached? We had controls!”. 

Simply stated. This is a significant problem to solve.

The tough truth is the evolution of our networks and the way organizations communicate accelerate faster that the limited amount of resources the organization has to apply. So, just hire more professionals, right?

Here’s the harsh truth. Developing a proper Security Operations Center takes well over a year on average, and that’s just to nail down the basics.  Once developed, you will need a minimum of 8 well-trained engineers and a Sr. Security Architect to maintain the ability to respond 24/7/365, with ever-evolving breach detections. 

So, what’s the solution?  

In fairness, there isn’t a single one-shot answer for this.  However, I can offer the following advice that can greatly improve the security posture of an organization. 

Maintain a clear understanding that a threat is not just the presence of events, but also the absence of events. A phishing email with a malicious binary is certainly interesting, but so is the failed synchronization of an HA or failure of vMotion Snapshots.

Acknowledging that breaches can remain active for over 100 days, a platform that collects artifacts at the lowest level of ground truth and hold that evidence for hundreds of days, is becoming a requirement.

Threat Intelligence feeds are not the glue that binds together a security platform.  They are simply atomic indicators that can be applied to network flows. That’s not to say there’s no value in these sources of data, but a need to correlate those indicators with other sources.  Additionally, more Threat Feeds isn’t the answer.  It is far more valuable to choose the proper feeds for your environment and prevent as much overlap as possible.

Leveraging platforms, such as PacketSled, that apply multiple sources of enrichment to wire-level data, can provide greater confidence in incident relevance and the reduction of false-positives. For example, a Threat Intelligence match for an Apache attack methodology likely doesn’t represent a true threat when leveraged against a Windows environment.

We need to rely less on signatures and leaning more on User and Entity-based behavioral analytics. This isn’t an easily applied solution, but one that establishes dynamic baselines on observed behaviors with entities, allowing it to determine anomalies.  Anomalies could be determined as user accounts conducting database queries after midnight, which could not symbolize a threat, but an indicator worth additional investigation.

A means of properly prioritizing cases in a meaningful and actionable way. This is a tough problem, but one that will maximize the limited resources an organization has available. 

What’s the overall message in this?  Security is hard. It’s less the process of efficiently identifying the probable state of all enterprise platforms and users, but more so with identifying and understanding the applied risk of all possible operational states of systems and people. 

 

Reach out today and learn what we are doing to help you close the gaps and lower the poverty line in Incident Response.

How your Refrigerator is a Threat and Why you Should Care: Attacks on IoT

in Security Research by Patrick Kelley Comments are off
Last week, Wikileaks dropped an explosive number of documents related to their surveillance and hacking capabilities.  Much of this information included strategies related to IoT and household devices, such as the Samsung TV.  To be clear, the leak of CIA documents and data didn’t readily include usable source or exploit code for leveraged attacks, but was more of an internal wiki which provided information about available attacks and strategies used by the agency.   

In our research, it appeared that most of the exploits reference full-on remote access vulnerabilities, some of which were already known. Many of the documents outlined planned strategies or half-developed exploits, many of which requiring physical access to the device or the supply line.

WikiLeaks, in a statement, was vague about its source. “The archive appears to have been circulated among former US government hackers and contractors in an unauthorized manner, one of whom has provided WikiLeaks with portions of the archive,” the organization said.  

As the data dump is quite lengthy, let’s start with “Weeping Angel”.  This is an attack methodology that was recently published by Wikileaks and outlines that a Samsung TV can be hijacked using vulnerable firmware.  This was developed during a joint workshop between MI5 and BTSS (British Secret Service).  The recent reports disclose how to make the television appear to be powered off but in reality was being used to monitor targets. It describes the television as being in “Fake Off” mode.  Some key things to note is that when the television is compromised, it provides the attacker with a ported and modified TinyShell to provide shell, command execution, and file transfer capabilities.   

This functionality allows the television to be used as a monitoring device, as well as a pivot point for further attacks against devices on the network (persistence).  

The current versions of vulnerable firmware provide the following technical details: 
  • Video capture / Video snapshots
  • Max possible storage usage is 700MB (of 1.6GB).
  • The installation is similar to installing a standard Samsung application.
  • empDownload is the binary that downloads other apps or adverts and is executed by the system.
  • It appears to connect to Dreamhost and supports Telnet and FTP.
  • It has native WPA and iw wireless network capabilities. 
As a longtime security researcher, I tend to believe that these capabilities extend much farther than televisions.

So, you might be asking, “when is he going to tell me about my refrigerator trying to kill me?”. 
Read more

Using Bro to Explore Your Networks, like an AWS WordPress Blog

in Security Research by Leo Linsky Comments are off
My personal WordPress blog was hacked a few weeks ago. I hadn’t checked my simple AWS micro instance in a while, and fortunately, I happened to look at the site just a day after it was compromised. WordPress makes it easy to stand up a pretty website if you don’t want to spend time crafting a front-end yourself, but security is a major question mark. If you keep it up to date and don’t load it with tons of third party content, it’s probably OK for a personal blog. However, I had several WP plugins and themes that were a few weeks behind the last update, as was WP Core. This is likely how the attacker was able to gain write-access to my one and only post on my blog and change the links to point at some sketchy-looking foreign domain websites to improve his SEO. Interestingly enough, the attacker also made some edits in the article, including grammatical fixes and clauses that were consistent with the content (environmental regulations).

Regardless, I updated everything, removed unnecessary plugins, added a plugin to record more detailed WordPress history, secured my active accounts, and reverted the changes (except for one grammatical improvement – thank you attacker). Good WordPress security and statistics plugins are difficult to come by, and they most likely increase the attack surface of the website, so I decided to opt for the tool I use and develop every day: Bro IDS. The visibility provided by Bro goes beyond threat detection and can be used as a more powerful version of netflow, showing what’s running on a system in significant detail.

Monitoring a single web server instance facing external http requests behind a pretty limiting firewall (inbound tcp/80 only, or tcp/22 from my static IP address only) is not our typical deployment for Bro here at Packetsled — limited to basic web requests, and with no honeypot, I didn’t expect a whole lot of interesting attack vectors. However, there were some takeaways after letting Bro run for a few weeks, mostly regarding how my network operates and what kind of requests my site typically sees.

The blog uses basic unverified HTTP (I’m too lazy and cheap to set it up right), so I was unsure why I had at least one ssl log entry every hour:
#fields id.orig_h id.orig_p id.resp_h id.resp_p version cipher curve server_name resumed last_alert next_protocol established cert_chain_fuids client_cert_chain_fuids subject issuer client_subject client_issuer validation_status

172.31.40.119 59718 52.201.183.155 443 TLSv12 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 secp256r1 - F - - F Fb0mOL2796DAoCkRa3 (empty) - - - - -
172.31.40.119 41499 66.155.40.189 443 TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 secp256r1 - F - http/1.1 F Fr4ISl3di8C0feHNC4,F2sfO14ZkvhwHhaNb4,F10O3d278YkNUhURTf (empty) - - - - -
Ah of course — after opening up the corresponding x509 certificate log, it’s clear that my device is reaching out to WordPress about twice a day, looking for updates from “CN=*.wordpress.org,OU=Domain Control Validated CN=Go Daddy Secure Certificate Authority – G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com.” More surprisingly though, my instance periodically was reaching out to an Amazon-based address every hour on my exposed network (as opposed to the back channels AWS uses to control instances):
pi@raspberrypi:~ $ whois 52.201.183.155
NetRange: 52.192.0.0 - 52.223.255.255 
CIDR: 52.192.0.0/11 
... 
Organization: Amazon Technologies Inc. (AT-88-Z) 
x509.log
#fields certificate.version certificate.serial certificate.subject certificate.issuer certificate.not_valid_before certificate.not_valid_after certificate.key_alg certificate.sig_alg certificate.key_type certificate.key_length certificate.exponent certificate.curve san.dns san.uri san.email san.ip basic_constraints.ca basic_constraints.path_len
3 07 emailAddress=info@bitrock.com,CN=stats.bitnami.com,O=BitRock Update Services,L=Seville,ST=Seville,C=ES emailAddress=info@bitrock.com,CN=BitRock Update Services,O=BitRock Update Services,L=Seville,ST=Seville,C=ES 1284478570.000000 1599838570.000000 rsaEncryption sha1WithRSAEncryption rsa 1024 65537 - - - - - F -
3 280392F6950C4C CN=*.wordpress.org,OU=Domain Control Validated CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\\, Inc.,L=Scottsdale,ST=Arizona,C=US 1417824798.000000 1513368681.000000 rsaEncryption sha256WithRSAEncryption rsa 2048 65537 - *.wordpress.org,wordpress.org - - - F -
Read more

Attacks On Routers and IoT

in Incident Response, Malware, Network Visibility, Security Research by Patrick Kelley Comments are off
Here at PacketSled, we live on the forefront of technological innovation.  Our deployed platform captures multitudes of attacks each day against devices that have just barely made it into the market. To keep up with attacks against “bleeding edge” IoT devices is no small feat.

To understand how to best protect these new assets, it’s best to understand what brought them here.  The adoption of IoT and BYOD has increased with the intent of streamlining technology for the user and easing adoption in the marketplace..  Apps in IoT can become seamless, removing the barrier that a user used to have in determining if they were sharing information with a co-worker or with the Internet.  The more covert we make these transactions, the more risk we are accepting (think tap to pay, passwords transferred through nfc, and magic links as Slack likes to call them).  

Without a clear understanding of standards and services, it’s a challenge to determine how to best approach securing them. In fact, it’s such a challenge that Gartner has claimed that nearly all security vendors will fail at this task. 

Personally, I agree.  

Security budgets are rarely earmarked for efforts around IoT and business scenarios require a delivery mechanism that can also grow and keep pace with security requirements in monitoring, detection, and access control.  Despite this, users continually add more devices to the enterprise network, due to ease of doing so.

Fortunately, PacketSled has been thinking about IoT for quite some time.  Our team has spent many years of focused research on the most common IoT attacks.

One of the most common attacks we witness is authentication bypass. This could be due to poor session handling with predictable IDs or backdoors using hardcoded credentials. Regardless of the means, the outcome is the same – unauthorized access to sensitive information.

A quick search of Shodan will likely provide access to nearly any device, including devices in your infrastructure, an attacker would be interested in. In fact, we need not look further than a recent IoT attack which was seen with Mirai. It worked by scanning the Internet for devices with default credentials and enrolling them into the command and control platform. Once done, all of these devices can be remotely controlled and used to perform nearly any action conceivable. These attacks occurred across a wide spectrum of devices from smart TV’s to routers to really anything with the “smart” monicker attached.

Packetsled is here to help protect by proactively building detections in our platform to look for these behaviors, but our recommendation is to make sure your organization is covering the basics.

Where should you begin? 

Start with the CIS Critical Security Controls with emphasis on the 1st six. 
  1. Inventory of Authorized and Unauthorized devices
  2. Inventory of Authorized and Unauthorized software
  3. Security configurations for hardware and software on mobile and IoT devices
  4. Continuous Vulnerability Assessment and Remediation
  5. Controlled user of administrative or root privileges
  6. Maintenance, Monitoring, and Analysis of Audit Logs
  

With these basics addressed, you will have a more clear understanding of what devices and accounts are in use on your network and how you should expect them to behave.  

Among the many detections that PacketSled provides, you should look for unencrypted credentials present on the network, by issuing the following query in the investigator:

last 24 hours cluster password on [password]





This simple query will provide you with every password observed on the network in the last day.  This list is exportable and can be used to aid in the mitigation of these vulnerabilities.

We also provide extensive support for newer IoT protocols, along with our raw TCP and UDP analyzers, which will allow you to see inside network flows, even when a specific protocol analyzer isn’t available. 

Along with our security platform and the recommendations outlined above, we suggest signing up with each vendor for updates related to security patches, firmware updates and any available alerts provided from the devices, themselves.

 
Written by Patrick Kelley and Chris Mitzlaff 

It’s 10 PM. Do you know where your data is?

in Security Research by Patrick Kelley Comments are off

I’ve had the fortune of working in Information Technology for over 20 years.  In that time, I’ve realized that this industry is constantly evolving. However, the recent and rapid adoption of cloud-based services has caused a disruption at a magnitude that I had not yet seen.  Unfortunately, it is also happening at a rate that isn’t properly allowing Information Security groups to properly gauge the security ramifications. 

When I first entered this industry, networks were far easier to secure.  We had differentiating operational goals, but what we secured were largely single, flat, and enormous networks with only a handful of entry points.  All data and assets lived within that one or two physical environments with their own dedicated controls.  When we built our enterprise networks, we would build them to support the maximum resources needed to support the assets and needs within that single environment.  It was very linear and, in comparison, far easier to scope and manage than the networks we support today.  Much like today, our worst enemy was downtime, but the rules of engagement has changed, as have the margins for error.

What do users want?  Everything right here. Right now. Oh yeah, we want it to be as cost-effective as possible.

With the benefits of cloud computing including quicker market entry, flexible costs and capacity, larger and more robust network fabric, allowing greater uptime, improved mobility and collaboration, and more fluid merger and acquisitions, it’s easy to understand why there has been such a major push into the IaaS and SaaS space. 

This also means that the “Crown Jewels” live in many new places, around the globe.  Several within the corporation’s complete control, many which does not.  Currently, AWS operates in as many as 13 distinct locations around the world.  That’s a lot of entry and exit points for your data to move.  With the rate of migration and architectural change, most Information Security groups haven’t had the time or resources to assure that proper monitoring is taking place in these new realms.

Let’s face it… It’s a pretty rough day when you experience a breach or network outage in your own network, but it becomes far more complicated when it occurs in your partner’s network.  In reality, the headlines read largely the same. 

Additionally, as compliance oversight and governance won’t go away with the introduction of cloud-services,neither will the requirements for monitoring, reporting, and coordinated incident response with resolution. In addition our research shows that firewall configuration complexity is leaving companies exposed. The technology to keep your networks safe exists, but it’s nearly impossible to manage properly. This is where PacketSled comes in.We build feature-rich, security platforms, which easily enable the aggregation of packet-level, network analysis from multiple IRES sensors deployable around the globe.  

Specifically, PacketSled sensors can live at multiple points throughout your core network, but also live within your cloud-environments. To ease management, we provide a centralized user interface that works for your team, wherever they are in the world.  With an increasing amount of technology partnerships and APIs being developed by Packetsled staff, we also play well with others. 

We understand that innovation is happening and at a rapid pace. With the ease of deploying Packetsled sensors, you can rollout new network coverage in a defined, lockstep approach to make sure you don’t miss an attack on your new infrastructure or initiative.  Best of all, you can launch new sensors when you need the coverage, not months or years beforehand. 

With our service, you always have the most recent detections, protocol analysis, and sensor technology, located in a Data Centre that will adhere to your governance and regulatory compliances.  We perform all of the research and development; you reap all of the benefits.

Wherever your business is today and headed tomorrow. Let us reduce your worries about moving into the cloud. With the Packetsled platform, we’re here to help.

-Patrick Kelley, Sr. Security Researcher

TIME TO DIE – Bricking An iPad Over the Air

in Security Research by rrhyne Comments are off

Research from PacketSled and Patrick Kelley, CISSP, CEH, MCP at Critical Assets proves it possible to remotely brick iDevices over-the-air. The team built the exploit based on Zach Straley’s research which exposed a flaw in iOS when a user to manually set the date of an iPhone or iPad to January. 1, 1970.



Using a custom Raspberry Pi setup built by Kelley, a wifi access point resembling a commonly trusted network spoofs Apple’s NTP servers to pass the 1/1/1970 date to the device. This starts a chain reaction of software instability resulting in a observed temperatures up to 54°C… which is hot enough to brick a device.

rpi
The rPi that killed the iPad


The team reported the exploit to Apple who released the update 9.3.1 to address the issue.


Read more on Krebs: krebsonsecurity.com

© 2017 PacketSled, Inc.