Quick PHP Malware vs AV Update

It’s been a while since I checked on the status of PHP malware versus anti-virus. So, here is a quick catch up post. (I’ve been talking about this for a while now. Here is an old example.)

I took a randomly selected piece of PHP malware from the HITME and checked it out this afternoon. Much to my surprise, the malware detection via AV has gotten better.

The malware I grabbed for the test turned out to be a multi-stage PHP backdoor. The scanner thought it was exploiting a vulnerable WordPress installation. 

I unpacked the malware parts into plain text and presented both the original packed version from the log and the unpacked version to VirusTotal for detection testing. As you know, in the past, detection of malware PHP was sub single digits in many cases. That, at least to some extent has changed. For those interested, here are the links to see what was tripped.

Decoded to plain text vs Encoded, as received

As you can see, decoded to plain text scored a detection of 44% (19/43), which is significantly improved from a year or so ago. Additionally, excitingly, undecoded, the attack in raw form triggered a detection rate of 30% (13/44)! The undecoded result is HUGE, given that the same test a year or so ago often yielded 0-2% detection rates. So, it’s getting better, just SLOWLY.

Sadly though, even with the improvements, we are still well below half (50%) detection rates and many of the AV solutions that fail to catch the PHP malware are big name vendors with commercial products that organizations running PHP in commercial environments would likely be depending on. Is your AV in the missing zone? If so, you might want to consider other forms of more nuanced detection

Now, obviously, organizations aren’t just depending on AV alone for detection of web malware. But, many may be. In fact, a quick search for the dropped backdoor file on Google showed 58,800 systems with the dropped page name (a semi-unique indicator of compromise). With that many targets already victim to this single variant of PHP backdoors, it might be worth checking into if you are a corporate PHP user.

Until next time, take a look around for PHP in your organization. It is a commonly missed item in the patch and update cycles. It also has a pretty wide security posture with a long list of known attack tools and common vulnerabilities in the coding patterns used by many popular products. Give any PHP servers you have a deeper inspection and consider adding more detection capability around them. As always, thanks for reading and stay safe out there! 

3 Tough Questions with Bill Sempf

Recently, I caught up over email with Bill Sempf. He had some interesting thoughts on software security, so we decided to do a 3 Tough Questions with him. Check this out! :

 

A short biography of Bill Sempf: In 1992, Bill Sempf was working as a systems administrator for The Ohio State University, and formalized his career-long association with inter-networking. While working for one of the first ISPs in Columbus in 1995, he built the second major web-based shopping center, Americash Mall, using Cold Fusion and Oracle. Bill’s focus started to turn to security around the turn of the century. Internet driven viruses were becoming the norm by this time, and applications were susceptible to attack like never before. In 2003, Bill wrote the security and deployment chapters of the often-referenced Professional ASP.NET Web Services for Wrox, and began his career in pen testing and threat modeling with a web services analysis for the State of Ohio. Currently, Bill is working as a security-minded software architect specializing in the Microsoft space. He has recently designed a global architecture for a telecommunications web portal, modeled threats for a global travel provider, and provided identity policy and governance for the State of Ohio. Additionally, he is actively publishing, with the latest being Windows 8 Application Development with HTML5 for Dummies.

 

Question #1: Infosec folks have been talking about securing the SDLC for almost a decade, if that is truly the solution, why haven’t we gotten it done yet?

For the same reason that there are still bugs in software – the time and money necessary to fix things. Software development is hard, and it takes a long time and lots of money to write secure software. Building security in to the lifecycle, rather than just waiting and adding it to the test phase, is just prohibitively expensive.

That said, some companies have successfully done it. Take Microsoft for instance. For a significant portion of their history, Microsoft was the butt of nearly every joke in the security industry. Then they created and implemented the MSDL and now Microsoft products don’t even show up on the top 10 lists anymore. It is possible and it should be done. It’s just very expensive, and companies would rather take on the risk than spend the money up front.

Question #2: How can infosec professionals learn to better communicate with developers? How can we explain how critical things like SQL injections, XSS and CSRF have become in a way that makes developers want to engage?

There are two fronts to this war: the social and the technical. I think both have to be implemented in good measure to extract any success.

On the social side, infosec pros need to get out of the lab, and start talking at developer conferences. I have been doing this as a good measure since 2010, and have encouraged other community members to do the same. It is starting to work. This year at CodeMash, Rob Gillen and myself gave a day long training on everything from malware analysis to Wi-Fi to data protection. The talk was so popular that we needed to be moved into a bigger room. Security is starting to creep into the developers scope of vision.

Technically, though, security flaws need to be treated just like any other defect. The application security test team needs to be part of QA, treated just like anyone else in QA, given access to the defect tracking system, and post defects against the system as part of the QA process. Until something like the Microsoft SDL is implemented in an organization, integrating security testing with QA is the next best thing.

Question #3: What do you think happens in the future as technology dependencies and complexities ramp up? How will every day life be impacted by information security and poor development/implementations?

More and more applications and devices are using a loosely connected model to support fast UIs and easy functional development. This means more and more business functionality exposed in the form of SOAP and REST services. These endpoints are often formerly internal services that were used to provide the web server with functionality, but are gradually being exposed in order to support mobile applications. Rarely are they fully tested. In the short term future, this is going to be the most significant challenge to application security. In the long term, I have no idea. Things change so fast, it is nearly impossible to keep up.

 

Thanks to Bill for sharing his insights. You can discuss them with him on Twitter, where he is @sempf. As always, thanks for reading!

Quick Thought on CSRF Attacks

Yesterday, I listened to @Grap3_Ap3 present at the Columbus OWASP local chapter on Cross Site Request Forgery (CSRF). While this attack has been around since 2001, it continues to show a strong presence in web applications across a range of platforms. Phil spent a lot of his time talking about content management systems on the public Internet, but we have seen CSRF very widely exploitable on embedded devices.

Embedded devices, often equipped with rather rudimentery web servers and applications for management, have proven to be a searing hot pain point for CSRF in our research. While that isn’t shocking or new, I definitely see an interesting and potentially dangerous collision between the growth of the “Internet of Things” and web vulnerabilities. Today, some of these platforms are toys, or novelty tools built into home appliances – BUT, the future of internetworking of our devices and our physical lives means that these web controls will eventually have larger impacts on our day to day lives.

What happens when a CSRF attack can be used to trick your teenager into clicking on a picture on the web that while they view it, they also execute a command to raise the temperature on your refrigerator to unsafe levels? Or when an embedded link in an email tricks you into a click that turns your oven onto super heat clean mode without your knowledge? Sound like a prank? Maybe. Extend it to thermostats, home automation and consumer control over alternative energy controls like solar panels and such and it might take a new form.

We are on a course of collision. Our inattention to information security and the exploding complexity and technology dependencies will soon come together in ways that may surprise us. Ignore the hyperbole, but think about it rationally. Isn’t it time we worked with organizations who make products to demand an increase in protection from some of these basic known attacks? In the future, consumers and organizations alike will vote with their dollars. How will you spend yours?

Java 0-Days are Changing Corporate Use Patterns

With all of the attention to the last few Java 0-days and the market value for them falling them (which many folks believe indicate there are more out there and more coming), we are starting to hear some organizations change their policies around Java, in general. 

It seems some clients have removed it from their default workstation images, restricting it to the pile of as-needed installs. A few have reported requiring more frequent Java update settings and a couple have talked about switching in-house development away from Java to different languages. 

Is your organization changing the way you view Java? How are things changing around the IT shops you work with? 

Drop us a line in the comments or via Twitter (@microsolved or @lbhuston) and let us know what YOU think!

Ask The Experts: Getting Started with Web App Security

Question from a  reader: What should I be paying attention to the most with regards to web applications? My organization has a number of Internet facing web applications, but I don’t even know where to start to understand what the risks and exposures might be.

Adam Hostetler responds:

The first thing I would do is to identify what the applications are. Are they in house developed applications, or are they something like WordPress or another framework? What kind of information do they store (email addresses, PII, etc)? If they are in house or vendor applications, have they been assessed before? With a little knowledge of the applications, you can start building an understanding of what the risks might be. A great resource for web application risks is the OWASP project. https://www.owasp.org

Phil Grimes adds:

When it comes to web applications, I always promote a philosophy that I was raised on and continue to pound into my kid’s heads today: Trust but verify. When an organization launches an internet facing application there is an immediate loss of control on some level. The organization doesn’t know that the users accessing the application are who they say they are, or that their intentions are “normal”. Sure, most people who encounter the app will either use it as intended or if they access the app inadvertently, they may just mosey on about their merry way. But when a user starts poking around the application, we have to rely on the development team to have secured the application. Making sure identity management is handled properly will help us ensure our users are who they say they are, and validating all data that a user might pass to the application becomes an integral part of security to ensure possible attacks are recognized and thwarted.

John Davis comments:

I would say that the most important thing is to ensure that your Internet facing web applications are coded securely. For some time now, exploiting coding weaknesses in web applications has been one of the leading attack vectors exploited by cyber criminals to compromise computer networks. For example, poor coding can allow attackers to perform code injection and cross site scripting attacks against your applications. The Open Web Application Security Project (OWASP), which is accessible on the Internet, is a good place to learn more about secure web application coding techniques. Their website contains lots of free tools and information that will help your organization in this process. There are also professional information security organizations (such as MicroSolved) that can also provide your organization with comprehensive application security assessments.

As always, thanks for reading and let us know if you have questions for the experts.

ProtoPredator to Become Family of Products

On Nov 16, we announced the availability of ProtoPredator for Smart Meters (PP4SM). That tool, aimed at security and operational testing of optical interfaces, has been causing quite a stir. Lots of vendors and utilities have been in touch to hear more about the product and the capabilities it brings to bear.

We are pleased with the interest in the PP4SM release and happy to discuss some of our further plans for future ProtoPredator products. The idea is for the ProtoPredator line to expand into a family of products aimed at giving developers, device designers and owners/operators a tool set for doing operational and security testing. We hope to extend the product family across a range of ICS protocols. We are currently working on a suite of ProtoPredator tools in our testing lab, even as we “scratch our own itch” and design them to answer the needs we have in performing testing of SmartGrid and other ICS component security assessments and penetration tests.

Thanks to the community for their interest in ProtoPredator. We have a lot more to come and we greatly appreciate your support, engagement and feedback.

ProtoPredator for Smart Meters Released

Today, MicroSolved, Inc. is proud to announce the availability of their newest software product – ProtoPredator™ for Smart Meters (PP4SM). This tool is designed for smart meter manufacturers, owners and operators to be able to easily perform security and operational testing of the optical interfaces on their devices.

PP4SM is a professional grade testing tool for smart meter devices. Its features include:

  • Easy to use Windows GUI
  • Easy to monitor, manage and demonstrate testing to management teams
  • Packet replay capability empowers testers to easily perform testing, verification and demonstrations
  • Manual packet builder 
  • Packet builder includes a standards compliant automated checksum generator for each packet
  • Automated packet session engine 
  • Full interaction logging
  • Graphical interface display with real time testing results, progress meters and visual estimations
  • Flexibility in the testing environment or meter conditions

The tool can be used for fuzzing smart meter interactions, testing protocol rule enforcement, regression testing, fix verification and even as a mechanism to demonstrate identified issues to management and other stakeholders. 

ProtoPredator for Smart Meters is available commercially through a vetted licensing process. Licenses are available to verified utilitiy companies, asset owners, asset operators and manufacturers of metering devices. For more information about obtaining PP4SM or to learn more about the product, please contact an MSI account representative. 

More information is available via:

Twitter: @lbhuston

Phone: (614) 351-1237 ext 206

Email: info /at/ microsolved /dot/ com (please forgive the spam obfuscation…) 🙂

What Is Your Browser Leaking?

Today in my tweet stream, someone pointed out this site and I wanted to blog about it. The site is called stayinvisible.com and offers a quick view of some of the data that is available to a web site or an attacker who can lure someone to a website. 

The site displays a dump of a variety of common data that you might not be aware of that is leaking from your browser. There are also tips for hardening your browser settings and operating system against some of the methods used to dump the data. 

If nothing else, it might just provide an “ah ha” moment for folks not used to the information security space. Give it a try and let us know what you think of it. 

We have no association with the site, its content or the folks who run it. We just thought it was interesting. Your paranoia may vary. 🙂

Surface Mapping Pays Off

You have heard us talk about surface mapping applications during an assessment before. You have likely even seen some of our talks about surface mapping networks as a part of the 80/20 Rule of InfoSec. But, we wanted to discuss how that same technique extends into the physical world as well. 

In the last few months, we have done a couple of engagements where the customer really wanted a clear and concise way to discuss physical security issues, possible controls and communicate that information to upper management. We immediately suggested a mind-map style approach with photos where possible for the icons and a heat map approach for expressing the levels of attack and compromise.

In one case, we surface mapped a utility substation. We showed pictures of the controls, pictures of the tools and techniques used to compromise them and even shot some video that demonstrated how easily some of the controls were overcome. The entire presentation was explained as a story and the points came across very very well. The management team was engaged, piqued their interest in the video and even took their turn at attempting to pick a couple of simple locks we had brought along. (Thanks to @sempf for the suggestion!) In my 20+ years of information security consulting, I have never seen a group folks as engaged as this group. It was amazing and very well received.

Another way we applied similar mapping techniques was while assessing an appliance we had in the lab recently. We photographed the various ports, inputs and pinouts. We shot video of connecting to the device and the brought some headers and tools to the meetings with us to discuss while they passed them around. We used screen shots as slides to show what the engineers saw and did at each stage. We gave high level overviews of the “why” we did this and the other thing. The briefing went well again and the customer was engaged and interested throughout our time together. In this case, we didn’t get to combine a demo in, but they loved it nonetheless. Their favorite part were the surface maps.

Mapping has proven its worth, over and over again to our teams and our clients. We love doing them and they love reading them. This is exactly how product designers, coders and makers should be engaged. We are very happy that they chose MSI and our lab services to engage with and look forward to many years of a great relationship!

Thanks for reading and reach out on Twitter (@lbhuston) or in the comments if you have any questions or insights to share.

MicroSolved Lab Services: A Secret from Behind the Locked Doors

One of the oddest, most fun and most secretive parts of MSI is our testing lab services. You don’t hear a lot about what happens back there, behind the locked doors, but that is because of our responsible disclosure commitments. We don’t often talk publicly about the testing we do in the lab, but it varies from testing unreleased operating systems, applications, hardware devices, voting mechanisms, ICS/SCADA equipment, etc. We also do a small amount of custom controls and application development for specific niche solutions. 

Mostly though, the lab breaks things. We break things using a variety of electronic tools, custom hardware, bus/interface tampering, software hacking, and even some more fun (think fire, water & electric shock) kinds of scenarios. Basically, whatever the threat model your devices or systems face, most of them can be modeled, examined, tested, simulated or otherwise tampered into place in the MSI labs.

Our labs have several segments, with a wide array of emulated environments. Some of the lab segments are virtualized environments, some are filled with discreet equipment, including many historical devices for cross testing and regression assessments, etc. Our electronics equipment also brings a set of capabilities for tampering with devices beyond the usual network focus. We often tamper with and find security issues, well below the network stack of a device. We can test a wide range of inputs, outputs and attack surfaces using state of the art techniques and creatively devious approaches.

Our labs also include the ability to leverage HoneyPoint technology to project lab tested equipment and software into parts of the Internet in very controlled simulations. Our models and HoneyPoint tools can be used to put forth fake attack surfaces into the crimestream on a global basis and identify novel attacks, model attack sources and truly provide deep threat metrics for entire systems, specific attack surfaces or components of systems. This data and the capabilities and techniques they are based upon are entirely proprietary and unique to MicroSolved.

If you would like to discuss how our lab services could assist your organization or if you have some stuff you want tested, get in touch. We would love to talk with you about some of the things we are doing, can do and some of the more creatively devious ideas we have for the future. 🙂

Drop us a line or give us a call today.  We look forward to engaging with you and as always, thanks for reading!