CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
11–20 of 106 posts
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#12This happens in many corporations as well. It's fun and exciting to be on the red-team (doing the penetration testing, writing exploits, etc) but the blue team (infrastructure teams and developer teams hardening things) is not only boring to most, but it's also the team that gets the most grief from developers for inducing friction. If your company has a red team, ask how big the blue team is and if they have the sam…
Hacker competitions often seem very contrived to me. I suspect that in order for the red team to make any progress you have to tie the blue teams hands behind their backs. Most of what I see from the penetration testing community is pretty gimmicky and situational generally and often doesn't take into account the attackers risk/reward ratio.
[deleted]
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#13Earlier quoted context omitted.
Allowing Blue Team to fight back maybe? Or to be able to actively track the red team instead, using an active defense, instead of only passive defense? Moreover, the outcomes are different for both teams: - RedTeam success => they are seen as "real" hackers/heros and the BlueTeam are the poor incompetent - RedTeam fail => the BlueTeam did "only" its job, the investments in cybersec for the company paid off... so the…
That's good. Perhaps something like if they can attribute the attack to a particular machine the red team gets "arrested".
Do the feds still attend DC? >:}
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#14>34 terabytes of information, or about 2.2 billion pages.
That's insane that they could leave so much data available to be stolen.
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#15Earlier quoted context omitted.
What would be a less gimmicky setup?
Let the non-red teams use pre-existing scripts, code, etc, to harden things. This of course would make the competition a level playing field and would make it much less fun for the red team. Attendance would drop off quickly and companies would no longer sponsor these events, as the primary purpose is to recruit people out of college.
Actually, this could be made like "CS:GO" competition:
- RT is the terro - BT is the AT
The RT has to "plant" an exploit. The BT can either block/track the RT or "diffuse" (find/disable) the exploit.
The "maps" would be the kind of system:
- an AD behind a firewall - a WebServer with datas to extract from a backend DB - and so...
The sponsors could sell either the skills of their pen-testers to hire, or their solution to secure a system, so it might be a good maketing campaing for the winner...
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#16I find it ironic that the CIA didn't bother to have it's systems secured/verified by the NSA. I'm sure the CIA thought that they were good enough, coming from an organization that was infiltrated from its inception, their hubris isn't surprising.
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#17Reminds me of any “security” product. Next time you get the chance, I suggest you tear into any industry standard security tool and you’ll be surprised at what you find.
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#18Words can't describe how normal that is. Exploit tools are require local systems to be super open in order to be frictionless.
Even in the consumer industry; anyone remember all those very silly people who installed backtrack2 (precursor to kali, based on slackware not debian) to their main drive and then went to defcon and got rekt because their OS was insecure (and couldn't be updated!)
Exploit development is a glass cannon, remove all friction to modify the system and craft packets, invoke monitoring modes for hardware and frictionless tracing... that's going to have a security cost.
This echo's a wider issue in the industry "Development" vs "Sysadmin" mindsets, where sysadmins are stifling and developers are all about removing barriers to progress faster and iterate more.
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#19Words can't describe how normal that is. Exploit tools are require local systems to be super open in order to be frictionless. Even in the consumer industry; anyone remember all those very silly people who installed backtrack2 (precursor to kali, based on slackware not debian) to their main drive and then went to defcon and got rekt because their OS was insecure (and couldn't be updated!) Exploit development is a gla…
What's the story re: backtrack2, for the uninformed?
Re: CIA hacking unit failed to protect its systems, allowing Vault 7 disclosure
#20Words can't describe how normal that is. Exploit tools are require local systems to be super open in order to be frictionless. Even in the consumer industry; anyone remember all those very silly people who installed backtrack2 (precursor to kali, based on slackware not debian) to their main drive and then went to defcon and got rekt because their OS was insecure (and couldn't be updated!) Exploit development is a gla…
What's the story re: backtrack2, for the uninformed?
I'm trying to find a citation here, but it's difficult because "Backtrack 2 ssh exploit defcon" is going to produce a lot of content which is unrelated.
Anyway I can give you the skinny of the situation:
1) Backtrack 2 did not have an installer, it was a live-CD. But that doesn't stop you installing it by just copying the live environment to a disk (with some mount-binding and grub install, you're all good!) There were guides for doing this although they all had large warnings and the backtrack maintainers cautioned heavily against doing it.
2) because it was a liveCD there was no package update mechanism, it was not based on debian at the time so there was no apt or anything similar, even if there was there was no repositories, backtrack was a "tool" not a distro really.
3) sshd is one of the services that gets started on system boot for backtrack2.
4) someone at defcon unveilled an sshd exploit, a pretty nasty one, they had disclosed responsibly and everyone had been patched for at least 6 months, except the people who went against recommendations and installed backtrack2. They all got rooted.
Bonus: everyone who ran backtrack2, without exception, ran it with the root user; as that was the default and they had patched software that normally complains about such things to not complain. xD