8 ms·

Here’s a twist - with the amount of effort the attacker went through to evade detection in their scripts and code, this whole project could function as a divers

Here’s a twist - with the amount of effort the attacker went through to evade detection in their scripts and code, this whole project could function as a diversion or at least fallback to one while multiple efforts go on simultaneously. How do you get one step ahead of that? Does the community focusing on SSHD impact some other part of the system as a whole? Some other technological aspect? Social? Tin foil hats are fun!

AndyMcConachie 3y ago
[flagged]
- glitchcrab 3y ago
  Conversely, do you have evidence against any of it?
mathverse 3y ago
We dont need any tinfoil hats. FOSS projects were being backdoored even before they became a thing the difference is that this time it's state sponsored actors doing it. The old groups GOBBLES,ADM,ac1db1tch3z,~el8 were doing it, private "security researchers" like isec.pl were doing it. This time it's a problem because state actors are abusing the corporate capitalism that created this era of underpaid people working on foundational projects. The bad actors have unlimited resources for their objectives. That's basically what created the demand and ineption of groups like NSO,Zerodium etc.. Basically before that exploits and backdoors were worthless and hackers hoped to be sponsored or hired by companies like Qualys.
- xhkkffbf 3y ago
  How did "corporate capitalism" create this situation? Some guy decided to volunteer his time to write some code. If anything, it might be said that corporate capitalism paid him well enough so he had the spare time? And I don't see what money has to do with any of this. There could be some well-paid programmer slipping backdoors into proprietary code just as easily. The salary or openness didn't affect the outcome. It's just as easy for salaried programmers to betray their bosses and their users.
hmottestad 3y ago
You could write all code yourself for absolutely everything with your own dedicated crew of vetted developers. Or buy closed source from someone like Microsoft, hoping that they have the resources and actually use the resources to scrutinise code more vigorously. And there is always the approach of having a great secops team to detect strange network activity and attempts to escalate.
mkup 3y ago
My idea of getting one step ahead of similar backdoors is to wrap sshd traffic into a spiped tunnel. Spiped is compiled from source and linked statically (last stable version from 2021).
- cpach 3y ago
  spiped is solid. Wireguard is another good option that is included in the Linux kernel.
- markhahn 3y ago
  jeez, why not just compile ssh static?
  - mkup 3y ago
    I still want sshd updated by my OS package manager. Statically linked spiped, which is out of scope of my OS package manager, is just a second line of defense.
bandrami 3y ago
I'm not optimistic. Nobody ever even audits the binary contents of flatpaks on flathub (were they actually built from the source? the author attests so!). You don't really even need a fancy delivery mechanism like this backdoor had.
- smallerfish 3y ago
  It seems like 75% of people are comfortable installing latest & greatest developer tools with `curl > bash`, so it's no wonder that flatpak and similar have momentum. Really, we desperately need a better sandboxing UX in linux.
  - christophilus 3y ago
    That is better to me than installing a random binary. You can trivially audit the curl. Also, the curl > bash thing usually comes from the project maintainer (as in the case of Bun) vs some rando flatpacker.
    - account42 3y ago
      No, you cannot audit the curl at all. What a website serves you now is not neccessarily what the website serves you one minute from now.
    - smallerfish 3y ago
      Not if the bash part then turns around and installs a random binary, which is often the case. How do you know how thoroughly it's been audited by third parties? Does it have a security patch mechanism built into it?
    - johnisgood 3y ago
      In all fairness, Jia was indeed the co-maintainer of the project. He modified SECURITY.md as well[1]. [1] https://github.com/tukaani-project/xz/commit/780d2c236de0e4749655696c2e0c26fb7565afd3 https://github.com/tukaani-project/xz/commit/780d2c236de0e47...
  - 3y ago
darthrupert 3y ago
1. Have multiple LLMs scrutinize every pull request that is created in the public. 2. Stop accepting shit tools like M4 and C for creating any software. You can never make the work of black hats impossible but you can trivially make it a whole lot harder.
- Intralexical 3y ago
  > 1. Have multiple LLMs scrutinize every pull request that is created in the public. --- > You: > Below is a hexdump of a test file added to our code repository. Is it any cause for concern? ``` 0000000 375 7 z X Z \0 \0 004 346 326 264 F 002 \0 ! 001 0000010 \b \0 \0 \0 330 017 # 023 001 \0 \f # # # # H 0000020 e l l o # # # # \0 \0 \0 \0 022 210 337 004 0000030 Y r 201 B \0 001 % \r q 031 304 266 037 266 363 } 0000040 001 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004 0000050 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023 0000060 340 005 026 001 _ ] \0 005 245 - U 273 230 004 | 0000070 306 231 274 240 f M 315 1 255 \v ) 270 ( \f . 0000080 274 3 263 ~ * 323 312 n 324 C 034 Q Y 314 217 341 0000090 350 343 357 @ 227 271 247 w 026 255 237 U * H 367 240 00000a0 K 260 p 9 5 370 j 017 203 ? 307 ] 005 326 220 240 00000b0 352 I 236 ` ? 304 306 365 246 375 226 [ 257 a 177 - 00000c0 261 033 204 001 203 251 346 252 243 244 < 016 h 256 273 356 00000d0 320 206 ! 355 367 P ) 247 035 226 357 026 224 324 u K 00000e0 255 8 277 326 350 347 205 \n : 220 334 342 u 216 M 357 00000f0 \f = c 316 244 % \0 233 E 354 x " 376 250 266 247 0000100 ^ 303 S 273 220 271 0 | 232 222 252 033 251 \r 372 g 0000110 n 221 177 ) 270 l \v X 315 w , ( \t 254 * $ 0000120 023 031 ! | 003 J 0 262 002 030 230 321 4 0000130 340 233 216 337 360 261 \ ] 216 016 020 206 001 357 346 332 0000140 337 z 306 363 374 ] 354 323 335 [ 337 214 z 330 226 027 0000150 j 255 037 260 ' 027 356 333 F W V 200 030 H ; 337 0000160 \n 245 q 7 372 360 I 263 ; 326 316 321 306 030 q K 0000170 337 264 030 1 345 z 032 @ 357 301 ] 302 U < 037 262 0000180 363 272 241 231 346 s \0 337 216 235 375 236 [ 037 215 037 0000190 274 341 033 200 \0 \0 \0 \0 u 216 336 U 336 r 1 u 00001a0 \0 001 311 002 227 \n \0 \0 \n 224 r 242 261 304 g 373 00001b0 002 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004 00001c0 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023 00001d0 001 \0 \r # # # # W o r l d # # # # 00001e0 \n \0 \0 \0 x 360 \v ) 314 g 337 330 \0 001 & 016 00001f0 \b 033 340 004 037 266 363 } 001 \0 \0 \0 \0 004 Y Z 0000200 ``` > Copilot: > The hexdump you've provided appears to be a binary file. It's difficult to determine if it's a cause for concern just by looking at the hexdump. Here are a few things you could consider: > 1. *File Origin*: If this file was added by a trusted team member and it's expected to be part of your code repository, it's probably safe. If the file's origin is unknown or it was added unexpectedly, you might want to investigate further. > 2. *File Purpose*: Understanding what this file is used for can help determine if it's a cause for concern. If it's a binary used for testing or a necessary part of your application, it might be fine. If its purpose is unclear, it's worth checking. > 3. *File Analysis*: You could use file analysis tools to examine the binary file. This could provide information about what the file does, which can help you decide if it's a cause for concern. > 4. *Security Scans*: Consider running security scans on the file. There are many tools available that can scan binary files for known security vulnerabilities. > 5. *Code Review*: If this file was added as part of a commit, make sure the commit was reviewed thoroughly. Unexpected binary files can sometimes be a sign of an insecure direct object reference (IDOR) vulnerability. > Remember, when in doubt, it's always better to err on the side of caution. If you're unsure, consider reaching out to a security professional. They can help you analyze the file and determine if it poses any risk. Lol. --- > 2. Stop accepting shit tools like M4 and C for creating any software. > You can never make the work of black hats impossible but you can trivially make it a whole lot harder. What could be more trivially done than simply replacing C for all code?
hackeraccount 3y ago
My tin foil hat idea is for people to be suspicious about open source contributors. Not from countries or even one's who have seemingly never been met. But from contributors who have no history and no footprint other then the project they're working on. That should be a red flag in the future.

AndyMcConachie 3y ago

[flagged]

glitchcrab 3y ago
Conversely, do you have evidence against any of it?

mathverse 3y ago

We dont need any tinfoil hats. FOSS projects were being backdoored even before they became a thing the difference is that this time it's state sponsored actors doing it. The old groups GOBBLES,ADM,ac1db1tch3z,~el8 were doing it, private "security researchers" like isec.pl were doing it. This time it's a problem because state actors are abusing the corporate capitalism that created this era of underpaid people working on foundational projects. The bad actors have unlimited resources for their objectives. That's basically what created the demand and ineption of groups like NSO,Zerodium etc.. Basically before that exploits and backdoors were worthless and hackers hoped to be sponsored or hired by companies like Qualys.

xhkkffbf 3y ago
How did "corporate capitalism" create this situation? Some guy decided to volunteer his time to write some code. If anything, it might be said that corporate capitalism paid him well enough so he had the spare time? And I don't see what money has to do with any of this. There could be some well-paid programmer slipping backdoors into proprietary code just as easily. The salary or openness didn't affect the outcome. It's just as easy for salaried programmers to betray their bosses and their users.

hmottestad 3y ago

You could write all code yourself for absolutely everything with your own dedicated crew of vetted developers. Or buy closed source from someone like Microsoft, hoping that they have the resources and actually use the resources to scrutinise code more vigorously. And there is always the approach of having a great secops team to detect strange network activity and attempts to escalate.

mkup 3y ago

My idea of getting one step ahead of similar backdoors is to wrap sshd traffic into a spiped tunnel. Spiped is compiled from source and linked statically (last stable version from 2021).

cpach 3y ago
spiped is solid. Wireguard is another good option that is included in the Linux kernel.
markhahn 3y ago
jeez, why not just compile ssh static?
- mkup 3y ago
  I still want sshd updated by my OS package manager. Statically linked spiped, which is out of scope of my OS package manager, is just a second line of defense.

bandrami 3y ago

I'm not optimistic. Nobody ever even audits the binary contents of flatpaks on flathub (were they actually built from the source? the author attests so!). You don't really even need a fancy delivery mechanism like this backdoor had.

smallerfish 3y ago
It seems like 75% of people are comfortable installing latest & greatest developer tools with `curl > bash`, so it's no wonder that flatpak and similar have momentum. Really, we desperately need a better sandboxing UX in linux.
- christophilus 3y ago
  That is better to me than installing a random binary. You can trivially audit the curl. Also, the curl > bash thing usually comes from the project maintainer (as in the case of Bun) vs some rando flatpacker.
  - account42 3y ago
    No, you cannot audit the curl at all. What a website serves you now is not neccessarily what the website serves you one minute from now.
  - smallerfish 3y ago
    Not if the bash part then turns around and installs a random binary, which is often the case. How do you know how thoroughly it's been audited by third parties? Does it have a security patch mechanism built into it?
  - johnisgood 3y ago
    In all fairness, Jia was indeed the co-maintainer of the project. He modified SECURITY.md as well[1]. [1] https://github.com/tukaani-project/xz/commit/780d2c236de0e4749655696c2e0c26fb7565afd3 https://github.com/tukaani-project/xz/commit/780d2c236de0e47...
- 3y ago

darthrupert 3y ago

1. Have multiple LLMs scrutinize every pull request that is created in the public. 2. Stop accepting shit tools like M4 and C for creating any software. You can never make the work of black hats impossible but you can trivially make it a whole lot harder.

Intralexical 3y ago
> 1. Have multiple LLMs scrutinize every pull request that is created in the public. --- > You: > Below is a hexdump of a test file added to our code repository. Is it any cause for concern? ``` 0000000 375 7 z X Z \0 \0 004 346 326 264 F 002 \0 ! 001 0000010 \b \0 \0 \0 330 017 # 023 001 \0 \f # # # # H 0000020 e l l o # # # # \0 \0 \0 \0 022 210 337 004 0000030 Y r 201 B \0 001 % \r q 031 304 266 037 266 363 } 0000040 001 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004 0000050 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023 0000060 340 005 026 001 _ ] \0 005 245 - U 273 230 004 | 0000070 306 231 274 240 f M 315 1 255 \v ) 270 ( \f . 0000080 274 3 263 ~ * 323 312 n 324 C 034 Q Y 314 217 341 0000090 350 343 357 @ 227 271 247 w 026 255 237 U * H 367 240 00000a0 K 260 p 9 5 370 j 017 203 ? 307 ] 005 326 220 240 00000b0 352 I 236 ` ? 304 306 365 246 375 226 [ 257 a 177 - 00000c0 261 033 204 001 203 251 346 252 243 244 < 016 h 256 273 356 00000d0 320 206 ! 355 367 P ) 247 035 226 357 026 224 324 u K 00000e0 255 8 277 326 350 347 205 \n : 220 334 342 u 216 M 357 00000f0 \f = c 316 244 % \0 233 E 354 x " 376 250 266 247 0000100 ^ 303 S 273 220 271 0 | 232 222 252 033 251 \r 372 g 0000110 n 221 177 ) 270 l \v X 315 w , ( \t 254 * $ 0000120 023 031 ! | 003 J 0 262 002 030 230 321 4 0000130 340 233 216 337 360 261 \ ] 216 016 020 206 001 357 346 332 0000140 337 z 306 363 374 ] 354 323 335 [ 337 214 z 330 226 027 0000150 j 255 037 260 ' 027 356 333 F W V 200 030 H ; 337 0000160 \n 245 q 7 372 360 I 263 ; 326 316 321 306 030 q K 0000170 337 264 030 1 345 z 032 @ 357 301 ] 302 U < 037 262 0000180 363 272 241 231 346 s \0 337 216 235 375 236 [ 037 215 037 0000190 274 341 033 200 \0 \0 \0 \0 u 216 336 U 336 r 1 u 00001a0 \0 001 311 002 227 \n \0 \0 \n 224 r 242 261 304 g 373 00001b0 002 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004 00001c0 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023 00001d0 001 \0 \r # # # # W o r l d # # # # 00001e0 \n \0 \0 \0 x 360 \v ) 314 g 337 330 \0 001 & 016 00001f0 \b 033 340 004 037 266 363 } 001 \0 \0 \0 \0 004 Y Z 0000200 ``` > Copilot: > The hexdump you've provided appears to be a binary file. It's difficult to determine if it's a cause for concern just by looking at the hexdump. Here are a few things you could consider: > 1. *File Origin*: If this file was added by a trusted team member and it's expected to be part of your code repository, it's probably safe. If the file's origin is unknown or it was added unexpectedly, you might want to investigate further. > 2. *File Purpose*: Understanding what this file is used for can help determine if it's a cause for concern. If it's a binary used for testing or a necessary part of your application, it might be fine. If its purpose is unclear, it's worth checking. > 3. *File Analysis*: You could use file analysis tools to examine the binary file. This could provide information about what the file does, which can help you decide if it's a cause for concern. > 4. *Security Scans*: Consider running security scans on the file. There are many tools available that can scan binary files for known security vulnerabilities. > 5. *Code Review*: If this file was added as part of a commit, make sure the commit was reviewed thoroughly. Unexpected binary files can sometimes be a sign of an insecure direct object reference (IDOR) vulnerability. > Remember, when in doubt, it's always better to err on the side of caution. If you're unsure, consider reaching out to a security professional. They can help you analyze the file and determine if it poses any risk. Lol. --- > 2. Stop accepting shit tools like M4 and C for creating any software. > You can never make the work of black hats impossible but you can trivially make it a whole lot harder. What could be more trivially done than simply replacing C for all code?

hackeraccount 3y ago

My tin foil hat idea is for people to be suspicious about open source contributors. Not from countries or even one's who have seemingly never been met. But from contributors who have no history and no footprint other then the project they're working on. That should be a red flag in the future.