Web Security Blog

Syndicate content
Official Blog of Trustwave's SpiderLabs - SpiderLabs is an elite team of ethical hackers, investigators and researchers at Trustwave advancing the security capabilities of leading businesses and organizations throughout the world.
Updated: 5 hours 38 min ago

[Honeypot Alert] New Bot Malware (BoSSaBoTv2) Attacking Web Servers Discovered

Mon, 2014-09-15 08:00

Our web honeypots picked up some interesting attack traffic.  The initial web application attack vector (PHP-CGI vulnerability) is not new, the malware payload is.  We wanted to get this information out to the community quickly due to the following combined threat elements -

  • Active exploit attempts to upload/install the malware
  • The overall low detection rates among AV vendors
  • The malware is actively being sold in underground forums 

Update - Another security researcher has also seen similar activity in his ModSecurity honeypots back on August 26.  Some of the tactics have changed but the core of the attack seems the same.

We have already discussed the initial PHP-CGI vuln attack/exploit vector in a previous blog post.  What is interesting in these attacks are the actual tools installed if the attack is successful.  Here is the initial screen shot of the attack payloads taken from the ModSecurity audit log file on the honeypot:

We cross referenced this attack with our own IDS alerts from Trustwave MSS team and have seen a definite increase in scanning activity for the inital web application attack vector (PHP-CGI) within the last month:

Keep in mind that exploit vectors and payloads are separate ecosystems.  They are often interchanged with each other.  For example, we often see new PHP command injection vectors used within botnet code that execute or install the same backend malware code.  The initial URL encoded data in the QUERY_STRING decodes to:

The final "auto_prepend_file=php://input -a" data tells php to take the info from the POST payload and append it to any existing code and execute it.  If we look at the complete PHP code in the request body, we see that there are actually 2 different variables that contain base64 encoded data.  

This data is then later decoded and places into temp files and then executed.

What are these files?  If we base64 decode the variable data, we can see that they are in fact ELF binaries that are packed with UPX -

Here is some quick static analysis -

The files are essentially the same, however one is 32-bit and one is 64-bit.  The attacker isn't even bothering with checking the web server OS version... they are just trying to execute both to see which one might work.  Checking this file over on VirusTotal shows that only 4 AV vendor currently detects this file as malicious:


 Note - We have internally verified that Trustwave AV does detect this file as malicious.

 The file contains many clear text URLs that have been associated with Botnet C&C activity:

  • srv5050.co

  • ka3ek.com

  • ircqfrum.com

  • 8rb.su 

Once we see the IRC botnet code, we get a clearer idea of what we are dealing with here:

There are many IRC commands here.  IRC botnet code installs are nothing earth-shatteringly new however most of the variants we capture are written in Perl, PHP, etc...  This one is binary C code.  One interesting tactical note - the destination IRC port on these C&C servers is 53.  This is a smart move from the attacker's perspective as DMZ network firewalls may allow web servers to initiate outbound DNS queries.   

Additionally, we see the highlighted section of code which seems to identify this code as: BoSSaBoTv2.  After some searching, we were able to find that this code is actively being sold on underground forums.  Here are some example screenshots:

Notice some of these features including bundling a Bitcoin Miner program.  This is interesting as this shows another aspect how an attacker is looking to abuse their access to a compromised web server.  They can siphon off local system resources such as CPU and RAM in attempts to create Bitcoins.  Here are some of the commands for downloading and running the Bitcoin miner -

 

We also see on the hacker forum that this malware is for sale at affordable prices:

 

Conclusion

We wanted to get this information out to the community quickly due to the following combined threat elements -

  • Active exploit attempts to upload/install the malware
  • The overall low detection rates among AV vendors
  • The malware is actively being sold in underground forums 

Here are a few defensive steps:

Update Network Firewall Egress Rules

All too often, we see weak or non-existent egress firewall rules.  As an example of why you need them - during our research, we saw the IRC botnet master send down commands to have the malware update itself by downloading a new version -

If you can block outbound connections from your web servers to 3rd party hosts, you can significantly help to reduce an attacker's ability to expand their breach.

Deploy a WAF

Our honeypots picked this up due to alerts from our ModSecurity WAF rules.  The Trustwave WAF also detects these attacks.  Not only will this give you some base protections, but it also provides better logging vs. standard web server log files.  Speaking of web server log files....

Check Your Logs

Review your web server log files to see if you have been receiving these initial PHP-CCI attacks.

Pay close attention to the HTTP Response Status Codes. Anything other than a 404 - Not Found could indicate trouble. 

Categories: web server

[Honeypot Alert] Active Probes for WordPress revslider_show_image Plugin Local File Inclusion Flaw

Wed, 2014-09-03 15:22

A local file inclusion vulnerability in the WordPress Slider Revolution Plugin has been released:

Apparently this vulnerability has been discussed on some underground forums for a couple months but it wasn't until these more main stream websites published data that we saw attackers start scanning for vulnerable sites.  Our web honeypots picked up increased scanning activity today.  Here is an example full audit log dump of the HTTP request from our ModSecurity WAF:

In this attack example, the attacker is trying to access the WordPress config file in the hopes of obtaining sensitive data such as database credentials.

Recommendations Update your WordPress Slider Revolution Plugin

Sucuri Security is seeing similar activity and it also reporting that the developer of this Plugin chose to silently patch this vulnerability.  This did a disservice to the Plugin userbase to be aware of the problem and to prompt updating.  A couple notes:

  • Updating this plugin may need to be done manually if your WP manager does not provide an interface for it.
  • Beware that "disabling' the Plugin may end up being superceded by the Theme and be re-enabled.  You may need to remove it altogether if you can not update it. 
Use WAF Protections

WAFs can be used to help prevent exploitation until you can get your systems updated.  Trustwave's WebDefend WAF would block this attack either through a generic "Directory Traversal Attack" signature or through an anomaly of the learned resource profile.  For ModSecurity WAF, we have added a new signature to our commercial rules feed:

Categories: web server

Blackhat Arsenal 2014: Live ModSecurity Demonstrations

Tue, 2014-08-05 11:00

If you are heading out to Blackhat USA 2014 in Las Vegas this week, please stop by the Arsenal Tools area on Thursday morning to see live demonstrations of ModSecurity's advanced features.

Arsenal Demonstration Information

  • Location:  Mandalay Bay Convention Center, Las Vegas, NV.
  • Event: Blackhat Arsenal
  • Conference Location: Breakers JK, Level 2.  ModSecurity will be at Station 4.
  • Date/Time: Thursday, August 7 between 10:00 a.m. - 12:30 p.m.

Some of the live demos that will be shown include:

Hope to see you all in Las Vegas!

Categories: web server

[Honeypot Alert] Wordpress XML-RPC Brute Force Scanning

Wed, 2014-07-23 17:37

There are news reports of new Wordpress XML-PRC brute force attacks being seen in the wild.  The SANS Internet Storm Center also has a Diary entry showing similar data.  We have captured similar attacks in our web honeypots so we wanted to share more data with the community.  Please reference earlier blog posts we have done related to Wordpress:

Thanks goes to my SpiderLabs Research colleague Robert Rowley for help in validating data for this blog post.

Wordpress XML-RPC wp.getUsersBlogs Component

Here is the general format of accessing this XML-RPC component:

As you can see, it is expecting username and password parameters. 

Example Honeypot Attack

Here is the data captured on our ModSecurity honepot:

This request was sending the following credentials:

  • username = admin
  • password = jeepjeep

Since we do not have Wordpress installed on our honeypot, there was no real response to this XML-RPC request.  If we do send this request to some demo sites we have with Wordpress, we can see different methods of response.

Component Not Installed/Activated

If you do not have XML-RPC installed or activated, then you would receive a response similar to the following:

Component Activated but Incorrect Credentials

If the XML-RPC component is activated, but the user sends incorrect credentials along with the wp.getUsersBlogs request, they would receive a response similar to the following:

Component Activated with Correct Credentials

If the client sends the correct credentials to the XML-RPC component, then they would receive and XML response similar to the following:

Defenses  Not Just wp.getUsersBlogs

It is important to note that the use of the wp.getUsersBlogs is but one of many possible vectors here so implementing a dumb block of that specific XML-RPC call will not suffice.  Pretty much all of the components listed in XML-RPC API documentation require a username/password.

Block the WinHttp.WinHttpRequest.5 User-Agent

There are many reports that list this as some type of scraper tool possibly related to a virus.  We have added this User-Agent string to our OWASP ModSecurity CRS repo.

Alert on XML-RPC Authentication Failures

We have added rules to our commercial ModSecurity rules package that will identify these XML-RPC authentication errors in the response bodies and generate alerts.

Categories: web server

Setting HoneyTraps with ModSecurity: Adding Fake Hidden Form Fields

Thu, 2014-06-12 12:35
This blog post continues with the topic of setting "HoneyTraps" within your web applications to catch attackers.  Please review the previous posts for more examples: This blog post will discuss Recipe 3-4: Adding Fake Hidden Form Fields from my book "Web Application Defender's Cookbook: Battling Hackers and Protecting Users".   Recipe 3-4: Adding Fake Hidden Form Fields

This recipe will show you how to add fake hidden form field data to existing forms and alert if the data is ever manipulated.

Ingredients

Hidden Form Fields

HTML hidden form field are just like normal form fields except for one distinct different; they are not displayed by the browser to the user.  Hidden fields are used as a mechanism to pass data from one request to another and their contents are not supposed to altered.  Web developers often make the mistake of believing that hidden parameter data cannot be manipulated however this is not the case.  While the browser does hide these form fields, the data is still accessible by the client.  They can either simply choose to view the source or use a browser plug-in.  Figure 3-6 shows an example of using the Groundspeed plug-in for the FireFox browser in order to view hidden form fields on the Twitter login page.

Figure 3-7: Hidden Form Fields on Twitter’s Login Page

The Groundspeed plug-in’s main benefit is that you are able to correlate the raw html elements of a page to the actual user interface.  In Figure 3-6, we see that there is a hidden form field named “context” with a value of “front” within the Sign Up form.  This is how the raw html hidden form field looks in the source:

<input type="hidden" value="front" name="context">

When the user clicks on the submit button, the hidden form field data will be sent along with all of the normal fields that accepted direct user input.  Here is how the request looks being sent back to the web application:

POST /signup HTTP/1.1 Host: twitter.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Referer: http://twitter.com/ Cookie: pid=v1%3A1328144669186587529055; guest_id=v1%3A132922623466696969; js=1; __utma=43838368.1969980750.1329226294.1329235683.1331320055.3; __utmz=43838368.1329226294.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); k=10.34.252.138.1331320050314838; _twitter_sess=BAh7CToMY3NyZl9pZCIlNmU3YmYyOTQ3ZDIzZjY0NzNhNzMzN2ZkOWI2NmIw%250AY2YiCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhh%250Ac2h7AAY6CkB1c2VkewA6D2NyZWF0ZWRfYXRsKwiO0tv4NQE6B2lkIiUyZmNl%250AMTNlY2E0NThjN2QyZWY3NmY2YWI0MGNmYTZlZA%253D%253D--e0ad2fef301aa20cc0af4431d0e9f365cc0a92e2; original_referer=4bfz%2B%2BmebEkRkMWFCXm%2FCUOsvDoVeFTl; __utmb=43838368.1.10.1331320055; __utmc=43838368 Content-Type: application/x-www-form-urlencoded Content-Length: 105   user%5Bname%5D=Bob+Smith&user%5Bemail%5D=bob%40email.com&user%5Buser_password%5D=B1gB0b1199&context=front   

Notice the bolded context parameter data at the end of the request body?  That is the hidden form field data.  By looking at this data, there is no way to know that this parameter data originated within a hidden form field.  Attacker’s can easily manipulate this data once they are outside the confines of the web browser just like any other input field.

Adding Fake Hidden Form Fields with ModSecurity

Just as we did previously with adding in the fake HTML comments, we can use the same methodology to inject fake HTML hidden form fields.  The key to this technique is key on the closing </form> HTML form tag and inject our honeytrap data just before it.  The following rule will accomplish this task:

# # Add a fake "debug" hidden parameter to forms. # # Here are some examples of parameter names/values that could be used: # # - debug=false # - debug=0 # - role=user # - role=1 # - admin=false # - admin=0 # # Make sure that your settings here match the detection rules above. # SecRule STREAM_OUTPUT_BODY "@rsub s/<\/form>/<input type=\"hidden\" name=\"debug\" value=\"false\">>\/form>/" "id:'999009',phase:4,t:none,nolog,pass"

With this rule in place, all HTML forms will have this honeytrap hidden parameter data injected into it.  Figure 3-7 shows the updated Groundspeed data, which highlights our honeytrap hidden field data.

Figure 3-8: Groundspeed Displays Honeytrap Hidden Form Field Data

Just as before, we next to implement a rule that will trigger if this data is ever manipulated.  Here is an example rule:

SecRule ARGS:debug "!@streq false" \ "id:'999010',phase:2,t:none,log,block,msg:'HoneyTrap Alert: Fake HIDDEN Form Data Manipulated.',setvar:ip.malicious_client=1" Conclusion

Attackers will quite often attempt to manipulate form fields in attempts to tamper with the web application logic.  By setting bogus hidden form field data, we can quickly identify malicious clients and take appropriate defensive actions. 

 

Categories: web server