Hardware keyloggers have been discovered in public libraries in Greater Manchester

Hardware keyloggers have been discovered in public libraries in Greater Manchester.
Two USB devices, attached to keyboard sockets on the back of computers in Wilmslow and Handforth libraries, would have enabled baddies to record every keystroke made on compromised PCs. It's unclear who placed the snooping devices on the machines but the likely purpose was to capture banking login credentials on the devices prior to their retrieval and use in banking fraud.
A third detected device was discovered but disappeared before it was turned over to local police, the Manchester Evening News reports.
Many members of the public use library computer access either for convenience or because they don't have a computer at home. The targeted libraries are in up-market districts on the southern outskirts of Greater Manchester. A BBC report on the incident has footage of one of the affected computers. The presumed scam, which had been going on for an as yet undetermined period, was only rumbled after staff examined one of the compromised PCs, which had begun misbehaving.
Library staff have been advised to keep a close eye on computers to help prevent the reccurrence of similar incidents in future. In addition, rules have been revised so that USB keyboards are plugged into the more visible front ports of a computer rather than its rear. PCs in Manchester libraries come fitted with net-nanny software and accounts that limit the ability of users to install software on machines. Cybercrooks have apparently found a way around these restrictions using hardware keyloggers, which are readily available at prices of around 30 or less.
The two confiscated devices are been examined by Cheshire polices hi-tech crime unit.

Stuxnet Had Five Targets

Graphic showing clusters of Stuxnet infections during targeted attacks launched in 2009 and 2010. Courtesy of Symantec.
Attackers behind the Stuxnet computer worm focused on targeting five organizations in Iran that they believed would get them to their final target in that country,accordingto anew report from security researchers.
The five organizations, believed to be the first that were infected with the worm, were targeted in five separate attacks over a number of months in 2009 and 2010, before Stuxnet was discovered in June 2010 and publicly exposed. Stuxnet spread from these organizations into other organizations on its way to its final target, which is believed to have been a nuclear enrichment facility or facilities in Iran.
“These five organizations were infected, and from those five computers Stuxnet spread out — not to just computers in those organizations, but to other computes as well,” says Liam O Murchu, manager of operations for Symantec Security Response. “It all started with those five original domains.”
The new information comes in an updated report from researchers at Symantec (.pdf), a computer security firm that has provided some of the leading analysis of the worm since it was discovered.
According to the report, Stuxnet’s first attack against the five organizations occurred in June 2009, followed by a second attack in July 2009. Eight months passed before subsequent attacks were launched in March, April and May 2010. The last attack was just one month before the code was discovered in June 2010 by VirusBlokAda, a security firm in Belarus, which said it had found the malware on computers of unspecified clients in Iran.
Symantec didn’t identify the names of the five organizations that were targeted; the company said only that all five “have a presence in Iran” and are involved in industrial processes. One of the organizations (what Symantec refers to as Domain B) was targeted with the worm in three of the five attacks. Of the remaining organizations, three of them were hit once, and the last organization was targeted twice.
Symantec has so far been able to count a constellation of 12,000 infections in the five organizations and outside organizations to which the malware spread. The most successful attack occurred in March 2010 when 69 percent of these infections occurred. The March attack targeted only Domain B, then spread.
Domain A was targeted twice (Jun 2009 and Apr 2010). The same computer appears to have been infected each time.
Domain B was targeted three times (Jun 2009, Mar 2010, and May 2010).
Domain C was targeted once (Jul 2009).
Domain D was targeted once (Jul 2009).
Domain E appears to have been targeted once (May 2010), but had three initial infections. (I.e., the same initially infected USB key was inserted into three different computers.)
O Murchu acknowledges that there could have been earlier attacks that occurred before June 2009, but no one has found evidence of this yet.
Symantec found that the shortest time between when the malware was compiled in one case — that is turned from source code into a working piece of software — and the subsequent attack using the code occurred, was just 12 hours. This occurred in the June 2009 attack.
“This tells us that the attackers more than likely knew who they wanted to infect before they completed the code,” O Murchu says. “They knew in advance who they wanted to target and how they were going to get it there.”
Stuxnet was not designed to spread via the internet but via an infected USB stick or some other targeted method within a local network. So the short timeframe between compilation and the launch of the June 2009 attack also suggests that the attackers had immediate access to the computer they attacked — either working with an insider or using an unwitting insider to introduce the infection.

“It could be they sent it to someone who put it on a USB key, or it could have been delivered via spear-phishing,” O Murchu says. “What we do see is that the exploits in Stuxnet are all land-based, so it is not going to spread wildly on the internet. From that, we can assume the attackers wanted to deliver Stuxnet to an organization that was very close to whatever the final destination for Stuxnet was.”
Symantec, working with other security firms, has so far been able to collect and examine 3,280 unique samples of the code. Stuxnet has infected more than 100,000 computers in Iran, Europe and the United States, but it’s designed to only deliver its malicious payload when it finds itself on the final system or systems it’s targeting.
On systems that are not targeted, the worm just sits and finds ways to spread to other computers in search of its target. To date, three variants of Stuxnet have been found (dating to June 2009, March 2010 and April 2010). Symantec believes a fourth variant likely exists, but researchers have not found it yet.
One of the organizations, Domain B, was targeted each time the attackers released a new version of Stuxnet.
“So it looks like they felt that if they got in there, Stuxnet would spread to the [system] they actually wanted to attack,” O Murchu says.
After the worm was discovered in June 2010, Symantec researchers worked on reverse-engineering the code to determine what it was designed to do. Two months later, the company stunned the security community when it revealed that Stuxnet was designed to attack Programmable Logic Controllers (PLCs), something that until then was considered a theoretical attack but had never been proven done. PLCs are components that work with SCADA systems (supervisory control and data acquisition systems) that control critical infrastructure systems and manufacturing facilities.
Shortly after Symantec released this information last August, German researcher Ralph Langner disclosed that Stuxnet was not attacking just any PLC, it was targeted to sabotage a specific facility or facilities. Speculation focused on Iran’s nuclear enrichment plant at Natanz as the likely target. Iran has acknowledged that malicious software struck computers at Natanz and affected centrifuges at the plant, but has not provided any details beyond this.

OS fingerprinting

What is meant by OS fingerprinting?
It must be familiar to UNIX geeks. There are popular tools like nmap that help you identify which hosts run Windows and which hosts run Linux. This can be as specific as even getting to know if a patch or service pack in Windows was installed.
But there is a problem with nmap OS fingerprinting as it uses active fingerprinting. Not a great idea. We want to use passive OS fingerprinting. In passive OS fingerprinting we rely on TCP SYN packets from the remote host to identify the OS. This is quite reliable though it can be trivially spoofed. I would imagine that if we use passive OS fingerprinting we can be reasonably sure about the remote OS.
It can be used as a policy tool to implement firewalling that can protect us against Windows worms or viruses. We can have a logical separation between Windows hosts and other hosts.
Passive OS fingerprinting can help us in many other ways too. We can find out many things that are hidden from the eyes of systems administrators. A tool called p0f is famous for doing passive OS fingerprinting correctly. And OpenBSD pf, the firewall in OpenBSD has inbuilt ability to do fingerprinting. You can also change the string that it displays for identifying the OS by specifying it in a file /etc/pf.os on any OpenBSD machine.
p0f and OpenBSD pf both use the TCP default Window size, time to live, the presence of absence of the DF(dont fragment) bit in IP header, the size of the SYN packet and the options in TCP header to identify the remote OS through passive fingerprinting.
You can identify what software people have installed by looking at the greeting message of TCP protocols by simply connecting to them with netcat. You can know if people use sendmail, postfix or MS Exchange. You can identify the OpenSSH version, you can know which web server people use and many other networking forensic data can be collected.
If you wish to know the countries that hit your web server, then GeoIP can help you lookup IP address and know where the ISP is located. This is not accurate as most free tools don't have the correct database. You have to do some crosschecks before arriving at the right tool.
Network forensic analysis is towing the thin line between hacking and cracking. We are not interested in prying into other people's or other network's innards. But you can use such tools for several useful applications without intruding into other's privacy.
Network scanning is also useful to know which services are running on UNIX hosts and request users to turn off harmful services. NAT is a blessing in disguise because most machines are not accessible to the big bad Internet. If that were not the case we would be having a lot more attacks than now.