VARIoT IoT vulnerabilities database

Affected products: vendor, model and version
CWE format is 'CWE-number'. Threat type can be: remote or local
Look up free text in title and description

VAR-201512-0402 CVE-2015-6429 Cisco IOS and IOS XE Software IKEv1 State Machine Denial of Service Vulnerability CVSS V2: 5.0
CVSS V3: -
Severity: MEDIUM
The IKEv1 state machine in Cisco IOS 15.4 through 15.6 and IOS XE 3.15 through 3.17 allows remote attackers to cause a denial of service (IPsec connection termination) via a crafted IKEv1 packet to a tunnel endpoint, aka Bug ID CSCuw08236. Vendors have confirmed this vulnerability Bug ID CSCuw08236 It is released as. Supplementary information : CWE Vulnerability type by CWE-19: Data Handling ( Data processing ) Has been identified. http://cwe.mitre.org/data/definitions/19.htmlExpertly crafted tunnel endpoint by third party IKEv1 Service disruption via packets (IPsec Disconnection ) There is a possibility of being put into a state. Cisco IOS is the interconnected network operating system used on most Cisco system routers and network switches. Successful exploits may allow attackers to cause the device to crash, denying service to legitimate users
VAR-201601-0066 CVE-2015-6856 Dell Pre-Boot Authentication Driver Vulnerabilities written in arbitrary physical memory locations CVSS V2: 7.2
CVSS V3: 7.8
Severity: HIGH
Dell Pre-Boot Authentication Driver (PBADRV.sys) 1.0.1.5 allows local users to write to arbitrary physical memory locations and gain privileges via a 0x0022201c IOCTL call. Attackers can exploit this issue to execute arbitrary code in the context of the affected application and gain elevated privileges. Dell Pre-Boot Authentication Driver 1.0.1.5 is vulnerable; other versions may also be affected. The title have been changed to better reflect the underlying component affected
VAR-201703-0266 CVE-2015-5729 plural Samsung Smart TV and Xpress of Soft Access Point Vulnerabilities that capture important information on functions CVSS V2: 5.0
CVSS V3: 9.8
Severity: CRITICAL
The Soft Access Point (AP) feature in Samsung Smart TVs X10P, X12, X14H, X14J, and NT14U and Xpress M288OFW printers generate weak WPA2 PSK keys, which makes it easier for remote attackers to obtain sensitive information or bypass authentication via a brute-force attack. Samsung SmartTV and Printers are prone to a security vulnerability that may allow attackers to obtain sensitive information. Attackers can exploit this issue with brute-force techniques to obtain passwords that can aid in further attacks. Samsung Smart TVs X10P, etc. are all smart TVs of South Korea's Samsung (Samsung) that integrate network content, Apps applications, AllShare content, search functions, and traditional TV channel lists into one user interface. Soft Access Point (AP) is one of the wireless access functions. There are security vulnerabilities in the Soft AP function of several Samsung products. The following products are affected: Samsung Smart TVs X10P, X12, X14H, X14J, NT14U, Xpress M288OFW. ================================================================ Samsung softap weak random generated password (This affects SmartTV and Printers) ================================================================ Information ********************** Vulnerability Type : Weak password Vulnerable Version : many Severity: Medium Author – Augusto Pereyra CVE-ID: CVE-2015-5729 (waiting) Twitter: @aedpereyra Description *********************** Samsung SoftAP WPA2-PSK weak password randomly generated. It’s possible intersept wpa2-psk handshake and crack the password using aircrack in a few hours Detailed description ************************** http://kaoticoneutral.blogspot.com.ar/2015/12/samsung-smarttv-and-printers-weak.html Severity Level: ========================================================= Medium Description: ========================================================== Vulnerable Product: [+] Samsung Smartvs with wifi included (Some of this firmware could be in process) Model Firmware patched X10P EU T-MST10PDEUCB-1210.0 X10P US T-MST10PAUSCB-1300.0 X10P US T-MST10PAUSCP-1302.0 X10P IBR T-MST10PIBRCB-1104.0 X12 EU T-MST12DEUCB-1111.4 X12 US T-MST12AKUCB-1114.0 X14H EU T-MST14DEUCB-1023.0 X14H US T-MST14AKUCB-1100.4 X14H CN T-MST14DCNCB-1010.0 X14J CN T-MS14JDCNCB-1004.2 X14J US T-MS14JAKUCB - 1102.5 X14J EU T-MS14JDEUCB-1018.0 NT14U EU T-NT14UDEUCB-1007.1 NT14U US T-NT14UAKUCB-1008.0 NT14U CN T-NT14UDCNCB-1003.1 [+] May be all printers Xpress series. Confirmed in M288OFW Vulnerable Parameter(s): [+] WPA2 password Advisory Timeline ************************ 20-Jul-2015- Reported 27-Jul-2015- Vendor Response 02-Dec-2015- Vendor Fixed some models 17-Dec-2015- Public disclosed Fixed Version: ***************** All version could be fixed if you read the workaround described in "Detailed Description" Reference ***************** https://samsungtvbounty.com/HallofFame.aspx http://kaoticoneutral.blogspot.com.ar/2015/12/samsung-smarttv-and-printers-weak.html
VAR-201512-0029 CVE-2015-7937 Schneider Electric Modicon M340 PLC BMXNOx and BMXPx Device stack-based buffer overflow vulnerability CVSS V2: 10.0
CVSS V3: -
Severity: HIGH
Stack-based buffer overflow in the GoAhead Web Server on Schneider Electric Modicon M340 PLC BMXNOx and BMXPx devices allows remote attackers to execute arbitrary code via a long password in HTTP Basic Authentication data. Schneider Electric Modicon M340 PLC BMXNOx and BMXPx are programmable controller products from Schneider Electric, France. GoAhead Web Server is one of the embedded web servers. Schneider Electric Modicon M340 is prone to an unspecified stack-based buffer-overflow vulnerability. Failed exploit attempts may crash the application, denying service to legitimate users
VAR-201601-0151 CVE-2015-8597 Blue Coat ProxySG and Advanced Secure Gateway Open redirect vulnerability CVSS V2: 5.8
CVSS V3: 7.4
Severity: HIGH
Open redirect vulnerability in Blue Coat ProxySG 6.5 before 6.5.8.8 and 6.6 and Advanced Secure Gateway (ASG) 6.6 might allow remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a base64-encoded URL in conjunction with a "clear text" one in a coaching page, as demonstrated by "http://www.%humbug-URL%.local/bluecoat-splash-API?%BASE64-URL%.". Supplementary information : CWE Vulnerability type by CWE-601: URL Redirection to Untrusted Site ( Open redirect ) Has been identified. http://cwe.mitre.org/data/definitions/601.htmlA third party " Clear text " Related to base64 Encoded with URL Any user through Web You may be redirected to a site and run a phishing attack. Both BlueCoatSystemsProxySG and AdvancedSecureGateway are secure Web gateway devices from BlueCoatSystems, USA. An attacker can leverage this issue by constructing a crafted URI and enticing a user to follow it. When an unsuspecting victim follows the link, they may be redirected to an attacker-controlled site; this may aid in phishing attacks. Other attacks are possible
VAR-201512-0020 CVE-2015-7927 eWON Cross-Site Scripting Vulnerability

Related entries in the VARIoT exploits database: VAR-E-201510-0004
CVSS V2: 4.3
CVSS V3: 6.1
Severity: MEDIUM
Cross-site scripting (XSS) vulnerability on eWON devices with firmware through 10.1s0 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. eWON is an industrial router product of the Belgian eWON company. eWON are prone to the following security vulnerabilities: 1. Weak session management vulnerability 2. Unauthorized Access Vulnerability 4. HTML-injection vulnerability 5. Plain text password information disclosure vulnerability 6. A security weakness An attacker can exploit these issues to bypass the authentication mechanism and gain unauthorized access, execute attacker-supplied HTML or JavaScript code in the context of the affected site, steal cookie-based authentication credentials, obtain sensitive information, and perform certain unauthorized actions. This may aid in further attacks. *eWON sa Industrial router - Multiple Vulnerabilities* eWON connects the machine across the Internet Breaking the barrier between industrial applications and IT standards, the mission of eWON is to connect industrial machines securely to the Internet, enabling easy remote access and gathering all types of technical data originating from industrial machines. Typical applications within the scope of our mission include remote maintenance, predictive maintenance, remote services, asset management, remote metering, multi-site building management, M2M, and more. *AFFECTED PRODUCTS* The following eWON router firmware versions are affected: *All eWON firmware versions prior to 10.1s0* *Reference* https://ics-cert.us-cert.gov/advisories/ICSA-15-342-01 *Vulnerabilities* *WEAK SESSION MANAGEMENT - FIXED by eWON* CVE-2015-7924 Session remains active even after user performs log off. Session is destroyed only after browser is exited. *CROSS-SITE REQUEST FORGERY ATTACKS - NOT FIXED by eWON* CVE-2015-7925 There is no CSRF token set by the application in any of the forms / pages. Any & all functions can be executed silently without getting validated from authorized user, if / when this issue is exploited. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON says*Verified but won't fix. The current implementation is done by design (the user must be able to submit forms using GET only). As CSRF attack suggests, the user must be already logged on the eWON using its internet browser and the session must thus be valid on user's browser. However eWON IP must also be known by the attacker knowing that the VPN will set another IP each time the victim connects to eWON. The connection to an eWON device is only possible by a secured VPN, a point- to-point LAN or a secured LAN. On their website, eWON describes this issue as following: http://ewon.biz/support/news/support/ewon-security-enhancement-7529-01 Mitigating factors: Many requirements have to be met for a successful attack: The attacker needs a valid login to the eWON. The attacker needs HTTP access to the eWON (e.g. eWON web server exposed to the public Internet). Also connections to eWON devices should in standard use cases only occur through: - a point-to-point LAN, a secured LAN (sniffing the victim IP is not really achievable in these two cases) - or a secured VPN (VPN allocated IP address is then defined by the VPN server). —> eWON team just doesn't understand how CSRF works. And continue to assume the device mgmt portal is accessible ONLY over the VPN, P2P LAN or secured LAN. They clearly have not looked at Shodan and / or publicly accessible portals. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *WEAK RBAC CONTROLS - FIXED by eWON* CVE-2015-7926 The software allows an unauthenticated user to gather information and status of I/O servers through the use of a forged URL. *NOTE*: It should be - *An unauthorized / low-privileged user can perform several unauthorized actions such as reading, updating, & deleting I/O servers, configurations, enabling/disabling I/O servers, & accessing, deleting valid users.* *Scenario* Two users 1. adm - Default privileged user - can perform all administrative functions - full rights - [ v o a c f e h j ] 2. test - newly created user - no rights - no [ v o a c f e h j ] *Issue 1* *It is possible to enumerate valid I/O servers* I/O Server list is a set defined list: MEM cbIOSrvList=0 EWON cbIOSrvList=1 MODBUS cbIOSrvList=2 NETMPI ... SNMP cbIOSrvList=4 DF1 ... FINS ... so on ... & others An unauthorized / unprivileged user can gather information and status of these IO servers in the following manner: *Logged in as ‘test'* Access - http://<IP>/rcgi.bin/Edit1IOSrvForm?cbIOSrvList=0&Ac2on=edit If Response says -> Not Configurable. -> Implies Not a valid I/O If Response says -> Access Denied -> Implies a valid I/O -> Window Title reveals the I/O server type - example, Modbus IO Server Config, DF1 1O Server Config, n so on *Issue 2* *It is possible to modify parameter values of I/O servers directly*Updating the values when logged in as 'test' Change POST request to GET Modify param values http://<IP>/rcgi.bin/EditUsrIOSrvForm?edCfgData=MinInterval%3A10%0D %0AMaxInterval%3A268435459%0D%0AReverseCount %3A0&B1=Update&AST_IOSrvNdx=1 Response -> IO Server config updated. Similarly, other I/O server configuration can be updated. In case an I/O server is not Enabled, it can be enabled and configured with custom values. *Following poc for SNMP I/O Server settings (This IO server communicates with any SNMP device)* Enabling and configuring SNMP I/O server (logged in as test) http://<IP>/rcgi.bin/EditAdvUsrIOSrvForm? edEnabledA=1&edGlobAddrA=&edPeriodA=&edGlobAddrB=&edPeriodB=&edGlo bAddrC=&edPeriodC=&B1=Update+Config&IOServer=SNMP -> IO Server config updated. *Issue 3* *Deleting All Users* It is possible for a user with no rights to: 1. Enumerate configured users 2. Delete any & all users. HTTP GET request to delete a user (when logged in as 'test') (unauthorized request) http://<IP>/rcgi.bin/EditForm?CB2=3&NbCB=4&Opera2onType=DeleteUser This brings up a confirmation prompt validating if we really want to delete the user. It presents the username and offers two options - Option 1 - Cancel and Confirm/Delete Option 2 - Select Confirm/Delete ..... Users List test Please confirm you want to delete these items Select Confirm/Delete ..... Next, the url redirects to DeleteForm which then shows Access denied twice ..... -> But the user gets deleted anyway. :) Verify by Refreshing User List *Enumerating Users* In order to enumerate valid users, we only need to submit the first DeleteUser request http://<IP>/rcgi.bin/EditForm?CB2=4&NbCB=3&Opera2onType=DeleteUser It will show the username. This process can of course be automated to view all valid application usernames. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON considered WEAK RBAC issue a minor one. Apparently, they didn’t understood the impact at all.* eWON said: It's a minor issue as these informations are already available through eWON User Manual. We will however completely block the page in a future eWON firmware release when user credentials don't meet the requirements to avoid any ambiguity regarding eWON security. —> Regardless, the new firmware says this issue has been fixed.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *STORED CROSS-SITE SCRIPTING - NOT FIXED by eWON* CVE-2015-7927 *Vulnerable functions / parameters* Create / Edit User User First Name User Last Name User information Create / Edit Tag Tag Description …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Verified. Won't fix: We left the possibility to include HTML tags or javascript in form fields and form url parameters to meet some specific final user needs. Note that this kind of injection is achievable through FTP upload as everything is saved in the eWON config files. Furthermore all theses XSS exploit also require valid user authentication and rights. —> Yeah, it’s a feature and input validation is a useless practice anyway.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *Reflected XSS - NOT FIXED by eWON* Vulnerable parameter - AST_ErrorMsg http://<IP>/rcgi.bin/wsdForm?sys_Csave=1&AST_ErrorMsg=Success<script>alert("xss-AST_ErrorMsg")</ script>&sys_IpMbsSrvPort=502&sys_IpEipSrvPort=44818&sys_IpIsoSrvPort=102& sys_IpFinsSrvPort=9600&sys_TagPollMode=0&sys_IOTcpDefTO=1000&btUpdate= Update *PASSWORDS NOT SECURED - PARTIAL FIX by eWON* CVE-2015-7928 Passwords are passed in plain text allowing a malicious party to retrieve them from network traffic. The autocomplete setting of some eWON forms also allows these passwords to be retrieved from the browser. Compromise of the credentials would allow unauthenticated access. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says 2. Won't fix as the final user is supposed to configure eWON through VPN. —> Yeah, *supposed to*.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *POST/GET ISSUES - NOT FIXED by eWON* CVE-2015-7929 eWON firmware web server allows the use of the HTML command GET in place of POST. GET is less secure because data that are sent are part of the URL. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Won't fix. This could be a problem regarding CRSF (issue B) but the final user is supposed to configure eWON through VPN (and thus https). Mitigating factors: This could be an issue regarding the CSRF attacks described above. However as already mentioned the eWON firmware exposure to CSRF attacks is really limited. Thus having equivalent POST and GET parameters handling for each request sent to the eWON webserver is by extension not problematic. —> Yeah, *supposed to*.. Not problematic... …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. -- Best Regards, Karn Ganeshen
VAR-201512-0021 CVE-2015-7928 eWON Vulnerability to gain access rights in device firmware

Related entries in the VARIoT exploits database: VAR-E-201510-0004
CVSS V2: 5.0
CVSS V3: 8.5
Severity: HIGH
eWON devices with firmware before 10.1s0 do not have an off autocomplete attribute for a password field, which makes it easier for remote attackers to obtain access by leveraging an unattended workstation. eWON is an industrial router product of the Belgian eWON company. A security vulnerability exists in eWON using firmware prior to 10.1s0, which is caused by the program transmitting passwords in clear text. An attacker could exploit the vulnerability to obtain plain text passwords and unauthorized access rights. eWON are prone to the following security vulnerabilities: 1. Weak session management vulnerability 2. A cross-site request forgery vulnerability 3. HTML-injection vulnerability 5. A security weakness An attacker can exploit these issues to bypass the authentication mechanism and gain unauthorized access, execute attacker-supplied HTML or JavaScript code in the context of the affected site, steal cookie-based authentication credentials, obtain sensitive information, and perform certain unauthorized actions. This may aid in further attacks. The vulnerability stems from the fact that the program does not set the auto-complete property for the password field. *eWON sa Industrial router - Multiple Vulnerabilities* eWON connects the machine across the Internet Breaking the barrier between industrial applications and IT standards, the mission of eWON is to connect industrial machines securely to the Internet, enabling easy remote access and gathering all types of technical data originating from industrial machines. Typical applications within the scope of our mission include remote maintenance, predictive maintenance, remote services, asset management, remote metering, multi-site building management, M2M, and more. *AFFECTED PRODUCTS* The following eWON router firmware versions are affected: *All eWON firmware versions prior to 10.1s0* *Reference* https://ics-cert.us-cert.gov/advisories/ICSA-15-342-01 *Vulnerabilities* *WEAK SESSION MANAGEMENT - FIXED by eWON* CVE-2015-7924 Session remains active even after user performs log off. Session is destroyed only after browser is exited. *CROSS-SITE REQUEST FORGERY ATTACKS - NOT FIXED by eWON* CVE-2015-7925 There is no CSRF token set by the application in any of the forms / pages. Any & all functions can be executed silently without getting validated from authorized user, if / when this issue is exploited. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON says*Verified but won't fix. The current implementation is done by design (the user must be able to submit forms using GET only). As CSRF attack suggests, the user must be already logged on the eWON using its internet browser and the session must thus be valid on user's browser. However eWON IP must also be known by the attacker knowing that the VPN will set another IP each time the victim connects to eWON. The connection to an eWON device is only possible by a secured VPN, a point- to-point LAN or a secured LAN. On their website, eWON describes this issue as following: http://ewon.biz/support/news/support/ewon-security-enhancement-7529-01 Mitigating factors: Many requirements have to be met for a successful attack: The attacker needs a valid login to the eWON. The attacker needs HTTP access to the eWON (e.g. eWON web server exposed to the public Internet). Also connections to eWON devices should in standard use cases only occur through: - a point-to-point LAN, a secured LAN (sniffing the victim IP is not really achievable in these two cases) - or a secured VPN (VPN allocated IP address is then defined by the VPN server). —> eWON team just doesn't understand how CSRF works. And continue to assume the device mgmt portal is accessible ONLY over the VPN, P2P LAN or secured LAN. They clearly have not looked at Shodan and / or publicly accessible portals. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *WEAK RBAC CONTROLS - FIXED by eWON* CVE-2015-7926 The software allows an unauthenticated user to gather information and status of I/O servers through the use of a forged URL. *NOTE*: It should be - *An unauthorized / low-privileged user can perform several unauthorized actions such as reading, updating, & deleting I/O servers, configurations, enabling/disabling I/O servers, & accessing, deleting valid users.* *Scenario* Two users 1. adm - Default privileged user - can perform all administrative functions - full rights - [ v o a c f e h j ] 2. test - newly created user - no rights - no [ v o a c f e h j ] *Issue 1* *It is possible to enumerate valid I/O servers* I/O Server list is a set defined list: MEM cbIOSrvList=0 EWON cbIOSrvList=1 MODBUS cbIOSrvList=2 NETMPI ... SNMP cbIOSrvList=4 DF1 ... FINS ... so on ... & others An unauthorized / unprivileged user can gather information and status of these IO servers in the following manner: *Logged in as ‘test'* Access - http://<IP>/rcgi.bin/Edit1IOSrvForm?cbIOSrvList=0&Ac2on=edit If Response says -> Not Configurable. -> Implies Not a valid I/O If Response says -> Access Denied -> Implies a valid I/O -> Window Title reveals the I/O server type - example, Modbus IO Server Config, DF1 1O Server Config, n so on *Issue 2* *It is possible to modify parameter values of I/O servers directly*Updating the values when logged in as 'test' Change POST request to GET Modify param values http://<IP>/rcgi.bin/EditUsrIOSrvForm?edCfgData=MinInterval%3A10%0D %0AMaxInterval%3A268435459%0D%0AReverseCount %3A0&B1=Update&AST_IOSrvNdx=1 Response -> IO Server config updated. Similarly, other I/O server configuration can be updated. In case an I/O server is not Enabled, it can be enabled and configured with custom values. *Following poc for SNMP I/O Server settings (This IO server communicates with any SNMP device)* Enabling and configuring SNMP I/O server (logged in as test) http://<IP>/rcgi.bin/EditAdvUsrIOSrvForm? edEnabledA=1&edGlobAddrA=&edPeriodA=&edGlobAddrB=&edPeriodB=&edGlo bAddrC=&edPeriodC=&B1=Update+Config&IOServer=SNMP -> IO Server config updated. *Issue 3* *Deleting All Users* It is possible for a user with no rights to: 1. Enumerate configured users 2. Delete any & all users. HTTP GET request to delete a user (when logged in as 'test') (unauthorized request) http://<IP>/rcgi.bin/EditForm?CB2=3&NbCB=4&Opera2onType=DeleteUser This brings up a confirmation prompt validating if we really want to delete the user. It presents the username and offers two options - Option 1 - Cancel and Confirm/Delete Option 2 - Select Confirm/Delete ..... Users List test Please confirm you want to delete these items Select Confirm/Delete ..... Next, the url redirects to DeleteForm which then shows Access denied twice ..... -> But the user gets deleted anyway. :) Verify by Refreshing User List *Enumerating Users* In order to enumerate valid users, we only need to submit the first DeleteUser request http://<IP>/rcgi.bin/EditForm?CB2=4&NbCB=3&Opera2onType=DeleteUser It will show the username. This process can of course be automated to view all valid application usernames. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON considered WEAK RBAC issue a minor one. Apparently, they didn’t understood the impact at all.* eWON said: It's a minor issue as these informations are already available through eWON User Manual. We will however completely block the page in a future eWON firmware release when user credentials don't meet the requirements to avoid any ambiguity regarding eWON security. —> Regardless, the new firmware says this issue has been fixed.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *STORED CROSS-SITE SCRIPTING - NOT FIXED by eWON* CVE-2015-7927 *Vulnerable functions / parameters* Create / Edit User User First Name User Last Name User information Create / Edit Tag Tag Description …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Verified. Won't fix: We left the possibility to include HTML tags or javascript in form fields and form url parameters to meet some specific final user needs. Note that this kind of injection is achievable through FTP upload as everything is saved in the eWON config files. Furthermore all theses XSS exploit also require valid user authentication and rights. —> Yeah, it’s a feature and input validation is a useless practice anyway.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *Reflected XSS - NOT FIXED by eWON* Vulnerable parameter - AST_ErrorMsg http://<IP>/rcgi.bin/wsdForm?sys_Csave=1&AST_ErrorMsg=Success<script>alert("xss-AST_ErrorMsg")</ script>&sys_IpMbsSrvPort=502&sys_IpEipSrvPort=44818&sys_IpIsoSrvPort=102& sys_IpFinsSrvPort=9600&sys_TagPollMode=0&sys_IOTcpDefTO=1000&btUpdate= Update *PASSWORDS NOT SECURED - PARTIAL FIX by eWON* CVE-2015-7928 Passwords are passed in plain text allowing a malicious party to retrieve them from network traffic. The autocomplete setting of some eWON forms also allows these passwords to be retrieved from the browser. Compromise of the credentials would allow unauthenticated access. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says 2. Won't fix as the final user is supposed to configure eWON through VPN. —> Yeah, *supposed to*.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *POST/GET ISSUES - NOT FIXED by eWON* CVE-2015-7929 eWON firmware web server allows the use of the HTML command GET in place of POST. GET is less secure because data that are sent are part of the URL. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Won't fix. This could be a problem regarding CRSF (issue B) but the final user is supposed to configure eWON through VPN (and thus https). Mitigating factors: This could be an issue regarding the CSRF attacks described above. However as already mentioned the eWON firmware exposure to CSRF attacks is really limited. Thus having equivalent POST and GET parameters handling for each request sent to the eWON webserver is by extension not problematic. —> Yeah, *supposed to*.. Not problematic... …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. -- Best Regards, Karn Ganeshen
VAR-201512-0022 CVE-2015-7929 eWON Information Disclosure Vulnerability

Related entries in the VARIoT exploits database: VAR-E-201510-0004
CVSS V2: 5.0
CVSS V3: 4.3
Severity: MEDIUM
eWON devices with firmware through 10.1s0 support unspecified GET requests, which might allow remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer logs, or (3) the browser history. eWON is an industrial router product of the Belgian eWON company. A security vulnerability exists in eWON using firmware prior to 10.1s0, which was caused by the program using an unsafe GET HTML command instead of a POST command. An attacker could exploit the vulnerability to perform unauthorized actions. eWON are prone to the following security vulnerabilities: 1. Weak session management vulnerability 2. A cross-site request forgery vulnerability 3. HTML-injection vulnerability 5. Plain text password information disclosure vulnerability 6. A security weakness An attacker can exploit these issues to bypass the authentication mechanism and gain unauthorized access, execute attacker-supplied HTML or JavaScript code in the context of the affected site, steal cookie-based authentication credentials, obtain sensitive information, and perform certain unauthorized actions. This may aid in further attacks. *eWON sa Industrial router - Multiple Vulnerabilities* eWON connects the machine across the Internet Breaking the barrier between industrial applications and IT standards, the mission of eWON is to connect industrial machines securely to the Internet, enabling easy remote access and gathering all types of technical data originating from industrial machines. Typical applications within the scope of our mission include remote maintenance, predictive maintenance, remote services, asset management, remote metering, multi-site building management, M2M, and more. *AFFECTED PRODUCTS* The following eWON router firmware versions are affected: *All eWON firmware versions prior to 10.1s0* *Reference* https://ics-cert.us-cert.gov/advisories/ICSA-15-342-01 *Vulnerabilities* *WEAK SESSION MANAGEMENT - FIXED by eWON* CVE-2015-7924 Session remains active even after user performs log off. Session is destroyed only after browser is exited. *CROSS-SITE REQUEST FORGERY ATTACKS - NOT FIXED by eWON* CVE-2015-7925 There is no CSRF token set by the application in any of the forms / pages. Any & all functions can be executed silently without getting validated from authorized user, if / when this issue is exploited. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON says*Verified but won't fix. The current implementation is done by design (the user must be able to submit forms using GET only). As CSRF attack suggests, the user must be already logged on the eWON using its internet browser and the session must thus be valid on user's browser. However eWON IP must also be known by the attacker knowing that the VPN will set another IP each time the victim connects to eWON. The connection to an eWON device is only possible by a secured VPN, a point- to-point LAN or a secured LAN. On their website, eWON describes this issue as following: http://ewon.biz/support/news/support/ewon-security-enhancement-7529-01 Mitigating factors: Many requirements have to be met for a successful attack: The attacker needs a valid login to the eWON. The attacker needs HTTP access to the eWON (e.g. eWON web server exposed to the public Internet). Also connections to eWON devices should in standard use cases only occur through: - a point-to-point LAN, a secured LAN (sniffing the victim IP is not really achievable in these two cases) - or a secured VPN (VPN allocated IP address is then defined by the VPN server). —> eWON team just doesn't understand how CSRF works. And continue to assume the device mgmt portal is accessible ONLY over the VPN, P2P LAN or secured LAN. They clearly have not looked at Shodan and / or publicly accessible portals. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *WEAK RBAC CONTROLS - FIXED by eWON* CVE-2015-7926 The software allows an unauthenticated user to gather information and status of I/O servers through the use of a forged URL. *NOTE*: It should be - *An unauthorized / low-privileged user can perform several unauthorized actions such as reading, updating, & deleting I/O servers, configurations, enabling/disabling I/O servers, & accessing, deleting valid users.* *Scenario* Two users 1. adm - Default privileged user - can perform all administrative functions - full rights - [ v o a c f e h j ] 2. test - newly created user - no rights - no [ v o a c f e h j ] *Issue 1* *It is possible to enumerate valid I/O servers* I/O Server list is a set defined list: MEM cbIOSrvList=0 EWON cbIOSrvList=1 MODBUS cbIOSrvList=2 NETMPI ... SNMP cbIOSrvList=4 DF1 ... FINS ... so on ... & others An unauthorized / unprivileged user can gather information and status of these IO servers in the following manner: *Logged in as ‘test'* Access - http://<IP>/rcgi.bin/Edit1IOSrvForm?cbIOSrvList=0&Ac2on=edit If Response says -> Not Configurable. -> Implies Not a valid I/O If Response says -> Access Denied -> Implies a valid I/O -> Window Title reveals the I/O server type - example, Modbus IO Server Config, DF1 1O Server Config, n so on *Issue 2* *It is possible to modify parameter values of I/O servers directly*Updating the values when logged in as 'test' Change POST request to GET Modify param values http://<IP>/rcgi.bin/EditUsrIOSrvForm?edCfgData=MinInterval%3A10%0D %0AMaxInterval%3A268435459%0D%0AReverseCount %3A0&B1=Update&AST_IOSrvNdx=1 Response -> IO Server config updated. Similarly, other I/O server configuration can be updated. In case an I/O server is not Enabled, it can be enabled and configured with custom values. *Following poc for SNMP I/O Server settings (This IO server communicates with any SNMP device)* Enabling and configuring SNMP I/O server (logged in as test) http://<IP>/rcgi.bin/EditAdvUsrIOSrvForm? edEnabledA=1&edGlobAddrA=&edPeriodA=&edGlobAddrB=&edPeriodB=&edGlo bAddrC=&edPeriodC=&B1=Update+Config&IOServer=SNMP -> IO Server config updated. *Issue 3* *Deleting All Users* It is possible for a user with no rights to: 1. Enumerate configured users 2. Delete any & all users. HTTP GET request to delete a user (when logged in as 'test') (unauthorized request) http://<IP>/rcgi.bin/EditForm?CB2=3&NbCB=4&Opera2onType=DeleteUser This brings up a confirmation prompt validating if we really want to delete the user. It presents the username and offers two options - Option 1 - Cancel and Confirm/Delete Option 2 - Select Confirm/Delete ..... Users List test Please confirm you want to delete these items Select Confirm/Delete ..... Next, the url redirects to DeleteForm which then shows Access denied twice ..... -> But the user gets deleted anyway. :) Verify by Refreshing User List *Enumerating Users* In order to enumerate valid users, we only need to submit the first DeleteUser request http://<IP>/rcgi.bin/EditForm?CB2=4&NbCB=3&Opera2onType=DeleteUser It will show the username. This process can of course be automated to view all valid application usernames. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON considered WEAK RBAC issue a minor one. Apparently, they didn’t understood the impact at all.* eWON said: It's a minor issue as these informations are already available through eWON User Manual. We will however completely block the page in a future eWON firmware release when user credentials don't meet the requirements to avoid any ambiguity regarding eWON security. —> Regardless, the new firmware says this issue has been fixed.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *STORED CROSS-SITE SCRIPTING - NOT FIXED by eWON* CVE-2015-7927 *Vulnerable functions / parameters* Create / Edit User User First Name User Last Name User information Create / Edit Tag Tag Description …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Verified. Won't fix: We left the possibility to include HTML tags or javascript in form fields and form url parameters to meet some specific final user needs. Note that this kind of injection is achievable through FTP upload as everything is saved in the eWON config files. Furthermore all theses XSS exploit also require valid user authentication and rights. —> Yeah, it’s a feature and input validation is a useless practice anyway.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *Reflected XSS - NOT FIXED by eWON* Vulnerable parameter - AST_ErrorMsg http://<IP>/rcgi.bin/wsdForm?sys_Csave=1&AST_ErrorMsg=Success<script>alert("xss-AST_ErrorMsg")</ script>&sys_IpMbsSrvPort=502&sys_IpEipSrvPort=44818&sys_IpIsoSrvPort=102& sys_IpFinsSrvPort=9600&sys_TagPollMode=0&sys_IOTcpDefTO=1000&btUpdate= Update *PASSWORDS NOT SECURED - PARTIAL FIX by eWON* CVE-2015-7928 Passwords are passed in plain text allowing a malicious party to retrieve them from network traffic. The autocomplete setting of some eWON forms also allows these passwords to be retrieved from the browser. Compromise of the credentials would allow unauthenticated access. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says 2. Won't fix as the final user is supposed to configure eWON through VPN. —> Yeah, *supposed to*.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. GET is less secure because data that are sent are part of the URL. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Won't fix. This could be a problem regarding CRSF (issue B) but the final user is supposed to configure eWON through VPN (and thus https). Mitigating factors: This could be an issue regarding the CSRF attacks described above. However as already mentioned the eWON firmware exposure to CSRF attacks is really limited. Thus having equivalent POST and GET parameters handling for each request sent to the eWON webserver is by extension not problematic. —> Yeah, *supposed to*.. Not problematic... …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. -- Best Regards, Karn Ganeshen
VAR-201512-0027 CVE-2015-7935 Motorola Solutions MOSCAD IP Gateway Vulnerable to reading arbitrary files CVSS V2: 5.0
CVSS V3: 7.5
Severity: HIGH
Motorola Solutions MOSCAD IP Gateway allows remote attackers to read arbitrary files via unspecified vectors. An attacker can exploit these vulnerabilities to obtain potentially sensitive information, execute arbitrary script code in the context of the web server process and to perform unauthorized actions in the context of a logged-in user of the affected application. This may aid in other attacks
VAR-201512-0028 CVE-2015-7936 Motorola Solutions MOSCAD SCADA IP Gateway Cross-Site Request Forgery Vulnerability CVSS V2: 6.8
CVSS V3: 7.5
Severity: HIGH
Cross-site request forgery (CSRF) vulnerability in Motorola Solutions MOSCAD IP Gateway allows remote attackers to hijack the authentication of administrators for requests that modify a password. Motorola Solutions MOSCAD SCADA IP Gateway is a set of Web-based management system-based SCADA systems from Motorola Solutions. An attacker can exploit these vulnerabilities to obtain potentially sensitive information, execute arbitrary script code in the context of the web server process and to perform unauthorized actions in the context of a logged-in user of the affected application. This may aid in other attacks. A remote attacker can exploit this vulnerability to change the password
VAR-201512-0400 CVE-2015-6427 Cisco FireSIGHT Management Center In HTTP Vulnerabilities that can bypass the attack detection function CVSS V2: 5.0
CVSS V3: -
Severity: MEDIUM
Cisco FireSIGHT Management Center allows remote attackers to bypass the HTTP attack detection feature and avoid triggering Snort IDS rules via an SSL session that is mishandled after decryption, aka Bug ID CSCux53437. Vendors have confirmed this vulnerability Bug ID CSCux53437 It is released as. Supplementary information : CWE Vulnerability type by CWE-254: Security Features ( Security function ) Has been identified. The Cisco FireSIGHT Management Center is a suite of management software from Cisco, Inc. that supports centralized management of network security and operational features of Cisco ASA and Cisco FirePOWER network security appliances using FirePOWER Services. An attacker can exploit this issue to bypass security restrictions and perform unauthorized actions. This may aid in further attacks
VAR-201512-0401 CVE-2015-6428 Cisco Model DPQ3925 with EDVA Vulnerabilities that capture important information on devices CVSS V2: 5.0
CVSS V3: -
Severity: MEDIUM
Cisco DPQ3925 devices with EDVA r1 Base allow remote attackers to obtain sensitive information via a crafted HTTP request, aka Bug ID CSCuv03958. Cisco Model DPQ3925 with EDVA Devices have vulnerabilities that can capture important information. The Cisco DPQ3925 devices are a wireless router device from Cisco. This issue is tracked by Cisco Bug ID CSCuv03958
VAR-201512-0017 CVE-2015-7924 eWON Vulnerability to gain access rights in device firmware

Related entries in the VARIoT exploits database: VAR-E-201510-0004
CVSS V2: 7.5
CVSS V3: 8.8
Severity: HIGH
eWON devices with firmware before 10.1s0 do not trigger the discarding of browser session data in response to a log-off action, which makes it easier for remote attackers to obtain access by leveraging an unattended workstation. Supplementary information : CWE Vulnerability type by CWE-613: Insufficient Session Expiration ( Incorrect session deadline ) Has been identified. https://cwe.mitre.org/data/definitions/613.htmlA third party may gain access by using an unattended workstation. eWON is an industrial router product of the Belgian eWON company. An attacker could exploit the vulnerability to interact with the device using the same session. eWON are prone to the following security vulnerabilities: 1. A cross-site request forgery vulnerability 3. Unauthorized Access Vulnerability 4. HTML-injection vulnerability 5. Plain text password information disclosure vulnerability 6. A security weakness An attacker can exploit these issues to bypass the authentication mechanism and gain unauthorized access, execute attacker-supplied HTML or JavaScript code in the context of the affected site, steal cookie-based authentication credentials, obtain sensitive information, and perform certain unauthorized actions. This may aid in further attacks. There is a security vulnerability in eWON using firmware 10.0s0 and earlier versions
VAR-201512-0018 CVE-2015-7925 eWON Cross-Site Request Forgery Vulnerability

Related entries in the VARIoT exploits database: VAR-E-201510-0004
CVSS V2: 6.8
CVSS V3: 8.0
Severity: HIGH
Cross-site request forgery (CSRF) vulnerability on eWON devices with firmware through 10.1s0 allows remote attackers to hijack the authentication of administrators for requests that trigger firmware upload, removal of configuration data, or a reboot. eWON is an industrial router product of the Belgian eWON company. An attacker could exploit the vulnerability to perform unauthorized actions with user rights. eWON are prone to the following security vulnerabilities: 1. Weak session management vulnerability 2. Unauthorized Access Vulnerability 4. HTML-injection vulnerability 5. Plain text password information disclosure vulnerability 6. A security weakness An attacker can exploit these issues to bypass the authentication mechanism and gain unauthorized access, execute attacker-supplied HTML or JavaScript code in the context of the affected site, steal cookie-based authentication credentials, obtain sensitive information, and perform certain unauthorized actions. This may aid in further attacks. *eWON sa Industrial router - Multiple Vulnerabilities* eWON connects the machine across the Internet Breaking the barrier between industrial applications and IT standards, the mission of eWON is to connect industrial machines securely to the Internet, enabling easy remote access and gathering all types of technical data originating from industrial machines. Typical applications within the scope of our mission include remote maintenance, predictive maintenance, remote services, asset management, remote metering, multi-site building management, M2M, and more. *AFFECTED PRODUCTS* The following eWON router firmware versions are affected: *All eWON firmware versions prior to 10.1s0* *Reference* https://ics-cert.us-cert.gov/advisories/ICSA-15-342-01 *Vulnerabilities* *WEAK SESSION MANAGEMENT - FIXED by eWON* CVE-2015-7924 Session remains active even after user performs log off. Session is destroyed only after browser is exited. Any & all functions can be executed silently without getting validated from authorized user, if / when this issue is exploited. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON says*Verified but won't fix. The current implementation is done by design (the user must be able to submit forms using GET only). As CSRF attack suggests, the user must be already logged on the eWON using its internet browser and the session must thus be valid on user's browser. However eWON IP must also be known by the attacker knowing that the VPN will set another IP each time the victim connects to eWON. The connection to an eWON device is only possible by a secured VPN, a point- to-point LAN or a secured LAN. On their website, eWON describes this issue as following: http://ewon.biz/support/news/support/ewon-security-enhancement-7529-01 Mitigating factors: Many requirements have to be met for a successful attack: The attacker needs a valid login to the eWON. The attacker needs HTTP access to the eWON (e.g. eWON web server exposed to the public Internet). Also connections to eWON devices should in standard use cases only occur through: - a point-to-point LAN, a secured LAN (sniffing the victim IP is not really achievable in these two cases) - or a secured VPN (VPN allocated IP address is then defined by the VPN server). —> eWON team just doesn't understand how CSRF works. And continue to assume the device mgmt portal is accessible ONLY over the VPN, P2P LAN or secured LAN. They clearly have not looked at Shodan and / or publicly accessible portals. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *WEAK RBAC CONTROLS - FIXED by eWON* CVE-2015-7926 The software allows an unauthenticated user to gather information and status of I/O servers through the use of a forged URL. *NOTE*: It should be - *An unauthorized / low-privileged user can perform several unauthorized actions such as reading, updating, & deleting I/O servers, configurations, enabling/disabling I/O servers, & accessing, deleting valid users.* *Scenario* Two users 1. adm - Default privileged user - can perform all administrative functions - full rights - [ v o a c f e h j ] 2. test - newly created user - no rights - no [ v o a c f e h j ] *Issue 1* *It is possible to enumerate valid I/O servers* I/O Server list is a set defined list: MEM cbIOSrvList=0 EWON cbIOSrvList=1 MODBUS cbIOSrvList=2 NETMPI ... SNMP cbIOSrvList=4 DF1 ... FINS ... so on ... & others An unauthorized / unprivileged user can gather information and status of these IO servers in the following manner: *Logged in as ‘test'* Access - http://<IP>/rcgi.bin/Edit1IOSrvForm?cbIOSrvList=0&Ac2on=edit If Response says -> Not Configurable. -> Implies Not a valid I/O If Response says -> Access Denied -> Implies a valid I/O -> Window Title reveals the I/O server type - example, Modbus IO Server Config, DF1 1O Server Config, n so on *Issue 2* *It is possible to modify parameter values of I/O servers directly*Updating the values when logged in as 'test' Change POST request to GET Modify param values http://<IP>/rcgi.bin/EditUsrIOSrvForm?edCfgData=MinInterval%3A10%0D %0AMaxInterval%3A268435459%0D%0AReverseCount %3A0&B1=Update&AST_IOSrvNdx=1 Response -> IO Server config updated. Similarly, other I/O server configuration can be updated. In case an I/O server is not Enabled, it can be enabled and configured with custom values. *Following poc for SNMP I/O Server settings (This IO server communicates with any SNMP device)* Enabling and configuring SNMP I/O server (logged in as test) http://<IP>/rcgi.bin/EditAdvUsrIOSrvForm? edEnabledA=1&edGlobAddrA=&edPeriodA=&edGlobAddrB=&edPeriodB=&edGlo bAddrC=&edPeriodC=&B1=Update+Config&IOServer=SNMP -> IO Server config updated. *Issue 3* *Deleting All Users* It is possible for a user with no rights to: 1. Enumerate configured users 2. Delete any & all users. HTTP GET request to delete a user (when logged in as 'test') (unauthorized request) http://<IP>/rcgi.bin/EditForm?CB2=3&NbCB=4&Opera2onType=DeleteUser This brings up a confirmation prompt validating if we really want to delete the user. It presents the username and offers two options - Option 1 - Cancel and Confirm/Delete Option 2 - Select Confirm/Delete ..... Users List test Please confirm you want to delete these items Select Confirm/Delete ..... Next, the url redirects to DeleteForm which then shows Access denied twice ..... -> But the user gets deleted anyway. :) Verify by Refreshing User List *Enumerating Users* In order to enumerate valid users, we only need to submit the first DeleteUser request http://<IP>/rcgi.bin/EditForm?CB2=4&NbCB=3&Opera2onType=DeleteUser It will show the username. This process can of course be automated to view all valid application usernames. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON considered WEAK RBAC issue a minor one. Apparently, they didn’t understood the impact at all.* eWON said: It's a minor issue as these informations are already available through eWON User Manual. We will however completely block the page in a future eWON firmware release when user credentials don't meet the requirements to avoid any ambiguity regarding eWON security. —> Regardless, the new firmware says this issue has been fixed.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *STORED CROSS-SITE SCRIPTING - NOT FIXED by eWON* CVE-2015-7927 *Vulnerable functions / parameters* Create / Edit User User First Name User Last Name User information Create / Edit Tag Tag Description …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Verified. Won't fix: We left the possibility to include HTML tags or javascript in form fields and form url parameters to meet some specific final user needs. Note that this kind of injection is achievable through FTP upload as everything is saved in the eWON config files. —> Yeah, it’s a feature and input validation is a useless practice anyway.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *Reflected XSS - NOT FIXED by eWON* Vulnerable parameter - AST_ErrorMsg http://<IP>/rcgi.bin/wsdForm?sys_Csave=1&AST_ErrorMsg=Success<script>alert("xss-AST_ErrorMsg")</ script>&sys_IpMbsSrvPort=502&sys_IpEipSrvPort=44818&sys_IpIsoSrvPort=102& sys_IpFinsSrvPort=9600&sys_TagPollMode=0&sys_IOTcpDefTO=1000&btUpdate= Update *PASSWORDS NOT SECURED - PARTIAL FIX by eWON* CVE-2015-7928 Passwords are passed in plain text allowing a malicious party to retrieve them from network traffic. The autocomplete setting of some eWON forms also allows these passwords to be retrieved from the browser. Compromise of the credentials would allow unauthenticated access. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says 2. Won't fix as the final user is supposed to configure eWON through VPN. —> Yeah, *supposed to*.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *POST/GET ISSUES - NOT FIXED by eWON* CVE-2015-7929 eWON firmware web server allows the use of the HTML command GET in place of POST. GET is less secure because data that are sent are part of the URL. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Won't fix. This could be a problem regarding CRSF (issue B) but the final user is supposed to configure eWON through VPN (and thus https). Mitigating factors: This could be an issue regarding the CSRF attacks described above. However as already mentioned the eWON firmware exposure to CSRF attacks is really limited. Thus having equivalent POST and GET parameters handling for each request sent to the eWON webserver is by extension not problematic. —> Yeah, *supposed to*.. Not problematic... …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. -- Best Regards, Karn Ganeshen
VAR-201512-0019 CVE-2015-7926 eWON Vulnerabilities that can capture important information in device firmware

Related entries in the VARIoT exploits database: VAR-E-201510-0004
CVSS V2: 5.0
CVSS V3: 9.9
Severity: CRITICAL
eWON devices with firmware before 10.1s0 omit RBAC for I/O server information and status requests, which allows remote attackers to obtain sensitive information via an unspecified URL. eWON is an industrial router product of the Belgian eWON company. A security vulnerability exists in eWON using firmware prior to 10.1s0. Weak session management vulnerability 2. A cross-site request forgery vulnerability 3. Unauthorized Access Vulnerability 4. HTML-injection vulnerability 5. Plain text password information disclosure vulnerability 6. A security weakness An attacker can exploit these issues to bypass the authentication mechanism and gain unauthorized access, execute attacker-supplied HTML or JavaScript code in the context of the affected site, steal cookie-based authentication credentials, obtain sensitive information, and perform certain unauthorized actions. This may aid in further attacks. *eWON sa Industrial router - Multiple Vulnerabilities* eWON connects the machine across the Internet Breaking the barrier between industrial applications and IT standards, the mission of eWON is to connect industrial machines securely to the Internet, enabling easy remote access and gathering all types of technical data originating from industrial machines. Typical applications within the scope of our mission include remote maintenance, predictive maintenance, remote services, asset management, remote metering, multi-site building management, M2M, and more. *AFFECTED PRODUCTS* The following eWON router firmware versions are affected: *All eWON firmware versions prior to 10.1s0* *Reference* https://ics-cert.us-cert.gov/advisories/ICSA-15-342-01 *Vulnerabilities* *WEAK SESSION MANAGEMENT - FIXED by eWON* CVE-2015-7924 Session remains active even after user performs log off. Session is destroyed only after browser is exited. *CROSS-SITE REQUEST FORGERY ATTACKS - NOT FIXED by eWON* CVE-2015-7925 There is no CSRF token set by the application in any of the forms / pages. Any & all functions can be executed silently without getting validated from authorized user, if / when this issue is exploited. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON says*Verified but won't fix. The current implementation is done by design (the user must be able to submit forms using GET only). As CSRF attack suggests, the user must be already logged on the eWON using its internet browser and the session must thus be valid on user's browser. However eWON IP must also be known by the attacker knowing that the VPN will set another IP each time the victim connects to eWON. The connection to an eWON device is only possible by a secured VPN, a point- to-point LAN or a secured LAN. On their website, eWON describes this issue as following: http://ewon.biz/support/news/support/ewon-security-enhancement-7529-01 Mitigating factors: Many requirements have to be met for a successful attack: The attacker needs a valid login to the eWON. The attacker needs HTTP access to the eWON (e.g. eWON web server exposed to the public Internet). Also connections to eWON devices should in standard use cases only occur through: - a point-to-point LAN, a secured LAN (sniffing the victim IP is not really achievable in these two cases) - or a secured VPN (VPN allocated IP address is then defined by the VPN server). —> eWON team just doesn't understand how CSRF works. And continue to assume the device mgmt portal is accessible ONLY over the VPN, P2P LAN or secured LAN. They clearly have not looked at Shodan and / or publicly accessible portals. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *NOTE*: It should be - *An unauthorized / low-privileged user can perform several unauthorized actions such as reading, updating, & deleting I/O servers, configurations, enabling/disabling I/O servers, & accessing, deleting valid users.* *Scenario* Two users 1. adm - Default privileged user - can perform all administrative functions - full rights - [ v o a c f e h j ] 2. test - newly created user - no rights - no [ v o a c f e h j ] *Issue 1* *It is possible to enumerate valid I/O servers* I/O Server list is a set defined list: MEM cbIOSrvList=0 EWON cbIOSrvList=1 MODBUS cbIOSrvList=2 NETMPI ... SNMP cbIOSrvList=4 DF1 ... FINS ... so on ... & others An unauthorized / unprivileged user can gather information and status of these IO servers in the following manner: *Logged in as ‘test'* Access - http://<IP>/rcgi.bin/Edit1IOSrvForm?cbIOSrvList=0&Ac2on=edit If Response says -> Not Configurable. -> Implies Not a valid I/O If Response says -> Access Denied -> Implies a valid I/O -> Window Title reveals the I/O server type - example, Modbus IO Server Config, DF1 1O Server Config, n so on *Issue 2* *It is possible to modify parameter values of I/O servers directly*Updating the values when logged in as 'test' Change POST request to GET Modify param values http://<IP>/rcgi.bin/EditUsrIOSrvForm?edCfgData=MinInterval%3A10%0D %0AMaxInterval%3A268435459%0D%0AReverseCount %3A0&B1=Update&AST_IOSrvNdx=1 Response -> IO Server config updated. Similarly, other I/O server configuration can be updated. In case an I/O server is not Enabled, it can be enabled and configured with custom values. *Following poc for SNMP I/O Server settings (This IO server communicates with any SNMP device)* Enabling and configuring SNMP I/O server (logged in as test) http://<IP>/rcgi.bin/EditAdvUsrIOSrvForm? edEnabledA=1&edGlobAddrA=&edPeriodA=&edGlobAddrB=&edPeriodB=&edGlo bAddrC=&edPeriodC=&B1=Update+Config&IOServer=SNMP -> IO Server config updated. *Issue 3* *Deleting All Users* It is possible for a user with no rights to: 1. Enumerate configured users 2. Delete any & all users. HTTP GET request to delete a user (when logged in as 'test') (unauthorized request) http://<IP>/rcgi.bin/EditForm?CB2=3&NbCB=4&Opera2onType=DeleteUser This brings up a confirmation prompt validating if we really want to delete the user. It presents the username and offers two options - Option 1 - Cancel and Confirm/Delete Option 2 - Select Confirm/Delete ..... Users List test Please confirm you want to delete these items Select Confirm/Delete ..... Next, the url redirects to DeleteForm which then shows Access denied twice ..... -> But the user gets deleted anyway. :) Verify by Refreshing User List *Enumerating Users* In order to enumerate valid users, we only need to submit the first DeleteUser request http://<IP>/rcgi.bin/EditForm?CB2=4&NbCB=3&Opera2onType=DeleteUser It will show the username. This process can of course be automated to view all valid application usernames. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *eWON considered WEAK RBAC issue a minor one. Apparently, they didn’t understood the impact at all.* eWON said: It's a minor issue as these informations are already available through eWON User Manual. We will however completely block the page in a future eWON firmware release when user credentials don't meet the requirements to avoid any ambiguity regarding eWON security. —> Regardless, the new firmware says this issue has been fixed.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *STORED CROSS-SITE SCRIPTING - NOT FIXED by eWON* CVE-2015-7927 *Vulnerable functions / parameters* Create / Edit User User First Name User Last Name User information Create / Edit Tag Tag Description …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Verified. Won't fix: We left the possibility to include HTML tags or javascript in form fields and form url parameters to meet some specific final user needs. Note that this kind of injection is achievable through FTP upload as everything is saved in the eWON config files. Furthermore all theses XSS exploit also require valid user authentication and rights. —> Yeah, it’s a feature and input validation is a useless practice anyway.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *Reflected XSS - NOT FIXED by eWON* Vulnerable parameter - AST_ErrorMsg http://<IP>/rcgi.bin/wsdForm?sys_Csave=1&AST_ErrorMsg=Success<script>alert("xss-AST_ErrorMsg")</ script>&sys_IpMbsSrvPort=502&sys_IpEipSrvPort=44818&sys_IpIsoSrvPort=102& sys_IpFinsSrvPort=9600&sys_TagPollMode=0&sys_IOTcpDefTO=1000&btUpdate= Update *PASSWORDS NOT SECURED - PARTIAL FIX by eWON* CVE-2015-7928 Passwords are passed in plain text allowing a malicious party to retrieve them from network traffic. The autocomplete setting of some eWON forms also allows these passwords to be retrieved from the browser. Compromise of the credentials would allow unauthenticated access. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says 2. Won't fix as the final user is supposed to configure eWON through VPN. —> Yeah, *supposed to*.. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. *POST/GET ISSUES - NOT FIXED by eWON* CVE-2015-7929 eWON firmware web server allows the use of the HTML command GET in place of POST. GET is less secure because data that are sent are part of the URL. …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. eWON says Won't fix. This could be a problem regarding CRSF (issue B) but the final user is supposed to configure eWON through VPN (and thus https). Mitigating factors: This could be an issue regarding the CSRF attacks described above. However as already mentioned the eWON firmware exposure to CSRF attacks is really limited. Thus having equivalent POST and GET parameters handling for each request sent to the eWON webserver is by extension not problematic. —> Yeah, *supposed to*.. Not problematic... …..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..…..….. -- Best Regards, Karn Ganeshen
VAR-201512-0622 No CVE Multiple Cross-site Scripting Vulnerabilities in EUR CVSS V2: 3.5
CVSS V3: -
Severity: Low
Multiple cross-site scripting vulnerabilities were found in EUR.Remote users can exploit these vulnerabilities to execute malicious scripts.
VAR-201512-0518 CVE-2015-7755 Juniper ScreenOS contains multiple vulnerabilities CVSS V2: 10.0
CVSS V3: 9.8
Severity: HIGH
Juniper ScreenOS 6.2.0r15 through 6.2.0r18, 6.3.0r12 before 6.3.0r12b, 6.3.0r13 before 6.3.0r13b, 6.3.0r14 before 6.3.0r14b, 6.3.0r15 before 6.3.0r15b, 6.3.0r16 before 6.3.0r16b, 6.3.0r17 before 6.3.0r17b, 6.3.0r18 before 6.3.0r18b, 6.3.0r19 before 6.3.0r19b, and 6.3.0r20 before 6.3.0r21 allows remote attackers to obtain administrative access by entering an unspecified password during a (1) SSH or (2) TELNET session. Juniper Networks ScreenOS versions 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 allow for an attacker to monitor and decrypt VPN traffic. ScreenOS is an operating system developed by Juniper Networks in the United States, and it mainly runs on the NetScreen series of firewall products. Successful exploits may allow an attacker to obtain sensitive information or gain unauthorized administrative access. This may aid in further attacks
VAR-201512-0399 CVE-2015-6426 Cisco Prime Network Services Controller Vulnerable to access restrictions CVSS V2: 7.2
CVSS V3: -
Severity: HIGH
Cisco Prime Network Services Controller 3.0 allows local users to bypass intended access restrictions and execute arbitrary commands via additional parameters to an unspecified command, aka Bug ID CSCus99427. A local attacker can exploit this issue to execute arbitrary commands in the context of the application. This may aid in further attacks. This issue being tracked by Cisco Bug ID CSCus99427. The software automates configuration changes to managed virtual networks through a single interface
VAR-201512-0519 CVE-2015-7756 Juniper ScreenOS contains multiple vulnerabilities CVSS V2: 5.0
CVSS V3: -
Severity: MEDIUM
The encryption implementation in Juniper ScreenOS 6.2.0r15 through 6.2.0r18, 6.3.0r12 before 6.3.0r12b, 6.3.0r13 before 6.3.0r13b, 6.3.0r14 before 6.3.0r14b, 6.3.0r15 before 6.3.0r15b, 6.3.0r16 before 6.3.0r16b, 6.3.0r17 before 6.3.0r17b, 6.3.0r18 before 6.3.0r18b, 6.3.0r19 before 6.3.0r19b, and 6.3.0r20 before 6.3.0r21 makes it easier for remote attackers to discover the plaintext content of VPN sessions by sniffing the network for ciphertext data and conducting an unspecified decryption attack. Juniper Networks ScreenOS versions 6.3.0r17 through 6.3.0r20 allows unauthorized remote administration access to the device. Juniper Networks ScreenOS versions 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 allow for an attacker to monitor and decrypt VPN traffic. ScreenOS is an operating system developed by Juniper Networks, Inc., which runs on the NetScreen family of firewall products. Juniper ScreenOS is prone to an unauthorized-access vulnerability and an information-disclosure vulnerability. Successful exploits may allow an attacker to obtain sensitive information or gain unauthorized administrative access. This may aid in further attacks. A security vulnerability exists in the encryption implementation of Juniper Networks ScreenOS
VAR-201601-0585 CVE-2015-7754 Juniper ScreenOS Denial of service in Japan (DoS) Vulnerability CVSS V2: 9.3
CVSS V3: 8.1
Severity: HIGH
Juniper ScreenOS before 6.3.0r21, when ssh-pka is configured and enabled, allows remote attackers to cause a denial of service (system crash) or execute arbitrary code via crafted SSH negotiation. Juniper ScreenOS is prone to a denial of service vulnerability. An attacker can exploit this issue to crash the affected application; denying service to legitimate users. Due to the nature of this issue, code-execution may be possible but this has not been confirmed. Juniper Networks Juniper ScreenOS is Juniper Networks ( Juniper Networks ) company’s set of operations that operate on NetScreen operating system in series firewalls. Juniper Networks ScreenOS 6.3.0r21 There was a security hole in the previous version