EOPRadar - Privilege escalation vulnerability scanner

Discussion in 'other anti-malware software' started by svenfaw, Jul 30, 2018.

  1. Floyd 57

    Floyd 57 Registered Member

    Joined:
    Mar 17, 2017
    Posts:
    78
    Location:
    Europe
    Using version 1.08 now, I've got a few questions:

    1) Since when did .log files become dangerous and executable files?
    2) Another dangling reference, but this time it's invisible, seems like EOPRadar has upped its game: https://i.lensdump.com/i/AipxgA.png
    3) What defines a file as Admin-owned? There are files whose owner is a limited user local account (not administrator, but a standard account) that are not marked as admin-owned but are marked as user-writable, as they should be, and other files marked as BOTH admin-owned and user-writable whose owner is the same STANDARD/LIMITED user account??? WHAT'S HAPPENING HERE???
    4) Ok now, what is this black magic thing going on here? Can you be a bit more precise than "critical"? This file is just like every other one on the ERP results list, permission and ownership-wise: https://i.lensdump.com/i/Ai7jcc.png
     
  2. svenfaw

    svenfaw Registered Member

    Joined:
    May 7, 2012
    Posts:
    213


    1) the .log files detected by EOPRadar are potentially dangerous because of their permissions, not their content.
    Even if they are just plain text, unsafe ACLs on log files (or their parent folders) created by elevated processes can enable a so-called Symbolic Link Attack, which can often lead to privilege escalation.
    2) That might be a bug. Will look into it.
    3) A file is also marked as admin-owned if its parent folder is. Again, this can lead to privilege escalation.
    I admit the scan results are a little ambiguous in this case and will try to address that in a further release.
    4) This normally means that the file was created by an elevated persistent (ie, auto-starting) process, which often makes privilege escalation trivial to achieve.

    I'm afraid I can't answer in more detail, but if you need more information, Google is your friend :)
     
    Last edited: Sep 11, 2018
  3. Floyd 57

    Floyd 57 Registered Member

    Joined:
    Mar 17, 2017
    Posts:
    78
    Location:
    Europe
    So essentially, what you're trying to say, is that, well obviously, a non-escalated entity can swap the log files with malicious ones, since the logs' permissions aren't properly set, and THEN the program using those logs will do something bad (malicious?) based on the information that it read from the malicious swapped log file? At least that's what I understood, according to slide 8 of this presentation that I found https://www.slideshare.net/OWASPdelhi/abusing-symlinks-on-windows

    Ok, so I kinda understood the last one, but I don't really understand this one. So what if the target file is admin-owned (either through its own owner or its parent folder's owner), what does that matter? I thought the goal was to prevent privilege escalation, how would the bad entity abuse the admin-owned files when it doesn't have admin rights itself? Also, if Folder 1 contains Folder 2, and Folder 2 contains a file, and neither the file nor Folder 2 are admin-owned, but Folder 1 is admin-owned, does ERPRadar then mark that file as admin-owned? I mean like did you implement that? And ofc it can extend to folder 3 folder 4 etc. until it reaches the drive permissions
     
Loading...
Similar Threads
  1. Mr.X
    Replies:
    1
    Views:
    186
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.