Thread Info
  • Locked Locked
  • Replies 6 replies
  • Subscribers 5 subscribers
  • Views 3155 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Security Vulnerability Found? Reality check please..

dougga

I think I stumbled upon a troubling security issue but wanted to get a reality check.

I'm flailing about trying to get Dynamic DNS working with NameCheap.

I have the system logs open and found the following:

 

2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: REPLIED: HTTP/1.1 200 OK
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Cache-Control: private
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Content-Length: 423
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Content-Type: text/html
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Server: Microsoft-IIS/8.5
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Set-Cookie: ASPSESSIONIDQEBAAAQS=IBMLKFFAKGJCFHLICBJOCJPH; secure; path=/
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: X-Powered-By: ASP.NET
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Date: Mon, 27 Mar 2017 22:40:44 GMT
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: Connection: close
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING:
2017:03:27-15:40:45 ravenna ddclient[22632]: WARNING: <?xml version="1.0"?><interface-response><Command>SETDNSHOST</Command><Language>eng</Language><ErrCount>1</ErrCount><errors><Err1>Domain name not found</Err1></errors><ResponseCount>1</ResponseCount><responses><response><ResponseNumber>316153</ResponseNumber><ResponseString>Validation error; not found; domain name(s)</ResponseString></response></responses><Done>true</Done><debug><![CDATA[]]></debug></interface-response>
2017:03:27-15:40:45 ravenna ddclient[22632]: FAILED: updating wahine: Invalid reply.
 
The last line shows the functional  error, the first line shows the security problem.  One of the most important authentication credentials a company can have is the username and password to one's DNS provider.  In this line it appears to me that my NameCheap username and password are passed over the internet in open text unencrypted http call. 
 
I don't have a sniffer available on the external network, but can someone check this.
 
This seems like a real problem.
Someone sniffing traffic could easily access my DNS provider and shut down all internet communications with me.  I'm a home user so the impact is marginal, but for companies, not so much.
 
Thanks,
Doug


This thread was automatically locked due to age.
Parents

  • I can't imagine that the UTM would use HTTP for this exchange unless that's all that NameCheap supports.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    Agreed, yet it's Sophos' user interface that suggests that the administrator input the primary DNS registrar username and password.  Whatever is entered is broadcasted in open text form.  I can't think of anything like this since perhaps the 90's.

  • in reply to dougga

    I do not use Namecheap, but their API certainly shows https is used.  I would sniff the connection and see what it is doing rather than rely on the log entry.  It is possible the dev who wrote the module may have just gotten the log entry message wrong.  You can use tcpdump on the sophos itself then scp the file out to wireshark if it help visualize.  It is also possible the dev used http instead of https, of course.

  • in reply to dougga

    Hmmm, even if it's just an error in the comment logged, it's a bug.  If credentials are, in fact, sent in clear text, it's a big, bad ugly bug!  Please let us know what you find with tcpdump.  That FQDN resolves to 104.219.249.25, so you could do something like:

    tcpdump -n -i eth1 dst 104.219.249.25

    I think that will let you see the port used.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • in reply to dougga

    Hmmm, even if it's just an error in the comment logged, it's a bug.  If credentials are, in fact, sent in clear text, it's a big, bad ugly bug!  Please let us know what you find with tcpdump.  That FQDN resolves to 104.219.249.25, so you could do something like:

    tcpdump -n -i eth1 dst 104.219.249.25

    I think that will let you see the port used.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • in reply to BAlfson

    Ok, I set up a bogus entry in the UTM to test this out.  The good news is that it never tried to connect over port 80.  It appears the log entry is incorrectly identifying http instead of https.  This may be a bug in ddclient, though, not in the UTM itself.  I do not have ddclient set up anywhere other than the UTM, so I am not sure if that is the issue or not.  But rest assured, it appears the UTM IS using 443, not 80.

    Incidentally, your password does exist in the ddclient configuration file in plain text.  And it will also obviously show in plain text in the log.  I suspect file permissions save you here and at the end of the day, if someone is connected to your UTM console, you have bigger issues.

  • in reply to darrellr

    Great sleuthing, Doug!  Great sniffing, Darrell!

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML