Internal IP Exposed

Mon Mar 25 00:46:56 UTC 2019

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>
> 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
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190324/9f05e314/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190324/9f05e314/attachment.bin>