The SMB server driver (srv.sys and srv2.sys) don't check the destination of a NTFS mount point when manually handling a reparse operation leading to being able to locally open an arbitrary device via an SMB client which can result in EoP. NTFS mount points are handled local to the SMB server so that the client does not see them. This is different from NTFS symbolic links which are passed back to the client to deal with. In order to handle the symbolic link case the server calls IoCreateFileEx from Smb2CreateFile passing the IO_STOP_ON_SYMLINK flag which results in the IoCreateFileEx call failing with the STATUS_STOPPED_ON_SYMLINK code. The server can then extract the substitution path from the reparse pointer buffer and either pass the buffer to the client if it's a symbolic link or handle it if it's a mount point. The way the server handles a symbolic link is to recall IoCreateFileEx in a loop (it does check for a maximum iteration count although I'd swear that's a recent change) passing the new substitute path. This is different to how the IO manager would handle this operation. In the IO manager's case the reparse operation is limited to a small subset of device types, such as Disk Volumes. If the new target isn't in the small list of types then the reparse will fail with an STATUS_IO_REPARSE_DATA_INVALID error. However the SMB server does no checks so the open operation can be redirected to any device. This is interesting due to the way in which the device is being opened, it's in a system thread and allows a caller to pass an arbitrary EA block which can be paged in.
When impersonating the anonymous token in an LPAC the WIN://NOAPPALLPKG security attribute is ignored leading to impersonating a non-LPAC token leading to EoP.
There's a missing check for impersonation level in NtImpersonateAnonymousToken when considering if the caller is currently an AC. This results in the function falling into the restricted token case if the caller is impersonating a non AC token at identification or below, leading to Elevation of Privilege.
When creating a new file on an NTFS drive it’s possible to circumvent security checks for setting an arbitrary owner and mandatory label leading to a non-admin user setting those parts of the security descriptor with non-standard values which could result in further attacks resulting EoP. The kernel limits who can arbitrarily set the Owner and Mandatory Label fields of a security descriptor. Specifically unless the current token has SeRestorePrivilege, SeTakeOwnershipPrivilege or SeRelabelPrivilege you can only set an owner which is set in the current token (for the label is can also be less than the current label). As setting an arbitrary owner in the token or raising the IL is also a privileged operation this prevents a normal user from setting these fields to arbitrary values. When creating a new file on an NTFS volume you can specify an arbitrary Security Descriptor with the create request and it will be set during the creation process. If you specify an arbitrary owner or label it will return an error as expected. Looking at the implementation in NTFS the function NtfsCreateNewFile calls NtfsAssignSecurity which then calls the kernel API SeAssignSecurityEx. The problem here is that SeAssignSecurityEx doesn’t take an explicit KPROCESSOR_MODE argument so instead the kernel takes the current thread’s previous access mode. The previous mode however might not match up with the current assumed access mode based on the caller, for example if the create call has been delegated to a system thread. A common place this mode mismatch occurs is in the SMB server, which runs entirely in the system process. All threads used by SMB are running with a previous mode of KernelMode, but will create files by specifying IO_FORCE_ACCESS_CHECK so that the impersonated caller identity is used for security cheks. This means that when creating a new file on an NTFS volume the security descriptor will be set using the kernel mode SeAssignSecurityEx API, allowing an arbitrary owner and mandatory label to be set.
The hardware service manager allows the registration of HAL services. These services are used by the vendor domain and other core processes, including system_server, surfaceflinger and hwservicemanager. The 'add' binder call allows callers to supply a binder instance to be registered with the hardware service manager. When issued, the call is unpacked by the auto-generated hidl stub, and then passed to 'ServiceManager::add' for processing. The function first checks if the caller is allowed to add the service by calling the 'mAcl.canAdd' function. However, this function has a flaw in that it allows all callers to add services if the 'mAllowAll' flag is set to true.
This exploit allows an attacker to execute arbitrary code on a vulnerable D-Link WAP 615/645/815 device running firmware version 1.03 or lower. The exploit works by sending a specially crafted POST request to the device's service.cgi page, which allows the attacker to execute arbitrary commands on the device.
Follow HTTP request is a simple PoC for anon time-based SQL injection (CVE-2016-2386) vulnerability in SAP NetWeaver AS Java UDDI 7.11-7.50. The payload used is %PRIVATE_DATASOURCE.un:Administrator% and other tables that can be used are UME_STRINGS_PERM, UME_STRINGS_ACTN, BC_DDDBDP, BC_COMPVERS, TC_WDRR_MRO_LUT, TC_WDRR_MRO_FILES, T_CHUNK, T_DOMAIN, T_SESSION, UME_ACL_SUP_PERM, UME_ACL_PERM, UM_STRINGS.
This exploit is a privilege escalation vulnerability in Windows 7 SP1 x86. It uses a shellcode to steal the token of the SYSTEM process and replace the token of the current process with it, thus granting the current process SYSTEM privileges.
This module exploits a remote command execution vulnerablity in Hewlett Packard Enterprise Intelligent Management Center before version 7.3 E0504P04. The dbman service allows unauthenticated remote users to restart a user-specified database instance (OpCode 10008), however the instance ID is not sanitized, allowing execution of arbitrary operating system commands as SYSTEM. This service listens on TCP port 2810 by default. This module has been tested successfully on iMC PLAT v7.2 (E0403) on Windows 7 SP1 (EN).
This module exploits a remote command execution vulnerablity in Hewlett Packard Enterprise Intelligent Management Center before version 7.3 E0504P04. The dbman service allows unauthenticated remote users to restore a user-specified database (OpCode 10007), however the database connection username is not sanitized resulting in command injection, allowing execution of arbitrary operating system commands as SYSTEM. This service listens on TCP port 2810 by default.