According to the report, the source for compromise are remote access applications. Commonly used by IT and support organizations as a means to simplify remote management, these applications expose IP address information to cybercriminals. The IP address information is then used as a means to gather other bits of data which combined, can be used as an attack vector. I took a look at nearly 600 (586 to be exact) traffic assessments performed over the last two years and found some very interesting statistics on remote access application use.

• At least one remote access application was in use in 96% of the participating organizations.
• A total of 28 variants were found, four of which are browser-based, and the rest are client server.
• On average, 5 variants were found in each of the participating organizations. The ten most commonly found applications are shown in the table below.

One of the most interesting things I saw here is that none of the top 10 use port 80 or port 443. In fact, only 5 of the 28 remote access applications use port 80 or port 443. The remaining 25 all use an uncommon port or will port hop.

The ramifications here are significant because we find smart end-users taking advantage of remote access applications to login to their home machines, which in turn can provide one of the tidbits a cybercriminal may need to begin their attack.

Now the next question is, what tools should an organization use to reign in the use of these applications. A traditional firewall won’t work really. You can lock the port down, but when IT uses the tool, so too can an end-user. URL filtering won’t see it, nor in most cases will an IPS.

One way to attack the problem is a combination of user education, policy and technology.

1. User education: find out which employees are using them and why. Explain the ramifications of uncontrolled/unmonitored use.
2. Policy: establish a policy that dictates which remote access applications are allowed and across which ports. Explain what the ramifications (reprimand, fired, no bonus, other) are if the policy is not adhered to. The remote access applications that are allowed should be monitored and inspected for threat activity.
3. Technology: use technology, preferably ours, to enforce the policy.

Thanks for reading.

An Information Week article last week highlighted some of the facts around the breach involving the Duanesburg Central School District in New York state.  The prevailing theory is that the Zeus banking trojan is to blame.  Unfortunately, while AV has gotten better at detecting the trojan and the accompanying botnet (zbot), organizations can’t control the transmission vectors, which are increasingly social networking and/or webmail applications.  Given the high degree of user trust and huge user populations, malware developers have been targeting social networks aggressively (webmail is a well-established transmission vector).  Some of the threats come in the form of social network-specific threats (e.g., koobface, fbaction), but many times they’re re-using existing or older threats delivered in a new, hybrid way – exploiting the trust associated with social networks – which has given threats like Zeus a huge boost.  If you can’t control the transmission vector, it’s much harder to manage the threat…especially when users click first, and think later.

We created Stateful Inspection at a time when applications could be controlled using ports and source / destination IPs because applications were tightly tied to ports and protocols. But today, applications of all types no longer adhere to port and protocol which means they can no longer be controlled, let alone identified by today’s port-based (Stateful Inspection) firewalls.

Today’s applications use either well-known open ports or a variety of evasive tactics to easily bypass firewalls. Sadly, most 11^th graders can go into any corporate network and use any application they want, go anywhere on the internet and do anything they want through the corporate network and there is nothing firewalls can do about this. The fundamental reasons that Stateful inspection can be easily evaded include they rely on fixed ports, they look only at the first packet and they are unable to inspect SSL traffic.

The question then becomes one of whether or not Stateful inspection can evolve in the same manner that the applications have. The answer is no. Stateful inspection is architected to classify traffic based specifically on ports and protocols. The use of port and protocol traffic classification is hard coded – it is arguably the most fundamental component of Stateful inspection because it is used as the basis of the security policy. The allow or deny decisions are based on the port and protocol, so modifying Stateful inspection to replace port and protocol with application identity means a complete re-write of the software, a monumental task, given the foundational importance of traffic classification. Here is why Stateful inspection cannot evolve.

Stateful Inspection firewalls enforce policy decisions for a complete TCP or UDP connection upon receiving the first packet of that connection. Once the policy decision is made, further inspection and associated policy lookup is not required because every packet carries the same port number and the following packets from the same connection are not going to provide any additional information about the connection. This form of classification and policy enforcement cannot control many of the applications we see on enterprise networks.

Classifying traffic based on applications must continuously examine packets and check the policy table in order to determine how to treat a given connection. For example, the first packet might have a destination of port 443. The firewall performs a policy check and determines that the connection should be accepted. After a few more packets, the firewall might learn that this an SSL connection (it could have been non-SSL on port 443). Again, the firewall consults the policy to determine whether to allow the connection and also figure out whether this SSL connection needs to be decrypted. After a few more packets, the firewall might learn that this is HTTP inside SSL on port 443. Again, the policy lookup needs to be performed. Additional inspection might determine that this is Yahoo! Instant Messenger, which again requires a policy look up and an allow or deny decision. The traffic classification and policy lookup process continues in this manner for all traffic across all ports.

During the continuous classification process, firewalls that classify traffic based on applications do more than just multiple policy lookups. They need to determine when to log new information they discover—which is a continual process, given the comparatively dynamic nature of application traffic. In addition to continual policy lookup and logging, the application is used as the basis for route lookups, QoS decisions, threat prevention and so on.

Now, let’s assume a complete rewrite of Stateful inspection is achievable, it is only one of the two components required to deliver an enterprise-class firewall that controls applications. The second component is the hardware required to support application layer inspection across all ports and on all traffic. It is well documented that this level of inspection requires significantly more processing power then mere port-based scanning. For example, in a Stateful inspection firewall, a flow that is established can move to a “fast-path” because it does not requires any more policy lookups. As described above, this is not the case with an application aware firewall. The continual inspection and policy lookup requires appropriate processing be applied to maintain performance. Existing Stateful inspection vendors would therefore be forced to not only re-write the software from scratch—they would need to develop in tandem, a new hardware platform with appropriate processing power.

In short, Stateful inspection, cannot evolve to control applications. A new approach is needed – one that identifies applications as soon as the traffic hits the box, ignoring ports, protocols, evasive tactic or SSL encryption. That is what we created here at Palo Alto Networks.

One of the key points made by Golan Ben-Oni, senior vice president of network architecture at IDT, was that next-generation firewalls have enabled him and his team to focus on what’s important, and not spend so much time just maintaining firewall rulesets.  Furthermore, because of the application visibility and control, and the capacity of Palo Alto Networks firewalls, IDT was able to greatly simplify their infrastructure – reducing both the number and variety of security devices – all while gaining more visibility and control.  The most important implication of this point, however, is summed up nicely:  “In the course of the first week, I had gotten more done than I had in months and months,” he said. “Once I was able to get the Palo Alto [firewalls] in, I was able to return to my normal job and get some sleep at night.”

In the information security world, the acknowledgment that a product or service has enabled a customer to get more sleep is is the highest goal that a security technology vendor can aspire to.  Have a look at the article here.

Comparative growth of browser-based file sharing usage.

To be clear: we are talking about how often browser-based file sharing was found during our traffic analysis. The increased frequency is not too surprising really. The business benefit to browser-based file-sharing applications is they make if very easy to move large files such as a presentation or a graphic. Users are no longer forced to split a file up or take other steps to get around the email attachment limitations.

This is not to say that P2P file sharing has gone away or dropped off in use. On the contrary, in almost all measurable aspects, P2P is still tops in terms of file sharing. A comparison of resource consumption and the number of variants found is shown in the table below.

Now let’s take a look at the risks. It would be inaccurate to say that browser-based file sharing pose the same level of risks that peer-to-peer applications pose. There have been no known errant distributions of confidential files through browser-based file sharing, possibly because they are user-to-user focused as opposed to the broadcast focus for P2P.

However, browser-based file sharing applications do pose some risks because they represent an avenue for purposeful transfer of confidential data. In addition to the potential data leakage risks, these applications provide a vector for the delivery of threats – either directly from someone pulling down an infected file, or indirectly through malware-infested advertising (a known delivery mechanism) as part of the application providers’ business model.

The action that you should take is first determine if these applications are in use and the reasons why. Then work with your constituents to apply security policies to protect network while enabling use.

Case in point. A St Louis Today reporter posed an open ended question and did not like one of the more vulgar responses—no doubt posted due in part to the “anonymous” nature of the web. But rather then let it go, the poster was “outed” to the employer and summarily fired. This is a perfect example of a little knowledge (the identity of the anonymous poster) used in a manner that most would view as an overreaction. So the question we have to ask is this – would either of these reactions (the post and the retribution) be made in a face-to-face meeting. I don’t think so.

Let’s switch gears now. Our customers are deploying a next-generation firewall that gives the security administrators detailed information on the applications traversing the network, who is using them and the potential threats they pose. The administrators face a similar dilemma of how to use the newfound knowledge they now have at their fingertips.

One extreme is to blindly block everything that is non-business related. Doing so may conserve bandwidth, and improve security a bit it will also damage morale and force users to try and find ways around the controls. Most importantly, blindly blocking will slow company productivity because personal applications like IM, webmail, Google Docs, Twitter and Facebook are being used for work purposes. The other extreme is to monitor and blindly allow everything. This too is going to hurt company bottom line but for different reasons.

The right approach is to work with the business groups to determine usage policies based on the new found knowledge, educate users on the new policies and then enforce them. And it should be done in a face-to-face manner – where possible. If for no other reason than to avoid overreacting.

http://www.stltoday.com/blogzone/talk-of-the-day/talk-of-the-day/2009/11/whats-the-craziest-thing-youve-ever-eaten-and-did-you-like-it/ http://arstechnica.com/web/news/2009/11/paper-outs-anonymous-commenter-job-loss-ensues.ars

Like the previous three versions of the Application Usage and Risk Report,  http://www.paloaltonetworks.com/researchcenter/reports/ the findings are based on actual analysis of application traffic, not survey questions.

Social networking, messaging of all types, cloud-based productivity, collaboration, blogging and wikis, are just a few of the types of applications that fall within that nebulous group of applications defined as Enterprise 2.0. This edition of the report shows that despite many enterprises’ attempts to block applications the rate at which they are making the crossover from personal to business use is happening faster than previous crossovers, such as instant messaging (IM). Some specific findings from the research include:

Enterprise 2.0 adoption – embraced or resisted – is in full swing.

• More than a third (38%) of the 651 unique applications found fall within the Enterprise 2.0 definition described above. Compared to the Application Usage and Risk Report (Spring Edition, 2009), many of the Enterprise 2.0 applications such as  SharePoint, Facebook, Twitter, and blog posting showed significant increases in usage from several different perspectives.

Enterprise 2.0 benefits are no longer elusive – companies are improving communications and ability to respond while reducing costs.

• Research shows that companies using these applications are seeing measurable benefits including increased ability to share ideas, more rapid access to knowledge experts, and a reduction in travel, operations, and communications costs.

Traditional business and technology distinctions are meaningless.

• Enterprise 2.0 applications highlight the dissolution of the traditional distinctions between business and personal use. More often than not, the same applications used for social interaction are being used for work-related purposes. Irrespective of personal or work related usage, the dominant underlying technology is the browser (72% of research sample).

Applications are not threats – yet they carry risks.

• The adoption of Enterprise 2.0 applications is being driven by users, not by IT. The ease with which they can be accessed, combined with the fact that newer (younger) employees are accustomed to using them, points toward a continuation of this trend. The somewhat disconcerting fact is that many of the users do not take into account the business and security risks that these applications present. Looking at the 202 Enterprise 2.0 applications found, 70% can transfer files, 28% are known to propagate malware, and 64% have known vulnerabilities.

Organizations are scrambling to determine policies, address security issues, and enable appropriate use. These applications are delivering business value – they are rapidly becoming part of “how business gets done” – but the risks are not being weighed by users.

Download the report

Some history is necessary here. Part of our customer engagement process is to place a Palo Alto Networks firewall in a customer network for evaluation purposes. At the conclusion of the evaluation, we extract log data and provide a traffic assessment report. We currently have log data on 363 different organizations. http://www.paloaltonetworks.com/request-AVR.html

Mariposa spreads itself across  nine different P2P networks including: Ares, Bearshare, Direct Connect, eMule, iMesh, Kazaa, Gnutella, BitTorrent, (via LimeWire client), and Shareaza. Essentially, for each P2P network, there is a Mariposa foldershare feeding the bot executable. In addition to P2P applications, MSN Instant Messaging is also used as a spreader.

Most commonly found applications that are capable of spreading Mariposa (out of 363 organizations).

Some more detailed analysis of the 363 organizations for which we have data exposed some sobering statistics:

• 312 (86%) of the organizations had at least one of the P2P applications used by Mariposa.
• An average of three of the nine P2P applications were found in each organization.
• Total bandwidth consumed by the P2P applications that spread Mariposa was 17.3 terabytes or an average of 55 gigabytes per organization.
• Session consumption by P2P spreaders was 555 million or 1.8 million sessions per organization average.
• MSN was found in 322 of the organizations (89%). Resource consumption per organization was 2.8 gigabytes of bandwidth and 67,400 sessions respectively.

With MSN appearing in 89% and an average of three P2P applications appearing in more than 85% of the organizations I would speculate that many organizations are exposed. The bandwidth being transferred and the sessions being consumed indicates fairly heavy usage which increases the exposure dramatically.

Read on for information on installing and using the plugin.

Where to get it

The project is hosted here on Google Code.

How to install it

Unzip the mariposa.zip file. There will be 3 files – mariposa.dll, the source file, and packet-mariposa.c. Copy the DLL into the wireshark plugin directory. For example, d:\wireshark\plugin. The code was compiled based on Wireshark version 1.2.2. It may work on previous versions, but there are no guarantees.

How to use it

Restart Wireshark. Open a PCAP of the Mariposa command and control traffic. Locate the traffic which you want to decypt, right-click and select Decode As…

A dialog box will appear (on the Transport tab) and you will get a list on the right side of the dialog box. Search and choose MARIPOSA and click Apply.

“MARIPOSA” will now appear as the protocol for the associated traffic.

How to read it

In the Wireshark Packet Detail window, there is a tree named MARIPOSA Protocol, you will find Opcode, Seq, Original Data, Decrypted Data, BOT cmd, BOT cmd Content items. The Decrypted Data is probably the most interesting. Click on it to view the decrypted data.

Mariposa pulling a file down from Rapidshare

Receiving attack instructions

A confirmation message from the infected client to the command and control server – “Flood running”

When we compared 2 US universities of equal size (roughly 13,000 students each), we were intrigued to find that one institution with open application usage policies had roughly 250 infected clients (an infection rate of 2%). The other university has a more proactive approach to application usage on the network and actively uses the Palo Alto Networks devices to control usage of P2P applications. Their university has only seen a few infected clients. The difference is in the control of the P2P applications. If you can control applications, you can control the threats that ride in over those connections.

Control the application, control the threats.