STE WILLIAMS

Comment The FBI has asked Apple to unlock two iPhones belonging to a murderer, potentially reviving a tense battle over encryption and the rights of law enforcement to digital devices.

Mohammed Saeed Alshamrani, of the Saudi Royal Air Force, shot and killed three people and injured eight others at a US naval base in Pensacola, Florida, in December before he was shot himself. He died at the scene.

Alshamrani had two iPhones – one of which he reportedly shot and damaged – and the FBI has been trying to unlock the phones and extract the encrypted contents to see if there is any evidence that others were involved in the attack, or other clues to his actions. As such, the bureau has asked Apple to provide it with as much information as it can.

The request came in the form of a letter from the FBI’s general counsel Dana Boente, and was sent to Apple’s top lawyer on Monday. It has not been published though its contents were relayed to journalists, who have reported that the FBI has been unable to log into the unidentified phones since they are locked and encrypted.

The letter notes the FBI has obtained a search warrant to examine the phone, and has tried to unlock it, asking other government agencies and third-party companies for help, though it has been unable to access the device and so asks for Apple’s assistance in extracting the data within.

While that may all seem perfectly normal and above board, the fact that the letter has been written at all has left many wondering whether there is a hidden strategy behind the request.

Famously, the FBI and Apple ended up in a tense stalemate over the contents of another shooter’s iPhone – that of San Bernardino terrorist Syed Farook in 2015 – in which the iGiant said it had no way to access the contents of the encrypted locked phone, and the FBI asked a judge to force Apple to find a way in. Apple argued that to do so it would have to somehow break its own strong encryption, and that raised legal issues.

Cook fried

Apple CEO Tim Cook put his neck on the line by publicly stating that Apple would not do so, and ultimately the Feds backed down by claiming they had found a third-party that could access the phone. Since then, the issue has periodically resurfaced with the FBI, and most recently Attorney General William Barr arguing that some kind of legal remedy needs to be created that would allow law enforcement to access encrypted phones.

As such, the fact that the FBI has sent another letter asking for access – even though it knows the response it will get – and has been willing to discuss the letter’s contents points to some kind of strategic effort.

As such, the question becomes: what is different in this case to the one in 2015? And the answer to that is four things:

1. The shooting happened in Florida, rather than California, which may bring different legal issues to bear, most notably when a court in the Sunshine State in 2017 ruled that suspected criminals can be forced to hand over their smartphone passcodes to investigators.
2. The Attorney General has made it plain he believes there should be a legal mechanism to allow law enforcement to access the contents of phones.
3. Apple CEO Tim Apple Cook has gone out of his way to make nice with President Donald Trump in recent months.
4. The FBI claims that it has exhausted all other possibilities to accessing the data on the phone prior to asking Apple for access

Clean sheet

The last point may be critical because in a special inquiry report by the US Department of Justice’s internal inspector general into the battle between the FBI and Apple over the San Bernardino shooter’s phone – published in March 2018 – the watchdog noted that the FBI “did not pursue all possible avenues in the search for a solution” before contacting Apple.

The report also flagged a number of other internal issues including that “not everyone within OTD [the FBI’s Operational Technical Division] was on the same page in the search for a technical solution to the Farook iPhone problem, including varying testimony from OTD managers on whether there was a dividing line discouraging collaboration between the units that predominantly do criminal and national security work in OTD.”

FYI: FBI raiding NSA’s global wiretap database to probe US peeps is probably illegal, unconstitutional, court says

READ MORE

As such, it is possible that this latest FBI letter to Apple over Alshamrani’s iPhone is a way of putting in a formal request that ticks all the boxes, with none of the messy issues that were identified in the inspector general report.

In other words, it is a way for the FBI to get to a clean legal position. If Apple then refuses to provide access to the phones – which is highly likely – the Feds are in the best possible position for a potential legal challenge.

With the Attorney General making it plain he supports a legal right for cops and g-men to access encrypted devices, and with Apple CEO Cook going out of his way not to upset the Trump administration, the FBI may well feel that its letter represents a possible crowbar that it could use to crack open the encryption debate.

We don’t yet know. But the FBI’s general counsel doesn’t write letters just for the hell of it. Something’s afoot.

As for Apple, its formal response so far has been the following: “We have the greatest respect for law enforcement and have always worked cooperatively to help in their investigations. When the FBI requested information from us relating to this case a month ago, we gave them all of the data in our possession and we will continue to support them with the data we have available.” ®

Article source: https://go.theregister.co.uk/feed/www.theregister.co.uk/2020/01/08/fbi_pushes_backdoors_iphone/

Patting itself on its back for motivating software makers to fix 97.7 per cent of the vulnerabilities it identifies within its 90-day disclosure deadline, Google’s bug-hunting unit Project Zero has decided to ease up on those racing to patch their flawed products.

This month, Project Zero revised its Disclosure Policy so that it will publicly reveal details of a security flaw precisely 90 days after privately disclosing the details to the relevant vendor. This is a change from the previous policy under which bugs were revealed after 90 days or when fixed, whichever came first.

As a result of the amended policy, vulnerability details will remain undisclosed for a longer period of time, giving developers enough time to fix their code, and netizens to test and install the patches, before Googlers make technical details and proof-of-concept exploits public for all to see. Project Zero will, we note, reveal vulnerability details sooner if there’s mutual agreement between the affected vendor and the web goliath’s team.

There are also other exceptions: vendors can request an additional 14-day grace period if a vulnerability will be fixed after the 90-day deadline but before 104 days have elapsed. And a seven-day deadline still applies for vulnerabilities being actively exploited in the wild.

Picture this

So, imagine this scenario: Project Zero privately informs you that your application has a security hole in it. You spend the next two weeks fixing and testing a resolution for the flaw, and then roll out a suitable patch to your users. Folks now have the best part of 90 days to install this update and be safe before Google goes public with full details of your programming blunder. If the patch breaks during these 90 days, you still have time to address it before the Silicon Valley monster lifts the veil.

Under the old approach, Project Zero would privately tell you that your app has a security hole in it. You then spend the next two weeks fixing and testing the update, and roll out the patch to your users. Googlers immediately spot this, and make their bug report public. Your users are now in a race to update their systems before the hole is abused by miscreants using the web giant’s exploit. If your patch doesn’t fully work, your users are now left completely vulnerable while hackers play merry havoc with your busted code as you scramble to emit a followup update.

In either case, of course, you’re racing against malware developers who are poring over your security patch, as soon as it is released, to find a way to attack unpatched users – though bear in mind, when Google goes public, it typically posts proof-of-concept exploit code, taking care of most of that effort for miscreants.

Bad news: Google drops macOS zero-day after Apple misses bug deadline. Good news: It’s fiddly to exploit

READ MORE

In a blog post on Tuesday, Tim Willis, Project Zero manager, explained that the policy tweak is intended to encourage more thorough patch development and better patch adoption, while maintaining the policy’s original goal of driving faster patch development.

“Too many times, we’ve seen vendors patch reported vulnerabilities by ‘papering over the cracks’ and not considering variants or addressing the root cause of a vulnerability,” Willis wrote. “One concern here is that our policy goal of ‘faster patch development’ may exacerbate this problem, making it far too easy for attackers to revive their exploits and carry on attacking users with little fuss.”

In other words, Project Zero researchers hope the consistent 90-day revelation time will give vendors’ security engineers more time after a patch is initially developed to ensure it covers minor exploit changes that could bypass code repairs. They also anticipate that the potential lag between patch development and vulnerability disclosure will leave more time for patches to be deployed, making exploitation less likely.

Willis said Project Zero expects to evaluate whether its revised policy is working as intended later this year. ®

Article source: https://go.theregister.co.uk/feed/www.theregister.co.uk/2020/01/07/google_project_zero/

Hackers are taking advantage of unpatched enterprise VPN setups ‒ specifically, a long-known bug in Pulse Secure’s code ‒ to spread ransomware and other nasties.

British infosec specialist Kevin Beaumont says a severe hole in Pulse Secure’s Zero Trust Remote Access VPN software is being used by miscreants as the entry point for inserting malware attacks.

The vulnerability in question, CVE-2019-11510, was among the bugs patched back in April by an out-of-band update. The flaw is present in Pulse Connect Secure, a VPN program pitched at enterprises for remote workers and bring-your-own-device workers. The bug can basically be abused to extract plain-text passwords, and other secrets, from networks without any authentication.

“That vulnerability is incredibly bad — it allows people without valid usernames and passwords to remotely connect to the corporate network the device is supposed to protect, turn off multi-factor authentication controls, remotely view logs and cached passwords in plain text (including Active Directory account passwords),” Beaumont explained.

Now, months after the fixes were posted, Beaumont has investigated multiple ransomware infections and has confirmed that the Pulse Secure vulnerabilities were the entry point into the network for the hackers spreading the file-scrambling Sodinokibi nasty.

“In both cases the organizations had unpatched Pulse Secure systems, and the footprint was the same,” Beaumont explained, “access was gained to the network, domain admin was gained, VNC was used to move around the network (they actually installed VNC via psexec, as java.exe), and then endpoint security tools were disabled and Sodinokibi was pushed to all systems via psexec.”

The Register pinged Pulse Secure for its side in all of this, and the company issued the following statement.

“Pulse Secure publicly provided a patch fix on April 24, 2019 that should be immediately applied to the Pulse Connect Secure (VPN). The CVE2019-1150 vulnerability is highly critical. Customers that have already applied this patch would not be vulnerable to this malware exploit. As we have communicated earlier, we urge all customers to apply the patch fix,” the biz said.

“Beyond issuing the original public Security Advisory – SA44101, but commencing that day in April, we informed our customers and service providers of the availability and need for the patch via email, in product alerts, on our community site, within our partner portal, and our customer support web site.

Tricky VPN-busting bug lurks in iOS, Android, Linux distros, macOS, FreeBSD, OpenBSD, say university eggheads

READ MORE

“Since then, our customer success managers have also been directly contacting and working with customers. In addition, Pulse Secure support engineers have been available 24×7, including weekends and holidays, to help customers who need assistance to apply the patch fix. We also offered assistance to customers to patch for these vulnerabilities even if they were not under an active maintenance contract.”

Part of the problem may be that organizations are unaware they are running Pulse Secure VPNs that are vulnerable. Earlier this week, for an update on his website, Bad Packets Report‘s Troy Mursch ran a vulnerability scan finding that 3,826 Pulse Secure VPN servers worldwide remain vulnerable.

As some admins have noted, keeping track of such boxes can be difficult within a large enterprise, let alone getting them patched in a timely manner.

In fact, Beaumont says that Travelex, the currency exchange service that has been knocked offline by a malware infection, had seven such unsecured Pulse Secure servers and was hit by the same Sodikinibi ransomware group involved in the other attacks he had observed. Mursch said he tried to warn Travelex of those exposed machines back in September. ®

Article source: https://go.theregister.co.uk/feed/www.theregister.co.uk/2020/01/07/pulse_secure_attacks/

Article source: https://www.darkreading.com/ask-the-experts/d/d-id/1334297?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The “MDB Leaker” vulnerability in the Microsoft Access Database could lead to a memory leak if left unpatched.

Researchers today disclosed the details behind their discovery of CVE-2019-1463, a flaw inside the Microsoft Access database application that could lead to a memory leak if left unpatched.

The “MDB Leaker” vulnerability could potentially affect more than 85,000 companies, report the Mimecast researchers who discovered it. This represents the number of organizations using the Microsoft Access database management system. Most are located in the United States.

CVE-2019-1463 is strikingly similar to CVE-2019-0560, an information disclosure bug discovered by Mimecast in January 2019. The older flaw could enable unintended leakage of data in previously created Office documents and files. It’s difficult to use as a code execution bug, experts say, but it could be leveraged to harvest information users unintentionally exposed.

The two vulnerabilities share a common coding error. In the case of MDB Leaker, an application’s improper management of improper memory could also lead to the disclosure of sensitive or private data. Microsoft issued a patch for this bug in December 2019.

Its discovery started with a simple false positive, says Meni Farjon, chief scientist of advanced malware detection with Mimecast. The team used a static analysis engine, part of which was designed to detect the presence of machine code in data files that should only contain data objects. “Finding machine instructions, like CPU code, in a data file is bad news,” Farjon says. While it could be harmless content fragments, there is always a possibility the machine code could indicate an exploit taking advantage of a reader like Microsoft Excel or Access, he adds.

This analysis system generated a false positive report for a Microsoft Access MDB file. Researchers found code fragments in the file, which should have been data-only, and worried it could be an exploit to give attackers control or accidental code that made its way into the file.

Further analysis revealed the machine code in that file was machine code the researchers found inside the Microsoft Access application itself. This led them to believe there was a possibility of an issue that caused content to leak from memory into the file, Farjon explains. This could have broader implications: if an attacker could access a machine with MDB files, or large quantities of MDB files, they could conduct an automated search to collect sensitive data within them.

“Essentially, when a document is saved, the contents of the memory in some locations are being dumped into a file on disk,” he says. “In this scenario, other contents that were not expected to be dropped into the file were dropped into the file.” The team saved the file and noticed its contents changed; the file presented different artifacts each time it was accessed.

Information disclosure and memory leak bugs are normally used in two-stage attacks, says Farjon of the implications for MDB Leaker. If an attacker has a remote code execution flaw, they still need to know where they are in memory in order to launch an attack. Vulnerabilities like CVE-2019-1463 can help them do this. “Without knowing the location, a remote code execution vulnerability is pretty much useless,” he points out.

“Also, these access cells are leaking potentially sensitive information,” Farjon continues. “But we can’t say for sure what kind of information because it’s completely random … this specific memory leak can leak anything from memory.” In this sense, he says, an exploit is less likely because it’s difficult for an attacker to gain access to specific pieces of information.

CVE-2019-1463 affects all versions of Microsoft Office. An advisory issued for the CVE ranked the vulnerability as Important. There is no knowledge of this bug being exploited in the wild.

When comparing MDB Leaker with similar bug CVE-2019-0560, Farjon says the latter is likely more significant because Microsoft Excel is more frequently used than Microsoft Access. That said, Access is used to store more sensitive content like database information, which usually contains usernames and passwords.

“The Excel one is a bit more dangerous because there are billions of those documents just out there that somebody could grab and use to hunt for sensitive information,” he notes. “On the other hand, Microsoft Access is used to store much more personal, more sensitive information but is less commonly used.”

Related Content:

• Widely Known Flaw in Pulse Secure VPN Being Used in Ransomware Attacks
• 6 Security Team Goals for DevSecOps in 2020
• Operational Technology: Why Old Networks Need to Learn New Tricks
• The Coolest Hacks of 2019

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “What Tools Will Find Misconfigurations in My AWS S3 Cloud Buckets?“

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/application-security/the-discovery-and-implications-of-mdb-leaker-/d/d-id/1336739?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

“Teams” and a new browser security acquisition expand the cloud firm’s security offerings.

Distributed denial-of-service mitigation and infrastructure provider Cloudflare kicked off the new year with the acquisition of a browser security firm and the launch of a new security service that includes a combination of identity and access management, endpoint protection, and Internet filtering.

Cloudflare today announced that it has acquired browser-isolation technology vendor S2 Systems Corp., whose product runs browser code in the cloud as a way to protect endpoints from Web-borne threats. Cloudflare also rolled out Cloudflare for Teams, a combination of two products that underscores the company’s deeper dive into security services. The S2 buy and new security rollout come just a few months after Cloudflare’s initial public offering in September of last year.

Matthew Prince, co-founder and CEO of Cloudflare, says the new Teams services use the same technology that the company built for its own internal Internet proxy-style infrastructure. “We now can talk to largely the same [Cloudflare] customers and say, ‘you need the network for infrastructure but also for your teams,'” Prince says.

Cloudflare now offers a “giant network proxy that’s highly programmable,” he explains, and supports its customers’ mobile and decentralized employee bases. Teams is made up of two main services, Cloudflare Access and Cloudflare Gateway, both of which will be available midyear. 

The updated Cloudflare Access service, which was first released in 2018, mirrors the emerging “zero-trust” approach, according to the company. Zero trust basically considers users and devices untrusted until they undergo more scrutinized authentication, user monitoring, and endpoint protection. Cloudflare has partnered with identity vendors Okta, OneLogin, and Ping Identity as well as endpoint security firms Malwarebytes, Tanium, and VMware Carbon Black for Cloudflare Access.

Prince says Access replaces corporate virtual private network (VPN) equipment, providing an alternative to slow and often unreliable VPN systems. “Cloudflare Access is [akin to] a bouncer that looks at the user’s ID, checks that the device is up to date,” and determines if the user gets access, Prince says.

The new Cloudflare Gateway piece of Teams is a combination of the company’s existing DNS-based filtering traffic function as well as cloud partners Cloudgenix for securing traffic to the Internet, Ciphercloud for securing cloud-based applications, and S2’s browser isolation technology. According to Cloudflare, the company blocks on average of 72 billion threats each day from its customers’ Internet traffic. Cloudflare Teams also offers Splunk, Datadog, and Sumo Logic, dashboards for managing network security.

Prince says the new Teams service places the company squarely against firewall and VPN hardware vendors, including Palo Alto Networks, Check Point, and FireEye, as well as cloud security provider Zscaler, for instance. He points out that with Teams, his company also now competes with more Cisco network security products. “We’ve always competed against Cisco. What’s different now there is we are competing against a broader set of the Cisco catalog,” he says.

Many corporate VPN products have suffered from performance and security problems. Both the NSA and the US Department of Homeland Security last year issued advisories on discovered VPN vulnerabilities and warned about nation-state threat groups exploiting them. Most recently, VPN provider Pulse Secure yesterday told customers to immediately apply a security patch it had released last April for a critical, remotely executable flaw in some versions of its VPN products, after reports of ransomware attacks being levied via the flaw, CVE-2019-1150.

“There’s an opportunity for Cloudflare to come along and to essentially rethink” the VPN experience performance-wise, notes Steve O’Grady, principal analyst with Redmonk. Organizations are increasingly more comfortable outsourcing services to the cloud than before, he notes, because they see it as stronger security than they can provide.

Either way, Cloudflare is expanding beyond its famed DDoS mitigation service.

“The net for me is essentially that Cloudflare has grown up as an infrastructure-centric player — providing a variety of services from some sort of base CDN [content delivery network] to more sophisticated DDoS prevention and mitigation, and so on,” O’Grady says. 

Related Content:

• State of the Cloud 
• 7 Ways VPNs Can Turn from Ally to Threat     
• 2019 Online Malware and Threats: A Profile of Today’s Security Posture
• Rethinking Enterprise Data Defense

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “What Tools Will Find Misconfigurations in My AWS S3 Cloud Buckets?”

 

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/cloud/cloudflare-adds-new-endpoint-web-security-service-/d/d-id/1336737?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Recent US military action in Baghdad could prompt retaliatory attacks against US organizations, it says.

Concerns about an Iranian cyber response to the recent American military strike in Baghdad grew this week with the US Department of Homeland Security urging organizations to be on heightened alert for denial-of-service and other more destructive attacks.

In an alert Monday, the DHS’s Cybersecurity and Infrastructure Security Agency (CISA) warned US organizations about Iran’s historic use of cyberattacks to retaliate against perceived foes. “Iran has a history of leveraging asymmetric tactics to pursue national interests beyond its conventional capabilities,” the CISA alert noted.

In recent years, cyber groups operating on behalf of the Iranian government have improved their offensive capabilities in carrying out denial of service, website defacement attacks, and data theft. “They have also demonstrated a willingness to push the boundaries of their activities, which include destructive wiper malware and, potentially, cyber-enabled kinetic attacks,” CISA said.

The CISA alert is the first public acknowledgement from the US government about potential Iranian cyberattacks in response to the US drone strike last week that killed Gen. Qassem Soleimani. Several security vendors, including Crowdstrike and Recorded Future, have noted the possibility of such attacks in recent days, citing past precedent.

According to Crowdstrike, while there is no evidence of a specific threat emanating from Iranian nation-state actors at this time, US organizations should assume a defensive posture all the same. Current intelligence suggests that organizations in the government, defense, financial, and oil and gas sectors will be the most likely targets for attacks, the security vendor said.

Recorded Future said it believes that Iranian cyber groups will try to use networks they already have compromised in previous espionage activities to carry out new attacks. Other likely tactics include the use of web shells, password spraying, and commodity and custom malware to break into target networks. In addition to US-based targets, Iranian cyber operatives likely will target organizations in the Persian Gulf as well as US allies and partners in the region, Recorded Future said.

Multiple Iran-based cyber groups with suspected ties to the government and the country’s Islamic Revolutionary Guard Corps are believed to have the capability to disrupt and damage operations at US organizations. Top among them are APT33, one of the most active threat groups operating out of the Middle East; APT34 (aka OilRig/MUDDYWATER); and APT39, a relatively newly surfaced group that targets companies in the technology, travel services, and telecommunications sectors.

“APTs 33 and 34 are primarily focused on financial, energy, telecom, and SCADA/ICS,” says Rosa Smothers, a former CIA technical intelligence officer and senior VP of cyber operations at KnowBe4. Private sector companies responsible for critical infrastructure are often unaware these threat actors already might have a presence on their network. That poses a threat because the Iranian government and its hacker proxies are likely to first consider targets where they currently maintain persistence.

“If organizations are fully defending against APTs — utilizing defense-in-depth methods, educating users about how to spot phishing and rejecting known breached and common passwords — then your technical bases should be covered,” Smothers says.

Recommended Actions
Organizations in targeted sectors should be keeping an eye out for activities, indicators of compromise, and the tactics, techniques, and procedures associated with these APT groups says Anuj Goel, CEO of Cyware Labs. Examples of tools used by these groups include njRAT, RevengeRAT and NonoCoreRAT, he says. “Most recently, APT33, Iran’s most potent cybercriminal group, was found probing physical control systems used in electric utilities, manufacturing, and oil refineries using password-spraying attacks,” Goel says.

This week’s CISA alert listed multiple Iranian APT group techniques that US organizations should be monitoring for, including credential dumping, file obfuscation, PowerShell misuse, and the abuse of other legitimate system features such as Registry run keys and the startup folder.

The alert also recommended several actions that organizations can take to mitigate their exposure to potential attacks. Among them was the need to disable unnecessary ports and protocols, enhance monitoring of email and network traffic, patch externally facing systems, and limiting and logging PowerShell use.

“Scrub accounts that are no longer active, and investigate accounts that log in at odd hours,” Smothers adds. “Iranian activities were previously [discovered] due to activity occurring only during Iranian government business hours.”

Related Content:

• Iran Ups Its Traditional Cyber Espionage Tradecraft
• Russian Hackers Using Iranian APT’s Infrastructure in Widespread Attacks
• Iranian Government Hackers Target US Veterans
• 8 Ways Businesses Unknowingly Help Hackers

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “What Tools Will Find Misconfigurations in My AWS S3 Cloud Buckets?“

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/dhs-warns-of-potential-iranian-cyberattacks/d/d-id/1336741?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The years 2015 through 2019 were sweet for an IT services and product outfit calling itself Interactive Systems.

It submitted 52 invoices to a global internet business in Manhattan for a slew of stuff: 10 servers here, 16 servers there, 3 firewall devices, plus fat setup fees for all of it.

Funny thing about those invoices, though: four of them were submitted as Microsoft Word documents. The metadata for all four of the Word docs pointed to the same author: an IT boss working for the internet company being billed.

That IT exec’s name is Hicham Kabbaj, and on Friday, he pleaded guilty to one count of wire fraud for having set up a shell company and billing his employer for firewalls and services that “Interactive Systems” never actually installed.

To make it all perfectly circular, Kabbaj even addressed the invoices to himself.

As prosecutor Scott McNeil described in court filings, from around August 2015 through to around April 2019, Interactive Systems submitted approximately 52 invoices to “Company-1”. Once Company-1 paid up, Kabbaj would slide the cash on over to his own bank account – a scam that netted him a cool $6 million.

The last payment he got his hands on was in May 2019. After that, investigators spoke with two of Kabbaj’s colleagues.

One of them was a datacenter employee who worked under Kabbaj. “Employee-1” was in charge of Company-1’s datacenters since sometime in 2016, including being in charge of purchases during the time that Kabbaj was working for the company. Employee-1 told the Feds that he never purchased the firewall devices described in a March 2018 invoice, nor in a February 2019 invoice. Ditto for the 10 servers listed in an April 2019 invoice.

And no, said Employee-2 – a senior IT manager in charge of the datacenter at the parent company’s subsidiaries – we never saw anybody from Interactive Systems show up to do the services they billed us for. To do so, a vendor would have had to get his approval, and he’d never even heard of a vendor called Interactive Systems, he told investigators.

And when investigators checked with the manufacturers of the gear that Interactive Systems says it installed, they found out that the bogus company wasn’t listed as an authorized dealer for their products. Nor did it ever file a tax return.

As far as the payments for those invoices goes, equivalent amounts were often transferred to Kabbaj’s personal account within a few days.

A few months later, in September, Kabbaj was collared and charged.

Pretty bad, for an exec to abuse their position of trust like that, said IRS-CI Special Agent in Charge Jonathan D. Larsen:

Today, Mr. Kabbaj pled guilty to a serious felony because he chose to misuse his position of trust as a corporate executive to steal company funds for his own personal gain.

Kabbaj, 48, is looking at a maximum sentence of 20 years behind bars, though of course, he’ll spend less time than that: maximum sentences are rarely handed out. He’s awaiting sentencing now. He’s also going to be handing back the goodies he bought with the loot: namely, one house in Palm Beach Gardens, Florida, and one in Hewitt, New Jersey.

He’ll also be paying restitution of $6,051,453.

Kabbaj isn’t the first IT boss gone bad, and he likely won’t be the last.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/hCFk4KMyf3E/

What’s the most effective way to fight back against a large ransomware attack?

Normally, the answer would be technical or organisational, but a new type of ransomware called Maze seems to have stirred up a very different response in one of its recent victims – bring in the lawyers and try to sue the gang behind it.

The victim this time was US cable and wire manufacturer Southwire, which last week filed a civil suit against Maze’s mysterious makers in Georgia Federal court.

This mentions a big attack involving Maze, which we know from the company’s Twitter account happened on 11 December 2019.

Given that the attackers are unknown – referred to only as “John Doe” in legal filings – this might sound like a fool’s errand. But it seems it is the way the ‘Maze Crew’ attempted to extort Southwire that led to such unorthodox tactics.

According to Bleeping Computer, the sum demanded from Southwire was 850 Bitcoins, equivalent to around $6 million.

That sounds like a lot to supply some encryption keys to unlock scrambled data, but the demand was backed by a second and more sinister threat – if the sum wasn’t paid the data would be released publicly.

That ransomware attackers can steal as well as encrypt data isn’t a new phenomenon but the possibility that sensitive data might be revealed to the world is potentially more damaging than any short-term disruption caused by the malware.

And yet, despite the seriousness of this threat, it seems that Southwire declined to pay.

Circling the wagons

To understand this defiance, consider other recent Maze incidents in which the Maze gang released samples of the stolen data to media, and set up a special website to publish it.

Southwire would have known this was likely to happen because the attackers reportedly name-checked that they’d released the data from another victim as part of their ransom pitch.

The same website was eventually used to publish some of Southwire’s data, with further releases promised.

As Southwire’s incident website explains, at that point the company decided to go after the website, gaining a court order in Ireland on 31 December to have the domain and the data on it taken down.

Will this deter Maze from releasing he data elsewhere? Probably not. But the mere fact that three sizeable victims have dared them to release breached data isn’t exactly a great advert for the ransomware’s effectiveness.

It’s remotely possible that the Maze gang left clues as to their origins when they registered the domain, hence the involvement of lawyers that might unmask their identities.

FBI warning

It’s since emerged that with less-than-ideal timing the FBI issued a non-public warning to US businesses on 23 December 2019 warning that the Maze gang was on the prowl.

This does at least offer important information on the ways Maze infects targets using boobytrapped macros inside Word documents pretending to come from governments, including the use of exploits against unpatched flaws in Internet Explorer (CVE-2018-8174, CVE-2018-15982) and Adobe Flash (CVE-2018-4878).

The FBI advises not to pay Maze’s ransoms because doing so would not guarantee the recovery of data, nor the destruction of stolen data.

Whether that’s correct or not, the die has been cast – just when you think ransomware crooks have worn out every trick they use to get paid, they hit on a new one. Data exposure driven by ransomware could be the next big wave.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/jNMBVgsS2Wg/

Google has temporarily disconnected Xiaomi’s IP cameras from its Home Hub service after a user reported that he was seeing images from other people’s devices.

Google’s Home Hub is the company’s answer to Amazon’s Echo – a connected home automation display controlled via the GUI and a voice assistant. You can use it to control your thermostat and lighting, ask Google Assistant questions, and to see images from the connected IP cameras around your house. Unfortunately, Xiaomi’s cameras began displaying images from other peoples’ houses too.

Reddit user u/Dio-V found that Xiaomi’s Mijia 1080p IP camera was sending still images from other peoples’ homes when he accessed it via his Google Home Hub.

The camera, which Dio-V said was purchased new and had up-to-date firmware, sent multiple images from other peoples’ Xiaomi cameras when connected to the Google device. To prove his point, he posted images on Reddit including a sleeping baby, a person resting in a chair, and someone else seated at a table. Whoops.

Both Google and Xiaomi moved quickly to address the issue. The Chinese manufacturer admitted the mistake and explained that it was down to a caching issue on its server. In a statement sent to several outlets it said:

Our team has since acted immediately to solve the issue and it is now fixed. Upon investigation, we have found out the issue was caused by a cache update on December 26, 2019, which was designed to improve camera streaming quality. This has only happened in extremely rare conditions. In this case, it happened during the integration between Mi Home Security Camera Basic 1080p and the Google Home Hub with a display screen under poor network conditions.

We have also found 1044 users were with such integrations and only a few with extremely poor network conditions might be affected. This issue will not happen if the camera is linked to the Xiaomi’s Mi Home app.

A Google representative responded to Dio-V’s complaint directly in the Reddit thread the day after it surfaced, asking for clarification via direct message. The following day, Rachel (Google employee and community manager for Google Home Products) explained:

Late night on January 1st, we were made aware of an issue where a Reddit user posted that their Nest Hub was able to access other people’s Xiaomi camera feeds. We’ve been working with Xiaomi and we’re comfortable that the issue was limited to their camera technology platform. While we worked on this issue with Xiaomi, we made the decision to disable all Xiaomi integrations on our devices. We understand this had a significant impact on users of Xiaomi devices but the security and privacy of our users is our priority and we felt this was the appropriate action.

We’re re-enabling Xiaomi device integrations for everything but camera streaming after necessary testing has been completed. We will not reinstate camera functionality for Xiaomi devices until we are confident that the issue has been fully resolved. We’ll keep you updated with information as more becomes available to share.

Several Redditors were understandably concerned about the issue, however temporary it might have been, with some calling it “creepy”.

While both companies dealt with the problem as quickly and efficiently as they could, it highlights an ongoing issue with cloud-based IoT services, which are vulnerable to mistakes and technical glitches. We’ve seen cameras that send images to the wrong people before, and others with security bugs that make them potentially accessible via the Shodan search engine.

What can you do to protect yourself from vendor mistakes?

One drastic solution is to avoid relying on the cloud at all and set up your own system self-hosted home automation solution that you can configure not to send your data to third parties. The Self Hosted podcast has more information on that. It would mean running your own server (which could be a Raspberry Pi) and setting up a decent VPN for remote access.

It’s certainly not simple but it would make a fun personal project for the technically minded.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/obA4FzgLKds/