the grugq @thegrugq@mastodon.social

here's a goodun from my pro twitter:

11 Oct 2012

Game: when someone in sec says 'ethical' replace with 'good for my career'. If resulting sentence is false, you are the first ever winner.

-- @HalvarFlake

https://arxiv.org/abs/1705.06809

Closing the Blinds: Four Strategies for Protecting Smart Home Privacy from Network Observers

Noah Apthorpe et al.

...we propose four strategies that device manufacturers and third parties can take to protect consumers from side-channel traffic rate privacy threats: 1) blocking traffic, 2) concealing DNS, 3) tunneling traffic, and 4) shaping and injecting traffic...

https://arxiv.org/abs/1705.06805

A Smart Home is No Castle: Privacy Vulnerabilities of Encrypted IoT Traffic

Noah Apthorpe et al.

...we examine four IoT smart home devices (a Sense sleep monitor, a Nest Cam Indoor security camera, a WeMo switch, and an Amazon Echo) and find that their network traffic rates can reveal potentially sensitive user interactions even when the traffic is encrypted...

https://arxiv.org/abs/1705.06784

Detect Kernel-Mode Rootkits via Real Time Logging & Controlling Memory Access

Igor Korkin et al.

...we propose monitoring and controlling access to the memory in real time using Intel VT-x with EPT. We... develop[ed] MemoryMonRWX, which is a bare-metal hypervisor. MemoryMonRWX is able to track and trap all types of memory access: read, write, and execute. ...MemoryMonRWX is able to protect critical kernel memory areas even when PatchGuard has been disabled

http://eprint.iacr.org/2017/440

Cryptographic Security Analysis of T-310

Nicolas T. Courtois et al.

T-310 is an important Cold War cipher. It was the principal encryption algorithm used to protect various state communication lines in Eastern Germany throughout the 1980s. ... In this paper we provide a detailed analysis of T-310 in the context of modern cryptography research and other important or similar ciphers developed in the same period.

https://arxiv.org/abs/1705.08279

Countermeasure against Side-Channel Attack in Shared Memory of TrustZone

Na-Young Ahn et al.

In this paper we introduced countermeasures against side-channel attacks in the shared memory of TrustZone. We proposed zero-contention cache memory or policy between REE and TEE to prevent from TruSpy attacks in TrustZone. And we suggested that delay time of data path of REE is equal or similar to that of data path of TEE to prevent timing side-channel attacks...

Privilege escalation mind map. https://securitymastod.one/media/jxrKynu5v9qzOZY4yJY

This picture is more terrifying than any terror attack. https://mastodon.social/media/Oab1Ov3sVToY2o6t-iA

Remember, when terrorists rely on lone wolf attacks it's a sign that their command and control channels have completely deteriorated (no doubt because of constant surveillance by Western security forces) and are incapable of any strategically significant action.
More surveillance wouldn't make a difference.

Via @cynicalsecurity on birbsite - https://www.ernw.de/download/Enno_Rey_RIPE74_Structural_Deficits_IPv6.pdf - Structural deficits in IPv6

Points out a lot of nasty issues that v6 has that make it a lot harder to work with than it really needs to be.

Mike Belopuhov (@mike) committed his implementation of FQ-CoDel, "Flow Queue - Controlled Delay" to #OpenBSD: http://marc.info/?l=openbsd-cvs&m=149392068217244&w=2

With the data it has Facebook could help prevent suicides. Instead it sells vulnerable moments to advertisers. https://arstechnica.com/business/2017/05/facebook-helped-advertisers-target-teens-who-feel-worthless/

https://i.imgur.com/sZjNc0U.gif
when you really trust your code.

@HalvarFlake @kwanre in the past few years I decided to go back and re-write my exploits once they are "good enough" because I want them to be more clean/accurate/readable, not just for others, but for myself.

I'll never forget the emails from a leaked email spool around ~2002 when the US Army said one of jduck's exploits was "the cleanest we had ever seen". And it was. ;-)

I suspect the reason why most exploit code is so messy to read is that while writing the exploit you're still figuring out the "architecture and language" of the thing you are attacking.

There are so many false starts, and so many false assumptions when you start.

A simple false assumption can start you down a wrong path for weeks... but often you can't easily verify that it is false before starting.

New #Phrack paper feed: "VM escape - QEMU Case Study" by Mehdi Talbi & Paul Fariello:

http://www.phrack.org/papers/vm-escape-qemu-case-study.html

HackerOne is running a bug bounty program for FlexiSpy, who specialise in spying on spouses https://twitter.com/josephfcox/status/857314960099160067

Their justification: it's "just fixing vulns" https://twitter.com/senorarroz/status/857399800601337856

I don't buy this at all. By providing security testing services to a shady company, you lend legitimacy to them and their brand. I agree with Casey on this one https://twitter.com/caseyjohnellis/status/857362206626689025

Hurtling toward cyberpunk dystopia: Amazon confirms picture and video stored indefinitely....

😰

https://motherboard.vice.com/en_us/article/amazon-echo-look-bedroom-camera

Voice recognition seems to work better if you talk like a robot. Who is training who here?!

Liamosaurs patented decision tree for whether you need to buy a $BIG_MONEY magical 0day protection service from $BIG_VENDOR...

Q: Can you put your hand on your heart and say "no technology stack my company uses contains publically known vulnerabilities"?

If the answer is "no", you should just work harder on patching your shit instead

If the answer is "yes", you should work on better understanding the software you use, because you're a liar