![]() ![]() Advanced Packet Technology Remote Internet Security Analysis Suite ![]() | |
Page last modified: May 04, 2013 at 18:12 | Developed by Steve Gibson |
![]()
![]() A public disclosure of our remote client authentication technology by Steve Gibson
The Challenge of Accurately Determining the User's IP
You will discover that even if an insecure connection is attempted to the ShieldsUP! system entry-point (https://www.grc.com/x/ne.dll?bh0bkyd2) it will be quickly and silently "coerced" into a secure connection. This can not be bypassed or overridden. However, deliberately configured browser proxies, more aggressive corporate SSL filters, and NAT routers, all continued to present problems. Additionally, a few users were unable, for various local administrative reasons, to establish secure connections of any sort. To address these problems, a second fall back solution was created and strongly recommended . . .
Unfortunately, this "trusting solution" turned out to be too trusting. That trust was exploited by malicious hackers in several instances:
A Comprehensive and Secure Solution for the Future
![]() ![]() ![]() ![]() |
Introducing the RSVP Agent Responsible delivery of the next-generation ShieldsUP!! and NanoProbe services which will include password penetration, denial of service perpetration, and "energetic application" of other known exploits requires that we must be absolutely certain that these testing nanoprobes can not be maliciously retargeted at innocent bystanding machines.
As mentioned above, the second-generation (and still completely FREE) ShieldsUP!! service will have much sharper teeth than its predecessor. But those "teeth" will only be accessible when the service is invoked through the use of the second-generation IP_Agent employing the new R.S.V.P. technology:
![]() Don't let the level of detail in this diagram freak you
How it Works . . .
(Note: If you are not yet versed in the details of TCP packet protocol, my disclosure of the GENESIS technology contains a clear and careful explanation. You might wish to see that first.):
|
![]() ![]() Subverting the RSVP Agent ![]() Unlike the much simpler IP_Agent, for which security was never a significant concern, the RSVP Agent technology has been designed from the start to thwart malicious exploitation: ![]() ![]() ![]() ![]() ![]() ![]()
RSVP and the "Man in the Middle"
![]() ![]() To exploit the "man in the middle" (MITM) position, and cause the NanoProbe server to test the security of an unsuspecting client, a fake RSVP Agent would be somehow inserted into the network flow so that ALL network traffic flowing to and from the client could be examined and perhaps modified by the MITM. As simple as the diagram above appears, achieving a man in the middle position cannot be accomplished by the random malicious hacker. It requires Internet Service Provider (ISP) style access to the client's Internet connection. Due to the heterogeneous structure and router-traffic-based routing of data across the Internet, packets are routed in a dynamic and non-pre-determined fashion as they move from one endpoint to another. Therefore, the MITM would need to be virtually adjacent to the client to be tested. Note that Gibson Research Corporation (grc.com) connects directly to a tier-one provider, Verio. We are "zero routers away" from the Internet backbone to absolutely minimize the opportunity for an unauthorized MITM at our end. But the point of this analysis is to play the devil's advocate, so let's see what else a Fake RSVP Agent would need to do if ISP-level interception could be achieved: In order for testing NanoProbes to be directed at the client machine, the Fake RSVP Agent would need to initiate an RSVP connection to the NanoProbe server using the client's IP address. Since this is tantamount to "spoofing the GENESIS stack", and since the GENESIS stack can not be spoofed, the MITM must be able to receive and intercept all packets bound for the client (whether or not they are carrying data) and selectively intercept only those which are used for managing the RSVP Agent session. This is further complicated by the fact that the NanoProbe server utilizes a new technology called "differential IP analysis" which originates testing packets from multiple IP addresses to analyze the client's responses to IP addresses with which it has no existing relationship. In other words, the Fake RSVP Agent would need to simulate the client's awareness of a connection to the NanoProbe server (for example, creating a port mapping through a NAT router), which would not actually exist since the client would have no such relationship. Firewalls that dynamically stealth the "ident" (port 113) based upon whether the probing server is currently known to the client render such simulations extremely complex. To pull this off, the Fake RSVP agent would need to understand the RSVP protocol in detail, examine every packet flowing to and from the unsuspecting client, then intercept and respond only to those which are about maintaining and authenticating the RSVP connection. And all the while the Fake RSVP Agent would need to accurately simulate any client responses which might differ as a result of the client knowing nothing about the NanoProbe server.
In Summary . . .
Thanks for your time and attention to this! |
|
![]() | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2022 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |
Last Edit: May 04, 2013 at 18:12 (3,791.85 days ago) | Viewed 5 times per day |