Toots for clathetic@infosec.exchange account

Written by Clathetic on 2025-01-30 at 17:03

Today is a good day so far.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-24 at 13:35

Brain is a such a strange thing. Everything's so dark, the future's hopeless, nothing I do works, the news is unbearable... and yet, for some unkown reason, I 'm happy to open IDA today. Let's see how long I can keep it together.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-17 at 13:53

another day..

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-16 at 14:19

Another day with dark thoughts. Should open gdb instead of thinking too much. May be luck will show up lol.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-14 at 14:25

Here's a juicy read about messing with Fortinet FortiGate firewalls: https://arcticwolf.com/resources/blog/console-chaos-targets-fortinet-fortigate-firewalls/

The article talks a lot about detection and forensics, but I'm itching for more details or insight into exploit paths.

The article mentions attackers scanning for HTTPS ports, which probably means some admins are leaving their webadmin exposed to the internet. Honestly, I’m pretty sure there's either a sweet authentication bypass or some tasty injection flaw lurking in their admin panels.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-14 at 12:33

Another day, another miserable failure. I try to speak, but my words just get lost in the noise. It’s like I’m not even here. I don’t understand anymore. Maybe I’m just too broken to fix — a glitch in the system nobody cares to debug. The rain outside matches the storm in my head: cold, endless, suffocating. Should’ve stayed in bed. Would’ve spared everyone the effort of pretending I’m not a mistake.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 22:46

Is Kwon Daegun the good guy?

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 14:44

We can send a second packet, with a fake 1800 bytes size! Now the memcpy function will copy 1800 bytes, but this is controlled bytes! Because

the old 0x2000 buffer is not cleaned between two calls, so the data beyond 1500 is what remains of the first ethernet frame sent !!

And so, we can this time overflow saved $PC with controlled data, thus achieving $PC control. As this binary is compiled without any defense, it's an easy win. 0day is in the place! For people in the same ethernet segment, so there is no impact, no consequences, juste like my existence. At least the ftd server and I have something in common: nobody notices when we're compromised.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 14:43

Now the magic trick: We overflow (red line) the Saved $SP. function ends, restore stack pointer. Restore heap address of the 0x2000 bytes.

=> View attached media

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 14:42

We have to do better. Instead of overflowing the saved $PC, we can overflow the saved $SP, only the least significant bytes. When func2 returns, the stack will point elsewhere, just a bit lower. As we only changed the least significant bytes, the stack points inside the previously copied buffer on the stack. And that's good, becaus we have a lot of saved registers which are restored. Notably, we have the heap address of the 0x2000 bytes buffer. Here's a completed image:

=> View attached media

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 14:41

buf->len is controlled, buf->data is controlled, and dst->data is on the stack...

The exploitation would be easy as fuck:

Send a big packet in the 0x2000 malloc'ed buf, announce a big len (0x0fff for example), and we copy this in the stack, overwrites the return address, gain $pc control. After, any strategy would be ok.

BUT. BUT. BUT. We have a huge problem. We are talking about ethernet. And ethernet max size is 1500 bytes (yeah, I know jumbo frames, but I'm pretty sure that the IOT doesn't enable it). So, I can send a fake size of whatever size (up to 0xffff because len is store on two bytes), but the inbuf will be filled not more than ~1500 bytes. And as the buffer is allocated once at the beginning, all of its bytes are null bytes, meaning that we can overflow the stack until saved $PC with null bytes. And its bad for exploitation.

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 14:40

it's time for a nice schematics of heap and stack layout:

=> View attached media

=> More informations about this toot | View the thread

Written by Clathetic on 2025-01-08 at 14:39

While browsing the internets, I saw a tweet from devttyS0 giving away a key enabling the deciphering of a firmware. I decided to take a look.

After unciphering and extracting, I found a binary called ftd. I quickly found a vuln, and decided to make something of it. This is a mipsRE LE binary.

RELRO No RelRO

STACK CANARY No canary found

NX No

PIE No PIE

RPATH No RPATH

RUNPATH No RUNPATH

Symbols No Symbols

FORTIFYFortified No

Fortifiable 00

FILE ftd

$

Although I didn't understood what was the purpose of "ftd", I understood that it listen network from wlan0 and br0, and parse ethernet frames with ethertype 0x890D. The code is basically

while (1) {

received_size = recvfrom(fd, buf, 0x2000, 0, var1, var2);

parse_buf(var3, var4, buf, received_size);

}

and parse_buf() does something like:

{

char dst[1550]; //pay attention to this size

switch (buf->pkt_type)

{

(...)

}

if buf->pkt_type == 0x64 {

(...)

}

else

{

(...)

memcpy(dst->data, buf->data, buf->len);

}

}

=> More informations about this toot | View the thread

Written by Clathetic on 2024-11-18 at 12:51

Why don’t we use memory allocators like ASAN or afl-dislocator in everyday systems? Yes, they slow things down—but isn’t the trade-off for security worth it? With the sheer computing power we have today, could we afford to shift priorities? Or is performance still king?

=> More informations about this toot | View the thread

Written by Clathetic on 2024-10-31 at 14:40

About pacific rim (not the movie, the sophos attack story :D ), there is many docs/blogpost, and so on..

This one is the technical paper:

https://news.sophos.com/en-us/2024/10/31/pacific-rim-timeline/

really interesting

=> More informations about this toot | View the thread

Written by Clathetic on 2024-10-25 at 12:35

https://offsec.almond.consulting/privilege-escalation-f5-CVE-2024-45844.html

TLDR: you have a local socket (/var/run/mcp is chmod 777) executing commands as root.

Any vulns in any prog can escalate to root.

The best part? F5 said: "WONT'T FIX"

=> More informations about this toot | View the thread

=> This profile with reblog | Go to clathetic@infosec.exchange account