DevOps | Breaking Cybersecurity News | The Hacker News

Less than a month ago, Twitter indirectly acknowledged that some of its source code had been leaked on the code-sharing platform GitHub by sending a copyright infringement notice to take down the incriminated repository. The latter is now inaccessible, but according to the media, it was accessible to the public for several months. A user going by the name FreeSpeechEnthousiast committed thousands of documents belonging to the social media platform over several months.  While there is no concrete evidence to support this hypothesis, the timing of the leak and the ironic username used by the perpetrator suggest that the leak was a deliberate act aimed at causing harm to the company. Although it is still too early to measure the impact of this leak on the health of Twitter, this incident should be an opportunity for all software vendors to ask a simple question:  what if this happened to us? Protecting sensitive information in the software industry is becoming increasingly critical as

LastPass, which in December 2022 disclosed a severe data breach that allowed threat actors to access encrypted password vaults, said it happened as a result of the same adversary launching a second attack on its systems. The company said one of its DevOps engineers had their personal home computer hacked and infected with a keylogger as part of a sustained cyber attack that exfiltrated sensitive data from its Amazon AWS cloud storage servers. "The threat actor leveraged information stolen during the first incident, information available from a third-party data breach, and a vulnerability in a third-party media software package to launch a coordinated second attack," the password management service  said . This intrusion targeted the company's infrastructure, resources, and the aforementioned employee from August 12, 2022, to October 26, 2022. The original incident, on the other hand, ended on August 12, 2022. The  August breach  saw the intruders accessing source cod

Identities now transcend human boundaries. Within each line of code and every API call lies a non-human identity. These entities act as programmatic access keys, enabling authentication and facilitating interactions among systems and services, which are essential for every API call, database query, or storage account access. As we depend on multi-factor authentication and passwords to safeguard human identities, a pressing question arises: How do we guarantee the security and integrity of these non-human counterparts? How do we authenticate, authorize, and regulate access for entities devoid of life but crucial for the functioning of critical systems? Let's break it down. The challenge Imagine a cloud-native application as a bustling metropolis of tiny neighborhoods known as microservices, all neatly packed into containers. These microservices function akin to diligent worker bees, each diligently performing its designated task, be it processing data, verifying credentials, or

The (Other) Risk in Finance A few years ago, a Washington-based real estate developer received a document link from First American – a financial services company in the real estate industry – relating to a deal he was working on. Everything about the document was perfectly fine and normal. The odd part, he  told  a reporter, was that if he changed a single digit in the URL, suddenly, he could see somebody else's document. Change it again, a different document. With no technical tools or expertise, the developer could retrieve FirstAm records dating back to 2003 – 885  million  in total, many containing the kinds of sensitive data disclosed in real estate dealings, like bank details, social security numbers, and of course, names and addresses. That nearly a billion records could leak from so simple a web vulnerability seemed shocking. Yet even more severe consequences befall financial services companies every week. Verizon, in its most recent  Data Breach Investigations Report ,

In an ideal world, security and development teams would be working together in perfect harmony. But we live in a world of competing priorities, where DevOps and security departments often butt heads with each other. Agility and security  are often at odds with each other— if a new feature is  delivered quickly but  contains security vulnerabilities, the SecOps team will need to scramble the release and patch the vulnerabilities, which can take days or weeks. On the other hand, if the SecOps team takes too long to review and approve a new feature, the development team will get frustrated with the slow pace of delivery. Security needs to move slowly and cautiously, while development wants to "move fast and break things" and release new features quickly. DevOps teams can view security as an impediment to their work instead of an important part of the process. With each team pulling in opposite directions, there is often tension and conflict between the two teams, slowing deve

DevOps platform CircleCI on Wednesday urged its customers to rotate all their secrets following an unspecified security incident. The company said an investigation is currently ongoing, but emphasized that "there are no unauthorized actors active in our systems." Additional details are expected to be shared in the coming days. "Immediately rotate any and all secrets stored in CircleCI," CircleCI's chief technology officer, Rob Zuber,  said  in a terse advisory. "These may be stored in project environment variables or in contexts." CircleCI is also recommending users to review internal logs for signs of any unauthorized access starting from December 21, 2022, to January 4, 2023, or until when the secrets are rotated. The software development service did not disclose any further specifics about the breach, but said it has also invalidated all  Project API tokens  and that they need to be replaced. The disclosure comes weeks after the company anno

GitHub has put out an advisory detailing what may be an ongoing phishing campaign targeting its users to steal credentials and two-factor authentication (2FA) codes by impersonating the CircleCI DevOps platform. The Microsoft-owned code hosting service said it learned of the attack on September 16, 2022, adding the campaign impacted "many victim organizations." The fraudulent messages claim to notify users that their CircleCI sessions have expired and that they should log in using GitHub credentials by clicking on a link. Another bogus email  revealed by CircleCI  prompts users to sign in to their GitHub accounts to accept the company's new Terms of Use and Privacy Policy by following the link embedded in the message. Regardless of the lure, doing so redirects the target to a lookalike GitHub login page designed to steal and exfiltrate the entered credentials as well as the Time-based One Time Password (TOTP) codes in real-time to the attacker, effectively allowing

SecDevOps is, just like DevOps, a transformational change that organizations undergo at some point during their lifetime. Just like many other big changes, SecDevOps is commonly adopted after a reality check of some kind: a big damaging cybersecurity incident, for example. A major security breach or, say, consistent problems in achieving development goals signals to organizations that the existing development framework doesn't work and that something new is needed. But what exactly is SecDevOps, why should you embrace it – and how can you do it more easily in practice? The fundamentals of SecDevOps By itself, SecDevOps is not just one single improvement. You may see it as a new tool, or set of tools, or perhaps a different mindset. Some might see SecDevOps as a culture. In reality, it's all of those factors wrapped into a new approach to development that's intended to put security first. SecDevOps rely on highly reproducible scenarios, touching on topics such as system

DevOps platform GitLab this week issued patches to address a critical security flaw in its software that could lead to arbitrary code execution on affected systems. Tracked as  CVE-2022-2884 , the issue is rated 9.9 on the CVSS vulnerability scoring system and impacts all versions of GitLab Community Edition (CE) and Enterprise Edition (EE) starting from 11.3.4 before 15.1.5, 15.2 before 15.2.3, and 15.3 before 15.3.1. At its core, the security weakness is a case of authenticated remote code execution that can be triggered via the GitHub import API. GitLab credited  yvvdwf  with discovering and reporting the flaw. A successful exploitation of the critical flaw could enable a malicious actor to run malicious code on the target machine, inject malware and backdoors, and seize complete control of the susceptible devices. While the issue has been resolved in versions 15.3.1, 15.2.3, 15.1.5, users also have the option of securing against the flaw by temporarily disabling the GitHub im

GitLab has moved to address a critical security flaw in its service that, if successfully exploited, could result in an account takeover. Tracked as  CVE-2022-1680 , the issue has a CVSS severity score of 9.9 and was discovered internally by the company. The security flaw affects all versions of GitLab Enterprise Edition (EE) starting from 11.10 before 14.9.5, all versions starting from 14.10 before 14.10.4, and all versions starting from 15.0 before 15.0.1. "When group SAML SSO is configured, the SCIM feature (available only on Premium+ subscriptions) may allow any owner of a Premium group to invite arbitrary users through their username and email, then change those users' email addresses via SCIM to an attacker controlled email address and thus — in the absence of 2FA — take over those accounts," GitLab  said . Having achieved this, a malicious actor can also change the display name and username of the targeted account, the DevOps platform provider cautioned in its

Containers revolutionized the development process, acting as a cornerstone for DevOps initiatives, but containers bring complex security risks that are not always obvious. Organizations that don't mitigate these risks are vulnerable to attack.  In this article, we outline how containers contributed to agile development, which unique security risks containers bring into the picture – and what organizations can do to secure containerized workloads, going beyond DevOps to achieve  DevSecOps . Why did containers catch on so fast? Containers are, in many ways, the evolution of virtualization. The goal was to speed up the development process, creating a more agile route from development through to testing and implementation – a method that's more lightweight than using full-blown virtual machines, anyway. At the core of this issue is application compatibility, as applications require certain versions of libraries – which could clash with the requirements of other applications. Container

DevOps platform GitLab has released software updates to address a critical security vulnerability that, if potentially exploited, could permit an adversary to seize control of accounts. Tracked as  CVE-2022-1162 , the issue has a CVSS score of 9.1 and is said to have been discovered internally by the GitLab team. "A hardcoded password was set for accounts registered using an  OmniAuth provider  (e.g., OAuth, LDAP, SAML) in GitLab CE/EE versions 14.7 prior to 14.7.7, 14.8 prior to 14.8.5, and 14.9 prior to 14.9.2 allowing attackers to potentially take over accounts," the company  said  in an advisory published on March 31. GitLab, which has addressed the bug with the latest release of versions 14.9.2, 14.8.5, and 14.7.7 for GitLab Community Edition (CE) and Enterprise Edition (EE), also said it took the step of resetting the password of an unspecified number of users out of an abundance of caution. "Our investigation shows no indication that users or accounts have

Cybersecurity researchers on Tuesday disclosed 14 critical vulnerabilities in the BusyBox Linux utility that could be exploited to result in a denial-of-service (DoS) condition and, in select cases, even lead to information leaks and remote code execution. The security weaknesses, tracked from CVE-2021-42373 through CVE-2021-42386, affect multiple versions of the tool ranging from 1.16-1.33.1, DevOps company JFrog and industrial cybersecurity company Claroty  said  in a joint report. Dubbed "the Swiss Army Knife of Embedded Linux,"  BusyBox  is a widely used software suite combining a variety of common Unix utilities or applets (e.g.,  cp ,  ls ,  grep ) into a single executable file that can run on Linux systems such as programmable logic controllers (PLCs), human-machine interfaces (HMIs), and remote terminal units (RTUs). A quick list of the flaws and the applets they impact is below — man  - CVE-2021-42373 lzma/unlzma  - CVE-2021-42374 ash  - CVE-2021-42375 hus

As software eats the world, the world faces a software security crisis. The movement to modern software such as cloud technologies and microservice architectures is essential to innovate quickly. Yet, nearly three in four developers say that security slows down Agile and DevOps. Neither developers nor security teams are to blame. DevOps speed is held back by a 15-year-old, scan-based application security (AppSec) model designed for the early 2000s. Traditional security tools cannot keep up with today's rapid development pace or modern application portfolio scale. However, sacrificing security for development speed places critical and confidential personal and business information at risk—from financial to healthcare data—and can disrupt operations or even cause outages. Code Scanners Cannot Meet Modern DevOps Legacy AppSec approaches that rely on point-in-time scanning are plagued by development delays and highly inaccurate results. Scans take many hours, if not days—not id