Posts tagged: 'network security'
The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.http://blog.logrhythm.com/tags/network-security/feed
Notice – LogRhythm nor the author of this blog post are liable for any illegal activities conducted with this information. LogRhythm does not condone or support such activity, this post is simply a proof-of-concept to explore the risks of open wireless access points.
Open wireless access points have always been a hot topic within the security community. Due to their nature, there are a plethora of attacks that allow hackers to breach these networks, mirror legitimate access points, man-in-the-middle traffic and much more. These attacks are conducted every day on many networks all over the planet. Hackers will leverage anything from the Wireless network at your local Starbucks, the airport, airplanes, hotel chains, personal guest networks, and more to steal personal information. You name it, someone out there has found a new way to exploit it. Still trust those pay-as-you-go WiFi hot spots that ask you to supply credit card information?
Which brings us to Comcast… They have been steadily implementing their plan to leverage their customers Comcast access points (only those owned by Comcast, not personal equipment) to distribute wireless access to any Comcast subscriber that happens to be in the vicinity.
“Comcast’s newest Wireless Gateway broadcasts two WiFi signals. By default, one is securely configured for the private use of the home subscriber. The second is a neighborhood “xfinitywifi” network signal that can be shared. This creates an extension of the Xfinity WiFi network and will allow visiting Xfinity Internet subscribers to sign in and connect using their own usernames and passwords.”
All you need to do is locate a nearby access point, log in using your Comcast credentials and start browsing the net through someone’s home router. There is a bit of controversy over this feature – however this is beside the point. What I’d like to talk about today is how hackers can leverage this
vulnerability feature for evil and why consumers should be wary of using open wireless access points in general.
To help illustrate this risk, I’ll be using the WiFi Pineapple – a great little device by the folks at Hak5 that most security professionals are familiar with. The Pineapple comes equipped with a myriad of tools to help trick clients into passing their traffic through this access point so that it can be sniffed, altered, modified, or worse. For our specific attack, we’ll be imitating an Xfinity WiFi access point and using this to steal users Comcast account credentials among other nefarious activities.
First, we need to obtain the code served up by one of these access points, learn how it works, and build our own version. Xfinity access points are popping up everywhere, so finding one is incredibly easy.
Upon finding an access point without even leaving my neighborhood, I cloned the code from the landing page, modified the HTML and added my own form processors to create two identical versions of the Comcast (standard and web) splash pages. This code can be downloaded here:
From here, this code can either be uploaded to the Pineapple or stored on a separate (internet-accessible) server if you’ve run out of free space on the Pineapple. For this walk through, we will host the code on the Pineapple itself. To keep this seperate from the other Pineapple tools, SSH into the Pineapple and make a new directory in the /www/ folder, we’ll call this folder ‘x‘.
Within the github repository, there are two landing page options. One is the default web landing page (login-page-option1) and the other is the default mobile landing page (login-page-option2). Either one will work or you can get creative and adjust the page displayed based on User Agent Strings.
With the folder in place, SCP the code from the xfinity-pineapple/login-page-option(1|2)/ directory to the new folder.
With the authentication page in place, we need to change the name of our access point to ‘xfinitywifi’ to mimic the legitimate Xfinity access point. This can be accomplished under the Karma Configuration menu.
Next, you will need to configure a redirect and force the user to log in. There are multiple ways to do this. The simplest option is to use the Pineapple DNSSpoof Infusion. This method will look for common keywords entered by the victim in the URI and redirect them to the Xfinity landing page. Going this route, they are more likely to catch on that something is up, especially when attempting to visit Google and it keeps redirecting them back to the Xfinity landing page…
The second and more believable option is to go with a captive portal. This allows you to pass the users through a splash page that you configure and force them to ‘authenticate’ before accessing the internet. Once the victim has ‘logged in’ successfully, they may now browse the internet. To accomplish this, you will need to install and enable the Evil Portal Pineapple Infusion.
Once the Evil Portal has been installed, open the module configuration page and follow the steps exactly as they are listed. Once you have installed the dependencies, made configuration changes, and tested to be sure that the splash page works, modify the /etc/nodogsplash/htdocs/splash.html page to reflect a false Xfinity portal. An example configuration page has been included within the Xfinity Pineapple Github repository and the splash page can be updated either through the Pineapple interface or via SSH. You may want to back up the original splash.html page at this point.
With the evil splash page configured to push users to the ‘authentication portal’ upon joining the access point, launch NodogSplash from the Pineapple interface and be sure to click ‘Start Once’ as this interface does have a tendency to hang. If it does hang, SSH to the Pineapple and run: killall nodogsplash.
With the configuration up and ready for users to connect through your access point, enable the wireless service on the Pineapple and verify that you show a newly available access point, ‘xfinitysifi’. Now sit back and watch as users join your access point and enter their Xfinity account credentials, which will be stored in the auth.log file. With these credentials, someone of lesser morals could use these to conduct illegal activities and have them traced back to the owner of the Comcast account. Not only that, but once the victim is browsing through the Pineapple, this is only the beginning…
You’ll notice that this file logs two password attempts, this is because the landing pages are configured to always fail the first attempt and act as though the second attempt was valid and pass them through to the internet. This was done on purpose to catch multiple authentication attempts in the event they miss-type them during one of the entries.
For bonus points, try setting up an evil Kali Linux access point using a Raspberry Pi for an even greater range of attacks when users connect. Depending on your home router’s configuration, you may even be able to set up a separate guest network as a false ‘xfinitywifi’ hotspot.
None of what we talked about here applies explicitly to Comcast, this can be done on any public access point, though stealing Comcast credentials does have the added advantage of providing attackers with credentials they can later use to mask their online activity. For this reason, users should take steps to protect themselves and be cautious when using these networks.
- First and foremost, Comcast customers can disable this feature if they are so inclined.
- If you have connected to an Xfinity access point in the past, you will pre-authenticate to any Xfinity access point going forward, this includes a masquerading Pineapple. This will not expose your credentials, but all your traffic will be passed through a potentially hostile access point.
- When not using WiFi on your phone / laptop / tablet, disable it, especially when in crowded areas such as an airport.
- When joining one of these access points, try to verify that one really does exist in this area using the Xfinity WiFi app on iOS/Android or by reviewing their Access Point Map.
- Real Xfinity access points will redirect you to https://wifilogin.comcast.net to authenticate, though this could also be fudged by an attacker using DNS Spoofing so it is not a dead giveaway. The real identifier here is that the legitimate landing page is using SSL and has a valid certificate. This can be spoofed as well, but is much harder.
- When connecting to any open Wireless network, use a VPN service to encrypt your traffic.
Then again, you can always just ask someone for their Comcast credentials…
Closing the backdoor…
Today Mikko Hypponen from F-Secure announced they had retrieved and analyzed the excel file used to create a backdoor into RSA.
The attacker used a phishing attempt to send an excel file loaded with an embedded flash object to a recipient inside RSA. Once opened, the excel file used an advanced 0-day exploit executed by the embedded Flash object to create backdoor that allows full remote access to the infected workstation.
Certainly this brings up the obvious warnings of not opening strange attachments, etc. However, the reality is that spear phishing attempts work. This wasn’t even a case of a highly sophisticated spear phishing attack (you can see the original email on Mikki’s blog entry listed above). Examples of successful spear phishing, like the IMF breach and the Epsilon breach, highlight that we should not only continue to educate end users to recognize the red flags and the dangers of opening attachments, but be prepared for the inevitable human mistake.
If a user falls prey to a phishing attempt, and a 0-day exploit evades our endpoint security, what can we do?
- In this case, the backdoor opened connections to servers at mincesure.com that have been used in previous espionage attacks. Using an IP reputation list could have detected the initial connection and actions could have been taken to stop it.
- What if they hadn’t used a known IP address? If you can detect the IP address geo-location, you can see the location is Venezuela. Using geo-location could have detected irregular data traffic being sent to a uncommon destination.
- Or what if the location wasn’t interesting? Once the backdoor was established, having a mechanism to recognize which user accounts access files on the workstation could have identified abuse the system or other accounts.
- Maybe the user accounts had permission to the files. In that case it was the sequence of access to the files after the new connection to an unknown location had been created that could have registered that an attack was occurring.
While it’s important to continually educate our end users on attacks they can help prevent, as security professionals we must have safeguards for when mistakes are made. Although the attacks themselves may not be sophisticated, they can still bypass many of our traditional security solutions. However, with behavior analysis and pattern recognition we should be able to detect and prevent these types of breaches.
I just attended a briefing at Black Hat where Julia Wolf presented a topic titled “The Rustock Botnet Takedown.” During the presentation some very interesting details and examples were given that described some of the ways the botnets operated to blend in with legitimate network traffic. One that stood out to me was that the payloads that compromised machines downloaded were in password-protected RAR files with names such as “mybackup13.rar.” In addition, the command and control servers (C&C) were placed in smaller cities within the United States, such as Kansas City or Scranton, PA. In addition, instead of sending out spam directly over SMTP, which is easily detectable (look for any non-SMTP servers sending out traffic on port 25), some of the botnets discussed would utilize a web-based e-mail service, such as hotmail, allowing the spamming to look like a normal user accessing their hotmail account. When a security analyst sees a RAR file named the way described above being downloaded from a US-based server, the analyst might consider it legitimate traffic. Even if there is a little suspicion and the analyst decides to investigate the RAR file itself, it will be password protected. The analyst is likely to look at the name of the RAR file, taking into consideration that a backup is something a user is likely to password protect, and decide not to investigate further. After a compromise, as the zombie starts to spam, it will also look simply like a user accessing their hotmail account, something many security analysts are likely to not consider malicious in nature. This all sort of reminds me of the premise behind social engineering. The malware is being designed in a way that when looked at from several different angles, paints a picture for a security analyst that there is no actual threat, and in some cases each additional piece re-enforces a belief that things are okay.
So, how can these issues be addressed? It’s unreasonable to assume a security analyst can investigate every time a hotmail server is hit, or any time a password protected file is downloaded. Some automated correlation and/or alarming is in order. One approach might be to simply alarm on any after-hours web-based e-mail access. Another might be to build a correlation rule that looks for an indication of an exploit on the end point (process crashing for instance), followed very shortly by a new connection originating from the same host (from perimeter log data or flow data). A threshold can be set to be around the average size of the payloads that are downloaded before the alarm fires, further limiting false-positives. To look for a possible outbreak, one can take a baseline of average hotmail activity by determine about how many unique internal hosts access hotmail each day, then build an alarm that looks for a higher number of unique hosts hitting hotmail.
Overall the “Rustock Botnet Takedown” presentation was very interesting, and really got my wheels turning on how to detect this activity using correlation on enterprise log-data. I’m looking forward to attending more sessions tomorrow, and will be blogging on other topics I find interesting.
The National Institute of Standards and Technology (NIST) has drafted a document that specifically addresses Personally identifiable information (PII). The document will become Appendix J of SP 800-53. This means FISMA is likely to change to include these new privacy controls.
What does this mean to you? In the short term, nothing. The standard will be in a public comment period until September 2, 2011, and is not scheduled to be included in SP 800-53 until December 2011 when Revision 4 gets released. After that, it still needs to be updated in FISMA and other regulations derived from SP 800-53.
However, the controls outlined in the draft are significant, and will eventually add extra layers of complexity to an organization’s plan to become compliant. I’m still fully digesting the draft, but something that initially stands out is that NIST is treating PII data similar to how PCI-DSS treats card-holder data, and to how NERC-CIP treats Critical Cyber Assets. For example, control SE-1 in the NIST draft states:
a. Establishes, maintains, and regularly updates a PII inventory that contains a listing of all programs and information systems identified as collecting, using, maintaining, or sharing PII;
b. Provides each update of the PII inventory to the CIO or other information security officials to support the establishment of appropriate information security requirements for all new or modified information systems containing PII.
This sounds very similar to the approaches in PCI-DSS for defining and securing the Cardholder Data Environment (CDE), or the NERC-CIP Critical Cyber Asset identification.
The draft also adds on all the standard process and procedure requirements, auditing requirements, monitoring, roles and responsibilities, etc, that are seen across the board in other compliance regulations.
While there will still be quite some time before organizations are mandated to adhere to this draft standard, getting a head-start now will save headaches in the future, and protecting PII is simply the right thing to do, regardless of whether it’s mandated by compliance.
If it didn’t come across as mind-bendingly smug, I might describe the Sega hack as ‘old news before it even broke’. But it is. Old news. Another global digital meganame falls prey to malicious, possibly mafia- or triad-backed ill-doers.
Recently I sat and watched a trusted colleague deliver a presentation to a roomful of security personnel and liken their industry to an air wreck. I believe his exact words were ‘if this were a plane, I’d be running up and down the aisles screaming that we’re all going to die!’. Needless to say this was not well received on the day, but I can’t help but think that he had a point.
Now, I work for an SIEM vendor – the best on the planet, in my opinion, but I’m not going to ambulance-chase this one. There are crucial issues raised now. This raises questions about whose responsibility personal privacy actually IS. As I’ve said before, Amazon, Barclays Retail, Dell, Dabs – any of these guys could get hacked tomorrow and lose YOUR data. What then? It can take weeks to recover from a personal identity breach – resetting email accounts, changing card numbers, suppliers and addressing the huge numbers of interconnected services and locations where your identity converges. This is not to mention the consequences if you actually lose money.
What more can individuals do? Most of us are getting it right: Don’t throw old business cards in the bin. Go for strong passwords, changed at least monthly. Don’t show identity badges in public places (watch out for my next blog on this!). Speak to everyone about the need for security. Educate the less technically literate about malware. Don’t respond to emails or phone calls about online matters unless you initiated the conversation. Keep one eye on the security blogs. Learn the language.
Can companies say the same thing? What about the people who I entrust my identity to? Invest in security – with all that entails. Infrastructure. Dedicated FTEs. Education. Compliance. Regular reviews. Fire drills. Specific executives whose job IS security. Clearly the people who take online privacy seriously are being let down by the companies who don’t, and the more companies that are breached, the more excusable it seems.
My own view on Sega and the bi-monthly additions to the ranks of large companies who didn’t make the grade, is that it’s time to think of security as a multi-partite affair. Your strategy should start with compliance, then loop through infrastructure best practise, via rigorous HR policies and finish by directly addressing social engineering. The modern breach is a blended affair. Only a blended security strategy will work. One that centres around human factors.