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

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

What is /usr/local/bin/dataupload.plx doing and why?

 

I noticed an unexpected email from my UTM software appliance (home use).

Current software version...: 9.703003
# crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall. # (- installed on Mon Aug 24 20:36:33 2020) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) 0 1 * * * /usr/local/bin/dataupload.plx > /dev/null #
# ls -l /usr/local/bin/dataupload.plx
-rwxr-xr-x 1 root root 93292 Aug 24 21:39 /usr/local/bin/dataupload.plx

 

I almost certainly would not have noticed this had standard error been redirected too.

 

A few notes:

u2d-ohelp9-9.1086 ?

/var/log/webadmin/*/*/*

/tmp/*/*.eip & /tmp/*/*.tar.gz

ip addresses, what more?

upload to something fronted by cloudfront?

 

 

Edit:  Note, incomplete answers will not be considered as an accepted answer.  Details on what the plx is doing, why it is doing so and why this appears to have been silently rolled out are not insignificant to the post.  Further questions in the replies are also important.



This thread was automatically locked due to age.
Parents
  • 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. 

  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I'll hazard a guess that this new "package" has something to do with this:

     

    https://support.sophos.com/support/s/article/KB-000039869?language=en_US

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 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?

  • Hi, 

    The UTM is not sending back this telemetry over email. The emails you see are due to errors in the script, which you should not see anymore. Let me know if you're still getting these emails. 

    We are only collecting this telemetry/data for 7 days. Afterwards the data collection script & cronjob will automatically be disabled. 

  • I agree to and .

    "The UTM is not sending back this telemetry over email. The emails you see are due to errors in the script, which you should not see anymore. Let me know if you're still getting these emails."

    Indeed, I didn't see this mail today. But, how could this be done without a sw update? Didn't install any today! May be, there's a backdoor in your sw which allows access to the UTM without user agreement? Strange, strange ...

    Anyway, for me it's enough. I'm a great fan of this sw since it was owned by Astaro. But, anyway, I hate systems which are sending back data without my prior agreement, anyway if visible or like now 'invisible'.

    I think every thing in life has its time. And for me the time of Sohpos UTM is expired. I'll switch to OPNsense® asap. Good by, Sophos UTM!

    Greetinx

    moose

  • I still get 2-6 emails every night because of this script!

Reply Children
No Data