HoneyPoint Personal Edition and Network Trust Agent 1.10 Released

We have been getting large numbers of requests to try our HPPE and HP:NTA products, but up until no demo versions have been available. This is no longer true, effective today!

Users who would like to try out either or both of these leading edge products can download fully functional versions from our website. Both products will run for fifteen minutes at a time, then pop up a message advising you about how to obtain a key and quit. The products can be restarted as many times as you wish, with each execution running 15 minutes!

We hope this new capability really gives everyone a chance to explore, analyze and play with these amazing tools. The feedback from other users has been so strong that we have been very hard at work to find a way to offer them to everyone.

To check them out and begin securing your workstation with the power of HoneyPoints, click below, then click on the time limited demo link at the bottom of the page (no registration required):

HoneyPoint Personal Edition

HoneyPoint:Network Trust Agent

**CENSORED** Worm Continues to Grow

Our HoneyPoints are still seeing an increase in the overall numbers of attacking systems exploiting the newest **CENSORED** vulnerability. The traffic has a destination port of TCP/4899.

Most sites should be filtering this port by now, but it seems some smaller organizations have not yet gotten the word about the problem.
Eastern Europe seems to be the home of more than a few systems scanning for this issue.

If you have not yet begun blocking this port, and are a **CENSORED** user who has not upgraded to date, then now would likely be a good time to implement blocks and inspect your exposed systems.

PS – I HAVE UPDATED THIS POSTING AS A RESULT OF A LETTER FROM THE VENDOR INVOLVED WHO REQUESTS THAT WE STOP USING THE TRADEMARKED NAME OF THEIR PRODUCT.

Increases in Attack and Probe Traffic Likely

With the official release of MetaSploit 3 occurring today, look for a likely increase in scans and probes associated with the tool and it’s 117 exploits. To date, MetaSploit accounts for a large percentage (some 75-80%, we believe) of manual attack traffic to our HoneyPoints.  It is widely adopted and easily used to compromise systems.

If you have not had a vulnerability assessment recently, now might be the time to get one underway and get some mitigations in place. The more publicity this tool gets, the more attack traffic that everyone will likely encounter in the coming few weeks.

This version of MetaSploit looks to be a very powerful upgrade, and there are a lot of tools built in for professional security testers, researchers and others. Modules for host identification, Denial of Service testing and all kinds of goodies are here. How those get used in the future, and whether or not they lead current script kiddies down the path of enlightenment and knowledge, remains to be seen.

In the meantime, get ready for some packet, network stream, log and IDS analysis. As the underground learns the new version, some of us are likely to be caught in the crossfire…

Useful Security Reports

It’s that time of year where we like to do some spring-cleaning of our various reporting formats and structures. This includes our Vulnerability, Penetration and Risk Assessment reports. A brief survey of reports and sample reports available on the Internets reveals a wide range of depth and style of reporting formats. Everything from HTML-based reports using raw data from a Nessus scan, to reports comprised of 90% prose and a couple of pie charts thrown in for the executives.

Over the years we’ve had the privilege of working with several companies and individuals who take a strong proactive stance in using their reports. As a result, we have developed a number of reporting formats tailored to each client, enabling them to streamline their internal operations and deal with findings in an expedited manner and move on to their other tasks. This process also allows us to develop insights into how to present audit data to the customer in a form and format that is concise and comprehensive. This allows them to act without being overwhelmed.

That’s what we love to do! Our goal is to present the end customer with a report that will enable them to do their jobs more accurately and thoroughly without getting bogged down in reporting that is not conducive to their normal work flow.

So we humbly ask, you the reader, what features of security reporting formats have you found that improved your workflow? What are the most useful features you have encountered? What are the least useful? How do you use your reports? How can reports be structured to improve the remediation of specific issues? How do your executives use the reports? Are there recurring questions that are posed by your executives? How do reports build or destroy your trust in your IT or risk auditors?

What is Your Favorite Application Security Tool?

Application security is all the rage these days. As such, vendors, open source projects and individual developers are flooding the market with tools for scanning, pen testing, application firewalls and all kinds of other stuff.

With so much “stuff” available, we though we should ask you, the users about what your favorite application security tools are. So, drop us a line or a comment and let us know about your coolest appsec toy. We will aggregate and post the best in an upcoming blog post.

Please share the name, the basic functionality and the reasons you like the tool so well.

Thanks for contributing!

Open Source Software File Integrity

Do you check file integrity when you download open source software? This is normally accomplished by the software developer providing MD5 sums for the files. An MD5 sum is a computed signature for the chosen file. By providing you this signature, you are able to verify the integrity of the file by computing the signature on your own system and comparing it against the sum that was downloaded with the file. Many developers have recently started including GPG signed sums, which is even better, and prevents creating fake sum files in the event that the system that contains the software and sum files is compromised.

The reason I bring this up is that a popular open source application was recently compromised. An attacker was able to access a server that contained the downloadable distribution and changed some of the files to contain malicious code that could be exploited remotely. The altered files were found by a user that had downloaded the files and found a discrepancy in the sums, potentially saving many that had downloaded the altered software.

Doing this may sound like an inconvenience, but it is really easy to do, and helps ensure that you are getting software that was not tampered with. To do your part, you just need to acquire an MD5 digest generating program. Many distributions of Linux include one, and you can download them for virtually any OS. You could even create one, if you want. Now you just need to run the MD5 generating program against the files you downloaded. Compare your output against the MD5 sum provided by the developer.

If you have GPG and the developer provides signed MD5 sums, you can check that the MD5 sums were actually created by the developer.

One Way An Attacker Uses Convenience Against You

Over the past year, MSI has performed so many information security assessments that I have lost count. As the Senior Security Engineer and quasi-Project Manager, I get to read each and every report that comes out of our technical team, before it gets shipped off to the client. While we occasionally see things that can only be described as “interesting”, there is usually one constant theme amongst the overwhelming majority of our clients that continues to surprise us AND them….and that’s the use of Microsoft’s Terminal Services.

For those of you that don’t know, Terminal Services is a solution that is designed to allow remote access to the graphical user interface (GUI) of the machine on which it is installed. Terminal Services is probably one of the most convenient solutions around for allowing remote access to a particular system. What continually surprises our clients is the fact that we, as the proverbial attacker, are just as capable of taking advantage of that “convenience” as the administrators who regularly use them are.

For an attacker, Terminal Services does not only provide access to a system’s GUI, given the correct credentials, it also provides a way to verify whether those credentials are legitimate. Here’s the deal, when an individual (or attacker) connects to a Terminal Services login portal, they are authenticating to the local machine OR the domain…dependent only upon their current mood or desire. You see, Terminal Services gives you the option to choose where you wish to authenticate, assuming the target host is configured as part of the domain.

While it might be useful to discuss exactly how an attacker can use Terminal Services against you, I think it’s more useful to discuss how we have seen Terminal Services deployed and what some of the better solutions might be.

We primarily see Terminal Services deployed on an internal network, which is where it was designed to be deployed.  On some rare occasions (much to our delight, our clients dismay) we see Terminal Services deployed on Internet-facing systems. This should be considered an absolute no-no. If an attacker were able to get their hands on legitimate credentials (any credentials that are valid on the target machine or domain, if configured) there is nothing stopping them from gaining access to the GUI on that Internet-facing system.  No need to scan the host for vulnerabilities.  No need to run any exploit code.  No need to set up any netcat shells.  No need to maneuver around the system via the command line.  The attacker can log into the host just as if he were sitting at the keyboard.

The problem with allowing Terminal Services on an internal network is that it simply makes an attackers job much easier than it should be. Again, given legitimate credentials, it becomes trivial for an attacker to move from host to host that has Terminal Services installed.  You can use your imagination to figure out what the attacker does once logged into the hosts.  The big question here is…which systems usually have Terminal Services installed, on an internal network?  In our experience, it’s usually the critical systems that administrators need to work with on a regular basis.  That’s right…domain controllers, mail servers, web servers, database servers, etc.  Many of those systems are usually showered with extra attention to ensure that their patches are current, anti-virus is up to date and logs are analyzed.

If you, the administrator, are dedicating so much time towards keeping those critical systems up-to-date, why keep an authentication portal available that offers no encryption, is vulnerable to man-in-the-middle attacks and grants remote access to the GUI of your most critical systems…all while allowing every single user on the domain to authenticate to the system?

On Internet-facing systems, we would much rather see a VPN solution being used to allow remote access. If a VPN solution cannot be used, we would prefer to see people using some sort of Virtual Network Connection (VNC) or Secure Shell (SSH) solution that encrypts the communication tunnel and authenticates to the service and not the local system or domain.

In both VNC and SSH, a username and password is set when the service is installed and configured.  Those credentials are specific only to the actual remote access service and not the sytem or domain as a whole. So, if an attacker compromises those credentials, they don’t automatically have access to the local system or domain…they are still stuck inside the sandbox of the remote access service.

On internal systems, there is really a couple of ways around the Terminal Services problems. If you are dead set on using Terminal Services, MSI would recommend that you disable the service until use is needed.  At that time, it is possible to start the Terminal Services service, remotely.  Once use has expired, disable the service again. In addition to disabling the service, it is imperative that Terminal Services be configured to only allow administrator accounts to connect and requires a multi-factor authentication token to authenticate. In doing so, you have created a service that is only available when needed and then only to individuals who are administrators AND possess a legitimate token.

The second option would be to use VNC, again.  As mentioned, using VNC instead of Terminal Services allows for credentials to be used that aren’t related to the local system or the domain…only the VNC service.

These are just a couple of ways around using Terminal Services.  A lot of our clients say that they use Terminal Services because it is convenient.  Our answer…yes we know…thank you for the assistance. A lot of times organizations have to try to balance security and convenience in order to allow for functionality. In this particular case, MSI believes that the individuals that normally use the Terminal Services should be technically savvy enough that security can be increased and convenience can be reduced, especially on critical systems.

Then again, if you think your convenience isn’t that big of a security problem, you could always ask us to help validate that theory.  Probably much easier AND cheaper than if a real attacker validates the theory for you.