[ABD] Proxy Revealer Olympus 0.3.3

Any abandoned MODs will be moved to this forum.

WARNING: MODs in this forum are not currently being supported or maintained by the original MOD author. Proceed at your own risk.
Forum rules
IMPORTANT: MOD Development Forum rules

WARNING: MODs in this forum are not currently being supported nor updated by the original MOD author. Proceed at your own risk.
Locked
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

[ABD] Proxy Revealer Olympus 0.3.3

Post by jasmineaura »

2010-07-12 - Resuming development, on SVN for now, till a working release is ready for phpBB-3.0.7-PL1

----

Due to lack of help in developing this MOD, I am the only one debugging the issue some people complained about (being unable to log in as admin or user after installing this MOD), and so I would appreciate any input/testing from others.
PLEASE DO NOT TEST THIS ON A LIVE/PRODUCTION FORUM YET! (At least until we find and fix the source of this bug)

More on that here...

Modification Name: Proxy Revealer Olympus
Author: jasmineaura

phpBB2 Author: TerraFrost
phpBB2 MOD: Proxy Revealer (IP unmasker)

Modification Description:: This is a port of Proxy Revealer 2.0.1 (phpBB2) to phpBB3. Attempts to determine someone's "real" IP address, using a myriad of techniques, and "blocks" such people. Original techniques included XSS, Java, and X_FORWARDED_FOR checks. In this port, Flash has been added as yet another unmasking technique. There maybe additional techniques added on later.
Modification Version:: 0.3.3 BETA
Requirements:
  • phpBB3.x
  • *Optional* Shell access on the hosting server as normal user if the Flash technique is to be used (for running included perl XMLSocket daemon script - Win/Linux/BSD/Solaris should all be supported)
Features:
  • HTTP(S)/SOCKS Proxy Detection by Flash and Java applet techniques, and optional blocking.
  • HTTP(S)/SOCKS Proxy Detection by Tracking-IP Cookie, and optional blocking.
  • CGI-Proxy Detection by XSS and Flash techniques, and optional blocking.
  • Transparent HTTP Proxies Detection with X_FORWARDED_FOR technique, and optional blocking.
  • Optional "Require Javascript enabled" feature (helps circumvent Firefox with "NoScript" addon).
  • Optional auto-banning of unmasked IP addresses with the chosen blocking techniques above.
  • Blocking/Banning done within the confines of phpBB3's "Session IP Validation" setting in the ACP.
  • Auto-Logging masked/unmasked IP addresses with possible extended info if Flash/Java was used.
  • Exception List Management for excluding particular proxy servers you may be running.
Please note that enabling auto-blocking with the "Cookie" or "X_FORWARDED_FOR" methods is not recommended unless you know what you're doing (and frequently check the logs of this MOD) to avoid false positives.

New Features in 0.3.0:
  • Option in "Settings" to completely disable this MOD
  • Optional blocking of all Tor exit-nodes IPs with the "Tor IPs" method (uses TorDNSEL)
  • Optional "Defer Scan Methods" in "Settings" (to allow for username exceptions)
  • Sections in "Exceptions" to add/remove Usernames to/from the exceptions list
  • Installer (also works as Updater for old releases that didn't store the MOD version in the database). Automates SQL setup and ACP Modules installation.
New Features in 0.3.1:
  • Signed & Trusted Java applet (Thawt signing authority). No more server-side workarounds needed for the Java detection method.
New Features in 0.3.2:
  • HTTP(S)/SOCKS/CGI Proxy Detection by RealPlayer technique, and optional blocking.
  • CGI-Proxy Detection now possible with the updated Java technique (along with HTTP(S)/SOCKS)
New Feature in 0.3.3:
  • DNSBL checking; allows logging and optionally blocking IPs listed as Open HTTP/SOCKS proxies in the appropriate DNSBLs
Screenshots:

Example showing the use of a CGI-Proxy to visit the forum site, and the blocking in action after first click (detection methods XSS & Flash in action in the background):
Image

Auto-banning enabled -> example showing browser using HTTP Proxy getting ban message after first click (detection methods Flash & Java in action in the background):
Image

Screenshots of the detection of flash (no flash, or old flash version < 9.0):

- No Flash detected but javascript enabled, user gets a DHTML/AJAX popup with sneaky message to lure them to install it:
Image

- Flash version older than 9.0 detected, user gets a popup and prompt to upgrade their flash version automatically using the expressInstall method of swfobject (latest version as of date - 2.1 - is used)
Image

Signed & Trusted Java applet (since version 0.3.1):
Image

Admin Screenshots:

External IPs Log:
(showing a CGI-Proxy's URL that was used when you roll over the "XSS" link - opens in a popup if clicked)
Image

Internal IPs Log:
Image

Search Functionality:
(clicking a masked ip automatically searches for all other real IPs that used that proxy, including all methods that detected it)
Image

Whois Functionality:
(clicking a real ip automatically pops up a window with the whois results - imitating the whois functionality from includes/acp/acp_users.php and using the user_ipwhois() function from includes/functions_user.php)
Image

Extended Flash Plugin Information:
(clicking the "Flash" method on any row pops up a window detailing the masked end-user's browser information and the Flash plugin version they have installed)
Image

Extended Java Plugin Information:
(clicking the "Java" method on any row pops up a window detailing the masked end-user's browser information and the Java plugin version they have installed)
Image

RealPlayer (or RealAlternative) Detection method & Plugin info (since version 0.3.2):
Image

DNSBL Checking & Blocking (since version 0.3.3):
Image

Settings:
Image
Image

Exceptions list:
Image
Image

Actions get automatically logged in admin (and moderator) log:
Image

Demo URL: not yet available
Demo Username: N/A
Demo Password: N/A

Modification Download:Proxy Revealer Olympus 0.3.3 Beta (Removed until further notice)[/url]

SVN source tree anonymous checkout:

Code: Select all

svn checkout https://proxy-revealer.googlecode.com/svn/trunk/ proxy-revealer-read-only
MODX 1.2.1
Image
Last edited by jasmineaura on Thu Aug 12, 2010 6:41 pm, edited 33 times in total.
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

This is not a double post, but a fork from the original DEV topic [DEV] Proxy Revealer Olympus due to some differences, and imho, lack of cooperation that hinders the development of this MOD.

Since the original thread started over a month ago, and as I did all the work so far by myself, I've decided to start a new thread of my own. Apologies to 3Di, but I don't think it should take a month to port any part of the code. Understandably, many of us have real-life duties and obligations that may end up putting off our plans.

Moreover, I do not appreciate the original topic getting locked by 3Di simply for the reason that I was discussing development-related information/updates of the MOD on the thread, when the original phpBB2 MOD author was giving valuable feedback on much of what I was posting. Afterall, the thread was marked as [DEV]...

Cheers,
Jasmine
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

Meanwhile, anyone may check out a read-only working copy anonymously over HTTP using svn:
svn checkout http://proxy-revealer.googlecode.com/svn/trunk/ proxy-revealer-read-only
Alternatively, if anyone wants to only look at the code (and possible changes) from their web browser:
http://code.google.com/p/proxy-revealer ... #svn/trunk

As of date, this is the working full functionality, though not yet including the ACP/admin part of the MOD.

Will be releasing a full archive download link in the first post of this thread as soon as I've completed the ACP part of this MOD, at which point I'll be marking this thread as [BETA].

Cheers :)
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

Per my earlier post on the IE7 issue not loading iframe1 (thus XSS check not being triggered) and the proposed solution:
http://www.phpbb.com/community/viewtopi ... 0#p6919305

I confirmed that this only affects IE7. Tested with IE6 and it didn't exhibit this problem, so the modified javascript part (in the template's overall_header.html) that I proposed earlier should be fine I think:

Code: Select all

<![if !IE]>
<script language="Javascript" type="text/javascript">
  document.getElementById("iframe1").src = "{U_PROBE_XSS2}&url="+escape(location.href);
</script>
<![endif]>
<!--[if IE 7]>
<script language="Javascript" type="text/javascript">
  document.getElementById("iframe1").onload = function(){
    document.getElementById("iframe1").src = "{U_PROBE_XSS2}&url="+escape(location.href);
  };
</script>
<![endif]-->
Thus far, I tested IE6, IE7 and Firefox 3.
To be tested, Firefox 2, Opera.
Unfortunately I don't have access to a Mac or OSX, so if anyone can test Safari as well that would be great.
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

A minor update to probe.php (already committed to svn) that I wanted to describe in depth, hopefully TerraFrost (original author of the phpBB2 version of the MOD) would like to see this and give me his opinion..

I noticed that a lot of CGI-Proxies do not convert over the URLs of iframe1 the second time around - when the javascript code updates it with the {U_PROBE_XSS2} link (which is essentially the same as the {U_PROBE_XSS} link that is iframe1's original "src" parameter) concatenated with "&url="+escape(location.href)

Wisely enough, given the original author's awareness of this situation, he remedies it as follows (as he kindly described it in the comments of functions.php's changes in the original MOD):
say a CGI proxy didn't convert over the URLs of an iframe. that means that the IP address iframe2 and iframe3 add is going to be the "real" IP address whereas normally it'd be the "masked" IP address. to remedy that, we make a seperate request to iframe4 via an iframe we'll call iframe0 and add the IP address to that. that way, even if iframe2 and iframe3 pass on the "real" IP address to iframe4, iframe0 can still pass on the "masked" IP address.
This is really ingenious and thoroughly thought out. However, there's one minor discrepancy I noticed which I'd like to describe in detail here:

The Scenario:
In the original MOD, the IP address which is passed to Java (before it loads) is "$client_ip" (equivalent to $user->ip in phpBB3).
Consequently, I originally followed the same method in the ported version of probe.php; setting ip=$user->ip in the $java_url variable (which gets passed to Java's applet in HTML as the "path" parameter), and in $flash_vars variable (which gets passed to Flash's object in HTML as the "FlashVars" parameter)

The issue:
Remember those CGI-Proxies that don't covert over the URLs?
Those URLs that they don't covert over are specifically the ones with "mode=xss" in them as $_GET vars, which trigger the case 'xss' in probe.php where $java_url and $flash_vars are defined then the HTML applet for Java and the HTML object for Flash are loaded.
That means in this case we're passing the "real ip" to Java and Flash before they attempt to unmask the end-user. So what happens is that Java and Flash will see that the original IP which they are passed matches the IP they discover from their checks, and therefore neither of them will trigger a block.

The Solution:
We pass the original ip which is:
- the $_GET['ip'] instead of $client_ip in the original phpBB2 version of the MOD
- $orig_ip in our ported version (which is basically the $_GET['ip] after htmlspecialchars - and stripslashes run on it if needed - by request_var() function) instead of $client->ip

The Logic:
1. CGI-Proxy doesn't convert over the URL that is loaded by javascript in iframe1
2. Request "probe.php?mode=xss&ip=pro.xy.ip.addy&extra=sid,key&url=http://cgi-proxy" comes directly from client
3. case 'xss' in probe.php loads Flash object and Java applet HTML, passing $orig_ip (which is $_GET['ip'] after sanity checks) rather than $user->ip
4. Java is loaded by client directly from our server, Java connects back, then case 'java' compares $orig_ip with $user->ip, finds they're different, so the test triggers and logs
5. Flash is loaded by client directly from server, Flash connects back, then case 'flash' compares $orig_ip with $user->ip, finds they're different, so the test triggers and logs as well

End Result:
The masked (through a CGI-Proxy) session will trigger the Java and Flash tests, and most likely the XSS test as well unless the CGI-Proxy filters out our XSS techniques. :P
So instead of session_speculative_test getting only a '2' for a successful unmasking XSS test, it gets '14'. That's '2' for XSS method + '4' for Java method + '8' for Flash method.

The added advantage:
Consider an updated CGI-proxy that filters our XSS technique, but fails to convert over the URLs described above. Java and Flash would still be loaded and triggered, effectively blocking the session (and optionally banning the real ip) :)

Consider another updated CGI-proxy that filters our XSS technique, and converts over all the URLs...
Java would not connect back to our server because it was loaded from the CGI-Proxy server (same-domain policy), but Flash will! Why?
Because of the way the Flash method is designed. It uses XMLSocket() connections which require a XMLSocket Policy file request to the server to authorize the connection before it attempts to connect back to it. And on the server, we run a small perl script called xmlsockd.pl that responds back and authorizes the connection back on this port, and from ALL domains (domain="*") so that Flash can connect back, regardless of what domain it was loaded from. Therefore, the Flash test will trigger, effectively blocking the session (and optionally banning the real ip) as well :D

neat, no?
Last edited by jasmineaura on Sun Sep 07, 2008 2:56 am, edited 1 time in total.
sportsfan200798
Registered User
Posts: 14
Joined: Sun Jun 22, 2008 6:22 pm

Re: [ALPHA] Proxy Revealer Olympus

Post by sportsfan200798 »

Can you give it an option, in the ACP, to only check for proxies upon registering?
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

sportsfan200798 wrote:Can you give it an option, in the ACP, to only check for proxies upon registering?
As it is, checking for proxies is only done once when a session is created.
So this would happen at first visit, login, or registration time, or if sessions ends and a new session is created because of timeout, or if the ip address changes and phpBB3's Session IP Validation destroys the session.

Having said that, it shouldn't be too difficult to move the code from:
styles/prosilver/template/overall_header.html and includes/functions.php
to:
styles/prosilver/template/ucp_register.html and includes/ucp/ucp_register.php

if that's all you need..

Edit: I meant functions.php, not session.php... Corrected (I am too tired..)
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

-cleanup-
Last edited by jasmineaura on Sun Sep 14, 2008 12:10 pm, edited 1 time in total.
User avatar
beggers
Registered User
Posts: 1257
Joined: Fri Nov 23, 2001 8:19 pm
Location: Las Vegas
Contact:

Re: [ALPHA] Proxy Revealer Olympus

Post by beggers »

Glad to see that this is still being actively developed. I used to use the phpBB2 version and it was great. If you're able to port it to phpBB3 and improve it I'll definitely try it.
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

Updated screenshots in first post
Last edited by jasmineaura on Sun Sep 14, 2008 12:11 pm, edited 2 times in total.
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

Here's an interesting unmasking method I've been thinking about for a while, perhaps this could be used later in the future... I've been itching to give it a try, so I wasted a couple hours playing with it to give a barebone PoC..

Scenario:
User visits the site through a CGI-Proxy or after configuring an HTTP Proxy or SOCKS server in their browser, and we use an embedded object to load an rtsp:// link (Real time streaming protocol) but pointing to our script instead of a streaming server/media :twisted:

Most users won't expect this to have setup RTSP proxy in their Real Player / Quicktime player (both support rtsp), so we get around their browser's proxy configuration :-)

I only tried with Real Player plugin so far, but I'm sure it will work with quicktime as well.
(And just for fun I experimented with windows media player and mms:// links - also possible) :-)

Here's a sample standalone php script I used for testing the above mentioned technique (call it decloak.php or whatever):

Code: Select all

<?php

$log_file = "decloak.log";

function iso_8859_1_to_utf16($str)
{
	// the first two characters represent the byte order mark
	return chr(0xFE).chr(0xFF).chr(0).chunk_split($str, 1, chr(0));
}

if ( !isset($_GET['ip']) && !isset($_GET['get_html_utf16']) )
{
	$iframe_url = $_SERVER['PHP_SELF'] . "?get_html_utf16";
?>
<html>
<head><title>decloak.php</title></head>
<body>

<p align="center">Below is a hidden iframe that opens another page including an object/embed that attempts to unmask you using real player</p>

<iframe src="<?php echo $iframe_url; ?>" width="1" height="1" frameborder="0"></iframe>

</body>
</html>

<?php
}

if ( isset($_GET['get_html_utf16']) )
{
	header('Content-Type: text/html; charset=UTF-16');

	$rtsp_url = "rtsp://" . $_SERVER['SERVER_NAME'] . ":" . $_SERVER['SERVER_PORT']
		. $_SERVER['PHP_SELF'] . "?ip=" . $_SERVER['REMOTE_ADDR']
		. "&user_agent=" . htmlspecialchars($_SERVER['HTTP_USER_AGENT']);

	$str = <<<DEFAULT
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head><title></title></head>
<body>

<object id=RVOCX classid="clsid:CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA" height="1" width="1">
	<param name="controls" value="ImageWindow">
	<param name="autostart" value="true">
	<param name="src" value="$rtsp_url">
	<embed height="1" width="1" controls="ImageWindow" src="$rtsp_url" type="audio/x-pn-realaudio-plugin" autostart=true></embed>
</object>

</body>
</html>
DEFAULT;

	echo iso_8859_1_to_utf16($str);
	exit;
}

if ( isset($_GET['ip']) && ($_GET['ip'] != $_SERVER['REMOTE_ADDR']) )
{
	// we managed to break out of the proxy, so get the data we need
	$orig_ip = addslashes($_GET['ip']);
	$real_ip = addslashes($_SERVER['REMOTE_ADDR']);
	$browser = isset($_GET['user_agent']) ? addslashes($_GET['user_agent']) : '';
	$player = isset($_SERVER['HTTP_USER_AGENT']) ? addslashes($_SERVER['HTTP_USER_AGENT']) : '';

	$data_str = "Masked IP: $orig_ip\nReal IP: $real_ip\nBrowser: $browser\nPlayer: $player\n\n";

	// log it to file
	$fh = fopen($log_file, "a") or die("Can't open file: $log_file");
	fwrite($fh, $data_str) or die("Can't write to file: $log_file");
	fclose($fh);
}
?>
I used the UTF16 encoding method because even though Internet Explorer doesn't care if a CGI-Proxy rewrites the URL (rtsp://... -> http://anon-cgi-proxy/rtsp://...) and opens the embedded rtsp:// link normally, firefox doesn't (it tries to check for real player update instead LOL :lol: )
So we encode the HTML page containing our object/embed that reference the rtsp link just in case a CGI-Proxy is used - to avoid rewriting the rtsp:// link...

What happens in the background?

First I go to http://anonymouse.org (cgi-proxy) and browse to http://mysite.com/test/decloak.php

Now lets look at the access_log of the web server:

193.200.150.45 - - [10/Sep/2008:04:56:47 -0700] "GET /test/decloak.php HTTP/1.0" 200 489 "-" "http://Anonymouse.org/ (Unix)"
193.200.150.45 - - [10/Sep/2008:04:56:48 -0700] "GET /test/decloak.php?get_html_utf16 HTTP/1.0" 200 1516 "-" "http://Anonymouse.org/ (Unix)"
62.100.100.100 - - [10/Sep/2008:04:56:51 -0700] "OPTIONS rtsp://mysite.com:80 RTSP/1.0" 301 296 "-" "RealMedia Player HelixDNAClient/10.0.1.65 (win32)"
62.100.100.100 - - [10/Sep/2008:04:56:52 -0700] "GET /test/decloak.php?ip=193.200.150.45&user_agent=http://Anonymouse.org/%20(Unix) HTTP/1.1" 200 176 "-" "RMA/1.0 (compatible; RealMedia)"

193.200.150.45 is anonymouse.org (the cgi-proxy)
62.100.100.100 is my real IP (supposedly :p )

Notice the two connections from real player plugin? first it assumes the server is a streaming server and supports RTSP/1.0. Then when it doesn't get back what it expected, it tries the GET request with HTTP/1.1 :-)

Then in our decloak.log file we get this useful info:
Masked IP: 193.200.150.45
Real IP: 62.100.100.100
Browser: http://Anonymouse.org/ (Unix)
Player: RMA/1.0 (compatible; RealMedia)
Which is exactly what I wanted to accomplish, BUT...

even though the embedded object is not visible to the end user, an error generated by real-player plugin pops up saying "A General Error has occured", with our rtsp:// link shown in the text box, which is definitely not desireable...

I don't know how to get around that yet, tried sending different headers like Location (to force a redirect back to a dummy.rm file on http) or header('HTTP/1.1 503 Service Unavailable'), etc.. in an attempt to find a way to supress real player plugin's popup error message, but I failed...

If anyone has any idea, please let me know... This could be a useful addon to this MOD if no error is shown to the end-user... :mrgreen:
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

jasmineaura wrote:even though the embedded object is not visible to the end user, an error generated by real-player plugin pops up saying "A General Error has occured", with our rtsp:// link shown in the text box, which is definitely not desireable...
Success!! I was stupidly adding the header("Location: http://host/link/to/sample.rm") in the wrong place in the code...

A slight modifcation to the PoC code above did the trick:

Code: Select all

if ( isset($_GET['ip']) )
{
	if ($_GET['ip'] != $_SERVER['REMOTE_ADDR'])
	{
		// we managed to break out of the proxy, so get the data we need
		$orig_ip = addslashes($_GET['ip']);
		$real_ip = addslashes($_SERVER['REMOTE_ADDR']);
		$browser = isset($_GET['user_agent']) ? addslashes($_GET['user_agent']) : '';
		$player = isset($_SERVER['HTTP_USER_AGENT']) ? addslashes($_SERVER['HTTP_USER_AGENT']) : '';

		$data_str = "Masked IP: $orig_ip\nReal IP: $real_ip\nBrowser: $browser\nPlayer: $player\n\n";

		// log it to file
		$fh = fopen($log_file, "a") or die("Can't open file: $log_file");
		fwrite($fh, $data_str) or die("Can't write to file: $log_file");
		fclose($fh);
	}
	
	// Redirect back to http -  to a single-frame rm (real video) file in the current directory.
	// This is to avoid plugin popping up an error that it couldn't play :-)
	$host  = $_SERVER['HTTP_HOST'] . ":" . $_SERVER['SERVER_PORT'];
	$uri   = rtrim(dirname($_SERVER['PHP_SELF']), '/\\');
	$video = "sample.rm";
	header("Location: http://$host$uri/$video");
	exit;
}
I created sample.rm from qtlogo.mov (click here to download it if you wish) which is a tiny single-frame quicktime movie that only contains the quicktime logo.
I converted the qtlogo.mov file to sample.rm (realvideo format) using "Real Producer Basic" (the Free version) - after choosing no audio, and video only in the target audience settings - and the size of the converted file is 7.76KB (the smallest I could make)
Then I uploaded sample.rm to the same directory as decloak.php

Result:

1. User visits http://my-host.com/decloak.php

2. the hidden embedded object loads the rtsp:// link in real player plugin
the link looks like this:
rtsp:// myhost.com:80 /test/decloak.php?ip=orig.visitor.ip.addy&user_agent=orig-browser-version
the real player plugin doesn't get back a valid RTSP response, so it tries a HTTP GET request instead (bypassing browser's HTTP Proxy setting)

3. decloak.php then compares ip (the original ip the user visited the page from) with $_SERVER['REMOTE_ADDR'] (the ip address where the real player plugin made the request from), and if they don't match -> log it..

4. A redirect is done using header("Location: http://$host$uri/$video") to a http URL which looks like this:
http://myhost.com:80/test/sample.rm

5. the plugin plays the single frame rm file and stops, so no error is generated. :D

Of course this is all practically invisible to the end-user as the object/embed is hidden (size 1x1 pixels), and loaded from a iframe with size 1x1 pixles. :mrgreen:

If I eventually decide to include this technique in the mod, it should be done via javascript only, so that we load it only if realplayer plugin is detected (via javascript on Firefox/Opera/Safari/Mac-IE, or VBScript in IE5+) as to avoid a popup in clients' browsers saying they need to install the plugin to see some content they wont even see ;)

Anyways, the technique I described above (using media plugins to reveal a client's real IP address) is nothing new. For example, I know it has been previously mentioned (briefly) in the following article:
Breaking TOR Anonymity (by Martin Suess)

Comments/suggestions welcome :mrgreen:
Last edited by jasmineaura on Thu Sep 11, 2008 11:01 am, edited 2 times in total.
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

UPDATE: the RTSP trick wouldn't work with QuickTime, due to a slightly different behavior than real player :(

I tried with latest version of Quicktime Player - v7.5.5.
If I load the object/embed with qtsrc="rtsp:// server:80/test/qtlogo.mov" (port explicitly specified), quicktime will only try RTSP and therefore won't issue an HTTP GET request.
If I load the object/embed without the port specified in the RTSP link (i.e. rtsp:// server/test/qtlogo.mov), quicktime will first try to connect to "server" on port 554 (default RTSP server port), and when it fails, it will connect to port 80 as an HTTP server and issue a normal HTTP GET request, using browser's HTTP Proxy setting if set!
Defeats the purpose.. :(

UPDATE-2: Same behavior with Windows Media Player 9 as that described above with Quicktime. :(

Therefore, the only way we could exploit rtsp:// with Quicktime or mms:// with Windows Media Player to circumvent browser's http proxy setting is to actually run a seperate daemon script on a custom high port - over 1024 (to be able to run it as normal user) to imitate an RTSP Server and to log the requests. Too cumbersome imho :cry:

So it seems RealPlayer is the only one that can be tricked with the initial use of RTSP link to circumvent browser's HTTP Proxy setting when it falls back to HTTP, even though Real player (v11.0.3a tested) also has the option "HTTP - Use system Internet Connection proxy settings" enabled by default... ;)
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

(removed what was here as everything mentioned has been already implemented. see updated screenshots in first post)
User avatar
jasmineaura
Registered User
Posts: 275
Joined: Mon Jun 30, 2008 2:18 pm
Location: Cairo, Egypt
Name: Jasmine

Re: [ALPHA] Proxy Revealer Olympus

Post by jasmineaura »

Slight addition to overall_header.html

Purpose:
Grey out the screen and show a cool animated message saying "Page Loading... Please wait" to prevent end-users from clicking on any page links while the inital page is loading when a session is first created. This is to avoid them moving to another page before our hidden iframes are fully loaded and the tests are finished (few seconds). This only happens once at first page visit when a session is first created. If a session already exists (or a session cookie saved) neither the tests are ran nor the page loading/wait message is shown.

Details:
IF S_SPECULATIVE_TEST is set (by our checks in page_header() function in functions.php), we add a pageloader.css stylesheet file (797 bytes) in the head section, then right after the body tag before we add the iframes for our tests, we put a couple div's; "loading-mask" and "loading".
The first is a CSS layer that covers the entire page with 70% opacity of black (the CSS code includes appropriate parameters for Firefox, IE, Safari and Opera), and the second div includes an animated gif (3.1kb) and a short message saying "Page Loading... Please wait" (text defined at end of language/en/common.php after the IP_MASK message)
Then after the two div's we include a pageloader.js javascript file (1.7kb) that first makes the CSS mask/overlay and the loading div appear, temporarily sets the body and the html tag's "overflow" property to "hidden" to temporarily disable the scroll bar so the masking Overlay doesn't cut off when user starts off with a really small window then scrolls down to the bottom of the page or resizes the screen larger. Then on window onload event (page done loading), the script removes the overflow="hidden" property from html/body tags so the scroll bar appears again - if needed - (and to avoid causing conflicts) and makes the masking Overlay and the loading message disappear with a cool fade-out effect after the page finishes loading. :mrgreen:
This loading/wait message only appears once when a new session is created, of course.

Screenshots:

Page loading (IE7) - you can see the "hidden" iframe's URL loading /probe.php?mode=xss in the status bar at the bottom of the browser. This flickers quickly so most people won't even notice it. :D
Also notice that not all the images are loaded yet, hence the missing rounded corners of the prosilver style.
Image

Page loading (Firefox 3) and fade-out effect just after page finished loading: (Notice how the scroll bar instantly reappears) :)
Image

Update:
Changes committed to SVN.
Also committed changes to the install.txt file for the install instructions of the ACP module(s).

Perhaps soon I may feel like converting the install.txt to MODX format then bundle a beta release and put a direct download link in the first post.
Keep posted :)
Locked

Return to “[3.0.x] Abandoned MODs”