VARIoT IoT vulnerabilities database

AutoEnt is a picture configuration software. AutoEnt has a memory corruption vulnerability. An attacker could exploit the vulnerability to cause memory corruption when reading a project file

Shenzhen INVT Electric Co., Ltd. is a product and service provider in the fields of electrical transmission, industrial control and new energy. The INVT VS series HMI programming software has a memory read out-of-bounds vulnerability. The vulnerability is caused by the failure of the file to verify the header of the project file. Attackers can use the vulnerability to cause memory reads to cross the boundary, causing a denial of service vulnerability. If the vulnerability is successfully exploited, it may also cause arbitrary code execution

Cross-site scripting (XSS) vulnerability in Address Book Editor in Synology CardDAV Server before 6.0.8-0086 allows remote authenticated users to inject arbitrary web script or HTML via the (1) family_name, (2) given_name, or (3) additional_name parameter. Synology CardDAV Server Contains a cross-site scripting vulnerability.Information may be obtained and information may be altered. Synology CardDAV Server is an application from Synology for synchronizing contacts. Address Book Editor is one of the address book editors

Unquoted service paths in Intel Processor Diagnostic Tool (IPDT) before version 4.1.0.27 allows a local attacker to potentially execute arbitrary code. Intel Processor Diagnostic Tool (IPDT) is a processor function diagnostic tool of Intel Corporation. A security vulnerability exists in versions prior to Intel IPDT 4.1.0.27. Intel published advisory SA-00140 <https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html> on 2018-06-27 and updated installers on 2018-05-18. The vulnerabilities can be exploited in standard installations of Windows where the user^WUAC-"protected administrator" account created during Windows setup is used, without elevation. This precondition holds for the majority of Windows installations: according to Microsoft's own security intelligence reports <https://www.microsoft.com/security/sir>, about 1/2 to 3/4 of the about 600 million Windows installations which send telemetry data have only ONE active user account. #1 Denial of service through insecure file permissions ====================================================== The downloadable executable installer (really: executable self-extractor built with WinZIP) IPDT_Installer_4.1.0.24.exe creates a subdirectory with random name in %TEMP%, copies itself into this subdirectory and then executes its copy. The subdirectory inherits the NTFS ACLs from its parent %TEMP%, and so does the copy of the executable self-extractor. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/377.html> and <https://cwe.mitre.org/data/definitions/379.html> plus <https://capec.mitre.org/data/definitions/29.html> Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. download IPDT_Installer_4.1.0.24.exe (quite some clueless copycats still offer it, violating Intel's copyright; <http://d.computerbild.de/downloads/7835763/IPDT_Installer_4.1.0.24.exe>) and save it in your "Downloads" directory"; 2. add the NTFS access control list entry (D;OIIO;WP;;;WD) meaning "deny execution of files in this directory for everyone, inheritable to files in all subdirectories" to the (user's) %TEMP% directory. 3. execute IPDT_Installer_4.1.024.exe: notice the complete failure of the executable installer^Wself-extractor, WITHOUT error message! #2 Escalation of privilege through insecure file permissions ============================================================ Although the (copy of the) executable self-extractor runs with administrative privileges (its embedded "application manifest" specifies 'requireAdministrator'), it extracts its payload, the REAL installers setup.exe and setup64.exe, plus the batch script setup.bat, UNPROTECTED into the user's %TEMP% directory, CD's into %TEMP% and finally executes the extracted batch script %TEMP%\setup.bat: --- setup.bat --- echo off ver | findstr 6.1.7600 if %errorlevel%==0 goto WinUnsup ver | findstr 6.0.6001 if %errorlevel%==0 goto WinUnsup if "%programfiles(x86)%XXX"=="XXX" goto 32BIT :64BIT setup64.exe goto END :32BIT setup.exe goto END :WinUnsup echo Intel Processor Diagnostic Tool cannot be installed on this Operating System echo Please go to Online support page to view list of supported Oerating Systems pause :END exit 0 --- EOF --- The extracted files inherit the NTFS ACLs from their parent %TEMP%, allowing "full access" for the unprivileged (owning) user, who can replace/overwrite the files between their creation and execution. Since the files are executed with administrative privileges, this vulnerability results in arbitrary code execution with escalation of privilege. Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. create the following batch script in an arbitrary directory: --- IPDT.CMD --- :LOOP1 @If Not Exist "%TEMP%\setup.exe" Goto :LOOP1 Echo >"%TEMP%\setup.bat" WhoAMI.exe /all Echo >>"%TEMP%\setup.bat" Pause :LOOP2 @If Not Exist "%TEMP%\setup64.exe" Goto :LOOP2 Copy /Y %COMSPEC% "%TEMP%\setup.exe" :LOOP3 @Copy %COMSPEC% "%TEMP%\setup64.exe" @If ERRORLEVEL 1 Goto :LOOP3 --- EOF --- NOTE: the batch script needs to win a race (which it almost always will, due to the size of the files extracted). 2. execute the batch script per double-click; 3. execute IPDT_Installer_4.1.024.exe per double-click: notice the command processor started instead one of the executable installers, running with administrative privileges. #3 Escalation of privilege through unsafe search path ===================================================== In Windows Vista and newer versions, the current working directory can be removed from the executable search path: <https://msdn.microsoft.com/en-us/library/ms684269.aspx> The batch script setup.bat calls setup.exe and setup64.exe without a path, so the command processor doesn't find the extracted setup.exe and setup64.exe in its CWD and searches them via %PATH%. %PATH% is under full control of the unprivileged user, who can create rogue setup.exe and setup64.exe in an arbitrary directory he adds to the %PATH%, resulting again in arbitrary code execution with escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. start an unprivileged command prompt in an arbitrary directory where the unprivileged user can create files, for example the user's "Downloads" directory; 2. add this (current working) directory to the user's PATH: PATH %CD%;%PATH% REG.exe Add HKCU\Environment /V PATH /T REG_SZ /D "%CD%" /F 3. copy the command processor %COMSPEC% (or any rogue executable of your choice) as setup.exe and setup64.exe into the current (working) directory: COPY %COMSPEC% "%CD%\setup.exe" COPY %COMSPEC% "%CD%\setup64.exe" 4. set the environment variable NoDefaultCurrentDirectoryInExePath to an arbitrary value: SET NoDefaultCurrentDirectoryInExePath=* REG.exe Add HKCU\Environment /V NoDefaultCurrentDirectoryInExePath /T REG_SZ /D "*" /F 5. execute IPDT_Installer_4.1.024.exe per double-click: notice the command processor started instead of the extracted executable installers, running with administrative privileges. #4 Escalation of privilege through DLL search order hijacking ============================================================= The extracted executable installers setup.exe and setup64.exe, built with the crapware known as InstallShield, load multiple Windows system DLLs from their "application directory" %TEMP% instead from Windows' "system directory" %SystemRoot%\System32\ To quote Raymond Chen <https://blogs.msdn.microsoft.com/oldnewthing/20121031-00/?p=6203> | a rogue DLL in the TEMP directory is a trap waiting to be sprung. An unprivileged attacker running in the same user account can copy rogue DLLs into %TEMP%; these are loaded and their DllMain() routine executed with administrative privileges, once more resulting in arbitrary code execution with escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. follow the instructions from <https://skanthak.homepage.t-online.de/minesweeper.html> and build a minefield of forwarder DLLs in your %TEMP% directory; NOTE: if you can't or don't want to build the minefield, download <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL> and save it as UXTheme.dll, DWMAPI.dll, NTMARTA.dll and MSI.dll in your %TEMP% directory. 2. execute IPDT_Installer_4.1.0.24.exe: notice the message boxes displayed from the DLLs built in step 1! NOTE: on a fully patched Windows 7 SP1, setup64.exe loads at least the following 32-bit DLLs from %TEMP%: UXTheme.dll, Version.dll, NTMARTA.dll and MSI.dll Due to its filename, setup.exe additionally loads WinMM.dll, SAMCli.dll, MSACM32.dll, SFC.dll, SFC_OS.dll, DWMAPI.dll and MPR.dll. Fix: ==== 1. DUMP all those forever vulnerable executable installers and self-extractors; provide an .MSI package or an .INF script plus a .CAB archive instead! 2. NEVER use an unqualified filename to execute/load an application or a DLL, ALWAYS specify their fully qualified pathname! Mitigations: ============ 1. DON'T execute executable self-extractors. 2. NEVER execute executable self-extractors with administrative privileges. 3. extract the payload of the self-extractor with a SAFE and SECURE unzip.exe into a properly protected directory. 4. exercise STRICT privilege separation: use separate unprivileged user accounts and privileged administrator account, DISABLE the "security theatre" UAC in the unprivileged user accounts. stay tuned Stefan Kanthak PS: the "portable executable" IPDT_Installer_4.1.024.exe has an export directory, but does NOT export any symbols: both the numbers of names and functions are 0, and the RVAs of the functions, names and ordinals arrays are 0 too. Timeline: ========= 2018-03-28 sent vulnerability report to <secure@intel.com> no reply, not even an acknowledgement of receipt 2018-04-05 resent vulnerability report to <secure@intel.com>, CC: to CERT/CC no reply, not even an acknowledgement of receipt 2018-05-03 resent vulnerability report via HackerOne 2018-05-04 Intel acknowledges receipt 2018-05-17 Intel confirms the reported vulnerabilities 2018-05-21 Intel publishes fixed installers, with a dangling reference to SA-00140 in the release notes, plus inaccuracies regarding the dependencies of IPDT NO notification sent to me that fixes have been published! 2018-06-05 sent report about the errors in the release notes after stumbling over the fixes 2018-06-12 Intel acknowledges the report regarding the notes 2018-06-27 Intel publishes their advisory SA-00140 AGAIN no notification sent that the advisory has been published! Intel's understanding of coordinated disclosure looks rather weird to me

Installation tool IPDT (Intel Processor Diagnostic Tool) 4.1.0.24 sets permissions of installed files incorrectly, allowing for execution of arbitrary code and potential privilege escalation. Intel Processor Diagnostic Tool (IPDT) is a processor function diagnostic tool of Intel Corporation. Intel published advisory SA-00140 <https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html> on 2018-06-27 and updated installers on 2018-05-18. The vulnerabilities can be exploited in standard installations of Windows where the user^WUAC-"protected administrator" account created during Windows setup is used, without elevation. This precondition holds for the majority of Windows installations: according to Microsoft's own security intelligence reports <https://www.microsoft.com/security/sir>, about 1/2 to 3/4 of the about 600 million Windows installations which send telemetry data have only ONE active user account. #1 Denial of service through insecure file permissions ====================================================== The downloadable executable installer (really: executable self-extractor built with WinZIP) IPDT_Installer_4.1.0.24.exe creates a subdirectory with random name in %TEMP%, copies itself into this subdirectory and then executes its copy. The subdirectory inherits the NTFS ACLs from its parent %TEMP%, and so does the copy of the executable self-extractor. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/377.html> and <https://cwe.mitre.org/data/definitions/379.html> plus <https://capec.mitre.org/data/definitions/29.html> Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. download IPDT_Installer_4.1.0.24.exe (quite some clueless copycats still offer it, violating Intel's copyright; <http://d.computerbild.de/downloads/7835763/IPDT_Installer_4.1.0.24.exe>) and save it in your "Downloads" directory"; 2. add the NTFS access control list entry (D;OIIO;WP;;;WD) meaning "deny execution of files in this directory for everyone, inheritable to files in all subdirectories" to the (user's) %TEMP% directory. 3. execute IPDT_Installer_4.1.024.exe: notice the complete failure of the executable installer^Wself-extractor, WITHOUT error message! #2 Escalation of privilege through insecure file permissions ============================================================ Although the (copy of the) executable self-extractor runs with administrative privileges (its embedded "application manifest" specifies 'requireAdministrator'), it extracts its payload, the REAL installers setup.exe and setup64.exe, plus the batch script setup.bat, UNPROTECTED into the user's %TEMP% directory, CD's into %TEMP% and finally executes the extracted batch script %TEMP%\setup.bat: --- setup.bat --- echo off ver | findstr 6.1.7600 if %errorlevel%==0 goto WinUnsup ver | findstr 6.0.6001 if %errorlevel%==0 goto WinUnsup if "%programfiles(x86)%XXX"=="XXX" goto 32BIT :64BIT setup64.exe goto END :32BIT setup.exe goto END :WinUnsup echo Intel Processor Diagnostic Tool cannot be installed on this Operating System echo Please go to Online support page to view list of supported Oerating Systems pause :END exit 0 --- EOF --- The extracted files inherit the NTFS ACLs from their parent %TEMP%, allowing "full access" for the unprivileged (owning) user, who can replace/overwrite the files between their creation and execution. Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. create the following batch script in an arbitrary directory: --- IPDT.CMD --- :LOOP1 @If Not Exist "%TEMP%\setup.exe" Goto :LOOP1 Echo >"%TEMP%\setup.bat" WhoAMI.exe /all Echo >>"%TEMP%\setup.bat" Pause :LOOP2 @If Not Exist "%TEMP%\setup64.exe" Goto :LOOP2 Copy /Y %COMSPEC% "%TEMP%\setup.exe" :LOOP3 @Copy %COMSPEC% "%TEMP%\setup64.exe" @If ERRORLEVEL 1 Goto :LOOP3 --- EOF --- NOTE: the batch script needs to win a race (which it almost always will, due to the size of the files extracted). 2. execute the batch script per double-click; 3. execute IPDT_Installer_4.1.024.exe per double-click: notice the command processor started instead one of the executable installers, running with administrative privileges. #3 Escalation of privilege through unsafe search path ===================================================== In Windows Vista and newer versions, the current working directory can be removed from the executable search path: <https://msdn.microsoft.com/en-us/library/ms684269.aspx> The batch script setup.bat calls setup.exe and setup64.exe without a path, so the command processor doesn't find the extracted setup.exe and setup64.exe in its CWD and searches them via %PATH%. %PATH% is under full control of the unprivileged user, who can create rogue setup.exe and setup64.exe in an arbitrary directory he adds to the %PATH%, resulting again in arbitrary code execution with escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. start an unprivileged command prompt in an arbitrary directory where the unprivileged user can create files, for example the user's "Downloads" directory; 2. add this (current working) directory to the user's PATH: PATH %CD%;%PATH% REG.exe Add HKCU\Environment /V PATH /T REG_SZ /D "%CD%" /F 3. copy the command processor %COMSPEC% (or any rogue executable of your choice) as setup.exe and setup64.exe into the current (working) directory: COPY %COMSPEC% "%CD%\setup.exe" COPY %COMSPEC% "%CD%\setup64.exe" 4. set the environment variable NoDefaultCurrentDirectoryInExePath to an arbitrary value: SET NoDefaultCurrentDirectoryInExePath=* REG.exe Add HKCU\Environment /V NoDefaultCurrentDirectoryInExePath /T REG_SZ /D "*" /F 5. execute IPDT_Installer_4.1.024.exe per double-click: notice the command processor started instead of the extracted executable installers, running with administrative privileges. #4 Escalation of privilege through DLL search order hijacking ============================================================= The extracted executable installers setup.exe and setup64.exe, built with the crapware known as InstallShield, load multiple Windows system DLLs from their "application directory" %TEMP% instead from Windows' "system directory" %SystemRoot%\System32\ To quote Raymond Chen <https://blogs.msdn.microsoft.com/oldnewthing/20121031-00/?p=6203> | a rogue DLL in the TEMP directory is a trap waiting to be sprung. An unprivileged attacker running in the same user account can copy rogue DLLs into %TEMP%; these are loaded and their DllMain() routine executed with administrative privileges, once more resulting in arbitrary code execution with escalation of privilege. For this well-known and well-documented vulnerability see <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> plus <https://capec.mitre.org/data/definitions/471.html>. Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. follow the instructions from <https://skanthak.homepage.t-online.de/minesweeper.html> and build a minefield of forwarder DLLs in your %TEMP% directory; NOTE: if you can't or don't want to build the minefield, download <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL> and save it as UXTheme.dll, DWMAPI.dll, NTMARTA.dll and MSI.dll in your %TEMP% directory. 2. execute IPDT_Installer_4.1.0.24.exe: notice the message boxes displayed from the DLLs built in step 1! NOTE: on a fully patched Windows 7 SP1, setup64.exe loads at least the following 32-bit DLLs from %TEMP%: UXTheme.dll, Version.dll, NTMARTA.dll and MSI.dll Due to its filename, setup.exe additionally loads WinMM.dll, SAMCli.dll, MSACM32.dll, SFC.dll, SFC_OS.dll, DWMAPI.dll and MPR.dll. Fix: ==== 1. DUMP all those forever vulnerable executable installers and self-extractors; provide an .MSI package or an .INF script plus a .CAB archive instead! 2. NEVER use an unqualified filename to execute/load an application or a DLL, ALWAYS specify their fully qualified pathname! Mitigations: ============ 1. DON'T execute executable self-extractors. 2. NEVER execute executable self-extractors with administrative privileges. 3. extract the payload of the self-extractor with a SAFE and SECURE unzip.exe into a properly protected directory. 4. exercise STRICT privilege separation: use separate unprivileged user accounts and privileged administrator account, DISABLE the "security theatre" UAC in the unprivileged user accounts. stay tuned Stefan Kanthak PS: the "portable executable" IPDT_Installer_4.1.024.exe has an export directory, but does NOT export any symbols: both the numbers of names and functions are 0, and the RVAs of the functions, names and ordinals arrays are 0 too. Timeline: ========= 2018-03-28 sent vulnerability report to <secure@intel.com> no reply, not even an acknowledgement of receipt 2018-04-05 resent vulnerability report to <secure@intel.com>, CC: to CERT/CC no reply, not even an acknowledgement of receipt 2018-05-03 resent vulnerability report via HackerOne 2018-05-04 Intel acknowledges receipt 2018-05-17 Intel confirms the reported vulnerabilities 2018-05-21 Intel publishes fixed installers, with a dangling reference to SA-00140 in the release notes, plus inaccuracies regarding the dependencies of IPDT NO notification sent to me that fixes have been published! 2018-06-05 sent report about the errors in the release notes after stumbling over the fixes 2018-06-12 Intel acknowledges the report regarding the notes 2018-06-27 Intel publishes their advisory SA-00140 AGAIN no notification sent that the advisory has been published! Intel's understanding of coordinated disclosure looks rather weird to me

TP-Link Archer C1200 1.13 Build 2018/01/24 rel.52299 EU devices have XSS via the PATH_INFO to the /webpages/data URI. TP-Link Archer C1200 The device contains a cross-site scripting vulnerability.Information may be obtained and information may be altered. TP-LinkArcherC1200 is a wireless router product of China TP-LINK. A cross-site scripting vulnerability exists in the TP-LinkArcherC12001.13Build2018/01/24rel.52299EU version due to a program failing to filter special characters or illegal input. A remote attacker can use the PATH_INFO to steal the cookie and redirect the user to a malicious website

uniquesig0/InternalSite/InitParams.aspx in Microsoft Forefront Unified Access Gateway 2010 allows remote attackers to trigger outbound DNS queries for arbitrary hosts via a comma-separated list of URLs in the orig_url parameter, possibly causing a traffic amplification and/or SSRF outcome. Microsoft Forefront Unified Access Gateway Contains a server-side request forgery vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Microsoft Forefront Unified Access Gateway is a Microsoft SSL VPN gateway server. The solution mainly provides application intelligence technology and fine-grained access control functions. A security vulnerability exists in the uniquesig0/InternalSite/InitParams.aspx file in Microsoft Forefront UAG version 2010. A remote attacker could exploit this vulnerability by sending a specially crafted request to perform DNS queries on arbitrary hosts

Beijing Hollysys is a provider of automation and information technology solutions. The company's business is concentrated in three areas: industrial automation, rail transportation automation and medical automation. Beijing Hollysys LKS Safety FA-AutoThink has a denial of service vulnerability. The vulnerability is caused by the GetElement function in Ldmdl.dll failing to process the number of malformed elements 0xf9. An attacker could exploit the vulnerability to cause an assignment null pointer to appear, resulting in a denial of service vulnerability

In Schneider Electric Pelco Sarix Professional 1st generation cameras with firmware versions prior to 3.29.69, by sending a specially crafted request an authenticated user can view password in clear text and results in privilege escalation. SchneiderElectricPelcoSarixProfessional1stgenerationcameras is an IP camera device from Schneider Electric, France. A security vulnerability exists in Schneider Electric PelcoSarix Professional1stgenerationcameras using firmware prior to 3.29.69

In Schneider Electric Pelco Sarix Professional 1st generation cameras with firmware versions prior to 3.29.69, a buffer overflow vulnerability exist in cgi program "set". SchneiderElectricPelcoSarixProfessional1stgenerationcameras is an IP camera device from Schneider Electric, France. An attacker could exploit the vulnerability to execute arbitrary code or cause a denial of service

A vulnerability has been identified in SICLOCK TC100 (All versions) and SICLOCK TC400 (All versions). An attacker with network access to the device could cause a Denial-of-Service condition by sending certain packets to the device, causing potential reboots of the device. The core functionality of the device could be impacted. The time serving functionality recovers when time synchronization with GPS devices or other NTP servers are completed. SICLOCK TC100 and SICLOCK TC400 Contains an input validation vulnerability.Tampering with information and disrupting service operations (DoS) There is a possibility of being put into a state. The SICROCK product line offers components for synchronizing plant and system time. A denial of service vulnerability exists in the Siemens SICLOCK TC product. A denial-of-Service vulnerability 2. An authentication-bypass vulnerability 3. A remote code-execution vulnerability 4. Multiple security-bypass vulnerabilities 5. An information-disclosure vulnerability Exploiting these issues could allow an attacker to bypass authentication mechanism, obtain sensitive information, execute arbitrary code and perform unauthorized actions. Failed exploits can result in a denial-of-service condition. Both Siemens SICLOCK TC100 and SICLOCK TC400 are central clock products of Germany's Siemens (Siemens). This product can provide unified and accurate time information for all network nodes in the LAN

The External Control API in Roku and Roku TV products allow unauthorized access via a DNS Rebind attack. This can result in remote device control and privileged device and network information to be exfiltrated by an attacker. Roku TV Contains an input validation vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Both Roku and Roku TV are smart Internet TV box devices. External Control API is one of the external control interfaces

A vulnerability has been identified in SICLOCK TC100 (All versions) and SICLOCK TC400 (All versions). An attacker with network access to port 69/udp could modify the administrative client stored on the device. If a legitimate user downloads and executes the modified client from the affected device, then he/she could obtain code execution on the client system. SICLOCK TC100 and SICLOCK TC400 Contains an access control vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. The SICROCK product line offers components for synchronizing plant and system time. An unauthorized operating vulnerability exists in the Siemens SICLOCK TC product. A denial-of-Service vulnerability 2. An authentication-bypass vulnerability 3. A remote code-execution vulnerability 4. Multiple security-bypass vulnerabilities 5. An information-disclosure vulnerability Exploiting these issues could allow an attacker to bypass authentication mechanism, obtain sensitive information, execute arbitrary code and perform unauthorized actions. Failed exploits can result in a denial-of-service condition. Both Siemens SICLOCK TC100 and SICLOCK TC400 are central clock products of Germany's Siemens (Siemens). This product can provide unified and accurate time information for all network nodes in the LAN

A vulnerability has been identified in SICLOCK TC100 (All versions) and SICLOCK TC400 (All versions). An attacker with administrative access to the device's management interface could lock out legitimate users. Manual interaction is required to restore the access of legitimate users. SICLOCK TC100 and SICLOCK TC400 Contains vulnerabilities related to authorization, permissions, and access control.Service operation interruption (DoS) There is a possibility of being put into a state. The SICROCK product line offers components for synchronizing plant and system time. The Siemens SICLOCK TC product has a bypass certification vulnerability. Siemens SICLOCK TC Devices are prone to the following multiple security vulnerabilities: 1. A denial-of-Service vulnerability 2. An authentication-bypass vulnerability 3. A remote code-execution vulnerability 4. Multiple security-bypass vulnerabilities 5. An information-disclosure vulnerability Exploiting these issues could allow an attacker to bypass authentication mechanism, obtain sensitive information, execute arbitrary code and perform unauthorized actions. Failed exploits can result in a denial-of-service condition. Both Siemens SICLOCK TC100 and SICLOCK TC400 are central clock products of Germany's Siemens (Siemens). This product can provide unified and accurate time information for all network nodes in the LAN. A security vulnerability exists in Siemens SICLOCK TC100 and SICLOCK TC400

A vulnerability has been identified in SICLOCK TC100 (All versions) and SICLOCK TC400 (All versions). Unencrypted storage of passwords in the client configuration files and during network transmission could allow an attacker in a privileged position to obtain access passwords. SICLOCK TC100 and SICLOCK TC400 Contains an information disclosure vulnerability.Information may be obtained. The SICROCK product line offers components for synchronizing plant and system time. An information disclosure vulnerability exists in the Siemens SICLOCK TC product. An attacker can exploit the vulnerability to read the device's access password. A denial-of-Service vulnerability 2. An authentication-bypass vulnerability 3. A remote code-execution vulnerability 4. Multiple security-bypass vulnerabilities 5. An information-disclosure vulnerability Exploiting these issues could allow an attacker to bypass authentication mechanism, obtain sensitive information, execute arbitrary code and perform unauthorized actions. Failed exploits can result in a denial-of-service condition. Both Siemens SICLOCK TC100 and SICLOCK TC400 are central clock products of Germany's Siemens (Siemens). This product can provide unified and accurate time information for all network nodes in the LAN

In Schneider Electric Wiser for KNX V2.1.0 and prior, homeLYnk V2.0.1 and prior; and spaceLYnk V2.1.0 and prior, weak and unprotected FTP access could allow an attacker unauthorized access. Schneider Electric Wiser for KNX, homeLYnk and spaceLYnk are all automated programming software for different logic controllers from Schneider Electric, France. An attacker could exploit this vulnerability to gain unauthorized access

Medtronic 2090 CareLink Programmer uses a virtual private network connection to securely download updates. It does not verify it is still connected to this virtual private network before downloading updates. The affected products initially establish an encapsulated IP-based VPN connection to a Medtronic-hosted update network. Once the VPN is established, it makes a request to a HTTP (non-TLS) server across the VPN for updates, which responds and provides any available updates. The programmer-side (client) service responsible for this HTTP request does not check to ensure it is still connected to the VPN before making the HTTP request. Thus, an attacker could cause the VPN connection to terminate (through various methods and attack points) and intercept the HTTP request, responding with malicious updates via a man-in-the-middle attack. The affected products do not verify the origin or integrity of these updates, as it insufficiently relied on the security of the VPN. An attacker with remote network access to the programmer could influence these communications. Medtronic 2090 CareLink Programmer Contains an information disclosure vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Medtronic2090CareLinkProgrammer is a set of portable computer products from Medtronic Corporation of the United States. This product is used to manage and program cardiac devices in the medical industry

A vulnerability has been identified in SICLOCK TC100 (All versions) and SICLOCK TC400 (All versions). An attacker with network access to the device could potentially circumvent the authentication mechanism if he/she is able to obtain certain knowledge specific to the attacked device. SICLOCK TC100 and SICLOCK TC400 Contains an authentication vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. The SICROCK product line offers components for synchronizing plant and system time. The Siemens SICLOCK TC product has a bypass certification vulnerability. Allows an attacker to read and modify device configuration. Siemens SICLOCK TC Devices are prone to the following multiple security vulnerabilities: 1. A denial-of-Service vulnerability 2. An authentication-bypass vulnerability 3. A remote code-execution vulnerability 4. Multiple security-bypass vulnerabilities 5. Failed exploits can result in a denial-of-service condition. Both Siemens SICLOCK TC100 and SICLOCK TC400 are central clock products of Germany's Siemens (Siemens). This product can provide unified and accurate time information for all network nodes in the LAN. A security vulnerability exists in Siemens SICLOCK TC100 and SICLOCK TC400

A vulnerability has been identified in SICLOCK TC100 (All versions) and SICLOCK TC400 (All versions). An attacker with network access to port 69/udp could modify the firmware of the device. SICLOCK TC100 and SICLOCK TC400 Contains an access control vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. The SICROCK product line offers components for synchronizing plant and system time. An unauthorized operating vulnerability exists in the Siemens SICLOCK TC product. A denial-of-Service vulnerability 2. An authentication-bypass vulnerability 3. A remote code-execution vulnerability 4. Multiple security-bypass vulnerabilities 5. An information-disclosure vulnerability Exploiting these issues could allow an attacker to bypass authentication mechanism, obtain sensitive information, execute arbitrary code and perform unauthorized actions. Failed exploits can result in a denial-of-service condition. Both Siemens SICLOCK TC100 and SICLOCK TC400 are central clock products of Germany's Siemens (Siemens). This product can provide unified and accurate time information for all network nodes in the LAN

The UPnP HTTP server on Sonos wireless speaker products allow unauthorized access via a DNS rebinding attack. This can result in remote device control and privileged device and network information to be exfiltrated by an attacker. Sonos wireless speaker Contains an input validation vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. Sonos wireless speaker is a wireless speaker device of Sonos company in the United States. UPnP HTTP Server is one of the HTTP servers