Tag Archives: Countermeasures

GitLab Watchman – Audit Gitlab For Sensitive Data & Credentials

Post Syndicated from Darknet original https://www.darknet.org.uk/2021/02/gitlab-watchman-audit-gitlab-for-sensitive-data-credentials/?utm_source=rss&utm_medium=social&utm_campaign=darknetfeed

GitLab Watchman – Audit Gitlab For Sensitive Data & Credentials

GitLab Watchman is an application that uses the GitLab API to audit GitLab for sensitive data and credentials exposed internally – this includes code, commits, wiki pages and more.

GitLab Watchman searches GitLab for internally shared projects and looks at:

  • Code
  • Commits
  • Wiki pages
  • Issues
  • Merge requests
  • Milestones

For the following data:

  • GCP keys and service account files
  • AWS keys
  • Azure keys and service account files
  • Google API keys
  • Slack API tokens & webhooks
  • Private keys (SSH, PGP, any other misc private key)
  • Exposed tokens (Bearer tokens, access tokens, client_secret etc.)
  • S3 config files
  • Passwords in plaintext
  • CICD variables exposed publicly
  • and more

Using GitLab Watchman to Audit Gitlab For Sensitive Data

GitLab Watchman will be installed as a global command, use as follows:

usage: gitlab-watchman [-h] –timeframe {d,w,m,a} –output
{file,stdout,stream} [–version] [–all] [–blobs]
[–commits] [–wiki-blobs] [–issues] [–merge-requests]
[–milestones] [–comments]

Monitoring GitLab for sensitive data shared publicly

optional arguments:
-h, –help show this help message and exit
–version show program’s version number and exit
–all Find everything
–blobs Search code blobs
–commits Search commits
–wiki-blobs Search wiki blobs
–issues Search issues
–merge-requests Search merge requests
–milestones Search milestones
–comments Search comments

required arguments:
–timeframe {d,w,m,a}
How far back to search: d = 24 hours w = 7 days, m =
30 days, a = all time
–output {file,stdout,stream}
Where to send results

You can run GitLab Watchman to look for everything, and output to default Stdout:

gitlab-watchman –timeframe a –all

Or arguments can be grouped together to search more granularly.

Read the rest of GitLab Watchman – Audit Gitlab For Sensitive Data & Credentials now! Only available at Darknet.

GKE Auditor – Detect Google Kubernetes Engine Misconfigurations

Post Syndicated from Darknet original https://www.darknet.org.uk/2021/01/gke-auditor-detect-google-kubernetes-engine-misconfigurations/?utm_source=rss&utm_medium=social&utm_campaign=darknetfeed

GKE Auditor – Detect Google Kubernetes Engine Misconfigurations

GKE Auditor is a Java-based tool to detect Google Kubernetes Engine misconfigurations, it aims to help security and development teams streamline the configuration process and save time looking for generic bugs and vulnerabilities.

The tool consists of individual modules called Detectors, each scanning for a specific vulnerability.

Installing and Using GKE Auditor to Detect Google Kubernetes Engine Misconfigurations
Installation

git clone https://github.com/google/gke-auditor
cd ./gke-auditor/
./build.sh

Usage

The tool has to be built by running the build.sh script first.

Read the rest of GKE Auditor – Detect Google Kubernetes Engine Misconfigurations now! Only available at Darknet.

Amazon Web Services Is the First Global Cloud Service Provider to Achieve the Korea-Information Security Management System Certification

Post Syndicated from Oliver Bell original https://aws.amazon.com/blogs/security/amazon-web-services-is-the-first-global-cloud-service-provider-to-achieve-the-korea-information-security-management-system-certification/

Scope of certification: Operation of infrastructure in the AWS Asia Pacific (Seoul) Region
Period of validity: December 27, 2017, through December 26, 2020

Amazon Web Services (AWS) has achieved the Korea-Information Security Management System (K-ISMS) Certification. The Korea Internet and Security Agency (KISA) completed its assessment of AWS, which covered the operation of infrastructure (such as compute, storage, networking, databases, and security) in the Asia Pacific (Seoul) Region. AWS is the first global cloud service provider to earn this status in Korea.

Sponsored by KISA and affiliated with the Korean Ministry of Science and ICT (MSIT), K-ISMS serves as a standard for evaluating whether enterprises and organizations operate and manage their information security management systems consistently and securely such that they thoroughly protect their information assets. The K-ISMS certification assessment covers 104 criteria, including 12 control items in 5 sectors for information security management, and 92 control items in 13 sectors for information security countermeasures.

With this certification, enterprises and organizations across Korea can meet KISA compliance requirements more effectively. Achieving this certification demonstrates the proactive approach AWS has taken with regard to driving compliance with the Korean government’s requirements and delivering secure AWS services to Korean customers. Enterprises and organizations in Korea that need the K-ISMS certification can use the work that AWS has done to reduce the time and cost of getting their own certification.

– Oliver

New Techniques in Fake Reviews

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/09/new_techniques_.html

Research paper: “Automated Crowdturfing Attacks and Defenses in Online Review Systems.”

Abstract: Malicious crowdsourcing forums are gaining traction as sources of spreading misinformation online, but are limited by the costs of hiring and managing human workers. In this paper, we identify a new class of attacks that leverage deep learning language models (Recurrent Neural Networks or RNNs) to automate the generation of fake online reviews for products and services. Not only are these attacks cheap and therefore more scalable, but they can control rate of content output to eliminate the signature burstiness that makes crowdsourced campaigns easy to detect.

Using Yelp reviews as an example platform, we show how a two phased review generation and customization attack can produce reviews that are indistinguishable by state-of-the-art statistical detectors. We conduct a survey-based user study to show these reviews not only evade human detection, but also score high on “usefulness” metrics by users. Finally, we develop novel automated defenses against these attacks, by leveraging the lossy transformation introduced by the RNN training and generation cycle. We consider countermeasures against our mechanisms, show that they produce unattractive cost-benefit tradeoffs for attackers, and that they can be further curtailed by simple constraints imposed by online service providers.

Unfixable Automobile Computer Security Vulnerability

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/08/unfixable_autom.html

There is an unpatchable vulnerability that affects most modern cars. It’s buried in the Controller Area Network (CAN):

Researchers say this flaw is not a vulnerability in the classic meaning of the word. This is because the flaw is more of a CAN standard design choice that makes it unpatchable.

Patching the issue means changing how the CAN standard works at its lowest levels. Researchers say car manufacturers can only mitigate the vulnerability via specific network countermeasures, but cannot eliminate it entirely.

Details on how the attack works are here:

The CAN messages, including errors, are called “frames.” Our attack focuses on how CAN handles errors. Errors arise when a device reads values that do not correspond to the original expected value on a frame. When a device detects such an event, it writes an error message onto the CAN bus in order to “recall” the errant frame and notify the other devices to entirely ignore the recalled frame. This mishap is very common and is usually due to natural causes, a transient malfunction, or simply by too many systems and modules trying to send frames through the CAN at the same time.

If a device sends out too many errors, then­ — as CAN standards dictate — ­it goes into a so-called Bus Off state, where it is cut off from the CAN and prevented from reading and/or writing any data onto the CAN. This feature is helpful in isolating clearly malfunctioning devices and stops them from triggering the other modules/systems on the CAN.

This is the exact feature that our attack abuses. Our attack triggers this particular feature by inducing enough errors such that a targeted device or system on the CAN is made to go into the Bus Off state, and thus rendered inert/inoperable. This, in turn, can drastically affect the car’s performance to the point that it becomes dangerous and even fatal, especially when essential systems like the airbag system or the antilock braking system are deactivated. All it takes is a specially-crafted attack device, introduced to the car’s CAN through local access, and the reuse of frames already circulating in the CAN rather than injecting new ones (as previous attacks in this manner have done).

Slashdot thread.

Research on Tech-Support Scams

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/04/research_on_tec.html

Interesting paper: “Dial One for Scam: A Large-Scale Analysis of Technical Support Scams“:

Abstract: In technical support scams, cybercriminals attempt to convince users that their machines are infected with malware and are in need of their technical support. In this process, the victims are asked to provide scammers with remote access to their machines, who will then “diagnose the problem”, before offering their support services which typically cost hundreds of dollars. Despite their conceptual simplicity, technical support scams are responsible for yearly losses of tens of millions of dollars from everyday users of the web.

In this paper, we report on the first systematic study of technical support scams and the call centers hidden behind them. We identify malvertising as a major culprit for exposing users to technical support scams and use it to build an automated system capable of discovering, on a weekly basis, hundreds of phone numbers and domains operated by scammers. By allowing our system to run for more than 8 months we collect a large corpus of technical support scams and use it to provide insights on their prevalence, the abused infrastructure, the illicit profits, and the current evasion attempts of scammers. Finally, by setting up a controlled, IRB-approved, experiment where we interact with 60 different scammers, we experience first-hand their social engineering tactics, while collecting detailed statistics of the entire process. We explain how our findings can be used by law-enforcing agencies and propose technical and educational countermeasures for helping users avoid being victimized by
technical support scams.

BoingBoing post.

NSA Using Cyberattack for Defense

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/02/nsa_using_cyber.html

These days, it’s rare that we learn something new from the Snowden documents. But Ben Buchanan found something interesting. The NSA penetrates enemy networks in order to enhance our defensive capabilities.

The data the NSA collected by penetrating BYZANTINE CANDOR’s networks had concrete forward-looking defensive value. It included information on the adversary’s “future targets,” including “bios of senior White House officials, [cleared defense contractor] employees, [United States government] employees” and more. It also included access to the “source code and [the] new tools” the Chinese used to conduct operations. The computers penetrated by the NSA also revealed information about the exploits in use. In effect, the intelligence gained from the operation, once given to network defenders and fed into automated systems, was enough to guide and enhance the United States’ defensive efforts.

This case alludes to important themes in network defense. It shows the persistence of talented adversaries, the creativity of clever defenders, the challenge of getting actionable intelligence on the threat, and the need for network architecture and defenders capable of acting on that information. But it also highlights an important point that is too often overlooked: not every intrusion is in service of offensive aims. There are genuinely defensive reasons for a nation to launch intrusions against another nation’s networks.

[…]

Other Snowden files show what the NSA can do when it gathers this data, describing an interrelated and complex set of United States programs to collect intelligence and use it to better protect its networks. The NSA’s internal documents call this “foreign intelligence in support of dynamic defense.” The gathered information can “tip” malicious code the NSA has placed on servers and computers around the world. Based on this tip, one of the NSA’s nodes can act on the information, “inject[ing a] response onto the Internet towards [the] target.” There are a variety of responses that the NSA can inject, including resetting connections, delivering malicious code, and redirecting internet traffic.

Similarly, if the NSA can learn about the adversary’s “tools and tradecraft” early enough, it can develop and deploy “tailored countermeasures” to blunt the intended effect. The NSA can then try to discern the intent of the adversary and use its countermeasure to mitigate the attempted intrusion. The signals intelligence agency feeds information about the incoming threat to an automated system deployed on networks that the NSA protects. This system has a number of capabilities, including blocking the incoming traffic outright, sending unexpected responses back to the adversary, slowing the traffic down, and “permitting the activity to appear [to the adversary] to complete without disclosing that it did not reach [or] affect the intended target.”

These defensive capabilities appear to be actively in use by the United States against a wide range of threats. NSA documents indicate that the agency uses the system to block twenty-eight major categories of threats as of 2011. This includes action against significant adversaries, such as China, as well as against non-state actors. Documents provide a number of success stories. These include the thwarting of a BYZANTINE HADES intrusion attempt that targeted four high-ranking American military leaders, including the Chief of Naval Operations and the Chairman of the Joint Chiefs of Staff; the NSA’s network defenders saw the attempt coming and successfully prevented any negative effects. The files also include examples of successful defense against Anonymous and against several other code-named entities.

I recommend Buchanan’s book: The Cybersecurity Dilemma: Hacking, Trust and Fear Between Nations.

Recovering an iPhone 5c Passcode

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2016/09/recovering_an_i.html

Remember the San Bernardino killer’s iPhone, and how the FBI maintained that they couldn’t get the encryption key without Apple providing them with a universal backdoor? Many of us computer-security experts said that they were wrong, and there were several possible techniques they could use. One of them was manually removing the flash chip from the phone, extracting the memory, and then running a brute-force attack without worrying about the phone deleting the key.

The FBI said it was impossible. We all said they were wrong. Now, Sergei Skorobogatov has proved them wrong. Here’s his paper:

Abstract: This paper is a short summary of a real world mirroring attack on the Apple iPhone 5c passcode retry counter under iOS 9. This was achieved by desoldering the NAND Flash chip of a sample phone in order to physically access its connection to the SoC and partially reverse engineering its proprietary bus protocol. The process does not require any expensive and sophisticated equipment. All needed parts are low cost and were obtained from local electronics distributors. By using the described and successful hardware mirroring process it was possible to bypass the limit on passcode retry attempts. This is the first public demonstration of the working prototype and the real hardware mirroring process for iPhone 5c. Although the process can be improved, it is still a successful proof-of-concept project. Knowledge of the possibility of mirroring will definitely help in designing systems with better protection. Also some reliability issues related to the NAND memory allocation in iPhone 5c are revealed. Some future research directions are outlined in this paper and several possible countermeasures are suggested. We show that claims that iPhone 5c NAND mirroring was infeasible were ill-advised.

Susan Landau explains why this is important:

The moral of the story? It’s not, as the FBI has been requesting, a bill to make it easier to access encrypted communications, as in the proposed revised Burr-Feinstein bill. Such “solutions” would make us less secure, not more so. Instead we need to increase law enforcement’s capabilities to handle encrypted communications and devices. This will also take more funding as well as redirection of efforts. Increased security of our devices and simultaneous increased capabilities of law enforcement are the only sensible approach to a world where securing the bits, whether of health data, financial information, or private emails, has become of paramount importance.

Or: The FBI needs computer-security expertise, not backdoors.

Patrick Ball writes about the dangers of backdoors.

EDITED TO ADD (9/23): Good article from the Economist.

The Unfalsifiability of Security Claims

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2016/05/the_unfalsifiab.html

Interesting research paper: Cormac Herley, “Unfalsifiability of security claims:

There is an inherent asymmetry in computer security: things can be declared insecure by observation, but not the reverse. There is no observation that allows us to declare an arbitrary system or technique secure. We show that this implies that claims of necessary conditions for security (and sufficient conditions for insecurity) are unfalsifiable. This in turn implies an asymmetry in self-correction: while the claim that countermeasures are sufficient is always subject to correction, the claim that they are necessary is not. Thus, the response to new information can only be to ratchet upward: newly observed or speculated attack capabilities can argue a countermeasure in, but no possible observation argues one out. Further, when justifications are unfalsifiable, deciding the relative importance of defensive measures reduces to a subjective comparison of assumptions. Relying on such claims is the source of two problems: once we go wrong we stay wrong and errors accumulate, and we have no systematic way to rank or prioritize measures.

This is both true and not true.

Mostly, it’s true. It’s true in cryptography, where we can never say that an algorithm is secure. We can either show how it’s insecure, or say something like: all of these smart people have spent lots of hours trying to break it, and they can’t — but we don’t know what a smarter person who spends even more hours analyzing it will come up with. It’s true in things like airport security, where we can easily point out insecurities but are unable to similarly demonstrate that some measures are unnecessary. And this does lead to a ratcheting up on security, in the absence of constraints like budget or processing speed. It’s easier to demand that everyone take off their shoes for special screening, or that we add another four rounds to the cipher, than to argue the reverse.

But it’s not entirely true. It’s difficult, but we can analyze the cost-effectiveness of different security measures. We can compare them with each other. We can make estimations and decisions and optimizations. It’s just not easy, and often it’s more of an art than a science. But all is not lost.

Still, a very good paper and one worth reading.

Yubico: Secure hardware vs. open source

Post Syndicated from corbet original http://lwn.net/Articles/687676/rss

Yubico has posted a
blog entry
defending the company’s decision to switch to closed-source
code in the Yubikey 4 product. “If you have to pick only one,
is it more important to have the source code available for review or to
have a product that includes serious countermeasures for attacks against
the integrity of your keys?

See also: Konstantin
Ryabitsev’s response
to this posting. “When it comes to any
hardware, we must at some point trust the manufacturer — unless we have
very large budgets that would allow us to fully monitor every step of the
manufacturing process. In the absence of such large budgets, we must base
our trust on the company’s prior record and their willingness to work with
the community to show that their hands are clean and their intentions are
pure. Putting out a blackbox proprietary device after all the good will you
have built up with NEOs sends the exact opposite message.

Details about Juniper’s Firewall Backdoor

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2016/04/details_about_j.html

Last year, we learned about a backdoor in Juniper firewalls, one that seems to have been added into the code base.

There’s now some good research: “A Systematic Analysis of the Juniper Dual EC Incident,” by Stephen Checkoway, Shaanan Cohney, Christina Garman, Matthew Green, Nadia Heninger, Jacob Maskiewicz, Eric Rescorla, Hovav Shacham, and Ralf-Philipp Weinmann:

Abstract: In December 2015, Juniper Networks announced that unknown attackers had added unauthorized code to ScreenOS, the operating system for their NetScreen VPN routers. This code created two vulnerabilities: an authentication bypass that enabled remote administrative access, and a second vulnerability that allowed passive decryption of VPN traffic. Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker. The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator’s output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper’s countermeasures against a Dual EC attack are never executed. Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.

We still don’t know who installed the back door.