Search the Community

Two out of three public-facing app instances open to hijacking Apache Superset until earlier this year shipped with an insecure default configuration that miscreants could exploit to login and take over the data visualization application, steal data, and execute malicious code. The open source application, based on Python's Flask framework, defaulted to a publicly known secret key: SECRET_KEY = '\2\1thisismyscretkey\1\2\e\y\y\h' In an advisory on Tuesday, security firm Horizon3.ai explained that when a user logs into a Superset instance, the web application sends a session cookie with a user identifier back to the visitor's web browser. "The web application signs the cookie with a SECRET_KEY, a value that is supposed to be randomly generated and typically stored in a local configuration file," said Naveen Sunkavally, chief architect at Horizon3.ai. If an attacker knows the value of SECRET_KEY, that person can then generate and sign cookies, effectively authenticating as the app administrator. And it turns out to be trivial to check whether Superset is using the default key with a tool called flask-unsign. According to Sunkavally, about two-thirds of those using the software failed to generate a new key when setting up Superset: as of October 11, 2021, the application had almost 3,000 instances exposed to the internet, about 2,000 of which relied on the default secret key. The Apache security team responded the following day and by January 11, 2022, made some changes, which established a new default secret key: "CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET" But this time the app included a check to see whether the new default remained unchanged. If so, the app issued a warning to the app's log file, with instructions for how to generate a secure key. Heeding the warning, however, was left to users. More than a year after this change was made, on February 9, 2023, Horizon3.ai again checked to see how many Superset instances were configuring their app with a public default secret key. This time they expanded their Shodan.io search to four different default keys – the original, the new one, and two others – one from a deployment template and one from the documentation. And not much had changed. Out of 3,176 Superset instances, 2,124 (~67 percent) were using one of the four default keys. So Horizon3.ai contacted the Apache security team again. And two weeks later, on February 24, 2023, the project maintainers committed an update that would ship as part of the 2.1 release on April 5, 2023, to "impose harsher measures when a default SECRET_KEY is identified." The change made it so the app would not start with a default key. "With this update, many new users of Superset will no longer unintentionally shoot themselves in the foot," said Sunkavally, who cautioned that it's still possible to end up with an insecure version of Superset if the software is installed via a docker-compose file or a helm template. "The docker-compose file contains a new default SECRET_KEY of TEST_NON_DEV_SECRET that we suspect some users will unwittingly run Superset with. Some configurations also set admin/admin as the default credential for the admin user." The Superset vulnerability was disclosed as CVE-2023-27524 on Monday. Sunkavally said concerned Superset users can check to see whether their server has a default key with this script that relies on flask-unsign. The 2,000+ vulnerable Superset instances identified were operated by companies large and small, government agencies, and universities, according to Sunkavally, who added that some of these organizations addressed the vulnerability after being notified about it. Sunkavally said this episode illustrates that users do not read documentation and don't read logs. "The best approach is to take the choice away from users and require them to take deliberate actions to be purposefully insecure," he said. ® Via theregister.com

Check your rooftops: Flying gear caught carrying network-intrusion kit Modified off-the-shelf drones have been found carrying wireless network-intrusion kit in a very unlikely place. The idea of using consumer-oriented drones for hacking has been explored over the past decade at security conferences like Black Hat 2016, in both the US and in Europe. Naomi Wu, a DIY tech enthusiast, demonstrated a related project called Screaming Fist in 2017. And in 2013, security researcher Samy Kamkar demonstrated his SkyJack drone, which used a Raspberry Pi to take over other drones via Wi-Fi. Now these sort of attacks are actually taking place. Greg Linares, a security researcher, recently recounted an incident that he said occurred over the summer at a US East Coast financial firm focused on private investment. He told The Register that he was not involved directly with the investigation but interacted with those involved as part of his work in the finance sector. The Register corresponded with an individual affiliated with the affected company who corroborated Linares's account and asked not to be identified owing to a non-disclosure agreement and employment concerns. In a Twitter thread, Linares said the hacking incident was discovered when the financial firm spotted unusual activity on its internal Atlassian Confluence page that originated from within the company's network. The company's security team responded and found that the user whose MAC address was used to gain partial access to the company Wi-Fi network was also logged in at home several miles away. That is to say, the user was active off-site but someone within Wi-Fi range of the building was trying to wirelessly use that user's MAC address, which is a red flag. The team then took steps to trace the Wi-Fi signal and used a Fluke system to identify the Wi-Fi device. "This led the team to the roof, where a 'modified DJI Matrice 600' and a 'modified DJI Phantom' series were discovered," Linares explained. The Phantom drone was in fine condition and had a modified Wi-Fi Pineapple device, used for network penetration testing, according to Linares. The Matrice drone was carrying a case that contained a Raspberry Pi, several batteries, a GPD mini laptop, a 4G modem, and another Wi-Fi device. It had landed near the building's heating and ventilation system and appeared to be damaged but still operable. "During their investigation, they determined that the DJI Phantom drone had originally been used a few days prior to intercept a worker's credentials and Wi-Fi," Linares said. "This data was later hard coded into the tools that were deployed with the Matrice." According to Linares, the tools on the drones were used to target the company's internal Confluence page in order to reach other internal devices using the credentials stored there. The attack, he said, had limited success and is the third cyberattack involving a drone he's seen over the past two years. "The attackers specifically targeted a limited access network, used by both a third-party and internally, that was not secure due to recent changes at the company (e.g. restructuring/rebranding, new building, new building lease, new network setup or a combination of any of these scenarios)," Linares told The Register. "This is the reason why this temporary network unfortunately had limited access in order to login (credentials + MAC security). The attackers were using the attack in order to access an internal IT confluence server that contained other credentials for accessing other resources and storing IT procedures." Long-term problem comes to life Linares said he had worked on a drone project in 2011 to test network attack capabilities and at the time, power, carry weight, and range were limiting factors. "We revisited it again in 2015 and drone tech had come a long way," he said. "Now in 2022 we are seeing really amazing drone advancements in power, range, and capabilities (for instance, the amazing synchronized drone shows that China puts out are utterly fantastic)." "This paired with drone payload options getting smaller and more capable – e.g. Flipper Zero kit – ... make viable attack packages that are reasonable to deploy," said Linares. "Targets in fintech/crypto and supply chain or critical third-party software suppliers would make ideal targets for these attacks where an attacker can easily cover their initial operating costs with immediate financial gain or access to more lucrative targets." Via theregister.com

Privacy. Are we there yet? No, but there's some progress at least When version 90 of Google's Chrome browser arrives in mid-April, initial website visits will default to a secure HTTPS connection in the event the user has failed to specify a preferred URI scheme. Lack of security is currently the norm in Chrome. As Google Chrome software engineers Shweta Panditrao and Mustafa Emre Acer explain in a blog post, when a user types "www.example.com" into Chrome's omnibox, without either an "http://" or "https:// prefix," Chrome chooses "http://." The same is true in other browsers like Brave, Edge, Mozilla, and Safari. This made sense in the past when most websites had not implemented support for HTTPS. It was only in 2018 that the majority of websites redirected traffic to HTTPS. But these days, most of the web pages loaded rely on secure transport (ranging from about 98 per cent on Chrome to about 77 per cent on Linux). And among the top 100 websites, 97 of them currently default to HTTPS. Previously, only websites that declared they should be loaded securely with an entry on an HTTP Strict Transport Security (HSTS) preload list – supported in multiple browsers – got HTTPS automatically. Chrome 90 will make HTTPS the default for first time website visits where no transport has been declared. Beyond the security and privacy benefits, say Panditrao and Acer, this will improve performance since the delay incurred by redirection from an http:// endpoint to an https:// endpoint will no longer happen. A few exceptions will persist, however. IP addresses, single label domains (eg contoso without TLD like .com), and reserved hostnames like localhost/ will still default to http://. Private like a fox In other browser-related news, Mozilla Firefox 87 debuted on Tuesday with a privacy feature called SmartBlock. Borrowing from techniques used by privacy-focused extensions NoScript and uBlock Origin (eg "stub scripts"), SmartBlock provides a way to block tracking scripts while attempting to minimize performance-affecting delays or errors that can arise from meddling with webpage code. Firefox SmartBlock can replace trackers found on the extensive Disconnect Tracking Protection List, which just for the US numbers well over a thousand. Firefox 87 also incorporates another privacy enhancement: It will limit the information contained in the referrer (misspelled but implemented as "Referer") header string by setting its default Referrer-Policy to "strict-origin-when-cross-origin." What this means is that when a Firefox user follows a link like "https://www.example.com/path?query" – where "path" and "query" represent more meaningful or sensitive information – the HTTP Referer Header that gets sent to the visited website will indicate that the visitor has arrived from "https://www.example.com" and the extra path and query data will be dropped. ® Via theregister.com