mastodon
4.6.0-alpha.5+glitch
securing software @ corp
vulnz.ch's first edition will take place on Thursday, March 5th at HeadsQuarter The Historic in Zurich. Yusuf will present on Android userspace exploitation and Jannis will cover reverse engineering black-box binaries with symbolic and concolic execution techniques. If you're into appsec, pentesting, vulnerability research, or anything in between, come join us!
vulnz.ch is a meetup I've been thinking about for a while. It's something I wanted to exist but couldn't find.
The idea is simple: bring together Zurich-based folks for a space dedicated to sharing knowledge about software security. That could mean presenting your analysis of an academic paper you've read, demoing a fork of an open source project you've been experimenting with, or showing off a tool you built during late-night coding sessions.
The first meetup is now being shaped, and the website is up and running. Check out vulnz.ch and sign up if you're interested in joining.
Judging by the 2020s cadence, there is a 50% chance of having another @phrack@haunted.computer Magazine release next year.
Why not have all the articles in the new issue directly piped into your favourite RSS reader?
The "Related Work" section in academic papers paints a high-density, medium-fidelity, and low-noise picture of the state-of-the-art in a scientific topic.
The previous Monday, @troyhunt@infosec.exchange the creator of @haveibeenpwned@infosec.exchange made another stop on his Have I Been Pwned Alpine Grand Tour, visiting countries like Germany, France, Italy, and Switzerland to discuss his work. Several Zurich user groups were fortunate to hear him speak on various topics and join him for drinks afterward. His presentation covered his experience testifying before the U.S. Congress, some of the most significant breaches tracked on the platform, and insights into how Have I Been Pwned operates
After discovering that the data is accessible via the API and noticing the lack of a visualization tool, I dedicated a few evenings to building haveibeenpwned.watch. This single-page website processes and presents data on leaks from Have I Been Pwned, with daily updates.
The site provides details on the total number of recorded breaches, the number of unique services affected, and the total accounts compromised. Charts break down the data by year, showing the number of breaches, affected accounts, average accounts breached per year, accounts by data type, and accounts by industry. Additionally, tables highlight the most recent breaches, the most significant ones, and the services with the highest number of compromised accounts.
Though simple, the website can be a useful resource for use cases like strategic security planning, cybersecurity sales, risk assessment, or simply tracking trends in the security landscape.
The website is open source, with its repository hosted on GitHub.
Feel free to share any feedback or submit a pull request if you’d like to contribute.
Troy, thank you for hosting these in-person talks and for creating this essential service that the internet relies on!
[1] https://haveibeenpwned.watch
[2] https://github.com/iosifache/haveibeenpwned.watch
One should fear becoming a librarian who hoards data without acting on it.
I don't mind if it's a choice or just the luck of picking the right WordPress theme, I salute the VCs with websites that have RSS feeds.
In war, proselytism, and business:
Cover the basic needs of neutral parties or enemies, and they will become your allies by their own will.
> you publishing this kind of information without our approval can be interpreted as confidential information disclosure, favoring cyber attacks or even complicity in the case of an incident
She calmly dropped this line during our WhatsApp call when I asked about sharing details on a vulnerability on my blog or on this platform. The call came after I emailed them the day before about a flaw in a publicly accessible, open-source security solution deployed by an institution. I tried to change her mind for a few minutes, but her position was clearly locked in at the institutional level.
I suggested a few ways they could step up their game:
• Clearer reporting process: Their website had no security contact or security.txt file. I had to hit up an acquaintance just to figure out who to reach.
• Deploying fixes: They said the vulnerability was a known issue and just one of many defences they had, so they wouldn’t fix it. Next time, they might hear about it from a shady, ill-intentioned actor hiding behind Onion proxies and VPNs.
• Securing open source: They were using a lesser-known open-source codebase with no hardening or obfuscation. A quick OSINT search revealed the exact repository they used, turning my impromptu black-box audit into a white-box review of a vulnerability-prone codebase.
• Community collaboration: The gov'ts should set up reputation-based bug bounty platforms with identity-verified volunteers. It’d need legal changes, but trusted civilians with diverse backgrounds flagging issues beats finding out during a breach.
We talked about other stuff, and I gave props to their hard work. After hanging up, I zoned out, struck by how their approach clashed with the classic vulnerability disclosure process from the open-source and bug-bounty worlds I know:
• Confidentiality and forced disengagement: Did they really know about the issue already? She told me that, yes, but I have no clue if this is true. Are there other defences in place? She says so, but I can’t see past the edge system I tested. Will I know if they fix it? Not officially, though I could check online. It felt almost like gaslighting.
• Legislation as a defensive layer: She played the legal trump card, citing specific laws that boxed me in. I was checkmated with no counter move.
A few seconds later, I snapped out of it, brewed another coffee, and got back to my day’s tasks.
By now, the AI labs should have become customers of social media scrapers, as there is plenty of feedback available through open channels that can be collected, summarised, and used to guide their development roadmaps.
Pattern in wealthy or moderately wealthy countries in Europe:
Low-paying jobs are no longer taken by locals, who generally seek higher wages, and often boomerang to their parents’ house or exploit the advantages of local currency through socially-inflated roles, such as public sector positions, manipulating others, or climbing the ranks within political parties with no prior experience — just to name a few examples.
These jobs are instead filled by hardworking immigrants from poorer Asian or African countries. With their hearts back home, they tend to view the host country primarily as a source of income, whether as a permanent destination or a temporary stop on their way further west. As a result, original cultures, languages, and traditions are getting diluted.
It’s saddening, but it’s a predictable outcome given the economic incentives involved.
The materials for the “Fuzzing in the Open” workshop are now available on GitHub [1]. You can find the presentation slides and practical files that we used during the workshop at the Ubuntu Summit two weeks ago [2].
Thanks to Dongge Liu and Jiongchi Yu’s insights into fuzzing, OSS-Fuzz, and open source, we garnered a lot of interest in the workshop, filling the room to capacity! From a personal perspective, it was also wonderful to see friends working on OSS projects or at Canonical attending the workshop. And thanks to Tatjana Dubrovica, the Latvian vaniļas zefīrs [3] are now the pinnacle of sweet treats I’ve ever had.
[1] https://github.com/iosifache/fuzzingintheopen
[2] https://events.canonical.com/event/51/contributions/540
[3] https://laima.lv/lv/product/laima-vanilas-zefirs
The previous year, fuzzing was one of the topics I covered in my Ubuntu Summit workshop (as in The Open Source Fortress [1]). It was such a groovy experience, and I’m fortunate that I can repeat it on Ubuntu’s 20th anniversary.
Dongge Liu, Jiongchi Yu, and I were accepted to this year’s conference with a 1.5-hour workshop [2] targeting open-source projects that play a role in the overall Internet infrastructure. We will detail how such projects can get integrated into Google’s OSS-Fuzz [3] to benefit from free-of-charge continuous fuzzing. As the workshop is made possible by Jiongchi’s contributions to Google Summer of Code (more on this topic in another post) [4], he will also describe his work in integrating OpenPrinting’s projects (mostly built on C) into OSS-Fuzz.
The conference will also host two other talks on tools improving open-source security. Cristóvão Cordeiro will present his work on Chiselled Ubuntu containers (i.e., distroless-like containers intentionally trimmed down to decrease their size and attack surface) [5], and the folks from Bitergia will discuss their work on GrimoireLab (i.e., risk assessments for open-source dependencies) [6].
If you’ll be in The Hague this week for Ubuntu Summit, I hope to see you in the workshop room and hang out during the HackerSpace organised the same evening. Otherwise, the presentation and materials will be made public shortly after the conference.
[1] https://ossfortress.io
[2] https://events.canonical.com/event/51/contributions/540
[3] https://google.github.io/oss-fuzz
[4] https://summerofcode.withgoogle.com/programs/2024/projects/QX4kRWZO
[5] https://events.canonical.com/event/51/contributions/520
[6] https://events.canonical.com/event/51/contributions/594
Startups may be afraid of receiving genuine, direct feedback on their ideas, so they use alternative methods such as LinkedIn messages to unknown people who convinced to spend 5 minutes checking a demo, boring feedback forms with generic questions, or installing tracking tools such as Hotjar in the hope of observing similarities in user behaviour.
This is not true for Noema [1] and their AutoHack project! The goal of the latter is to programmatically create multi-staged cybersecurity scenarios that can subsequently be used with AI models to assess their adversary capabilities. They intend to initially test this method in a unique way: they will challenge specialists with hacking scenarios, collect proper feedback from them, and reward the top three players with a $10.000 (yeah, that's right, there are four zeros) prize pool.
So, if you are interested in practical cybersecurity exercises that simulate real-world circumstances, wish to help to the advancement of AI safety, and win a few thousand bucks, simply read the full announcement on their website [2] and fill out the application form [3]!
[1] https://noemaresearch.com
[2] https://noemaresearch.com/blog/join-autohack-2024-tournament
[3] https://docs.google.com/forms/d/e/1FAIpQLScZKrLlCe1LWrEKqc4GpBmu8ylaF8rXkraBDgUJfT7o7rj9nA/viewform
I'm joining this year the AppSec Village and @defcon@defcon.social folks in challenging the old saying, "What happens in Vegas, stays in Vegas".
On the 9th of August, starting at 3 p.m. for 2.5 hours, I will be hosting the Open Source Fortress workshop [1] in the AppSec Village as part of DEF CON [2].
The purpose of the workshop will be aligned with those from the previous conferences it was presented in, namely to empower security engineers with public AppSec information [3] and a handy open source toolkit for vulnerability discovery. The stories may be different: no AppSec tooling at all, limited budgets for the security dept, or compute power that can be burned on new CI pipelines with quality gates. What matters is that these tools [4], put in the open by passionate people, can be used to level up the security posture of the codebases or catch bugs that other scanners missed.
The Goat-like vulnerable application that is analysed during the workshop, the Sand Castle [5], also got an update. There are new XSSes, CSRFs, and SSRFs to be discovered with open source tooling. The wiki was also made more expert-friendly, with the ability to hide hints and beginner pages.
If you are at DEF CON, join the workshop! You'll leave with new AppSec knowledge and hands-on practice, some Swiss chocolate, stickers, and, for the most competitive of you, some prizes. See you in Vegas!
[1] https://ossfortress.io
[2] https://www.appsecvillage.com/events/dc-2024/the-open-source-fortress-finding-vulnerabilities-in-your-codebase-using-open-source-tools-677630
[3] https://github.com/iosifache/oss_fortress
[4] https://ossfortress.io/analysis-infrastructure#docker-infrastructure
[5] https://ossfortress.io/sandcastle
I recently realised that PyPi's security team is similar to first responders such as paramedics and firefighters. Why? The work of both is catalysed by the assistance of a volunteer-based social system.
First responders are aided by the Red Cross's Disaster Action Team [1]. This team, usually composed of two to three people, serves as first responders at a disaster scene. While they may not be as experienced and well-prepared as institutional staff, they can act more quickly than the first responders, helping to mitigate the damage. Conversely, PyPi administrators receive reports from individuals and companies conducting proactive research and discovering Python malware distributed through the repository. This symbiosis is due to the lack of reliable automated open-source tools detecting malware by looking at the source code.
The above was just a single insight I developed after creating the latest @ubuntusecurity@fosstodon.org Podcast episode. We are examining a paper called "Bad Snakes: Understanding and Improving Python Package Index Malware Scanning", which I discovered while watching Zachary Newman's presentation at the Open Source Summit 2023. In addition to presenting the PyPi security ecosystem, the paper also details the PyPi administrators' requirements for a mature malware analysis tool and explains why the current open-source malware detection solutions don't tick the boxes.
Curious enough? The episode is already available on podcast platforms [2], and the show notes can be found on our website [3]!
[1] https://www.redcross.org/volunteer/disaster-action-team.html
[2] https://ubuntusecuritypodcast.org
[3] https://ubuntusecuritypodcast.org/episode-221/#resources