Int strncmp ( const char * string1, const char * string2, size_t count ) We should pay extra attention here, because the devil always sits undisturbed in the details.Īs opposed to strcmp which is dealing with null-terminated strings, strncmp is returning a 0 (identical strings) if one of the two checked ** non-null-terminated** substrings are identical for the given N characters, no matter how many extra characters are prepended afterwords. This value is then saved in r8 (as MaxCount) and passed together with our entire command to strncmp. We can double-check via WinDbg that, in my specific case, the path-string is indeed 29 character long. This parameter is then passed to strlen, which gives 0x1d as a result. To check the path length, strlen is called first, whose argument is the Str variable, derived by the following function, which has obviously hardcoded parameters matching the expected application path C:\ProgramData\Druva\inSync4\. Firstly, let’s take a closer look at the two functions, strlen and strncmp that are responsible for the branching decision. This poses the questions which string is representing the allowed path? And how is the verification actually done? Let’s deal with one thing at a time. It seems that a path checker has been introduced: any binary invoked outside the scope of the inSync path will just be ignored. If we run the old exploit against the latest version, we fail miserably and we get warned by an admonitory message.Īs an initial strategy we can diff the patched CreateProcess function to see if there is an additional check in place or any other changes to the previous version. Is the fix really fixing what is supposed to be fixed? □ĭruva’s security bulletin stated that the latest 6.6.3 release included a fix, which can be downloaded here. This made me curious and I started to dig deeper into how the vulnerability had been mitigated. This is clearly an unrestricted command injection that allows us to execute any commands with the same privileges as SYSTEM user. Setting in motion IDA and verifying that function number 5 is exposing remote command injection, gives this result:Īnd sure enough, at location 140001F60 we spot our beloved CreateProcess taking the command line string as an argument. In this case, it is function number 5 that’s of interest, as it is mapped to a generic command execution. Ě function number: the app maps various functionalities, like backup snapshot or probing, to a function number.A hello packet: in our case it’s the hardcoded string inSync PHC RPCW.The communication protocol is pretty straightforward and it requires the following packets to be sent one at a time: The escalation is accomplished by interacting to the he local service running on port 6064 by means of valid network commands. The first bug discovered by Tenable research is in fact a Local Privilege Escalation (LPE) via Command Injection. The InSync Windows client application runs a service as SYSTEM, hence any security vulnerability could lead to an escalation of privileges (EoP). Initial bug historyĭruva InSync is an endpoint application that is responsible for “Integrated backup, eDiscovery and compliance monitoring” as stated on Druva website. ![]() A team from Tenable Research and I concurrently discovered this new vulnerability, resulting in a new CVE ( CVE-2020-5752) and exploit being published. However, the patch introduced an additional bug, paving the way for further exploitation and making it possible for a local low-privileged user to obtain SYSTEM level privileges. Druva had by then implemented a patch on their latest InSync release, fixing the bug. On April 29th, exploit-db published a Local Privilege Escalation (LPE) exploit for Druva InSync.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |