The perils of sharing

The perils of sharing

P2P PERILS update fixes Adobe Flash issue”, CNET News, 10 September 2009. 8. Symantec. 2009. “FAQ: Norton products and Mac OS X 10.6 (code-named Snow...

110KB Sizes 1 Downloads 105 Views

P2P PERILS update fixes Adobe Flash issue”, CNET News, 10 September 2009. 8. Symantec. 2009. “FAQ: Norton products and Mac OS X 10.6 (code-named Snow Leopard)”. Norton support website, DOCID 20090826171027EN, 31 August 2009. 9. Symantec. 2009. “Compatibility with Symantec AntiVirus for Macintosh 10.x and Mac OS X 10.6 Snow Leopard”, Symantec support website, Document ID 2009081911000448, 19 October 2009. 10. Symantec. 2009. “FAQ: Norton and

Windows 7”, Norton support website, DOCID: 20090605001726EN, 22 October 2009. 11. Apple. 2009. “Mac OS X v10.6: About incompatible software”, Apple Support website, 28 August 2009. 12. Kessler, T. 2009. “ClamXav updated to version 2.0.2, addressing Snow Leopard problems”, MacFixIt, CNET Reviews, 14 September 2009.< http://reviews. cnet.com/8301-13727_7-10352009263.html?tag=mncol;title – ClamXav> 13. Intego. 2009. “How the Anti-Malware Function in Apple’s Snow Leopard Works”, Intego Security Memo, 2 September 2009.
tion-in-apples-snow-leopard-works.asp> 14. Dilger, D.E. 2009. “Inside Mac OS X Snow Leopard: Malware Protection”, AppleInsider, 7 September 2009. < http:// www.appleinsider.com/articles/09/09/07/ inside_mac_os_x_snow_leopard_ malware_protection.html> 15. Dang, A. 2009. “Behind Pwn2Own: Exclusive Interview With Charlie Miller”, Tom’s Hardware, 25 March 2009. (accessed 20 September 2009). 16. See “Norton Internet Security for Mac OS X and Snow Leopard Support”, Discussion thread on ‘Norton Community: Norton Users Discussion Forum: Norton for Mac’. http://community.norton.com/norton/board/ message?board.id=norton_mac&thread. id=1104 (accessed 20 September 2009).

The perils of sharing Steve Mansfield-Devine Filesharing technologies, using peer-to-peer (P2P) networks, are shaping up to be one of the major threats of the coming year. They’re being exploited to spread and control malware and steal data. And attempts to limit or eliminate them could just drive the problem underground. According to researchers and analysts from Kaspersky, 2010 is going to be a bad year for filesharing. They believe that the P2P networks used by filesharers will begin to take over from websites as the key medium for spreading malware. And P2P technologies will be at the heart of new mass malware epidemics, like the TDSS and Virut breakouts we witnessed in 2009. These developments were at the top of Kaspersky’s predictions for this year.1 And while making predictions is notoriously fraught with dangers, these researchers are probably on a pretty safe bet. Alongside their portents of malware mayhem, you can add other P2P-based threats which can only gain in significance this year. Chief among these is the potential for the bad guys to lift files right off your hard disk – files you didn’t really mean to share.

January 2010

Pirate software Alongside unlawful music sharing, P2P networks have long been used for distributing so-called ‘warez’ – illegal copies of software, often with licence cracks so that software which would normally require authentication or registration before it works can be run without it. Anyone of a justifiably paranoid disposition would run a mile from such code. Aside from the legal implications, it seems blindingly obvious that some of this software is going to be supplied complete with malware. And so it has proved. For instance, in early 2009, a pirate version of Apple’s iWork ‘09 package, being freely distributed via BitTorrent, was found to contain the OSX.Trojan.iServices.A malware. On many Mac OS X systems, this was able to run automatically with root privileges.

Steve MansfieldDevine

“US Navy investigators were alarmed to find confidential documents about the new Marine 1 presidential helicopter programme available via Limewire.” It was quickly countered with AV software updates, but if the relatively malware-resistant OS X platform can be compromised this way, imagine what mayhem is being wrought every day by Windows-using filesharers. Some estimates – probably over-pessimistic but indicative – say that as much as half of shared proprietary software is infected. Open source software, by its very nature, is rarely compromised this way.

Accidental sharing There’s also the problem of sharing files when you don’t mean to. Filesharing

Network Security

11

P2P PERILS clients are designed to allow other people to access files directly from your computer. It’s important, then, that you control which files can be reached in this way. In the US, an as-yet unnamed defence worker learned this the hard way in 2009. US Navy investigators were alarmed to find confidential documents about the new Marine 1 presidential helicopter programme available via Limewire. At some point, these documents made their way to Iran.2 Poor configuration of a filesharing client can make available more of your files than you intend, and that seems to have been the case here. Typically, the result is not high-profile espionage but simple identity theft, as criminals scour P2P networks for people who are inadvertently sharing documents containing personal information. It’s possible that identity harvesting could represent an even more significant use of P2P networks than music downloads. In one case, reported by the Washington Post in 2008, an investment firm employee was using Limewire to share music, and also shared the names, dates of birth and Social Security numbers of around 2,000 of the company’s clients, including one Supreme Court judge. The leak was not discovered for six months and was eventually found not by the company but by a security researcher.3 On 26 February 2009, the Today show broadcast a piece about the dangers of filesharing. As part of its research it unearthed more than 150 000 tax returns, 25 800 student loan applications, and over 620 000 credit reports, as well as countless Social Security numbers, all on just one P2P network, and all found in a short space of time.

Command and control Around 2005, security researchers began debating the potential of P2P technologies for botnet control and malware distribution. But it wasn’t until 2007, with the arrival of the Storm worm, that this approach grabbed everyone’s attention. Until then, botnet control was largely a centralised effort, typically using IRC channels or HTTP-based mechanisms. 12

Network Security

The Nugache botnet, which emerged in early 2006, used P2P methods. However, in the early days it was easily countered by closing TCP port 8. Nugache evolved to use random high-numbered ports, yet it still wasn’t getting much attention – probably because of low volumes of activity – and in spite of some assertions that it grew to be larger than Storm, researchers David Dittrich and Sven Dietrich insist that it pretty much fell out of use.4 Storm adapted the Overnet P2P protocol (based on the Kademlia distributed hash table algorithm as also used by eDonkey) as a way of concealing its command and control servers, which resulted in improved stealth, anonymity and resilience. It also made it much harder for researchers to estimate the size of the botnet. One analysis concluded that these benefits were bought at the price of only a marginal drop in efficiency.5 The malicious code didn’t actually share any files. Storm’s P2P capabilities were used by each infected machine to find others similarly compromised. Some of these would be seeded with the information the trojan was seeking – a URL from which it would download secondstage executables. The URL itself, of course, regularly changed and the small amount of information exchanged by Storm’s P2P mechanism was encrypted. This is much harder to combat than if Storm used a hardwired URL.6 In 2008, we saw the emergence of the Peacomm botnet, which researchers Matthew Steggink and Igor Idziejcak claim was the first to have a fully decentralised P2P structure.7 The use of P2P protocols for both malware distribution and command and control is hard to detect using text-based or DNS-based signatures. And the decentralised nature makes it more difficult to take down a botnet built this way.

Fighting back Filesharing itself is under attack. France has already enacted the so-called Hadopi ‘three strikes’ law intended to deter copyright thieves. Other countries are looking to follow France’s lead, though some have gone to the brink and pulled back

in the face of criticism over what are seen as heavy-handed tactics. In any case, even with the threat of criminal proceedings and the risk of malware infection, millions will continue to share files. Attempts to stop them may just drive the problem underground.

“In attempting to crush illegal filesharing, threats of legal action may simply make it much harder to detect – and to guard against” “One thing filesharers might do is simply to start using SSL,” says Neil O’Neil, principal digital forensics investigator and ethical hacker at the Logic Group. “Current BitTorrent downloads use their own ports and unencrypted protocols, so at the firewall and proxies you can monitor traffic content and prove or stop illegal download of materials. SSL ports are generally open on all routers and firewalls and because the communication and payload is encrypted, you can’t see what’s in there.” In addition, we are seeing the emergence of anonymised internet services that disguise the content of traffic and both source and destination of data. For example, ItsHidden employs VPN technology to encrypt all traffic between users and its own servers. In attempting to crush illegal filesharing, threats of legal action may simply make it much harder to detect – and to guard against. For example, many organisations found that protecting themselves against the Storm worm was made easier by the ability to detect its P2P traffic. By emulating Overnet protocols, it used ports that security practitioners could eliminate with suitably configured firewall rules or by watching for the classic signs of P2P traffic. When Storm re-emerged in 2009, it no longer used these somewhat ‘noisy’ P2P mechanisms, having reverted to an HTTPbased approach, and malware fighters were forced to adopt different methods of fighting the menace. For the time being, the banning of filesharing clients within the corporate network, and the use of firewall rules to bar P2P traffic will go a long way to

January 2010

SECURING IP NETWORKS eliminating the collateral damage of P2P applications. However, this won’t address the vulnerability of files held on laptops or homeworkers’ PCs used beyond the organisation’s boundaries. For the time being, your best defence in these circumstances is education about the dangers. But we all know how effective that is.

References 1. Kaspersky Lab issues 2010 cyberthreat forecast, Kaspersky, December 15 2009 2. Navy Releases New Information On Presidential Security Leak, WPXI Pittsburgh, February 28 2009
www.wpxi.com/news/18818589/ detail.html> 3. Justice Breyer Is Among Victims in Data Breach Caused by File Sharing, Washington Post, July 9 2008 4. David Dittrich and Sven Dietrich. ‘P2P as botnet command and control: a deeper insight’. In Proceedings of the 3rd International Conference On Malicious and Unwanted Software (Malware 2008). IEEE Computer Society, October 2008.

5. Davis, Neville, Fernandez, Robert and McHugh, ‘Structured Peer-to-Peer Overlay Networks: Ideal botnets command and control infrastructures?’ 2008, 6. Storm Worm DDoS Attack, SecureWorks, Feburary 8 2007 7. Matthew Steggink and Igor Idziejcak, ‘Detection of peer-to-peer botnets’, University of Amsterdam, February 2008

Securing IP networks Sindhu Xirasagar, communication processor software product manager and Masoud Mojtahed, applications architect, LSI Corporation In part one of this two-part series on securing IP networks, the issues and technologies involved with securing these networks were addressed. We discussed how the evolution of packet-switched networks has driven the need for scalable security solutions. In this second and final installment, we’ll address the necessary specifications for the silicon, software and hardware platforms that can enable applications with packet processing at up to 3Gbps and IPsec processing at up to 1.5Gbps for all applications.

Implementing secure networks: OEM perspectives A viable security solution for emerging security requirements must provide fast and accurate IPsec processing, with minor incremental increase in cost and power. With increasing adoption of IPsec for user data traffic as well as control and management traffic, throughput requirements of over 1Gbps are becoming commonplace. Bulk crypto processors are not optimal for meeting these performance requirements due to unacceptable increases in associated cost and power. The ideal solution includes high-performance packet processors with embedded security engines that can process all networking functions and support inline IPsec processing without host intervention. Further, the embedded IPsec engine must

January 2010

have comprehensive support for the various encryption and authentication algorithms. Ideally, the silicon is also capable of providing some hardware acceleration for compute-intensive security key generation functions.

“Processors that support IPsec processing must be available as a family of devices that scale along a range of cost, performance and power to enable component re-use.” Wireless and enterprise markets require that OEMs offer a broad portfolio of products supporting a range of performance at different cost points. In today’s cost-sensitive environment, managing the total cost of ownership (TCO) including development, maintenance, support and operational costs, is critical to business success. Component re-use

across the product portfolio enables engineering and operational resources to be leveraged and minimises the need for expensive test equipment, thus significantly reducing TCO. Processors that support IPsec processing must be available as a family of devices that scale along a range of cost, performance and power to enable component re-use. Time-to-market is a perennial challenge for OEMs. Today, silicon devices have become complex subsystems, and it is very time and resource intensive for OEMs to learn internal details of the device and program it at a register level. The silicon vendor must also provide device configuration and management software with well-abstracted, application programming interfaces (API). To support IPsec, the API should support configuring the embedded IPsec engine to run different algorithms, update Security Association (SA) and Security Policy (SP) information, and so on. OEMs can integrate this runtime software directly into their application and focus their own efforts on application development and system integration. Software-related costs dominate system TCO. Software reuse is a key element of minimising software-related costs. Ideally,

Network Security

13