Category Archives: Threat-Centric

Coming to Grips with DDoS – Prepare

Posted on by
3

This post introduces a 3 part series we are doing covering distributed denial of service attacks (DDoS) and helping organizations prepare for them. The series will cover 3 parts, Prepare, Defend and Respond. 

Part 1 of 3 – Prepare.

Distributed Denial of Service (DDoS) attacks use networks of compromised computers (botnets) or web servers (brobots) to flood organization websites with so much traffic that it causes them to fail. This is especially worrying for financial institutions and utilities which rely so very heavily on the availability of their services and controls. DDoS attacks are also mounted by attackers to hide fraud or other hacking activities being perpetrated on networks. Although these types of attacks are not new, they are presently increasing in frequency and especially in sophistication. Application layer DDoS attacks do a good job of mimicking normal network traffic and recent DDoS attacks have been measured at a huge 65 Gb (nearly 10 times the previous high point). The purpose of this blog is to discuss some methods small organizations can employ to properly prepare for DDoS attacks. (Later articles in this series will discuss means for defending against and responding to these attacks).

The first thing any organization should do in this effort is proper pre-planning. Ensure that DDoS is included in your risk assessment and controls planning efforts. Include reacting to these attacks in your incident response and business continuity plans. And as with all such plans, conduct practice exercises and adjust your plans according to their results. In all our years in business, MSI has never participated in a table top incident responce or disaster recovery exercise that didn’t expose planning flaws and produce valuable lessons learned.

Next, your organization should consider DDoS when choosing an ISP. It helps immensely to have an Internet provider that has enough resources and expertise to properly assist if your organization is targeted for one of these attacks. Ensure that you develop a close relationship with your ISP too – communicate your needs and expectations clearly, and find out from them exactly what their capabilities and services really are. 

Finally on the preparation side of the problem, make sure that you keep well informed about DDoS and the actual threat level it poses to your organization. Keep active in user groups and professional organizations. Use the net to gather intelligence. The Financial Service Information Sharing and Analysis Center (FS-ISAC) has plenty of useful and up to date information on DDoS. You can even turn the World Wide Web against the enemy and use it to gather intelligence on them!

–This article series is written by John Davis of MSI. 

PS – This is NOT a problem you can “purchase your way out” of. Organizations can’t and should not buy huge amounts of bandwidth as a preparation for DDoS. The cost impacts of such purchases are not effective, nor is bandwidth size an effective control in most cases. Note that some technology solutions for packet scrubbing and the like do exist. Your milage may vary with these solutions. MSI has not reviewed or tested any of the DDoS technology products as a part of this series.

Quick Thought on CSRF Attacks

Posted on by
Reply

Yesterday, I listened to @Grap3_Ap3 present at the Columbus OWASP local chapter on Cross Site Request Forgery (CSRF). While this attack has been around since 2001, it continues to show a strong presence in web applications across a range of platforms. Phil spent a lot of his time talking about content management systems on the public Internet, but we have seen CSRF very widely exploitable on embedded devices.

Embedded devices, often equipped with rather rudimentery web servers and applications for management, have proven to be a searing hot pain point for CSRF in our research. While that isn’t shocking or new, I definitely see an interesting and potentially dangerous collision between the growth of the “Internet of Things” and web vulnerabilities. Today, some of these platforms are toys, or novelty tools built into home appliances – BUT, the future of internetworking of our devices and our physical lives means that these web controls will eventually have larger impacts on our day to day lives.

What happens when a CSRF attack can be used to trick your teenager into clicking on a picture on the web that while they view it, they also execute a command to raise the temperature on your refrigerator to unsafe levels? Or when an embedded link in an email tricks you into a click that turns your oven onto super heat clean mode without your knowledge? Sound like a prank? Maybe. Extend it to thermostats, home automation and consumer control over alternative energy controls like solar panels and such and it might take a new form.

We are on a course of collision. Our inattention to information security and the exploding complexity and technology dependencies will soon come together in ways that may surprise us. Ignore the hyperbole, but think about it rationally. Isn’t it time we worked with organizations who make products to demand an increase in protection from some of these basic known attacks? In the future, consumers and organizations alike will vote with their dollars. How will you spend yours?

Threat Update: Wide Scale Phishing in Progress

Posted on by
Reply

GlobalDisplay Orig

Just a quick update about the ongoing threat from malware dropped by phishing attacks. There are a lot of phishing attacks currently in progress. Fishing has been a leading form of compromise for quite some time and indicators appear to point to an increasing amount of phishing attacks and a larger amounts of damage from successful exploitation.

Many organizations are reporting wide spread phishing using recycled, older malware including Zeus, Tepfer and other common remote access tools. In some cases, these malware are repackaged or otherwise modified to evade anti-virus detection. Attackers are showing medium to high levels of success with these attacks.

Once compromised, the normal bot installation and exfiltration of data occurs. For most organizations that don’t play a role in critical infrastructure, this likely means credentials, customer information and other commercially valuable data will be targeted. For critical infrastrcuture organizations, more specific  design, future state and architectural data is being targeted along with credentials, etc.

Organizations should be carefully and vigilantly reviewing their egress traffic. They should also be paying careful attention to user desktop space and the ingress/egress from the user workstation DMZ or enclaves (You DO have your user systems segregated from your core operations, correct???). Remember, you CAN NOT depend on AV or email filtering to rebuff these attacks at a meaningful level. Detection and response are key, in order to limit the length of time the attacker has access to your environment. Anything short of full eradication of their malware and tools is likely to end with them still maintaining some level of access and potentially, control.

Now is a good time to consider having a phishing penetration test performed, or to consider using MSISimplePhish to perform some phishing for yourself. Awareness alerts and training are also encouraged. This is going to be a long term threat, so we must begin to implement ongoing controls over the entire technology/ppolicy & process/awareness stack. 

If you have any questions on phishing attacks, malware or incident response, please let us know. Our teams are used to working with these attacks and their subsequent compromises. We also have wide experience with designing enclaved architectures and implementing nuance detection mechanisms that focus on your critical assets. Feel free to touch base with us for a free 30 minute call to discuss your options for increasing security postures.

Event Announcement: ICS/SCADA Security Briefing

Posted on by
Reply

MSI, along with the teams at NexDefense and Critical Intelligence, will be participating in an online webinar about ICS/SCADA Security. The date of the event is February, 6th and you can learn more about it here. 

The event is free to attend, though registration is required. You can earn a CPE for participating! 

We hope you will tune in and check us out!

Overview of the event: 

Learning Objectives

  • Significant trends in the threat and vulnerability environment
  • Relevant trends in ICS technology
  • What proactive steps you can take
  • How to leverage security intelligence

Agenda

  • Introductions
  • ICS Cyber Security Intelligence Briefing, Michael Assante
  • ICS Threat Update, Brent Huston
  • How to Leverage Security Intelligence, Bob Huber
  • Live Q&A

Who Should View?

  • Senior Information Security Leaders, CISOs and CTOs
  • Security and Risk Analysts
  • Control system security engineers
  • Security operation leads for ICS reliant organizations

From the HITME: Port 3131 “Gameframe” Scans

Posted on by
34

We’ve been watching some interesting scans primarily hitting our HITME sensors in Asia for the last couple of weeks. The connection occurs on port 3131/TCP and contains the following request:

GET http://gameframe.net/headers HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.10
Host: gameframe.net
Accept-Encoding: deflate, gzip
Proxy-Connection: Keep-Alive
Accept-Language: en-gb,en;q=0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Pragma: no-cache
Cache-Control: no-cache

The scans we have seen seem to be originating primarily from Europe.

Have you seen similar scans and probes on this port? If so, please share with us in comments or via Twitter (@lbhuston). 

In the meantime, it is worth checking your application logs if you have any custom applications deployed on this port, particularly exposed to the Internet. While we don’t see anything indicating an attack, review of anything exposed for errors or follow on attack traffic is suggested (it’s usually a good idea anyway). 

Thanks for reading! 

 

Threat Data Sharing in ICS/SCADA Needs Improvement

Posted on by
Reply

I had an interesting discussion on Twitter with a good friend earlier this week. The discussion was centered around information sharing in ICS/SCADA environments – particularly around the sharing of threat/attack pattern/vulnerability data. 

It seems to us that this sharing of information – some might call it “intelligence”, needs to improve. My friend argues that regulation from the feds and local governments have effectively made utilities and asset owners so focused on compliance, that they can’t spare the resources to share security information. Further, my friend claims that sharing information is seen as dangerous to the utility, as if the regulators ever found out that information was shared that wasn’t properly reported “up the chain”, that it could be used against the utility to indicate “negligence” or the like. I can see some of this, and I remember back to my DOE days when I heard some folks talk along the same lines back when we showed up to audit their environments, help them with incidents or otherwise contribute to their information security improvement.

When I asked on open Twitter with the #ICS/#SCADA hashtags about what hampered utilities from sharing information, the kind Twitter folks who replied talked about primarily three big issues: the lack of a common language for expressing security information (we have some common languages for this (mitre’s work, VERIS, etc.)), legal/regulatory concerns (as above) and the perceived lack of mitigations available (I wonder if this is apathy, despair or a combination of both?). 

I would like to get some wider feedback on these issues. If you don’t mind, please let me know either in comments, via private email or via Twitter (@lbhuston) what you believe the roadblocks are to information sharing in the ICS/SCADA community.

Personally, I see this as an area where a growth of “community” itself can help. Maybe if we can build stronger social ties amongst utilities, encourage friendship and sharing at a social level, empower ourselves with new mechanisms to openly share data (perhaps anonymously) and create an air of trust and equity, we can solve this problem ourselves. I know the government and industry has funded ISACs and other organizations, but it seems to me that we need something else – something more easily participatory, more social. It has to be easier and safer to share information between us than it is today. Maybe, if we made such a thing, we could all share more openly. That’s just my initial 2 cents. Please, share yours.

Thanks for reading, and until next time, stay safe out there!  

Surface Mapping Pays Off

Posted on by
Reply

You have heard us talk about surface mapping applications during an assessment before. You have likely even seen some of our talks about surface mapping networks as a part of the 80/20 Rule of InfoSec. But, we wanted to discuss how that same technique extends into the physical world as well. 

In the last few months, we have done a couple of engagements where the customer really wanted a clear and concise way to discuss physical security issues, possible controls and communicate that information to upper management. We immediately suggested a mind-map style approach with photos where possible for the icons and a heat map approach for expressing the levels of attack and compromise.

In one case, we surface mapped a utility substation. We showed pictures of the controls, pictures of the tools and techniques used to compromise them and even shot some video that demonstrated how easily some of the controls were overcome. The entire presentation was explained as a story and the points came across very very well. The management team was engaged, piqued their interest in the video and even took their turn at attempting to pick a couple of simple locks we had brought along. (Thanks to @sempf for the suggestion!) In my 20+ years of information security consulting, I have never seen a group folks as engaged as this group. It was amazing and very well received.

Another way we applied similar mapping techniques was while assessing an appliance we had in the lab recently. We photographed the various ports, inputs and pinouts. We shot video of connecting to the device and the brought some headers and tools to the meetings with us to discuss while they passed them around. We used screen shots as slides to show what the engineers saw and did at each stage. We gave high level overviews of the “why” we did this and the other thing. The briefing went well again and the customer was engaged and interested throughout our time together. In this case, we didn’t get to combine a demo in, but they loved it nonetheless. Their favorite part were the surface maps.

Mapping has proven its worth, over and over again to our teams and our clients. We love doing them and they love reading them. This is exactly how product designers, coders and makers should be engaged. We are very happy that they chose MSI and our lab services to engage with and look forward to many years of a great relationship!

Thanks for reading and reach out on Twitter (@lbhuston) or in the comments if you have any questions or insights to share.

Terminal Services Attack Reductions Redux

Posted on by
3

Last week, we published a post about the high frequency of probes, scans and attacks against exposed Windows Terminal Services from the Internet. Many folks commented on Twitter to me about some of the things that can be done to minimize the risk of these exposures. As we indicated in the previous post, the best suggestions are to eliminate them altogether by placing Terminal Services exposures behind VPN connections or through the implementation of tokens/multi-factor authentication. 

Another idea is to implement specific firewall rules that block access to all but a specific set of IP addresses (such as the home IP address range of your admins or that of a specific jump host, etc.) This can go a long way to minimizing the frequency of interaction with the attack surfaces by random attacker tools, probes and scans. It also raises the bar slightly for more focused attackers by forcing them to target specific systems (where you can deploy increased monitoring).

In addition, a new tool for auditing the configuration of Terminal Services implementations came to our attention. This tool, called “rdp-sec-check”, was written by Portcullis Security and is available to the public. Our testing of the tool showed it to be quite useful in determining the configuration of exposed Terminal Services and in creating a path for hardening them wherever deployed. (Keep in mind, it is likely useful to harden the Terminal Services implementations internally to critical systems as well…)

Note that we particularly loved that the tool could be used REMOTELY. This makes it useful to audit multiple customer implementations, as well as to check RDP exposures during penetration testing engagements. 

Thanks to Portcullis for making this tool available. Hopefully between this tool to harden your deployments and our advice to minimize the exposures, we can all drive down some of the compromises and breaches that result from poor RDP implementations.

If you would like to create some threat metrics for what port 3389 Terminal Services exposures might look like for your organization, get in touch and we can discuss either metrics from the HITME or how to use HoneyPoint to gather such metrics for yourself. 

PS – Special thanks to @SecRunner for pointing out that many cloud hosting providers make Terminal Server available with default configurations when provisioning cloud systems in an ad-hoc manner. This is likely a HUGE cause for concern and may be what is keeping scans and probes for 3389/TCP so active, particularly amongst cloud-hosted HITME end points.

PSS – We also thought you might enjoy seeing a sample of the videos that show entry level attackers exactly how to crack weak passwords via Terminal Services using tools easily available on the Internet. These kinds of videos are common for low hanging fruit attack vectors. This video was randomly pulled from the Twitter stream with a search. We did not make it and are not responsible for its content. It may not be safe for work (NSFW), depending on your organization’s policies. 

 

Exposed Terminal Services Remains High Frequency Threat

Posted on by
4

GlobalDisplay Orig

Quickly reviewing the HITME data gathered from our global deployment of HoneyPoint continues to show that exposed Terminal Services (RDP) on port 3389 remains a high frequency threat. In terms of general contact with the attack surface of an exposed Terminal Server connection, direct probes and attacker interaction is seen on an average approximately two times per hour. Given that metric, an organization who is using exposed Terminal Services for remote access or management/support, may be experiencing upwards of 48 attacks per day against their exposed remote access tool. In many cases, when we conduct penetration testing of organizations using Terminal Services in this manner, remote compromise of that service is found to lead to high levels of access to the organization’s data, if not complete control of their systems.

Many organizations continue to use Terminal Services without tokens or VPN technologies in play. These organizations are usually solely dependent on the security of login/password combinations (which history shows to be a critical mistake) and the overall security of the Terminal Services code (which despite a few critical issues, has a pretty fair record given its wide usage and intense scrutiny over the last decade). Clearly, deploying remote access and remote management tools is greatly preferred behind VPN implementations or other forms of access control. Additionally, upping Terminal Services authentication controls by requiring tokens or certificates is also highly suggested. Removing port 3389 exposures to the Internet will go a long way to increasing the security of organizations dependent on RDP technology.

If you would like to discuss the metrics around port 3389 attacks in more detail, drop us a line or reach out on Twitter (@microsolved). You can also see some real time metrics gathered from the HITME by following @honeypoint on Twitter. You’ll see lots of 3389 scan and probe sources in the data stream.

Thanks for reading and until next time, stay safe out there!

Threat and Vulnerability: Pay Attention to MS12-020

Posted on by
5

Microsoft today released details and a patch for the MS12-020 vulnerability. This is a remotely exploitable vulnerability in most current Windows platforms that are running Terminal Server/RDP. Many organizations use this service remotely across the Internet, via a VPN, or locally for internal tasks. It is a common, prevalent technology, and thus the target pool for attacks is likely to make this a significant issue in the near future. 

 
Please identify your exposures to this vulnerability. Exploits are likely currently being developed. We have not yet (3/13/12 – 2.15pm Eastern) seen exploitation or an increase in probes for port 3389, but both are expected to occur shortly.
 
Please let us know if you have any questions or if we may be of any assistance with this issue.
 
UPDATE: 
 
 
This article makes reference to a potential worm attack vector, which we see as increasingly likely. Our team believes the exploitation development time to be significantly less than 30 days and more like 1-3 days for resourced attackers. As such, PLEASE TREAT THIS AS A SIGNIFICANT INTERNAL VULNERABILITY as well. Certainly, IMMEDIATE consideration is needed for Internet exposed systems, but INTERNAL systems should be patched as soon as manageable as well.
 
UPDATE II:
 
 
This confirms the scope and criticality of this issue.
 
UPDATE III:
 
Just a quick note – we are seeing vast work on the MS12-020 exploit. Some evidence points to 2 working versions. Not public, yet, but PATCH NOW. Internal & protected networks too.
 
UPDATE IV:
 
MSI is proud to announce the immediate availability of a FREE version of HoneyPoint, called HPRDP2012 to help organizations monitor for ongoing scans and potential future worm activity. The application listens on port 3389/TCP and is available for OS X (Intel), Windows & Linux. This application is similar to our releases for Conficker & Morto, in that it will be operational for a set time (specifically until October 1, 2012). Simply unzip the application to where you would like to run and execute it. We hope this helps organizations manage this vulnerability and detect impacts should scans, probes or a worm emerge. Traditional HoneyPoint customers can use Agent and/or Wasp to listen for these connections and report them centrally by dilating TCP listener HoneyPoints on port 3389. Please let us know if you have any questions.