areynold
commented
11 years ago Browsing luci source, it looks like stok is generated in one of these files:
- contrib/luasrcdiet/lua/optlex.lua
- modules/admin-mini/luasrc/controller/mini/index.lua
- modules/admin-full/luasrc/controller/admin/index.lua
- libs/web/luasrc/dispatcher.lua
optlex.lua seems -most- least likely
FINDING ID: iSEC-COMMO13-2
TARGETS: The stok Cross-Site Request Forgery (CSRF) token placed within the site URL such as: http://103.3.0.1/cgi-bin/luci/;stok=60894104183094a30c6967cfc9d4fabc/admin/
DESCRIPTION: The application uses a random stok parameter as a form of Cross-Site Request Forgery (CSRF) protection. This token is stored within the URL and remains static for each admin session. As the token is stored within the URL, it may be leaked within HTTP or Proxy logs and referrer headers.
In addition to possible exposure risks, unauthenticated mesh users can specify applications, which allows a malicious user to directly leak the CSRF token via referer header to a specific host. When the administrator visits the list of pages, their token is exposed as demonstrated in the following example: GET /icon.png HTTP/1.1 Host: www.isecpartners.com Referer: http://103.3.0.1/cgi-bin/luci/;stok=b434bc654cc0056d5572e816d881d83b/admin/commotion/apps Connection: keep-alive
EXPLOIT SCENARIO: An attacker can add an application, setting the host icon to a malicious site. When a Commotion administrator logs in and views their local applications, their browser automatically sends a GET request for the application icon which will include their CSRF token in the referer header. An attacker may be able to leverage this to perform a CSRF attack, made worse by the fact that the current administrator password is not required to set a new value.
This additionally may expose the location and CSRF tokens to third parties such as luci.subsignal.org (shown below). While it is unlikely this host is malicious, this may be called out in a review of the application or if further third parties may be integrated.
SHORT TERM SOLUTION: Investigate methods of moving the CSRF protection into an HTTP Header and using per-form POST values. Additionally, requiring the current administrator password for any sensitive actions can provide a defense in depth against CSRF attacks.
LONG TERM SOLUTION: Consider methods for improving the security of anonymous local-application additions or default to disallowing local application functionality unless enabled by an administrator. This may contribute to a stronger default security posture and reduce the "out of box" attack surface.