Jump to content

Search the Community

Showing results for tags 'vulnerabilities'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Welcome New Members !
    • General Discussion
    • Site News
  • DevOps & SRE
    • DevOps & SRE General Discussion
    • Data Engineering, Data Science & AI
    • Development & Programming
    • CI/CD & GitOps
    • Docker, Containers, Microservices & Serverless
    • Infrastructure-as-Code
    • Kubernetes
    • Linux
    • Monitoring, Observability & Logging
    • Security
  • Cloud Providers
    • Amazon Web Services
    • Google Cloud Platform
    • Microsoft Azure
    • Red Hat OpenShift

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


LinkedIn Profile URL


About Me


Development Experience


Cloud Experience


Current Role


Skills


Certifications


Favourite Tools


Interests

  1. Incidents It has been implicated in activity which resembles scanning remote hosts on the internet for security vulnerabilities. Activity of this nature is forbidden in the AWS Acceptable Use Policy (https://aws.amazon.com/aup/). We’ve included the original report below for your review. This is a notification of unauthorized uses of systems or networks. We have observed IP addresses from your network probing my servers for TCP open ports. Due to their dubious behavior, they are suspected to be compromised botnet computers. If you regularly collect IP traffic information of your network, you will see the IPs listed connected to various TCP ports of my server at the time logged, and I suspect that they also connected to TCP ports of many other IPs. If a Linux system was at the attacker’s IP, you might want to use the command “netstat -ntp” to list its active network connections. If there is still some suspicious connection, find out what PID/program/user ID they belong to as you might find something to help you solve this problem. In addition to the above, kindly notify the victims (owners of those botnet computers) as this will assist them in taking the appropriate action to clean their computers. Once this action is completed, not only will it prevent severe incidents such as data leakage and DDos but, it will also stand off botnets from taking up your network bandwidth. Solution Step – 1 – Investigate the Process $ netstat -ntp $ ps -p 207082 -o command= $ ls -l /proc/207082/exe Step 2 – Check for Service Units or Cron Jobs The process might be started by a systemd service or a cron job: Systemd service: Check for custom systemd service files in /etc/systemd/system/ or /lib/systemd/system/ and use systemctl to list all services to see if any custom or suspicious service is running. Step 3 – Stop and Disable the Process If the process is managed by a systemd service, disable and stop it: $ sudo systemctl stop servicename.service $ sudo systemctl disable servicename.service If it's a cron job, remove or comment out the line in the crontab. Step 4 – Remove Executable and Clean Up After identifying the executable, consider carefully removing it if it's confirmed to be malicious or not needed: $ sudo rm /path/to/executable Be cautious, as removing system files or legitimate processes can harm your system. 5. Further Security Measures Rootkit Check: Since this process appears suspicious, it’s a good idea to run a tool like rkhunter or chkrootkit to check for rootkits. Malware Scan: Use a Linux-based antivirus tool to scan your system for malware. Audit Logs: Check /var/log/auth.log, /var/log/syslog, or relevant system logs for any unusual activity, especially around the times the process was started. System Updates: Ensure your system and all applications are up-to-date with the latest security patches. Firewall Review: Verify your iptables rules and ensure no unwanted rules are allowing traffic through. Network Monitoring: Monitor outbound and inbound connections for further suspicious activities. CULPRIT#1 I see the process was getting created by daemon user and through crontab file /var/tmp/bash18 file /var/tmp/sh18 file /var/tmp/init18 file /var/bash18 file /var/sh18 file /var/init18 file /var/lock/bash18 file /var/lock/sh18 file /var/lock/init18 Investigation Further -> How this code was added in Crontab? I am wondering how these executable such as bash18, sh18 and init18 is set in user daemon crontab using XAMPP. Any clue? To search through your JavaScript (.js) and PHP (.php) codebase for patterns that might indicate code responsible for adding cron jobs, you can use the grep command in Linux. Basic grep Search This searches all PHP and JS files for the word "crontab": $ grep -r --include=\*.{php,js} "crontab" . Search for Shell Execution Functions Many malicious scripts use PHP's shell execution capabilities (exec, shell_exec, system, passthru, and backticks) to run system commands. $ grep -r --include=\*.php "\(exec\|shell_exec\|system\|passthru\|`\)" . This command will search for any of the mentioned functions in PHP files. Note the use of backslashes to escape certain characters and the use of \| to indicate an "OR" condition. Searching for Suspicious Base64 Encodings Malicious code is often encoded in Base64 to obfuscate its presence. Searching for Base64 encoded strings can sometimes uncover hidden malicious code. $ grep -r --include=\*.{php,js} "base64_decode" . The post DevSecOps: scanning remote hosts on the internet for security vulnerabilities appeared first on DevOpsSchool.com. View the full article
  2. iPhone and iPad owners may want to update to iOS 17.4 and iPadOS 17.4 in the near future, as the updates address two security vulnerabilities that may have been exploited to gain access to user devices. In the security support document for the updates, Apple says that it "is aware of a report" that RTKit and kernel vulnerabilities may have been exploited by bad actors.Impact: An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited.Apple fixed the memory corruption issue with improved validation to patch the security hole. iOS 17.4 and iPadOS 17.4 also address an Accessibility vulnerability and an issue with Safari Private Browsing that could allow locked tabs to be briefly visible while switching tab groups. The software updates were released this morning and are available on eligible iPhones and iPads by going to Settings > General > Software Update.Related Roundups: iOS 17, iPadOS 17Related Forums: iOS 17, iPadOS 17 This article, "Make Sure to Update: iOS 17.4 and iPadOS 17.4 Fix Two Major Security Vulnerabilities" first appeared on MacRumors.com Discuss this article in our forums View the full article
  3. Development and security teams are becoming overwhelmed by an ever-growing backlog of security vulnerabilities requiring their attention. Although these vulnerability insights are essential to safeguard organizations and their customers from potential threats, the findings are often bloated with a high volume of noise, especially from false positives. The 2022 Cloud Security Alert Fatigue Report states that more than 40% of alerts from security tools are false positives, which means that teams can be inundated with vulnerabilities that pose no actual risk. The impact of these false positives includes delayed releases, wasted productivity, internal friction, burnout, and eroding customer trust, all of which accumulate significant financial loss for organizations. How can developers and security professionals cut through the noise so that they can more effectively manage vulnerabilities and focus on what truly matters? That is where the Vulnerability Exploitability eXchange (VEX) comes in. In this article, we’ll explain how VEX works with Docker Scout and walk through how you can get started. What is VEX? VEX, developed by the National Telecommunications and Information Administration (NTIA), is a specification aimed at capturing and conveying information about exploitable vulnerabilities within a product. Among other details, the framework classifies vulnerability status into four key categories, forming the core of a VEX document: Not affected — No remediation is required regarding this vulnerability. Affected — Actions are recommended to remediate or address this vulnerability. Fixed — These product versions contain a fix for the vulnerability. Under Investigation — Whether these product versions are affected by the vulnerability is still unknown. An update will be provided in a later release. By ingesting the context from VEX, organizations can distinguish the noise from the confirmed exploitable vulnerabilities to get a more accurate picture of their attack surface and bring focus to their remediation activities. For example, vulnerabilities assigned a “not affected” status in the VEX document may potentially be ruled out as false positives and hidden from tool outputs to minimize distraction. Although the practice of documenting software vulnerability context is not novel per se, VEX itself represents an advancement over solutions that have traditionally ruled over the vulnerability management processes, such as emails, spreadsheets, Confluence pages, and Jira tickets. What sets VEX apart are its standardized and machine-readable features, which make it much better suited for integration and automation within an organization’s vulnerability ecosystem, resulting in a more streamlined and effective approach to vulnerability management without unnecessary resource drain. However, to yield these results — repeatedly and at scale — the technology landscape surrounding VEX must first evolve to deliver tools and experiences that can successfully put VEX data into action in verifiable, automatable, and meaningful ways. For more information on VEX, refer to the one-page summary (PDF) by NTIA. Want to get started with VEX? Docker can help The implementation of VEX is still nascent in the industry and widespread utilization and adoption will be key in unleashing its full potential. Docker, too, is early in its VEX journey, but read on for how we’re helping our users get started. Use Docker Scout with local VEX documents If you want to try how VEX works with Docker Scout, the quickest way to get up and running is to create a local VEX document with the tool of your choice, such as vexctl, and incorporate it into your image analysis with the --vex-location flag for the docker scout cves command. $ mkdir -p /usr/local/share/vex $ vexctl create [options] --file /usr/local/share/vex/example.vex.json $ docker scout cves --vex-location /usr/local/share/vex <image-reference> Embed VEX documents as attestations The new docker scout attestation add command lets you attach VEX documents to images as in-toto attestations, which means VEX statements are available on and distributed together with the image. $ docker scout attestation add \ --file /usr/local/share/vex/example.vex.json \ --predicate-type https://openvex.dev/ns/v0.2.0 \ <image> Docker Scout automatically incorporates any VEX attestations into the results when you analyze images on the CLI. It also works with attestations signed with Sigstore and attached using vexctl attest --attest --sign. Automatically create VEX documents with Sysdig The Sysdig integration for Docker Scout detects what packages are being loaded into memory in your runtime environment and automatically creates VEX statements for filtering out non-applicable CVEs. Try it out We are working on embedding the above capability and more into Docker Scout so that users can effortlessly generate and apply VEX to vanquish their false positives for good. Simultaneously, we are exploring VEX for Docker Official Images to allow upstream maintainers to indicate non-applicable CVEs in their images, which can improve tooling (e.g., scanner) accuracy if VEX is taken into account. In the meantime, if you are curious about how this all works in practice, we’ve created a guide that walks you through the steps of creating a VEX document, applying it to image analysis, and creating VEX attestations. Learn more Read the guide: Suppress image vulnerabilities with VEX. Subscribe to the Docker Newsletter. Get the latest release of Docker Desktop. Vote on what’s next! Check out our public roadmap. Have questions? The Docker community is here to help. New to Docker? Get started. View the full article
  4. A recent survey found that, on average, organizations have 55.5 security vulnerabilities each day in their remediation queue, with at least one critical.View the full article
  5. January 31 update: Patches for runc and BuildKit are now available. We at Docker prioritize the security and integrity of our software and the trust of our users. Security researchers at Snyk Labs recently identified and reported four security vulnerabilities in the container ecosystem. One of the vulnerabilities, CVE-2024-21626, concerns the runc container runtime, and the other three affect BuildKit (CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653). We want to assure our community that our team, in collaboration with the reporters and open source maintainers, has been diligently working on coordinating and implementing necessary remediations. We are committed to maintaining the highest security standards. We will publish patched versions of runc, BuildKit, and Moby on January 31 and release an update for Docker Desktop on February 1 to address these vulnerabilities. Additionally, our latest Moby and BuildKit releases will include fixes for CVE-2024-23650 and CVE-2024-24557, discovered respectively by an independent researcher and through Docker’s internal research initiatives. Versions impactedrunc<= 1.1.11BuildKit<= 0.12.4Moby (Docker Engine)<= 25.0.1 and <= 24.0.8Docker Desktop<= 4.27.0 These vulnerabilities can only be exploited if a user actively engages with malicious content by incorporating it into the build process or running a container from a suspect image (particularly relevant for the CVE-2024-21626 container escape vulnerability). Potential impacts include unauthorized access to the host filesystem, compromising the integrity of the build cache, and, in the case of CVE-2024-21626, a scenario that could lead to full container escape. We strongly urge all customers to prioritize security by applying the available updates as soon as they are released. Timely application of these updates is the most effective measure to safeguard your systems against these vulnerabilities and maintain a secure and reliable Docker environment. What should I do if I’m on an affected version? If you are using affected versions of runc, BuildKit, Moby, or Docker Desktop, make sure to update to the latest versions as soon as patched versions become available: Patched versionsrunc>= 1.1.12BuildKit>= 0.12.5Moby (Docker Engine)>= 25.0.2 and >= 24.0.9Docker Desktop>= 4.27.1 If you are unable to update to an unaffected version promptly after it is released, follow these best practices to mitigate risk: Only use trusted Docker images (such as Docker Official Images). Don’t build Docker images from untrusted sources or untrusted Dockerfiles. If you are a Docker Business customer using Docker Desktop and unable to update to v4.27.1 immediately after it’s released, make sure to enable Hardened Docker Desktop features such as: Enhanced Container Isolation, which mitigates the impact of CVE-2024-21626 in the case of running containers from malicious images. Image Access Management, and Registry Access Management, which give organizations control over which images and repositories their users can access. For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid using BuildKit frontend from an untrusted source. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using the buildctl build command. To mitigate CVE-2024-24557, make sure to either use BuildKit or disable caching when building images. From the CLI this can be done via the DOCKER_BUILDKIT=1 environment variable (default for Moby >= v23.0 if the buildx plugin is installed) or the --no-cache flag. If you are using the HTTP API directly or through a client, the same can be done by setting nocache to true or version to 2 for the /build API endpoint. Technical details and impact CVE-2024-21626 (High) In runc v1.1.11 and earlier, due to certain leaked file descriptors, an attacker can gain access to the host filesystem by causing a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, or by tricking a user to run a malicious image and allow a container process to gain access to the host filesystem through runc run. The attacks can also be adapted to overwrite semi-arbitrary host binaries, allowing for complete container escapes. Note that when using higher-level runtimes (such as Docker or Kubernetes), this vulnerability can be exploited by running a malicious container image without additional configuration or by passing specific workdir options when starting a container. The vulnerability can also be exploited from within Dockerfiles in the case of Docker. The issue has been fixed in runc v1.1.12. CVE-2024-23651 (High) In BuildKit <= v0.12.4, two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition, leading to files from the host system being accessible to the build container. This will only occur if a user is trying to build a Dockerfile of a malicious project. The issue will be fixed in BuildKit v0.12.5. CVE-2024-23652 (High) In BuildKit <= v0.12.4, a malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container from the host system. This will only occur if a user is using a malicious Dockerfile. The issue will be fixed in BuildKit v0.12.5. CVE-2024-23653 (High) In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. In BuildKit <= v0.12.4, it is possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special security.insecure entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. The issue will be fixed in BuildKit v0.12.5. CVE-2024-23650 (Medium) In BuildKit <= v0.12.4, a malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic. The issue will be fixed in BuildKit v0.12.5. CVE-2024-24557 (Medium) In Moby <= v25.0.1 and <= v24.0.8, the classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered a valid cache candidate for some build steps. The issue will be fixed in Moby >= v25.0.2 and >= v24.0.9. How are Docker products affected? The following Docker products are affected. No other products are affected by these vulnerabilities. Docker Desktop Docker Desktop v4.27.0 and earlier are affected. Docker Desktop v4.27.1 will be released on February 1 and includes runc, BuildKit, and dockerd binaries patches. In addition to updating to this new version, we encourage all Docker users to diligently use Docker images and Dockerfiles and ensure you only use trusted content in your builds. Docker Build Cloud Any new Docker Build Cloud builder instances will be provisioned with the latest Docker Engine and BuildKit versions after fixes are released and will, therefore, be unaffected by these CVEs. Docker will also be rolling out gradual updates to any existing builder instances. Security at Docker At Docker, we know that part of being developer-obsessed is providing secure software to developers. We appreciate the responsible disclosure of these vulnerabilities. If you’re aware of potential security vulnerabilities in any Docker product, report them to security@docker.com. For more information on Docker’s security practices, see our website. Advisory links Runc CVE-2024-21626 BuildKit CVE-2024-23650 CVE-2024-23651 CVE-2024-23652 CVE-2024-23653 Moby CVE-2024-24557 View the full article
  6. Google's Vulnerability Reward Program offers up to $31,337 for discovering potential hazards. Google joins OpenAI and Microsoft in rewarding AI bug hunts.View the full article
  7. There had been “thousands” of hyper-volumetric HTTP distributed denial of service (DDoS) attacks in the time since the HTTP/2 Rapid Reset vulnerability was disclosed, a new report from Cloudflare has claimed, adding that 89 of those exceeded 100 million requests per second (rps). Thanks to these attacks, the total amount of HTTP DDoS attacks for the third quarter of the year, compared to Q2, was up 65%, the company added. "Similarly, L3/4 DDoS attacks also increased by 14%,” it added... View the full article
  8. This Safari vulnerability has not been exploited in the wild. Apple offers a mitigation, but the fix needs to be enabled manually.View the full article
  9. After reading the technical details about this zero-day that targeted governmental entities and a think tank in Europe and learning about the Winter Vivern threat actor, get tips on mitigating this cybersecurity attack.View the full article
  10. The vulnerabilities, one of which was rated critical and one of which was rated highly severe, affect Cisco IOS XE software.View the full article
  11. The number of devices exposing the web UI on the internet, a timeline and technical details about this malicious activity, and tips for mitigating this zero-day threat are featured.View the full article
  12. A vulnerability in the HTTP/2 network protocol is currently being exploited, resulting in the largest DDoS attack in history. Find out what security teams should do now, and hear what Cloudflare's CEO has to say about this DDoS.View the full article
  13. Over the last few years, Google's DDoS Response Team has observed the trend that distributed denial-of-service (DDoS) attacks are increasing exponentially in size. Last year, we blocked the largest DDoS attack recorded at the time. This August, we stopped an even larger DDoS attack — 7½ times larger — that also used new techniques to try to disrupt websites and Internet services. This new series of DDoS attacks reached a peak of 398 million requests per second (rps), and relied on a novel HTTP/2 “Rapid Reset” technique based on stream multiplexing that has affected multiple Internet infrastructure companies. By contrast, last year’s largest-recorded DDoS attack peaked at 46 million rps. For a sense of scale, this two minute attack generated more requests than the total number of article views reported by Wikipedia during the entire month of September 2023... View the full article
  14. The maintainers of curl, the popular command-line tool and library for transferring data with URLs, will release curl 8.4.0 on October 11, 2023. This version will include a fix for two common vulnerabilities and exposures (CVEs), one of which the curl maintainers rate as “HIGH” severity and described as “probably the worst curl security flaw in a long time.” The CVE IDs are: CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool) CVE-2023-38546: severity LOW (affects libcurl only, not the tool) View the full article
  15. Detecting vulnerabilities in open-source software requires a holistic approach, and security best practices recommend scanning early and often throughout your development lifecycle to help maintain an effective security posture. However, only scanning in the CI/CD pipeline or registry can miss artifacts and containers that are deployed to production through other mechanisms. Likewise, only scanning runtimes can pass over software supply chain vulnerabilities. To address these security concerns, Artifact Analysis in partnership with Google Kubernetes Engine (GKE) is introducing a new offering called Advanced Vulnerability Insights in public preview. We’re also expanding scanning language support for Artifact Registry... View the full article
  16. Dynatrace has extended the Application Security Module it provides for its observability platform to protect against vulnerabilities in runtime environments, including the Java Virtual Machine (JVM), Node.js runtime and .NET CLR. In addition, Dynatrace has extended its support to applications built using the Go programming language. The Dynatrace Application Security Module leverages existing Dynatrace tracing […] View the full article
  17. A survey of 200 security professionals found nearly 83% of respondents reported that an increase in the rate at which applications are being deployed has led to an increase in the reintroduction of previously remediated vulnerabilities. The survey, conducted by Waratek, a provider of tools for managing security-as-code, found 93% of the security professionals polled […] The post Poor App Remediation Creates a Vicious Vulnerability Cycle appeared first on DevOps.com. View the full article
  18. Rezilion today announced general availability of a platform that enables DevOps teams to better prioritize remediation efforts by identifying which vulnerabilities both run in memory and actually impact a class or function that can be executed. Liran Tancman, Rezilion CEO, said the biggest DevSecOps challenge organizations face today is that the bulk of vulnerabilities that […] The post Rezilion Launches Vulnerability Prioritization Platform appeared first on DevOps.com. View the full article
  19. Spell checkers, grammar checkers and predictive keyboards all help reduce errors in written communication, but in a creative medium where writers need to innovate new expressions, nothing can eliminate all errors. The same is true in the code we write. Of course, your code is probably perfect but, on average, all code has bugs. Some […] The post The Two Types of Code Vulnerabilities appeared first on DevOps.com. View the full article
  20. Tags: kubernetes, software supply chain security..View the full article
  21. In this post, we’ll demonstrate how you can leverage Amazon CodeGuru Reviewer Command Line Interface (CLI) to integrate CodeGuru Reviewer into your Jenkins Continuous Integration & Continuous Delivery (CI/CD) pipeline. Note that the solution isn’t limited to Jenkins, and it would be equally useful with any other build automation tool. Moreover, it can be integrated at any stage of your SDLC as part of the White-box testing. For example, you can integrate the CodeGuru Reviewer CLI as part of your software development process, as well as run it on your dev machine before committing the code... View the full article
  22. New JFrog Xray Integrations with ServiceNow Lightstep Incident Response and Spoke Help IT and SRE Teams Proactively Secure the Software Supply Chain with Real-Time, Cross-Department Visibility & Team Activation for Security Incidents Sunnyvale, CA and San Diego, CA, May 26, 2022 — (swampUP 2022) – JFrog Ltd. (“JFrog”) (NASDAQ: FROG), the Liquid Software company and creators of the JFrog DevOps […] The post JFrog Integrates with ServiceNow to Improve Software Security Vulnerability Response Times with “ServiceOps” appeared first on DevOps.com. View the full article
  23. IT has scanners for everything. And by everything, I mean everything. We scan source code for vulnerabilities and data leaks. We scan apps for vulnerabilities. We scan the network for holes. We scan our cards for access … Okay, that last one doesn’t fit, but you get the idea. Know what we don’t scan for […] View the full article
  24. Community Attestation Service addresses need for integrated, continuous security for developers KubeCon Europe, VALENCIA, Spain, May 16, 2022 — Codenotary, leaders in software supply chain security, today announced the addition of the first-ever free background vulnerability scanning service combined with a free and open source Community Attestation Service (CAS) code signing and attestation service to further […] The post Codenotary Adds Vulnerability Scanning to Popular Community Platform for Open Source Supply Chain Security appeared first on DevOps.com. View the full article
  • Forum Statistics

    39.7k
    Total Topics
    39.9k
    Total Posts
×
×
  • Create New...