As for changing the IP; yes, that may help too, but in some cases it may not be a viable option;
Agreed. It's a half-measure workaround
OB1 wrote:
; referring to the remaining CSRF issue, an idea to help preventing it (aside from changing the admin port) would be modifying the web gui to require another authentication for "write" operation; I mean something like this:
you log on the gui; from that moment on you can browse the settings and so on
if you change one or more settings, as soon as you hit the "write" button, the GUI will popup an auth request and you'll have to reenter the credentials
this way, even if someone tries to play CSRF on an open admin page, the request will be blocked by the auth request; sure, such an approach may be annoying, but at least it may be a butt-saver <g>
I think a better way might be to have a session token passed by a cookie that must be included as part of the URL for any subsequent communication with the Web UI. It could be generated upon authorization and good for a limited period. So you'd just add something like the following to the URL whenever you talk back to the Web UI:
Alternatively, the token could be passed back via GET rather than POST so that its not viewable in the URL at all.
A new token could be passed for every UI page and then verified. It could expire after 5 minutes of no activity (configurable) or whatever. It would take a pretty serious bug in the browser to expose that cookie/form element, and as far as I could tell would make CSRF much harder.
(Note-- I'm not a security expert or anything, so maybe someone could point out a flaw, but seems like it would work.)
now let's try to sum up things which should be added to the admin GUI
* the ability to change the admin port from GUI and something to ENFORCE such a change after the installation
* a security token embedded into the admin URLs
* a check when recalling pages which perform "commit" of changes to ensure the token is present/valid and that the page has been called using the "POST" verb and not the "GET" one
now, if someone would only turn the above into a "request for improvements" and submit it to the developers...
now, if someone would only turn the above into a "request for improvements" and submit it to the developers...
EKO and BS both have PM, if ONE person who understands this (not me)wanted to send them each a message. EKO is also by the forum fairly regularly and might have already seen this. However, a better way to approach it is to submit it as an enhancement in trac. It will get dealt with, one way or another, through trac. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
now, if someone would only turn the above into a "request for improvements" and submit it to the developers...
EKO and BS both have PM, if ONE person who understands this (not me)wanted to send them each a message. EKO is also by the forum fairly regularly and might have already seen this. However, a better way to approach it is to submit it as an enhancement in trac. It will get dealt with, one way or another, through trac.
Murrkf, go for it. Here's basically the description:
ISSUE:
DD-WRT needs a form of session tracking to help fight CSRF attacks. This could work as follows:
1. Upon successful HTTP authentication, DD-WRT generates a session ID (md5 hash of a salted string generated from the authentication datestamp, for example). The session ID is returned to the browser as a cookie with a built-in expiration period. (which could be altered via the Security tab).
2. ALSO-- following successful authorization, all forms could include a HIDDEN form element containing the session ID (ie, POST), or it could be included in the URL as &SESSIONID=WHATEVER (ie, GET). Or just use the cookie. The goal is to track the session across connections.
3. Any "trusted" interaction with the Web Interface should verify the session ID was passed back to the server. The server should ask for authorization to any connection that does not provide the Session ID.
4. The server should invalidate/no longer accept the Session ID token after the expiration period.
Murrkf, go for it. Here's basically the description:
No way! You think I understand this stuff!!! I'm just a HO with a posting problem!
YOU do it. Anyone can open a trac account. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
No way! You think I understand this stuff!!! I'm just a HO with a posting problem!
YOU do it. Anyone can open a trac account.
But- but- you're a GURU! I'm a novice!
"Guru" doesn't mean nothing. Do it. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Besides fixing the exploit Brainslayer could run the server as a different user with less privileges.
I successfully reconfigured my reverse proxy which is running on the router and is in fact the one listening to the Internet for http-requests. If someone is able to hack it he would still be limited in the damage he's able to cause.
The http-server (unlike my proxy) still needs some privileges to do the configuration changes which may take a lot of work to find out.
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=37958&start=30 _________________ Asus RT16N + OTRW
Kingston 4GB USB-disk 128 MB swap + 1.4GB ext3 on /opt + 2 GB ext3 on /mnt
Copperjet 1616 modem in ZipB-config
Asterisk, pixelserv & Pound running on router
Another Asus RT16N as WDS-bridge
Sigh..this create a lot of works not to mention downtime. I've many router, just few days before this all flash to stable build suggested in peacock thread because according to the thread sp1 is not stable enough.
Then I found this! Do I need to upgrade the routers behind the main one (gateway) or just enough with main router only. I wish I can use the firewall rules but then that render chillispot's cgi-bin useless. How about router which I use as wds node only? Need to upgrade also?
Just upgrade the ones that are listening to the Internet (either directly or through a portforward). _________________ Asus RT16N + OTRW
Kingston 4GB USB-disk 128 MB swap + 1.4GB ext3 on /opt + 2 GB ext3 on /mnt
Copperjet 1616 modem in ZipB-config
Asterisk, pixelserv & Pound running on router
Another Asus RT16N as WDS-bridge
Joined: 02 Mar 2009 Posts: 144 Location: Phoenix, Az
Posted: Sun Aug 02, 2009 22:02 Post subject:
Maybe this was already covered.
At the very least, time out the access.
Currently once you authenticate if you leave the browser window open for days browsing other sites and come back it does not ask you for authentication again. This allows anyone to later access the router if the window has not been closed.
At least just time it out. Im sure thats easy to do. _________________ Mikrotik RB450G / 750G / 800 / WRT54G-TM / Ubiquity Bullet2HP / Ubiquity Bullet M5
Joined: 24 Feb 2009 Posts: 2026 Location: Sol System > Earth > USA > Arkansas
Posted: Sun Aug 02, 2009 22:20 Post subject:
That is actually not a bad idea Xymox. Possibly a user configured timeout of no more than 5 minutes. If a person cannot get it done in that amount of time, then a re-authenticate the user. _________________ E3000 22200M KongVPN K26
WRT600n v1.1 refirb mega 18767 BS K24 NEWD2 [not used]
WRT54G v2 16214 BS K24 [access point]
Try Dropbox for syncing files - get 2.5gb online for free by signing up.
Read! Peacock thread
*PLEASE* upgrade PAST v24SP1 or no support.
Joined: 02 Mar 2009 Posts: 144 Location: Phoenix, Az
Posted: Sun Aug 02, 2009 23:14 Post subject:
It does not solve the issue of course, but this could be implemented right away to at least minimize exposure to the time out period. I think. But im no expert.
No matter what,,, it should time out at some interval. I would think this would be very easy to implement by BS or Eko. _________________ Mikrotik RB450G / 750G / 800 / WRT54G-TM / Ubiquity Bullet2HP / Ubiquity Bullet M5