"Successfully building, deploying, monitoring, and maintaining systems is only possible when security and reliability are central elements in their architecture. Yet both are often afterthoughts, considered only once an incident has occurred, resulting in expensive and sometimes difficult improvements."

Early Release: Building Secure Reliable Systems - Written by Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield

https://landing.google.com/sre/resources/foundationsandprinciples/srs-book/

Java deserialization explained

Finally, I found a paper about Java deserialization that I understand!
https://community.microfocus.com/t5/Security-Research-Blog/The-perils-of-Java-deserialization...
After several talks and blog posts, this was the paper that made me feel I understand it now.

Java deserialization is one of those bugs not many people look at.
Not because it's new, it's a damn old topic. I think many (like me) thought it was too hard and didn't go beyond running ysoserial.

Deserialization is such an awesome topic, some gadget chains are just crazy.
Originally, this paper is about mitigations and bypasses, but the intro to deserialization is why I recommend this.

"In our paper, we review the basics of the Java deserialization process and explain how and why it becomes vulnerable. We will show how different Java classes – referred to as gadgets throughout the paper – can be abused by attackers during the deserialization process to compromise or attack applications and servers. We explain how attackers can leverage these gadget classes for their own purposes. We examine several remote code execution gadgets to show how these attacks chain multiple pieces of code to craft the malicious payload. We review available mitigation advice and present a new technique to bypass some of the recommended protections. Finally, we conclude by reviewing how the problem affects similar libraries, and wrap up by offering our own mitigation strategies to more effectively protect against this problem."

Slides

Linking Anonymous Transactions via Remote Side-Channel Attacks

crypto.stanford.edu/timings

"We describe remote side-channel attacks on receiver privacy in anonymous cryptocurrencies. Our attacks, which we validate on Zcash and Monero, enable a remote attacker to:

In addition, for Zcash, the vulnerabilities underlying our attacks can be abused to remotely corrupt and crash any Zcash node for which the attacker knows a payment address, as well as to set up a remote timing side-channel on an ECDH key exchange between a victim node's private key and an attacker's ephemeral public key. In principle, this side-channel can be used to fully recover the victim's private key, thereby completely breaking receiver anonymity.

Our attacks rely on differences in the way that a user's wallet processes a transaction, depending on whether the user is the transaction's payee. We show that these differences in wallet behavior affect the behavior of the P2P node that the wallet is connected to. In turn, a remote adversary can exploit various network and timing side-channels to observe these differences in the P2P node's behavior, and thereby infer the wallet's receipt of a transaction."

Found this on hackerone, guess this is the perfect place to share it.

SSRF Bible / Cheatsheet

"SSRF - Server Side Request Forgery attacks. The ability to create requests from the vulnerable server to intra/internet. Using a protocol supported by available URI schemas, you can communicate with services running on other protocols. Here we collect the various options and examples (exploits) of such interaction"

In a leaked audio recording from an internal Facebook meeting obtained by The Verge, CEO Mark Zuckerberg expressed his thoughts about the social media giant's stablecoin project, Libra.

In the recording, Zuckerberg reiterated Libra's goal of trying "to stand up a new kind of digital money that can work globally, [and] that will be stable," adding that Libra is a new type of system that will be implemented by big companies and not just Facebook. "By the time it launches, we expect we’ll have 100 or more companies as part of it," Zuckerberg stated.

Zuckerberg also acknowledges that "finance is a very heavily regulated space" and that the Facebook team needs to have a more "consultative approach" when launching project that "touch very socially important aspects of society." 

"There’s a lot of important issues that need to be dealt with in preventing money laundering, preventing financing of terrorists and people who the different governments say you can’t do business with. There are a lot of requirements on knowing who your customers are. We already focus a lot on real identity, across especially Facebook, so there’s even more that we need to do in order to have this kind of a product," said Zuckerberg

On the topic of public scrutiny the Libra project has experienced in recent months, Zuckerberg stated that he believed public hearings "tend to be a little more dramatic," than private ones, adding that private meeting with various regulators around the world are often "more substantive and less dramatic."

Unofficial ZapRead Responsible Disclosure Guide

I am just talking about my experience, so don't take this post as official rules.
But having reported several bugs to ZapRead, I know how things works here.

Reporting a Bug

Critical Bugs

If you believe your bug is high severity and shouldn't be disclosed publicly, don't do so.
I use the ZapRead chat to report bugs and talk about reasons/mitigation.
Usually Zelgada answers within 48h after reporting a bug, often earlier.

GitHub

If you think the bug you found isn't too critical, just open a GitHub issue.
Most of the bugs I reported ended up becoming GitHub issues.

Bounty?

Quoting Zelgada: "If the fix goes into the code base, you will get the bugfinder achievement, and a tip.".
Read the discussion below.

Disclosure

I would wait at least 30 days, or until it has been fixed.
For crazy bugs I'd give 90 days time, be fair.

Fixing the Bug

It would be awesome if you create fixes for the bugs you report.
Zelgada can't do everything instantly, help is appreciated.
Just create a PR on GitHub.

Hacking ZapRead

I avoid hacking zapread.com itself as much as I can, to be legally safe.
Also sources and a debugger help a lot, so there's no need.
To get your own debug ZapRead, follow the guide on GitHub.

Have fun!

What is the goal of obfuscation? It's not making the code hard to understand, it's making the reverse-engineer give up.
One example is the M/o/Vfuscator2 which compiles C code to mov instructions only. But Chris Domas has more ideas.
Drawing pictures in the control flow graph for example. You see, it get's interesting. 

"Your precious 0-day? That meticulously crafted exploit? The perfect foothold? At some point, they'll be captured, dissected, and put on display. Reverse engineers. When they begin snooping through your hard work, it pays to have planned out your defense ahead of time. You can take the traditional defensive route - encryption, obfuscation, anti-debugging - or you can go on the offense, and attack the heart and soul of anyone who dare look at your perfect code. With some carefully crafted assembly, we'll show how to break down a reverse engineer by sending them misleading, intimidating, and demoralizing messages through the control flow graphs of their favorite RE tools - turning their beloved IDA (Hopper, BinNavi, Radare, etc) into unwitting weapons for devastating psychological warfare in reverse engineering."

Back up your hard drives.

R.I.P. Hard Drive [*]

Burp Tutorial: Enumerating User Ids || Tipping every ZapReader a satoshi

VIDEO: https://i.imgur.com/kCiyZPK.mp4

I'll probably stop the "attack" soon, don't wanna cause too much traffic, so if you didn't get a satoshi and want one, ask ;)

EDIT: Don't know y I can't embed the imgur video, sry.