Closed Bug 371598 Opened 17 years ago Closed 4 years ago

drive-by pharming: changing settings on home router without the user's knowledge

Categories

(Core :: Security, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 354493

People

(Reporter: bugzilla.20.bvh, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

Through use of javascript and/or plain http requests (images, links, ...), settings of some broadband routers that use web-based configuration can be modified.
This can lead to various attacks when changes are made to DNS servers (think phishing), DMZ (NAT won't serve as basic firewall anymore), ...


Reproducible: Sometimes

Steps to Reproduce:
1. use a vulnerable router (with default password (note: on philips routers, a password is not required to perform this attack))

2. visit a web page that contains, for example, following code:
<img src=http://192.168.1.1/cgi-bin/setup_dns.exe?page=setup_dns&logout=&dns1_1=208&dns1_2=67&dns1_3=222&dns1_4=222&dns2_1=208&dns2_2=67&dns2_3=220&dns2_4=220>
    -> this sets, on a philips router, the dns servers to opendns.org without asking for a password
note: in the paper on "drive-by pharming" (see additional information) more examples are given (javascript on how to determine the router's ip address, brand and model (through use of images in the configuration page of the router))

Actual Results:  
DNS servers can be changed (leading to phishing attacks) but so can port forwarding rules, DMZ, wireless encryption, changing the firmware of the router, ...

Expected Results:  
Even though this is the responsibility of the router manufacturer and the user (change default password, ...), maybe firefox should prevent web pages from loading scripts/images/... from the ip of the router (or anything on the lan for that matter) if the user has not requested to actually visit http://<ip of router> (note: this does not prevent users from clicking a link that changes configuration...)

Maybe it's better to go to an error page that says "Do you want to change settings of your router?" 

See http://www.symantec.com/avcenter/reference/Driveby_Pharming.pdf 
and http://www.schneier.com/blog/archives/2007/02/driveby_pharmin.html
(and maybe http://it.slashdot.org/article.pl?sid=07/02/16/1421238)

note: I have not yet tested this on other routers that do require password authentication not just for visiting the configuration pages (check this by using for example wireshark(former ethereal) and saving what GET/POST requests are made during configuration. Afterwards, try issuing the same requests from a test html file and see whether configurations have changed.(you all know this, so I don't know why I'm writing this ;) ))

note: changing default passwords and router ip addresses are responsibilities of the user, however, as the past has shown, we can't expect everyone to have done this. As long as vulnerable routers are in use, I feel firefox should do something to prevent users from falling victim of such attacks("pharming") in light of the phishing protection added in 2.0

note: this is the first bug I have filed, I'm in no way an authority on the field of security or bugzilla and I apologize if I have made a mistake by posting this here and hope the proper admins can move this to the proper category. I have chosen to not make this a "confidential bug" since it's more of a feature request.
There is an easy solution to this problem:

Here is an example of a malicious code (harmless because setting a ligitimate DNS):
Visiting a website with the following code will change the DNS entry of a TRENDnet TRW-432BRP router (provided the default password of the router has not been changed):
<script src =
"http://admin:admin@192.168.1.1/wan_poe.cgi?dns1=204.101.251.1">
</script>

Normally, Firefox will not send an HTTP authentication without warning. For example, the javascript code

myWindow=window.open("http://admin:admin@192.168.1.1/restart.cgi",\
"",'width=100,height=100)

will open a warning window with the text:

Confirm
You are about to log into the site "192.168.1.1" with the username "admin"
Cancel/OK

This warning window does not show up if the router is accessed via a <script> tag. My suggestion is to change the software so that the warning window shows up if a <script> tag includes a src that is password-protected. 


Generally, this warning shold always appear if a HTTP authentication code is sent to an address for the first time. 
Unfortunately, not all routers use basic http authentication. The philips router I was talking about earlier authenticates using a request like http://192.168.1.1/cgi-bin/login.exe?pws=PASSWORD.

Even then, this is only necessary to actually visit the configuration pages, not  to make changes using techniques described above. I know not all people use routers this insecure, but I don't know how many people do (this is however the router distributed by the major ISP in my country). 

You suggested the warning window on <script src=...>, malicious requests can also be made using <img src=...> and <href=... (if you can get the  user to click a link).

Also, the brand and model of a router can be discovered by requesting images from the login page unique to each model of router. This way the router can be identified without any http authentication. In the future this may allow attackers to attack specified routers using other means.

Does anyone know an actual use for requesting anything on the LAN unless the user has typed the IP address in the url bar?
(In reply to comment #2)
> Unfortunately, not all routers use basic http authentication. The philips
> router I was talking about earlier authenticates using a request like
> http://192.168.1.1/cgi-bin/login.exe?pws=PASSWORD.
> 
> Even then, this is only necessary to actually visit the configuration pages,
> not  to make changes using techniques described above. I know not all people
> use routers this insecure, but I don't know how many people do (this is however
> the router distributed by the major ISP in my country). 
> 
> You suggested the warning window on <script src=...>, malicious requests can
> also be made using <img src=...> and <href=... (if you can get the  user to
> click a link).
> 
> Also, the brand and model of a router can be discovered by requesting images
> from the login page unique to each model of router. This way the router can be
> identified without any http authentication. In the future this may allow
> attackers to attack specified routers using other means.
> 
> Does anyone know an actual use for requesting anything on the LAN unless the
> user has typed the IP address in the url bar?
> 
A router that accepts cgi commands without password protection is certainly an unacceptable security risk that leaves the user defenceless, but this is not a browser issue. Complain to your ISP, they should change the firmware on their routers. But Mozilla could at least enhance the security of basic HTTP authentification

A firmware update appears to have fixed the login problem (maybe OT but to anyone who'll also update to the latest firmware: it assigns two "physical" ports to belgacom tv so you may want to change that back).

On other routers default passwords remain a problem however... 

How's mozilla's standpoint towards protecting the user against himself? 

(I notice the irony in this since I didn't go looking for a firmware update every month (my isp could've send an email or something))


Depends on bug https://bugzilla.mozilla.org/show_bug.cgi?id=38933 "Warn before using foreign authentication/cookies/POST data"
Blocks: csrf
Status: UNCONFIRMED → NEW
Depends on: 165531
Ever confirmed: true
Product: Firefox → Core
QA Contact: firefox → toolkit
Should also depend on bug 354493 IMHO.
Depends on: 354493
Status: NEW → RESOLVED
Closed: 4 years ago
No longer depends on: 354493
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.