Two flaws in the popular developer cloud platform show how weaknesses in authorization functions and SaaS flaws can put cloud apps at risk.

Two vulnerabilities in Atlassian Jira Align, an agile planning software-as-a-service (SaaS) tool, could allow users with access to the service to become application administrators, and then attack the Atlassian service.

That's according to cybersecurity services firm Bishop Fox, which said in an advisory today that the vulnerabilities typify the risks posed to cloud services by relatively well-known, but often hard to catch, flaws. 

The two vulnerabilities found by Bishop Fox affect the Jira Align application, which is used to set agile-development goals, track efforts toward those goals, and create agile strategies. Because every instance of Jira Align is provisioned by Atlassian, an attacker could gain control of a part of the company's cloud infrastructure, Bishop Fox stated.

One vulnerability, a server-side request forgery (SSRF), could allow a user to retrieve "the AWS credentials of the Atlassian service account that provisioned the Jira Align instance," according to Bishop Fox.

The second vulnerability — in the authorization mechanism for users with the People role — could allow those users to elevate their role to Super Admin, which has access to all settings for the Jira Align tenant, such as resetting accounts and modifying settings.

The combination of the two flaws could allow a significant attack, says Jake Shafer, a security consultant with Bishop Fox, who found the flaws.

"Using the authorization finding would allow a low-privileged user to elevate their role to super admin which, in terms of information disclosure, would allow the attacker to gain access to everything the client of the SaaS had in their Jira deployment," he says. "From there, the attacker could then leverage the SSRF finding to go after the infrastructure of Atlassian themselves."

Both vulnerabilities have been patched — the first within a week and the second within a month, according to the disclosure timeline published by Bishop Fox.

However, companies should note that the increasing reliance on cloud applications has made attacks on cloud services and workloads much more common, so much so that the top class of vulnerability, according to the Open Web Application Security Project (OWASP), is broken authentication and access-control issues.

Furthermore, authorization issues are difficult for automated tools to pinpoint; plus, SSRF is a relatively new class of vulnerability that uses a cloud service's functionality and servers to conduct attacks, often bypassing security at the network edge as well as some internal security measures. 

Atlassian's Jira software has already had to deal with other instances of server-side request forgery, but the company is not alone. In 2019, a former Amazon Web Services used a SSRF vulnerability to steal data from financial firm Capital One.

**How to Combat Cloud Security Bugs**

With cloud services becoming part of operations for the vast majority of companies, tackling the top cloud vulnerabilities is critical, Shafer says.

"With the prevalence of how integrated these SaaS applications have become in the day-to-day operations of small and large companies, it’s important to remember that even these well-established companies can make mistakes," he says. "Trust but verify for all new software you’ll have to be reliant on, especially something as entrenched in the tech."

These most recent vulnerabilities highlight that developers should always make sure to double-check content supplied by users before completing a request, Shafer says. Additional input-sanitization checks could prevent both attacks.

"You're allowing customers into your cloud infrastructure, they may be paying for the service but at the end of the day they should be considered just as untrusted as a potential attacker," he says.

Companies should make sure to either manually test third-party applications or reach out to the cloud provider and check the results of their security assessments. Unfortunately, automated tools are not great at discovering authorization issues, Shafer says.

"These tools rely on a set of instructions or guidelines for what to look for and dealing with authorization issues will be different for every single piece of software out there," he says. "It’s very difficult to establish a set of rules that a scanner can pick up on and say 'Hey, user X shouldn’t be able to do Y in the context of this specific functionality.'"

Shafer lauded Atlassian's response, saying the company "did all the right things." Atlassian did not provide a comment by publishing time.

Atlassian Vulnerabilities Highlight Criticality of Cloud Services

Categories: News
Tags: food

Tags:  medical

Tags:  nhs

Tags:  gousto

Tags:  compromise

Tags:  laptop

Tags:  vouchers

Peter Foy racked up a peculiar list of compromises before being brought to justice



(Read more...)




The post An odd kind of cybercrime: Gift vouchers, medical records, and...food appeared first on Malwarebytes Labs.

Someone with a gift for technology but a nasty habit of using it for very bad things has been spared from going to jail with a suspended sentence. Peter Foy, 18 at the time of his antics, racked up a remarkable, and slightly peculiar, list of compromises before being brought before the court.

**A strange combination**

According to Brighton and Hove news, his spree began in 2019 with the initial purchase of a laptop from Amazon, bought with “fake Honey gift vouchers”. I would love to know more about how this initial foray into system compromise worked, as one would imagine purchasing anything with fake vouchers would be a bit of a tall order. Nevertheless, he did it, and from here a somewhat short life of crime beckoned.

From the South East Regional Organised Crime Unit:

> The court heard that on 13 October, 2019, Foy committed fraud in that he made a false representation to Amazon—that he was entitled to use gift vouchers to buy an Acer laptop. It was using this laptop that Foy committed further offences.

From this report, it’s hard to tell if the vouchers were indeed fake, or obtained without permission. His compromise modus operandi was a combination of breaking into networks run by food retailers, and breaking into networks containing confidential patient records. That’s quite a peculiar mixture.

On the one hand, he was “arranging food deliveries” at a cost of thousands to the affected businesses. On the other, he was accessing patient records of a third party company providing services to the National Health Service. As the release notes, this is during the COVID-19 pandemic, where the last thing we needed was people potentially breaking health record services. Food delivery services also played an important role during lockdown, so any disruption here would also be potentially very disruptive for those most at risk. A strange combination, then, but not a very pleasant one.

**Not quite Robin Hood**

Eventually, he was grabbed by the long arm of the law. None of the available information explains how this happened, but it's likely that a trail was left across the compromised businesses. Even a pro can slip up! One last roll of the dice for the defendant remained in the form of claiming that he was notifying and helping the organisations he compromised.

However, he “demanded financial rewards” from the victims, which isn’t how legitimate help works. If this was his version of a bug bounty program, it isn’t a very good one.

The attempt to downplay the crimes didn't impress the judge much, and he was sentenced to 18 months’ custody, suspended for two years. In addition to this, he’ll also have to perform 300 hours of unpaid work. There's no word if any sort of ban from using digital technology is included in any of this.

**A hopefully short-lived impact**

The details released on this set of attacks are unfortunately sparse, and perhaps not as specific as you’d expect. Detective Inspector Rob Bryant had this to say:

> This case also serves as a timely reminder to anyone using their financial details online to check the security of the data. Foy was able to gain access to many victims’ accounts as they often used the same passwords across more than one account.

The Detective Inspector also went on to suggest making use of two-factor authentication (2FA), which is great advice.

If you’re notified in the near future that you’ve been impacted, or indeed have been contacted already, here’s what you can do:

*   Take the advice on 2FA. Options include SMS, various apps, or even a physical hardware key. A FIDO2 hardware key is the best option.
*   Grab yourself a password manager. They create and remember strong passwords to prevent reuse, and many will refuse to sign in to bogus websites.
*   The various attacks outlined above likely resulted in the attacker seeing personal data he shouldn't. This could put those people at an increased risk of social engineering or identity theft.

An odd kind of cybercrime: Gift vouchers, medical records, and...food

Multiple stored cross-site scripting vulnerabilities in the web user interface of IPFire versions prior to 2.27 allows a remote authenticated attacker with administrative privilege to inject an arbitrary script.

The next Core Update is released: IPFire 2.27 - Core Update 170. It features new IP blocklists for the firewall engine, significant improvements to Pakfire, modernizes the default cryptographic algorithm selection for IPsec connections, as well as a new kernel, and a plethora of bug fixes and security improvements under the hood.

**IP-Reputation Blocking to keep known threats out**

Based on prior development by Tim FitzGeorge, Stefan brought a new feature to the firewall engine, which allows the easy activation of various public IP-based blocklists, just by a single click.

All enabled blocklists are updated automatically at an appropriate interval (a technique we already deployed for updating IPS rulesets), and protect against various threats, such as IP addresses or networks having a poor reputation, being involved with cyber crime hosting, or simply not allocated, hence no traffic should be routed to and from them.

You probably wonder why IPFire now comes with yet another way for IP-based blocking. There are several motivations behind this:

*   IP blocklists are already available for the Intrusion Prevention System. However, it is a rather expensive way for dealing with network traffic that can already be safely dropped based on the reputation of involved IPs. There is no need to waste more CPU resources on it than absolutely necessary - why not let the firewall engine itself handle such traffic, and bother the IPS with more relevant stuff?
*   The "drop all traffic from and to hostile networks" feature is meant as a basic level of network protection suitable for IPFire's _entire_ user base, hence enabled by default. It protects against "the baddest of the bad" on the internet, and does not require any attention or maintenance whatsoever.
*   IP blocklists, as introduced with this Core Update, provide a more fine-grained level, and your mileage may vary: For example, blocking Tor traffic might be appropriate for some IPFire users, but certainly not for all of them. Some may find certain blocklists to be too aggressive for their use-case.

One size doesn't always fit all. The IP blocklist feature is IPFire's way of take this into account, and make further protection against network threats easy and resource-efficient.

**IPsec: MODP-2048 is ejected for new connections in favour of ECP-384/-521**

Following recommendations not to use Diffie-Hellman groups shorter than 3,000 bits after 2022, MODP-2048 has been dropped from the default cryptographic algorithm selection for new IPsec connections. To provide a more performant alternative to MODP-3072 and MODP-4096 and to be more compatible to other vendors in the default configuration, the NIST-standardized elliptic curves ECP-384 and ECP-521 have been added to the defaults for new IPsec connections.

Existing IPsec connections remain unchanged. However, IPFire users operating IPsec connections are advised to revise the cryptographic settings for these, and drop using weak algorithms, if possible.

**Linux Kernel 5.15.59**

Among bug fixes throughout the kernel including security fixes and hardware support improvements, the updated kernel also adds mitigations against Retbleed, another CPU vulnerability affecting various Intel and AMD processors. IPFire's web interface has been updated to display the mitigation state of Retbleed accordingly.

The following kernel-related changes have been made in addition:

*   On x86_64, Intel DMA Remapping Devices (better known as IOMMU) are enabled by default during boot, if available.
*   To reduce attack surface, legacy DRM drivers are no longer available. Since the respective kernel modules have already been blocklisted for a long time, thus unusable, this should not have an impact in production.
*   64-bit ARM users experience improved KASLR thanks to the kernel's memory address now being randomized before unpacking it (#12363).
*   Merging slab caches is no longer permitted, to prevent kernel heap overflows, and adversaries interfering with cache structures used by several programs.
*   Support for PCI pass-through has been enabled to allow mapping PCI devices into VMs running on IPFire (#12754).

**Miscellaneous**

*   Robin Roevens contributed a series of improvements to Pakfire, such as better error handling on downloads, and refactored a lot of code under the hood.
*   He also updated and improved the Zabbix agent add-on, which now features version 6.0.6 (LTS).
*   Support for assigning aliases to multiple RED interfaces has been added.
*   Non-unique hardware UUIDs as well as empty serial numbers are now ignored for computing Fireinfo profile IDs (#12896).
*   The blocklist of the University of Toulouse is now downloaded via HTTPS (#12891).
*   Logwatch summaries are now properly included in backups (#12827).
*   ncurses terminfo files for tmux are now properly shipped, resolving #12905.
*   All logged IPS events are now correctly displayed in the web interface (#12899).
*   Mount options of /boot have been hardened on both existing installations and new x86_64 IPFire instances.
*   On new installations, the partition's size has also been increased to 256 MiB, since components such as the kernel keep getting bigger and bigger.
*   amazon-ssm-agent is now available on 64-bit ARM as well.
*   pyfuse3 is now packaged for BorgBackup (#12611).
*   Two stored XSS vulnerabilities have been fixed, thanks to JPCERT for reaching out (#12925).
*   Updated packages: Bash 5.1.16, bind 9.16.31, GnuTLS 3.7.7, harfbuzz 4.4.1, hdparm 9.64, intel-microcode 20220809, kmod 30, krb5 1.20, logwatch 7.7, lsof 4.95.0, nano 6.4, ninja 1.11.0, OpenSSL 1.1.1q, rpcsvc-proto 1.4.3, screen 4.9.0, sqlite 33900000, suricata 5.0.10, unbound 1.16.2, usbutils 014, vim 9.0, xfsprogs 5.18.0, zlib to incorporate a fix for CVE-2022-37434.
*   Updated add-ons: ClamAV 0.105.1, fmt 9.0.0, git 2.37.1, gptfdisk 1.0.9, gutenprint 5.3.4, haproxy 2.6.0, htop 3.2.1, i2c-tools 4.3,iperf 2.1.7, mpd 0.23.8, NRPE 4.1.0, openvmtools 12.0.5, pcengines-apu-firmware 4.17.0.1, python3-cryptography 36.0.2, qemu 7.0.0, qemu-ga 7.0.0, rsync to patch CVE-2022-29154, Samba 4.16.4, shairport-sync 3cc1ec6

As always, we thank all people contributing to this release in whatever shape and form. Please note IPFire is backed by volunteers, maintaining and improving this distribution in their spare time - should you like what we are doing, please donate to keep the lights on, an consider becoming engaged in development to distribute the load over more shoulders.

CVE-2022-36368: IPFire 2.27 - Core Update 170 released - The IPFire Blog

Cross-site scripting vulnerability in BookStack versions prior to v22.09 allows a remote authenticated attacker to inject an arbitrary script.

Since BookStack can hold important information for users you should be aware of any potential security concerns. Read through the below to ensure you have secured your BookStack instance. Note, The below only relates to BookStack itself. The security of the server BookStack is hosted on is not instructed below but should be taken into account.

If you’d like to be notified of new potential security concerns you can sign-up to the BookStack security mailing list. For reporting security vulnerabilities, please see the “Security” section of the project readme on GitHub.

*   Initial Security Setup
*   Multi-Factor Authentication
*   Securing Images
*   Attachments
*   User Passwords
*   JavaScript in Page Content
*   Web Crawler Control
*   Secure Cookies
*   Host Iframe Control
*   Iframe Source Control
*   Failed Access Logging
*   Untrusted Server Side Requests
*   Content Security Policy (CSP)
*   MySQL SSL Connection
*   Using BookStack Content Externally

**Initial Security Setup**

1.  Ensure you change the password and email address for the initial admin@admin.com user.
2.  Ensure only the public folder is being served by your webserver. Serving files above this folder opens up a lot of code that does not need to be public. Triple check this if you have installed BookStack within the commonly used /var/www folder.
3.  Ensure the database user you’ve used for BookStack has limited permissions for only accessing the database used for BookStack data.
4.  Check that you’ve set the APP_URL option in your .env file so that system generated URLs cannot be manipulated.
5.  Within BookStack, go through the settings to ensure registration and public access settings are as you expect.
6.  Review the user roles in the settings area.
7.  Read the below to further understand the security for images & attachments.

**Multi-Factor Authentication**

Any user can enable multi-factor authentication (MFA) on their account. Upon login they would then need to use an extra proof of identity to gain access. BookStack currently supports the following mechanisms:

*   TOTP (Time-based One-Time Passwords)
    *   Labelled as “Mobile App” (Google/Microsoft Authenticator etc…).
    *   Uses a SHA1 algorithm internally (Greater algorithms have poor cross-app compatibility).
*   Backup Codes
    *   These are a list of 16 one-time-use codes.
    *   Users will be warned once they have less than 5 codes remaining.

Secrets and values for these options are stored encrypted within the database.

Where required, MFA can be forced upon users via their roles. This can be found via a “Requires Multi-Factor Authentication” checkbox seen when editing a role. If a user does not already have an MFA method configured, they will be forced to set one up upon next login.

**Securing Images**

By default, Images are stored in a way which is publicly accessible which ensures performance while using BookStack. Listed below are a few options for increasing image security.

**Alternative Storage Options**

Review our file upload storage options documentation for image storage options that add addition access or permission control to image requests.

**Complex Urls**

In the settings area of BookStack you can find the option ‘Enable higher security image uploads?’. Enabling this will add a 16 character random string to the name of image files to prevent easy guessing of URLs. This increases security without potential performance concerns.

**Prevent Directory Indexes**

It’s important to ensure you disable ‘directory indexes’ to prevent unknown users from being able to navigate their way through your images. Here’s the configuration for NGINX & Apache if your server allows directory indexes:

**NGINX**

    1
    2
    3
    4
    5
    

    # By default indexes are disabled on Nginx but if you have them enabled
    # add this to your BookStack server block
    location /uploads {
           autoindex off;
    }
    

**Apache**

    1
    2
    3
    4
    5
    

    # Add this to your Apache BookStack virtual host if Indexes are enabled.
    # If .htaccess file are enabled then the below should already be active.
    <Location "/uploads">
        Options -Indexes
    </Location>
    

You can test that indexes are disabled by attempting to navigate to <your_bookstack_url>/uploads/images in the browser after having uploaded at least one image. You should not see a list of files but instead a BookStack “Not Found” page.

**Attachments**

Attachments, if not using Amazon S3, are stored in the storage/uploads directory. By default, unlike images, these are stored behind the application authentication layer so access depends on permissions you have set up at a role level and page level.

If you are using Amazon S3 for file storage then access will depend on your S3 permission settings. Unlike images, BookStack will not automatically attempt to make uploaded attachments publically accessible.

**User Passwords**

User passwords, if not using an alternative authentication method, are stored in the database. These are hashed using the standard Laravel hashing methods which use the Bcrypt hashing algorithm.

**JavaScript in Page Content**

By default, JavaScript tags within page content is escaped when rendered. This can be turned off by setting ALLOW_CONTENT_SCRIPTS=true in your .env file. Note that even if you disable this escaping the WYSIWYG editor may still perform it’s own JavaScript escaping. This option will also alter the CSP rules set by BookStack.

_**This option disables some fundamental cross-site-scripting protections. Only use this option on secure instances, where only very trusted users can edit content**_

**Web Crawler Control**

The rules found in the /robots.txt file are automatically controlled via the “Allow public viewing?” setting. This can be overridden by setting ALLOW_ROBOTS=false or ALLOW_ROBOTS=true in your .env file. If you’d like to customise the rules this can be done via theme overrides.

**Secure Cookies**

BookStack uses cookies to track sessions, remember logins and for XSRF protection. When using HTTPS you may want to ensure that cookies are only sent back to the browser if the connection is over HTTPS. If you have set a https APP_URL option in your .env this will enabled automatically but it can also be forced on by setting SESSION_SECURE_COOKIE=true in your .env file.

**Host Iframe Control**

By default BookStack will only allow itself to be embedded within iframes on the same domain as you’re hosting on. This is done through a CSP: frame-ancestors header. You can add additional trusted hosts by setting a ALLOWED_IFRAME_HOSTS option in your .env file like the example below:

    1
    2
    3
    4
    5
    

    # Adding a single host
    ALLOWED_IFRAME_HOSTS="https://example.com"
    
    # Multiple hosts can be separated with a space
    ALLOWED_IFRAME_HOSTS="https://a.example.com https://b.example.com"
    

Note: when this option is used, all cookies will served with SameSite=None (info) set so that a user session can persist within the iframe.

**Iframe Source Control**

By default BookStack will only allow certain other hosts to be used as src values for embedded iframe/frame content within the application. This is done through a CSP: frame-src header. You can configure the list of trusted sources by setting a ALLOWED_IFRAME_SOURCES option in your .env file like the examples below:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    

    # Adding a single host
    ALLOWED_IFRAME_SOURCES="https://example.com"
    
    # Multiple hosts can be separated with a space
    ALLOWED_IFRAME_SOURCES="https://a.example.com https://b.example.com"
    
    # Allow all sources
    # This opens vulnerability risk and should only be done in secure & trusted environments.
    ALLOWED_IFRAME_SOURCES="*"
    

By default this option is configured as follows:

    1
    

    ALLOWED_IFRAME_SOURCES="https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com"
    

Note: The source of ‘self’ will always be automatically added to this CSP rule. In addition, the host used for the diagrams.net integration (If enabled) will be automatically appended to the lists of hosts.

**Failed Access Logging**

An option is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban. This works with login attempts using the default email & password login mechanism or attempts via LDAP login. Failed attempts are **not logged** for “one-click” social or SAML2 options.

To enable this you simply need to define the LOG_FAILED_LOGIN_MESSAGE option in your .env file like so:

    1
    

    LOG_FAILED_LOGIN_MESSAGE="Failed login for %u"
    

The optional “%u” element of the message will be replaced with the username or email provided in the login attempt when the message is logged. By default messages will be logged via the php error_log function which, in most cases, will log to your webserver error log files.

**Untrusted Server Side Requests**

Some features, such as the PDF exporting, have the option to make http calls to external user-defined locations to do things such as load images or styles. This is disabled by default but can be enabled if desired. This is required for using WKHTMLtoPDF as your PDF export renderer. This should only be enabled in BookStack environments where BookStack users and viewers are fully trusted.

To enable untrusted server side requests, you need to define the ALLOW_UNTRUSTED_SERVER_FETCHING option in your .env file like so:

    1
    

    ALLOW_UNTRUSTED_SERVER_FETCHING=true
    

**Content Security Policy (CSP)**

BookStack serves responses with a CSP header to increase protection again malicious content. This is especially important in a system such as BookStack where users can create a variety of HTML content, especially so if you allow untrusted users to create content in your instance. The CSP rules set by BookStack are as follows:

*   frame-ancestors 'self'
    *   Restricts what websites can embed BookStack pages via iframes.
    *   See the “Host Iframe Control” section above for details on expanding this rule to other hosts.
*   frame-source 'self' https://*.diagrams.net https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com https://embed.diagrams.net
    *   Restricts what sources are allowed to load for frames/iframes.
    *   Can be configured via a ALLOWED_IFRAME_SOURCES .env option.
    *   May be different depending on other configuration set.
*   script-src http: https: 'nonce-abc123' 'strict-dynamic'
    *   Restricts what scripts can be ran on a BookStack-served page.
    *   Will not be set if the ALLOW_CONTENT_SCRIPTS .env option is active.
    *   The nonce value used is randomly generated upon each request. It is automatically applied to any “Custom HTML Head Content” scripts.
*   object-src 'self'
    *   Restricts which embeddable content can be loaded onto a BookStack-served page.
    *   Will not be set if the ALLOW_CONTENT_SCRIPTS .env option is active.
*   base-uri 'self'
    *   Restricts what <base> tags can be added to a BookStack-served page.

If needed you should be able to set additional CSP headers via your webserver. If there’s a clash with an existing BookStack CSP header then browsers will generally favour the most restrictive policy.

**MySQL SSL Connection**

If your BookStack database is not on the same host as your web server, you may want to ensure the connection is encrypted using SSL between these systems. Assuming SSL is configured correctly on your MySQL server, you can enable this by defining the MYSQL_ATTR_SSL_CA option in your .env file like so:

    1
    2
    3
    4
    5
    

    # Path to Certificate Authority (CA) certificate file for your MySQL instance.
    # When this option is used host name identity verification will be performed
    # which checks the hostname, used by the client, against names within the
    # certificate itself (Common Name or Subject Alternative Name).
    MYSQL_ATTR_SSL_CA="/path/to/ca.pem"
    

**Using BookStack Content Externally**

In some scenarios you may use BookStack user-provided content externally (Accessed via the database or API). Such content is not guaranteed to be safe so keep security in mind when dealing with such content. In some cases, the system will apply some filtering to content in an attempt to prevent certain vulnerabilities, but this is not assured to be a bullet-proof defence.

Within its own interfaces, unless disabled, BookStack makes use of Content Security Policy (CSP) rules to heavily negate cross-site scripting vulnerabilities from user content. If displaying user content externally, it’s advised you also use defences such as CSP or other techniques such as disabling of JavaScript entirely.

CVE-2022-40690: Security ·  BookStack

A credential-exposure vulnerability in the support-bundle mechanism in Gradle Enterprise 2022.3 through 2022.3.3 allows remote attackers to access a subset of application data (e.g., cleartext credentials). This is fixed in 2022.3.3.

All advisories**Exposure of S3 access credentials in support bundles**

**Affected product(s)**

*   Gradle Enterprise 2022.3 - 2022.3.2

**Severity**

Moderate

**Published at**

2022-10-19

**Related CVE ID(s)**

*   CVE-2022-41575

**Description**

Gradle Enterprise can be configured to store Build Scan™ data in an Amazon S3 compatible object store. This configuration may include access credentials. Support bundles generated from Gradle Enterprise 2022.3 through to 2022.3.2 expose these credentials in plaintext. The credentials could be used by an attacker to read and write Build Scan data directly to the object store.

Support bundles are a mechanism used by Gradle Enterprise support to obtain log files and other operational telemetry from a Gradle Enterprise installation. They must be generated by an installation administrator with access to the installation host environment, or via the application administration user interface. The bundle files are typically then shared with Gradle Enterprise support and discarded.

Gradle Enterprise installations not using an Amazon S3 compatible object store for build data are unaffected. Installations using the “instance profile” authentication method are also unaffected.

**Mitigation**

As of Gradle Enterprise 2022.3.3, the access credentials are encrypted in support bundles.

Affected installations should consider revoking existing credentials and generating and configuring new credentials.

CVE-2022-41575: Gradle Enterprise - Security Advisories

The new open source specification from Open Compute Project is backed by Google, Nvidia, Microsoft, and AMD.

Some of the top names in the hardware industry have joined forces to create common technologies to enhance security in the cloud.

Google, Nvidia, Microsoft, and AMD partnered to establish Caliptra, an open specification to embed security mechanisms inside chips. The spec, which is open source and free to license, was announced on Tuesday at the Open Compute Project Summit, being held in Santa Clara, Calif. The participating companies are members of the Open Compute Project (OCP), which will maintain the development of the specification along with the Linux Foundation.

The Caliptra project revolves around establishing a root of trust (RoT) — building security layers into silicon so data is encrypted and not exposed as it travels in data centers or the cloud.  

"We need to embed that capability in silicon. At some point in the future, it's not going to be enough to have it on the motherboard, for example in the server as a separate piece of circuitry," said Cliff Grossner, vice president of market intelligence at OCP, during a press briefing.

Caliptra expands the security boundaries of data from the chip level to the cloud. The specification provides common language for chip makers and cloud providers to create technologies around confidential computing, which is gaining attention as a way to protect data while it is in storage, in transit, or being processed in the cloud.

"With the rise of edge computing, the resultant growth in the exposed attack surface also presents a need for stronger physical security solutions," wrote Mark Russinovich, Microsoft CTO for Azure, in a Tuesday blog post about Caliptra.

**Defining Open Source Confidential Computing**

Vulnerabilities like Spectre and Meltdown showed hackers could steal data by attacking hardware. Intel and AMD, whose CPUs dominate the data center and cloud infrastructure, are adding proprietary features to lock down data at the chip level, but Caliptra is being pitched as a viable open source alternative.

The specification defines a reusable silicon block that can be dropped into chips and devices to establish an RoT. The silicon block provides verifiable cryptographic assurances that the chip security configuration is correct. It also provides a mechanism within the chip to ensure that the boot code can be trusted.

"This represents an enhancement over existing solutions today, and we expect that this will meet the enhanced security requirements for edge and confidential computing going forward," OCP's Grossner said.

The specification includes mechanisms to protect data from a range of electromagnetic, side-channel, and other common attacks. But Caliptra does not cover emerging attack vectors like quantum computers, which will provide the means to crack advanced encryption in just seconds.

The Caliptra specification also covers major aspects of attestation, which is more of a chip-level handshake to ensure that only authorized parties get access to data stored in hardware enclaves. The RoT blocks in a chip isolate the data, while providing an effective mechanism to verify the authenticity and integrity of code, firmware, and other security assets.

**Securing the Enterprise Cloud**

The first Caliptra spec, version 0.5, can be prototyped on field-programmable gate arrays before being implemented into final chip designs. The specification document points to the technology being geared for enterprise computing infrastructures rather than home or business PCs.

The tenets of Caliptra, which include authentication, detection, and recovery, tilt heavily toward establishing a silicon RoT for server and edge chips, which are built differently than PC chips.

Microsoft is using attestation based on Trusted Platform Module (TPM) chips as a security mechanism for Windows 10 and 11 operating systems. The company's Pluton security chip, which has a TPM built in and can be used for attestation, has largely been rejected by the wider PC industry.

Microsoft and Google executives didn't say whether or when they would make Caliptra a part of their cloud services. Microsoft last week expanded the use of AMD's SNP-SEV technology for confidential computing in the cloud. Azure also offers virtual machine instances with Intel's proprietary SGX security enclave.

**Expanding the Open Compute Project**

The Open Compute Project was established in 2011 by the likes of Google and Meta (then Facebook), which were buying thousands of servers and looking to standardize on hardware designs in their mega data centers. The goal was to reduce the server build times and cut costs by stripping off unnecessary components.

OCP has since grown into a powerhouse that counts all major infrastructure hardware providers as members — with the exception of Apple and Amazon, which rely on internally designed hardware.

OCP guidelines also include power, cooling, storage, and networking specifications that are now widely adopted. The OCP has also inspired nontech companies, largely in the financial sector, to experiment and develop standardized servers for on-premises data centers.

"We have the industry leaders coming together here within the OCP community, and we want to bring the standardized facility architecture for deployed servers," Grossner said. "Server security will become scalable."

Servers previously largely depended on CPUs, but now include different computing devices such as GPUs to handle applications like artificial intelligence. Standardizing the server security architecture was a top priority for company executives addressing media during the OCP call.

"This ecosystem we all play in — it starts with trust you have ... in your computing. We were on a path to have a number of bifurcated solutions, and that's just not good for anyone," said Mark Papermaster, chief technology officer at AMD, during the call.

Hardware Makers Standardize Server Chip Security With Caliptra

Many enterprises continue to leave cloud storage buckets exposed despite widely available documentation on how to properly secure them.

Cloud storage misconfigurations of the sort that Microsoft disclosed late yesterday continue to be a major contributor to data breaches.

Microsoft Security Response Center said in a post that information shared by prospective clients with the company in recent years potentially may have been compromised via a misconfigured cloud storage endpoint.

SOCRadar, the threat intelligence firm that reported the issue to Microsoft, described discovering the data in an Azure Blob storage bucket that was publicly accessible over the Internet. The data was associated with more than 65,000 companies in 11 countries and included statement-of-work documents, invoices, product orders, project details, signed customer documents, product price lists, personally identifiable information (PII), and potentially intellectual property as well.

Microsoft blamed the issue on an unintentional misconfiguration on an endpoint containing the data, and said SOCRadar "greatly exaggerated the scope of this issue," with some duplicate data that exaggerated the numbers.

**Ongoing Problem**

Storage-bucket misconfigurations by other organizations have resulted in numerous data breaches in recent years. A Trend Micro study last year found storage-related configuration errors to be among the most common cloud security issues that lead to data breaches. The analysis showed, for example, that administrators frequently misconfigure a setting in Amazon's AWS cloud service that allows organizations to block public access to data in their S3 storage buckets. But even with readily available and detailed documentation, administrators often fall short and leave Amazon S3 buckets open and publicly accessible. 

The security vendor found the same problem prevalent in Microsoft Azure storage environments as well. The Azure storage account service that contains Azure Storage objects such as blobs, file shares and tables, had a misconfiguration rate of 60.75%, Trend Micro found.

Unsurprisingly, data exposures resulting from misconfigured cloud storage buckets remain commonplace. Many of the publicly known instances have involved data in insecure or poorly configured AWS S3 storage buckets. One recent example is Skyhigh Security's discovery of some 3TB worth of airport data — more than 1.5 million files — stored in a publicly accessible S3 bucket. The compromised data included PII and sensitive employee and company data associated with at least four airports in Peru and Colombia.

According to third-party risk management vendor UpGuard, there have been thousands of S3-related breaches tied to misconfigured S3 settings in recent years. Incidents involving Azure Blob misconfigurations — though fewer in number — have resulted in major compromises as well. Research that CyberArk conducted last year uncovered millions of files stored online in Azure Blob storage without any access restrictions at all, meaning anyone looking for the data could access it. Many of the files that CyberArk found include personal identifiable information, payment card information, financial information, and other sensitive data.

**So Much Data**

Meantime, the circumstances surrounding Microsoft's newly disclosed Azure Blob misconfiguration are not clear, says Claude Mandy, chief evangelist for data security at Symmetry Systems. "A more technical post-incident analysis would be beneficial for the entire industry to take proactive steps to avoid similar issues," he says.

The information released thus far on the Microsoft incident suggests that either the Azure storage container or the blobs containing the data was configured to allow anonymous public read access to the data — a setting that is not allowed by default. "This configuration drift is unfortunately common. For example, it may result from users with excessive privileges attempting to share specific data with external parties without having the expertise to configure external access securely," Mandy says.

In addition, it appears that the specific blob storage may have also been used to backup data from other blob storages, resulting in further unattended sharing of data, he adds.

The incident underscores the challenges organizations face from the sheer scale of data being generated and collected these days, and the way it is shared and managed. "This can include simple changes such as people joining and leaving organizations, or the need to use or share data with different parties," Mandy says. "The impact of the continual change at the most granular data object level can result in unattended and significant consequences but is challenging to manually monitor at scale."

Andrew Hay, chief operating officer at Lares Consulting, believes the recent incident was likely the result of an oversight by a developer or administrator. "Like AWS S3, users must go out of their way to allow public access to the Azure Storage Blob," Hay says. "Public read-access to blob data is an optional setting that can be enabled on a container."

While public read-access can be convenient for sharing data it also entails security risks, he says. Azure allows administrators to disallow public access to data in a storage account, he notes. Any subsequent request for access to blob data then would need to be authorized and anonymous requests would fail, Hay explains.

Microsoft had not responded to a request for additional comment as of this posting.

Microsoft Data-Exposure Incident Highlights Risk of Cloud Storage Misconfiguration

Some versions of Sonos One (1st and 2nd generation) allow partial or full memory access via attacker controlled hardware that can be attached to the Mini-PCI Express slot on the motherboard that hosts the WiFi card on the device.

**Introduction**

Sonos is a wireless home sound system, allowing multiroom music playing.

In 2020, we discovered a DMA (Direct Memory Access) vulnerability on Sonos Play speakers (1st gen and 2nd gen “One”). We worked with Sonos in order to address the security vulnerability and were credited on the Security Researcher Recognition page.

> We are aware that Synacktiv publicly disclosed the vulnerability on the Sonos One the 03/2021. After discussion with Sonos, they were not aware of this publication. We preferred to follow a responsible disclosure process.

**Vulnerability****Attack on Sonos Play 1 (First gen)**

We performed our first tests on the Sonos Play 1 speaker. Multiple papers are talking about some security issues on the web interface of Sonos.

However, we decided to take a look at the hardware part of the speakers to see if debugging interfaces were available.

After opening the Play 1 speaker, something immediately focused our attention: a _Mini PCI-Express (mPCIE)_ Wireless card.

We decided to perform a DMA Attack on the Sonos speaker using PCILeech and the PLX USB3380 development board in order to read the memory content.

_DMA Attack on Sonos Play Speaker_

A web interface was available on TCP port 1400, it can be used to get some information about the system, and outputs some command outputs (from the _brctl_ command) at the _status/showstp_ page.

We searched for strings in the pcileech dump matching _brctl_, and found _/usr/sbin/brctl showstp br0_. After some tests, we confirmed that this string is used by the _status/showstp_ page.

We came up with the following PCILeech signature that will replace the _brctl_ command with one of our choice:

*,2f7573722f7362696e2f627263746c2073686f7773747020627230,0,-,r0,2f62696e2f62757379626f7820756e616d65202d61000000000000

*   * means to search into each memory pages.
*   2f7573722f7362696e2f627263746c2073686f7773747020627230 is the /usr/sbin/brctl showstp br0 string hex-encoded.
*   0 and - means that we don’t have to look for another chunk.
*   r0 is the relative offset where the patch should be applied.
*   2f62696e2f62757379626f7820756e616d65202d61000000000000 is the patch that will replace the brctl command with the command of our choice (here, /bin/busybox uname -a).

With the signature file at hand, we just needed to run the following command pcileech patch -sig sonos_uname, and browse the _status/showstp_ page to gain arbitrary code execution.

_showstp page executing the command of our choice_

After browsing the filesystem content, we found a way to enable a debugging feature that will execute a telnetd process (as root) at startup. We then gained unrestricted access to the Sonos Play 1 first generation speaker system.

**Attack on Sonos Play One (Second gen)**

After our research on Sonos Play 1, Sonos released a new speaker: the Sonos Play One.

It features Amazon Alexa integration (so a microphone), and a brand-new ARM Architecture.

We bought it, and immediately opened it: the miniPCIe card was still here.

We ran the same attack that the first generation speaker, but it seems that additional protections were applied.

_DMA Attack on the Sonos One SL_

PCILeech isn’t able to dump the memory content. We tried multiple time, and we managed to dump only a few kilobyte of memory.

We analyzed the memory content, and discovered that it was a _U-Boot_ memory dump. We found some logs checking for the vendor ID of the MiniPCIe card. Maybe a protection in order to not change the PCIe card with another vendor, maybe a security feature.

**Spoofing the PCI Vendor ID**

When you plug a PCILeech patched PLX USB3380 card on the target computer, the USB3380 is recognized as a Memory Card Reader (PCI ID: 16BC14E4).

We looked at how the PCILeech PLX USB3380 firmware is made, and we found the following content in the usb3380_flash/linux/pcileech_flash.c file:

    static const unsigned char g_firmware_pcileech[] = {
       0x5a, 0x00, 0x2a, 0x00, 0x23, 0x10, 0x49, 0x38, 0x00, 0x00, 0x00, 0x00, 0xe4, 0x14, 0xbc, 0x16,
       0xc8, 0x10, 0x02, 0x06, 0x04, 0x00, 0xd0, 0x10, 0x84, 0x06, 0x04, 0x00, 0xd8, 0x10, 0x86, 0x06,
       0x04, 0x00, 0xe0, 0x10, 0x88, 0x06, 0x04, 0x00, 0x21, 0x10, 0xd1, 0x18, 0x01, 0x90, 0x00, 0x00 };

If you search for the PCI Vendor ID _16BC14E4_, you can find it in the firmware code _0xe4, 0x14, 0xbc, 0x16_.

We modified some parts of the PCILeech flash program to flash the USB3380 card with the vendor ID of the Wireless card.

We plugged our patch USB3380 card on another Linux computer, and confirmed that the USB33800 card as the same vendor ID as the Sonos PCIe Wi-Fi card.

We tested the pcileech dump command against the Sonos One speaker, and we were now able to dump the memory content. We then performed the same attack as the first generation speakers, and gained root access on the device.

**Research Conclusion**

The Play One system was hardened against some attacks: the root filesystem is mounted as read-only, all other filesystems are mounted with the _nodev_ and _noexec_ options.

If you tried to perform a remount of a filesystem (for example remount / as read-write), the kernel will enforce it as \* nodev\* and _noexec_.

We didn’t have this behavior on the Sonos 1 (first gen) speaker.

Because our attack was performed on memory, we did not alter the filesystem content. We even managed to drop a _meterpreter shell_ by patching the memory.

Fixing the vulnerabilities may be difficult because hardware-specific protections must be enabled ( like System Memory Management Unit - SMMU for ARM units).

We would like to thank the Sonos Team for the excellent work they have done handling this vulnerability.

**Timeline (dd/mm/yyyy)**

*   03/01/2020: Initial contact with security@sonos.com
*   03/01/2020: Advisory sent to Sonos
*   07/01/2020: Reply from Sonos that they are currently investigating the issue
*   28/01/2020: Sonos informs us that they are close to a solution for the ARM architecture (NXP iMX6)
*   11/02/2020: Video meeting with the Sonos Security Team
*   19/02/2020: CVE-2020-9285 assigned by MITRE
*   20/02/2020: Sonos informs us that they have a working solution, but need more testing
*   Coronavirus Crisis
*   05/06/2020: Sonos send us a Sonos One SL for testing
*   05/08/2020: Exploit reproduced with Sonos One SL
*   06/08/2020: Sonos provide us custom tool and a custom firmware that should fix the security vulnerability
*   11/08/2020: The Sonos patch is working. However, we were able to dump memory during U-Boot initialization
*   12/08/2020: Sonos share technical patch details with us
*   14/08/2020: Sonos send us the source of the Kernel patch that fix the issue
*   19/08/2020: Sonos send us a new firmware fixing the U-Boot issue with the kernel patch
*   25/08/2020: We confirm that all the issues have been resolved
*   21/12/2020: Sonos inform us that the patch has a significant performance impact and can’t be incorporated into products that use the NXP iMX6 SoC
*   04/02/2021: Sonos ask us about disclosure plans
*   23/02/2021: Expected publication date sent to Sonos
*   29/07/2021: Article sent to Sonos for validation
*   02/08/2021: Sonos authorizes the publication of the article
*   09/08/2021: Disclosure by TNP IT Security

**Credits**

*   Nicolas Chatelain : nicolas.chatelain -at- tnpconsultants.com

CVE-2020-9285: [EN] Responsible Disclosure - Gaining root access on Sonos Play (1st gen and 2nd gen 'One') Speakers

On October 10, 2022, there were 576,562 LinkedIn accounts that listed their current employer as Apple Inc. The next day, half of those profiles no longer existed. A similarly dramatic drop in the number of LinkedIn profiles claiming employment at Amazon comes as LinkedIn is struggling to combat a significant uptick in the creation of fake employee accounts that pair AI-generated profile photos with text lifted from legitimate users.

On October 10, 2022, there were 576,562 **LinkedIn** accounts that listed their current employer as **Apple Inc.** The next day, half of those profiles no longer existed. A similarly dramatic drop in the number of LinkedIn profiles claiming employment at **Amazon** comes as LinkedIn is struggling to combat a significant uptick in the creation of fake employee accounts that pair AI-generated profile photos with text lifted from legitimate users.

Jay Pinho is a developer who is working on a product that tracks company data, including hiring. Pinho has been using LinkedIn to monitor daily employee headcounts at several dozen large organizations, and last week he noticed that two of them had far fewer people claiming to work for them than they did just 24 hours previously.

Pinho’s screenshot below shows the daily count of employees as displayed on Amazon’s LinkedIn homepage. Pinho said his scraper shows that the number of LinkedIn profiles claiming current roles at Amazon fell from roughly 1.25 million to 838,601 in just one day, a 33 percent drop:

The number of LinkedIn profiles claiming current positions at Amazon fell 33 percent overnight. Image: twitter.com/jaypinho

As stated above, the number of LinkedIn profiles that claimed to work at Apple fell by approximately 50 percent on Oct. 10, according to Pinho’s analysis:

Image: twitter.com/jaypinho

Neither Amazon or Apple responded to requests for comment. LinkedIn declined to answer questions about the account purges, saying only that the company is constantly working to keep the platform free of fake accounts. In June, LinkedIn acknowledged it was seeing a rise in fraudulent activity happening on the platform.

KrebsOnSecurity hired Menlo Park, Calif.-based **SignalHire** to check Pinho’s numbers. SignalHire keeps track of active and former profiles on LinkedIn, and during the Oct 9-11 timeframe SignalHire said it saw somewhat smaller but still unprecedented drops in active profiles tied to Amazon and Apple.

“The drop in the percentage of 7-10 percent \[of all profiles\], as it happened \[during\] this time, is not something that happened before,” SignalHire’s **Anastacia Brown** told KrebsOnSecurity.

Brown said the normal daily variation in profile numbers for these companies is plus or minus one percent.

“That’s definitely the first huge drop that happened throughout the time we’ve collected the profiles,” she said.

In late September 2022, KrebsOnSecurity warned about the proliferation of fake LinkedIn profiles for Chief Information Security Officer (CISO) roles at some of the world’s largest corporations. A follow-up story on Oct. 5 showed how the phony profile problem has affected virtually all executive roles at corporations, and how these fake profiles are creating an identity crisis for the businesses networking site and the companies that rely on it to hire and screen prospective employees.

A day after that second story ran, KrebsOnSecurity heard from a recruiter who noticed the number of LinkedIn profiles that claimed virtually any role in network security had dropped seven percent overnight. LinkedIn declined to comment about that earlier account purge, saying only that, “We’re constantly working at taking down fake accounts.”

A “swarm” of LinkedIn AI-generated bot accounts flagged by a LinkedIn group administrator recently.

It’s unclear whether LinkedIn is responsible for this latest account purge, or if individually affected companies are starting to take action on their own. The timing, however, argues for the former, as the account purges for Apple and Amazon employees tracked by Pinho appeared to happen within the same 24 hour period.

It’s also unclear who or what is behind the recent proliferation of fake executive profiles on LinkedIn. Cybersecurity firm **Mandiant** (recently acquired by **Google**) told Bloomberg that hackers working for the North Korean government have been copying resumes and profiles from leading job listing platforms LinkedIn and **Indeed**, as part of an elaborate scheme to land jobs at cryptocurrency firms.

On this point, Pinho said he noticed an account purge in early September that targeted fake profiles tied to jobs at cryptocurrency exchange **Binance**. Up until Sept. 3, there were 7,846 profiles claiming current executive roles at Binance. The next day, that number stood at 6,102, a 23 percent drop (by some accounts that 6,102 head count is still wildly inflated).

Fake profiles also may be tied to so-called “pig butchering” scams, wherein people are lured by flirtatious strangers online into investing in cryptocurrency trading platforms that eventually seize any funds when victims try to cash out.

In addition, identity thieves have been known to masquerade on LinkedIn as job recruiters, collecting personal and financial information from people who fall for employment scams.

**Nicholas Weaver**, a researcher for the International Computer Science Institute at **University of California, Berkeley**, suggested another explanation for the recent glut of phony LinkedIn profiles: Someone may be setting up a mass network of accounts in order to more fully scrape profile information from the entire platform.

“Even with just a standard LinkedIn account, there’s a pretty good amount of profile information just in the default two-hop networks,” Weaver said. “We don’t know the purpose of these bots, but we know creating bots isn’t free and creating hundreds of thousands of bots would require a lot of resources.”

In response to last week’s story about the explosion of phony accounts on LinkedIn, the company said it was exploring new ways to protect members, such as expanding email domain verification. Under such a scheme, LinkedIn users would be able to publicly attest that their profile is accurate by verifying that they can respond to email at the domain associated with their current employer.

LinkedIn claims that its security systems detect and block approximately 96 percent of fake accounts. And despite the recent purges, LinkedIn may be telling the truth, Weaver said.

“There’s no way you can test for that,” he said. “Because technically, it may be that there were actually 100 million bots trying to sign up at LinkedIn as employees at Amazon.”

Weaver said the apparent mass account purge at LinkedIn underscores the size of the bot problem, and could present a “real and material change” for LinkedIn.

“It may mean the statistics they’ve been reporting about usage and active accounts are off by quite a bit,” Weaver said.

Battle with Bots Prompts Mass Purge of Amazon, Apple Employee Accounts on LinkedIn

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

Just in time for Halloween, come up with a cybersecurity-themed caption for the cartoon above. If it's Dark Reading editors' favorite, you'll win a $25 Amazon gift card. Here are four convenient ways to submit your ideas before the contest closes on Wednesday, Nov. 9, 2022:

*   Email _\[email protected\]_ with the subject line "Dark Reading October Toon."
*   Via social media: Twitter, Facebook, and LinkedIn. (If you win, we'll respond to you on the same platform, requesting your email address_._)

**Last Month's Winner**

A hearty congratulations goes to Twitter member @\_interroBANG\_ for coming up with the winning caption for September's "Shiver Me Timbers" cartoon contest. Your email treasure chest will soon contain a $25 Amazon gift card.

    

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Tag

#amazon