Monzo, a mobile-only bank operating in the UK, admitted today to storing payment card PINs inside internal logs. From a report: The company is now notifying all impacted customers and urging users to change card PINs the next time they use a cash machine. Monzo described the issue as a "bug" that occurred when Monzo customers used two specific features of their Monzo mobile apps -- namely the feature that reminds users of their card number and the feature for canceling standing orders. When Monzo customers used one of these two features, they'd be asked to enter their account PIN, for authorization purposes, but unbeknowst to them, the PIN would also be logged inside Monzo's internal logs. Monzo said these logs were encrypted and that only a few employees had access to the data stored inside. The company said it discovered the bug on Friday, August 2, and spent all weekend removing PIN numbers from its internal logs.

Slashdot reader Artem S. Tashkinov writes: Mathy Vanhoef and Eyal Ronen have recently disclosed two new additional bugs impacting WPA3. The security researched duo found the new bugs in the security recommendations the WiFi Alliance created for equipment vendors in order to mitigate the initial Dragonblood attacks [found by the same two security researchers]. "Just like the original Dragonblood vulnerabilities from April, these two new ones allow attackers to leak information from WPA3 cryptographic operations and brute-force a WiFi network's password," reports ZDNet.
More from ZDNet: "[The] Wi-Fi standard is now being updated with proper defenses, which might lead to WPA3.1," Vanhoef said. "Although this update is not backwards-compatible with current deployments of WPA3, it does prevent most of our attacks," the researchers said.

But besides just disclosing the two new Dragonblood vulnerabilities, the two researchers also took the chance to criticize the WiFi Alliance again for its closed standards development process that doesn't allow for the open-source community to contribute and prevent big vulnerabilities from making it into the standard in the first place.

"This demonstrates that implementing Dragonfly and WPA3 without side-channel leaks is surprisingly hard," the researchers said. "It also, once again, shows that privately creating security recommendations and standards is at best irresponsible and at worst inept."
While these type of feedback might be ignored when coming from other researchers, it means more when it comes from Vanhoef. The Belgian researchers is the one who discovered the KRACK attack that broke the WPA2 WiFi authentication standard and forced the WiFi Alliance to develop the WPA3 standard, which it launched in June 2018.

The Google Project Zero team said that around 95.8% of the security bugs they find in other software and report to their respective vendors get fixed before the 90-day deadline for a public disclosure expires. From a report: That's quite the batting average for one of world's most infamous cybersecurity programs. In a statistic shared on Wednesday, Google's elite security team said that during its whole history -- from July 17, 2014, when Project Zero was created and until July 30, this week -- its researchers found and reported a total of 1,585 vulnerabilities to a wide range of hardware and software vendors. Of these, Google said that vendors failed to deliver a patch before the final deadline expired only for 66 reports. As a result, its researchers were forced to make vulnerability technical details public before a fix was made available to users.

Google researchers have shared details of five flaws in Apple's iMessage software that could make its devices vulnerable to attack. The BBC reports: In one case, the researchers said the vulnerability was so severe that the only way to rescue a targeted iPhone would be to delete all the data off it. Another example, they said, could be used to copy files off a device without requiring the owner to do anything to aid the hack. Apple released fixes last week. But the researchers said they had also flagged a sixth problem to Apple, which had not been rectified in the update to its mobile operating system.

Apple's own notes about iOS 12.4 indicate that the unfixed flaw could give hackers a means to crash an app or execute commands of their own on recent iPhones, iPads and iPod Touches if they were able to discover it. Apple has not commented on this specific issue, but has urged users to install the new version of iOS, which addresses Google's other discoveries as well as a further range of glitches and threats. One of the two Google researchers involved - Natalie Silvanovich - intends to share more details of her findings at a presentation at the Black Hat conference in Las Vegas next month.

Truecaller, a service that helps users screen robocalls, has rolled out an update to its app in India, its largest market, after a previous software release covertly signed up an unspecified number of users to its payments service. From a report: A number of users in India began to complain late Monday that Truecaller, which has amassed over 100 million daily users in the country, had registered them to its payments service without their consent. In a statement to TechCrunch, Truecaller acknowledged the error and said a bug in the previous software update caused the issue. The bug led the app to quietly send a text message to a bank to verify their account -- which is part of the procedure to sign up to the payments service.

An anonymous reader quotes Vice: In May, Microsoft released a patch for a bug in several versions of Windows that is so bad that the company felt it even had to release a fix for Windows XP, an operating system that (has been unsupported) for five years. That vulnerability is known as BlueKeep, and it has kept a lot of security researchers up at night. They are worried that someone could write an exploit for it and make a worm that could wreak havoc the way WannaCry or NotPetya -- two viruses that spread almost uncontrollably all over the world locking thousands of computers -- did.... Researchers were so worried about this vulnerability that for months, no one has published the code for a proof-of-concept exploit. In other words, no one wanted to be the guy to even prove that this type of malware was even possible to write.

Until now.

On Tuesday, Immunity, a long time US government contractor, announced that it had developed an exploit for BlueKeep and included it into its penetration testing toolkit Canvas, which is available only to paying subscribers. Canvas customers, can now exploit this bug using Immunity's own code.
ZDNet notes that Canvas licenses "cost between thousands and tens of thousands of US dollars," but also adds that "hackers have been known to pirate or legitimately buy penetration testing tools."

An anonymous reader quotes a report from The Register: Some models of Airbus A350 airliners still need to be hard rebooted after exactly 149 hours, despite warnings from the EU Aviation Safety Agency (EASA) first issued two years ago. In a mandatory airworthiness directive (AD) reissued earlier this week, EASA urged operators to turn their A350s off and on again to prevent "partial or total loss of some avionics systems or functions." The revised AD, effective from tomorrow (26 July), exempts only those new A350-941s which have had modified software pre-loaded on the production line. For all other A350-941s, operators need to completely power the airliner down before it reaches 149 hours of continuous power-on time.

Concerningly, the original 2017 AD was brought about by "in-service events where a loss of communication occurred between some avionics systems and avionics network" (sic). The impact of the failures ranged from "redundancy loss" to "complete loss on a specific function hosted on common remote data concentrator and core processing input/output modules." In layman's English, this means that prior to 2017, at least some A350s flying passengers were suffering unexplained failures of potentially flight-critical digital systems.

New submitter Grindop53 shares a report: Widespread reports of a "critical security issue" that supposedly impacted users of VLC media player have been debunked as "completely bogus" by developers. Earlier this week, German computer emergency response team CERT-Bund -- part of the Federal Office for Information Security (BSI) -- pushed out an advisory warning network administrators and other users of a high-impact vulnerability in VLC. It seems that this advisory can be traced back to a ticket that was opened on VLC owner VideoLAN's public bug tracker more than four weeks ago. The alleged heap-based buffer overflow flaw was disclosed by a user named "topsec(zhangwy)," who stated that a malicious .mp4 file could be leveraged by an attacker to take control of VLC media player users' devices. The issue was flagged as high-risk on the CERT-Bund site, and the vulnerability was assigned a CVE entry (CVE-2019-13615).

However, according to VideoLAN president Jean-Baptiste Kempf, the exploit does not work on the latest VLC build. In fact, any potential issues relating to the vulnerability were patched more than a year ago. "There is no security issue in VLC," Kempf told The Daily Swig in a phone conversation this morning. "There is a security issue in a third-party library, and a fix was pushed [out] 18 months ago." When asked how or why this oversight generated so much attention, Kempf noted that the reporter of the supposed vulnerability did not approach VideoLAN through its security reporting email address. "The guy never contacted us," said Kempf, who remains a lead developer at the VLC project. "This is why you don't report security issues on a public bug tracker." Kempf and his team were unable to replicate the issue in the latest version of VLC, leading many to believe that the bug reporter was working on a computer running an outdated version of Ubuntu. "If you report a security issue, at least update your Linux distribution," Kempf said.

A design flaw in Facebook's Messenger Kids app allowed children to enter group chats with unapproved strangers. "For the past week, Facebook has been quietly closing down those group chats and alerting users, but has not made any public statements disclosing the issue," reports The Verge.

The alert reads as follows: "Hi [PARENT],
We found a technical error that allowed [CHILD]'s friend [FRIEND] to create a group chat with [CHILD] and one or more of [FRIEND]'s parent-approved friends. We want you to know that we've turned off this group chat and are making sure that group chats like this won't be allowed in the future. If you have questions about Messenger Kids and online safety, please visit our Help Center and Messenger Kids parental controls. We'd also appreciate your feedback." From the report: The bug arose from the way Messenger Kids' unique permissions were applied in group chats. In a standard one-on-one chat, children can only initiate conversations with users who have been approved by the child's parents. But those permissions became more complex when applied to a group chat because of the multiple users involved. Whoever launched the group could invite any user who was authorized to chat with them, even if that user wasn't authorized to chat with the other children in the group. As a result, thousands of children were left in chats with unauthorized users, a violation of the core promise of Messenger Kids. It's unclear how long the bug was present in the app, which launched with group features in December 2017.

"Everyone knows security needs to be baked into the development lifecycle, but that doesn't mean it is," writes ZDNet, reporting on a new survey they say showed that "long-standing friction between security and development teams remain."

The results came from GitLab's "2019 Global Developer Report: DevSecOps" survey of over 4,000 software professionals. Nearly half of security pros surveyed, 49%, said they struggle to get developers to make remediation of vulnerabilities a priority. Worse still, 68% of security professionals feel fewer than half of developers can spot security vulnerabilities later in the life cycle. Roughly half of security professionals said they most often found bugs after code is merged in a test environment.

At the same time, nearly 70% of developers said that while they are expected to write secure code, they get little guidance or help. One disgruntled programmer said, "It's a mess, no standardization, most of my work has never had a security scan." Another problem is it seems many companies don't take security seriously enough. Nearly 44% of those surveyed reported that they're not judged on their security vulnerabilities.
ZDNet also cites Linus Torvalds' remarks on the Linux kernel mailing list in 2017, complaining about how security people celebrate when code is hardened against an invalid access. "[F]rom a developer standpoint, things really are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported, and debugged, and fixed, so that the bug actually gets corrected. So from a developer standpoint, the end point of hardening is just the starting point, and when you think you're done, we're really only getting started."

Torvalds then pointed out that the user community also has a third set of entirely different expectations, adding that "the number one rule of kernel development is that 'we don't break users'. Because without users, your program is pointless, and all the development work you've done over decades is pointless... and security is pointless too, in the end." Juggling the interest of users and developers, Torvalds suggests security people should adopt "do no harm" as their mantra, and "when adding hardening features, the first step should *ALWAYS* be 'just report it'. Not killing things, not even stopping the access. Report it. Nothing else."

ZDNet: Slack published more details about a password reset operation that ZDNet reported earlier today. According to a statement the company published on its website, the password reset operation is related to the company's 2015 security breach. In March 2015, Slack said hackers gained access to some Slack infrastructure, including databases storing user credentials. Hackers stole hashed passwords, but they also planted code on the company's site to capture plaintext passwords that users entered when logging in. At the time, Slack reset passwords for users who it believed were impacted, and also added support for two-factor authentication for all accounts. But as ZDNet reported earlier today, the company recently received a batch of Slack users credentials, which prompted the company to start an investigation into its source and prepare a password reset procedure. "We immediately confirmed that a portion of the email addresses and password combinations were valid, reset those passwords, and explained our actions to the affected users," Slack said. In a message on its website, Slack said this batch of credentials came via its bug bounty program. The company said it initially believed the data came from users who had their PCs infected with malware, or users who reused passwords across different services.

We're reviving an old Slashdot tradition -- the review. Whenever there's something especially geeky -- or relevant to our present moment -- we'll share some thoughts. And I'd like to start with Jonathan Coulton's amazing 2017 album Solid State, and its trippy accompanying graphic novel adaptation by Matt Fraction. I even tracked down Jonathan Coulton on Friday for his thoughts on how it applies to our current moment in internet time...

"When I started work on Solid State, the only thing I could really think of that I wanted to say was something like, 'The internet sucks now'," Coulton said in 2017 in an epilogue to the graphic novel. "It's a little off-brand for me, so it was a scary place to start..."

So what does he think today? And what did we think of his album...?

This week Intel announced two new patches, according to Tom's Hardware: The flaw in the processor diagnostic tool (CVE-2019-11133) is rated 8.2 out 10 on the CVSS 3.0 scale, making it a high-severity vulnerability. The flaw [found by security researcher Jesse Michael from Eclypsium] "may allow an authenticated user to potentially enable escalation of privilege, information disclosure or denial of service via local access," according to Intel's latest security advisory. Versions of the tool that are older than 4.1.2.24 are affected.

The second vulnerability, found by Intel's internal team, is a medium-severity vulnerability in Intel's SSD DC S4500/S4600 series sold to data center customers. The flaw found in the SSD firmware versions older than SCV10150 obtained a 5.3 score on the CVSS 3.0 scale, so it was labeled medium-severity. The bug may allow an unprivileged user to enable privilege escalation via physical access.

As one of the flaws was uncovered by Intel itself and for the other the Eclypsium research coordinated with Intel for its disclosure, Intel was able to have ready the patches in time for the public announcement.

Apple has disabled the Apple Watch Walkie Talkie app due to an unspecified vulnerability that could allow a person to listen to another customer's iPhone without consent. From a report: Apple has apologized for the bug and for the inconvenience of being unable to use the feature while a fix is made. The Walkie Talkie app on Apple Watch allows two users who have accepted an invite from each other to receive audio chats via a 'push to talk' interface reminiscent of the PTT buttons on older cell phones.

"Windows 10 continues to be a danger zone," writes Forbes senior contributor Gordon Kelly: Not only have problems been piling up in recent weeks, Microsoft has also been worryingly deceptive about the operation of key services. And now the company has warned millions about another problem. Spotted by the always excellent Windows Latest, Microsoft has told tens of millions of Windows 10 users that the latest KB4501375 update may break the platform's Remote Access Connection Manager (RASMAN). And this can have serious repercussions.

The big one is VPNs. RASMAN handles how Windows 10 connects to the internet and it is a core background task for VPN services to function normally. Given the astonishing growth in VPN usage for everything from online privacy and important work tasks to unlocking Netflix and YouTube libraries, this has the potential to impact heavily on how you use your computer. Interestingly, in detailing the issue Microsoft states that it only affects Windows 10 1903 - the latest version of the platform.

The problem is Windows 10 1903 accounts for a conservative total of at least 50M users.
Microsoft estimates they'll have a solution available "in late July," adding that the issue only occurs "when a VPN profile is configured as an Always On VPN (AOVPN) connection with or without device tunnel. This does not affect manual only VPN profiles or connections." That support page also offers a work-around which involves configuring the default telemetry settings in either the group policy settings or with a registry value.

UPDATE (7/7/2019): ZDNet is strongly criticizing Forbes' article, arguing that the issue affects only a small number of Windows users, "when the diagnostic data level setting is manually configured to the non-default setting of 0." For those who don't understand how unusual that configuration is, note that it applies only to Windows 10 Enterprise and that it can be set only using Group Policy on corporate networks or by manually editing the registry. You can't accidentally enable this setting. And you can't deliberately set it on a system running Windows 10 Home or Pro, because it is for Enterprise edition only.

An anonymous reader writes: "The Tor Project is preparing a fix for a bug that has been abused for the past years to launch DDoS attacks against dark web (.onion) websites," reports ZDNet. "Barring any unforeseen problems, the fix is scheduled for the upcoming Tor protocol 0.4.2 release." The bug has been known to Tor developers for years, and has been used to launch Slow Loris-like attacks on the web servers that run the Tor service supporting an .onion site. It works by opening many connections to the server and maxing out the CPU. Since Tor connections are CPU intensive because of the cryptography involved to support the privacy and anonymity of the network, even a a few hundreds connections are enough to bring down dark web portals. A tool to exploit the bug and to automate DDoS attacks has been around for four years, and has been used by hackers to extort dark web marketplaces all spring. At least two markets selling illegal products have shut down after refusing to pay attackers. To get the bug fixed, members of a dark web forum banded together and donated to the Tor Project to sponsor the bug's patch.

Microsoft's original co-founder Paul Allen was honored posthumously with a lifetime achievement award for philanthropy this week at the Forbes Philanthropy summit.

Bill Gates remembers Allen as "one of the most intellectually curious people I've ever known," adding "I wish more people understood just how wide-ranging his giving was," and shared his remembrances at the ceremony: Later in life, Paul gave to a huge spectrum of issues that seem unrelated at first glance. He wanted to prevent elephant poaching, improve ocean health, and promote smart cities. He funded new housing for the homeless and arts education in the Puget Sound region. In 2014 alone, he supported research into the polio virus and efforts to contain the Ebola outbreak in West Africa -- all while standing up an amazing new institute for studying artificial intelligence.

If you knew him, the logic in Paul's portfolio is easy to see. He gave to the things that he was most interested in, and to the places where he thought he could have the most impact. Even though Paul cared about a lot of different things, he was deeply passionate about each of them.
There's a picture of a young Bill Gates in the eighth grade watching Paul Allen on a teletype terminal. "The only way for us to get computer time was by exploiting a bug in the system."

"We eventually got busted, but that led to our first official partnership between Paul and me: we worked out a deal with the company to use computers for free if we would identify problems. We spent just about all our free time messing around with any machine we could get our hands on." One day -- when Paul and I were both in Boston -- he insisted that I rush over to a nearby newsstand with him. He wanted to show me the cover of the January 1975 issue of Popular Electronics. It featured a new computer called the Altair 8800, which ran on a powerful new chip. I remember him holding up the cover and saying, "This is happening without us!"

Paul always wanted to push the boundaries of science. He did it when we were testing the limits of what a chip could do at Microsoft, and he continues to do it today -- even after he's gone -- through the work of the Allen Institute. When I first heard he was creating an organization to study brain science, I thought, "Of course...."

I wish Paul had gotten to see all of the good his generosity will do. He was one of the most thoughtful, brilliant, and curious people I've ever met....

I will miss him tremendously.

Google on Thursday confirmed that a bug in its Nest security cameras could have allowed users to be spied on. The Daily Dot reports: The issue was first raised by a user on Facebook who recently sold his Nest Cam Indoor yet was still able to access its feed. The problem involves Wink, an app that lets people manage multiple smart devices regardless of their developer. The Facebook user noted that despite carrying out a factory reset on his Nest camera before selling it, his Wink account remained connected to the device, allowing him to view snapshots of the buyer's live feed.

Wirecutter tested the vulnerability on its own Nest Cam by linking it to a Wink account and then performing a factory reset. The publication also found it was receiving "a series of still images snapped every several seconds" via its Wink account. "In simpler terms: If you buy and set up a used Nest indoor camera that has been paired with a Wink hub, the previous owner may have unfettered access to images from that camera," Wirecutter says. "And we currently don't know of any cure for this problem." Google responded to the report and said it has fixed the problem. "We were recently made aware of an issue affecting some Nest cameras connected to third-party partner services via Works with Nest," a spokesperson told Wirecutter. "We've since rolled out a fix for this issue that will update automatically, so if you own a Nest camera, there's no need to take any action."

An anonymous reader writes: A recent Firefox zero-day that has made headlines across the tech news world this week was actually used in attacks against Coinbase employees, and not the company's users. Furthermore, the attacks used not one, but two Firefox zero-days, according to Philip Martin, a member of the Coinbase security team, which reported the attacks to Mozilla. One was an RCE reported by a Google Project Zero security researcher to Mozilla in April, and the second was a sandbox escape that was spotted in the wild by the Coinbase team together with the RCE, on Monday.

The question here is how an attacker managed to get hold of the details for the RCE vulnerability and use it for his attacks after the vulnerability was privately reported to Mozilla by Google. The attacker could have found the Firefox RCE on his own, he could have bribed a Mozilla/Google insider, hacked a Mozilla/Google employee and viewed details about the RCE, or hacked Mozilla's bug tracker, like another attacker did in 2015.

Artem S. Tashkinov writes: The Register reports that it is possible to crash network-facing Linux servers, PCs, smartphones and tablets, and gadgets, or slow down their network connections, by sending them a series of maliciously crafted packets. It is also possible to hamper FreeBSD machines with the same attack. Patches and mitigations are available, and can be applied by hand if needed, or you can wait for a security fix to be pushed or offered to your at-risk device. A key workaround is to set /proc/sys/net/ipv4/tcp_sack to 0. At the heart of the drama is a programming flaw dubbed SACK Panic aka CVE-2019-11477: this bug can be exploited to remotely crash systems powered by Linux kernel version 2.6.29 or higher, which was released 10 years ago.