Profile for joern
About joern
Fields
- Website
- https://0day.click
- Threema
- https://threema.id/K8J68WTX
Bio
Your mom's favorite hacker!
My other account is @joernchen
- Joined
- Posts
- 687
- Followed by
- 1129
- Following
- 261
Stats
Recent public posts
exclude boostsHot Take: we should stop putting those "for educational purposes only" disclaimers on offensive security software. They are not legally binding and probably provide no real protection. Plus every OSS license already has a no-liability clause. Continuing to put those disclaimer on software has the same energy as those "confidential email, do not distribute" disclaimers people put on their outgoing emails; which are also not legally binding because reading a disclaimer is not the same as signing a legal document.
we pwned @tailscale ❤️
ft. @jamie
https://emily.id.au/tailscale
Mastodon in a week has gone from “I can read all posts in 15 minutes” to “i can’t keep up”. Well done.
the Berkeley Packet Filter (BPF) is a subsystem of many Unix operating systems wherein all packets are sent to a server in Berkeley, California, which has the firewall rules on it.
Ooooohkay, who are the fun and irreverent people you're following here? Bonus points for sweary and witty.
I need some levity among the intellectualism in my feed.
Shitposting meta
Shitposting in the fediverse: so much joy.
Birdsite shitposting seems mostly about Mr. Musk nowadays.
“Boost my toot” sounds weirdly sexual.
SHITPOSTING
is an anagram of
TOP INSIGHTS
hot take: you should be suspicious about anyone who unironically boasts about being on the forbes 30 under 30 list.
1. it's actually like 600 under 30 and they know it
2. it's largely meaningless cuz (at least back in the day) all you had to do was be friends with someone who worked at Forbes to make the list in some of the categories that Forbes didn't know much about
3. if you actually try to get on the list, you probably value self-promotion/networking more than you should
i am on the list for completely dumb reasons and i hope people stop taking it seriously.
There’s been a lot of discussion about a rule we recently instituted regarding security testing on the infosec.exchange instance. I understand the value or pen testing as much or more than most people, and I’m fully cognizant that pen tests are happening all the time and I’m not getting the report. I get it. But there are now 28,000 people using this service to communicate. I know there are vulnerabilities waiting to be discovered. Finding blog post fodder by fuzzing instances that are already running hot due to explosive growth is not super helpful. But at the same time, I WANT that testing to happen.
As a result, I am going to set up two instances tomorrow that only federate with each other. This is where I’d prefer legitimate security testing be performed. I’ll also be using it as the QA environment to test new updates and settings prior to deploying to the production instance. I’ll moderate signups because I don’t want it accidentally becoming fediverse 2.0 in the ongoing rush for the doors at twitter, but will accept anyone who wants to join, with clear indications that it’s a sandbox and should not be considered safe.
Thanks for patience as we continue to find out way.
If anyone knows any entry level/ junior prodsec folks looking for a gig, HMU. Fully remote anywhere in the US.
Arbeitet hier wer zufällig mit PCR-Testmaschinen?
Es gab ja Anfang des Jahres die Situation, dass BA.2-Varianten nicht per PCR detektiert wurden (https://www.beckershospitalreview.com/lab/new-omicron-variant-doesn-t-show-up-on-pcr-tests-10-things-to-know.html).
Ist das immer noch so bzw. für ganz aktuelle Varianten wieder?
Situation bei den betroffenen Personen ist: Eindeutige Symptome und deutlich positiver Schnelltest, aber PCR kommt "negativ" zurück. Die Sorte (Longsee) und auch diese spezifische Charge Schnelltests ist erprobt und zuverlässig (in beide Richtungen).
Oops. I accidentally deleted the original toot. I was trying to issue an update on my toot about twitter censorship and didn’t realize deleting a reply toot would bork the whole thread 🤦🏾♀️
From what I've gathered, it seems that Twitter blocking joinmastodon.com is a ~special case~ as the domain used to resolve to a spam website. I'm not sure how long the .com domain has been pointed to the official joinmastodon.org but recommend sharing the .org instead. #mastodon #twittermigration #Twitter
Bugfinders' law: The most interesting things are found 5 minutes before a meeting.
The first one on finding vulnerabilities in hard targets! For those starting out and some general thoughts from over the years on software security:
1. Developer mindset vs Adversarial mindset - Code review as a bug hunter is often different from code reviewing as part of feature change. As a bug hunter you are only focusing on how to circumvent a control or use in a way it was not intended. Learning this mindset is key.
2. Going Deep vs Going Wide - Researching a target there is a trade off between going deep and going wide. If you have no knowledge then going wide helps to discover potential weak areas and build up a mental model. At some point it becomes important to focus down and refine.
3. Target Biases - Its common to think because something is well established then there will be less bugs lurking there. However, most software is evolving and new features are constant being added. This new code is often a really good source of bugs.
4. Fuzzing Enhancements - As code moves on over time, developers need to create test code. This means that often this new code misses test coverage or has no tests at all. Binary diffing, API change logs and software update analysis are a great way to extend fuzzer coverage.
5. Code/binary review led fuzzing - It can be very challenging to spot certain bugs using only code review or binary analysis. Combing the approach allows to identify complexity and focus fuzzing to weak areas which may lead to vulns you would have not spotted with pure code review alone.
6. Variant Analysis - As a researcher most of the bugs you find will not be particularly novel and are generally abstractions of a common vulnerability pattern. Knowing how to recognise these patterns and integrating into your toolset to allow faster identification is a must.
7. Research Tracking - In the area you are researching it is important to keep up-to date on published material. As new attack surfaces are unearthed or new vulnerability classes are identified then taking this knowledge and integrating it into your tooling is important
8. Collaboration - You can get quite far solo in bug hunting, however being able to work in a team allows effective use of the team members specialisation and allows for distribution of work. It helps with motivation on the VR emotional rollercoaster when failure is common.
9. Bug Tracking - Whilst going for the most impact as possible is the goal, reaching that goal may require many other lesser impact vulnerabilities chained together. As you are performing your research it is important to make notes of literally anything of potential value.
10. Target Knowledge Base - Whilst you are doing this research and afterwards it is important to maintain a target knowledge based. Building on existing knowledge is much easier than coming from zero knowledge of the target. Really helps if you switch between targets lots.
For the #Mastodon #server instances out there, is there a guideline on drive space that anyone could recommend? If I ran an instance it would be a user base of just a handful, but I’m curious about storage limits. The other issues with being an #administator I think I can track down, but this is alluding me.
Dumb Question, and I'm sure it's been asked before, but is there a repo somewhere of trivially exploitable *nix binaries for testing/demo purposes? Preferably with Makefiles that disable all of the fancy mitigations.
#appsec #exploitation #exploitdev #binaries

