Improper Input Validation vulnerability in the Apache Airflow Google Provider. This issue affects Apache Airflow Google Provider versions before 8.10.0.

**Apache Airflow Google Provider Improper Input Validation vulnerability**

Moderate severity GitHub Reviewed Published Feb 24, 2023 to the GitHub Advisory Database • Updated Feb 24, 2023

GHSA-h8p2-8g72-qpgh: Apache Airflow Google Provider Improper Input Validation vulnerability

**Email display mode:**

Modern rendering  
Legacy rendering

CVE-2023-25691

CVE-2023-25692

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Feb. 17 and Feb. 24. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed...

Threat Round up for February 17 to February 24

An investigation into data safety labels for Android apps available on the Google Play Store has uncovered "serious loopholes" that allow apps to provide misleading or outright false information.
The study, conducted by the Mozilla Foundation as part of its *Privacy Not Included initiative, compared the privacy policies and labels of the 20 most popular paid apps and the 20 most popular free

An investigation into data safety labels for Android apps available on the Google Play Store has uncovered "serious loopholes" that allow apps to provide misleading or outright false information.

The study, conducted by the Mozilla Foundation as part of its \*Privacy Not Included initiative, compared the privacy policies and labels of the 20 most popular paid apps and the 20 most popular free apps on the app marketplace.

It found that, in roughly 80% of the apps reviewed, "the labels were false or misleading based on discrepancies between the apps' privacy policies and the information apps self-reported on Google's Data safety form."

"The apps aren't self-reporting accurately enough to give the public any meaningful reassurance about the safety and privacy of their data," Mozilla further said, adding consumers are being led to "believe these apps are doing a better job protecting their privacy than they are."

Three of the apps – UC Browser - Safe, Fast, Private; League of Stickman Acti; and Terraria – did not have their Data safety sections filled at all. A mere 6 of the 40 apps received an "OK" grade.

Last year, Google began rolling out a new Data safety section on the Play Store that spells out the apps' privacy and security practices. It's also the company's answer to Apple's app privacy labels that came into effect in December 2020.

However, there are some crucial differences. Apple's labels emphasize on what data is being collected, including those that are collected for tracking purposes as well as information that's linked to the users.

Google's labels, on the other hand, allows developers to provide more context as to why such a data collection may be required and the security principles that are used to safeguard the information.

That said, both systems rely on developers to be transparent about how their apps use data. While Apple has instituted routine checks to ensure that the labels don't provide a false sense of security, Google leaves developers to make "complete and accurate declarations."

Now according to Mozilla, these self-reported labels may not be an accurate representation of an app's data-gathering policies, calling into question the effectiveness of such a framework in enhancing privacy transparency and enabling users to make informed decisions.

"For example, Google exempts apps sharing data with 'service providers' from its disclosure requirements, which is problematic due to both the narrow definition it uses for service providers and the large amount of consumer data involved," Mozilla said.

To that end, Mozilla refutes Snapchat, TikTok and Twitter's claims that their apps don't "share user data with other companies or organizations," stating that the apps' privacy policies explicitly mention sharing user information with advertisers and internet service providers, among others.

It's worth pointing out here that apps can be exempted from disclosing data sharing provided they have sought users' consent, if the data is being shared with a developer's service provider, or if the data is fully anonymized.

The American non-profit is also recommending Apple and Google to adopt a universal nutrition labeling standard, alongside urging the tech giants to "explain their enforcement action against apps that don't comply and take some responsibility for ensuring the accuracy of the information apps report."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Majority of Android Apps on Google Play Store Provide Misleading Data Safety Labels

At the inaugural CloudNativeSecurityCon, DevSecOps practitioners discussed how to shore up the software supply chain.

At the recent CloudNativeSecurityCon in Seattle, 800 DevSecOps practitioners gathered to address a myriad of software supply chain security issues, including the security of container images and the impact of zero trust on the software supply chain.

As of last year, there were 7.1 million cloud-native developers, 51% more than the 4.7 million 12 months earlier, Cloud Native Computing Foundation executive director Priyanka Sharma said in the opening keynote. "Everyone is becoming a cloud-native developer," Sharma said.

However, this rapid shift to cloud-native development can be a source of concern, since the rapid release cycles may lead to organizations not following secure lifecycle development (SDLC) practices, Sharma warned. Snyk's 2022 State of Cloud Security report found that 77% of organizations acknowledged that they have poor training and lack effective collaboration among developers and security teams.

"There are siloed teams often working in separate countries, time zones, using different tools, policy frameworks," Sharma said. "In the cloud-native environment, we are interacting with so many other entities. Throw in a lack of security policy, and there's the recipe for your security breach."

The lack of security policies is fueling an increase in vulnerabilities due to misconfigurations. An alarming 87% of container images running in production have critical or high-severity vulnerabilities, up from 75% a year ago, according to the Sysdig 2023 Cloud-Native Security and Usage Report. Yet only 15% of those unpatched critical and high vulnerabilities are in packages that are in use at runtime where a patch is available.

Sysdig's findings are based on telemetry gathered from thousands of its customers' cloud accounts, amounting to billions of containers. The high percentage of critical or high-severity vulnerabilities in containers is the outgrowth of the rush by organizations to deploy modern cloud applications. The push has created an influx of software developers moving to the more agile continuous integration continuous development (CI/CD) programming model.

Sysdig's report recommended filtering to isolate only the critical and highly vulnerable packages in use in order to focus on packages that present the most risk. Further, only 2% of the vulnerabilities are exploitable. "By looking at what has in use exposure, that is what is actually in use at runtime, and having the fix available will help teams prioritize," Sysdig threat researcher Crystal Morin wrote in the report.

**5 Elements of Zero Trust Implementation**

Sharma pointed to last year's Cost of a Data Breach report from IBM and Ponemon Institute, which showed that 79% of organizations have not moved to a zero-trust environment. "That is really not good," Sharma said. "Because almost 20% of breaches are occurring because of a compromise at a business partner. And keep in mind that almost half the breaches that occur are cloud-based."

A key barrier to instituting zero trust is environments where permissions are not under control. According to the Sysdig report, 90% of permissions granted are not used, creating an easy path for stealing credentials. According to the report, "teams need to enforce least privilege access, and that requires an understanding of which permissions are actually in use."

Zack Butcher, founding engineer at Tetrate and an early engineer on Google's service mesh project Istio, said creating a zero-trust environment isn't that complicated. "Zero trust itself isn't a mystery," Butcher told attendees. "There's a lot of FUD \[fear, uncertainty, and doubt\] around what zero trust is. It's fundamentally two things: people process and runtime controls that answer and mitigate the question, 'what if the attacker is already inside that network?'"

Butcher identified five policy checks that would make up a zero-trust system:

1.  Encryption in transit to ensure messages can't be eavesdropped
2.  Service level identity to enable authentication at runtime, ideally a cryptographic identity
3.  The ability to use those identities to be able to perform runtime service-service authorization to control which workloads can talk to each other
4.  Authenticating the end user in session
5.  A model that authorizes the actions users are taking on resources in the system

Butcher noted that while these are not new, there is now an effort to create an identity-based segmentation standard with the National Institute of Standards and Technology (NIST). "If you look at things like API gateways and ingress gateways, we do these checks usually," he said. "But we need to be doing them, not just at the front door, but every single hop in our infrastructure. Every single time anything is communicating, we need to be applying, at minimum, these five checks."

**NIST Standard Coming Up**

During a breakout session, Butcher and NIST computer scientist Ramaswamy "Mouli" Chandramouli explained the five controls and how they fit into a zero-trust architecture. Tools such as a service mesh can help implement many of those controls, Butcher said.

The presentation is an outline for a proposal that will be presented as NIST SP 800-207A: A Zero Trust Architecture (ZTA) Model for Access Control in Cloud Native Applications in Multi-Location Environments. "We expect to have this out for initial public review sometime in June," Butcher said.

Butcher said supply chain security is a critical component of a zero-trust architecture. "If we can't inventory and attest what's running in our infrastructure, we leave a gap for attackers to exploit," he said. "Zero trust as a philosophy is all about mitigating what an attacker can do if they are in the network. The goal is bounding their attack in space and time, and controlling the applications that execute in that infrastructure is a key element of bounding the space an attacker has to work with."

87% of Container Images in Production Have Critical or High-Severity Vulnerabilities

An untrusted search path vulnerability exists in Node.js. <19.6.1, <18.14.1, <16.19.1, and <14.21.3 that could allow an attacker to search and potentially load ICU data when running with elevated privileges.

Updates are now available for the v19.x, v18.x, v16.x, and v14.x Node.js release lines for the following issues.

This security release includes OpenSSL security updates as outlined in the recent OpenSSL security advisory.

Impacts:

*   All versions of the 19.x, 18.x, 16.x, and 14.x release lines.

**Node.js Permissions policies can be bypassed via process.mainModule (High) (CVE-2023-23918)**

It was possible to bypass Permissions and access non authorized modules by using process.mainModule.require(). This only affects users who had enabled the experimental permissions option with --experimental-policy.

Thank you, to @goums for reporting this vulnerability and thank you Rafael Gonzaga for fixing it.

Impacts:

*   All versions of the 19.x, 18.x, 16.x, and 14.x release lines.

**Node.js OpenSSL error handling issues in nodejs crypto library (Medium) (CVE-2023-23919)**

In some cases Node.js did does not clear the OpenSSL error stack after operations that may set it. This may lead to false positive errors during subsequent cryptographic operations that happen to be on the same thread. This in turn could be used to cause a denial of service.

Thank you, to Morgan Jones and Ryan Dorrity from Viasat Secure Mobile for reporting and discovering this vulnerability and thank you Rafael Gonzaga for fixing it.

Impacts:

*   Versions of < 19.2.0 and lower of the 19.x release line and all versions of the 18.x, and 16.x release lines.

The fetch API in Node.js did not prevent CRLF injection in the 'host' header potentially allowing attacks such as HTTP response splitting and HTTP header injection.

Thank you, to Zhipeng Zhang (@timon8) for reporting this vulnerability and thank you Robert Nagy for fixing it.

Impacts:

*   All versions of the 19.x, 18.x and 16.x release lines.

The Headers.set() and Headers.append() methods in the fetch API in Node.js were vulnerable to a Regular Expression Denial of Service (ReDoS) attacks.

Thank you, to Carter Snook for reporting this vulnerability and thank you Rich Trott for fixing it.

Impacts:

*   All versions of the 19.x, 18.x, and 16.x release lines.

Node.js would search and potentially load ICU data when running with elevated priviledges. Node.js was modified to build with ICU_NO_USER_DATA_OVERRIDE to avoid this.

Thank you, to Ben Noordhuis for reporting this vulnerability and thank you Rafael Gonzaga for fixing it.

Impacts:

*   All versions of the 19.x, 18.x, 16.x, and 14.x release lines.

This security release also includes an npm update for Node.js 14 to address a number of CVEs which either do not affect Node.js or are low severity in the context of Node.js. You can get more details for the individual CVEs in nodejs-dependency-vuln-assessments.

Impacts:

*   All versions 14.x release lines.

**Downloads and release details**

Thanks to Rafael Gonzaga and Richard Lau for their work on the releases.

*   Node.js v14.21.3 (LTS)
*   Node.js v16.19.1 (LTS)
*   Node.js v18.14.1 (LTS)
*   Node.js v19.6.1 (Current)

The Node.js project is delaying the planned security releases until Thursday February 16 2023 due to the need for additional testing and validation.

The Node.js project will release new versions of the 14.x, 16.x, 18.x and 19.x releases lines on or shortly after, Tuesday February 14 2023 in order to address:

*   2 low severity issues.
*   2 medium severity issues.
*   1 high severity issues.
*   OpenSSL security updates for which the highest vulnerability severity is high. You can read more about this update in the OpenSSL security advisory.

The 19.x release line of Node.js is vulnerable to 2 low severity issues, 2 medium severity issues and 1 high severity issue and the OpenSSL vulnerabilities.

The 18.x release line of Node.js is vulnerable to 2 low severity issues, 2 medium severity issues and 1 high severity issue and the OpenSSL vulnerabilities.

The 16.x release line of Node.js is vulnerable to 2 low severity issues, 2 medium severity issues, and 1 high severity issue and the OpenSSL vulnerabilities.

The 14.x release line of Node.js is vulnerable to 1 low severity issue, and 1 high severity issue and the OpenSSL vulnerabilities.

Releases will be available on, or shortly after, Tuesday February 14 2023.

The current Node.js security policy can be found at https://nodejs.org/en/security/. Please follow the process outlined in https://github.com/nodejs/node/blob/master/SECURITY.md if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organization.

CVE-2023-23920: Thursday February 16 2023 Security Releases | Node.js

A flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.

Seth found that the CPU-entry-area; the piece of per-cpu data that is mapped into the userspace page-tables for kPTI is not subject to any randomization -- irrespective of kASLR settings. On x86\_64 a whole P4D (512 GB) of virtual address space is reserved for this structure, which is plenty large enough to randomize things a little. As such, use a straight forward randomization scheme that avoids duplicates to spread the existing CPUs over the available space. \[ bp: Fix le build. \] Reported-by: Seth Jenkins <sethjenkins@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de>

@@ -130,10 +130,6 @@ struct cpu\_entry\_area {

};

#define CPU\_ENTRY\_AREA\_SIZE (sizeof(struct cpu\_entry\_area))

\-#define CPU\_ENTRY\_AREA\_ARRAY\_SIZE (CPU\_ENTRY\_AREA\_SIZE \* NR\_CPUS)

\-

\-/\* Total size includes the readonly IDT mapping page as well: \*/

\-#define CPU\_ENTRY\_AREA\_TOTAL\_SIZE (CPU\_ENTRY\_AREA\_ARRAY\_SIZE + PAGE\_SIZE)

DECLARE\_PER\_CPU(struct cpu\_entry\_area \*, cpu\_entry\_area);

DECLARE\_PER\_CPU(struct cea\_exception\_stacks \*, cea\_exception\_stacks);

@@ -11,6 +11,12 @@

#define CPU\_ENTRY\_AREA\_RO\_IDT\_VADDR ((void \*)CPU\_ENTRY\_AREA\_RO\_IDT)

\-#define CPU\_ENTRY\_AREA\_MAP\_SIZE (CPU\_ENTRY\_AREA\_PER\_CPU + CPU\_ENTRY\_AREA\_ARRAY\_SIZE - CPU\_ENTRY\_AREA\_BASE)

+#ifdef CONFIG\_X86\_32

+#define CPU\_ENTRY\_AREA\_MAP\_SIZE (CPU\_ENTRY\_AREA\_PER\_CPU + \\

\+ (CPU\_ENTRY\_AREA\_SIZE \* NR\_CPUS) - \\

\+ CPU\_ENTRY\_AREA\_BASE)

+#else

+#define CPU\_ENTRY\_AREA\_MAP\_SIZE P4D\_SIZE

+#endif

#endif /\* \_ASM\_X86\_PGTABLE\_AREAS\_H \*/

@@ -266,7 +266,7 @@ static inline bool within\_cpu\_entry(unsigned long addr, unsigned long end)

/\* CPU entry erea is always used for CPU entry \*/

if (within\_area(addr, end, CPU\_ENTRY\_AREA\_BASE,

\- CPU\_ENTRY\_AREA\_TOTAL\_SIZE))

\+ CPU\_ENTRY\_AREA\_MAP\_SIZE))

return true;

/\*

@@ -16,16 +16,53 @@ static DEFINE\_PER\_CPU\_PAGE\_ALIGNED(struct entry\_stack\_page, entry\_stack\_storage)

#ifdef CONFIG\_X86\_64

static DEFINE\_PER\_CPU\_PAGE\_ALIGNED(struct exception\_stacks, exception\_stacks);

DEFINE\_PER\_CPU(struct cea\_exception\_stacks\*, cea\_exception\_stacks);

\-#endif

\-#ifdef CONFIG\_X86\_32

+static DEFINE\_PER\_CPU\_READ\_MOSTLY(unsigned long, \_cea\_offset);

+

+static \_\_always\_inline unsigned int cea\_offset(unsigned int cpu)

+{

\+ return per\_cpu(\_cea\_offset, cpu);

+}

+

+static \_\_init void init\_cea\_offsets(void)

+{

\+ unsigned int max\_cea;

\+ unsigned int i, j;

+

\+ max\_cea = (CPU\_ENTRY\_AREA\_MAP\_SIZE - PAGE\_SIZE) / CPU\_ENTRY\_AREA\_SIZE;

+

\+ /\* O(sodding terrible) \*/

\+ for\_each\_possible\_cpu(i) {

\+ unsigned int cea;

+

+again:

\+ cea = prandom\_u32\_max(max\_cea);

+

\+ for\_each\_possible\_cpu(j) {

\+ if (cea\_offset(j) == cea)

\+ goto again;

+

\+ if (i == j)

\+ break;

\+ }

+

\+ per\_cpu(\_cea\_offset, i) = cea;

\+ }

+}

+#else /\* !X86\_64 \*/

DECLARE\_PER\_CPU\_PAGE\_ALIGNED(struct doublefault\_stack, doublefault\_stack);

+

+static \_\_always\_inline unsigned int cea\_offset(unsigned int cpu)

+{

\+ return cpu;

+}

+static inline void init\_cea\_offsets(void) { }

#endif

/\* Is called from entry code, so must be noinstr \*/

noinstr struct cpu\_entry\_area \*get\_cpu\_entry\_area(int cpu)

{

\- unsigned long va = CPU\_ENTRY\_AREA\_PER\_CPU + cpu \* CPU\_ENTRY\_AREA\_SIZE;

\+ unsigned long va = CPU\_ENTRY\_AREA\_PER\_CPU + cea\_offset(cpu) \* CPU\_ENTRY\_AREA\_SIZE;

BUILD\_BUG\_ON(sizeof(struct cpu\_entry\_area) % PAGE\_SIZE != 0);

return (struct cpu\_entry\_area \*) va;

@@ -211,7 +248,6 @@ static \_\_init void setup\_cpu\_entry\_area\_ptes(void)

/\* The +1 is for the readonly IDT: \*/

BUILD\_BUG\_ON((CPU\_ENTRY\_AREA\_PAGES+1)\*PAGE\_SIZE != CPU\_ENTRY\_AREA\_MAP\_SIZE);

\- BUILD\_BUG\_ON(CPU\_ENTRY\_AREA\_TOTAL\_SIZE != CPU\_ENTRY\_AREA\_MAP\_SIZE);

BUG\_ON(CPU\_ENTRY\_AREA\_BASE & ~PMD\_MASK);

start = CPU\_ENTRY\_AREA\_BASE;

@@ -227,6 +263,8 @@ void \_\_init setup\_cpu\_entry\_areas(void)

{

unsigned int cpu;

\+ init\_cea\_offsets();

+

setup\_cpu\_entry\_area\_ptes();

for\_each\_possible\_cpu(cpu)

CVE-2023-0597: git/torvalds/linux.git - Linux kernel source tree

Generative AI is heating up everywhere and fundamentally changing everything we know about how cybercriminals develop and deploy attacks.

There has been a lot of talk about generative AI and chatbots like ChatGPT launching cyberattacks. What does that mean for the future of cybersecurity, and how can organizations prepare?

Threat actors are using ChatGPT to launch cyberattacks now. ChatGPT allows threat actors to increase the speed and variation of their attacks by modifying code in malware or creating thousands of variations of social engineering attacks to increase the probability of success. As machine learning technologies advance, so will the variety of ways this technology is used for malicious intent.

Generative AI is heating up everywhere and fundamentally changing everything we know about how cybercriminals develop and deploy attacks with increased speed and variations. The possible uses of AI for malicious intent are in their infancy. AI-powered technologies that leverage generative AI and diffusion models can modify the appearance of video and voice. They will most likely be used for cyberattacks, resulting in unfortunate consequences for organizations.

A race to develop new technologies leveraging AI is happening in voice (written and verbal), video, and more, as is evidenced by OpenAI's ChatGPT, Google's Bard, and Microsoft's AI-powered Bing. All are large language models that exponentially accelerate access to knowledge and rapidly generate new forms of content based on that contextualized knowledge. These tools rely on big data sets and the quality of those data sets.

While ChatGPT has the initial lead as the fastest-growing tool in history, don't bet against Google's ability to surpass ChatGPT in the future. It will certainly be a race, unlike anything we've seen before. As these new technologies become available, they will be used by organizations and cybercriminals, and both sides will use them to perpetrate and stop cybercrime. The abuse of AI is something we knew would happen for a long time, which is why SlashNext engineers have been developing natural-language generative AI technology for a few years in anticipation of these types of changes in the threat landscape.

**How Real the Generative AI Threat Is and How Organizations Can Prepare**

Generative AI, chatbots, and diffusion models are all developments in AI that present a real danger to users and businesses. Right now, ChatGPT, in particular, is a real enhancement to malware, business email compromise (BEC), and ransomware threat development. Cyberattacks are most dangerous when delivered with speed and frequency to targets.

With malware, ChatGPT enables cybercriminals to make infinite code variations to stay one step ahead of the malware detection engines. BEC attacks are target attempts to social engineer a victim into giving valuable financial information or data. These attacks require personalized messages to be successful. Now ChatGPT can create well-written, personal emails en masse with infinite variations. The speed and frequency of these attacks will increase and yield a higher success rate of user compromises and breaches. Legacy security technology doesn't stand a chance against these types of attacks. 

We must fight AI cyber threats with AI cybersecurity technology. When cybercriminals launch successful attacks, the results are massively disruptive to people, organizations, and the economy. The No. 1 cyber challenge that organizations face globally is human-focused attacks. Cybercriminals are increasing their attacks in LinkedIn, Microsoft Teams, Messenger, and Slack and taking advantage of the most vulnerable part of organizations: its people.

Many organizations are already using AI-based cybersecurity products to manage detection and response. AI technologies with generative AI will become essential technology to stop hackers and breaches. As new technology becomes available, hackers and cybersecurity vendors will use it to perpetrate and stop cybercrime. The abuse of AI is something we knew would happen for a long time, which is why SlashNext has been developing a natural-language generative AI technology for a year and a half in anticipation of these types of threats.

ChatGPT is not new, but OpenAI is the first to make an interface, so it's more accessible. ChatGPT is not the technology to fend off threats designed with ChatGPT. Still, generative AI technology, which makes ChatGPT possible, will be used to develop cyber defenses capable of stopping malware and BEC threats developed with ChatGPT. 

**About the Author**

    

Patrick Harr is the CEO of SlashNext, an integrated cloud messaging security company using patented HumanAI™ to stop BEC, smishing, account takeovers, scams, malware, and exploits in email, mobile, and Web messaging before they become a breach.

Generative AI Changes Everything We Know About Cyberattacks

Security Pro File: The old-school hacker traces a path from young hardware tinkerer to senior cybersecurity executive.

Before he was Space Rogue, before L0pht, before testifying in front of Congress about what used to be a very unknown risk of networked computers, and before he embarked on a career in cybersecurity, he was just young Cris Thomas with a homemade flashlight.

Growing up in a mobile home in rural Maine in the 1970s, Thomas didn't have a whole lot of access to technology in his early years. But at the tender age of five, armed with a hammer and a worn-out sealed alkaline flashlight — the kind that you threw away after the batteries lost their juice — he was able to first learn the basics of electrical circuits. Cannibalizing parts from those flashlights and adding C and D cell batteries and wires consisting of garbage bag twist ties, he was in business with his very own lighting device.

That kind of tinkering is the very essence of a hacker's modus operandi, and it was the start of his love affair with hacking and his eventual profession as a cybersecurity leader. Over the years, Thomas has done stints at the likes of Trustwave Security, Tenable, and almost six years now at IBM as Global Lead of Policy and Special Initiatives. But at its root his beginnings have all the same flavor of self-directed experimentation and trial-and-error with his flashlight. His route was circuitous and full of ups and downs, but he says that in some ways it was easier for him to go down that path than those trying to get their break in cybersecurity today without the traditional path straight from college.

"There's still people who are trying to break into the industry with little to no formal education, and the debate of college or certifications is still raging. So, I think getting into the industry, from an austere beginning and maybe even skipping the formal education and being self-taught — it is possible," he says. "It's a lot more difficult today, because I think people put a lot of importance on the college degree and the formal education, and so it's hard to get around that stigma."

After early grade school he moved to a bigger town, was exposed to computers in bits and pieces, and mastered the basics of BASIC from chance encounters, clubs, and high school computer class. But it wasn't until he was in the Army that he was able to buy his very own computer, a Mac SE he bought on credit from a store nearby his base. It was from this machine he dug further into programming and got synced up with his first local user group, a Mac HyperCard user group. From there he branched out into BBSs and began to tap into the burgeoning Internet hacker subculture. After the Army and a brief stint at Boston University, he took the handle Space Rogue, dialing into the Boston BBSs. Many of those had a whole underground world of in-person meet-ups attached to them. Running in those circles — plus holding down a job at a local CompUSA where a number of local hackers worked — is what would eventually lead Space Rogue to the ragtag group of hackers called L0pht.

**Remembering the L0pht**

A collective of elite hackers and a hackerspace rolled into one, the L0pht is one of those storied groups that's inextricably tied in with the infancy of the cybersecurity industry. In a book published this month, _Space Rogue: How the Hackers Known as L0pht Changed the World_, Thomas writes the memoir of his winding journey to hacking and his membership in the group.

Space Rogue was one of the earliest members and was heavily involved in the group's adventures and hacking experimentation. He was there for its evolution into what would become L0pht Heavy Industries, its release of the L0phtCrack password-cracking tool, and its eventual sale to @Stake. Together with hackers like Mudge, Weld Pond, Kingpin, Dildog, tan, and Stefan von Neumann, they were on the bleeding edge of experimentation with hardware and software — partially from scavenging corporate dumpsters for equipment, partially from soliciting donations and picking up cool finds at the MIT Flea Market, where they also sold refurbished gear to partially fund their loft space. The crew ran their own NOC, experimenting with different forms of networking, and they shared files online through the early version of the L0pht.com server. Space Rogue ran the popular Whacked Mac Archives, a collection of software collected from underground systems and BBSs over the years. He did the books and paid the bills as an unofficial chief operating officer and was also instrumental in helping raise the profile of the group by founding and running Hacker News Network and helping to coordinate a lot of its work with the media.

The work the L0pht did for a very long time was simply a labor of love — the hackers had day jobs. In their off-hours time of experimentation they started learning how truly vulnerable systems are to manipulation and exploitation in ways unexpected by their creators. As the team evolved, they started picking up gigs writing custom signatures for the first incarnations of intrusion detection systems, issued advisories about vulnerabilities on their website and Bugtraq, and were courted by firms to do pen testing. For a long time they barely broke even, but their security chops did gain the attention of the federal government, and in 1998 Space Rogue and six other core members of the L0pht stepped in front of a Congressional panel to give one of the earliest public warnings about the state of insecurity of the online world.

Thomas does a great job detailing all of these happenings in his book, which offers a very personal and open account of his perspective on how things unfolded. He does a great job highlighting the personalities and mindsets of the different hackers he worked with or came across over the years, and is very relatable and vulnerable offering thoughts on his maturing perspectives on dealing with not just systems but also people. Readers get to follow along with his close connections with hacker friends, fallouts and reconciliations, and run-ins with difficult bosses, as well as career disillusionment and rebirth.

**What's in a Handle?**

Musing about the L0pht and his book recently, he notes that while his unconventional learnings and rise through cybersecurity could probably be emulated by newcomers, the rise of L0pht itself occurred during a very unique era in time and would be a whole heck of a lot more difficult to recreate.

"I mean, you can get a bunch of people together and rent some space and do some stuff, but getting the same attention would be harder because the bugs are harder to find now," he says. He explains that what L0pht did wasn't easy, but they found the low-hanging fruit in security flaws.

They also had a lot less red tape and legal and professional standards to navigate. Doing what they did back in the 1990s today would put most cybersecurity researchers in a lot of hot water.

"There's a lot more risk involved. I mean, there was risk then too, but if you're going to release information about a zero-day vulnerability to the public without a pseudonym, the risk of lawsuits is pretty high. Which is, again, one of the reasons why we were using the handles and the pseudonyms to begin with. But staying pseudonymous is a lot more difficult today than it was."

Thomas still cherishes and uses his Space Rogue handle — it's part of his online and professional persona. For example, his email address at IBM is based on that handle rather than his real name.

"I built a reputation as Space Rogue within the industry. I was the last member of the L0pht to actually start using their given name in professional settings," he says. "So it's only been a few years for me, really, that people have looked at the handle and been able to equate it to the given name easily."

These days, Mudge is known as Peiter Zatko, who worked at DARPA and Google in key roles, and most recently in the news as the Twitter whistleblower who drew attention to the social network's lacking security stance. Weld Pond is Chris Wysopal, who co-founded Veracode. Kingpin is Joe Grand, a well-known security researcher and author who runs Grand Idea Studio. But when they see each other, they'll always be Mudge, Weld, and Kingpin to him.

"And for the most part, people still address me as Space Rogue or SR. At work, people call me Space, and occasionally I'll get Mr. Rogue, but that's usually as a joke," he says. "My wife actually referred herself in a Twitter thread the other day as Mrs. Space Rogue."

**Looking Back at Industry Change**

All kidding aside about handles, Space Rogue is still as much of a concerned industry watcher as those days back at the L0pht, stepping in front of federal lawmakers.

"I've always been interested in policy and how legal ramifications are impacting the online world. Right now, I'm following a lot of actions of CISA, and I have to say that as a nation we're actually doing a great job," he says. "In the past, government has been behind schedule and playing catch-up, but I think CISA's actually taken a very good, proactive approach, which is a welcome change in the industry."

At the same time, though, he says that there's this dichotomy in cybersecurity where over the last 25 years, everything has changed but is also still the same. There's a ton more awareness now, not just from policy makers or industry insiders but just individual workers or non-tech business executives, about things like ransomware or phishing.

"Most people have to go through some sort of security training in their job, so the awareness factor is much higher," he says.

At the same time, though, the cybersecurity world is still knocking its head against the same problems it did decades ago.

"We're making stupid mistakes. We're using default passwords. We're designing flat networks. And these are the same problems that we had 25 years ago," he says. "So, it's a little bit of some and a little less of some other stuff. A lot of things have changed and gotten better, but a lot of things have still stayed the same as well."

**PERSONALITY BYTES**

**What he does for fun:** A lot of treasured hobbies mirror his hacking interests — his fun project at the moment is setting up a Raspberry Pi for his son to help him learn Python and picoCTF. "You can't get Raspberry Pis at the moment, so I've had to cannibalize some of my old projects to get him one that he can use."

**Non-hacking hobbies:** There was a time he was into making hard cider, but he moved and had less room for all of the equipment. Now he's turned his sights to rock tumbling. "My youngest got a rock tumbler last year and never used or was very interested in it. And I was like 'Well, if you're not going to use it, I'm going to.' Now I have four tumblers and I'm rotating rocks in the basement all the time."

**Quirky tidbits:** He says he's kind of an open book, and shares a lot of fun stuff with co-workers via Slack, so there's nothing they'd be surprised to know about him. But like many folks in the industry, he's got his quirky interests. "I'm a big Saturn car aficionado."

**Favorite day-to-day drink:** "I drink a lot of caffeine-free Diet Coke."

**How he tells people what he does for a living:** Per his book, he wrote, "I rarely blurt out 'Hi, I’m a hacker' when I first meet people. Trying to explain to people what I do for work can sometimes be tricky and lead into all sorts of long and sticky conversations, so I usually just say I work in computers."

Tag

#google