Tag Archives: HoneyPoint

Web Proxy Scanning – Attack or Desperate Search for Free Information Flow

Posted on by
Reply

I remember when I was coming up in the infosec world, there used to be a rallying cry among “hackers” that “information wants to be free”. Certainly, we know from history and the present that information freedom has a high value to democratic society. The fact that unrestrained communications can be used to cause social, economic and political change is a given.

I often encounter hundreds of web proxy probes against our HoneyPoints every day. As I look through the logs, research the various traffic and analyze any new events, I am in the habit of largely ignoring these simple probes. Today, however, it occurred to me that many, likely not all (but many), of these probes were folks in less open countries trying to find access mechanisms to get unrestricted access to the web. They may well be searching for an SSL wrapped pipe to retrieve current news, conversations, applications and other data from sources that the “powers that be” in their country would rather not have them see.

Of course, I know that not all proxy scans are for the purpose of escaping political oppression. I know that there are attackers, cyber-stalkers, pr0n fanatics and criminals all looking for proxies too. I also know, first hand, from our HoneyPoints that when they think they find them, many of these probes turn out to be less “CNN” and more attempts to break into the organization offering the proxy. I have seen more than my share of proxied, “internal” probes when attackers believe that their new “proxy” is real and useful.

But, even with the idea that some folks use these tools for illicit purpose, I think, some folks must be dependent on them for free access to uncensored information. Of course, the big question is, how can we help the folks that would like to use the proxy for legitimate public access to free information while refusing illicit access through our system. This is very very difficult without resorting to blacklisting, if we want to offer access to the net as a whole.

However, one of my engineer friends chimed in that perhaps access to the entire web is not really needed. What if you somehow created a system that had proper controls in place to prevent most attacks, but had a white list of sites that traffic could be proxied to. You would still be acting as a sort of “information moderator” in that you could control the sources, but what if the default page listed the sites that were allowed, and you allowed the most common news sites or other commonly sought sources for information that somehow had been vetted beforehand. Not a totally optimal situation, I understand, but better than the current scenario for some folks.

The question is, how could such a solution be created? How could it be established and managed? How would sites get vetted and could existing software be used to create these mechanisms or would new tools require development cycles?

If you have thoughts on this idea, please drop us a line. I would be very interested in your feedback!

[Tangent] Can infosec VARs Really Make an Evangelical Sale?

Posted on by
Reply

We have been having quite a struggle finding infosec VARs to resell our HoneyPoint products. The problem seems to be that HoneyPoint and the idea of a Next Generation Distributed Honeypot product are such a radical concept to most organizations that they require evangelism and education for the customers to understand the value of the product and why it is a better solution that they are using now. It usually takes a while for them to understand that they can free themselves from false positives and the overhead of many of the detective tools they are using today if they simply embrace the idea of thinking differently about the problem.

VARs today seem to be focused solely on the products that are demand driven. They want to sell the Cisco products, the copies of anti-virus and the stuff that clients are already used to asking for. The days of VARs looking for ways to shake up the markets, establish value with fresh approaches and build their businesses by leveraging rapport with their customers by solving their deeper problems seem to be all but gone. Sure, you can find VARs to resell your widget or appliance if you have a model that requires little work, even if it has a small margin. But, it seems like finding evangelical VARs is nearly impossible in today’s market. If they are out there, we don’t seem to be able to find them.

I really feel like that is a bad thing for the market and for the clients. In the early days of MSI and the security industry, there was a lot to be gained by being a VAR that was able to bring bleeding edge solutions to customers. I can remember working with clients to help them understand new protective technologies like the Sidewinder firewall from Secure Computing, Real Secure from ISS and spending a lot of time traveling, talking to clients and listening to them explain the things that hurt them – then digging into the net and our brains for REAL, DEEP solutions that addressed the root problems that they were experiencing. For me, at least, that was the exciting thing about being a VAR – finding that next breakthrough that could really empower some of my clients in a way that they may not even have known that they needed until we showed them that a better way was available. That was exciting, fun and really gained us the trust of organizations who have been clients for nearly two decades now.

If there are any VARs out there that you think fit this model, I would like to hear about them. I would love to find a few folks who are willing to help evangelize what is clearly a better solution to the insider threat and to securing virtual environments. I would like to work with someone who shares that energy, passion and willingness to help solve deeper problems than traditional “network gear” resellers will ever be able to uncover. If you’re out there, give me a call – I think we have something to talk about…

HoneyPoint Security Server Console Upgrade and New Deployment Worksheet Available

Posted on by
Reply

A new release of HoneyPoint Security Server Console was released today. Version 2.51 includes two bug fixes and several library upgrades. The new release seems to be a bit faster on Windows systems, likely due to upgrades in the back-end libraries.

The new version fixes a bug in the math of the email alerts to system administrators where the wrong event counts would be included. It also repairs a bug that caused a crash on some systems when changing the status of multiple events. While neither of these bugs are critical, we thought the speed changes were worth a release.

The new version also includes the recently updated User Guide that now includes full instructions for installing the HPoints as a service or daemon using common tools or the tools from the resource kit.

We are also pretty happy to announce the availability of a deployment worksheet that guides new users through the deployment of the console and HPoints and helps them gather and define the information needed to do a full roll out.

We are hard at work on new HPoints and we have several that are finishing the testing process, so stay tuned for more releases soon. Updates are also underway to the Personal Edition (including a whole new GUI) and we are just starting to plan for version 3 of the console, so if you have suggestions, send them in.

Both the updates and the deployment guide are now available on the FTP server. Please use your credentials assigned when you made your product purchase to download them. If you need assistance, simply give us a call!

Increases in PHP Scanning

Posted on by
Reply

We are detecting increasing PHP scans for a series of known PHP vulnerabilities that thus far are originating from Asia.

To date, we see no new attacks, just checks for known bad pages, particularly admin interfaces and a couple of quick URLs to test for command injections. The scans seem to have begun in the last 24 hours and the traffic appears to be related to a possible new PHP scanner. Likely, some new tool has been released that contains a plethora of PHP vulnerabilities.

Organizations should ensure that any systems offering PHP or PHP applications have been properly assessed and patched.

HoneyPoint Security Server users are urged to deploy a web HoneyPoint or HornetPoint and to drop the hosts performing the scans into your firewall or router black hole lists. This should allow you to create a “one strike and you’re out” approach for black holing attacking systems.

Please let us know if you see any new PHP activity. We are currently watching this pattern for any zero-day type activity, but thus far, we have observed only known security issues. being probed.

SHOCKER – The FBI says Wi-Fi Hotspots are Insecure!!!

Posted on by
Reply

It’s hard to believe, but the FBI has recently announced that Wi-Fi Hotspots might not be secure.

I read it here, so it must be true… 😉

In a way I am glad to see public notices like this. Maybe if the FBI draws attention to the problems, average people will pay attention to the solution. Of course, their mitigation suggestions include the “keep your computer patched, use firewall and encryption” routine.

The sad part is that you can do all of these things and still fall victim to a number of security issues such as dns poisoning, DHCP spoofing, social engineering and a myriad of other problems. I guess that is a perfect reason why we push so hard for average folks to use our HoneyPoint:Network Trust Agent product. At less than 10 bucks, it adds yet more capability and ease of use to protecting even non-technical users when they are on untrusted networks, including wi-fi.

Public networks are likely to remain unsafe for users who are not vigilant for a long time to come. Firewalls and patches can help keep them safe, but until they make better decisions about information security and can resist many of the basic attacks that leverage social engineering and the like, free wi-fi will likely be a cyber-wild west for a while longer.

If you want to hear more about protecting mobile users against public network threats, drop us a line. Until then, we will wait to hear from the FBI. Maybe they can help us get the word out that there is help available for wi-fi users.

Time to Play Some Offense…

Posted on by
Reply

To quote, Allan Bergen, it sure looks like it might be “time to play some offense”…

Not surprising to me, I read today that the primary security concern of IT managers is the inside threat. It doesn’t surprise me because I have been working on educating organizations for several years about the seriousness of the insider threat. In fact, I would suggest that there are very very few threats that are NOT insider threats. Why? Because there really is no inside or outside. Thanks to disruptive technologies and evolved attacker capabilities – just about everything is exposed to attack. Just ask some of the recent vendors who were compromised in high profile “PCI-related” cases how well they feel that their “perimeter security” protected them…

The truth is, there are three powerful things that can be done to combat modern attacks, whether internal-based or executed by attackers half a world away.

1. Implement and enforce data classification – Know where your critical assets are, how they move around your environment throughout their lifecycle and then use tools like access controls, encryption and integrity verification to make sure that they are protected. Use logging analysis and event management to detect issues and make sure all of the controls, including role-based access controls, are HEAVILY and PERIODICALLY tested.

2. Embrace enclaving – Enclaving is like defense in depth throughout the whole network. Establish proper need to know boundaries, then build enclaves of security mechanisms around the data. Don’t build networks that trust user workstations with access to databases and other servers, segregate them with firewalls, detection mechanisms and access controls. Build as much security for the users as makes sense, but design the environment so that if users make bad decisions (which they will) and get popped – so what! Client side exploits and malware are only a concern if users have access to inordinate amounts of data. The problem is making sure that you get your controls and practices tight enough to limit the exposure that user compromise presents. That alone should go a LONG way toward minimizing your risk if done properly.

3. Move up the security stack to Threat Management and Risk Assessment – Use processes like risk assessment as a factor in business decision making. Security can truly empower business, but you have to let security teams stop being the “patch patrol” and “net cop” and let them get to actually helping you manage risk. They have to be able to identify threats, model threats and understand attacks and exposures. That requires education, dependable tools and upper management support. Encourage your security team to mature and begin to take real-world risk into consideration. Help them to resist the cult of the arcane technical security issue…

Of course, MicroSolved can help you with all three of these areas. We have the experience, insight and expertise to help you build effective enclaves and design data classification systems that make sense. We can help your team find security assessment goals that make more sense and provide ongoing assessment to keep them focused on the real-world risks. Our HoneyPoint products can help them model threats, frequency of attacks, understand the capability and intent of attackers and even give them deep insight into proactive risk metrics that they can leverage for “more science than academic” metrics of risk measurement. All of these things help your organization protect against the insider threat. All of them are available today.

The bottom line is this – if you are an IT manager looking to defend against the insider threat – give us a call. Together we can apply these strategies and others that your organization may need to effectively manage their risk and protect their assets.

At MicroSolved, we think differently about information security. So should you.

What is “Defensive Fuzzing”?

Posted on by
Reply

Since the release of HornetPoints with the newest version of HoneyPoint Security Server, I have been getting a lot of mail asking about “defensive fuzzing”. I thought I would take a moment and talk a little bit about it and explain a bit about its uses.

Defensive fuzzing is a patent-pending approach to network, system and application defense. It is based on the idea of using techniques from “fuzz testing”, but applying them against incoming connections in a defensive manner rather than as a test mechanism for known software. The idea is that attacker tools and malware probably fail to meet established best practices for software development and thus, are likely to have issues with unexpected input just as normal professionally developed software does. Further, “defensive fuzzing” lends itself to using fuzzing techniques as a protective mechanism to cause attacker tools, malware and other illicit code to abnormally terminate. Basically, by fuzzing incoming connections to a HornetPoint (which should have no real world use, thus all incoming connections are illicit) we can terminate scans, probes, exploits, worms, etc. and reduce the risk that our organization (and other organizations) face from these attacks.

For those of you who might not be familiar with fuzzing, you can read more about the basics of it here. However, keep in mind, that defensive fuzzing applies these techniques in new ways and for a protective purpose rather than a software testing process.

HornetPoints simply embody this process. They can be configured to fuzz many types of existing connections, emulating varying protocols and applications. For example, targeting spam and relay scanners can be done by implementing the SMTP HornetPoint. It listens on the SMTP port and appears to be a valid email relay. Instead, however, it not only captures the source and traffic from the spammers, but also fuzzes the connection as the spam is sent, attempting to terminate the spammer scanning tool, bot-net client or other form of malware that is generating the traffic. Obviously, success rates vary, but our testing has shown the process to be quite effective against a number of tools and code bases used by attackers today.

That is just one example and many more are possible. For more information about defensive fuzzing or HornetPoints, please leave us a comment or contact us. We would be happy to discuss this evolution in security with you!

Changing the World….Again!

Posted on by
Reply

In the last couple of years since we launched the HoneyPoint family of products, it has been an interesting experience. I have learned the joys and hardships of marketing a security software product. I have tried to make myself heard in an overcrowded and noisy marketplace. I would do it all over again, because HoneyPoint is the right idea and the right thing to do.

Now, MSI is again out to change the world. This week, we are launching a new release of HoneyPoint Security Server Console and officially releasing the long awaited HoneyPoint Trojan. Using these new tools, security teams can now create friendly Trojans that report information back to them whenever they are used. Security teams can gather when people access data that they should not and they can track data, documents and other pseudo-information around the world. That means that if you make jet engines, you can drop these Trojans on your file servers and anonymous FTP sites and then proceed to learn more about where they propagate!

But, that isn’t even the big news. The big deal is a new enhancement to HoneyPoint Security Server called HornetPoint. HornetPoints are the world’s first implementation of what we call “defensive fuzzing”. Like normal HoneyPoints, these pseudo-services listen on IP ports and wait for network contact. Just like HoneyPoints, they then capture the source and content of those transactions and report them to the central server. HoneyPoints, of course are often deployed to create an enterprise honeypot.

But, unlike normal HoneyPoints, HornetPoints are not a passive defense. Instead of replying with normal and expected data, the HornetPoints fuzz the expected data and mutate it into random and unexpected ways. The result is that a high number of attacker tools, worms, scanners and bot-net tools crash when the mutated data is received. Thus, HornetPoints, actively defend themselves and the network of their owners. Unlike more traditional defenses, HornetPoints don’t just guard against attacks – they break attackers and their tools!

We are just starting to populate the web site with information on these new versions and enhancements to the HoneyPoint product line. Over the next several days, we will make the new versions available and get the updated marketing added to the web site. In the meantime, if you are interested in hearing more about these new capabilities and the evolution from security to Corporate Counter Intelligence, just give us a call.

A special thanks is due from the MSI staff to those who have supported us during this process. Thanks to all of the folks who have urged us to complete the enhancements and to those who have helped challenge us to again rise to a new level. Things are certainly changing and we are all very proud to be a part of the next evolution of information security! We promise, we will continue to work hard to bring the best bleeding-edge protection and insights to all of you. As always, thanks so much for believing in us and in choosing MSI as your security partner!

MSI Launches New Threat Modeling Offering & Process

Posted on by
Reply

Yesterday, we were proud to announce a new service offering and process from MSI. This is a new approach to threat modeling that allows organizations to proactively model their threat exposures and the changes in their risk posture, before an infrastructure change is made, a new business operation is launched, a new application is deployed or other IT risk impacts occur.

Using our HoneyPoint technology, organizations can effectively model new business processes, applications or infrastructure changes and then deploy the emulated services in their real world risk environments. Now, for the first time ever, organizations can establish real-world threat models and risk conditions BEFORE they invest in application development, new products or make changes to their firewalls and other security tools.

Even more impressive is that the process generates real-world risk metrics that include frequency of interaction with services, frequency of interaction with various controls, frequency of interaction with emulated vulnerabilities, human attackers versus automated tools, insight into attacker capabilities, focus and intent! No longer will organizations be forced to guess at their threat models, now they can establish them with defendable, real world values!

Much of the data created by this process can be plugged directly into existing risk management systems, risk assessment tools and methodologies. Real-world values can be established for many of the variables and other metrics, that in the past have been decided by “estimation”.

Truly, if RISK = THREAT X VULNERABILITY, then this new process can establish that THREAT variable for you, even before typical security tools like scanners, code reviews and penetration testing have a rough implementation to work against to measure VULNERABILITY. Our new process can be used to model threats, even before a single line of real code has been written – while the project is still in the decision or concept phases!

We presented this material at the local ISSA chapter meeting yesterday. The slides are available here:

Threat Modeling Slides

Give us a call and schedule a time to discuss this new capability with an engineer. If your organization is ready to add some maturity and true insight into its risk management and risk assessment processes, then this just might be what you have been waiting for.

Yet More SSH Fun – This Time With Humans!

Posted on by
Reply

2b.jpg

OK, so last week we took an overview of SSH scans and probes and we dug a bit deeper by examining one of our HoneyPoints and the SSH scans and probes it received in a 24 hour period.

This weekend, we reconfigured that same SSH HoneyPoint to appear as a known vulnerable version. And, just in time for some Monday morning review activity and our blog posting, we got what appears to be an automated probe and then about an hour later, a few attempts to access the vulnerable “service” by a real human attacker.

Here is some of the information we gathered:

The initial probe occurred from a 62.103.x.x IP address. It was the same as before, a simple connection and banner grab. The probe was repeated twice, as per the usual activity, just a few seconds apart.

This time, ~40 minutes later, we received more connections from the same source IP. The IP address only connected to port 22, they did no port scanning, web probes or other activity from that address or in that time frame.

The attacker made several connections using the DropBear SSH client. The attacker seemed to be using 0.47, which has a couple of known security issues, according to the banner the client sent to the HoneyPoint.

The attacker performed various SSH handshake attempts and a couple more versions of banner grabbing tests. Over the next ~20 minutes, the attacker connected 5 times to the HoneyPoint, each time, probing the handshake mechanism and grabbing the banner.

Finally, the attacker decided to move on and no more activity has been seen from the source IP range for a day and a half.

The attacker source IP was from a Linux system in Athens, Greece that appears to belong to an ISP. That system has both OpenSSH 3.9p1 and regular telnet exposed to the Internet. The system advertises itself by hostname via the telnet prompt and the name matches its reverse DNS entry.

We contacted the abuse contact of the ISP about the probes, but have not received any comment as of yet.

The interesting thing about this specific set of probes was that the human connections originated from the same place as one of the banner grabbing scans. This is not usual and is not something that we have observed in the recent past. Usually, the probes come from various IP addresses (likely some form of worm/bot-net) and we rarely see any specifically identifiable human traffic. So, getting the attention of the human attacker is certainly a statistical anomaly.

The other interesting behavior piece here was that the attacker did not bother to perform even a basic port scan of the target. They specifically focused on SSH and when it did not yield to their probes, they moved on. There were several common ports populated with interesting HoneyPoints, but this attacker did not even look beyond the initial approach. Perhaps they were suspicious of the SSH behavior, perhaps they were lazy or simply concentrating on SSH only attacks. Perhaps, their field of targets is simply so deep that they just moved on to easier – more usual targets. It is likely we will never know, but it is certainly interesting, no doubt.

Thanks for the readers who dropped me emails about their specific history of SSH problems. I appreciate your interest in the topic and I very much appreciate the great feedback on the running commentary! I hope this helps some security administrators out there, as they learn more about understanding threats against their networks, incident handling and basic event research. If there are other topics you would like to see covered in the future, don’t hesitate to let me know.