[ABD] Proxy Revealer Olympus 0.3.3

[jasmineaura]

Thank you A_Jelly_Doughnut

I'm back, and I apologize to all who were having difficulties with the MOD for not being around for a few months to look into - or answer - your questions.

Hopefully will continue working on this MOD quite soon and hope to resolve the issues that some users have been having.

[jasmineaura]

I've deleted the install folder what you tell me, and upload of new archives "Functions.php and Sessions.php" , and appears this message, when i try to log-on

phpBB Debug] PHP Notice: in file /includes/functions.php on line 3727: Undefined index: session_speculative_key

And i can't log-on.

Line 3727 is:

$speculative_key = $user->data['session_speculative_key'];

Thanks for the Help and Greetings!

@ haweki

Sorry if this is a little late, but if you're still trying to give this a try on 3.0.2:


in includes/functions.php

change:

Code: Select all

$speculative_key = $user->data['session_speculative_key']; 

to:

Code: Select all

$speculative_key = isset($user->data['session_speculative_key']) ? $user->data['session_speculative_key'] : "";
 

[Stamen]

I'd like to suggest making some connection between the found IPs and user accounts. If a user logs in or registers while behind a proxy, save that user name in the log. That way, admins could find out what IP made spam posts or fake registrations, without blocking valid users using a proxy.
To clarify: I am aware that there are some user specific features, but as far as I can tell from the screenshots, you are not yet logging which user name belongs to what IP.

[jasmineaura]

I'd like to suggest making some connection between the found IPs and user accounts. If a user logs in or registers while behind a proxy, save that user name in the log. That way, admins could find out what IP made spam posts or fake registrations, without blocking valid users using a proxy.
To clarify: I am aware that there are some user specific features, but as far as I can tell from the screenshots, you are not yet logging which user name belongs to what IP.

Unfortunately, that logic conflicts with the current implementation, for some fundamental reasons.
The proxy detection, the logging and/or blocking, all happens as soon as a session is created (in header). That means that this happens as soon as someone visits any page of the forum, before they even click register or login button..
And because of how sessions work, all session information (including the blocked messages - if you enable blocking with any particular method(s)) do not appear until next page load. Like how when you normally login with your username and password, your session login information is not displayed until the second page load..
With the original phpBB2 MOD, the detection, the logging and/or blocking, all occurred before the user even had a chance to register or login. With this port to phpBB3, I added features so that blocking methods, when enabled, can optionally be "deferred" until after login, to see if a particular user is exempt from the particular proxy-blocking methods. But that only applies to pre-registered users, for obvious reasons.. You cannot determine the authenticity of the remote user except by their username or their IP address or IP range. And that's why you have, in this version, ability to exclude IP's, and ability to defer blocking methods and exclude usernames..
And as the exclusion of usernames is (obviously) done by the admin only for "trusted" users, there was no point in logging the IP's of those "trusted" (excluded) usernames..
Moreover, if you needed to know the Real IP's associated with some "trusted" user that you excluded from the proxy-blocking, you can simply click the "?" question mark on the "trusted" user's post, native phpBB3 functionality gives you the poster IP, then you copy that IP, and in Proxy revlear just search by that IP, and find the corresponding Real IP...

Hope the above explanation is clear and answers your questions..

[Stamen]

Unfortunately, that logic conflicts with the current implementation, for some fundamental reasons. [...]

Thanks anyway! So sadly I can't use your mod, because in my case, the forum itself is behind a SSL proxy and every user gets the same IP.

[Gyiyg]

Suggestion for the future: QuickTime is much more widespread these days thanks to iTunes, while RealNetworks has faded into obscurity. QuickTime supports RTSP as well; could it act as a substitute for RealPlayer in probe.php?

Here's some QuickTime detection JS, may be useful: http://blog.deconcept.com/2005/01/26/we ... and-embed/

I'll look into implementing it in the meantime. I'm also porting your script to standalone PHP, not dependent on PHPBB. I will probably be integrating it into this project. probe.php is phenomenal!

If found, we load it using javascript to avoid browsers that don't have the plugin intalled so they don't get prompted to install it :)
We use the UTF-16 encoding method so that CGI-Proxies can't load the object/embed and cause realplayer plugin errors, and also so they can't see the rtsp:// URL and try to rewrite it and make Firefox trip out :p

And possibly evil ;)

[jasmineaura]

Suggestion for the future: QuickTime is much more widespread these days thanks to iTunes, while RealNetworks has faded into obscurity. QuickTime supports RTSP as well; could it act as a substitute for RealPlayer in probe.php?

Sadly, no... Soon as I discovered the real player downfall, I quickly tested latest quicktime and mediaplayer versions at the time, and both simply defeated the purpose, for technical reasons...
For more details, see my post (from first page of this thread):
http://www.phpbb.com/community/viewtopi ... 5#p6991365

Here's some QuickTime detection JS, may be useful: http://blog.deconcept.com/2005/01/26/we ... and-embed/

Right, actually there's code on developer.apple.com iirc for standardized cross-browser detection methods of multiple plugins, and of course including quicktime. That came quite handy when doing the real plugin detection javascript in this MOD.

Perhaps in the future it maybe worth a shot to test if other popular browser plugins can be tricked, say, Adobe Acrobat Reader for instance

I'll look into implementing it in the meantime. I'm also porting your script to standalone PHP, not dependent on PHPBB. I will probably be integrating it into this project. probe.php is phenomenal!

Sure, why not

If found, we load it using javascript to avoid browsers that don't have the plugin intalled so they don't get prompted to install it
We use the UTF-16 encoding method so that CGI-Proxies can't load the object/embed and cause realplayer plugin errors, and also so they can't see the rtsp:// URL and try to rewrite it and make Firefox trip out :p

And possibly evil

Actually, TerraFrost has recently brought to my attention an issue discovered by HarshReality with some quirky web-proxies out there, which basically kind of screwed things up sometimes as to the UTF-16 method for firefox... That will have to be fixed in the next release..

Here's TerraFrost's original message on improving the utf16 XSS detection method

HarshReality has been trying to adapt Proxy Revealer for an SMF MOD and found an issue with the XSS detection method. Specifically:

http://www.frostjedi.com/terra/scripts/ ... mode=utf16

...when viewed with this:

http://www.creditcardproxies.com/index.php

Anyway, after using Wireshark to capture the packets being sent to and fro...

[..snip..]

That'll duplicate the error. Remove the first character, however, and it'll work just fine.

The problem is that UTF-16 is a multibyte encoding. Two bytes represent one character. The problem is that the CGI proxy is not aware of this - it's adding an ISO-8859-1 string to the top of a UTF-16 encoded page and is then passing the original Content-Type (specifying UTF-16 as the encoding) to the browser.

Of course, not just any ISO-8859-1 string will do this - only strings with an odd number of characters will do it. When the browsers grouping all the characters into groups of two, there'll be one group with a character from the original IP Unmasker page and another from the inserted string. All subsequent groupings will be off by one. So instead of the browser seeing "\0<\0h" as two characters - "\0<" and "\0h", the browser will see "<\0". "\0" will be combined with the previous character and "h" will be combined with the next character.

Per all that, mode=utf16 will never work with that proxy. A newly added utf16-2, however, will work:

http://www.frostjedi.com/terra/scripts/ ... de=utf16-2

You'll see the IP address info towards the bottom of the page.

[..snip..]

Edit: Removed source linked by TerraFrost, as I couldn't find it elsewhere, and its possibly 0day

[Gyiyg]

Sadly, no... Soon as I discovered the real player downfall, I quickly tested latest quicktime and mediaplayer versions at the time, and both simply defeated the purpose, for technical reasons...
For more details, see my post (from first page of this thread):
http://www.phpbb.com/community/viewtopi ... 5#p6991365

Ah, should have known. However, for those running a real RTSP server, this wouldn't be an issue, yeah? Or, as you say, an imitation RTSP server. This might be something for me to consider since LAMPS is much more concerned with comprehensiveness than whether a solution is cumbersome.

[jasmineaura]

Ah, should have known. However, for those running a real RTSP server, this wouldn't be an issue, yeah? Or, as you say, an imitation RTSP server. This might be something for me to consider since LAMPS is much more concerned with comprehensiveness than whether a solution is cumbersome.

Right, however, it depends..

As far as I remember, it mainly depends on the type of proxy configured in the browser... If it's an HTTP-only proxy, then most likely the quicktime rtsp protocol will not work through it, and will fall back to direct connection, unless it has an "rtsp proxy" configured in it (in itunes/quicktime player).. If the proxy configured in the browser is a "SOCKS proxy" or a so-called "Connect-proxy" (aka HTTPS Proxy), then the player might be able to make its rtsp connection/stream through it.

Another useful feature for user-tracking, if you do have an rtsp server, or an imitation, is logging the client's GUID (Genuine User ID)

[Gyiyg]

Another useful feature for user-tracking, if you do have an rtsp server, or an imitation, is logging the client's GUID (Genuine User ID)

Good idea! One of the key concepts behind LAMPS is to have a persistent user database. The current planned method of implementing this is through cookies and some intelligent IP tracking, aside from the obvious login mechanism (but LAMPS is much more general, it's not just for sites with registration systems). It's not as important to have a true IP address, so much as to have a way of identifying a user as themselves on the server, although true IP is ideal.

Unfortunately I'm not really very familiar with RTSP at all. I'll have to investigate further.

Edit: I should note that LAMPS will support a site-wide registration system that I plan to make pluggable with popular services like WordPress, MediaWiki, and, most relevantly, phpBB. So it's probably good that I'm here. One of the goals of the project is to be able to have a single login across a site, regardless of what software packages are used.

[jasmineaura]

Edit: I should note that LAMPS will support a site-wide registration system that I plan to make pluggable with popular services like WordPress, MediaWiki, and, most relevantly, phpBB. So it's probably good that I'm here. One of the goals of the project is to be able to have a single login across a site, regardless of what software packages are used.

You might want to take a look at WP-United (phpBB + Wordpress) as well:
http://www.wp-united.com/

[jasmineaura]

Thanks to suitlocal for turning my attention to "itms Decloaking" (iTunes decloak method)

As I haven't visited http://decloak.net in a while, I thought of checking it to see what I've been missing lately, and it seems there are a couple more trivial decloak methods that have been added which can be quite useful to implement in this MOD:

So-called Microsoft "word" decloak method

6. When Microsoft Office is installed and configured to automatically open documents, a file can be returned which automatically downloads an image from the internet. This can bypass proxy settings and expose the real DNS servers of the user.

I wonder if it exposes the actual real/external IP, not just the "real DNS servers" of the user as mentioned... hmm

And the Quicktime decloak method

7. When the Quicktime plugin is installed, it can be loaded with a parameter which explicitly tells it to use a direct connection for the movie and to ignore the browser's settings.

this post on metasploit blog quickly reveals:

Thanks to Paul Craig for the Quicktime method implemented in iKAT

the component in question is loaded from http://ikat.ha.cked.net/Windows/quicktime.html

Code: Select all

<EMBED SRC="files/dummy.mov" WIDTH="200" HEIGHT="240"
  href="http://www.google.com/" 
  qtsrcdontusebrowser=true
  enablehref="false"
  autohref="true" 
  controller="true"
  kioskmode="false">

The parameter qtsrcdontusebrowser is tells the browser to load the movie from "qtsrc" parameter directly from quicktime (and not the one downloaded by browser from "src" parameter, hence the dummy.mov)

So we have yet two (or maybe three) more "proxy-revealing" methods to enrich this MOD with

But first, I need to find the time to fix a long-standing elusive general bug that everyone has been having after installing this MOD (the "unable to login to forum nor ACP" after installation issue).. Hopefully soon.
While I'm at it, I might as well get rid of the automated installer and put the manual installation steps back in the MODX file (such as the SQL operations, and mod installation in ACP), since "Automod" has made a lot progress, thanks to phpbb developers, and we might actually see a stable release soon

Update: revised

[4Teach]

This is what i was looking for a long time, i 'll just say you did a awesome work. but before using this i have some questions in my mind.
#1. 'll it slow down the board speed or is speed effected by this?
#2. is it compatible with v3.0.4,5 and up coming v3.0.6?
#3. can i avoid using Flash player? (not all people and browser have installed it by default)
#4. any false positive problems with this?
...and
#5. any future release plans for this to make it more better?

[jasmineaura]

This is what i was looking for a long time, i 'll just say you did a awesome work. but before using this i have some questions in my mind.

Sure, I'm a little tired now, and my memory is not at its best state, and I have a little headache, but will try to answer your questions generally and as best I can for the moment.

#1. 'll it slow down the board speed or is speed effected by this?

This MOD kicks in only once, on a per-user basis, only when their session is first created, and typically takes a few (3-6) seconds to load on a 256kbps connection. i.e. when they first open the forum, or after a revisit when their previous session timed-out (depends on session length you set in ACP). The time it actually actually takes to load varies for each user because it depends on a few factors, such as their bandwidth, the server bandwidth and server load, and ultimately whether the user visited the forum previously or not (because that determines whether the forum style is cached in the user's browser), and how many supported browser plugins they have installed and enabled when they visit the forum that has this MOD..

#2. is it compatible with v3.0.4,5 and up coming v3.0.6?

The last version has been released a while back, when 3.0.2 was the latest. Having said that, it seems quite a few people have been experiencing some very odd situation where they are unable to login to the forum after installing this MOD. Seems like an elusive bug, and not everyone has experienced it (I certainly haven't). I plan on making a fresh test install of phpBB3.0.5 and updating for that, pretty soon, so keep a close eye..

#3. can i avoid using Flash player? (not all people and browser have installed it by default)

You don't have to avoid anything, because the MOD uses automatic plugin detection, and if it cannot initiate plugin detection routines (javascript), such as if you don't require javascript in the MOD settings and the user does have javascript disabled, the browser/plugin-dependant tests are skipped.
If you do require javascript via settings, the user is forced to enable javascript, and the MOD is able to automagically detect whether or not flash is installed in the end user's browser, via swfobject library, and conveniently gives a nice popup prompting the user to install flash player for "optimal experience", which they can simply ignore if they want for more info on that, see screenshots in first post of this thread.

#4. any false positive problems with this?

The components of this MOD that can generate false positives are not enabled as a blocking method by default, for realiability reasons. They still are triggered and do log info (which you can view in the ACP), but do not block by default.. An example of that would be the X_FORWARDED_HOST check, and the tracking cookie check. Also see screenshots in first post of this thread.

Other checks such as java and flash and realplayer plugin techniques, and the TORDNSEL check, simply cannot generate false positives, because they will never trigger unless the user's is going through some sort of proxy.. However, our definitions of false-positives can differ significantly... For instance, if you consider a scenario where a end-user's ISP transparently forwards the user's web traffic through a filtering/caching proxy without the end-users knowledge (by content interception and redirection, such as in many countries where internet is censored), then you might consider that a false-positive, but the MOD certainly has no way of determining that.
In which case, the MOD has alternative configuration options to account for such fallbacks, which is "deferring" detection methods. This allows the tests to only be run when the user either: 1. click register, or 2. logs in... This allows you to disallow registrations from proxied users, while allowing legitimate users who are forced to access your site through a proxy to login with their existing "trusted" account.

...and
#5. any future release plans for this to make it more better?

Definitely, ISA see my previous post on my plans to add quite a few more (reliable) methods of detection and blocking

Shukriya & Salaam

[4Teach]

As-Salāmu `Alaykum (السلام عليكم)

Sure, I'm a little tired now, and my memory is not at its best state, and I have a little headache, but will try to answer your questions generally and as best I can for the moment.

Thanks for the corporation.

The last version has been released a while back, when 3.0.2 was the latest. Having said that, it seems quite a few people have been experiencing some very odd situation where they are unable to login to the forum after installing this MOD. Seems like an elusive bug, and not everyone has experienced it (I certainly haven't). I plan on making a fresh test install of phpBB3.0.5 and updating for that, pretty soon, so keep a close eye..

even, admins and mods or only Registered users are effected by this bug?

You don't have to avoid anything, because the MOD uses automatic plugin detection, and if it cannot initiate plugin detection routines (javascript), such as if you don't require javascript in the MOD settings and the user does have javascript disabled, the browser/plugin-dependant tests are skipped.
If you do require javascript via settings, the user is forced to enable javascript, and the MOD is able to automatically detect whether or not flash is installed in the end user's browser, via swfobject library, and conveniently gives a nice popup prompting the user to install flash player for "optimal experience", which they can simply ignore if they want for more info on that, see screenshots in first post of this thread.

That's a very good feature.

Shukriya & Salaam

wa alaykum as-salām, Shukriya (Shukran, ألف شكرا و شكرا )