All Entries Tagged With: "attack"

Man-in-the-middle attacks demoed on 4 smartphones

Security researchers from SMobile Systems have released a paper detailing successful man-in-the-middle attacks against several smartphones.

The SSL enabled log in sessions on the tested, Nokia N95, HTC Tilt, Android G1 and iPhone 3GS devices was sniffed using the publicly available SSLstrip tool, with the attack taking place over insecure Wi-Fi network, now prevalent literally everywhere. Here’s the scenario they used, and possible mitigation approaches:

“The attacker visits the same cafe that offers a free Wi-Fi hotspot and decides to employ basic host, network identification and enumeration tools from the laptop to enumerate all the active devices connected to the Wi‐Fi hotspot. From the results, the attacker notices a MAC address referring to a Nokia smartphone. The attacker know that there is little to no detection capabilities present on an overwhelming majority of smartphone’s in use today, so the owner would likely never find out about a successful man-in-the-middle- attack (MITM).

The well-informed attacker creates a successful MITM attack. In the meantime, the smartphone owner accesses the online bank website and enters the login credentials required to gain access to the banking information. In this scenario, all of the communication between the smartphone and the online bank site is routed through the attacker’s machine and the attacker can see the login details in plain text, as well as can capture all the sites accessed by the victim.”

The awareness-raising test aims to educate users on approaching convenient and free, public Wi-Fi networks with caution, emphasizing on how their mobile service provider’s 3G connection, or the one offered by a trusted Wi-Fi network should always be considered as their first choice.
Anyway, just how insecure or susceptible to compromise are the majority of Wi-Fi networks found on high-trafficked locations such as airports or international cities? The answer is sadly, self-evident with data backing it up available publicly.

• Go through related posts: GPU-Accelerated Wi-Fi password cracking goes mainstream; D-Link router’s CAPTCHA flawed, WPA passphrase retrieved; Survey: 88% of Mumbai’s wireless networks easy to compromise

Last year, AirTight Networks conducted a major wireless network security study by visiting 14 airports (11 in the U.S and 3 in the Asia-Pacific) and found out that a huge percentage of the 478 Wi-Fi Access Points analyzed are either open, or using outdated encryption protocols. Even more interesting was the fact that users were falling victims to “viral” Wi-Fi networks using descriptive and lucrative names seeking to establish legitimacy.

The prevalence of such “handy”, but easy to compromise Wi-Fi networks internationally, is virtually the same. For instance, similar wardriving tests conducted in Paris; Santiago, Chile; China; Monterrey — Mexico, Sao Paulo – Brazil, Caracas (Venezuela), Warsaw, and London offer similar insights into the “security” of such public networks.

Possible mitigation practices? According to Marlinspike, the author of the tool:
Cautious users, for example, have been advised to explicitly visit https URLs or to use bookmarks in order to protect themselves from sslstrip, while other SSL/TLS based protocols such as imaps, pop3s, smtps, ssl/irc, and SSL-based VPNs never present an opportunity for stripping. This talk will outline some new tools and tricks aimed at these points of communication, ultimately providing highly effective attacks on SSL/TLS connections themselves.
How often do you face the trade-off of using a public, and possible insecure Wi-Fi hotspot, for the sake of convenience instead of sticking to your 3G data plan, even when traveling abroad?

Have you ever avoided using your mobile device and instead used your laptop at an airport, due to your host-based firewall’s better ARP filtering features — if any — enabling the detecting of changed MAC address for a (trusted) gateway network adapter in order to detect possible MItM attempts?

How EV SSL-aware is your E-banking provider, especially if you’re E-banking over a mobile device? Or do you simply “VPN-and-forget” over a public Wi-Fi network?

Facebook CSRF Attack

From nukeitdotorg

This is an example of a Facebook attack for personal information theft. I don’t condone this but it shows just how easy it is to do, and to obtain the methodology to do it. Scary isn’t it?

SSL under attack (again) #BlackHat

short wrap up by Sean Michael Kerner – from the ‘be careful who you certify’ files:

LAS VEGAS. Earlier this year security researcher Moxie Marlinspike turned the world of SSL security on its head with a presentation at Black Hat DC. Here in Vegas, he’s expanding his tool SSLstip with a series of improvement that will make the tool even more powerful.

“On the web SSL is not usually encountered directly,” Marlinspike said. “It’s usually a redirect where someone types in bankofamerica.com (or any other site) and then they get forwarded to an SSL page.”

What the original SSLstip tool did was to take advantage of that fact to trick browser into thinking an HTTP connection was actually an SSL connection. Marlinspike noted that its an automated process to get a regular SSL certificate. The way the process works by first getting a whois lookup to admin contact.

“They only look for the root of the domain.the don’t give a shit about subdomains,” Marlinspike said.

As such a person could get a certificate for a null domain like *0\.attackersite.bankname.com that would validate. He commented that such a wildcard gives SSLstrip great power, providing what looks like a real certificate. To make matters worse he’s now also built in a technique to prevent the wildcard certificate from being revoked by the certificate authority as well.

“In short, we’ve got your passwords, your communications and control over the software that runs on your computer,” Marlinspike said.

There is however a solution. In response to a question from the audience Marlinspike noted that all the SSL vendors would have to do is validate the whole domain, not just the last bit of it.

How to perform a client-side attack without attempting an exploit

This method was taken out in the Core IMPACT Pro 8 release, but it can still be done. I’ve taken the ‘generic’ knowledge base article from the Core Security customer support portal for the 7.5 product, and edited it to show how it works. Core tell me that they are looking to put the ability to perform a client side attack without attempting an exploit back into the mix in the next rev.

Here’s a couple of points to note though – the chances are the AV on the local machine is going to pick up the ‘click’ as a virus called “Bloodhound.Exploit.196″ – your crew will see a lot of anti virus activity if the exploit works. Also, if you have an internal proxy with AV built in, clicking the link will be immediately redirected, and won’t make it through to the exploit web server. Who has an internal proxy though? Right? We do!

An interesting idea that I’ve heard would be to have a message appear on clicking the link in the exploited email that says “You shouldn’t have clicked that! – Contact IT immediately” or whatever your company dictates is appropriate – I’m liking that idea. Any who – here’s the write up.

How to perform a client-side attack without attempting an exploit, and acquire an understanding of users (via their respective email addresses) who are susceptible to a client-side attack.

After acquiring a list of email addresses via the Client-side Information Gathering wizard, perform the following steps:

1. Launch the Client-side Attack & Penetration wizard, specify an email address in the FROM field, choose one or more target email addresses for the TO field, and click Next.

2. For the Attack Type, choose the Web Browser attack and click Next.

3. For the Exploit, click the Change button and select the IE VML Buffer Overflow exploit. For the E-Mail template, click the Change button and choose a message template. Modify the SUBJECT and click Next.

4. Specify an IP address for the SMTP server to which the messages are to be delivered, select the Connect From connection method and click Next.

5. Once the Client Side Attack & Penetration wizard appears in the Executed Modules window (give it a minute or two if you have a huge list of email addresses), right-click the Agent Connector Manager Module that is running beneath it and select Stop.

What will occur is that the Agent Connector module will stop, which prevents the attempt of the exploit, as well as the Client-side Attack & Penetration wizard itself, and the IE VML Buffer Overflow exploit and child module. The only module that should remain running will be the Web Server module.

Note the purpose of the Web Server module is to record any connectivity to it, received the result of a user having clicked the link offered within the email. And if you examine the Module Log window in relation to the Web Server module, if there is any connectivity, it will be reflected here.

After a period of time has passed, if the User Report is generated (found under the Client Side Report Generation wizard), it will reflect the number of email addresses harvested, the number of email addresses tested (AKA attacked) and the number of email addresses of users who clicked the link offered, as well as pertinent information including their email address and IP address, etc.

Detecting a SYN flood DoS Attack

From: COMMAND LINE KUNG FU: PaulDotCom, Ed Skoudis, Hal Pomeranz, byte_bucket

Ed muses:

I was talking with a sysadmin buddy a couple of months ago, who told me he thought his system was under a SYN flood Denial of Service attack, but he wasn’t sure. I asked, “Why aren’t you sure?” He told me that he couldn’t get ahold of his network guys to look at the router and IDS. I said, “You don’t need them… just measure it on your end system.” “How?” he asked. “Count the number of half-open connections… Oh, and you should count the number of full-open connections too, in case you have a connection flood,” I answered. “How?” he repeated.

I told him to use our good friend, netstat. Half-open TCP connections are generated by a SYN flood when an attacker uses a spoofed source address that never sends RESETs to tear down half-open connections. Netstat shows such items in its output as “SYN_RECEIVED”. We can count the number of half-open connections using:

C:> netstat -na | find /c "SYN_RECEIVED"

I’m simply using the /c option of the find command to look for connections in that state. Note that find is case sensitive, so I put in all caps for SYN_RECEIVED. The find command with /i is case insensitive.

Please note that the number of normal half-open connections for most systems is relatively small, typically under a hundred. If you see several hundred, you may have a SYN flood.

Another possibility involves the attacker launching a connection flood, not just a SYN flood. Here, the bad guy won’t spoof anything, but will actually complete the three-way handshake with your system again and again. Some bot-net attacks do this by sending HTTP requests to a flood target because it blends in with normal web surfing. We can count those with netstat too, using:

C:> netstat -na | find /c "ESTABLISHED"

Now, the number of established connections is heavily dependent on the nature and use of your given machine. A busy mail server or web server may have several hundred, or it might not. It all depends. What we need to look for here is a deviation from normal behavior for the system, with a lot more connections that we normal expect.

But, the beauty here is that we are using built-in tools to determine whether we’ve got a SYN or connection flood, without having to bother the network or IDS guys.

Hal comments:

This is, of course, a lot easier in the Unix shell than in Windows. In fact, I can actually give you counts for all current socket states with a single command line:

$ netstat -an | awk '/^tcp/ {print $6}' | sort | uniq -c
13 ESTABLISHED
29 LISTEN

Thanks for giving me an easy one, Ed. Maybe I’ll do the same for you sometime. Maybe.