Hackers gebruiken nieuw lek in Internet Explorer 8

De details van hoe een nieuw beveiligingslek in Internet Explorer 8 is te misbruiken zijn voor iedereen openbaar geworden, nu de exploit aan een populaire hackertool is toegevoegd. Dit weekend werd bekend dat een onbekende kwetsbaarheid actief in Microsoft's browser was gebruikt bij een 'drinkplaats-aanval'. Aanvallers hadden de website van het Amerikaanse Ministerie van Werkgelegenheid gehackt.

Op de gehackte website werd de exploit geplaatst. Bij een drinkplaats-aanval zijn individuen het doelwit die uit zichzelf de gehackte website bezoeken en zo besmet raken. Microsoft bevestigde de aanwezigheid van het lek in Internet Explorer 8 op Windows XP, Vista, Windows 7, Server 2003 en Server 2008 en werkt aan een beveiligingsupdate.

Oplossing
Om misbruik te voorkomen kunnen gebruikers de instellingen van de browser aanpassen of naar een nieuwere IE-versie te upgraden, aangezien het lek daar niet aanwezig in is. IE9 en IE10 werken niet op Windows XP, waardoor het upgraden naar een alternatieve browser ook een oplossing is.

De kans op grootschalig misbruik van het lek is namelijk toegenomen nu de details openbaar zijn gemaakt. Een exploit is aan de populaire hackertool Metasploit toegevoegd. Metasploit is een 'framework' waarmee security professionals en penetratietesters de veiligheid van systemen en netwerken kunnen testen.

Browser
Daardoor zijn de details nu voor iedereen toegankelijk. Metasploit-ontwikkelaar 'sinn3r' adviseert gebruikers van Vista of een nieuwere Windows-versie naar IE9 of IE10 te upgraden. Windows XP-gebruikers doen er verstandig aan om een andere browser te gebruiken, zoals Google Chrome of Mozilla Firefox.

Sinn3r stelt dat één van de adviezen van Microsoft niet klopt. De softwaregigant adviseerde om de instelling van ActiveX controls te wijzigen, maar dit zou de exploit niet voorkomen, aangezien de aanval geen ActiveX controls gebruikt.

Beveiligingsonderzoeker Eric Romang heeft inmiddels een video gemaakt waarin de Metasploit-exploit wordt gedemonstreerd.

Bron: Security.nl

Hijacking airplanes with an Android phone

An extremely well attended talk by Hugo Teso, a security consultant at n.runs AG in Germany, about the completely realistic scenario of plane hijacking via a simple Android app has galvanized the crowd attending the Hack In The Box Conference in Amsterdam today.

Teso, who has been working in IT for the last eleven years and has been a trained commercial pilot for a year longer than that, has combined his two interests in order to bring to light the sorry state of security of aviation computer systems and communication protocols.

By taking advantage of two new technologies for the discovery, information gathering and exploitation phases of the attack, and by creating an exploit framework (SIMON) and an Android app (PlaneSploit) that delivers attack messages to the airplanes' Flight Management Systems (computer unit + control display unit), he demonstrated the terrifying ability to take complete control of aircrafts by making virtual planes "dance to his tune."

One of the two technologies he abused is the Automatic Dependent Surveillance-Broadcast (ADS-B), which sends information about each aircraft (identification, current position, altitude, and so on) through an on-board transmitter to air traffic controllers, and allows aircrafts equipped with the technology to receive flight, traffic and weather information about other aircrafts currently in the air in their vicinity.

The other one is the Aircraft Communications Addressing and Reporting System (ACARS), which is used to exchange messages between aircrafts and air traffic controllers via radio or satellite, as well as to automatically deliver information about each flight phase to the latter.

Both of these technologies are massively insecure and are susceptible to a number of passive and active attacks. Teso misused the ADS-B to select targets, and the ACARS to gather information about the onboard computer as well as to exploit its vulnerabilities by delivering spoofed malicious messages that affect the "behavior" of the plane.

Based on his own research, Teso developed the SIMON framework that is deliberately made only to work in a virtual environment and cannot be used on real-life aircrafts. His testing laboratory consists of a series of software and hardware products, but the connection and communication methods, as well as ways of exploitation, are absolutely the same as they would be in an actual real-world scenario.

Since it's nearly impossible to detect the framework once deployed on the Flight Management System, there is no need to disguise it like a rootkit. By using SIMON, the attacker can upload a specific payload to the remote FSM, upload flight plans, detailed commands or even custom plugins that could be developed for the framework.

To make things even more interesting - or easier - Teso showcased an Andorid application that uses SIMON's powers to remotely control airplanes on the move. The application, fittingly named PlaneSploit, sports a clean and simple interface, but is packed full with features. This is a remarkable example of technology evolution - ten years ago we barely had phones with a color screen, today we can use them to hack aircrafts.

PlaneSploit uses the Flightradar24 live flight tracker and you can tap on any airplane found in range. When talking about the range, please keep in mind that we are talking about a proof-of-concept application used in a virtual environment. In real life, the range would be limited depending on the antennas used (if going directly for the plane), or global (if misusing one of the two big ACARS players such as SITA or ARINC).

The user interface is divided by its main functions which are self-explanatory: discovery, information gathering, exploitation and post exploitation. The attacker can click on any active airplane and is receives its identification, current location and final destination. In case a nearby airplane system is exploitable (a number of vulnerability vectors mentioned, not much details provided), the application alerts the user via an in-application alert or a push message. The payload can be uploaded with a tap of a button and from that point on, the flight management system is remotely controlled by an attacker. There are a number of other systems connected to FMS, so further exploitation is possible.

Here are some of the functions Teso showed to the HITBSecConf Amsterdam audience:

• Please go here: A way of interacting with the plane where the user can dynamically tap locations on the map and change the plane's course.
• Define area: Set detailed filters related to the airplane, for example activate something when a plane is in the area of X kilometers or when it starts flying on a predefined altitude.
• Visit ground: Crash the airplane.
• Kiss off: Remove itself from the system.
• Be punckish: A theatric way of alerting the pilots that something is seriously wrong - lights start flashing and alarms start buzzing.

By showing a sample scenario of a drunk pilot flying over Berlin, Teso mentioned that the Android application also uses the benefits of the accelerometer and therefore a remote attacker can transform the motion of its smartphone into physical changes in the plane's movement.

It's amazing to discover that aviation - an industry where safety is of vital importance and every physical element has one or even two fail-safe mechanisms - is failing to secure the onboard computer, the heart and brain of the plane.

Teso has not shared too many details about the tools he used to effect the attack, as the vulnerabilities have yet to be fixed. He says that he was pleasantly surprised by the reaction of the industry to his research and discoveries, as the companies didn't try to deny the existence of the problems and have vowed to aid him in his research.

He says that older, legacy systems harking back to the 1970s will be difficult, if not impossible, to fix, but that modern ones will easily be updated with patched and modified firmware and software.

The vulnerabilities, of course, differ from system to system and from plane to plane, but it's easy to discover just which ones are present once the attacker identifies the type, model of the plane, and the airline for which it flies.

There is a solution for pilots to regain the control of the plane and land it safely, he says. Attacks of this kind work only when the auto-pilot is on, so the trick is to switch it off, then fly the plane by using analog instruments.

The bad news is that there aren't that many on modern planes, and that the pilots have to detect that the plane's computer is being hacked in order to effect these maneuvers, and that is no easy feat.

Bron: Netsecurity

Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines

The Twenty Critical Security Controls have already begun to transform security in government agencies and other large enterprises by focusing their spending on the key controls that block known attacks and find the ones that get through. With the change in FISMA reporting implemented on June 1, the 20 Critical Controls become the centerpiece of effective security programs across government These controls allow those responsible for compliance and those responsible for security to agree, for the first time, on what needs to be done to make systems safer. No development in security is having a more profound and far reaching impact.

These Top 20 Controls were agreed upon by a powerful consortium brought together by John Gilligan (previously CIO of the US Department of Energy and the US Air Force) under the auspices of the Center for Strategic and International Studies. Members of the Consortium include NSA, US Cert, DoD JTF-GNO, the Department of Energy Nuclear Laboratories, Department of State, DoD Cyber Crime Center plus the top commercial forensics experts and pen testers that serve the banking and critical infrastructure communities.

The automation of these Top 20 Controls will radically lower the cost of security while improving its effectiveness. The US State Department, under CISO John Streufert, has already demonstrated more than 94% reduction in "measured" security risk through the rigorous automation and measurement of the Top 20 Controls.

20 Critical Security Controls - Version 4.1

• Critical Control 1: Inventory of Authorized and Unauthorized Devices
• Critical Control 2: Inventory of Authorized and Unauthorized Software
• Critical Control 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
• Critical Control 4: Continuous Vulnerability Assessment and Remediation
• Critical Control 5: Malware Defenses
• Critical Control 6: Application Software Security
• Critical Control 7: Wireless Device Control
• Critical Control 8: Data Recovery Capability
• Critical Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps
• Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
• Critical Control 11: Limitation and Control of Network Ports, Protocols, and Services
• Critical Control 12: Controlled Use of Administrative Privileges
• Critical Control 13: Boundary Defense
• Critical Control 14: Maintenance, Monitoring, and Analysis of Audit Logs
• Critical Control 15: Controlled Access Based on the Need to Know
• Critical Control 16: Account Monitoring and Control
• Critical Control 17: Data Loss Prevention
• Critical Control 18: Incident Response and Management
• Critical Control 19: Secure Network Engineering
• Critical Control 20: Penetration Tests and Red Team Exercises

Bron: Sans

How Spamhaus’ attackers turned DNS into a weapon of mass destruction

A little more than a year ago, details emerged about an effort by some members of the hacktivist group Anonymous to build a new weapon to replace their aging denial-of-service arsenal. The new weapon would use the Internet's Domain Name Service as a force-multiplier to bring the servers of those who offended the group to their metaphorical knees. Around the same time, an alleged plan for an Anonymous operation, "Operation Global Blackout" (later dismissed by some security experts and Anonymous members as a "massive troll"), sought to use the DNS service against the very core of the Internet itself in protest against the Stop Online Piracy Act.
This week, an attack using the technique proposed for use in that attack tool and operation—both of which failed to materialize—was at the heart of an ongoing denial-of-service assault on Spamhaus, the anti-spam clearing house organization. And while it hasn't brought the Internet itself down, it has caused major slowdowns in the Internet's core networks.
DNS Amplification (or DNS Reflection) remains possible after years of security expert warnings. Its power is a testament to how hard it is to get organizations to make simple changes that would prevent even recognized threats. Some network providers have made tweaks that prevent botnets or "volunteer" systems within their networks to stage such attacks. But thanks to public cloud services, "bulletproof" hosting services, and other services that allow attackers to spawn and then reap hundreds of attacking systems, DNS amplification attacks can still be launched at the whim of a deep-pocketed attacker—like, for example, the cyber-criminals running the spam networks that Spamhaus tries to shut down.

Hello, operator?

The Domain Name Service is the Internet's directory assistance line. It allows computers to get the numerical Internet Protocol (IP) address for a remote server or other network-attached device based on its human-readable host and domain name. DNS is organized in a hierarchy; each top-level domain name (such as .com, .edu, .gov, .net, and so on) has a "root" DNS server keeping a list of each of the "authoritative" DNS servers for each domain registered with them. If you've ever bought a domain through a domain registrar, you've created (either directly or indirectly) an authoritative DNS address for that domain by selecting the primary and secondary DNS servers that go with it.
When you type "arstechnica.com" into your browser's address bar and hit the return key, your browser checks with a DNS resolver—your personal Internet 411 service— to determine where to send the Web request. For some requests, the resolver may be on your PC. (For example, this happens if you've requested a host name that's in a local "hosts" table for servers within your network, or one that's stored in your computer's local cache of DNS addresses you've already looked up.) But if it's the first time you've tried to connect to a computer by its host and domain name, the resolver for the request is probably running on the DNS server configured for your network—within your corporate network, at an Internet provider, or through a public DNS service such as Google's Public DNS.
There are two ways for a resolver to get the authoritative IP address for a domain name that isn't in its cache: an iterative request and a recursive request. In an iterative request, the resolver pings the top-level domain's DNS servers for the authoritative DNS for the destination domain, then it sends a DNS request for the full hostname to that authoritative server. If the computer that the request is seeking is in a subdomain or "zone" within a larger domain—such as www.subdomain.domain.com—it may tell the resolver to go ask that zone's DNS server. The resolver "iterates" the request down through the hierarchy of DNS servers until it gets an answer.
But on some networks, the DNS resolver closest to the requesting application doesn't handle all that work. Instead, it sends a "recursive" request to the next DNS server up and lets that server handle all of the walking through the DNS hierarchy for it. Once all the data is collected from the root, domain, and subdomain DNS servers for the requested address, the resolver then pumps the answer back to its client.

How DNS queries are supposed to work—when they're not being used as weapons.

To save time, DNS requests don't use the "three-way handshake" of the Transmission Control Protocol (TCP) to make all these queries. Instead, DNS typically uses the User Datagram Protocol (UDP)—a "connectionless" protocol that lets the server fire and forget requests.

Pump up the volume

That makes the sending of requests and responses quicker—but it also opens up a door to abuse of DNS that DNS amplification uses to wreak havoc on a target. All the attacker has to do is find a DNS server open to requests from any client and send it requests forged as being from the target of the attack. And there are millions of them.
The "amplification" in DNS amplification attacks comes from the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the attackers' victim.
DNS amplification attacks wouldn't be nearly as amplified if it weren't for the "open" DNS servers they use to fuel the attacks. These servers have been configured (or misconfigured) to answer queries from addresses outside of their network. The volume of traffic that can be generated by such open DNS servers is huge. Last year, Ars reported on a paper presented by Randal Vaughan of Baylor University and Israeli security consultant Gadi Evron at the 2006 DefCon security conference. The authors documented a series of DNS amplification attacks in late 2005 and early 2006 that generated massive traffic loads for the routers of their victims. In one case, the traffic was "as high as 10Gbps and used as many as 140,000 exploited name servers," Vaughan and Evron reported. "A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60."
But even if you can't find an open DNS server to blast recursive responses from, you can still depend on the heart of the Internet for a respectable hail of packet projectiles. A "root hint" request—sending a request for name servers for the "." domain—results in a response 20 times larger than the packet the request came in. That's in part thanks to DNS-SEC, the standard adopted to make it harder to spoof DNS responses, since now the response includes certificate data from the responding server.

A comparison of a "root hint" query and the response delivered by the DNS server. Not all data shown.

 

 

 

In the case of the attack on Spamhaus, the organization was able to turn to the content delivery network CloudFlare for help. CloudFlare hid Spamhaus behind its CDN, which uses the Anycast feature of the Border Gateway Protocol to cause packets destined for the antispam provider's site to be routed to the closest CloudFlare point of presence. This spread out the volume of the attack. And CloudFlare was able to then shut off amplified attacks aimed at Spamhaus with routing filters that blocked aggregated DNS responses matching the pattern of the attack.
But that traffic still had to get to Cloudflare before it could be blocked. And that resulted in a traffic jam in the core of the Internet, slowing connections for the Internet as a whole.

No fix on the horizon

The simplest way to prevent DNS amplification and reflection attacks would be to prevent forged DNS requests from being sent along in the first place. But that "simple" fix isn't exactly easy—or at least easy to get everyone who needs to participate to do.
There's been a proposal on the books to fix the problem for nearly 13 years—the Internet Engineering Task Force's BCP 38, an approach to "ingress filtering" of packets. First pitched in 2000  1998 as part of RFC 2267 , the proposal has gone nowhere. And while the problem would be greatly reduced if zone and domain DNS servers simply were configured not to return recursive or even "root hint" responses received from outside their own networks, that would require action by the owners of the network. It's an action that doesn't have a direct monetary or security benefit to them associated with it.
ISPs generally do "egress filtering"—they check outbound traffic to make sure it's coming from IP addresses within their network.  This prevents them from filling up their peering connections with bad traffic.  But "ingress" filtering would check to make sure that requests coming in through a router were coming from the proper direction based on their advertised IP source.
Another possible solution that would eliminate the problem entirely is to make DNS use TCP for everything—reducing the risk of forged packets.  DNS already uses TCP for tasks like zone transfers. But that would require a change to DNS itself, so it's unlikely that would ever happen, considering that you can't even convince people to properly configure their DNS servers to begin with.
Maybe the attack on Spamhaus will change that, and core network providers will move to do more to filter DNS traffic that doesn't seem to match up with known DNS servers. Maybe just maybe, BCP 38 will get some traction. And maybe pigs will fly.

Bron: Arstechnica

Details on the denial of service attack that targeted Ars Technica

Last week, Security Editor Dan Goodin posted a story about the "swatting" of security reporter Brian Krebs and the denial of service attack on Krebs' site. Soon after, Ars was targeted by at least one of the individuals behind the Krebs attack. On Friday, at about noon Eastern Daylight Time, a denial of service attack struck our site, making connectivity to Ars problematic for a little less than two hours.
The attack continued to run throughout Friday. At 9pm EDT, when our hosting provider brought down one of the filters that had been put in place to thwart it, it quickly became apparent that the attack was still underway, and the filter was restored. The most aggressive filters were finally removed on Saturday.
At least in part, the offensive used the same attack tool and user credentials that were involved in the denial-of-service (DoS) attack on Krebs On Security, as Krebs himself revealed in a blog post. The attackers used multiple accounts on TwBooter, a "booter" site that provides denial of service attacks as a paid service (ostensibly for security testing purposes), to launch an automated, denial of service attack on Ars. And at least one of those logins was also used to attack Krebs' site.
TwBooter masks all of the complexity of launching attacks against sites. Users of the site can, depending on how much they pay, launch up to three simultaneous automated attacks against sites through a simple Web interface. TwBooter users can even set up multiple accounts and fill up the queue of the service's "attack server."

Individual accounts using TwBooter's server can be "licensed" for up to three simultaneous attacks lasting up to two hours, if you can come up with the cash. Free plans can be set up in exchange for filling out a few surveys.

It doesn't cost much to get in on the ground floor with TwBooter—an account with rights to a single automated attack of up to 60 seconds in length is $10 for a month. This means you can launch as many 60 second attacks as you want, one at a time, all month long. The "license" to launch up to three attacks at a time of up to two hours duration is $169 a month—but there's a 20 percent discount if you pay through Liberty Reserve instead of PayPal. There's also a free plan that allows for attacks up to 300 seconds long. That service requires users to pick an attack type from a pull-down menu in a Web form.

The Web form for launching attacks from TwBooter's free attack service.

PayPal payments for the site are routed to Sebastien Lariviere, a former IT technician for the county government (MRC) of Pierre-De Saurel in Quebec (now operating as Lariviere Security). Lariviere did not respond to e-mails from Ars for comment.
Obviously, sites like TwBooter generate a lot of ill will and are ironically the target of DoS attacks themselves. Like many legitimate and "black hat" sites—such as the site exposed.su, a website that recently posted the personal information of many public figures—TwBooter runs behind the CloudFlare content delivery network as a way of shielding itself from attacks.
TwBooter may not have been the only service used to launch the attacks on Ars and Krebs. "There are dozens of these booter services out there, most of them based on the same source code," Krebs told Ars. But Krebs received a tip pointing to a dump of TwBooter's customer database—openly accessible on the services' website. It's clear the TwBooter site was part of the attack. A snippet from the SQL dumps Krebs provided to Ars show that multiple attacks (including Slowloris, TCP amplification, and SYN flood attacks) were queued up by multiple accounts on the site.

Pick your poison

Some of the attacks served up by TwBooter are targeted at Web servers themselves. For example, HTTP Get and Post attacks attempt to overwhelm the ability of the targeted server to respond by filling up buffer memory with requests. But there were a few attacks thrown at Ars that don't require the massive traffic of a million-PC botnet.
Slowloris, for example, takes a less brute-force approach—it's a slow HTTP attack that exploits a misconfiguration of the Apache Web server. It sends partial HTTP requests to its intended victim, which forces the server to keep the connection open while waiting for the rest. Because it relies on very little traffic to do the job, it doesn't have to be distributed to work. But since it's dependent on the target being an Apache server that hasn't been tweaked against the slow HTTP style attack, it's not very effective against high-volume Web servers (especially sites using NGINX Web servers, like Ars).
Another attack used against Ars was the RUDY, or R-U-Dead-Yet attack, which also uses relatively few packets. Instead of sending partial requests, it sends what seems like an unending HTTP POST, sending a very large value for content-length in the POST request header. That keeps the server waiting for the rest of the POST to come until the length is reached... which never happens.
Other attacks in the "booter" arsenal go after the network connections of the targets themselves. SYN Flood attacks, for example, attempt to overwhelm the target's network connection by creating a huge volume of "half-open" network connections, using the nature of the TCP protocol's "three-way handshake" to use up server resources. The attacker sends SYN, or "synchronize," requests to the target; the target responds with a synchronization acknowledgement (SYN-ACK), which would normally prompt a return acknowledgement (ACK) message from a legitimate user connection. Instead, the attacker never sends ACK packets back, and the target is left with unfinished connections filling up its network buffers until it can't handle any more connections. These packets are usually sent with forged headers (since the attacker never has to actually get the SYN-ACK from the server), so they're difficult to trace and can appear to be more distributed than they actually are.
Another attack type flung at Ars was a UDP-LAG attack. It just uses a large stream of UDP packets in an attempt to overwhelm a target's network connection and knock them offline. UDP-LAG attacks on "booter" services are often used by online gamers who want to slow down the network connections of a competitor. This way, they can camp on their location and kill them while they lag, respawn, and lag some more. Because they use UDP packets, UDP-LAG attacks in large volume can look like DNS amplification attacks—attacks that use responses from DNS servers to spoofed requests that give the address of the target.

Shrugging it off

Fortunately, Ars' hosting provider was able to quickly identify the attacks that were causing the most damage to site availability. Our IT team alerted our provider to the problem at 12:09pm EDT on Friday; the problem was mostly in hand by 1:30pm through the application of traffic filters at the provider's router.
But the fact remains that anyone with some spare change, spare time, and an axe to grind can turn to sites like TwBooter and stage DOS attacks at will—with little fear of retribution. The sites come and go, hiding behind the thin veil of a "terms of service" agreement that asks users, pretty please, to not misuse their attack servers. These booters profess that they are for "security professionals only"—yet they do little to track the actual identities of those who use the servers.

Bron: Ars technica

SSHD rootkit in the wild

There are a lot of discussions at the moment about a SSHD rootkit hitting mainly RPM based Linux distributions.

Thanks to our reader unSpawn, we received a bunch of samples of the rootkit. The rootkit is actually a trojanized library that links with SSHD and does *a lot* of nasty things to the system.
At this point in time we still do not know what the initial attack vector is – it is unknown how the attackers get root access on the compromised servers that is needed to change the legitimate libkeyutils library with a trojanized one. We are, of course, keeping an eye on the development and will post a new diary or update this one if we receive more information about the attack vectors.
The trojanized library is very, very nasty. Upon execution it performs a number of actions, as described below.

The code first deobfuscates the text strings needed for it to work. The original text is only XORed so this is very easy to retrieve and the deobfuscated strings have already been posted on a lot of sites.
Once that has been done, the library sets up everything needed for it to work. It resolves symbols for the following functions which are used later: PEM_write_RSAPrivateKey, PEM_write_DSAPrivateKey, MD5_Init, MD5_Update, and MD5_Final. As you can already see, it is definitely messing up with the authentication mechanism.

Besides resolving the symbols, the library also hooks the following functions: pam_authenticate, pam_start and crypt as well as audit_log_user_message and audit_log_acct_message. By hooking these functions, the rootkit can modify the flow of the SSHD – as you can see, this is a user-mode rootkit, as it does not affect the kernel.

The main activity of the rootkit consists in collection of credentials of authenticated users. Notice that the rootkit can steal username and password pairs as well as RSA and DSA private keys, so no matter which authentication mechanism you use, if the target host is infected it will successfully steal your information. The hooking of audit_log* functions was done to allow the attacker to stay as low profile as possible – if the attacker uses the hardcoded backdoor password to issue any commands to the rootkit, no logs will be created.

The current version of the rootkit supports three commands: Xver, Xcat and Xbnd. The first command just prints the rootkit’s version; the Xcat commands print the collected information back in the session for the attacker while the Xbnd command allows the attacker to setup a listener.
Besides this, the rootkit can automatically send collected credentials to the attacker. In order to do this the rootkit has a DGA (Domain Generation Algorithm) implemented that will create random looking domain names in the .biz, .info and .net domains (in that order). It will then send a DNS packet containing collected credentials to the target IP address, if it was able to resolve it (meaning the attacker has registered that day’s domain). If no domains have been resolved, the DNS packet is sent to the hard-coded IP address, which in all samples we received was 78.47.139.110.

The rootkit itself looks very similar to the Ebury trojan which was detected back in 2011. In fact, I’m pretty sure that a lot of the code has been directly copied, however, the Ebury trojan patched the whole SSHD and required the attacker to change it.

This was easier to detect and prone to being overwritten with patching. The libkeyutils library, which comes as part of the keyutils-libs package is not changed that often so the chance of it being overwritten automatically is much lower.

If you run a RPM based system you can check the integrity of the file with the rpm command:
# rpm -Vv keyutils-libs-1.2-1.el5
........    /lib/libkeyutils-1.2.so
S.5.....    /lib/libkeyutils.so.1
........    /usr/share/doc/keyutils-libs-1.2
........  d /usr/share/doc/keyutils-libs-1.2/LICENCE.LGPL

This will check a lot of things, the most important being the MD5 checksum so if you see the output as one above you have a trojanized library. Proper output should have all (and only) dots. Keep in mind that the RPM’s verification, of course, depends on the integrity of its database and the kernel itself.

Bron: ISC

Mandiant Exposes APT1 – One of China’s Cyber Espionage Units & Releases 3,000 Indicators

Today, The Mandiant® Intelligence Center™ released an unprecedented report exposing APT1′s multi-year, enterprise-scale computer espionage campaign.  APT1 is one of dozens of threat groups Mandiant tracks around the world and we consider it to be one of the most prolific in terms of the sheer quantity of information it has stolen.

Highlights of the report include:

• Evidence linking APT1 to China’s 2nd Bureau of the People’s Liberation Army (PLA) General Staff Department’s (GSD) 3rd Department (Military Cover Designator 61398).
• A timeline of APT1 economic espionage conducted since 2006 against 141 victims across multiple industries.
• APT1′s modus operandi (tools, tactics, procedures) including a compilation of videos  showing actual APT1 activity.
• The timeline and details of over 40 APT1 malware families.
• The timeline and details of APT1′s extensive attack infrastructure.

Mandiant is also releasing a digital appendix with more than 3,000 indicators to bolster defenses against APT1 operations. This appendix includes:

• Digital delivery of over 3,000 APT1 indicators, such as domain names, IP addresses, and MD5 hashes of malware.
• Thirteen (13) X.509 encryption certificates used by APT1.
• A set of APT1 Indicators of Compromise (IOCs) and detailed descriptions of over 40 malware families in APT1′s arsenal of digital weapons.
• IOCs that can be used in conjunction with Redline™, Mandiant’s free host-based investigative tool, or with Mandiant Intelligent Response® (MIR), Mandiant’s commercial enterprise investigative tool.

The scale and impact of APT1′s operations compelled us to write this report.  The decision to publish a significant part of our intelligence about Unit 61398 was a painstaking one.  What started as a “what if” discussion about our traditional non-disclosure policy quickly turned into the realization that the positive impact resulting from our decision to expose APT1 outweighed the risk of losing much of our ability to collect intelligence on this particular APT group.  It is time to acknowledge the threat is originating from China, and we wanted to do our part to arm and prepare security professionals to combat the threat effectively.  The issue of attribution has always been a missing link in the public’s understanding of the landscape of APT cyber espionage.  Without establishing a solid connection to China, there will always be room for observers to dismiss APT actions as uncoordinated, solely criminal in nature, or peripheral to larger national security and global economic concerns.  We hope that this report will lead to increased understanding and coordinated action in countering APT network breaches.
We recognize that no one entity can understand the entire complex picture that many years of intense cyber espionage by a single group creates.  We look forward to seeing the surge of data and conversations a report like this will likely generate.
You can download the report, the appendices and view the video showing APT1 attacker activity at http://www.mandiant.com/apt1.

Bron: Mandiant