threatactor.club

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

@joern Alles locker im Docker.

Free #ctf idea: use ECDSA wrong by signing a message directly instead of a hash. ECDSA on P-256 for example will only sign the first 32 bytes, the rest you can change however you want.

(original source https://www.inforisktoday.com/twitter-two-factor-authentication-has-vulnerability-a-20475, but that was me confirming it)

I'm absolutely losing it

Must remember not to open twitter anymore
Must remember not to open twitter anymore
Must remember not to open twitter anymore
Must remember not to open twitter anymore

I feel like I need something for my blood pressure after that.

Anyhow, how is everyone doing?

"This issue is Volume One, Issue One, released on November 17, 1985."

http://www.phrack.org/issues/1/1.html

Don't mind me, just storing my account recovery codes here because we're all friends.

Dropbox

sqa7 brix
vwaf k2qm
oyda bgck
blmg hhsy
l93f trww
z1cp 0c1l
6vlt 320e
l5hn rwq1
kdnf nmky
9ddn vh61

Facebook

7147 3084
6298 3780
2148 1878
5145 7791
3876 0444
8851 9256
2864 9061
3518 2411
1516 0291
2696 9257

Reddit

154891
915269
271083
393744
451820
516234
773634
233741
018590
502965

Google

8092 1121
9389 5246
3872 9286
4760 8952
2566 5417
5864 8282
3296 8476
4689 7152
0387 3760
4304 5896

Boost this toot if you're planning on sticking around Mastodon whether or not it becomes more popular than the birdsite.

Idea for the Windows bug bounty.. I call it the "Prove it" award. If we classify your bug as a DOS or not exploitable and you resubmit the bug with a working exploit that proves us wrong. We pay you 10x (or some large number) the original bounty. thoughts? #bugbounty

We're about 15 seconds away from someone getting Elon to open devtools, type in a console command, and have his creds exfilled

nobody:

absolutely nobody:

yubikey: cccjgjgkhcbbcvchfkfhiiuunbtnvgihdfiktncvlhck