/usr/local/bin/dataupload.plx, what is it and what is it doing?

Hello - I am a Sophos UTM home user as well and I received the same email. I have used the same UTM software for many years now and this is the first time I have seen this message. Can't help but think the worst ... is this a 0-day exploit attempt? 

Firmware version 9.702-1

Cron <root@utm> /usr/local/bin/dataupload.plx > /dev/null

I noticed dataupload.plx is an ELF binary file that was created on August 24th @ 20:39 

Please let me know what is going on here. 

Hi all, 

Please don't be alarmed, this script was part of a Sophos-issued update and the purpose was to collect additional telemetry for SophosLabs. This was not an attack on SG UTM, and the cronjob is expected. 

What data is collected?  Where is later processed and stored?

Where does one opt-out of this collection?  (or depending on where someone is: where is the opt-in?)

Why was it distributed as an ohelp update and not in another form?

Same here. Got this mail now second time (yesterday and today) from two UTM-Instances.

Same here. Got this mail now second time (yesterday and today) from two UTM-Instances.

Me to, sadly. But, mail wasn't sent to sophos, my mailservers intercepted them. No good luck for sophos, sorry. Nice idea, sadly failed :-) Many black heads are more clever!

By the way, I think sophos (in former times Astaro fw) is a European company. I.e., up to 12/31/2021 ... when Great Britain should pffer the papers how they want to leave the controlled. So far the

REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02016R0679-20160504

acutally should also apply to Sophos as (yet) European company.

Furthermore I don't think it's a good idea of a secrutiy equipment manufacturer to slip the users a silent, not agreed data collection, not to inform about it and not to build-in a switch where you can disable it.

I'm totally disappointed from sophos, good products back or forth. That's not a confidenc-building measure, sorry!

Greetinx

moose

Same thing happened to me this morning.  None of the emails will get back to Sophos, because of the way our mail is routed, but that's not really the point is it?

This product prides itself on providing security - it should not circumvent that security because the developer of the product wants statistics, without...

a) Informing the customer this is happening

b) giving the customer the option to opt out.

Come on guys - sort it out!

so do I take it from this undeliverable email that the script doesn't work

To: root
Cc: 
Bcc: 
Date: Wed, 26 Aug 2020 01:00:03 +0100 (BST)
Subject: Cron <root@another> /usr/local/bin/dataupload.plx > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0   158    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
158   158    0     0  158   158      0    400 --:--:-- --:--:-- --:--:--  1717

What I do not understand, why this is suddenly occurring now, because I am not using the latest version of the UTM at all. Didn't update since many month.

I think we'll find that this has arrived as part of the detection updates, not a firmware update.

The emails themselves are a sign that the crontab entry had output.  cron then attempts to email this to the owner of the crontab entry, root in this case.  they may also suggest things about our UTM configurations regarding email.  (others might want to try less $MAIL as root)

The content of the email will suggest if the upload was successful. 

Here is MotoMoto's email, reformatted with a fixed width font and the reported transferred byte count in red:

To: root
Cc: 
Bcc: 
Date: Wed, 26 Aug 2020 01:00:03 +0100 (BST)
Subject: Cron <root@another> /usr/local/bin/dataupload.plx > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0   158    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
158   158    0     0  158   158      0    400 --:--:-- --:--:-- --:--:--  1717

So then, a bit more about the upload content might include?

In my case I observe a tar.gz containing a file with a name that includes: 

• "clean" (what other values might there be?)
• date
• UTM License ID (# cc get licensing | grep ^Id)
• system_id (#cc get settings system_id)
• filename ending in .eip

The content of the file?   IP addresses, or rather network addresses with no indication of the subnet size. 

It is curious that it appears to look for something in the webadmin logs, all of them.  What & why?

It arrived as a part of the online help package.

# rpm -ql $(rpm -qa | grep u2d-ohelp) | grep dataupload.plx
/usr/local/bin/dataupload.plx

On mine at the moment.

# rpm -qi $(rpm -qa | grep u2d-ohelp)
Name : u2d-ohelp9 Relocations: (not relocatable)
Version : 9 Vendor: Astaro GmbH & Co. KG
Release : 1091 Build Date: Tue 25 Aug 2020 11:28:36 PM -03
Install Date: Wed 26 Aug 2020 08:36:21 AM -03 Build Host: kar-patternbuild1
Group : Pattern Source RPM: u2d-ohelp9-9-1091.src.rpm
Size : 55157336 License: Astaro
Signature : (none)
Packager : Astaro GmbH & Co. KG
URL : http://www.astaro.com
Summary : Onlinehelp
Description :
Onlinehelp
Distribution: Astaro Security Gateway
#

The entire contents of the ohelp package currently installed on your UTM:  rpm -ql $(rpm -qa | grep u2d-ohelp)

Given how much working environments have changed this year, we have accelerated our product security efforts, taking a more proactive approach.  As part of this initiative, we’ve already deployed a number security enhancements in UTM 9.704 and MRs for our XG Firewall platform.  As a result of these efforts, we have identified additional telemetry that would better assist with our security efforts.  This telemetry gathering is a valuable feature we already have on our XG Firewall platform, but we lacked some information that would enable us to better protect our SG UTM platform.  We do not collect any Personally Identifiable Information (PII).  Specifically the information we are gathering is:

- UTM ID

- License serial #

- Any helpful error entries in webadmin.log

- Other operational statistics

As described, we are not collecting any PII data. The data which is collected complies with the GDPR, the EULA, and other data privacy requirements. We are gathering this operational data to help improve the product, enhance its security, and further protect your important data.  

Thanks for your understanding, and we apologize for any confusion.

Why is our Sophos sending that kind of data back to you?

Despite that we did not agree to send any data back. Like "Sophos Adaptive Learning" is disabled, as well as "Send suspicious content to Sophos Labs for analysis".

It is not okay, to just collect data without any customer approval!

And why is our e-mail-server used for that?

How can I disable that? Is it save to disable this cronjob?

Mamolian is absolutely right to argue here.

If i don't want to have such a function within my existing installations, how to disable that now?
You didn't ask for customer approval and integrated that data-collecting into also older versions through a back door.

At the moment the systems try to send maildata every night, but they can't do that, because my mailgateways don't allow it. It is annoying to keep receiving error messages.

how do you deactivate it again easily and officially?