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.https://blog.logrhythm.com/tags/information-security/feed
Last weekend, a significant number of celebrities had their private photos and videos exposed to the internet in the largest celebrity data leak to date. Initial speculation led people to believe that their iCloud accounts were the primary targets. If this is indeed the case, there is a popular theory behind this ‘hack’.
This may have been the result of a brute-force attack against each account using select passwords from the ever popular rockyou password list in conjunction with the ibrute script written by @hackappcom. This python script essentially bypasses the AppleID lock feature of the Find My iPhone application. In an article published by Wired, once the password was successfully brute-forced, the Elcomsoft Phone Password Breaker (EPPB) tool was used to download this data from iCloud backups. This is due to the fact that EPPB allows anyone to impersonate the victim’s iPhone and download the full backup.
If this was indeed the source, it is a result of an amalgamation of the fact that Find My iPhone did not implement adequate brute force protection, these celebrities picked some really weak passwords, and did not implement Apple’s two-factor authentication.
Another aspect to consider is that the culprits gained access to much more than pictures and videos, such as address books and other sensitive data that is all available via iCloud. More importantly, with many organizations adopting iPhones and Androids in the workplace, attacks such as this increase the ever expanding possibility of corporate data loss. One obvious risk with the release of these pictures is that location data, included in the image Exif metadata gives away the locations where the pictures were taken (warning NSFW link).
All things considered, it is unlikely that only one avenue was taken to obtain all of this data. More importantly, just because everything was dumped on the internet at the same time and that a majority of the photos were taken with an iPhone does not at all mean that it was all stolen at the same time or even by the same person. I assume a team with a common goal was behind this, and they used many different means to obtain this data.
Apple released a statement on the leak:
“When we learned of the theft, we were outraged and immediately mobilized Apple’s engineers to discover the source,” they said. “After more than 40 hours of investigation, we have discovered that certain celebrity accounts were compromised by a very targeted attack on user names, passwords and security questions, a practice that has become all too common on the Internet. None of the cases we have investigated has resulted from any breach in any of Apple’s systems including iCloud or Find my iPhone. We are continuing to work with law enforcement to help identify the criminals involved.”
Granted, Apple did fix the Find My iPhone specific vulnerability shortly after discovery, which is very good, but a glaring hole like this should not have made it past QA. The funny thing is, this could have been avoided entirely if the vulnerability was disclosed to Apple prior to its public release. However, researchers may have been more encouraged to share this information with Apple, had they instituted a bug bounty program. Could all this stolen data be from iCloud? Maybe. Could it have been extracted in the same manner? Certainly, but not likely in my opinion. My guess is that good old fashioned social engineering played a part in obtaining access to some accounts.
In the wake of this recent leak, there are a few lessons that we can all take away from this to help better protect our own cloud data, taking into account the many methods by which it can be obtained:
- Whenever possible, implement multifactor authentication. Apple has a two-step verification feature which will assist with this.
- If multifactor authentication is not an option, question the sensitivity of the data you are storing on the service and do not store it in the cloud if you are worried about someone else getting ahold of it.
- Use strong and unique passwords for every site.
- Use pass phrases instead of passwords.
- Use a password manager to store, manage, and create strong + unique passwords for each site that you use.
None of these security recommendations are in any way new or at all difficult to implement. The problem is that too few people follow these basic guidelines and continue to use the same weak passwords for all of their online activities, resulting in the theft of sensitive data. Do not rely on companies to protect your information, take your own precautions and educate yourself on the risks.
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.