About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

MicroSolved, Inc. Announces the Immediate Release of NED Alpha

That’s right! No longer do you have to spend days and nights worrying about the state of your network. No more fretting about your partners, security or other traditional concerns.

Today is the dawn of a new day for network engineers around the globe!

Want to know how your network is? ASK YOUR PACKETS!!!!!

MicroSolved’s revolutionary new product, code named, NED or Network Emotion Detector, will continually update you on the emotional health of your packets. If there’s a network problem, a security breach or if you happen to fall out of compliance with the Pennsylvania Concrete Institute’s (PCI) standards, your NED will immediately alert your team to the lack of happiness being experienced by your packets as they traverse the various public and private networks!

wpid-NEDShot.82HVMJmrrSV4.jpg

Even more powerful than the executive dashboard, the GUI can be operated near the data center hallway window, so passing executives can quickly identify the happiness quotient (TM) of your network. When they see NED smiling, they will know you are doing your job well. When NED is unhappy and your packets begin to show signs of sadness, they can quickly and easily purchase additional “emotional credits” through the handy interface. These emotional credits (ie: money) make your packets happy and joyous as they traverse the Intertubes.

If that were all NED did, it would still be the most powerful network emotional monitoring tool on the market, but we even take it one step further! Using NED’s soon to be copylefted capabilities, we create emotional tunnels for your packets to move back and forth with your peers. These “Virtual Private Hugs” (VPH) allow you and your business partners to mutually enjoy all the power of NED and emotional credits together. You can easily monitor the happiness of your partner’s packets and those that show emotional disparity, making VPH even more important for those folks. Lastly, NED features a peer-to-peer network monitoring mechanism that allows you to closely monitor the overall happiness level around the Cloud. That’s right, MSI is the first in the world to create Happiness as a Service (HaaS)(TM)!

Act now and you can get your own copy of NED for Windows FREE for a limited time. Download from here and start enjoying the ease and joy of NED from MSI. We hope you enjoy NED, “because packets need love too…”

Happy April Fools Day from your security partners at MicroSolved, Inc. We hope it made you smile. BTW – The download really runs. Windows only, for now…. :p

Updated PHP RFI Slides with Code Examples

Thanks to the folks who joined us for this afternoon’s PHP security talk about modern RFI attacks, how they work and what attackers are up to. If you are interested in the new slide deck, you can find them here: http://bit.ly/bT2TF7

If you would like to attend a virtual presentation or book one of our engineers to give the talk for your development team (either virtually or face to face), drop me a line and let me know. The talk is very strong and lends itself well to understanding how PHP RFI has become one of the most common attack vectors in use to spread malware, bots and other illicit activity.

Another Close Up with Anti-Virus Tools

In the last few days, the folks that make sub7, a pretty common and well known Windows back door/remote access tool, released a new version. You can find more about the capabilities of this application here.

Since I have been doing a bit of research lately that has included anti-virus and their often abysmal detection rates, I decided to test this new version of Sub7 against the VirusTotal scanning base. You can find the results here.

As you can see, the detection rates for this “remote access tool” is just under 55%. This time, all three of the major enterprise vendor products catch the malware nature, but the most common free tool, AVG, misses it entirely. As such, organizations are likely protected, but a vast many home user and consumer machines will be unable to detect the install of this very common attacker tool.

As with many of the posts about this in the past, I simply point this out to folks to help them come to an understanding of the true levels of protection that AV offers. Many people see it as a panacea, but clearly, it is not. AV is a needed part of defense in depth, but additional controls and security tools are required to create effective detection for malware infections.

Catching PHP RFI Infected Hosts with Log Greps

I posted details here along with a current list of PHP RFI drop hosts that are being used to compromise web servers with vulnerable code.

You can use the list along with grep/regex to scan your outbound web/firewall/proxy logs for web servers that are likely infected with bot code from the scanners using these sites.

The link to the list and such is here: http://hurl.ws/cf5s

This data was entirely generated using captured events from the last several weeks by the Honeypoint Internet Threat Monitoring Environment (#HITME). You can find more information about HoneyPoint here.

If you would like to learn more about PHP RFI attacks, please feel free to drop me a line, check out @lbhuston on Twitter and/or give my RFI presentation slides a look here. If you would like to schedule a presentation or webinar for your group on PHP RFI, HoneyPoint or PHP/web application security testing, please give us a call at 614-351-1237 x206.

As always, we appreciate your reading State of Security and we hope you make powerful use of the information here.

AV Versus Old and New Bot Code

Today, in my research work on the data from the HoneyPoint Internet Threat Monitoring Environment (HITME), I uncovered an old (2008) piece of PERL code embedded inside a PHP bot-net infector client that I discovered from the HITME logs. This perl code was included in the PHP bot as a base64 string, which is quite common. The PHP code unencodes the perl script and drops it on your hard disk when the PHP bot herder wants to have a reverse shell to execute commands on your system.

In this case, the placement of the PHP bot was via PHP Remote File Injection, so the malware would be placed on your victimized web server. For enterprises, that means that if your web server got hacked in this way, then you would expect your anti-virus to be the last line of defense for protecting you against this malware.

Here’s where it gets weird. AV detection was absolutely horrible for both of these pieces of code. For the perl backdoor, the detection rate at VirusTotal was just 55% and that code has been known for years. For the PHP bot, in its entirety, the total was even worse with detection rates of just 46%.

Even worse to me than the percentages are the vendors that caught vs missed these simple scripts. Check the list for your AV vendor, because I was shocked to see that some of the big name, enterprise class products missed these forms of malware entirely. Some of the small freeware vendors we might expect to miss some of the malware targeted at servers, but I would think we should expect more from the enterprise AV vendors, especially if you read the hype of their marketing.

Now, a lot of folks are going to say, of course AV misses stuff. There’s polymorphic code out there, Brent, and a lot of the bad guys have really spent a ton of resources to obfuscate and modify their code on the fly. I agree with this. But, in this case, we are not talking about custom designed binary code with trapdoors, memory injection, polymorphism or anything of the like. These are simple script files, in plain text. Neither of them is obfuscated. You can see the PERL back door code for your self. I just published it on my Posterous blog for supporting materials. I think after you check that out, you can see that the “complex malware code” argument, just doesn’t hold water in this scenario.

The bottom line is this, your AV software and other mechanisms that are heuristics based are likely not doing the job of protecting you that you might imagine. Just something to keep in mind when you do your next risk assessment, threat model or the like.

Thanks for reading!

What Helps You with PCI?

Yesterday, at RSA much press attention was paid to a metric that 41% of all organizations tested needed temporary compensating controls to meet even the minimum security provided by PCI DSS compliance.

This led us to this discussion. If so many organizations need temporary controls to do the minimum, then what controls, in your experience, are the most worthwhile for those struggling to meet PCI?

Please leave a comment and tell us what controls you find most useful, easiest to leverage and worth the investment for PCI compliance.

As always, thanks for reading and we look forward to your input.

Quick Metrics from the HITME

I just posted this on Twitter:

The #HITME caught 1,684 new unique probes last week. That’s about 10 unique probes per hour or one unique probe every 6 minutes on avg.

Interesting idea that some sort of entropy in attacker signatures happens that often on average. Every 6 minutes some nuance of an attack pattern changes and we see it in the HITME data. Sure, some of these are encoding changes, slight modifications, but some are new scanning targets, new payloads and entirely new strains of attack and probe activity.

With attack patterns changing so rapidly, are you really sure your heuristics-based tools and approaches are able to keep up? Remember, too, this is just server/application viewpoint data. It has nothing to do with the threat entropy that a client application like a browser encounters. Those metrics, in my opinion, are likely to be exponentially higher if we could ever find a way to measure them in a meaningful way.

PHP RFI: Old Attack, Common #FAIL

I just completed the slides for my new presentation on application security. It is focused on understanding Remote File Include attacks against PHP implementations.

The preso covers what they are, how common they are, metrics, signatures, code examples and guidance for finding and mitigating them.

If there is interest, I will try and either record audio or video of the presentation and post that separately. If you would like to see/hear that in the near future, leave a comment below.

This research and the resulting project were made possible by two facets of MicroSolved, Inc. that we don’t talk a lot about, so here is some info on the power behind this project.

The first, is our application security assessments. We have really been focusing on these projects recently and my team has been working hard to complete assessments for clients, as well as a variety of open source/community tools. As a part of our deep lab capability here and our relationship with Syhunt, in Brazil, we have been working together to test and improve their Sandcat4PHP and Sandcat Pro products (which we distribute/resell for them in the US). Essentially, this gives us a very deep capability to “grey box” test PHP applications. For those unfamiliar with grey box testing, that means that the tools and engineers have both access to the source code (white box) and a useable testing version implementation (black box). Combined, this testing methodology creates a very robust, accurate and thorough capability to exercise and examine an application. Manual and automated assessments intertwine to achieve maximum width and depth of assessment.

The second facet that powered this project was the HoneyPoint Internet Threat Monitoring Environment (HITME). This is a rapidly-growing network* of HoneyPoint deployments donated to MSI for the purpose of gathering attack data. The HoneyPoint agents are deployed in a variety of international locations to give us a real-time, global view of attacker sources, frequency and tactics for our research projects. The HITME is a unique capability to MSI and brings us data that most other security organizations can only dream of. In turn, we take the gathered knowledge and give it back to the security community in presentations and projects like this and the @honeypoint/#HITME feeds on Twitter and use it to protect our clients against an ever-growing arsenal of threats.

Combined, these capabilities have helped us identify hundreds of new PHP RFI attack signatures (which we plan to release shortly), find privately released PERL and PHP attack code/bot-net infectors (shared with the AV & IDS/IPS vendors) and build this presentation for the security community.

It also opened our eyes to just how popular PHP has become and how large the footprint is in corporate organizations and businesses around the world. In a recent survey, about 50% of the polled population stated that they did not have PHP in their enterprise, but did indicate that they use some combination of WordPress, Drupal, Joomla, Moodle, etc. All of these technologies are written in and utilize PHP! To the MSI team, this represents another area where the underlying technology is not understood in our corporate networks. This is another “unknown” for the attacker to leverage.

I hope you enjoy the presentation slides and I look forward to presenting this in public. If you would like to discuss more about our application security capabilities or the HITME, please let me know.

* Organizations and individuals can donate the operation of an Internet facing HoneyPoint Agent to MSI. Depending on the situation, they may receive a free license for HoneyPoint or the HoneyPoint Managed Service for their organization or home network. If you think you might be interested, please let me know and we can discuss how we might be able to work together.

Why I No Longer Have a Login at ISACA.org

After much conversation with the folks who manage the ISACA.org site and quite a bit of frustration trying to reach the people responsible for the site within ISACA, I had a good discussion with them last night and they have removed my login credentials by my request. While I have been and continue to be a supporter and member of ISACA, I disagree with them over this particular issue.

The problem is that the ISACA.org password reset mechanism sends your password in clear text to your registered email address. An attacker, or anyone, only needs to know or guess a user name to cause the system to send the password. If an attacker initiates this process and can gain access to the email system or the email itself in transit, then they gain access to a live, user generated password.

The threat model for this is obvious and commonly exploited. Users, even security folks, often re-use the same passwords around the Internet for a variety of sites. If the attacker can gain the password by exploiting this mechanism, then it becomes easy to try and leverage those credentials on a myriad of sites and accounts. Similar attacks have been quite popular lately and have proven effective for high level compromises on social media, e-commerce and other popular sites.

When I explained the problem to the web manager, he did not disagree with either the risk or the attack vectors. He only explained that they had known of the problem for a year or so and that their mitigation was to launch a new web site. He assured me the new site would be ready within a few months. He explained that the new site, in accordance with current best-practices, would include a new reset mechanism for passwords that used a token URL link or the like instead of a plain text password. I suggested that they remove the current mechanism from use until then and he said they would explore that as an option.

My main point on this issue is that I expect more from ISACA. I expect that since they are teaching the world to audit systems and processes for security, that they themselves would have secure processes. I especially have a hard time accepting that they knew of this problem for a year and chose to accept the risk without any additional controls being implemented, thereby placing the residual risk squarely on the shoulders of their members. To make matters worse, they transferred this risk to the membership without so much as a reminder or disclosure statement on their site about the problem. I understand that they may have resource constraints around managing the site, as he explained,   but these are the same issues that all organizations face, including the very organizations their training teaches people not to accept this explanation from.

While the discussion was amiable and professional, I am left with my disappointment. I got no assurances that anything would be done differently until the new site is launched and I got no sense for how that new site will be peer tested, reviewed or the like. Thus, I asked them to remove my account until that time. This is also the reason I am making this post. I want all ISACA members to be aware of the risk and that their credentials could potentially be exposed. Hopefully, none of the membership reuses their password around the web, but that seems unlikely. At least now, if they read this blog post, they will be aware.

Please feel free to let me know your thoughts on this issue by leaving a comment below. You can also contact ISACA by phone. Their numbers are listed in the contact us portion of their website.

Lastly, I want to say that I continue to support ISACA and their membership. I think their mission is critical and that their training is a strong positive for the security community and the world at large. As always, thanks for reading!

Interesting Bot News

In the last couple of days, there have been a couple of interesting pieces of bot-net news.

This one, discusses how a bot-net software war is brewing over control of your PC. Some bots are now including kill code for other bots. In this case, the new kid on the block is killing zeus code to make sure it has sole control over your fraud.
Then there was this one about ms10-015 where the bot authors have fixed their rootkit code to make the BSOD go away. They did this not as a favor to MS or anything, but to restore use of the PCs and their chain of fraud. They also wanted to cover up their own code to keep users from cleaning it.
Interesting stuff around the bot threat landscape….