Home of a code hacker, not a real hacker.

Finally figured out our curl issue

by

We have spent days working on an issue where when we curl’d our sites we were getting the error

SL read: error:00000000:lib(0):func(0):reason(0), errno 104

Cert was ok but Curl could not touch the site…

Found out it was due to a misconfiguration in NGINX.

For you that care and find this, to fix make sure when you define a server to use 443 and a cert that you define all of it’s config option.

For example we were missing

ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

That’s silly you should have that defined… We did in our default and we assumed that the site would inherit this.

A little know fact is that NGINX will allow inherit if you don’t redefine the cert so we took out the redefined cert (because it was the same as the default) and voila! the error was gone.

Hope this helps someone.

Whitt

A possible fix for CVE-2000-0649 in NGINX

by

We have been working on shoring up our servers for a specific client.  Their latest scan showed an issue with CVE-2000-0649 “Web Server Internal IP Address/Internal Network Name Disclosure Vulnerability”

We looked and looked and there is not documentation to fix the issue.

We could replicated it using https://www.exploit-db.com/exploits/20096/

telnet

After days of trying to figure it out we finally found a fix.

http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name_in_redirect

server_name_in_redirect on

Once it’s added to nginx.conf and nginx is reloaded this is what you will see

telnet_fixed

Wait what about my domain?  Shouldn’t it be that instead of localhost?

I think it’s because the vulnerability is from HTTP 1.0 which won’t contain the “Host” part of the header.

But I’m not 100% sure…

Maybe I’ll look into it more later but for now it fixes our issue and we can move on.

I hope this helps anyone looking to fix the problem and feel free to comment below if you have a better way or can see any issues with enabling this flag.

Whitt