반응형

https://xploit.ninty.ninja/Tools

Tools


Tutorials






// 스위치 관련 exploits 정리

https://gbatemp.net/threads/switch-hacking-homebrew-discussion.464282/


Useful Links


Tools By The Community


Proof of Concept Exploits

These exploits are of no use for non-developer people and only show what will be possible soon!



// CVE-2016--4657 - LiveOverflow

https://gbatemp.net/threads/cve-2016-4657-walk-through-and-intro-to-browser-exploitation.464327/


https://reswitched.tech/



// 스위치 관련 software 및  OS 등 관련 정보 기술

http://switchbrew.org/index.php?title=Main_Page

반응형
반응형

출처:https://www.darknet.org.uk/2015/04/evilap-defender-detect-evil-twin-attacks/


EvilAP_Defender-master.zip


infernal_twin.z01

infernal_twin.zip


EvilAP_Defender is an application that helps wireless network administrators to discover and prevent Evil Access Points (AP) from attacking wireless users. The application can be run in regular intervals to protect your wireless network and detect Evil Twin attacks.

EvilAP Defender - Detect Evil Twin Attacks

By configuring the tool you can get notifications sent to your email whenever an evil access point is discovered. Additionally you can configure the tool to perform DoS on discovered evil AP in order to give the administrator more time to react. However, notice that the DoS will only be performed for evil APs which have the same SSID but different BSSID (AP’s MAC address) or running on a different channel. This to avoid DoS your legitimate network.

The tool is able to discover evil APs using one of the following characteristics:

  • Evil AP with a different BSSID address
  • Evil AP with the same BSSID as the legitimate AP but a different attribute (including: channel, cipher, privacy protocol, and authentication)
  • Evil AP with the same BSSID and attributes as the legitimate AP but different tagged parameter – mainly different OUI (tagged parameters are additional values sent along with the beacon frame.

Currently no software based AP gives the ability to change these values. Generally software based APs are so poor in this area).

Whenever an Evil AP is discovered the tool will alert the admin through email (SMS will be supported soon). Additionally the tool will enter into preventive mode in which the tool will DoS the discovered Evil AP. The tool can be configured easily by starting in what we call “Learning Mode”. In this mode you can whitelist your legitimate network. This can be done by following the wizards during the Learning Mode. You can also configure the preventive mode and admin notification from there as well.

Finally, you need to change into Normal Mode or re-run the tool in this mode in order to start discovering Evil APs.


Requirements

Learning Mode:

This Mode can be invoked with the “-L” switch. When running the tool in this mode the tool will start by scanning for the available wireless networks. Then it lists all the found wireless networks with whitelisted APs colored with green. It also lists the whitelist APs and OUIs (tagged parameters).

The tool also provides several options which allow you to add/remove SSIDs into/from whitelist. You need to whitelist your SSID first before running the tool in the Normal Mode. Moreover, you can configure Preventive Mode from “Update options -> Configure Preventive Mode”. First you need to set the Deauthentication time (in seconds) into a number bigger than 0 (setting the value to 0 will disable this mode). Then you need to set the number of time to repeat the attack. This is so important for attacking more than Evil AP because the tool cannot attack all of them in the same time (how can you attack several APs on different channels? Later on we will improve the tool and allow it to attack (in the same time) several APs in the same channel).

The tool will attack the first Evil AP for specified deauthentication time then it will stop and attack the second one and so on. Be careful from increasing the Deatuth time so much because this may attack only one AP and leaving the others running. My recommendation is to set the Deauth time to something suitable such as 10 seconds and increasing the repeat time. Finally, you can configure admin notification by setting admin email, SMPT server address, SMTP username (complete email address) for authentication purpose, and SMTP password. You can use any account on Gmail or your internal SMTP server account.

Normal Mode:

This is the mode in which the tool starts to discover Evil APs and notify the administrator whenever one is discovered. This mode can be invoked by “-N” switch.

반응형
반응형

 [출처] [WASC-36] SSI Injection 번역|작성자 ezno

http://blog.naver.com/PostView.nhn?blogId=ezno&logNo=130142788938



WASC-36 의 번역입니다. 

http://projects.webappsec.org/w/page/13246964/SSI%20Injection )


SSI Injection

Page history last edited by Robert Auger 2 years, 6 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-36


SSI Injection

 SSI Injection (Server-side Include)  server side exploit 기술로서공격자가 웹 애플리케이션으로 나중에 웹 서버에 의해 실행 될 수 있는 코드를 보낼 수 있다. SSI Injection server-side로 해석된 HTML file 삽입하기 전에 사용자 제공 데이터를 유용하게 보이기 위해 웹 애플리케이션의 오류를 악용한다

 

 HTML 웹 페이지를 제공하기 전에웹 서버는 아마 Server-side  Include된 구문을 사용자에게 제공하기 전에 분석하고 실행시킬지 모른다.( 예를 들면게시판방명록 혹은 관리 시스템 콘텐츠 등), 웹 애플리케이션은 사용자 제공데이터에 web page의 소스코드를 삽입할 것이다

 만약 공격자가 Server-side Include 구문을 실행시킨다면그는 아마 임의적으로 운영체제의 명령어 를 실행시키거나제한된 파일의 내용을 포함 시킬 수 있을 것이다이러한 명령은 웹 서버 사용자의 권한 level로 실행 될 것이다.


Example

 다음의 SSI tag는 공격자가 UNIX 기반의 시스템의 root 디렉토리 목록을 보여준다.

<!--#exec cmd="/bin/ls /" -->

  다음의 SSI tag는 공격자가 database 연결 string을 얻도록 하거나, .NET 설정 파일에 다른 중요한 데이터를 포함시킨다

<!--#INCLUDE VIRTUAL="/web.config"-->

 

Mitigation

다음의 체크항목을 확인해야 한다.

 

오직 페이지가 필요로하는 지정된 SSI만 실행가능하게 하고 나머지는 전부 실행할 수 없도록 한다

사용자가 제공한 HTML entity 를 인코딩하여 페이지에 전달하기 전에 SSI 실행 권한을 확인한다.

페이지가 웹 서버 유저가 아닌 파일의 소유주로서 실행시킬 수 있도록 SUExec[5] 를 사용한다   

 

References

"Server Side Includes (SSI)" - NCSA HTTPd

[1] http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html

 

"Security Tips for Server Configuration" - Apache HTTPD

[2] http://httpd.apache.org/docs/misc/security_tips.html#ssi

 

"Header Based Exploitation: Web Statistical Software Threats" - CGISecurity.com

[3] http://www.cgisecurity.net/papers/header-based-exploitation.txt

 

"A practical vulnerability analysis"

[4] http://hexagon.itgo.com/Notadetapa/a_practical_vulnerability_analys.htm

 

"Apache suEXEC Support"

[5] http://httpd.apache.org/docs/1.3/suexec.html http://httpd.apache.org/docs/2.0/suexec.html

 

"Apache Tutorial: Introduction to Server Side Includes"

[6] http://httpd.apache.org/docs/2.0/howto/ssi.html http://httpd.apache.org/docs/1.3/howto/ssi.html

 

"Testing for SSI Injection"

[7] http://www.owasp.org/index.php/Testing_for_SSI_Injection

 

Server Side Include (SSI) Injection

[8] http://capec.mitre.org/data/definitions/101.html

 


반응형
반응형

[출처] Testing for SSI Injection (OWASP-DV-009) 번역|작성자 ezno

http://blog.naver.com/PostView.nhn?blogId=ezno&logNo=130142796061&parentCategoryNo=&categoryNo=&viewDate=&isShowPopularPosts=false&from=postView





원문 https://www.owasp.org/index.php/Testing_for_SSI_Injection 

번역입니다.


Testing for SSI Injection (OWASP-DV-009)

(Redirected from Testing for SSI Injection)

OWASP Testing Guide v3 Table of Contents

 

Brief Summary (생략)

Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI). In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.

 

Description of the Issue

Server-Side Inlcudes는 웹서버가 사용자에게 페이지를 제공하기 전에 구문을 해석하도록 지시한다. Server-Side Inlcudes는 CGI프로그램을 작성하거나 혹은 server side 스크립트를 사용하는 내장된 간단한 언어들로오직 간단한 task들을 실행할 때 만 필요로 한다.

공통 SSI 구현은 외부의 파일들을 include 할 수 있는 명령어들을 제공하며웹 서버의 CGI 환경 변수를 설정하고 출력할 수 있고또한 외부의 CGI 스크립트 혹은 시스템 명령어들을 실행 할 수 있다.

 

SSI 지시를 static HTML 문서에 넣는 것은 다음과 같은 코드를 쓰는 것 만큼 간단하다 

<!--#echo var="DATE_LOCAL" -->

현재의 시간을 출력

<!--#include virtual="/cgi-bin/counter.pl" -->

CGI 스크립트의 결과를 포함

<!--#include virtual="/footer.html" -->

파일 포함

<!--#exec cmd="ls" -->

시스템 명령어의 결과를 포함

 

만약 web server SSI 지원이 가능하면서버는 이러한 명령들을 실행 시킬 것이다기본 설정으로일반적으로대부분의 웹 서버들은 이러한 exec 명령들이 system 명령어를 실행시키도록 허용하지 않는다.

모든 bad 입력 값 검증(bad input validation) 상황처럼문제는 웹 애플리케이션의 사용자가 애플리케이션 혹은 웹 서버가 예측하지 못한 방식으로 데이터들을 제공하도록 허용할 때 발생한다.

SSI injection 때문에공격자가 애플리케이션에(혹은 서버에 직접적으로삽입된 동적으로 페이지를 생성 수 있는 input을 만들 수 있다면한 개 혹은 그 이상의 SSI 지시들을 parse 시킬 수 있다.

전통적인 스크립트 언어 injection 취약점과 매우 유사하다한가지 나은 점은 웹서버가 SSI를 허용하도록 설정해야 한다는 것이다.반면에, SSI Injection 취약점은 실행시키기 좀 더 간단하다왜냐하면 SSI 지시어들은 이해하기 쉽고파일의 내용을 출력하고 시스템 명령어를 실행 시킬 수 있을 만큼 강력하기 때문이다.

 

Black Box testing

finding if the web server actually supports SSI directives.

웹서버가 SSI 지시어들을 허용하는지 대상 웹사이트들의 컨텐츠를 보면서 확인한다.

.shtml 파일이 있다면, SSI를 허용할 가능성이 높다.

아래와 같은 입력 값들이 유효하며입력값이 저장된 것을 확인한다.

< ! # = / . " - > and [a-zA-Z0-9]

To test if validation is insufficient, we can input, for example, a string like the following in an input form

다음과 같은 문자열을 input form에 입력하여 확인을 해본다.

<!--#include virtual="/etc/passwd" -->

이것은 XSS 취약점을 점검하는 것과 유사하다.

<script>alert("XSS")</script>

만약 애플리케이션이 취약하다면지시어들은 삽입이 되고 다음 페이지가 제공될 때 서버에 의해서 해석될 것이다따라서, Unixpassword 파일이 컨텐츠에 포함될 것이다.

만약 웹 애플리케이션이 데이터들을 동적으로 페이지에게 생성하도록 한다면삽입은 HTTP 헤더에서 또한 수행할 수 있다.

GET / HTTP/1.0

Referer: <!--#exec cmd="/bin/ps ax"-->

User-Agent: <!--#include virtual="/proc/version"-->

Gray Box testing and example  (번역 생략)

If we have access to the application source code, we can quite easily find out:

If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate.

Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined.

How the input is handled, what kind of filtering is performed, what characters the application is not letting through, and how many types of encoding are taken into account.

Performing these steps is mostly a matter of using grep to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on).


References

Whitepapers

Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html

Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html

Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi

Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt

SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

Tools

Web Proxy Burp Suite - http://portswigger.net

Paros - http://www.parosproxy.org/index.shtml

WebScarab

String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor


반응형

+ Recent posts