Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 15 replies
  • Subscribers 9 subscribers
  • Views 25329 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

Passwords in Debug Logfiles - necessary or no go for a firewall device.

BeEf

Hello Everybody,

recently we had a difficult to track and not reproducable problem and rarely occuring problem with our OpenVPN dial in connections (still open after several weeks). The sophos support switched on the DebugLogging without mentioning to us that this will log passwords for the user and admin webinterface, vpn dial in an, connections to backend systems (Active Directory LDAP).

After waiting some weeks to get the issue resolved I looked into this myself and noticed that that all passwords are exposed in the logfiles. This was not only all AD SSO user passwords but also high level administrative passwords that were granted permissions via Active Directory group membership to administrate the firewall devices. Although the administrations interface was strictly limited by ip (nobody can log in with this credential from a normal internet address) the security breach here is the exposed administrative password in the logfiles.

Operating Systems like Windows and Unix take big care not to expose their passwords in clear text and this can not be easily cracked - even by their administrators. Putting passwords in clear text in a logfile in a procedure that can easily be switched on by every administrator of the device is a MAJOR SECURITY ISSUE in my opinion. Think of a criminal administrator in a big company who switches this on an inpersonate the users and other administrators to do some illegal stuff in their names.

This should be switched off permanently ASAP in all production devices or at least all passwords need to be masqueraded.

How do you think about this?



This thread was automatically locked due to age.
Parents
  • 0

    After having 2 or 3 problems from allowing unattended access, I have tsken a policy position that the support tunnel will never be enabled.  Allowing its use always seemed like a difficult-to-justify security risk.  We use a logmein session instead.  I provide ssh and webadmin access without ever releasing the UTM passwords.

    In one case, they ran a report that started devouring my disk space, setting off alarms.   Since I did not have them on tbe phone, I could not tell them that they wrre causing a problem.  An innocent mistake, but an unneccessay risk during peak network usage.   In another case, they reset the ssh password without letting me know.

    If you are in monitoring the debug sessuon, you are better positioned to know what needs to be turned back off and to control how sensitive data is used.

  • 0 in reply to DouglasFoster

    I am really dissatified with the sophos support. The reaction time is very bad - took 5 weeks to escalate the ticket to development and our problem is still not solved.

    The problem we had is only happening from time to time and was not reproduceable. As it seems not possible to get somebody on the phone immeadetely when the issue occours (we need to resolve the issue on the user side quickly by reinitialising the OTP as he/she can not login) the only way is to try to resolve this by analysing logfiles.

    I have a lot of other things to do and don't want to watch them with a teamviewer (or logmein) session all the time. The major issue with passwords was not that I had to give them to sophos (the standard is to grant access for several well known (Sophos Support) IPs and they have installed certificates that can be used with ssh sessions from their addresses). The main issue is the passwords that are printed in the logfiles when in debug mode. This could also be used by administrators in regular operation scenarios to get hold of the passwords of their users on backend systems - e.g. the Active Directory password (nobody want's to create and manage hundreds of local accounts on the sophos).

    The quality of the product has decreased significantly during the last year. I guess this is because they need to split all their ressources betweeen UTM and XG. XG seems to be even worse. It talked to several administrators and consultants and everybody advised me not to use XG instead of UTM.

    On the UTM side there seems to be a fiasco with the 9.50x Version. The latest update 9.503 that should resolve some of the errors was released on the 24th of August and was recalled one day later. Again, all my contacts told me not to upgrade to 9.50x at the moment.

Reply
  • 0 in reply to DouglasFoster

    I am really dissatified with the sophos support. The reaction time is very bad - took 5 weeks to escalate the ticket to development and our problem is still not solved.

    The problem we had is only happening from time to time and was not reproduceable. As it seems not possible to get somebody on the phone immeadetely when the issue occours (we need to resolve the issue on the user side quickly by reinitialising the OTP as he/she can not login) the only way is to try to resolve this by analysing logfiles.

    I have a lot of other things to do and don't want to watch them with a teamviewer (or logmein) session all the time. The major issue with passwords was not that I had to give them to sophos (the standard is to grant access for several well known (Sophos Support) IPs and they have installed certificates that can be used with ssh sessions from their addresses). The main issue is the passwords that are printed in the logfiles when in debug mode. This could also be used by administrators in regular operation scenarios to get hold of the passwords of their users on backend systems - e.g. the Active Directory password (nobody want's to create and manage hundreds of local accounts on the sophos).

    The quality of the product has decreased significantly during the last year. I guess this is because they need to split all their ressources betweeen UTM and XG. XG seems to be even worse. It talked to several administrators and consultants and everybody advised me not to use XG instead of UTM.

    On the UTM side there seems to be a fiasco with the 9.50x Version. The latest update 9.503 that should resolve some of the errors was released on the 24th of August and was recalled one day later. Again, all my contacts told me not to upgrade to 9.50x at the moment.

Children
  • 0 in reply to BeEf

    Yes. The esxalation process has always been slow.

    I have made it to that level multiiple times.

    If the problem is a confirmed bug you are at the mercy of the development schedule tp get your issue fixed.  Given their deveopment problems, your issue may be slow to get action.

    Fortunately, I delayed upgrading firmware until it became clear that 9.408 was superior to anything released since then.  Sadly, the XG side of this blog suggests that the most recent release of XG is unacceptable also.

    I don't understand why we have not seen a statement from senior management to apologize and assure us that they have a get-well plan for UTM development.  9.502 was hopeful, then 9.503 had to be withdrawn.

  • 0 in reply to BeEf

    Is your problem related to this one, and does his workaround work for you?

  • 0 in reply to DouglasFoster

    No.  Occasionally the connection of an existing user to his OTP gets lost. The workaround ist to reinitialize (user gets a different token) and everything is working again. Usually this happens once or twice a week but one day we had serveral users seeing the issue. AFIK there is no pattern which user is affected an when - at least I was not able to identify one.