It's a sunday and many friends sent me this paper by Maryam Motallebighomi and Aanjhan Ranganathan delving deep into their security assessment of Shimano's Di2 wireless shifting architecture and hardware
Needless to say, with the football on, I delved deep into understanding it a bit more
1: Replay Attacks - let me change gear for you
2: Targeted Jamming - now you can't change gear
3: Information Leakage - gear selection leakage (meh dude i can SEE this
Ok they are meh bugs
The researchers were able to execute replay attacks from a distance of up to 10 metres using software-defined radios without amplifiers
They note that beyond this distance the signal falls outside the effective range
But first, it's maths time (notice the s, very important)
Pro pelotons average 45km/h, and if this 10 meter baseline is important,
45km/h=45×3600s1000m=12.5m/s
So, it takes 0.8 seconds to cover 10 meters at a speed of 45 km/h.
If you've ever watched a race before, you might struggle to move at that speed whilst carrying an SDR, launching the attack to capture the change (again, you need to have the rider DO the change to capture) and then replay it to drop gear
It's just not feasible imho & that's from someone who rides. In a lab, sure and yes there are things like rolling codes or even better PSK approaches but maintenance and other elements come into play here.
Then right at the end they did the clanger, you called it what?
I do appreciate the depth of research here but come on brothers, this isn't that at all.
Anyway full paper can be found at
Academia come outside, it's fun sometimes and you forget the two-column approach very quickly toousenix.org/system/files/w…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I'm going on a web app security rant, so bear with me.
23 years ago OWASP was formed and it tried to help the web application space and those building apps to do so in a secure way. Session management was one of them.
If you had a token, in a header/cookie, make it secure
We've evolved this over the decades, we collectively got better with understanding the nuances and complexities of this identity being thrown around and the consequences of not doing it right.
and yet, even with all this VC cash thrown at people wearing Patagonia vests and wearing apple watches, I still see most SaaS solutions doing stuff we did when Rain Forest Puppy was hurting SQL
Patch ALL teh things we constantly tell CISOs and CIOs.
Thing is, let's be honest with each other right? we can't and this graph is telling.
Patching is a pain, we get it and we do need to revolutionise the approach. Two years ago, @LargeCardinal wrote a phenomenal paper
where, in essence, the idea was to prioritize patches by expressing the connectivity of various vulnerabilities on a network with a QUBO and then solving this with quantum annealing.
Strap in, we's going on a ride, a static analysis ride. I recently came across this paper, which looked at a wide variety of SAST tools against a number of Java apps.
Java being the choice of enterprise, and often not the best Java approaches out there, so it's a good choice
First up, what did they use and what did they benchmark it against?
They looked at free tools, tools that specifically supported Java and most importantly, are being actively maintained.
The target was the @owasp project, a good choice imho. They also looked for Java apps with bugs with disclosed CVEs which was around 680 programs.
Bugs happen but it's rare you see a bug that grabs you so hard and makes you nod like a little dog..
CVE-2023-44487 did that for me
good god what a bug and here's why
First up is understanding the key differences between HTTP 1.1 and 2, especially how requests work
HTTP 1.1 is a text-based protocol that uses a single connection for each request/response pair. Every time you request the / from , it will be a diff request NSA.gov
for each element of that page (CSS, images etc)
HTTP 2 is a binary protocol that utilises multiplexing, which allows multiple requests and responses to be sent simultaneously over a single connection
An interesting new feature found in @Apple’s latest privacy and security report is that of Link Tracking Protection and I’ve not stopped thinking about this
First up it’s pretty cool. My views on the pervasive nature of the tracking industry are not something I’ve hidden away: it’s an ugly industry with no real oversight, so any efforts to put a finger in their eye is one to applaud
The approach by Apple is interesting
First up is the deeper inspection (I’m assuming client only) that intercepts any url and does a regex on it to strip out utm and other crap added to the url
If it works like that, I’m impressed. However, how much stuff will it break in the process? I guess time will tell
Here’s the thing right: if you are building any application/binary or indeed something that takes input and uses that to form the basis of further functions/actions, you kinda need to think about robustness.
Imagine a HTTP POST request to /remote/portal/bookmarks
What is needed is Content-Length, which indicates the size of the corresponding body. This is how the web works, so to send and indeed accept a zero byte body is odd and you’d check for that right?
Bueller? Right??
Well it seems not and there’s a brilliant write up of why this was a problem that caused a segfault in a SSL VPN appliance by Aliz Hammond over at @watchtowrcyber