Posts tagged: 'information 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/information-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…
This year I was fortunate enough to be able to attend the Black Hat 2013 conference in Las Vegas. The opening keynote by General Alexander set the mood for what I think will be a common trend throughout the rest of conference this year, connecting the dots. It was a heckle filled talk that left the General unfazed while he kept restating in different ways how we need to “connect the dots” across different dimensions of information to keep our country safe and failing to do so… essentially, will allow the bad guys to win.
Being able to efficiently and accurately connect the dots is the Holy Grail in all domains of security, including information/network security. From the talks I’ve attended in just one day, it’s obvious that there are a lot of bright people and companies out there in the malware community who are studying, reverse engineering and coming up with ingenious ways to identify malware. It always fascinates me to see how clever malware can be and the various tricks they employ. For instance, fast flux domain switching. This isn’t a new technique but has been widely utilized for a variety of criminal enterprises. Enterprises akin to malware delivery, spamming, phishing schemes, and to other activities leading to even darker criminal intentions. It’s an efficient way to utilize a botnet by having numerous DNS A records associated with a single FQDN. Then the key step is to swap out these IPs every 5 minutes or so without changing the domain name. This technique is only becoming easier to implement as time goes on with competing hosting sites practically giving away domains for just 99 cents.
The good news is that the detection of malware employing the use of fast flux domain switching exists. It has existed for a while. It just requires the collection, storage, and normalization of webserver and DNS logs – not to mention efficient lookup & dot connecting capabilities on that data. You hear this a lot, but I think it bears repeating. The amount of data floating around out there is beyond non-trivial, it’s overwhelming. Being able to leverage advanced intelligence techniques on key meta data fields is the fundamental step in being able to connect the dots required for the identification of advanced malicious threats.
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.