Dsl error micro_httpd

dsl error micro_httpd

Except that neither DNS nor IP were designed to be secure. This attack is concerning because it demonstrates the failure in practice of the encryption and. Server: micro_httpd. Cache-Control: no-cache. Date: Mon, 18:45:31 GMT WWW-Authenticate: Basic realm="DSL Router". WIRELESS ROUTER | HOME D-Link DSL-2252 D-Link GlassFish Server Open Source Edition 4.1.1 - Error report.

Dsl error micro_httpd - are

hacker

turmio

hacker
ms

/VulnCoord (2013)

We are hacking my actively used DSL-modem so some of the details will be on private side. Sorry about that.

/Private

NMAP scans

$ nmap -v -sT -p 1-65535 -A 192.168.1.1 ... Nmap scan report for 192.168.1.1 Host is up (0.019s latency). Not shown: 65525 closed ports PORT STATE SERVICE VERSION 21/tcp open tcpwrapped 22/tcp open ssh Dropbear sshd 0.46 (protocol 2.0)

wayjac

MVM

2011-Jan-29 4:49 pm

but when I attempt to connect to the wan address across the net - I get timed out. No acccess.

The modem may not allow this you may need to use another internet connection for this

In my old Windstream 4300 - I have a menu item to enable remote administration and set a password ... But I don't see a similar menu in the 1704

Click the management link, then the access control, then passwords

actions · 2011-Jan-29 4:49 pm ·

dyanni
join:2003-11-29
Rabun Gap, GA

dyanni

Member

2011-Feb-6 10:18 am

I set the admin password and tested it locally.

( i.e. connected using my ipad that had obtained an ip address directly from the dhcp server on the router. routher is at 192.168.1.1 and iPad was assigned 192.168.1.101 )

Works great - can access the router with no problem.

When I go away from home - and attempt to connect back to the router ( naturally my iPad has picked up an ip address from wherever I am ... dads house, mcdonalds, etc ... )

Does not work. I connect to the router from a remote location - and get prompted to login and password. I use the same login and password that DID work locally and I just keep getting re-prompted.

"The server donnysServer.x.y.z:50580 at DSL Router requires a username and password."
When I enter my username and password - it simply returns to the same prompt asking for my username and password.

I try my known password, the original password, etc etc ... I just keep getting prompted. When I click 'cancel' - I get the pink screen that says:

401 Unauthorized

Authorization required.
micro_httpd

So - I know I AM connecting to the router - it just seems that remote access is not enabled. How do you enable it ?

The cheaper 4300 was nowhere near this much trouble to access.

actions · 2011-Feb-6 10:18 am ·

When I go away from home - and attempt to connect back to the router Does not work. I connect to the router from a remote location - and get prompted to login and password. I use the same login and password that DID work locally and I just keep getting re-prompted

Are you certain you can set the username?
It may be preconfigured
If you have dialup internet access you should use that to test the setup of the remote access

actions · 2011-Feb-7 2:24 pm ·

jeffingato dyanni

Anon

2011-Feb-14 9:03 am

to dyanni

same problem here. I can get internet, but nothing else works on this router. I have spent hours trying to get remote access and port forwarding to work. I have come to the conclusion that these routers are crap. Give me a SS4200 any day.

actions · 2011-Feb-14 9:03 am ·


Windstream
Premium Member
join:2009-03-31
Twinsburg, OH

Instruction to remotely access the 1704 router:

•Go to the 1704 router interface (»192.168.254.254) and go to Management->Access Control in order to setup a new username/password for remote access
•In a web browser, go to »xxx.xxx.xxx.xxx:50580 (the X's being the WAN IP the router is pulling)
•Use the username and password you just setup for remote access

Justin
Senior Technical Specialist
Broadband Tier II

actions · 2011-Feb-14 11:25 am ·


D-Link DSL 320B Password Extractor - Metasploit


This page contains detailed information about how to use the auxiliary/admin/http/dlink_dsl320b_password_extractor metasploit module. For list of all metasploit modules, visit the Metasploit Module Library.

Module Overview


Name: D-Link DSL 320B Password Extractor
Module: auxiliary/admin/http/dlink_dsl320b_password_extractor
Source code: modules/auxiliary/admin/http/dlink_dsl320b_password_extractor.rb
Disclosure date: -
Last modification time: 2017-10-09 17:06:05 +0000
Supported architecture(s): -
Supported platform(s): -
Target service / protocol: http, https
Target network port(s): 80, 443, 3000, 8000, 8008, 8080, 8443, 8880, 8888
List of CVEs: -

This module exploits an authentication bypass vulnerability in D-Link DSL 320B <=v1.23. This vulnerability allows to extract the credentials for the remote management interface.

Module Ranking and Traits


Module Ranking:

  • normal: The exploit is otherwise reliable, but depends on a specific version and can't (or doesn't) reliably autodetect. More information about ranking can be found here.

Basic Usage


Required Options


  • RHOSTS: The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'

Go back to menu.

Msfconsole Usage


Here is how the admin/http/dlink_dsl320b_password_extractor auxiliary module looks in the msfconsole:

Module Options


This is a complete list of options available in the admin/http/dlink_dsl320b_password_extractor auxiliary module:

Advanced Options


Here is a complete list of advanced options supported by the admin/http/dlink_dsl320b_password_extractor auxiliary module:

Auxiliary Actions


This is a list of all auxiliary actions that the admin/http/dlink_dsl320b_password_extractor module can do:

Evasion Options


Here is the full list of possible evasion options supported by the admin/http/dlink_dsl320b_password_extractor auxiliary module in order to evade defenses (e.g. Antivirus, EDR, Firewall, NIDS etc.):

Go back to menu.

Error Messages


This module may fail with the following error messages:

Check for the possible causes from the code snippets below found in the module source code. This can often times help in identifying the root cause of the problem.

<RHOST>:<RPORT> - Default Configuration of DSL 320B detected - no password section available, try admin/admin


Here is a relevant code snippet related to the "<RHOST>:<RPORT> - Default Configuration of DSL 320B detected - no password section available, try admin/admin" error message:

<RHOST>:<RPORT> - Failed to connect to the web server


Here is a relevant code snippet related to the "<RHOST>:<RPORT> - Failed to connect to the web server" error message:

Go back to menu.

Related Pull Requests


References


See Also


Check also the following modules related to this module:

Authors


  • Michael Messner <devnull[at]s3cur1ty.de>

Version


This page has been produced using Metasploit Framework version 6.1.24-dev. For more modules, visit the Metasploit Module Library.

Go back to menu.

UPDATE: My 2750U has kicked the bucket due lightning striking my house, quite a shame, while it wasn't much to look at, it performed very well, R.I.P little modem-router. And so dear reader, I am not able to try out any new firmware versions. That USB port on this model isn't a swift one, so if you can't see it or can't get it to work, my opinion, not something I'd lose sleep over. Have a great day. Love you, fellow human!


The manual doesn't explain this feature in detail, so here is a quick guide on using the Storage Servicefeature on D-Link DSL-2750U.

For firmware SE_1.01

You can see firmware version on the top right corner of the router control panel. On this version, Storage Service is much more direct, I like this a lot more. Here is how it can be accessed.

Windows


Open up any Windows Explorer window like My Computer for example and type the address of your D-Link router, by default its: "\\192.168.1.1"


Use "admin"  for both username and password (without quotes). I did not see anyway to change that, might as well because it gives the impression the drive is secured by user accounts, which is not the case.

Mac


Go to Finder > Go > Connect to Server ...

And enter "SMB:\\192.168.1.1"


Use "admin"  for both username and password (without quotes). I did not see anyway to change that, might as well because it gives the impression the drive is secured by user accounts, which is not the case.

I got both read and write access now, where as on firmware 1.0 it was only read and delete access, I'm not entirely sure if its because I have Fuse and NTFS-3G installed, which are for native writing to NTFS drives. So I guess you'll have to try and see, apologies.

(Everything below is for firmware SE_1.0)


For firmware SE_1.0

On firmware SE_1.0, Storage device is read and delete but not write access if accessed from a Macintosh; on Windows, you can both read and write to the drive.

Step 1

Plug in your USB device into the USB port at the back of the DSL-2750U, you should see the USB indicator light at the front panel light up when it's recognized.

Step 2

Go to the router's administration interface on your computer, access this on your web browser by typing in http://192.168.1.1/

If you didn't update the admin password at all, then the login username and password is the default admin and admin. You can update this under: Maintenance > Access Controls.

Step 3

Now head to Advanced> Storage Service.

There are two links here, click on Storage Device Infofirst, you'll see your USB device listed, make note of the Volumenamefield, like for example: usb1_1.

Step 4

This is the main step, head to Advanced> Storage Service> User Accounts, the screenshot below shows this page.


Create a new user, this will be your account credential when you access your USB storage, create your username and password and fill in the VolumeNameas noted earlier in Step 3.  My Username is sundaymorning and the volumeName is usb1_1. Hit the Apply button and we are done with the admin interface.

Accessing your storage device on both Windows and Mac is pretty easy too, here are the steps.


On Windows XP

Launch Windows Explorer, just any window basically and type in:
\\192.168.1.1\sundaymorning\usb1_1

Note the pattern is: \\ Server Address \ Username \ Volume Name.

You'll be prompted for your login credentials you created earlier in Step 4,  click OK and that's it!

Type in the address any window's address bar (top), the login panel will appear.

Once logged in successfully, you can start browsing the volume!
You can add this address to Favorites or you can go the more advanced route of Mapping the Network Drive, I'm not familiar with Mapping, so for convenience here is a Google search result link if that is what you want to do.



On OS X

This doesn't work well with Macs. On all media and formats I tried, I can read and copy files, even delete files, but could not write to it, the Finder error I get is along the lines of "no space available ..." on the device. Those media I tried were empty, and I can write to them via Windows without problem. Especially the FAT32 formatted USB thumb drive where I can write to it on the Mac if connected directly.

Snow Leopard was my first OS X, but I'm guessing its the same with earlier versions since it is using SMB, I could be wrong. Make sure Finder is selected then choose Go > Connect to Server ... (or Cmd+K), then type in:
smb://192.168.1.1/sundaymorning/usb1_1


Note the pattern is: smb:// Server Address / Username / Volume Name.


Enter the username and password you created in Step 4, click Connect and done!

Type the address here at, Finder menu > Go > Connect to Server ...
then hit the Connect button

Finally, type in your login credentials and hit the Connect button,
if everything is set correctly, the file browser will appear, however it seems to be read only for Macs.

[Updated on Oct 29, 2012 added firmware 1.01 changes]

DSL modem hack used to infect millions with banking fraud malware

AofI

Wise, Aged Ars Veteran

Registered: Apr 3, 2003

Posts: 198

Posted: Mon Oct 01, 2012 11:00 pm

Jason T. Miller wrote:

Quote:

The mass attack is concerning because it successfully targeted devices few of us spend much time trying to secure.



Except that neither DNS nor IP were designed to be secure. This attack is concerning because it demonstrates the failure in practice of the encryption and server authentication protocols (SSL and TLS under the current CA regime) designed to protect users against this sort of threat, and, in particular, the failure of banks (not ISPs, customer site admins, or customers, as these groups have little or no control over the security measures employed by the bank) to successfully leverage these and other technologies to protect their customers against fraud.


In most situations they just changed the DSL router to use modified DNS servers to point the victim to a server where they were tricked into installing key logging/screen capturing type malware. People trust google.com and facebook.com and wouldn't be hesitant about installing something these sites say they should. Once that is done you don't need to circumvent any authentication protocols.

Only thing I think people could be doing to prevent this type of DNS spoofing is to always use the secured URL's for popular sites, EG. https://www.google.comand then be sure to look and see that it's secure?

pavon

Ars Tribunus Militum
et Subscriptor

Tribus: NM

Registered: Feb 26, 2007

Posts: 1959

Posted: Mon Oct 01, 2012 11:19 pm

HedPhuqt wrote:

This requires access to the victim PC before the exploit can take place.


No, it doesn't. I just requires that the victim to:
1) Have logged into the modem configuration page recently.
2) Visit a website with malicious links.
This link then uses the credentials which the browser has stored for the modem to change the configuration settings, possibly even the setting to upload new firmware.

Quote:

Chicken and egg. I'm reading that they were breaking routers to get to PCs.


Once the router has been compromised as above, it can run any sort of MITM attack against all of the user's traffic, including compromising the PC or any accounts they log into.

crosslink

Ars Scholae Palatinae

Registered: Jul 31, 2006

Posts: 765

Posted: Mon Oct 01, 2012 11:22 pm

Excellent comments in this thread. Thanks Arsians.

igor.levicki

Ars Scholae Palatinae

Tribus: Serbia

Registered: Jan 20, 2012

Posts: 1227

Posted: Mon Oct 01, 2012 11:29 pm

Am I the only one eagerly expecting a surge in home-made Brazillian pr0n after this? :)

Chemical Tribe

Ars Legatus Legionis
et Subscriptor

Registered: Aug 13, 2005

Posts: 25266

Posted: Tue Oct 02, 2012 1:04 am

AofI wrote:

Jason T. Miller wrote:

Quote:

The mass attack is concerning because it successfully targeted devices few of us spend much time trying to secure.



Except that neither DNS nor IP were designed to be secure. This attack is concerning because it demonstrates the failure in practice of the encryption and server authentication protocols (SSL and TLS under the current CA regime) designed to protect users against this sort of threat, and, in particular, the failure of banks (not ISPs, customer site admins, or customers, as these groups have little or no control over the security measures employed by the bank) to successfully leverage these and other technologies to protect their customers against fraud.


In most situations they just changed the DSL router to use modified DNS servers to point the victim to a server where they were tricked into installing key logging/screen capturing type malware. People trust google.com and facebook.com and wouldn't be hesitant about installing something these sites say they should. Once that is done you don't need to circumvent any authentication protocols.

Only thing I think people could be doing to prevent this type of DNS spoofing is to always use the secured URL's for popular sites, EG. https://www.google.comand then be sure to look and see that it's secure?



Well for google and all banking sites, it has to be https. And then the browser will throw a warning since it isn't the correct site by checking the certificate.

viljoviitanen

Seniorius Lurkius

Tribus: Jyväskylä, Finland

Registered: Oct 2, 2012

Posts: 26

Posted: Tue Oct 02, 2012 7:54 am

Everyone wondering about the details of the attack (and the kind of inaccuracies of the Ars article), please read one of the linked articles, https://www.securelist.com/en/blog/2081 ... DSL_modems .

Red Herring

Ars Scholae Palatinae

Registered: Jul 21, 2007

Posts: 654

Posted: Tue Oct 02, 2012 8:40 am

Not good at all given how common Broadcom DSL routers are, time to go look for a non-Broadcom one as I don't trust the hardware makers to say if they have fixed it, DSL devices are often neglected by them as well in favour of firmware updates for standalone routers.

brokensyntax

Ars Centurion

Registered: Aug 1, 2012

Posts: 250

Posted: Tue Oct 02, 2012 8:56 am

This is why I always set my own DNS servers manually.

I highly suggest OpenDNS (208.67.222.222 and 208.67.220.220) or one the big companies with easy to remember DNS IP addresses (4.2.2.2

Dsl error micro_httpd - not

COMTREND ADSL Router CT-5367 C01_R12 - Remote Code Execution

Offensive Security The Exploit Database is maintained by Offensive Security, an information security training company that provides various Information Security Certifications as well as high end penetration testing services. The Exploit Database is a non-profit project that is provided as a public service by Offensive Security.

The Exploit Database is a CVE compliant archive of public exploits and corresponding vulnerable software, developed for use by penetration testers and vulnerability researchers. Our aim is to serve the most comprehensive collection of exploits gathered through direct submissions, mailing lists, as well as other public sources, and present them in a freely-available and easy-to-navigate database. The Exploit Database is a repository for exploits and proof-of-concepts rather than advisories, making it a valuable resource for those who need actionable data right away.

The Google Hacking Database (GHDB) is a categorized index of Internet search engine queries designed to uncover interesting, and usually sensitive, information made publicly available on the Internet. In most cases, this information was never meant to be made public but due to any number of factors this information was linked in a web document that was crawled by a search engine that subsequently followed that link and indexed the sensitive information.

The process known as “Google Hacking” was popularized in 2000 by Johnny Long, a professional hacker, who began cataloging these queries in a database known as the Google Hacking Database. His initial efforts were amplified by countless hours of community member effort, documented in the book Google Hacking For Penetration Testers and popularised by a barrage of media attention and Johnny’s talks on the subject such as this early talk recorded at DEFCON 13. Johnny coined the term “Googledork” to refer to “a foolish or inept person as revealed by Google“. This was meant to draw attention to the fact that this was not a “Google problem” but rather the result of an often unintentional misconfiguration on the part of a user or a program installed by the user. Over time, the term “dork” became shorthand for a search query that located sensitive information and “dorks” were included with may web application vulnerability releases to show examples of vulnerable web sites.

After nearly a decade of hard work by the community, Johnny turned the GHDB over to Offensive Security in November 2010, and it is now maintained as an extension of the Exploit Database. Today, the GHDB includes searches for other online search engines such as Bing, and other online repositories like GitHub, producing different, yet equally valuable results.

_ssh-hostkey: 1040 7c:17:56:30:1e:48:96:50:8d:eb:ad:64:c9:93:ed:b4 (RSA) 23/tcp open telnet? 80/tcp open http micro_httpd Avtech AV787 webcam http config/ Host: 101.53.64.73 () Ports: 80/open/tcp//http//Allegro RomPager 4.07 UPnP Avtech AV787 webcam http config/ Host: 101.53.64.52 () Ports: 80/open/tcp//http?/// Host: 101.53.64.53 () Ports: 80/open/tcp//ssl 4.6.6.6 are all functioning DNS servers)

Other DNS servers of course can be found online from various ISPs and very few lock-out non ISP users.

If you don't trust the DNS settings to be set at the modem or router level because you are unfamiliar with the tools available to properly diagnose and monitor said hardware, then you can place the DNS settings directly at the PC level in your NIC settings.

And as much as this affects home users, consider all of the business with WiFi hotspots that are affected by this vulnerability. Coffee shops and hotels rarely have the time or expertise to troubleshoot an issue like this, and leaves hundreds of customers per day vulnerable.

If you have a laptop and you travel from public WiFi to public WiFi, you never know what has happened to it. For gods sake, use your own DNS servers, use SSL wherever possible (https://www.google.ca, https://www.facebook.com, etc.) If you have a proxy or VPN available to you through home or work, use that!

Only you can protect your online data.



I myself use open DNS, but I fail to see how this would protect me from an attack that targets my router itself. If they can change the DNS settings to what they want then it really doesn't matter what my DNS settings were in the first place.
Also, if this attack can steal bank login credentials it could also steal your VPN credentials too!
The only suggestion about securing against this kind of attack that makes any sense to me is disabling the remote login feature on the router ( mine is by default but maybe others aren't). At least until the method used is reported in more detail.

HedPhuqt

Ars Tribunus Militum

Registered: Jan 24, 2000

Posts: 2060

Posted: Tue Oct 02, 2012 2:25 pm

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.
3. Another script runs that logs into and configures the router.
4. Attackers wait for user to do something.
5. User enters www.facebook.com into their browser.
6. User resolves facebook.com to evil webhost (see step 3).
7. User is prompted to install "Java upgrade for enhanced experience," but gets a keylogger instead.
8. Pay day rolls around and user browses to their bank.
9. Keylogger logs key strokes and sends bank credentials for user to john.

kakao

Seniorius Lurkius

Tribus: Brasília, Brazil

Registered: Mar 10, 2005

Posts: 42

Posted: Tue Oct 02, 2012 2:33 pm

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.

Z1ggy

Ars Legatus Legionis

Tribus: New York

Registered: Jun 6, 2009

Posts: 14721

Posted: Tue Oct 02, 2012 3:16 pm

ads2 wrote:

Z1ggy wrote:

Adam Starkey wrote:

Ahh, looking at the advisory, it seems like a standard default username/password attack.

Are modem makers really still doing this?


my mother got a new modem from her cable company last year, the username/password is on the outside of the box.
I changed the password the first chance i had while setting her up.

then i had to write it down for her. :(


why does writing down a rarely used password make a frowny face?
it seems like as perfectly reasonable thing to do, unless your mom had Russian mobsters wandering through her home office.

because its on her computer in a text document labeled passwords. and its not the only thing in there. and my older sister has access to the network and has terible decision making skills when it comes to clicking on links.

Bokononist

Seniorius Lurkius

Registered: Sep 26, 2012

Posts: 35

Posted: Tue Oct 02, 2012 3:20 pm

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?

PBOM

Smack-Fu Master, in training

Registered: Nov 25, 2009

Posts: 74

Posted: Tue Oct 02, 2012 3:46 pm

I have some firsthand experience with something similar. We bought a bunch of generic broadmax/broadcom modem/router combos in bulk for our ADSL subscribers. We would configure the units in house before sending them out to the field for self or assisted installation, and we would almost always leave the web interface open so we could remotely manage/test the units once they came online. The routers would pull a static IP address and name servers during the whole PPPoE coconut dance.

The router for my home drop (free intertubes == win) was a static setup with a /29 assigned on the "LAN" side to accomodate multiple devices behind it. Long story short, the DNS switcheroo didn't really do anything to me, but I noticed the weird DNS server entries and a badly configured port forward in the DSL router's web interface during a test one night. We found maybe 20-30 similar cases in the field that next week, but none of the routers had the default usernames or passwords configured. My router had a unique username/password given to it so nobody else could get in, so imagine my surprise when I found it weirding out. Mind you, this was something like 7-8 years ago, so I'm kind of fuzzy on all of the specific details.

Some access filters, duct tape, and three hedgehogs later, we had it all cleaned up. I think the next month we switched to a different vendor for CPE and took some other precautions to prevent a similar incident. It's not always a simple as "block teh port 80." We wanted to leave the customer ranges as open as possible. If someone wanted to run a little website out of is closet, awesome! I think we tossed /30 blocks out to our more serious customers anyhow, especially the folks we had known for a long time.

That job was a lot more fun than the one I have now. The things we do to pay the bills. :/

tedsofbeverlyhills

Ars Praetorian

Registered: Nov 7, 2007

Posts: 438

Posted: Tue Oct 02, 2012 4:06 pm

Still not as good as Dick Assman.

kakao

Seniorius Lurkius

Tribus: Brasília, Brazil

Registered: Mar 10, 2005

Posts: 42

Posted: Tue Oct 02, 2012 4:10 pm

Bokononist wrote:

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?


Yes you are safe from THATexploit used on the shown code. If the web interface is exposed to the internet then make sure the password is strong.

HedPhuqt

Ars Tribunus Militum

Registered: Jan 24, 2000

Posts: 2060

Posted: Tue Oct 02, 2012 4:15 pm

kakao wrote:

Bokononist wrote:

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?


Yes you are safe from THATexploit used on the shown code. If the web interface is exposed to the internet then make sure the password is strong.



No.

Quote:

Even if you have a strong password configured on the device, the flaw allows an attacker to access the control panel, capture the password, log into the device and make changes.




Code:

[email protected]:~#  get.pl http://192.168.1.1/password.cgi   ## Information Disclosure
 
/*HTTP/1.1 200 Ok
Cache-Control: no-cache
Connection: close
Date: Mon, 03 Jan 2000 23:01:25 GMT
Server: micro_httpd
Content-Type: text/html
 
<html>
   <head>
      <meta HTTP-EQUIV='Pragma' CONTENT='no-cache'>
      <link rel="stylesheet" href='stylemain.css' type='text/css'>
         <link rel="stylesheet" href='colors.css' type='text/css'>
            <script language="javascript" src="util.js"></script>
            <script language="javascript">
<!-- hide\n                               ## Dammit! =))
pwdAdmin = '<CENSORED>';                  ## Censored Password
pwdSupport = '<CENSORED>';                ## Censored Password
pwdUser = '<CENSORED>';\n                 ## Censored Password
*/



source

kakao

Seniorius Lurkius

Tribus: Brasília, Brazil

Registered: Mar 10, 2005

Posts: 42

Posted: Tue Oct 02, 2012 4:50 pm

HedPhuqt wrote:

kakao wrote:

Bokononist wrote:

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?


Yes you are safe from THATexploit used on the shown code. If the web interface is exposed to the internet then make sure the password is strong.



No.

Quote:

Even if you have a strong password configured on the device, the flaw allows an attacker to access the control panel, capture the password, log into the device and make changes.



That quote from the blog refers to the vulnerability exposed on March, 2011:

http://www.exploit-db.com/exploits/16275/

from which you took this code:

HedPhuqt wrote:

Code:

[email protected]:~#  get.pl http://192.168.1.1/password.cgi   ## Information Disclosure
 
/*HTTP/1.1 200 Ok
Cache-Control: no-cache
Connection: close
Date: Mon, 03 Jan 2000 23:01:25 GMT
Server: micro_httpd
Content-Type: text/html
 
<html>
   <head>
      <meta HTTP-EQUIV='Pragma' CONTENT='no-cache'>
      <link rel="stylesheet" href='stylemain.css' type='text/css'>
         <link rel="stylesheet" href='colors.css' type='text/css'>
            <script language="javascript" src="util.js"></script>
            <script language="javascript">
<!-- hide\n                               ## Dammit! =))
pwdAdmin = '<CENSORED>';                  ## Censored Password
pwdSupport = '<CENSORED>';                ## Censored Password
pwdUser = '<CENSORED>';\n                 ## Censored Password
*/




Now notice that the codelinkedin the blog does not use that vulnerability. There is nothing in the blog text showing a link between the two.

If you look at the called script, roda.sh, you will see it simply uses known credentials, hardcoded not passed as a parameter as it would be the case if they had been taken from somewhere else.

Yes there is something missing here. As there is no access to the presentationit is hard to know what is the link between the original vulnerability and the code found in the offending server, if any. What I say is that the last two pieces of code are just dumb and you are safe from them if you change passwords.

Last edited by kakao on Tue Oct 02, 2012 5:14 pm

Bokononist

Seniorius Lurkius

Registered: Sep 26, 2012

Posts: 35

Posted: Tue Oct 02, 2012 5:07 pm

HedPhuqt wrote:

kakao wrote:

Bokononist wrote:

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?


Yes you are safe from THATexploit used on the shown code. If the web interface is exposed to the internet then make sure the password is strong.



No.

Quote:

Even if you have a strong password configured on the device, the flaw allows an attacker to access the control panel, capture the password, log into the device and make changes.




Code:

[email protected]:~#  get.pl http://192.168.1.1/password.cgi   ## Information Disclosure
 
/*HTTP/1.1 200 Ok
Cache-Control: no-cache
Connection: close
Date: Mon, 03 Jan 2000 23:01:25 GMT
Server: micro_httpd
Content-Type: text/html
 
<html>
   <head>
      <meta HTTP-EQUIV='Pragma' CONTENT='no-cache'>
      <link rel="stylesheet" href='stylemain.css' type='text/css'>
         <link rel="stylesheet" href='colors.css' type='text/css'>
            <script language="javascript" src="util.js"></script>
            <script language="javascript">
<!-- hide\n                               ## Dammit! =))
pwdAdmin = '<CENSORED>';                  ## Censored Password
pwdSupport = '<CENSORED>';                ## Censored Password
pwdUser = '<CENSORED>';\n                 ## Censored Password
*/



source


Thanks for that, so if even turning off remote access to the router won't stop this attack, and Kaspersky won't release a list of vulnerable routers then that makes me think that there are probably a *lot* of potentially vulnerable systems outside of Brazil.
As for defense against this attack, the only suggestion that makes sense to me would be the additional router as a firewall, not really that practical though unless you have spare routers lying around.
One thought that does occur though, would simply be to check your DNS settings before you get started on your browsing session. Not that practical for most I hear you cry, however (with apologies to syntaxerror) if you use Open DNS there is a page on their site that confirms if you are using their DNS servers, just set that as your homepage and you're good to go. :)

EDIT: good spot Kakao, missed your post. The amount of houses I've been to and asked for their router password and they've told me to check the bottom of the router, admittedly a small sample but probably representative. Could be a lot of people vulnerable to this.
Really would like to see the presentation though, is there more to it than just leaving your router on default settings?

Last edited by Bokononist on Tue Oct 02, 2012 5:51 pm

HedPhuqt

Ars Tribunus Militum

Registered: Jan 24, 2000

Posts: 2060

Posted: Tue Oct 02, 2012 5:41 pm

kakao wrote:

HedPhuqt wrote:

kakao wrote:

Bokononist wrote:

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?


Yes you are safe from THATexploit used on the shown code. If the web interface is exposed to the internet then make sure the password is strong.



No.

Quote:

Even if you have a strong password configured on the device, the flaw allows an attacker to access the control panel, capture the password, log into the device and make changes.



That quote from the blog refers to the vulnerability exposed on March, 2011:

http://www.exploit-db.com/exploits/16275/

from which you took this code:

HedPhuqt wrote:

Code:

[email protected]:~#  get.pl http://192.168.1.1/password.cgi   ## Information Disclosure
 
/*HTTP/1.1 200 Ok
Cache-Control: no-cache
Connection: close
Date: Mon, 03 Jan 2000 23:01:25 GMT
Server: micro_httpd
Content-Type: text/html
 
<html>
   <head>
      <meta HTTP-EQUIV='Pragma' CONTENT='no-cache'>
      <link rel="stylesheet" href='stylemain.css' type='text/css'>
         <link rel="stylesheet" href='colors.css' type='text/css'>
            <script language="javascript" src="util.js"></script>
            <script language="javascript">
<!-- hide\n                               ## Dammit! =))
pwdAdmin = '<CENSORED>';                  ## Censored Password
pwdSupport = '<CENSORED>';                ## Censored Password
pwdUser = '<CENSORED>';\n                 ## Censored Password
*/




Now notice that the codelinkedin the blog does not use that vulnerability. There is nothing in the blog text showing a link between the two.

If you look at the called script, roda.sh, you will see it simply uses known credentials, hardcoded not passed as a parameter as it would be the case if they had been taken from somewhere else.

Yes there is something missing here. As there is no access to the presentationit is hard to know what is the link between the original vulnerability and the code found in the offending server, if any. What I say is that the last two pieces of code are just dumb and you are safe from them if you change passwords.


Thanks for explaining but there's still a gap. I'm not a script guy but I don't see any hardcoded anything here. Just a bunch of what I think are variables ($bla).

Quote:

Once accessed, another script called "roda.sh" would run and access the modem. The vulnerability reveals the administration password of the modem. Capturing the password, the script accesses the modem admin panel, changes the configuration of the Domain Name System (DNS) and changes the password, preventing the device owner from changing it later.

HedPhuqt

Ars Tribunus Militum

Registered: Jan 24, 2000

Posts: 2060

Posted: Tue Oct 02, 2012 5:43 pm

Bokononist wrote:

HedPhuqt wrote:

kakao wrote:

Bokononist wrote:

kakao wrote:

HedPhuqt wrote:

Apparently there is a significant amount of confusion about this attack.

Step by step:

1. Attackers scan a block of IPs looking for a specific response that identifies a vulnerable router.
2. A script runs that exposes the credentials of the router.



Number 2 is wrong. The script uses publicly known credentials (user/password) with which the modems are factory set. With those credentials it changes the passwords themselves and the DNS addresses.


So if your router has been configured away from factory settings, i.e. router name and password, *or* remote access to the router is disabled in the options *or* both, this vulnerability is closed off yes?


Yes you are safe from THATexploit used on the shown code. If the web interface is exposed to the internet then make sure the password is strong.



No.

Quote:

Even if you have a strong password configured on the device, the flaw allows an attacker to access the control panel, capture the password, log into the device and make changes.




Code:

[email protected]:~#  get.pl http://192.168.1.1/password.cgi   ## Information Disclosure
 
/*HTTP/1.1 200 Ok
Cache-Control: no-cache
Connection: close
Date: Mon, 03 Jan 2000 23:01:25 GMT
Server: micro_httpd
Content-Type: text/html
 
<html>
   <head>
      <meta HTTP-EQUIV='Pragma' CONTENT='no-cache'>
      <link rel="stylesheet" href='stylemain.css' type='text/css'>
         <link rel="stylesheet" href='colors.css' type='text/css'>
            <script language="javascript" src="util.js"></script>
            <script language="javascript">
<!-- hide\n                               ## Dammit! =))
pwdAdmin = '<CENSORED>';                  ## Censored Password
pwdSupport = '<CENSORED>';                ## Censored Password
pwdUser = '<CENSORED>';\n                 ## Censored Password
*/



source


Thanks for that, so if even turning off remote access to the router won't stop this attack, and Kaspersky won't release a list of vulnerable routers then that makes me think that there are probably a *lot* of potentially vulnerable systems outside of Brazil.
As for defense against this attack, the only suggestion that makes sense to me would be the additional router as a firewall, not really that practical though unless you have spare routers lying around.
One thought that does occur though, would simply be to check your DNS settings before you get started on your browsing session. Not that practical for most I hear you cry, however (with apologies to syntaxerror) if you use Open DNS there is a page on their site that confirms if you are using their DNS servers, just set that as your homepage and you're good to go. :)


Other than workarounds, which are many and varied, the defense against this is upgrading firmware on the affected box.

Oesor

Seniorius Lurkius

Registered: Jan 3, 2008

Posts: 30

Posted: Tue Oct 02, 2012 5:57 pm

HedPhuqt wrote:


Thanks for explaining but there's still a gap. I'm not a script guy but I don't see any hardcoded anything here. Just a bunch of what I think are variables ($bla).



The affected modems push out the admin, support and user passwords as string javascript variables so that the web GUI can check against the old password entered and helpfully pop up a 'Old xxx password is wrong.' alert box. If you want to change the passwords you can just look at the source to find what to push out along with new new passwords as the old password; that is if the modem even bothers to vet the POSTed new passwords.

Additionally, you can access the password change cgi script without authenticating.

kakao

Seniorius Lurkius

Tribus: Brasília, Brazil

Registered: Mar 10, 2005

Posts: 42

Posted: Tue Oct 02, 2012 6:10 pm

HedPhuqt wrote:

Thanks for explaining but there's still a gap. I'm not a script guy but I don't see any hardcoded anything here. Just a bunch of what I think are variables ($bla).

Quote:

Once accessed, another script called "roda.sh" would run and access the modem. The vulnerability reveals the administration password of the modem. Capturing the password, the script accesses the modem admin panel, changes the configuration of the Domain Name System (DNS) and changes the password, preventing the device owner from changing it later.


This is also not based on the shown roda.sh code. I can't post the relevant part as the script is an image and I think it is not possible to upload to the forum but I will try to transcript one line and explain:

Code:

curl $copts http://$ip_completo/password.cgi?sptPassword=dnschange -d "userName=2&pwdOld=support&pwNew=dnschange&pwCfm=dnschange" > /dev/null;


curl is a command line utility that is used in this case to send an HTTP request to the modem. The modem address is contained in the $ip_completo variable. It was passed as a parameter ($1) to the script and you can see it being assigned in the second line. $copts is a variable containing curl options. You can see its contents in the fifth line of the script. password.cgi is the requested page. Now the -d curl parameter is the most important. That string between double quotes is passed as a post method to the page. It contains 4 parameters which are userName, pwdOld, pwNew and pwCfm with the respective values of 2, support, dnschange, dnschange. What is happening is it is passing the old and the new password which are support and dnschange respectively. They are indeed hardcoded.

kakao

Seniorius Lurkius

Tribus: Brasília, Brazil

Registered: Mar 10, 2005

Posts: 42

Posted: Tue Oct 02, 2012 6:44 pm

Bokononist wrote:

EDIT: good spot Kakao, missed your post. The amount of houses I've been to and asked for their router password and they've told me to check the bottom of the router, admittedly a small sample but probably representative. Could be a lot of people vulnerable to this.
Really would like to see the presentation though, is there more to it than just leaving your router on default settings?


While the cited vulnerability is real I see nothing, up to now, linking it to the alleged 4.5 million affected modems. The problem attaching that number to that vulnerability is that it is not easy to catch all those people in a cross site scripting exploit.

First the user should be authenticated to the modem while visiting a malicious or infected site for the malicious script to be able to see the credentials. And a simple HTTP authentication vanishes when the browser is closed so the time window to exploit it is small. Second most the users don't know how to access the modem's web interface or even know that it exists or what purpose it serves. It would be possible to send spam urging the user to click on a link pointing to some of the modem's pages but then an authentication message would be shown and most the users would not fall on that trap, even if just because they don't know the credentials, default or not. So it looks unlikely that a CSRF would lead to such massive number of infections.

That said I already found the latest firmware update for my modem and I will apply it as soon as possible.

Last edited by kakao on Tue Oct 02, 2012 7:17 pm

ReaderBot

Ars Praefectus

Registered: Jul 6, 2007

Posts: 4128

Posted: Tue Oct 02, 2012 7:04 pm

Z1ggy wrote:

ads2 wrote:

Z1ggy wrote:

Adam Starkey wrote:

Ahh, looking at the advisory, it seems like a standard default username/password attack.

Are modem makers really still doing this?


my mother got a new modem from her cable company last year, the username/password is on the outside of the box.
I changed the password the first chance i had while setting her up.

then i had to write it down for her. :(


why does writing down a rarely used password make a frowny face?
it seems like as perfectly reasonable thing to do, unless your mom had Russian mobsters wandering through her home office.

because its on her computer in a text document labeled passwords. and its not the only thing in there. and my older sister has access to the network and has terible decision making skills when it comes to clicking on links.


You should teach them how to use OnePass/KeyPass/LastPass/Password Safe/etc., and only need write down one password. And use a piece of paper not attached to the computer.

Z1ggy

Ars Legatus Legionis

Tribus: New York

Registered: Jun 6, 2009

Posts: 14721

Posted: Tue Oct 02, 2012 7:09 pm

ReaderBot wrote:

Z1ggy wrote:

ads2 wrote:

Z1ggy wrote:

Adam Starkey wrote:

Ahh, looking at the advisory, it seems like a standard default username/password attack.

Are modem makers really still doing this?


my mother got a new modem from her cable company last year, the username/password is on the outside of the box.
I changed the password the first chance i had while setting her up.

then i had to write it down for her. :(


why does writing down a rarely used password make a frowny face?
it seems like as perfectly reasonable thing to do, unless your mom had Russian mobsters wandering through her home office.

because its on her computer in a text document labeled passwords. and its not the only thing in there. and my older sister has access to the network and has terible decision making skills when it comes to clicking on links.


You should teach them how to use OnePass/KeyPass/LastPass/Password Safe/etc., and only need write down one password. And use a piece of paper not attached to the computer.

well first i would need to use on of those. :(Ive got it in a notepad on my computer as well, i just dont have it labeled as passwords. :)I KNOW I KNOW.... its on my list of things to do, but my wife uses the accounts as well, and im not sure how well it would go over.

Hoku

Seniorius Lurkius

Tribus: Northern Arizona

Registered: Jun 25, 2009

Posts: 17

Posted: Wed Oct 03, 2012 5:13 am

There are a few DSL and cable modems that have open ports so the ISP can push out firmware updates. I suggest you port scan your IP address and see if your modem has an open port. I haven't found an easy solution to closing the open port on my DSL modem.

leexgxreal

Ars Scholae Palatinae

Tribus: UK

Registered: Sep 10, 2012

Posts: 1372

Posted: Wed Oct 03, 2012 1:52 pm

Bokononist wrote:

brokensyntax wrote:

This is why I always set my own DNS servers manually.

I highly suggest OpenDNS (208.67.222.222 and 208.67.220.220) or one the big companies with easy to remember DNS IP addresses (4.2.2.2 dsl error micro_httpd

0 Comments

Leave a Comment

Proudly Powered By WordPress.

Theme Kaira by .