https://github.com/osquery/osquery logo
Powered by
s

slevchenko

02/03/2022, 8:34 AM
Hi everyone. Does anybody knows which kind of address this is 
00:02:08:10:60:00:00:00:00:00:00:00:00:00:88:82
(address redacted) ? I seed such addresses in bpf_socket_events remote_address field and are not recognized with usual utilities like nc, ping and so on.
Hi @alessandrogario I apologize for tagging you directly, I've noticed that you've answered some bpf related questions. If you have a spare moment, could you please look into my question, or advise someone might know? Thanks in advance.
a

alessandrogario

02/03/2022, 4:49 PM
Hey @slevchenko! That looks like a bug, can you verify that the address is correct by grouping those values every 2 bytes?
s

slevchenko

02/03/2022, 4:52 PM
I will. Can you explain how to do it ?
a

alessandrogario

02/03/2022, 4:52 PM
Sure! You can just remove every odd 
:
character from the address
So it becomes: 0002081060000000000000000000:8882
Now I don't know about endianness, bytes may have to be swapped. That would look like this: 
0200:1008:0060:0000:0000:0000:0000:8288
Finally, I am not 100% sure about these rules, but in theory fields that have only zeroes can be collapsed: 
0200:1008:0060:::::8288
This can probably applied to zeroes on the left too: 
200:1008:60:::::8288
s

slevchenko

02/03/2022, 4:56 PM
Now that does resemble valid IPv6
a

alessandrogario

02/03/2022, 5:02 PM
were you able to verify that the IP address is correct?
s

slevchenko

02/03/2022, 5:04 PM
Unfortunatelly no. I've tried abut all variants I managed to get returned just:
Copy code
...88: Name or service not known
I feel like I need some script to do all these transformations with no mistakes
Like swapping zeroes, skipping octets filled with nothing but zeroes, so on and so forth
Not sure if it helps, but I've noticed that mangled addresses come from containerized apps: docker containers, snaps (Ubuntu snapcraft), Flatpaks (RH Flatpak)
a

alessandrogario

02/03/2022, 5:10 PM
I think it's just bad handling on all IPv6 addresses
or are you thinking that those addresses are being mishandled and are not in fact IPv6?
s

slevchenko

02/03/2022, 5:11 PM
maybe, but it gives a huge headache to our security team, so I had to share it with someone form dev team at very least 🙂
I think they are IPv6, but I don't know how they ended up messed up so bad
a

alessandrogario

02/03/2022, 5:12 PM
if they have always been IPv6, they have been broken for a while I think
s

slevchenko

02/03/2022, 5:13 PM
to me it looks like more just skipping zero filled octets, since in this case address might look like: 
2008:::::....
a

alessandrogario

02/03/2022, 5:14 PM
it's not corruption or uninintialized memory, it's just that the logic to convert to string those addresses is wrong
s

slevchenko

02/03/2022, 5:15 PM
Applications actually work, so they definitely able to reach destinations, it's rather related to how Osquery reflects them in query results
a

alessandrogario

02/03/2022, 5:17 PM
yeah, it's all in the ::toString method of IPv6 addresses
s

slevchenko

02/03/2022, 5:18 PM
BTW, to reproduce it one can try to use, Thunderbird (snap, remote_port 53), Microsoft Teams (flatpak remote_port 53), to name a few. Unfortunately rest of apps are custom and naming them will not help
a

alessandrogario

02/03/2022, 5:18 PM
I think a simple netcat on ::1 should reproduce it easily
s

slevchenko

02/03/2022, 5:27 PM
Copy code
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01
that's 
nc ::1 53
So just as you said it's IPv6 conversion getting mangled
a

alessandrogario

02/03/2022, 5:30 PM
Yeah, so you can probably still query data that has been already collected
until a fix is included in the stable release
s

slevchenko

02/03/2022, 5:30 PM
Yes if I'll figure out how to convert it to readable form
it was easy with ::1, but how to handle complex addresses which values we don't know beforehand ?
a

alessandrogario

02/03/2022, 5:32 PM
i think the easiest way is to process this data from the log aggregator
rather than trying to fix it with SQL
s

slevchenko

02/03/2022, 5:33 PM
on our side osquery is used for anomaly detection, and it works with ipv4.
I guess, we can wait. Do you think this fix has any chances to make it into stable release?
if that's considered a minor issue, it would be also great to know, we'll find a way to work around it, one way or another
a

alessandrogario

02/03/2022, 5:38 PM
We already have some additional fixes to BPF, but I am not sure when they are going to be merged & released
bpf: Improve socket event handling https://github.com/osquery/osquery/pull/7446 Add BPF support for CentOS 7.6 distributions with kernel 3.10 https://github.com/osquery/osquery/pull/7378 bpf_process_events: Implement additional events https://github.com/osquery/osquery/pull/7370
It is definitely a bug so it will get fixed
s

slevchenko

02/03/2022, 5:41 PM
Oh, that's great. Thank you Alessandro for your time and answers, have a great day.
a

alessandrogario

02/08/2022, 8:54 PM
s

slevchenko

02/09/2022, 9:45 AM
That's great, thanks for your efforts Alessandro.
6 Views
Powered by