Tuesday, February 6, 2007

The year 2007: A review through the crystal ball

The year 2007: A review through the crystal ball

It's the season of the end-of-the-year reviews. We have used our crystal ball to jump forwards a year to provide you the ultimate review of 2007 -- here and now.

2007 was the year of the super bots: Never before has malicious software been equipped with so many functions that help it to hide from antivirus software and to resist removal. The majority of malicious software programs used root kits, and their number doubled again on last years figure to over 500. Local privilege escalation vulnerabilities in Windows were increasingly exploited; accounts with restricted user rights were used to gain system rights. Initially, the protective functions in Windows Vista, which has been available for end customers since January, made it more difficult for malicious code to infiltrate the system. The crimeware scene responded and numerous vulnerabilities appeared as the year progressed and these were exploited to cancel or bypass the majority of the security functions. The user account protection (UAC), in particular, proved to be ineffective: Most users just confirmed any respective requests, since they did not undertand the displayed information.

While in 2006, DDoS attacks with botnets were mainly targeted at unwanted competitors, online betting offices and consumer protection sites, 2007 also saw large attacks launched on critical infrastructures. In April, the stock exchange nearly crashed, when a DDoS attack on the electronic trading system disconnected it from the Internet for several days, resulting in automated control programs loosing control and attempting to divest shares in a panic reaction.

When analysing this event, neither law enforcement agencies nor other specialists involved were able to switch off the responsible botnet with its decentralised control. The individual bots communicated with each other in a peer-to-peer structure, similar to those used for file sharing sites; the commands transferred in the Net were encrypted and had a digital signature.

An insurance company suffered significant damages, when a botnet attack cut off all the telephones in the entire company group for two days. While the Voice-over-IP infrastructure proved to yield operational cost savings, this was at the expense of system stability, when vulnerabilities of the SIP protocol were used for targeted attacks. So far, no explanation has been found for why the attacks stopped abruptly after two days; persistent rumours say that a six-digit sum changed hands.

For security software vendors, too, 2007 was a black year: The number of critical holes detected in products that had been designed to provide a higher degree of security was higher than ever before. For instance, various worms used zero-day exploits for holes in antivirus software to find a way into the system during the mail scanning process.

For the first time, underground prices for such zero-day exploits dropped in 2007, compared to the previous year. Insiders think this drop in prices was caused by a glut of such exploits, mainly due to the broad usage of simpler fuzzing tools. Bit by bit, these half-automated vulnerability scanners are uncovering the (security) sins of a whole generation of programmers.

Again, the share of web-based attacks experienced strong growth rates. However, malicious web sites did not so much exploit holes in browsers; rather, they used holes in media player plug-ins and software for Internet Explorer, Firefox and Opera, to infect PCs. The popularity of video portals such as YouTube, MyVideo and ClipFish, as well social networking sites, contributed to this development, with the MySpace worm being the sad culmination. For several weeks, this worm exploited a hole in the Flash Player to infect the PCs of hundreds of thousands of visitors, logged their surf patterns and chat activities and posted this information in public forums.

With many companies starting to migrate to Web 2.0, the security situation changed for the worse: Cross-site scripting holes on web servers became an epidemic plague. Defacing web sites advanced from an insider gag to mass entertainment when Jonathon Ross presented his favorite pages on the sites of Buckingham Palace, the Whitehouse and the Vatican. For a short time, the Xacks archive -- named after a combination from XSS and hack -- had even more page impressions than shooting star YouTube. Meanwhile the ministry of justice announced plans to impose penalties for accessing such manipulating URLs.

Traditional web applications did not get off scot-free either. After the "month of PHP bugs" in March 2007 and the subsequent intrusion into ten thousands of web servers, global web hosters were forced to take their servers off the Net for several days, until updates for the major PHP holes were available. In a study published in June 2007, the US-CERT recommended that PHP should not be used for critical environments. The National Infrastructure Security Coordination Centre advised against the usage of PHP on the servers deployed in state and public institutions and authorities and suggested using Ruby on Rails instead.

Regarding privacy issues, 2007 experienced a continuation of the payback trend: An increasing number of companies tried to buy off the onerous restrictions imposed on the usage of personal data. With attractive offerings, they enticed customers into accepting their terms and conditions that grant the respective providers freedom from restriction in this context. The case of an IP-TV provider, who sold his advertisers profiles containing his customers' viewing behaviours, including names and addresses, led to a public awakening after radical feminists outed two conservative politicians as regular viewers of a porno channel. Since then IP-TV providers have discussed committing themselves to not passing personal data to puckish third parties.

A slip-up also cast a shadow on search engine provider Google: Contrary to their own assertions, the data octopus had analysed and indexed all e-mails processed through their mail service. Due to a mistake made by an administrator, a database of the highly secret project was mirrored onto the external index servers, and as a result, the private mails of thousands of GMail users could be accessed via the search front-end for at least one hour. This event adds weight to warnings against a potential combination of data from the traditional search engine, Google Desktop, Google Analytics, YouTube and other Google services. Whether this will have consequences or not, will be revealed in our year 2008 review.

So let's just hope that our crystal ball is wrong...

Labels: ,

Virtual Private Network Security Threat

Dynamic Security can dry up the reserve of passwords that hackers use to penetrate VPNs.



Michael Thumann

Breaking into a VPN

Sloppy configurations make for unsecured VPNs

The IP extension IPSec is generally considered the most secure VPN technology. But it also has its weak points that special tools can find and exploit. Prudent administrators therefore test their own network – before the hackers do.

Virtual Private Networks (VPNs) can save a lot of money by using the Internet to transport data instead of expensive dedicated lines, and modern encryption and authentication methods can ensure the confidentiality of data sent across such public networks. Currently, the most important protocol for the implementation of VPNs is IPSec, which is unfortunately also the most complex. IPSec can not only be used to link complete enterprise networks to the Internet, but also to connect mobile users to their company's email and database server.

At the same time, this complexity can itself become a security risk. You need expertise and experience to configure IPSec-based VPNs correctly -- two requirements that an astonishing number of administrators do not sufficiently meet. In combination with lazy use of default settings in many devices and programs, underskilled administrators create preventable weak points that leave open dangerous points of entry for hackers.

Last stop: security

VPN encryption is almost impossible to crack itself, so the best place to try to get into a VPN are the two end points. On the one hand, we have VPN gateways, a company's central dial-in point; on the other, the VPN client of mobile users, such as notebooks.

The most common target of hackers is generally notebooks, starting from theft to entry via security holes in the operating system or applications running on it. Wireless networks in hotels and airports offer hackers promising opportunities because in such places it is very probable that they will find someone setting up a VPN tunnel to their company to exchange data.

While most vendors of VPN solutions offer special client software with an integrated firewall to prevent access to the computer, not all of them actually install and enable the software. Once VPN access has been set up, hackers are able to move around within the enterprise network via the hacked device and get access to confidential information -- if they haven't already found it on the local hard drive.

But the company's gateway may also offer hackers a few entry points. And unlike mobile devices, it is of necessity constantly reachable via the Internet, making it directly exposed to attacks.

Footprints

In preparing for an attack, hackers first collect all available information. A VPN gateway is relatively easy to identify. All you need is a port scanner like nmap, which will produce output such as the following:

# nmap -sSUV -O 10.1.1.254 
Starting nmap 3.70 (Interesting ports on 10.1.1.254: 
PORT      STATE         SERVICE
256/tcp   open          fw1-secureremote   
257/tcp   open          fw1-log service 
259/udp   openfiltered firewall1-rdp 
500/udp   openfiltered isakmp 
1701/udp  openfiltered L2TP 
Device type: firewall 
Running: Checkpoint Windows NT/2K/XP 
OS details: Checkpoint SecurePlatform NG FP3 

The characteristics of the port reached shows that the firewall is from Checkpoint. The fingerprinting that nmap uses and the service discovery (not shown above) also suggest that a Firewall-1 NG was just detected on the SecurePlatform. The UDP Port 500 is a clear sign that this firewall also runs as a VPN gateway. VPNs use this port to process the protected exchange of keys via IKE (Internet Key Exchange), an essential part of IPSec.

Fingerprints

Special tools can even detect the cryptographic methods and parameters that the gateway uses, providing even more indications of the vendor. The free program IKE-Scan [1] handles this task:

 
#ike-scan 10.1.1.254 --trans=5,2,1,5 -o 
Starting ike-scan 1.2 with 1 hosts  
10.1.1.254 
IKE Main Mode Handshake returned (1 transforms) 
  
IKE Backoff Patterns: 
  
IP Address   No.     Recv time               Delta Time 
10.1.1.254   1       1092956328.817392       0.000000 
10.1.1.254   2       1092956330.923392       2.106000 
10.1.1.254   3       1092956332.885392       1.962000 
10.1.1.254   4       1092956334.833392       1.948000 
10.1.1.254   5       1092956336.836392       2.003000 
10.1.1.254   6       1092956338.835392       1.999000 
10.1.1.254   7       1092956340.844392       2.009000 
10.1.1.254   8       1092956344.875392       4.031000 
10.1.1.254   9       1092956348.882392       4.007000 
10.1.1.254   10      1092956352.866392       3.984000 
10.1.1.254   11      1092956356.902392       4.036000 
10.1.1.254   12      1092956360.883392       3.981000 
10.1.1.254   Implementation guess: Firewall-1 4.1/NG 

The option "-trans=5,2,1,5 " indicates the parameters to be tested: 3DES, SHA, Preshared Key, Diffie Hellman group 5. The message "IKE Main Mode Handshake returned" indicates that the VPN gateway accepts these parameters, and the name of the vendor is displayed immediately. But these tools can only be used successfully if the VPN gateway is configured in a certain way and supports certain parameters. Here, it often helps to try out the IKE and IPSec parameters manually or by means of a script.

Too fast

It is perhaps a matter of opinion as to whether the disclosure of such information should be considered a security problem. The operator of a VPN has a real problem if hackers manage to crack authentication and log in at the gateway. Under certain circumstances, however, this may not even be difficult -- for example, if a pre-shared key (PSK) is used for authentication and the gateway is working in "aggressive mode." Aggressive mode shortens the IKE handshake for the exchange of keys to speed things up. Instead of the six packets used in the conservative main mode, only three are transmitted. But speeding things up this way comes at a price: the aggressive mode is vulnerable to targeted attacks.

For authentication, the gateway transmits a hash value derived from the PSK through the network. As this hash is not encrypted, it may be possible to reconstruct the pre-shared key in dictionary attack or brute-force attack [2]. Depending on the quality of the keys, the attack may be successful in just a few minutes, a few months, or a few years. It is not especially hard to get the hash: the VPN gateway transmits it through the network in the aggressive mode during an attempt to contact a VPN client.

Script kiddy

The IKEProbe developed by ERNW scans VPNs for weak spots and can be used to find such holes in IPSec VPN Gateways [3]. To do so, the tool simulates a VPN client and attempts an IKE handshake in the aggressive mode. It tests all of the IKE parameters supported and checks whether the gateway transmits the PSK hash. As soon as a response comes, the gateway is vulnerable. A scan of a vulnerable gateway with IKEProbe might look like this:

 
#ikeprobe 10.1.1.254 
IKE Aggressive Mode PSK Vulnerability Scanner 
Supported Attributes 
Ciphers              : DES, 3DES, AES-128, CAST 
Hashes               : MD5, SHA1 
Diffie Hellman Groups: DH Groups 1, 2 and 5 
  
IKE Proposal for Peer: 10.1.1.254 
Aggressive Mode activated ...   
Attribute Settings: 
Cipher DES 
Hash SHA1 
Diffie Hellman Group 1 
    
0.000 3: ph1_initiated(00443ee0, 00384708)   
0.010 3: < ph1 (00443ee0, 244)   
0.030 3: > 40   
0.030 2: sx_recv_notify: invalid doi   
2.532 3: < ph1 (00443ee0, 244)   
5.537 3: < ph1 (00443ee0, 244)   
8.541 3: ph1_disposed(00443ee0) 
(...) 
Attribute Settings: 
Cipher 3DES 
Hash SHA1 
Diffie Hellman Group 5 
   
64.551 3: ph1_initiated(00443ee0, 00384708)   
64.662 3: < ph1 (00443ee0, 340)   
64.692 3: > 328  
64.842 3: ph1_get_psk(00443ee0) 
   
System is vulnerable!! 

Hash cracked

It is astonishingly easy to attack such a vulnerable VPN gateway. Cain & Abel, a password sniffing and cracking tool, can monitor whilst IKEProbe is running and extract the hash with its IKE parser [4].

image 1 [489 x 133 Pixel @ 16,8 KB]

Cain sniffs the hash value during the IKE handshake between IKEProbe and the gateway

But Cain & Abel can do more: it uses its password cracker to get the right key for the hash, either by means of a dictionary attack or a brute-force attack depending on the configuration. In principle, a good key cannot be cracked within a reasonable timeframe. However, good pre-shared keys are surprisingly rare in practice.

One reason for this is that people still think that such attacks are harder than they actually are. For instance, it takes less than one minute to try out a list of one million words. Even a somewhat old PC with a 1.2GHz processor would only need around two hours to try out all combinations of lowercase letters for a six-character key. Adding two more characters would mean the computer needs 55 days. If uppercase letters and numbers are allowed, the operation would take 148 years.

image 2 [490 x 179 Pixel @ 21,9 KB]

Cain has succeeded in calculating the pre-shared key

All you need to get a cracked key to enable a connection to a VPN gateway is a normal VPN client, such as PGPNet in PGP or Sentinel [5]. To get actual access to the enterprise network, hackers still have to guess the right IP subnetworks behind the gateway -- but that is just a matter of time. A firewall behind the gateway would, however, limit access to network resources. VPN gateways are therefore often placed in a separate, demilitarized zone (DMZ) so the unencrypted connections to the LAN can be filtered again.

Safety net

Whether a VPN gateway uses the risky aggressive mode depends on the settings. In some products, it is even the standard setting, such as in some Cisco equipment and old versions of Checkpoint's Firewall-1. In contrast, other implementations such as FreeS/Wan do without it altogether and restrict IKE to the conservative main mode, which all IPSec implementations have to support.

The easiest way to prevent the security risks described here is to forego pre-shared keys completely and use Smartcards, HardwareTokens, and X.509 certificates instead. If you have to use PSKs for authentication because your network budget gives you no option and it would be too much trouble to switch, use keys that are at least 20 characters long and consist of letters, numbers and special characters. And be sure to stay clear of aggressive mode. (dab)

References

[1] IKE-Scan

[2] Brute Force - Attacks on passwords in Windows networks

[3] IKEProbe

[4] Cain & Abel

[5] PSK Cracking using IKE Aggressive Mode

[6] Cisco Security Notice: Response to BugTraq - Internet Key Exchange Issue

Labels: ,

Not by Firewalls alone: Firewall vulnerability using the NAT

The same trick can be used by hackers of course...

Jürgen Schmidt

The hole trick

How Skype & Co. get round firewalls

Peer-to-peer software applications are a network administrator's nightmare. In order to be able to exchange packets with their counterpart as directly as possible they use subtle tricks to punch holes in firewalls, which shouldn't actually be letting in packets from the outside world.

Increasingly, computers are positioned behind firewalls to protect systems from internet threats. Ideally, the firewall function will be performed by a router, which also translates the PC's local network address to the public IP address (Network Address Translation, or NAT). This means an attacker cannot directly adress the PC from the outside - connections have to be established from the inside.

This is of course a problem when two computers behind NAT firewalls require to talk directly to each other - if, for example, their users want to call each other using Voice over IP (VoIP). The dilemma is clear - whichever party calls the other, the recipient's firewall will decline the apparent attack and will simply discard the data packets. The telephone call doesn't happen. Or at least that's what a network administrator would expect.

Punched

But anyone who has used the popular internet telephony software Skype knows that it works as smoothly behind a NAT firewall as it does if the PC is connected directly to the internet. The reason for this is that the inventors of Skype and similar software have come up with a solution.

Naturally every firewall must also let packets through into the local network - after all the user wants to view websites, read e-mails, etc. The firewall must therefore forward the relevant data packets from outside, to the workstation computer on the LAN. However it only does so, when it is convinced that a packet represents the response to an outgoing data packet. A NAT router therefore keeps tables of which internal computer has communicated with which external computer and which ports the two have used.

The trick used by VoIP software consists of persuading the firewall that a connection has been established, to which it should allocate subsequent incoming data packets. The fact that audio data for VoIP is sent using the connectionless UDP protocol acts to Skype's advantage. In contrast to TCP, which includes additional connection information in each packet, with UDP, a firewall sees only the addresses and ports of the source and destination systems. If, for an incoming UDP packet, these match an NAT table entry, it will pass the packet on to an internal computer with a clear conscience.

Switching

The switching server, with which both ends of a call are in constant contact, plays an important role when establishing a connection using Skype. This occurs via a TCP connection, which the clients themselves establish. The Skype server therefore always knows under what address a Skype user is currently available on the internet. Where possible the actual telephone connections do not run via the Skype server; rather, the clients exchange data directly.

Let's assume that Alice wants to call her friend Bob. Her Skype client tells the Skype server that she wants to do so. The Skype server already knows a bit about Alice. From the incoming query it sees that Alice is currently registered at the IP address 1.1.1.1 and a quick test reveals that her audio data always comes from UDP port 1414. The Skype server passes this information on to Bob's Skype client, which, according to its database, is currently registered at the IP address 2.2.2.2 and which, by preference uses UDP port 2828.

Alice calls Bob

Step 1: Alice tries to call Bob, which signals Skype.

Bob's Skype program then punches a hole in its own network firewall: It sends a UDP packet to 1.1.1.1 port 1414. This is discarded by Alice's firewall, but Bob's firewall doesn't know that. It now thinks that anything which comes from 1.1.1.1 port 1414 and is addressed to Bob's IP address 2.2.2.2 and port 2828 is legitimate - it must be the response to the query which has just been sent.

Hole punching

Step 2: Bob tries to reach Alice, which punches a hole through Bob's Firewall.

Now the Skype server passes Bob's coordinates on to Alice, whose Skype application attempts to contact Bob at 2.2.2.2:2828. Bob's firewall sees the recognised sender address and passes the apparent response on to Bob's PC - and his Skype phone rings.

Call established

Step 3: Alice finally reaches Bobs computer through the hole.

Doing the rounds

This description is of course somewhat simplified - the details depend on the specific properties of the firewalls used. But it corresponds in principle to our observations of the process of establishing a connection between two Skype clients, each of which was behind a Linux firewall. The firewalls were configured with NAT for a LAN and permitted outgoing UDP traffic.

Linux' NAT functions have the VoIP friendly property of, at least initially, not changing the ports of outgoing packets. The NAT router merely replaces the private, local IP address with its own address - the UDP source port selected by Skype is retained. Only when multiple clients on the local network use the same source port does the NAT router stick its oar in and reset the port to a previously unused value. This is because each set of two IP addresses and ports must be able to be unambiguously assigned to a connection between two computers at all times. The router will subsequently have to reconstruct the internal IP address of the original sender from the response packet's destination port.

Other NAT routers will try to assign ports in a specific range, for example ports from 30,000 onwards, and translate UDP port 1414, if possible, to 31414. This is, of course, no problem for Skype - the procedure described above continues to work in a similar manner without limitations.

It becomes a little more complicated if a firewall simply assigns ports in sequence, like Check Point's FireWall-1: the first connection is assigned 30001, the next 30002, etc. The Skype server knows that Bob is talking to it from port 31234, but the connection to Alice will run via a different port. But even here Skype is able to outwit the firewall. It simply runs through the ports above 31234 in sequence, hoping at some point to stumble on the right one. But if this doesn't work first go, Skype doesn't give up. Bob's Skype opens a new connection to the Skype server, the source port of which is then used for a further sequence of probes.

wireshark screenshot

Skype can do port scans. Here it suceeds on port 38901 and connects through the firewall.

Nevertheless, in very active networks Alice may not find the correct, open port. The same also applies for a particular type of firewall, which assigns every new connection to a random source port. The Skype server is then unable to tell Alice where to look for a suitable hole in Bob's firewall.

However, even then, Skype doesn't give up. In such cases a Skype server is then used as a relay. It accepts incoming connections from both Alice and Bob and relays the packets onwards. This solution is always possible, as long as the firewall permits outgoing UDP traffic. It involves, however, an additional load on the infrastructure, because all audio data has to run through Skype's servers. The extended packet transmission times can also result in an unpleasant delay.

Use of the procedure described above is not limited to Skype and is known as "UDP hole punching". Other network services such as the Hamachi gaming VPN application, which relies on peer-to-peer communication between computers behind firewalls, use similar procedures. A more developed form has even made it to the rank of a standard - RFC 3489 "Simple Traversal of UDP through NAT" (STUN) describes a protocol which with two STUN clients can get around the restrictions of NAT with the help of a STUN server in many cases. The draft Traversal Using Relay NAT (TURN) protocol describes a possible standard for relay servers.

DIY hole punching

With a few small utilities, you can try out UDP hole punching for yourself. The tools required, hping2 and netcat, can be found in most Linux distributions. Local is a computer behind a Linux firewall (local-fw) with a stateful firewall which only permits outgoing (UDP) connections. For simplicity, in our test the test computer remote was connected directly to the internet with no firewall.

Firstly start a UDP listener on UDP port 14141 on the local/1 console behind the firewall:

local/1# nc -u -l -p 14141

An external computer "remote" then attempts to contact it.

remote# echo "hello"  nc -p 53 -u local-fw 14141

However, as expected nothing is received on local/1 and, thanks to the firewall, nothing is returned to remote. Now on a second console, local/2, hping2, our universal tool for generating IP packets, punches a hole in the firewall:

local/2# hping2 -c 1 -2 -s 14141 -p 53 remote

As long as remote is behaving itself, it will send back a "port unreachable" response via ICMP - however this is of no consequence. On the second attempt

remote# echo "hello"  nc -p 53 -u local-fw 14141

the netcat listener on console local/1 then coughs up a "hello" - the UDP packet from outside has passed through the firewall and arrived at the computer behind it.

Network administrators who do not appreciate this sort of hole in their firewall and are worried about abuse, are left with only one option - they have to block outgoing UDP traffic, or limit it to essential individual cases. UDP is not required for normal internet communication anyway - the web, e-mail and suchlike all use TCP. Streaming protocols may, however, encounter problems, as they often use UDP because of the reduced overhead.

Astonishingly, hole punching also works with TCP. After an outgoing SYN packet the firewall / NAT router will forward incoming packets with suitable IP addresses and ports to the LAN even if they fail to confirm, or confirm the wrong sequence number (ACK). Linux firewalls at least, clearly fail to evaluate this information consistently. Establishing a TCP connection in this way is, however, not quite so simple, because Alice does not have the sequence number sent in Bob's first packet. The packet containing this information was discarded by her firewall.

Labels: ,

Marko Rogge

Bluetooth as Achilles' heel

How Bluetooth marketing desensitises users to mobile viruses

More and more businesses are experimenting with Bluetooth advertisements. In doing so they are doing consumers a disservice - because it is almost impossible to tell where a Bluetooth message comes from, they are smoothing the way for the distribution of mobile viruses.

In the age of fast mobile communication, marketing is also becoming ever more flexible, so it comes as no surprise that advertisers are attempting to make use of Bluetooth. After all, Bluetooth opens up new ways of sending advertising messages to mobile phones and PDAs. These adverts can include images, videos, java games or applications, which can be transmitted to passers-by at trade shows, exhibitions, airports and stations or in the vicinity of restaurants or shopping centres.

Bluecell Networks GmbH from Gundelsheim in Germany has developed the Bluetooth hotspot technology - beamzone, which recognises different mobile phone models in order to send suitably tailored applications. There are presently 115 operational Bluetooth hotspots throughout Germany, from which it is possible to receive files via beamzone. Alongside fast food chains, companies such as BMW, Ericsson, Nokia and Volvo are making use of Bluecell Network's services in order to serve mobile phone users with advertisements.

Bild 1 [176 x 208 Pixel @ 26 KB]

On mobile phones, the source of Bluetooth messages is uncertain.

The hotspots which have already been installed in Cinestar cinemas have a range of around 30 metres, enabling them to reach a substantial group of mobile phones. One of these hotspots is in a small town in Bavaria, and if you have Bluetooth activated on your mobile phone you can try out this new technology at a local fast food joint. Bluecell Networks works on the assumption that 5 to 7 percent of the people frequenting a location with a Bluetooth hotspot receive the advertisements. With an average of just over 1000 visitors per day, for example (source: McDonald's), this represents a potential 50 to 70 recipients. Because the service is free to the recipient, customers are keen to use it, and advertising data, videos, images, applications, games or java applications find their way onto recipients' mobile phones.

The flip side

For a hacker, however, this is manna from heaven! A device claiming to be a Bluetooth hotspot can infect mobile phones with malware via short range radio. Users of smartphones running Symbian operating systems are at particular risk. In the second quarter of 2006, 12.3 million mobile phones with the Symbian OS were sold, with around 90 different mobile phone models. The operating system is thus of considerable interest to virus writers. F-Secure claims to have already seen 316 pieces of malware for this platform, which are able to disable a mobile phone, or, for example, rack up huge costs for the user, by sending MMS messages. In addition many mobile phone viruses are able to spread autonomously via Bluetooth. Cabir and Commwarrior are currently the most widely distributed malware identified in this context.

image 3 [243 x 282 Pixel @ 17,5 KB]

Once a handset is infected, it becomes extremely difficult to restore. The worm Skulls, destroys even system files.

An infection can take place very quickly - anyone passing by an attacker's Bluetooth device will be offered an SIS file. The SIS extension indicates a Symbian installation file and contains executable programs and installation instructions for the mobile phone. Unfortunately mobile phone viruses also come in this sort of packaging. Whether an SIS file really installs what the name implies may be open to doubt.

Unfortunately it is not possible to check what sort of message it is until the file has been received. Symbian will attempt to install SIS files or Java applications (*.jar, *.jad) immediately. The warning message that the application does not have a valid digital certificate and that it could be malware often won't deter users from clicking on "OK" to continue the installation - if in doubt, curiosity will often get the better of caution. After successful transfer and installation virus infection cannot be averted. At events, in cinemas or in fast food chains in particular, visitors' mobile phones may become infected with a worm more quickly than you might imagine.

Bild 4 [176 x 208 Pixel @ 26,5 KB]

To an average user, the difference between beamzone and beamzone-0 might be hardly noticeable.

As well as not knowing what the content of a file is, the fact that the recipient does not know exactly who they have just received something from, also plays into the hands of the attacker. For a normal user, it is not possible to determine whether an incoming message from beamzone is really from the beamzone Bluetooth hotspot. Normally anyone can reject incoming messages from beamzone and will then no longer be bothered by the genuine Bluecell hotspot. An attacker, however, will be a little pushier and will keep on sending the message until the user agrees or leaves the reception area.

It is relatively easy to imitate a Bluetooth hotspot. A mobile phone, in which the Bluetooth name has been changed in the connection settings to beamzone or, where there is a conflict with the real hotspot, to beamzone-0 is sufficient. The suffix "-0" is unlikely to be noticed. The deception works even better with a laptop and a class 3 Bluetooth dongle, for an increased range. This combination should be as powerful as a real hotspot.

Putting it to the test

An in situ test clearly showed that most recipients do not really understand what they are being offered. Young people especially hang out in fast food restaurants for lunch and are happy to utilise this free service. The potential clientele is even larger at cinemas or events. Positioned about 10 metres away with Bluetooth activated on our laptop, we provided passers-by with a second file-sending Bluetooth hotspot. All that can be seen on the phone screen is that a message has been received. It is not clear whether it's an image, a video, an executable file or even a virus.

image 2 [236 x 270 Pixel @ 13 KB]

if the application appears interesting, users will often accept installation after repeated invitations to do so.

In our test, 4 of 10 recipients were prepared to install the software we had sent them, without knowing what it was. None of the mobile phone users who had accepted the file had a problem with the fact that the software did not have a valid certificate. In our test no information on the Bluetooth hotspots was displayed and staff at the location were also unable to give us any information. Naturally the test file we used in the test was not a virus, just a calculator application which had been renamed. However, it permitted us to test whether users were informed about mobile phone viruses and whether the name at least would put users off.

Bluecell Networks state that it is easy for the user to determine who they are receiving stuff from. There is, the company says, clear information on the presence of a beamzone, which has a range of only a few centimetres. A user would therefore have to consciously move into the zone and consent to receive messages. The name of the zone would also be clear and the sent applications would always have a digital certificate from Verisign. Bluecell Network's general manager Rainer Rother admits, however, that as with all security measures it is up to the user to decide whether all necessary conditions are met.

Outlook

In the future, people should pay more attention to security of mobile phones or other Bluetooth devices, because technologies such as beamzone are likely to become established as marketing instruments. Nowadays everyone knows that executable files sent as e-mail attachments on their PC shouldn't be trusted. The same problem applies with mobile phones; however, the level of awareness is, at least at present, much lower. Without a mobile phone virus scanner, currently the only effective means of protecting yourself from Bluetooth attacks is to deactivate the interface. Bluetooth should only be activated when it's needed. Users should also only accept files from senders who are right in front of them. Users should not even open messages which drift in via Bluetooth and whose origins are unclear. The manufacturers of mobile devices such as mobile phones and PDAs should pay more attention to wireless communications security and create technical opportunities for normal users to be able to recognise potential threats.

 

Gartner predicts growth in security software in 2007

Market researches at Gartner are convinced that the constantly growing market for anti-virus software will continue to drive global sales of security software upwards this year. The analysts predict that total sales of security software in 2007 will reach 9.1 billion dollars (about seven billion euros) - this would represent an increase of 10.7 percent over the previous year. According to analysis by Gartner, anti-virus software will contribute 4.9 billion dollars of these sales, representing 53.8 percent of the predicted total sales.

The analysts report, however, that anti-virus software is embarking on a process of long-term technical development. The trend is away from software reacting purely to virus signatures, towards predictive systems, which will be proactive. Suppliers of anti-virus software are already working on systems for clients that bring the functionality of spyware killers, personal firewalls, intrusion prevention systems (IPS) and controlled remote access under one umbrella.

Gartner does not expect business customer purchasing of such new security software packages to take off any time soon. Over the next 18 months, they estimate that less than 15 percent of business customers will switch their entire computer centre over to the new technology. One reason cited for this is the high administrative costs. However user habits also play a role - they would have to adapt to more false alarms and potential interactions with existing software installations.

 

Daniel Bachfeld

Summary of the Month of Apple Bugs

The Month of Apple Bugs (MoAB) is over, and aside from all of the discussion about the way the material was presented, the important question concerns just what insights it provided into the security of Mac OS X.

As promised, the initiators of the Month of Apple Bugs, Lance M. Havok and Kevin Finisterre, published a hole in Mac OS X or an application for it every day. In the process, they provided all of the components that an attacker needs to take over an Apple computer. Whilst in most cases the victims still need to interact, Mac users are also curious and, like everyone else, click on links that look interesting or download files from the internet. For example, the MoAB started off with an exploit demonstrating how a hole in QuickTime can be used to inject and execute malicious code in systems via specially prepared websites. The next day, the initiators demonstrated a similar flaw in the VLC player that was also related to additional Mac OS X functions and third-party applications.

While some Mac users did not fail to point out that the malicious code only ran with user rights and was therefore not able to do much harm, attackers would nonetheless be able, for example, to delete documents or send spam e-mails with such rights. In addition, Havok and Finisterre published several local privilege escalation holes that could be used to gain root privileges. These holes, in particular, revealed some considerable vulnerabilities in the way Mac OS X issues rights for paths and files. For instance, system programs can be exchanged not only if you are a member of the admin group, but also with restricted user privileges; likewise, arbitrary programs could be saved and then launched by the system's setuid programs. Such flaws have been quite rare in older operating systems like Windows and Linux for several years now. These elementary flaws indicate that Mac OS X was not seriously designed as a multiuser system and that a clear delineation of user accounts was apparently not an important design goal.

While most of the privilege escalation vulnerabilities are new, it is even more disconcerting that the most critical of them has been known for some time. Users do not even have to be a member of the admin group to get root privileges by manipulating the InputManager. More than a year ago, the Leap.A OS X worm exploited this loophole to launch itself automatically with root privileges. Apple has yet to remedy this problem.

Indeed, Apple did not seem to have much to say about MoAB. The only patch that the company has provided concerns the hole in QuickTime. Apple has not provided patches or workarounds for the vulnerabilities in the processing of DMG images (which can also cause data losses) or for the holes in iChat, AppleTalk, QuickDraw, and other system components. To make things worse, Apple has not even informed its users about the problems as Microsoft does when a hole becomes known but no update has yet been provided. Instead, Landon Fuller's MoAB Fix Group was formed to provide unofficial patches or at least some ideas about workarounds.

But now that MoAB is over, there is no reason to expect specially prepared websites to be popping up everywhere or for e-mails to be sent more often with viruses for Mac OS X. The number of Apple systems being used is probably just too small for authors of viruses to be interested in writing trojans and spyware for them. Nonetheless, MoAB managed to demonstrate impressively that well targeted attacks can be quite successful, if need be. Apple now has its work cut out for it if it wants to work off this list of flaws and provide updates both for the holes and the design errors. And if Apple does not do so, MoAB will not have served its purpose of increasing the security of MacOS X in the long term -- but then Apple is to blame.

 

Websense® Security Labs™ has discovered that the official website of Dolphin Stadium has been compromised with malicious code. The Dolphin Stadium is currently experiencing a large number of visitors, as it is the home of Sunday's Super Bowl XLI. The site is linked from numerous official Super Bowl websites and various Super Bowl-related search terms return links to the site.

A link to a malicious javascript file has been inserted into the header of the front page of the site. Visitors to the site execute the script, which attempts to exploit two vulnerabilities: MS06-014 and MS07-004. Both of these exploits attempt to download and execute a malicious file.

The file that is downloaded is a NsPack-packed Trojan keylogger/backdoor, providing the attacker with full access to the compromised computer. The filename is w1c.exe and its MD5 is ad3da9674080a9edbf9e084c10e80516

We have notified the owner's of the site, but the site is currently still malicious.

 

Please do not visit the site until it has been cleaned.

Site screenshot:

Site source screenshot:

 

Made4biz Security Translating real-world security knowhow into state of the art security systems.
Made4biz Security

Turn on Sound for Demos:
Bill Gates Demo (Location-based)
Elvis Demo (Location/Context-based)
Clint Eastwood Demo (Temporal-based)

Powered by Blogger

Subscribe to
Posts [Atom]

Technorati Profile

RSS Syndication

Made4Biz Security Inc