Just a quick heads up post that Adobe has just released an “emergency patch” for at least 17 holes in Reader and Acrobat. This is likely worth rushing into testing and ultimately production as PDF attacks have become all the rage lately. You can find more information about the patch here: http://www.theregister.co.uk/2010/06/29/adobe_emergency_patch/
Just talked to a client who had dropped a HoneyPoint decoy host in their VPN termination segment a couple of weeks ago. Yesterday, it paid off.
They caught a machine that had passed the anti-virus and patching requirements of the NAC for the VPN. The machine was AV scanned clean. But, immediately upon connection the machine began to port probe hosts around it. This triggered the decoy machine’s HoneyPoints, causing the security team to investigate. The machine was brought in and examined. Closer inspection found it infected with a bot tool that escaped AV detection, but was capable of scanning for bad passwords and a couple of common vulns on surrounding machines. The machine is currently being imaged and rebuilt.
This is an excellent example of how HoneyPoint can help catch bots and malware, even when other controls fail. Defense is depth pays off and the leverage that HoneyPoint provides is often quite powerful, as in this case.
Have you thought about using decoy hosts? If so, how?
For this weeks tool review, we’re looking at Splunk. Splunk is a log collection engine at heart, but it’s really more than that. Think of it as search engine for your IT infrastructure. Splunk will actually collect and index anything you can throw at it, and this is what made me want to explore it.
Setting up your Splunk server is easy, there’s installers for every major OS. Run the installer and visit the web front end, and you are in business. Set up any collection sources you need, I started off with syslog. I started a listener in Splunk, and then forwarded my sources to Splunk (I used syslog-ng for this). Splunk will also easily do WMI polling, monitoring local files, change monitoring, or run scripts to generate any data you want. Some data sources require running Splunk as an agent, but it goes easy on system resources as the GUI is turned off. Installing agents is exactly the same process — you just disable the GUI when you’re finished setting up; however you can still control Splunk through the command line.
Splunk can also run addons, in the form of apps. These are plugins that are designed to take and display certain information. There are quite a few, provided both by the Splunk team and also some created by third parties. I found the system monitoring tools to be very helpful. There are scripts for both Windows and Unix. In this instance, it does require running clients on the system. There are also apps designed for Blue Coat, Cisco Security and more.
In my time using Splunk, I’ve found it to be a great tool for watching logs for security issues (brute forcing ssh accounts for example), it was also useful in fine tuning my egress filtering, as I could instantly see what was being blocked by the firewall, and of course the system monitoring aspects are useful. It could find a home in any organization, and it plays nice with other tools or could happily be your main log aggregation system.
Splunk comes in two flavors, free and professional. There’s not a great difference between them. The biggest difference is that with the free version Splunk is limited to 500MB of indexing per day, which proves to be more than enough for most small businesses, and testing for larger environments. Stepping up to the professional version is a lot easier on the pockets than might be expected, only about $3,000.
Note: This webinar is being rescheduled for July. Date and time to be announced.
This Thursday, June 24, at 2:00 PM – 3:00 PM EST, Phil Grimes, Security Analyst with MicroSolved, Inc., will be presenting a slideshow on DimDim. Join us to learn how to harden a WordPress site! Time will be left at the end for questions.
Send an email to register and we’ll send you the sign-in credentials.
See you there!
In continuing our research and experimentation with PHP and the threat of Remote File Inclusion (RFI), our team has been seeking out and testing various tools that have been made available to help identify web sites that are vulnerable to RFI during our penetration tests. Because we’re constantly finding more tools to add to the list, we’ve started the evaluation this week with the release of darkjumper v5.7. This python tool prides itself on being cross platform, and at first glance, seems rather easy to use. After downloading the tarball and extracting the files, simply calling the script from the command line brings it to life.
Running again with the –help or -h switches will print the options to the menu. This tool has several helpful options that could help expedite the discovery of various attack vectors against the web site. The injection switch incorporates a full barrage of SQLi and blind SQLi attempts against every web site identified on the target server. We did not use this option for this evaluation but intend to thoroughly test it in the future.
Using the inclusion switch will test for both local file inclusion (LFI) and RFI, again on every website identified on the target. This is our main focus for the evaluation since we’ve seen an incredible number of RFI attacks in the recent HITME data from around the globe. Selection of the full switch will attack the target server with the previously mentioned checks, in addition to scanning cgi directories, user enumeration, port scanning, header snatching, and several other possibly useful options. While a full review of this tool will be written eventually, we’re focusing on the RFI capabilities this time, so we’re using this test only against our test target. The test appears quite comprehensive. Another seemingly useful function of this tool is its ability to discover virtual hosts the live on the target server. After a short wait, darkjumper works it’s magic and spits out several files with various information for us to review. After pouring through these files, our team was disappointed to realize that there were URLs that pointed to this server which seem to have been missed by the tools scans. Even more disappointing is the fact that of the 12 target sites identified by the tool, none were the target that we had suspected of being vulnerable to RFI.
File inclusion is a real threat in the wild today. We are seeing newly vulnerable and compromised hosts on a regular basis from the HITME data, and seeing that Apache ships with a default configuration that is vulnerable to these attacks and the fact that PHP is inherently insecure, makes the battle even more intense. It is absolutely critical in this environment that we are hardening our servers before bringing them online. Those of us developing our web applications are validating every bit of information that is submitted to us by our users! Allowing our servers to execute code from an unknown source is one of the most popular attack vectors today from SQL injection, to XSS and XSRF, to RFI. The Internet continues to be a digital equivalent to the wild, wild west, where outlaws abound. There is no guarantee that the users who interface with our sites are who they say they are or that they have the best of intentions. It is up to us to control how our applications and servers are handling this data.
“Consumer use of the cloud”; in a phrase, is how the cloud will leak into your enterprise, whether you like it or not. Already, IT is struggling with how to manage the consumer use of devices and services in the enterprise. Skype/VoIP and WIFI were the warning shots, but the BlackBerry, iPhone, iPad and other consumer devices are the death nail for centralized IT (and IS) control.
Consumer electronics, backed by a wide array of free or low cost cloud services, are a new frontier for your organization. Services like MobileMe, DropBox, various file sharing tools and remote access services like GoToMyPC, et al. have arrived. Likely, they are in use in your environment today. Consumers use and leverage these services as a part of their increasingly de-centralized online life. Even with sites like Twitter and FaceBook growing in capability and attention, consumers grow their use, both personally and professionally of services “in the cloud”. Make no mistake, despite your controls at the corporate firewalls, consumers are using their mobile and pocket devices and a variety of these services. Unless you are searching them at the door and blocking cell phone use in your business, they are there.
This might not be “the cloud” that your server admins are worrying about. It might not represent all of the off-site system, database and other hosting tools they are focused on right now, but make no mistake, this consumer version of the cloud has all, if not more, of the same issues and concerns. Questions about your data is managed, secured and maintained all abound.
Given the “gadget posture” of most organizations and their user communities, this is not likely to be something that technical controls can adequately respond to. The consumer cloud services are too dynamic and widespread for black listing approaches to contain them. Plus, they obviously lack centralized choke points like in the old days of “network perimeter security”. The new solution, however, is familiar. Organizations must embrace policies and processes to cover these technologies and their issues. They also have to embrace education and awareness training around these topics with their user base. Those who think that denial and black listing can solve this problem are gravely mistaken. The backdoor cloud consumer movement into your organization is already present, strong and embedded. Teaching users to be focused on safe use of these services will hopefully reduce your risk, and theirs.
Just a quick note on the recent Google announcement about dumping Windows for desktops in favor of Linux and Mac OS X. As you can see from the linked article, there is a lot of hype about this move in the press.
Unfortunately, dumping Windows as a risk reducer is just plain silly. It’s not which OS your users use, but how safely they use it. If a user is going to make the same “bad computing hygiene” choices, they are going to get p0wned, regardless of their OS. Malware, Trojans and a variety of attacks exist for most every, if not every, platform. Many similar brower-based attacks exist across Windows, Linux and OS X. These are the attack patterns of today, not the Slammer and Code Red worm attack patterns of days gone by.
I fail to see how changing OS will have any serious impact on organizational risk. Perhaps it will decrease, a very small amount, the costs associated with old-school spyware and worms, but this, in my opinion is likely to be a decreasing return. Over time, attackers are getting better at cross platform exploitation and users are likely to quickly feel a false sense of security from their OS choice and make even more bad decisions. Combine these, and then multiply the costs of additional support calls to the help desk as users get comfortable and have configuration issues in the enterprise, and it seems to me to be a losing gambit.
Time will tell, but I think this was a pretty silly move and one that should be studied carefully before being mirrored by other firms.
Lately, we have been looking at a lot of banking apps and front ends for the iPhone, Android and other mobile devices in the lab. Our testing thus far has shown some great results and it seems like a lot of banks, credit unions and other financial institutions are interested in having an “app” for their customers and members. Many of these apps are well designed, deep and rich. Many are simply canned front ends to existing web page content and functionality. A few are just plain horrible.
Here are three tips for organizations to keep in mind when coding their banking and financial apps for the mobile devices.
1. The mobile devices are not PCs. The apps should be light weight, clean and easy to use. Usability is tied to security in this case, because of errors. If your app has tiny little buttons with confusing text, no confirmation dialogs and lacks other basic usability features then you make it easier for users to make mistakes, create bad transactions, get confused and other issues would could constitute a risk for your business and your users. Don’t design for a PC monitor. Make sure your designs are usable on the appropriate size screens and with appropriate space for human digits.
2. Don’t allow users to store their credentials in the app or its underlying data structures. Many mobile phones and such remain woefully unsecured. Even where the vendor has provided for basic security controls for the devices, many users do not use them. Plan ahead for this. The app has to be convenient, but it shouldn’t let the users place undo risk on themselves. If you allow them to store logins, or even a digital certificate, make sure they can’t also store at least 1-2 other pieces of credentials between uses. If someone just picks up their device, they should NOT have access to the users accounts.
3. This goes without saying, but don’t forget encryption. Just because an application uses the cell network, does not mean that you don’t need SSL. (I’m looking at you two developer groups in the last 90 days, you know who you are.) No matter the network, protect your transactions and data streams with strong crypto. The mobile devices can handle it. They can do enough lifting to handle SSL or they shouldn’t be running a banking app. Like Nike says, “Just Do It!”
There you have it. Three basic ways that you can help increase the safety and capability of your financial services app on the iPhone, iPad and other mobile platforms. If you have done these three basics, then you are off to a start. The next crucial step is to get your app and the back-end processes checked via a risk assessment and security test. Give us a call if you need assistance or want us to drop it into our testing lab process. We are seeing quite a few of these days.
So, just a quick thought on this one. What if we, as security folks, made a serious endeavor to reduce the earning capability of those who create crimeware, spyware and other malware? What if we did to them exactly what the gaming companies and MPAA have been saying is killing their business? What if every time we saw a piece of “licensed” crimeware tool, we cracked it and published keygens and other cracks for it?
Sure, in the mid-term there would be more attackers able to use the malware. But, what if, in the longer term, less malware were actually created? What if the bar went up to the point where publishing these tools was no longer profitable? Would the numbers and evolution of malware be slowed?
I am asking, not because I have an answer in mind, but because I am curious. At what point does striking at the root of the profitability of criminals reduce their efforts and capabilities? Anyone with ideas or experience in this line of thought, please leave a comment below. Thanks for reading and I look forward to your responses.
This has to be one of the worst, most FUD-filled articles I have seen yet on cyber security.
In the article, many vulnerabilities and threats are discussed, but the article fails to lay out any sense of real risk based on probability or likely damages. In other words, here is a bunch of the over the top crap to scare you about using technology.
I think this kind of stuff is exactly why consumers have grown palliative to security threats and keeping their machines patched. The media loves to whip the fear and hype on them routinely, yet common sense tells us innately that the sky can’t always be falling, or it would have fallen by now. Humans are incapable of existing at high levels of threat sensory overload for long periods of time. We just weren’t wired for it. Our sense of risk becomes irrational with too frequent and infrequent use.
Please, talk to people who ask about this stuff with a well-placed sense of risk. Explain that security issues exist in a variety of platforms, but the average person needs not fear every security problem. They need to base their decisions and actions on real world probability and damage calculations and NOT on hype by vendors, the media or interested parties.
I don’t know about you, but I’m not too worried about someone HERFing my stereo. It would work, likely, but the odds of someone caring enough to do it, having access and capability, seem pretty small. I’m not planning on tempesting the house any time soon, and neither should you.