Internal IP Exposed

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Internal IP Exposed

Abdul Qoyyuum
Hi all,

New to the mailing list and a complete newbie to openssl and the likes. There's a ticket by a client that I'm new at and he claims that there's a security problem with the openssl command to his servers.

Internal IP exposed after running a openssl (version 1.1.0j) connect command:

openssl s_client -connect 103.XX.XXX.XX:10443 -quiet

Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, typed the following:

GET /images HTTP/1.0

And hit enter twice, the following gets displayed:

HTTP/1.0 301 Moved Permanently
Date: Mon, 25 Mar 2019 00:10:13 GMT
Server: xxxxxxxx-xxxxx
Location: https://10.240.123.1:10443/images/
Connection: close
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=28800

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF="https://10.240.123.1:10443/images/">here</A>.<P>
</BODY></HTML>
read:errno=0

The 10.240.123.1 is an internal IP and it is exposed by this little method. Although not shown when using curl -kv -O command.

Is there a way to cover up the "Location" or at least the internal IP from being exposed? Thanks.

Sorry if this isn't clear or if this is the wrong place to ask this.

--
Abdul Qoyyuum Bin Haji Abdul Kadir
HP No: +673 720 8043
Reply | Threaded
Open this post in threaded view
|

Re: Internal IP Exposed

Karl Denninger


On 3/24/2019 19:33, Abdul Qoyyuum wrote:
Hi all,

New to the mailing list and a complete newbie to openssl and the likes. There's a ticket by a client that I'm new at and he claims that there's a security problem with the openssl command to his servers.

Internal IP exposed after running a openssl (version 1.1.0j) connect command:

openssl s_client -connect 103.XX.XXX.XX:10443 -quiet

Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, typed the following:

GET /images HTTP/1.0

And hit enter twice, the following gets displayed:

HTTP/1.0 301 Moved Permanently
Date: Mon, 25 Mar 2019 00:10:13 GMT
Server: xxxxxxxx-xxxxx
Location: https://10.240.123.1:10443/images/
Connection: close
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=28800

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF="https://10.240.123.1:10443/images/">here</A>.<P>
</BODY></HTML>
<a class="moz-txt-link-freetext" href="read:errno=0">read:errno=0

The 10.240.123.1 is an internal IP and it is exposed by this little method. Although not shown when using curl -kv -O command.

Is there a way to cover up the "Location" or at least the internal IP from being exposed? Thanks.

Sorry if this isn't clear or if this is the wrong place to ask this.

OpenSSL is not involved in that in any way so the fix and issue is not there.

I am assuming that the original connection is to a "tunnel" on the internal/external gateway.  That is, connect to <a.b.c.d:10443> and the gateway "twists" that to the internal address on port 443, which is the usual HTTPS port (this assumption is due to that looking like an HTTPS server from what it returns.)  This is a very common firewall/gateway function.

The issue is that OpenSSL just created and maintained the SSL connection and data transport.  The offending information isn't emitted by OpenSSL; it's emitted by the remote server code itself and OpenSSL simply transports it from one end to the other, encrypted.  It thus must (and does) transport exactly, byte-by-byte, whatever it gets (in both directions.)

The server code on the remote end could be programmed to not issue the header and body text, but if it generates a 301 the HTML header "Location:" MUST be returned with the new location by the HTML specifications so the application that connected (typically a browser) can issue a new request to the correct, redirected place.  However it doesn't have to return an IP number and most servers do not because there frequently is more than one host and/or domain on a given IP number -- it could and should instead return a domain name (e.g. "https://www.example.com/images") -- but that header has to be there.  The body text actually does not; it can be void and it's ok (that's not used by browsers, but is useful for humans if/when troubleshooting.)

The issue is LIKELY that the host in question doesn't have a reverse IP mapped for itself but that's web server and OS dependent.  It may also be that the hostname is not defined in the server's configuration file.  Without knowing what the web server in question is all I can do there is guess as to exactly what is missing, but in any event the issue is in the web server application configuration and not OpenSSL.

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Internal IP Exposed

Jochen Bern
In reply to this post by Abdul Qoyyuum
On 03/25/2019 01:08 PM, [hidden email] digested:
> Date: Mon, 25 Mar 2019 11:33:55 +1100
> From: Abdul Qoyyuum <[hidden email]>
>
> GET /images HTTP/1.0

Note that this is a HTTP 1.*0* request that doesn't require the client
to send a Host: header stating what *his* idea of "which server am I
trying to talk to?" is.

> HTTP/1.0 301 Moved Permanently
> Location: https://10.240.123.1:10443/images/

/images is a directory, which means that the client is supposed to ask
for "/images/" (with a trailing slash) to request a directory listing.

The server is helpfully sending back a HTTP Redirect to tell the client
what he *should* request instead, in the form of a complete URL, which
necessitates a host and port part. Having no idea who and what the
*client* expects to talk to, the server fills in what *it* knows - its
local (internal) IP and port. This "attack" already worked that way
almost 20 years ago, when I demonstrated it to some (horrified) bank IT
people on their Netscape-based online banking solution middleware ...

OpenSSL is not involved here, and whether (and what) you can do to close
the gap depends on what HTTP server (and, if present, reverse proxy
solution) you're using.

Regards,
--
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Internal IP Exposed

Kyle Hamilton
In reply to this post by Abdul Qoyyuum
That's a configuration issue with the servers, not an issue with the
openssl command itself.

There's no information on what the back-end HTTP server software is
being used.  If it were Apache, there would be a ServerName directive
that could change the server's idea of what name it should refer to
itself as.  I don't have information on other server software
configuration.

-Kyle H

On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
<[hidden email]> wrote:

>
> Hi all,
>
> New to the mailing list and a complete newbie to openssl and the likes. There's a ticket by a client that I'm new at and he claims that there's a security problem with the openssl command to his servers.
>
> Internal IP exposed after running a openssl (version 1.1.0j) connect command:
>
> openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
>
> Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, typed the following:
>
> GET /images HTTP/1.0
>
> And hit enter twice, the following gets displayed:
>
> HTTP/1.0 301 Moved Permanently
> Date: Mon, 25 Mar 2019 00:10:13 GMT
> Server: xxxxxxxx-xxxxx
> Location: https://10.240.123.1:10443/images/
> Connection: close
> Content-Type: text/html; charset=utf-8
> X-Frame-Options: SAMEORIGIN
> Content-Security-Policy: frame-ancestors 'self'
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Strict-Transport-Security: max-age=28800
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML><HEAD>
> <TITLE>301 Moved Permanently</TITLE>
> </HEAD><BODY>
> <H1>Moved Permanently</H1>
> The document has moved <A HREF="https://10.240.123.1:10443/images/">here</A>.<P>
> </BODY></HTML>
> read:errno=0
>
> The 10.240.123.1 is an internal IP and it is exposed by this little method. Although not shown when using curl -kv -O command.
>
> Is there a way to cover up the "Location" or at least the internal IP from being exposed? Thanks.
>
> Sorry if this isn't clear or if this is the wrong place to ask this.
>
> --
> Abdul Qoyyuum Bin Haji Abdul Kadir
> HP No: +673 720 8043