Home Gateway device security includes:
-
DEFAULT CREDENTIALS
Change the default credentials that’s pre-installed on the gateway device and remember strong password principles
-
DISABLE WPS
The 8-digit WPS pin allows access to your home Wi-Fi network [SWIPE LEFT]. Due to it’s 8-character count, it’s easily cracked by hackers. It’s likely disabled by default, but if not, disable it
-
WI-FI SECURITY
A home Wi-Fi SSID shouldn’t disclose the router’s manufacture (e.g., Linksy’s, NetGear, etc.). In addition, the encryption should be set to WPA2-PSK [SWIPE LEFT] or WPA3 (if available) with a strong, unique password
-
INTERNAL VULN SCANNING
Perform internal vulnerability scans using tools like OpenVAS and Nessus Home. OpenVAS is free and comes pre-installed in Kali Linux. Alternatively, Nessus Home [SWIPE LEFT] allows users to can scan up to 16 IP addresses at high speeds with in-depth assessments. These tools glean a ton of information about the vulnerabilities on any network device
-
EXTERNAL VULN SCANNING
Unless port forwarding for gaming or hosting an internal server, the gateway shouldn’t have open ports on the WAN side. However, submitting your public IP address to www.grc.com/shieldsup is a great free tool to check for things like Windows file sharing and Common Ports vulnerabilities [SWIPE LEFT]. In addition, you can always audit your gateway device using nmap scans through a VPN
-
CUSTOM FIRMWARE
The firmware installed on your modem/router is likely basic and provides little-to-no customization or security functionalities other than setting the firewall settings to low, medium, or high. But, if you want to configure security features, like VPNs, VLANs, isolate Wi-Fi, iptables, configure authentication servers, and enable traffic monitoring, then there are plenty of good custom firmware options available
-
I really like using DD-WRT(https://dd-wrt.com). [SWIPE LEFT] There are both free and paid versions that support the functionalities described above. To install this firmware on your home router/modem, you’d download the new firmware as a file, navigate to your router or modem’s admin console, and then upgrade the device by uploading the firmware file
The American Institute on Router Safety published a report last year indicating that 60% of home routers/modems had medium-security vulnerabilities [SWIPE LEFT]. These include authentication bypassing, RCE, CSRF, stack-based buffer overflows, information disclosure, etc
-
A typical gateway home router and/or modem supplied by an ISP isn’t secure by default (sometimes, for spying) [SWIPE LEFT]. This includes off-the-shelf routers at Walmart or Best Buy. As the name suggests, these devices are the “gateway” into a home network and should be a secure device. And yet, most lack practical security features
-
Consider that hackers actively target these devices on the Internet (e.g., VPNFilter, BCMUPnP_Hunter, and Mirai malware). If the gateway responds to external pings on the WAN side, then the gateway is visible on the Internet. It should be of no surprise to see a home router in a Shodan query
-
By default, gateway devices come with default login credentials to the admin console, and credentials for popular router/modem manufacturers are easily accessible via www.routerpasswords.com. A pwned gateway device leads to DoS, MitM attacks, DNS tampering, and other variants that expose web traffic
-
Wi-Fi also brings significant security issues, since gateways are often APs. A newly installed Wi-Fi network has a default network name, which broadcasts the router’s brand via beaconing frames. Likewise, WPA and WEPS encryption are still available for backwards compatibility purposes, leaving layman users oblivious that their Wi-Fi can be easily cracked. WEPS- and WPS-enabled routers are still seen on an Airodump-ng and Wash command output in my neighborhood, thus it’s still an issue
-
Firmware updates should be mandatory if they are critical or recommended, but users often neglect this. This is because manufacturers fail to update users to do so (unless registered via e-mail). This stems from the lax security built within. Even the pre-installed firewall lacks anything but a few customizable options because it’s too complex for avg users
-
Part II discusses how to secure a gateway device from these vulnerabilities. What are some ways you keep your home router/modem secure?
Google's Threat Analysis Group (TAG) discovered several compromised web sites that were commandeered for hacking iPhones in what looks like a strategic Watering Hole attack. The number of sites, region, or what the sites were is unknown, but simply visiting the site could be enough to exploit one of several iOS vulnerabilities and install a back door via spyware
-
The report disclosed 14 iOS vulnerabilities (including 2 zero days) that were being exploited through 5 privilege escalation exploit chains, which judging by the sophistication, sounds like a state-sponsored APT infiltration or government operation
-
Victims that were unfortunate enough to visit these web sites may have had their personal information sent to a C2 server, such as iMessages, photos, GPS location, WhatsApp, Telegram, and even Keychain data like passwords and tokens! Despite the major implications of destruction to data confidentiality, these malicious activities went undetected for two years; therefore, anybody running iOS 10 to the latest iOS 12 (09/2016 to Present) may have been impacted
-
What exactly were these vulnerabilities? A quick glance over Google Project Zero’s “in-the-wild iOS exploit chain” reports shows a wonderfully detailed team effort to decipher a collection of iOS Kernel, Safari, and Sandbox escape vulnerabilities [2, 3, 4, 5, 6]. Thanks to the closed-nature of the iOS, there was no need for the spyware to hide its execution. What could have perhaps prevented it all? Better code review, says Google’s security researchers
-
The team wants everyone to bear in mind that mass exploitation still exists, and with that fact, to behave accordingly. Although our phones are integral to our modern lives, it’s important to know that once compromised, every action we take can be uploaded to a database and used against us [1]
-
[1] Beer, I. (2019). A Very Deep Dive into iOS Exploit Chains Found in the Wild. Google Project Zero.
-
[2] Beer, I. (2019). In-the-wild iOS Exploit Chain 1. Google Project Zero. -
[3] Beer, I. (2019). In-the-wild iOS Exploit Chain 2. Google Project Zero. -
[4] Beer, I. (2019). In-the-wild iOS Exploit Chain 3. Google Project Zero. -
[5] Beer, I. (2019). In-th
I know this has been covered by every major cybersecurity news site, but I like hacking Wi-Fi networks and this is a topic I’d like to start discussing in pieces. It’s been a little over a year since the launch of the new WPA3 security standard for Wi-Fi and, as I mentioned prior to it’s release, we’d see serious vulnerabilities within the first year
.
This likely stems from the notoriety gained by Mathy Vanhoef and his discovery of key reinstallation attacks (KRACKs) on WPA2 networks back in 2017. Although this wasn’t the first weakness discovered in WPA2, it is by far the most serious with 10+ CVE identifiers
.
WPA2 has always been vulnerable to dictionary/brute force attacking, but this is assuming the password is very weak. KRACK, on the other hand, does not rely on password guessing. KRACK works against all modern Wi-Fi networks by exploiting a weakness in the WPA handshake mechanism, although some Wi-Fi-supported devices more vulnerable than others
.
KRACKs work by tricking the victim into reinstalling an already-in-use key during the WPA handshake, and as we know, the same key should never be used more than once. WPA3, however, prides itself on using the dragonfly (SAE - RFC 7664) handshake to address some of the weaknesses in WPA2. But, Vanhoef and his colleagues have already discovered various downgrade and side-channel attacks that exploit weaknesses in the new WPA3 standard. They coin these collection of attacks, “Dragonblood.” Listed here are some attacks that affect home WPA3 Wi-Fi networks.
.
Vanhoef and his colleagues will be presenting their paper on Dragonblood at the IEEE Symposium on Security and Privacy on 18-20 May 2020 in Oakland, San Francisco
===================================
* CERT ID #VU871675: Downgrade attack against WPA3-Transtition mode leading to dictionary attacks.
* CERT ID #VU871675: Security group downgrade attack against WPA3's Dragonfly handshake.
* CVE-2019-9494: Timing-based side-channel attack against WPA3's Dragonfly handshake.
* CVE-2019-9494: Cache-based side-channel attack against WPA3's Dragonfly handshake.
* CERT ID #VU871675: Resource consumption attack (i.e. denial of service) against WPA3's Dragonfly handshake.
Back in January, I discussed a flaw in network security’s perimeter model whereby splitting the entire network into architected, trusted and untrusted zones may not be the best solution to the current threat landscape. Great questions were brought-up before I took a 6-month hiatus from posting anything, which sets the topic for this post
.
ESTABLISHING TRUST CHAINS
In a zero trust model, we establish trust chains, which build automated and scalable systems that operate in a trusted way. For instance, trust delegation in a zero-trust network can be demonstrated in a Public Key Infrastructure (PKI), whereby the identity of devices, users, and applications can be verified in a chain of trust. Another example might be auto scaling in a cloud environment in which an established system is explicitly trusted to provision servers and build scaling plans that automate how different resources respond to changes in demand
.
AUTHENTICATION & PKI BASICS
PKI uses the X.509 certificate standard. These certificate use a “public” key and a “private” key. A user’s public key can encrypt its data, but the private key can decrypt it, and in vice versa. Likewise, the public key is distributed and the private key is held by the owner of the certificate. However, the private key can be stolen, which would destroy the trust of the PKI. Therefore, credential rotation (e.g., changing and renewing keys) and time-boxing keys is essential to prevent or mitigate key theft
.
CERTIFICATE AUTHORITIES
But, certificates by themselves aren’t sufficient; They must be trusted. Certificate Authorities (CAs) establish trust as a trusted third party that endorses the validity of a certificate by digitally signing it. By trusting the CA, all certificates issued/signed by this CA are valid because they can be linked back to the known trusted CA, hence a trust chain
.
TO BE CONTINUED
PKI tends to be confusing topic because it uses asymmetric cryptography as opposed to its more easier-understood counterpart, symmetric cryptography. Explaining the PKI cryptographic architecture and it’s importance in zero-trust networks deserves its own separate post.
The CSRF attack is a malicious exploit against a website whereby unauthorized commands are transmitted from an authorized user to the web server, typically by clicking on a malicious link. Let’s say the victim logs onto http://wellsfargo.com/. The victim is like any other web user in which he is authorized to perform specific actions, such as deposit, withdraw, transfer, etc. Since the user is authenticated to the server, the web site trusts the user and the hacker exploits this trust
-
Here’s a quick example of how the attack works (disclaimer: you won’t typically see security holes like this on modern web apps). Assume the victim is authenticated to http://wellsfargo.com/. Also assume that the developers are using GET requests instead of POST requests. The victim can make a GET request that allows the web application to transfer $100 to his friend’s account. This might look something like this: http://wellsfargo.com/transfer.do?acct=FriendAccount=$100. A hacker, however, can modify this GET request to look like this: http://wellsfargo.com/transfer.do?acct=HackerAccount=$100. This new hyperlink transfers $100 from the victim’s account to the hacker’s account. But, the victim would first need to be tricked into clicking this link for this to work
.
While still authenticated to Wells Fargo, let’s say the victim receives an e-mail from a targeted mass phishing campaign. The e-mail contains the malicious link within an <img> tag, such as: <img data-fr-src="http://wellsfargo.com/transfer.do?acct=HackerAccount=$100” />. Since modern web apps use cookies for authentication, the victim’s browser checks if it has cookies associated with the origin of http://wellsfargo.com/, which in this case, it does. Those cookies are sent with each http request so that users aren’t required to authenticate for every page they visit. By clicking on the link, and by being authenticated to http://wellsfargo.com/, the victim was tricked into sending a request to transfer money on the hacker’s behalf. This resulted in $100 being transferred from the victim’s account to the hacker’s account
.
.
CONTINUED IN COMMENTS
The Blind XSS (BXSS) is a type of persistent XSS attack whereby the hacker blindly targets web pages that store user input in a database, such as blogs, forums, comment boxes, contact forms, login forms, and message boards. Although the BXSS and the Persistent XSS attacks are fairly identical in terms of the end-goal and the stored payload, the distinction lies in the execution of the attack
.
In a BXSS attack, the hacker fires off payloads into vulnerable sites, but doing so manually is cumbersome. The process can be automated using XSS security tools, such as XSS Hunter, which discovers XSS vulnerabilities on web pages, automatically generates payloads for those vulnerabilities, and even correlates injection attempts. The hacker isn’t expecting to see any immediate response or sign that the attack worked; they aren’t even aware if the payload was stored in the same web application or even stored in the first place...hence a “blind” XSS
.
The BXSS sometimes targets site administrators because the malicious script is commonly either sanitized before being served to everyday site visitors or served by a different web application. Site admins/mods who use management web sessions to load content for administrative tasks might find themselves executing the malicious code in the admin interface
.
For example, say the hacker injects malicious code in a contact form and submits it to the server. The code will be stored in the database, but not likely in the same application. Thus, there is no immediate response, such as the typical JavaScript Alert() box. The browser of a victim who visits the same contact page isn’t authorized to make a GET request for the hacker’s payload stored in the database; however, a site admin who is reviewing the everyday contact submissions from site visitors may inadvertently execute the malicious script stored inside the hacker’s contact submission
