Vendors often have interesting ways to facilitate support for their appliances. Today, I'll discuss a few ways we have seen it implemented: one that is vulnerable to exploitation and others that aren't so bad.
When we find vulnerabilities doing independent research, we work with the vendors through our disclosure program to attempt to get the issues fixed, and we are free to publish whether or not the vendor addresses the problems. Occasionally while on an engagement for a client, we come across one or more vulnerabilities in third-party platforms. When this happens, we work with our client to inform their vendor in an effort to get the vulnerabilities corrected, and coordinate disclosure.
Usually, vendors are responsive, and our client and other customers of that vendor get the fix. However, it does not always work that way.
Here at KoreLogic, we are constantly cracking passwords — it's just one of the things we do. While we haven't made a concerted effort to track it, I'd venture to say that cracking for us is pretty close to a 24/7/365 operation. Between paid cracking engagements and penetration tests, our resident cracking expert, Rick, almost always has something cooking on our Distributed Cracking Grid ("Grid"). This week, it happens to be LinkedIn hashes. This level of uptime is made possible by the WebJob framework, the foundation upon which our Grid was built (check out this paper for a brief overview of the technology). WebJob's queuing system allows us to maintain a number of concurrent work orders at any given time. Today, for instance, we have 22 active work orders consisting of 151,995 jobs (or attacks) spread out over 35 queues. At any time, a single attack can be in one of several states (e.g., waiting, working, complete), and resources (i.e., GPU and CPU cores) can be shifted from queue to queue as needs dictate. Additionally, attacks within any given queue can be prioritized. All of this allows us to keep work orders active for days, weeks, or even months at a time, and that's pretty darn cool.
As the Grid's chief architect and primary developer, it's my job to keep the Grid running and add new features/capabilities over time. In this article, I'd like to share with you our aspirations and reasons for creating a cracking grid that is secure, distributed, scalable, and extensible.
As you may know, a "full" dump of email addresses and password hashes for the Linkedin.com attack that occured in 2012 has become available. Here at KoreLogic, we got our hands on the list of emails and the separate list of passwords (but nothing linking the two together, which we don't want or need). We started to gather some statistics on them using our Password Recovery Service (PRS). The following analysis assumes the lists are real; due to the valid email addresses and confirming some of our own accounts' data from back then, we believe that the dump is real.
What we know so far:
The @CrackMeIfYouCan team at KoreLogic has had a lot of questions about this year's DEFCON Crack Me If You Can (CMIYC) contest ...
The short answer is, we are not doing a CMIYC this year at DEFCON. That does not mean that 2015 was our last year, it just means we aren't doing one in 2016. It's been a very busy year for us so far, and CMIYC is a huge commitment on our schedules. We just cannot make it happen this year.
On a more personal note, I dreamed up CMIYC in 2010 with multiple goals in mind:
Welcome to part four in our four part series on firmware and embedded devices. In our final part, we will discuss a remote root vulnerability in a popular cable modem. Awhile ago, we were shown the administrator portal for a particular cable modem vendor. Old school, right? Still, what an interesting attack vector, we thought. We realize ISPs need some degree of access in order to properly provision modems, but how much should you trust your ISP (and who they partner with) to make security decisions for you? Personally, we only believe in what can be measured and this meant our hands needed to get dirty... Don't worry root, we're coming for you!
Welcome to the third part of our series! Today I hope to spark a conversation amongst the readers about an important topic in a world filled with IoT: access to device firmware. And not just (at best) encrypted opaque blobs provided for device updates, but usable images that can be deconstructed, evaluated, and reconstructed.
There are a few categories of devices for which firmware access would apply. These are consumer, enterprise, medical, and military. My coworkers and I have dealt with all of these to varying degrees. You might think military procurement would always include full firmware/source code access; I mean, they'll want to make sure the device is not designed in a way that is counter to their interests in the same way that I want to ensure the same thing when I (and most other people for that matter) also purchase a device. Mumble mumble...
What about consumer or enterprise grade devices? Most vendors have some support level (i.e. price point) at which they'll give an enterprise customer access to firmware. But for smaller organizations, or one-off purchases, they are often told what I am as a consumer a majority of the time: "no". In the last two parts of our series, I'll go into deeper thought on firmware access using current and upcoming examples from our vulnerability disclosure program.
Hello again and welcome back. This is part two in our four-part series on firmware and embedded devices. Today, I will be discussing home automation and the Internet of Things (IoT). More specifically, I'll be talking about Blossom. Blossom is a cloud-based smart lawn watering system that will 'automatically' water your lawn. Normally, our goal is to break into the target device so I may inspect running processes and resident binaries to ensure they are not designed to work in ways that are counter to our interests. Today, I won't be doing that. Instead, I am going to observe the functionality of the device and how it interacts with the manufacturers cloud-based API. Then, I'll force network traffic redirection from the device to a server I control. Finally, I will recreate a bare minimum copy of the manufacturer's API available internally so that the device will no longer require internet access for a somewhat normal operation.
What does this mean? I am going to write an application to water my lawn, when I want my lawn watered. Why? Because I like the functionality of smart-enabled devices, but I do not like adding network potential pivot points anywhere on my networks. My hope is that this part in our series serves as a soft introduction into the thought process I typically use when removing an unwanted third-party from my networks or even attempting to attack the underlying software of a target device.
Hello folks, welcome to the first of a four part blog mini-series on firmware and embedded devices. My name is Matt Bergin and i'll be guiding you through the series. We plan to release each part of the series on the Friday of each week in December. The release of the final part in our series is dependent on our responsible disclosure timeline holding for a finding, but we're pretty confident.
We're going to start slowly and with something simple. Today's tale is about a little access point that tried and tried but just couldn't keep its mouth shut. If it has an IP it'll talk, and what it says you might not like. Though, we tried to make it stop (see the timeline in the advisory), it didn't seem to matter to the manufacturer. So here we are: an 0day to help start your holiday season.
Onward and upward!
You can purchase the vulnerable device and download the corresponding firmware here: http://www.linksys.com/us/support-product?pid=01t80000003cVuwAAE
I am pleased to announce that a new release of the Password Topology Histogram Wear-Leveling (PathWell) library and PAM module for dynamic password-strength enforcement is now available for download here.
Version 0.6.3 is an update release of PathWell. Generally, code was cleaned up and refined as necessary. The API remains unchanged, but the library did get a revision bump -- the new version is 1:1:0. The primary goals of this release were to work out the build issues previously encountered for some flavors of Linux and to extend configure/build support to MinGW/MSYS build environments. And while the library along with the associated command line utilities compile cleanly and pass all their unit tests under Windows, setting up that build environment and getting the various dependencies (e.g., GMP, PCRE, SQLite, etc.) to compile involves a number of steps, a few hurdles, and fair amount of determination, so be prepared if you decide to venture down that road. Perhaps that will be the topic of a future blog post. Who knows? ...
Anyway, this will likely be our last release for the 0.6.0 branch as our attention has shifted to the 0.7.0 release, which includes new features and tools. More on that to follow in the coming days, so stay tuned ...
MASTIFF is a living project whose continuous goal is to provide an automated means for static analysis of files. To meet this end, the project has multiple short and long term goals in place. Recently we silently released an update that hit one of the major goals we have been working towards since inception of the project: output plug-ins.
As noted before, the puzzles are still accessible at the CTF page, so there are spoilers if you plan to go through them.
As noted before, the puzzles are still accessible at the CTF page, so there are spoilers if you plan to go through them.
During Black Hat, Ron Tokazowski of phishme.com put together a Yara Capture The Flag (CTF) contest for Black Hat 2015. This CTF consisted of 11 logic and Yara-based puzzles that participants had to solve for a chance to win a DJI Quadcopter. The best part is you could participate in the CTF if you weren't at Black Hat!
I participated in the CTF and won!!! I got through 10 out of 11 puzzles; the 11th and my lack of doing it is explained later. This post, as well as two more, describe how I went through each puzzle and solved them. The puzzles are still accessible at the CTF page, so be warned that spoilers are below!
I am thrilled to announce the first public release of the Password Topology Histogram Wear-Leveling (PathWell) library and PAM module for dynamic password-strength enforcement. Version 0.6.1 is available for download here.We have blogged and written and presented about PathWell several times, but now we've finally dropped the code.
The LibPathWell release is a PAM module and supporting library to implement password topology complexity enforcement. There is a static component called blacklisting that allows you to seed the PathWell database with the most popular password topologies, so instead of an attacker cracking 25%+ in their first few mask attacks, they get zero. And then there are dynamic components ensuring that enterprise users, as they change their passwords, are forced to choose new passwords that are substantially different from one another.
tl;dr: PathWell makes enterprise user passwords 5-6 orders of magnitude harder to guess!
A search through the online mirror of the information stolen from Hacking Team shows indications that a BIOS-based infection capability was developed as part of the Remote Control System software. This may be the first time a commercial spyware product claims this type of capability.
The Giles production rule system compiler (which we described here) has gotten some good press lately!
An article describing Giles and its use has been published in the June 2015 issue of The ISSA Journal, which can be seen by subscribers here. The ISSA Journal is the official journal of the Information Systems Security Association, and we're very proud to have an opportunity to discuss Giles on its pages. The article describes what Giles is, how to use it, and how to use the engines it creates. It also talks a little bit about how it works under the hood.
Also of note, I will be presenting a talk about Giles at this year's Black Hat USA in Las Vegas on August 1-6th. This talk will describe the reasons behind the creation of Giles, how it works, and how it can help you build efficient, simple event correlation engines and expert systems. Let us know if you're going to be at Black Hat this summer; we hope to see you there!
And remember, Giles is open source, so be sure to check it out (both in the look-at-it sense and in the grab-a-copy-of-its-code sense) at https://git.korelogic.com/giles.git/.
The MASTIFF Online site was updated on 2015-06-05 which included the following:
The WebJob framework is a next generation endpoint security solution that, from a centralized management location, can execute virtually any program on an arbitrary number of end systems at any time. This framework has been deployed in a number of production environments including the Federal government and Fortune 500 businesses to perform various activities such as evidence collection, enterprise searches, incident response, live forensics, system management and monitoring, and grid computing.
The WebJob framework is an open source client-server solution that acts as a force multiplier for anyone who needs to automate various tasks or work on an enterprise scale. It does this by enabling engineers to run arbitrary programs and/or scripts on a wide array of operating systems (e.g., UNIX®, Linux®, Mac OS®, Windows®, Android®, etc.). The results, if any, can be aggregated and collated on the WebJob server where they can be operated on in bulk. With the flexibility that the framework provides, administrators who are inclined to write their own scripts can achive a high level of automation and efficiencies of scale. With the WebJob framework, you can effectively do more with less.
Please click the link below to read more about how the framework could be the next generation endpoint security solution for you.
The WebJob Framework: A Generic, Extensible, and Scalable Endpoint Security Solution
It has been exactly one month since MASTIFF Online was opened, and to celebrate, we have released the next stable version of MASTIFF! Version 0.7.1 includes a large number of bug fixes, as well as some new analysis plug-ins to get more information out of the files you are analyzing. The new version can be found at https://git.korelogic.com/mastiff.git/.
The use of CCleaner is encountered at times during forensic investigations of computer systems. It has been labeled an "anti-forensics" tool as it has a secure deletion mode where it can overwrite data, filenames, and free space.
Overwriting files and filenames removes the chance to recover the data and subject it to further analyses; hence, the anti-forensics label. There may be some remnants and data left for analysis and comparison; but, at best you can infer what had been wiped. What you are faced with is a case of "You don't know what you don't know".
That is, until now. CCleaner will actually tell you what files it wiped. You just have to work for it.
KoreLogic is pleased to announce the release of MASTIFF Online, a web interface into the open source MASTIFF static analysis framework. With this free online tool, anyone can upload files to be examined by MASTIFF, returning the results within minutes. MASTIFF Online can be accessed at https://mastiff-online.korelogic.com.
Digital evidence storage for legal matters is a common practice. As the use of Solid State Drives (SSD) in consumer and enterprise computers has increased, so too has the number of SSDs in storage increased. When most, if not all, of the drives in storage were mechanical, there was little chance of silent data corruption as long as the environment in the storage enclosure maintained reasonable thresholds. The same is not true for SSDs.
A stored SSD, without power, can start to lose data in as little as a single week on the shelf.
In my post for today, I will be discussing a vulnerability that I found within the TCP/IP driver as implemented by Microsoft within their Windows 2003 Operating System with Service Pack 2 installed (advisory here). If an attacker has obtained unprivileged access into the operating system, this vulnerability may be used to elevate their privilege to that of SYSTEM. This is accomplished by abusing a null near pointer dereference within code that runs during the processing of a specific unprivileged IOCTL call.
This vulnerability was issued identifiers: KL-001-2015-001, MS14-070, and CVE-2014-4076.
In order to avoid duplicating content from the advisory issued for this vulnerability, I will only provide a brief tl;dr before diving into the exploit.
The Giles production rule system compiler has just been released! It is available for download here.
Production rule systems (or "engines" in Giles parlance) are tools that are commonly used to efficiently find patterns in streams of data where any number of data items (or "facts") can be added or removed over time. They're very commonly used to perform complex behavior detection (i.e., event correlation), like fraud detection for credit cards via transaction history or multi-part attacks against servers via combined analysis of firewall and server logs. They can also be used to provide some form of artificial intelligence, forming the core of many expert systems and automated planners.
All that sounds great, but what is Giles?
UPDATE: Some have requested the actual JS used in this analysis, so here it is:
Since news of the Sony hack broke, a number of reports have been pointing to North Korea as the source of the compromise. Part of the reasoning that North Korea is to blame is undoutedly because the malware recovered from the compromise, and subsequently made available on a number of malware analysis websites, had internal resources that had the Korean language. While the languages associated with Windows resources on executables can be used for attribution, this post will show that they should not be singularly relied upon.
Disclosure: KoreLogic is not involved with this investigation, nor do we have any inside knowledge. This post is based on the public information available and our experience and expertise.
During a recent review of the VMWare Workstation application, I discovered a method that allows any member of the __vmware__ group to extract arbitrary sections of kernel memory. When you consider the fact that members of this group are not required to already have administrative privileges, this suddenly becomes a significant vulnerability in the sense that it implies that otherwise unprivileged users now have the means to extract and subsequently use/abuse sensitive data like process-level tokens, encryption keys, etc. Needless to say, this poses a significant security risk to any organization that allows unprivileged users to operate virtual machines by way of the __vmware__ group.
To date, VMWare has declined to mitigate this vulnerability despite the detailed evidence we have provided and our repeated attempts to convince them that there is an underlying design flaw here that needs to be addressed. Also note that this vulnerability, officially documented here, has not been assigned a CVE identifier because MITRE declined to do so.
A few months ago I posted a high-level overview of some source code repository tampering risks.
The other day I presented a much deeper dive at BSides DC, with examples of multiple ways to manipulate CVS, Git, and Subversion repositories, and some thoughts on how companies and code-hosting sites could/should harden their infrastructures.
Watch the presentation, or download the slides. (PDF warning)
Watch for future blog posts that extract and expand upon some of those examples.
Thanks to the BSidesDC folks for a great conference, and to ComputeCycle for the recordings!
Check out the recent Huffington Post article The Big Password Mistake That Hackers Are Hoping You'll Make by Jeff Fox that talks about the need to "avoid a little-known mistake recently uncovered by password researchers" (i.e., the overuse of common password patterns (or topologies) by users as they create their passwords). This article references some of the conclusions that came out of our PathWell (Password Topology Histogram Wear-Leveling) project, which was sponsored by DARPA (Defense Advanced Research Projects Agency) in 2013 under its Cyber FastTrack program. Stay tuned for more PathWell-related news as we are preparing to release the software developed for that project in the near future.
Recently, we came across the BthPan.sys driver while researching Microsoft's Bluetooth implementation within 32-bit Windows XP (SP3), and after conducting a number of fuzzing tests, we discovered that this driver has a vulnerability known as a write-what-where condition. It should be noted that the BthPan.sys driver is not enabled or even installed by default. Thus, the attack described below will only function if the end user or operating system administrator has installed the driver, such as via 'Add/Remove Programs' within the Control Panel, or installing some hardware driver that implicitly enables it.
Despite repeated breaches of password repositories, most recently the rumored cause of the Apple iCloud celebrity image theft, password-based authentication remains the norm for most users even though solutions like multi-factor authentication offer superior protection. Not only are user accounts at risk, but more importantly, so are their data. More often than not, default passwords have been the root cause of multiple high-profile system and company compromises. As with any recurring, successful attack, the bar must be raised to prevent the inevitable question from management: "This attack is well known, so why didn't we prevent it?"
Version 3.11.0 is a minor release of FTimes. Generally, code was cleaned up and refined as necessary. Several bugs have been fixed -- see the ChangeLog for details. This release introduces file hooks support for an embedded Python interpreter. Finally, a new tool, ftimes-bimvl, has been added to the project.
Version 1.2.0 is a minor release of KLogTail. Generally, code was cleaned up and refined as necessary. Several bugs have been fixed; all warning and error messages have been enhanced to facilitate post-processing by log analysis tools; a basic man page has been added; and the project has been completely restructured to use autoconf/automake for the configure/build process.
Consider this security scenario: Attackers gain access to developer or sysadmin accounts. They find and target the revision control system that is used to manage system configurations, internal code, or even software that is shipped to customers. The attackers use the compromised accounts to modify the source code and insert back doors or logic bombs. Now ask this question: How long will it take the organization to notice?
This scenario may seem far-fetched, but think about all of the breaches of software vendors you've read about: Adobe, the victims of Aurora, APT1, etc. Who says they only had their code read?
Recently, KoreLogic examined a number of malware downloaders that use API callback functions to redirect the flow of execution and make malware analysis more difficult. While this is not a new technique our research did not find many public resources discussing this topic. The purpose of this blog post is to describe KoreLogic's analysis on what callback functions are, how malware uses them, and how this technique can be detected and analyzed.
Over the last few weeks, a number of updates have been pushed to the dev version of MASTIFF located in the Git repository. One of these updates is a major change to the analysis plug-in architecture.
Also, due to the Heartbleed bug that everyone has been dealing with, we updated the SSL certificates on the Git server. Unfortunately, this seems to be causing an issue with Debian and Ubuntu based clients. Update: We deployed a server-side workaround; details below.
The updates, and the fix to the Git issue, are described below.
This weekend at Infosec SouthWest 2014 KoreLogic's Crack Me If You Can (CMIYC) team ran a mini-CMIYC contest for the people attending the conference. The prize was a $100 dollar gift card.
We made the challenge pretty simple, with 1-2 hashes that were a little bit harder.
The winner was Scot Perkins. Congratulations to the winner! Here are the hashes we posted if you want to play along after the fact:
As previously discussed at multiple conference and in this blog, KoreLogic worked on the PathWell project for the DARPA Cyber Fast Track program. PathWell identifies and blocks common passwords based upon common password topologies and learned user behavior.
Watch a presentation on PathWell, or download the slides here.
The PathWell software is not yet public, but people have frequently asked us to publish the list of the most popular topologies within enterprises that we compiled during that research. So, that is what we are doing today.
In order to make new development versions of MASTIFF available to the masses, KoreLogic has set up a Git server. This repository can be accessed at https://git.korelogic.com/mastiff or the repository can be cloned with:
git clone https://git.korelogic.com/mastiff.git
On January 20, I will be giving a talk at ShmooCon Epilogue on PathWell, a project we did last summer. Epilogue is a great event and is much easier to get tickets for than ShmooCon, and I highly recommend it. (And I said that before they accepted my talk ;)
Over the past couple of years, we - mostly my coworker Rick Redman (Minga) - have given many talks about how enterprise password strength enforcement rules, as currently implemented, are broken and harmful. They make enterprise passwords easy to crack. The only thing worse than having them is not having them.
PathWell ("Password Topology Histogram Wear-Leveling") introduces a new dimension for measuring and enforcing enterprise password strength that attempts to take away from the attacker the advantages that they currently have when cracking (or even just flat-out guessing blindly) an enterprise's passwords.
|Please contact us if you would like more information about our services, tools, or careers with us.|