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

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.

What??? all passwords are clear in the logfiles, that should indeed never ever happen!

Yes. If you switch on debug mode [removed] all passwords are printed in the logfile in cleartext. Calling [removed] again switches off the debug mode.The main issue here is that this can be exploited by every administrator of a firewall device.

I see that there might be some need to debug and test authentication during the development process of the software. However this should be removed completely in the production environment (or at least all passwords should be replaced by * or something else). The latter would still give you the opportunity to see what's happening on the firewall (eg. the results of an LDAP query against Active Directory) and whether this is successfull or not.

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.

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.

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

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.

Hi BeEf,

I can really understand the criticality and would like to know the case#. I will look into the case personally and make sure this incident is taken care. 

Thanks

Hi Sachingurung,

the case IDs are [#7441831] [#7528461]. The case is in German. They told me now to upgrade to 9.503 because they think it might be related to NUTM-6532 und NUTM-7167. Are you the same opinion? I plan to do the update next week and leave one of the nodes with the old firmware 9.413-04.

The last person who worked on this was

Timo Möhrle
Sophos Technischer Support

who had some development guy in the background.

However this ticket was basically about printing passwords in the logfile in cleartext. In the opinon of me (and my colleagues) this is a major security breach as this could expose passwords in backend systems by every firewall administrator. Maybe you can ask your development to get this changed.

Actually I am considering to send this to Heise Security (the blog of the most popular German computer magazine) or cve.mitre.org.

Best regards,

Bernd

Contacting the Mitre CVE database sounds like the better idea, as it has more likelihood of requiring an engineering response rather than a marketing one.