4 ms·
>Of course, in reality, this CVE seems almost un-exploitable in the wild, anyway. How will an exploiter get to the login page in the first place? They'd have to
by spartas 7y ago
>Of course, in reality, this CVE seems almost un-exploitable in the wild, anyway. How will an exploiter get to the login page in the first place? They'd have to know your network password and be in your physical vicinity, or your ISP would have to send traffic to your router's login page from the Internet.
Nope. Not at all. Most router attacks these days are malicious JavaScript (like in ads and trackers) that send HTTP requests to the router from the user's own web browser (already inside the network). No proximity access is needed
https://arstechnica.com/information-technology/2019/07/website-driveby-attacks-on-routers-are-alive-and-well-heres-what-to-do/ https://arstechnica.com/information-technology/2019/07/websi...
- jjeaff 7y agoWould this not also require some sort of exploitable CORS vulnerability?
- peeters 7y agoDepends on the attack and the vulnerability. The article does say this: > The attacks work when routers use weak administrative passwords and are vulnerable to CSRF attacks. Which implies that a cross site request is being made. So e.g. you put a hidden form in a netf1ix.com page whose action is at some URL on the router. The user ends up accidentally posting data to that URL which is not affected by CORS and same-origin.
- chopin 7y agoCORS prevents the JS from seeing the result but it doesn't prevent the sending of the request. This is one of the reasons my internal network is not 192.168.1.1/24 and the router is not 192.168.1.1.
- spartas 7y ago> This is one of the reasons my internal network is not 192.168.1.1/24 and the router is not 192.168.1.1. Do you also disable WebRTC on all clients on your network? An attacker (or script) may be foiled by your non-standard gateway network, but your work in obfuscating the router is wasted if they can get at your client IP address.
- kbenson 7y agoDoesn't CORS generally send an OPTION request first to see if the target site even allows the requests, thus preventing this? That's what I've seen when trying to work around browser CORS limitations.
- rnicholus 7y agoonly for ajax requests that are not "simple", that is requests that cannot be sent w/out JavaScript. The sending of this OPTIONS request is referred to as a pre-flight. A more through description at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- foxylion 7y agoYou can also just do a normal form post request into an invisible iframe that is generated by the attacker's javascript.
- singron 7y agoYou can submit forms without CORS as long as there is no CSRF protection. I don't know what CSRF protection is being used.
- jtaft 7y agoNormal form posts don't require pre-flight requests. DNS rebinding attacks can be used too.