Tag Archives: threats

Passwords, Dinosaurs, and 8-Track Tapes

Posted on by
Reply

What do passwords dinosaurs and 8 track tapes all have in common? Pretty soon they will all be in the same category: things of the past! It’s not just a matter of people using short, simple, “stupid” passwords any more. With advances in easily available and cheap computing power such as advanced graphics processors and solid state drives (SSDs), even long and complex passwords can be cracked in seconds! Not to mention the fact that if you get hacked and someone installs a keylogging Trojan on your machine, it doesn’t matter how long and complex a password you use; it’s game over!

There are always big concerns about the “exploit du jour” in the information security field. SQL injection, application hacks, XSS, Bots – you name it! But ever since the start the number one way computers get hacked is because of password problems. It’s still going on today! No matter what system one tests, it seems someone has a password of “password” or “admin” or something dumb like that. Or someone forgets to change a blank SA password or forgets to change the default password in some application. Then, of course, there are the system admins who use the same passwords for their user and admin accounts. Instant privilege elevation is given to domain admin and, once again, game over! This is really just a problem of human nature. We all have ambitions to follow the password policies exactly, to use strong passwords all the time, use different passwords for every account, change them on a regular basis, and never reuse the same ones twice, etc. But we all get lazy, or complacent or busy or forget or just screw up! Like I say – human nature.

What is the upshot of all this? Passwords alone as a security measure are hopelessly inadequate. And they always have been! So what is the answer? Well, obviously, we need to use something in addition to passwords. Ideally it would be preferable to use all three of the possible authentication techniques: something we know, something we have and something we are. But it’s hard enough to get people and organizations to consider even two of the three. There is TREMENDOUS resistance against insisting that everyone use tokens for example. And I can understand that. They cost money, you always have to remember to have them with you, they might break at the most awkward of moments, they can be stolen or they can be lost. Same thing with biometrics. They are expensive, they are not always reliable, they can be often be circumvented and they may leave you open to personal attack or even kidnapping! These are all real issues that need to be addressed and, what’s more, gotten used to. People are just going to eventually come to the realization that one or more of these techniques MUST be used. Until now, though, people have been willing to accept the consequences rather than bite the bullet and put up with the hassles and expense. The tipping point has yet to be reached. But, with identity theft, cyber crime and the increasing ease with which passwords can be stolen or broken that point is now very close indeed!

In the mean time, we all should REALLY do a much better job in using strong passwords. The new MINIMUM standard for passwords should be 12 characters and they should use at least three of the four possible character types. And that’s just for normal folks. For system admins and other high value access passwords alone should never be enough. These folks should surely be using multi-part authentication techniques no matter what the expense or hassle. After all, they DO hold the keys to the kingdom for all of us!

An Explanation of Our HoneyPoint Internet Threat Monitoring Environment #HITME #security

Posted on by
Reply

One of the least understood parts of MicroSolved is how the HoneyPoint Internet Threat Monitoring Environment (#HITME) data is used to better protect our customers. The engineers have asked me to drop this line into the newsletter and give you a “bees knees” perspective of how it works! First, if you don’t know about the #HITME, it is a set of deployed HoneyPoints that gather real world, real time attacker data from around the Internet. The sensors gather attack sources, frequency, targeting information, vulnerability patterns, exploits, malware and other crucial event data for the technical team at MSI to analyze. You can even follow the real time updates of attacker IPs and target ports on Twitter by following @honeypoint or the #HITME hash tag. MSI licenses that data under Creative Commons, non-commercial for FREE as a public service to the security community.

That said, how does the #HITME help MSI better protect their customers? Well, first, it allows folks to use the #HITME feed of known attacker IPs in a blacklist to block known scanners at their borders. This prevents the scanning tools and malware probes from ever reaching you to start with. Next, the data from the #HITME is analyzed daily and the newest, bleeding edge attack signatures get added to the MSI assessment platform. That means that customers with ongoing assessments and vulnerability management services from MSI get continually tested against the most current forms of attack being used on the Internet. The #HITME data also gets updated into the MSI pen-testing and risk assessment methodologies, focusing our testing on real world attack patterns much more than vendors who rely on typical scanning tools and back-dated threats from their last “yearly bootcamp”.

The #HITME data even flows back to the software vendors through a variety of means. MSI shares new attacks and possible vulnerabilities with the vendors, plus, open source projects targeted by attackers. Often MSI teaches those developers about the vulnerability, the possibilities for mitigation, and how to perform secure coding techniques like proper input validation. The data from the #HITME is used to provide the attack metrics and pattern information that MSI presents in its public speaking, “State of the Threat,” the blog, and other educational efforts. Lastly, but certainly not least, MSI provides an ongoing alerting function for organizations whose machines are compromised. MSI contacts critical infrastructure organizations whose machines turn up in the #HITME data and works with them to mitigate the compromise and manage the threat. These data-centric services are provided, pro-bono, in 99% of all of the cases!

If your organization would be interested in donating an Internet facing system to the #HITME project to further these goals, please contact your account executive. Our hope is that the next time you hear about the #HITME, you’ll get a smile on your face knowing that the members of my hive are working hard day and night to protect MSI customers and the world at large. You can count on us, we’ve got your back! 

AV Versus Old and New Bot Code

Posted on by
Reply

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!

Toata Scanning for Zen Shopping Cart with Brain File – Updated

Posted on by
1

If you’ve been a long time reader of this blog, then you know about our ongoing efforts to help stem the tide of web application infections. Here is another example of this effort in action.

A couple of days ago the HITME began tracking a series of new scans that are circulating from the Toata bot network. These new scans appear to be aimed at cataloging systems that are running the Zen shopping cart application. As per usual behavior of these tools, it appears that the cataloging is automated and then later, exploitation occurs from either another piece of code or human intervention.

ToataZenBrain102709.txt

Above is a link to a brain file for the Web application scanner that we produce called BrainWebScan. You can use this tool and the brain file above to scan your own servers for implementations of the Zen shopping cart. If you identify servers that have the Zen shopping cart installed, careful review of these systems should be conducted to examine them for signs of compromise. Reviews of the logs for the string “Toata” will identify if the system has already been scanned by this particular attack tool. However, other attack tools are being used that do not create specific named strings in the log files. The vulnerability that these tools are seeking to eventually exploit is unknown at this time, may be an old vulnerability or exploit, or could potentially be a new and previously unknown vulnerability.

Users of the Zen cart application are encouraged to ensure that they are following the best practices for securing the application. The application should be kept up-to-date and the Zen cart vendor website should be carefully monitored for future updates and known issues. Additional monitoring, vigilance and attention to servers running the Zen cart application should be performed at this time. It is probably not a bad idea to have these systems assessed for currently known vulnerabilities in their operating system, content management application and other web components.

If you would like assistance checking your web application or vulnerability assessment performed on your web application, please do not hesitate to contact us for immediate assistance.

PS: You can download BrainWebScan for Windows from here: http://dl.getdropbox.com/u/397669/BrainWebScan100Win.zip

Here are an additional set of gathered targets:

//zencart/includes/general.js
//zen/includes/general.js
//ZenCart/includes/general.js
//ZEN/admin/includes/stylesheet.css
//zen/admin/includes/stylesheet.css
//zen-cart/admin/includes/stylesheet.css
//zencart/admin/includes/stylesheet.css
//zc/admin/includes/stylesheet.css
//zshop/admin/includes/stylesheet.css
/zencart/install.txt
/zen-cart/install.txt
/zen/install.txt
/zcart/install.txt

Pandemic Planning Update: Consider 10 Day Minimums for Sick Time

Posted on by
Reply

Having just read this article, and participated in several discussions around Pandemic Planning, I am of the belief that folks might want to consider mandatory 10 day sick times/work from home times for H1N1 infected employees.

Research shows that infected folks may be contagious for up to 10 days from the onset of their symptoms, even after they “feel better”. The problem with this is that as they “feel better” they may return to work or school, thus exposing others to the virus, albeit, inadvertently. Many people simply think that if they “feel better”, then they must be over the infection and not contagious anymore.

So, as you consider your pandemic plans, please think about the idea of a 10 day work from home program or the like for folks that are symptomatic. Explanation and education of folks carrying the virus can only help, so take the time to explain this cycle to your team.

Thanks for reading and please let us know if you have any questions about pandemic planning or remote working issues. My team and I have been doing quite a bit of consulting lately reviewing pandemic plans and helping organizations make sure that they are prepared and that their remote access systems are robust enough to handle the load and secure enough to be trusted. If we can be of any help to your organization along these lines, please do not hesitate to call or drop us a line!

When The System Works, It Really Works! :)

Posted on by
5

OK gang, so here is our part of the story.

As many of you may now know, the NCUA issued a fraud alert this week based on a social engineering test we were doing for a client natural person Credit Union. You can find some of the materials at the following URLS:

NCUA Media Release

SANS Storm Center

NetworkWorld

Once we saw the alert from the NCUA, we immediately contacted our Credit Union client about the situation. The client had received the letter and CD set in the mail, just as intended and called for in their testing agreement. However, on their side, the person responsible for the penetration test was out the day the letter arrived. The receiver of the letter followed their incident response process and reported the suspicious activity to the NCUA Fraud Hotline, just as they are supposed to do.

Upon our contact with the CU, the entire situation became apparent and we quickly identified how the process had proceeded. The employee of the CU had followed the process, just as they should, and alerted the proper authorities to the potential for fraud. We immediately contacted the NCUA Fraud hotline and explained that the process was a part of a standard penetration test. Eventually, we talked with executive management of NCUA and offered them any information they desired, including the source code to the tools on the CDs. The NCUA was wonderful to work with, understood the situation and seemed appreciative of our efforts to help ensure that their members were meeting the requirements of NCUA 748, which calls for the protection of member data against illicit access, including social engineering attacks like these.

During our discussion with NCUA executive management, we discussed me reaching out to SANS and such to clarify the situation and to explain that the “attack” was simply a part of a penetration test. I did this as soon as I hung up the phone with NCUA. The handlers at SANS and I traded emails and phone calls and they amended their release to include the penetration testing scenario. The whole point of this was to add clarification and to prevent people from getting “spun up”, since there really was no ongoing attack in progress.

However, in typical Internet fashion, the story had already taken on a life of it’s own. The next thing we know, the press is picking up the story, there’s an article on slashdot and people are in alert mode. We then set about trying to calm folks down and such on Twitter, through email and such.

The bottom line here is this. This was a controlled exercise in which the process worked. The social engineering attack itself was unsuccessful and drew the attention of the proper authorities. Had we been actual criminals and attempting fraud, we would have been busted by law enforcement. The NCUA did a great job of getting the word out that such an attack had occurred and the media and security folks did a great job in spreading the word to prevent further exposures to this threat vector. Everyone, and I do mean everyone, is to be congratulated here for their efforts!

The system worked. Had we been bad guys, we would have been busted. The world was protected, once more, thanks to the vigilance and attention of the NCUA and the security community.

Now, about the testing. MicroSolved, Inc. does, indeed, test social engineering attack vectors as a part of our standard assessments. The social engineering threat is a powerful and valid attack vector that often leads to compromise. Our process for testing these engagements is well scoped, well organized and intensely controlled. The threats we emulate are very real (in this case, we even included typos and such in the fake letter). The simulated malware we use is a custom application, developed in house by my team of engineers and does not propagate in any way. It is safe, effective, tested and has been in use with ongoing revision and testing for more than five years. The entire process for testing social engineering has been performed thousands of times for thousands of clients and will continue to be a part of our testing methodology. We truly believe that information security starts and ends with the people involved in protecting the data.

I hope this answers any questions you may have about the process or the alert. If not, drop me a line at bhuston@microsolved.com and I will try and assist you, if I can. I would really like to thank the NCUA, SANS, my technical team and the customer CU for their help and attention on this project. Thanks also, to all of the security folks and CU folks who helped spread the word about this attack vector. Though the awareness campaign was unintended, it certainly has raised the bar for would be attackers if they hope to exploit this in the future. Thanks for all of your hard work and attention!

Oh, and lastly, no, it is not us sending the laptops to governors of the states. It might not even be us sending the next round of CDs, USB keys or whatever new fraud schemes emerge in the future. But, regardless of whether or not it is us doing a test for your organization, or real criminals attempting to exploit you, don’t fall for it! Report these events to the authorities and let’s make use of the process that we have clearly established!

Thanks for reading and make it a great day!

Update: Thanks to NetworkWorld for their help on getting the word out. Thanks to @alexhutton as well for this article.

Yay! A Winning Anti-Virus Check! Or Not…

Posted on by
Reply

So today on my RSS feeds, I saw that a new version of the Sub7 trojan has been released. This new version, called “legends” has some new features and such for exploitation and maintaining control over infected systems.

Being curious, I uploaded the installer to VirusTotal to see what kind of hit ratio I would get. To my surprise, ~96% of the AV software there detected Sub7!

There are two ways to look at this, I suppose. It sure seems like a victory when you get such a high hit rate, but on the other hand there are likely some elements of this extremely well known code that haven’t changed since it first emerged on the scene in the 90’s. So, I would hope that we could detect it with a high accuracy rate. In fact, I had really hoped we could detect it at 100%, but it seems that some AV vendors still miss it. Still 96% is far better than the ~15% detection rate I got on another test like this, just a little bit ago.

The second way to look at it is that we still have long known malware that is not detected by some AV products. Now, given, that is a small percentage, but after all of this time, they can not detect Sub7? That would be pretty horrible if you happen to be a customer of theirs and your data is at risk. Compound this with the data from the breach reports that show increases in custom malware being used in attacks and you can see the problem from a new perspective. If we can’t detect malware from the 90’s across the board, then how can AV hope to continue to be seen as the magic bullet defense against increasingly complex and dynamic attack code in the future? Of course, the answer is, it can not. It NEVER HAS BEEN THE MAGIC BULLET THAT MANY IT FOLKS AND MANAGEMENT FOLKS BELIEVE IT IS.

Where does that leave us? Somewhere between victory and defeat? Right where we have always been, but maybe, just maybe, with a little more argument and knowledge for those “magic bullet” folks!

PS – Here is my VirusTotal submission if you want to check it out.

Risk Assessment and Mitigation for the MS Web Office Issue

Posted on by
Reply

Here is a PDF of the risk assessment and review of this emerging vulnerability. Please check it out if you are working on mitigating this issue.

While the corporate risk is identified as an overall medium, there is a high risk of workstation infection from this problem.

Check out the document here.

Vuln RA 071409 – MS Web Office 0-day

If you would like to follow the emerging threat, the SANS Internet Storm Center is the best place to get current news about the outbreaks and exploitation. You can also follow me (@lbhuston) on Twitter for more information as it comes in.

UPDATES:

7/14 – 2:17pm Eastern –

SANS has gone back to green status and is posting that they hope awareness has been raised.

Nick Brown wrote in to tell us that the exploit in MetaSploit is easy to use and very effective against most XP workstations. He also warns home users to be on the lookout as this is very likely to turn into a worm or automated bot-net attack very soon. He agreed that the MetaSploit exploit is unlikely to affect servers as we expressed in our assessment. Lastly, he wanted us to remind everyone that using the kill bits, REQUIRES A REBOOT OF THE SYSTEM BEFORE IT IS IMMUNE.

Adam Hostetler also found this site, which has some interesting ways of identifying vulnerable hosts: http://blogs.technet.com/srd/archive/2009/07/13/more-information-about-the-office-web-components-activex-vulnerability.aspx

We have scheduled a FLASH Campfire chat for a threat update and discussion at 4pm Eastern today. The URL for that chat is: https://microsolved.campfirenow.com/ccf03

Thanks for reading and for all of the excellent feedback!

Update2: Here is the transcript from the public chat. Thanks to all who attended. Hopefully, it will be helpful for folks who are working on the issue.

Transcript

Project Pre-Release – Vulnerabilities in Popular Content Management Systems Under Study

Posted on by
Reply

Over the next few weeks you will see more details from us about a project that we have been working on. As a part of our relationship with Syhunt, one of our elite partners for application security work, we have been testing and reviewing their new tool, Sandcat4PHP. The tool is a sophisticated and user friendly source code scanner for performing deep analysis of PHP applications including their surrounding javascript and HTML components.

Stay posted here for a pretty in-depth review of the new tool, its use and capabilities. We will be doing that review as a part of the project as well.

First, let me start with the purpose and the scope of the project. In the last few months we have worked with a number of clients who have had issues with the security of their content management system. More than a few of them are using popular products, but several are using proprietary tools as well. As such, we have worked on a few incidents and application reviews. That led to a pretty in-depth discussion between a couple of clients and ourselves about the state of content management system security, in general. As an off shoot of that discussion, we decided to test 5 of the most popular content managers using the new Syhunt PHP scanner, since we needed to review it anyway.

Next, we obtained a couple of lists of popular content managers. Selecting our five was pretty easy and we settled on the following:

WordPress, Joomla!, Mambo, Drupal and BitWeaver

We then downloaded the current versions of the CMS (as of that day, a couple of weeks ago…) and set up our testing environment.

We assessed the entire package, but only as downloaded from the web site. That means in most cases, that we tested only the core components and not any additional modules, plugins or components. We considered whatever was in the default download to be the basis for our work.

To date, we have begun our assessments and review of the CMS tools. We will be in contact with each of the CMS projects about the findings of the assessments and they will receive the details of the tool’s findings prior to public release of the technical details. Statistical and numeric data will also be forthcoming.

For now just let us say that we are evaluating our findings and that the tool performed very very well.

I look forward to sharing the details with everyone in the coming days.

Let me know if you have any questions about the product, the project or the work.

Bad News in Trends of 2007

Posted on by
Reply

The infosec community got some bad news today in the first release of trends for 2007. Overall, things are not going as well as we would like. Attacks continue to rise and successful compromises that end in data compromise are up.

Attackers seems to have fully embraced client-side attacks and bot-nets for performing illicit activity and laptop theft is also seen as rising. As expected, identity theft is rapidly becoming a huge criminal enterprise with an entire underground economy emerging to support it.

Reports came out today that showed that malware attacks have doubled in 2007 and that data theft rates have TRIPLED!

From our standpoint, this validates that existing traditional security controls based around the perimeter simply are NOT WORKING. We must establish defense in depth. We must embrace enclaving, encryption of sensitive data and portable systems and establish proactive security mechanisms that can raise the bar of compromise out of the reach of the common attacker. Until we begin to think differently about security, data protection and privacy – these trends remain likely to increase even further.