/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. 

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.

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)

I just checked two clients and neither has dataupload.plx in crontab.  It would seem to violate Sophos' own rules relative to GDPR for the devs to gather data from customers' machines without them specifically opting in.

Cheers - Bob