ownDMS 4.7 is vulnerable to SQL Injection. An attacker can inject malicious SQL queries via the IMG, showfordoc parameters in pdfstream.php, imagestream.php, anyfilestream.php, cashbook.php respectively. This can be exploited to bypass authentication, access, modify and delete data in the back-end database.
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Windows. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of VCard files. Crafted data in a VCard file can cause Windows to display a dangerous hyperlink. The user interface fails to provide any indication of the hazard. An attacker can leverage this vulnerability to execute code in the context of the current user.
The 1Password application < 7.0 for Android is affected by a Denial Of Service vulnerability. By starting the activity com.agilebits.onepassword.filling.openyolo.OpenYoloDeleteActivity or com.agilebits.onepassword.filling.openyolo.OpenYoloRetrieveActivity from an external application (since they are exported), it is possible to crash the 1Password instance. To invoke the exported activity and crash the app, it is possible to use Drozer: run app.activity.start --component com.agilebits.onepassword com.agilebits.onepassword.filling.openyolo.OpenYoloDeleteActivity
The CGI scripts used on the 420HD phone (web interface) do not filter user inputs correctly. Consequently, an authenticated attacker could inject arbitrary commands (Remote Code Execution) and take full control over the device. For example, it is possible to intercept live communications.
Many input fields are vulnerable to SQL injection. An SQL injection allows typically an attacker to execute almost arbitrary SQL commands. It is possible to break out of the original query with an uptick, append a custom query and fix the syntax. The application supports Firebird and MS SQL database servers. Stacked queries do not work with both database servers. One of the vulnerable input fields is the user name within the login form. This allows even unauthenticated users to exploit the application. Because the authentication process is implemented in the client application, the SQL injection in the login form does not allow a login bypass. The most promising real-life attack among other possible attacks is to steal the encrypted passphrase of the users.
The COM Desktop Broker doesn’t correctly check permissions resulting in elevation of privilege and sandbox escape. Windows 10 introduced “Brokered Windows Runtime Components for side-loaded applications” which allows a UWP application to interact with privileged components by allowing developers to write a custom broker in .NET. Rather than handling this with the existing Runtime Broker a new “Desktop Broker” was created and plumbed into the COM infrastructure. This required changes in COMBASE to instantiate the broker class and RPCSS to control access to the broker. The stated purpose is only for use by sideloaded enterprise applications, specifically .NET based ones. Looking at the checks in RPCSS for the activation of the broker we can see the check as follows: HRESULT IsSideLoadedPackage(LPCWSTR *package_name, bool *is_sideloaded) { PackageOrigin origin; *is_sideloaded = false; HRESULT hr = GetStagedPackageOrigin(package_name, &origin); if (FAILED(hr)) return hr; *is_sideloaded = origin != PackageOrigin_Store; return S_OK; } This check is interesting because it considered anything to be sideloaded that hasn’t come from the Store. Looking at the PackageOrigin enumeration this includes Inbox applications such as Cortana and Edge both of which process potentially untrusted content from the network. Of course this isn’t an issue if the broker is secure, but… For a start, as long as RPCSS thinks the current package is side-loaded this feature doesn’t require any further capability to use, or at least nothing checks for one during the process. Even in the side loading case this isn’t ideal, it means that even though a side loaded application is in the sandbox this would allow the application to
The Data Sharing Service MoveFileInheritSecurity method is broken leading to EoP. The PolicyChecker::MoveFileInheritSecurity method is almost an exact copy of the code from the Storage Service which I exploited in MSRC cases 42121 and 42122. In fact I’d say it’s the same code copy and pasted. It has the exactly same bugs as the storage service version, specifically arbitrary file writes, due to the reverting call to MoveFileEx and arbitrary ACL setting by placing a hardlinked file in a directory with inheritable ACEs. This method is called from DSSMoveToSharedFile and DSSMoveFromSharedFile. While those methods do some checking it’s still possible to bypass the checks. This results in the MoveFileInheritSecurity method being called as the SYSTEM user which results in EoP.
The Data Sharing Service DSOpenSharedFile method takes a flag to delete a shared file on close which can be abused to delete an arbitrary file. The DSOpenSharedFile method takes a flag parameter where the file handle can be opened overlapped or for delete on close. The delete on close flag will set the flag FILE_FLAG_DELETE_ON_CLOSE when opening the file with CreateFile. This code runs as SYSTEM so will open any file that that user has access to. However there’s a couple of issues with this: 1) The code doesn’t check that the file was shared writable, which means it’s possible to trivially specify a file to DSCreateSharedFileToken you want to delete and specify read only permissions. Then call DSOpenSharedFile with the delete on close flag, as the flag automatically adds the DELETE permission to the file open this will succeed even with the read-only mode set. 2) The DSOpenSharedFile relies on calling DSUtils::VerifyPathFromHandle prevent returning a handle which was redirected due to something like a symlink or directory junction. However by the time the code reaches the verification it’s already too late and the file will delete on close regardless of what the service now does.
The Data Sharing Service allows you to setup a shared file, referenced by a GUID token by calling DSCreateSharedFileToken. The GUID token can then be passed back to DSOpenSharedFile to get a handle to the file. When the token is created the user passes a flag to indicate whether the file should be opened as Read and/or Write. This flag is then used during the call to CreateFile inside the service while running as the SYSTEM user. In order to defend against the user replacing the file with a symlink the service checks that the opened file and the original path match by calling GetFinalPathNameByHandle. While the file will be opened as SYSTEM the user won’t get back a handle to the file to allow them to manipulate it. This breaks down with hard links, it’s possible for the user to setup a file to which they have full access and register the token. The file can then be deleted (as the service doesn’t maintain any lock on the file) and replace it with a hard link to a file the user can only read. This is possible as while the CreateHardlink API requires FILE_WRITE_ATTRIBUTES access the user can still create a hard link to a file they don’t have access to. When the service then calls GetFinalPathNameByHandle it will return the original path, not the path of the hard link. This means the service will open the file with full access, allowing the user to read and write to the file.
Bigcart - Ecommerce Multivendor System 1.0 is vulnerable to SQL Injection. An attacker can send a specially crafted HTTP request to the vulnerable application in order to execute arbitrary SQL commands in the back-end database. This can be exploited to manipulate or disclose arbitrary data in the back-end database.
Services By CQR