Monthly Archives: July 2017

Dow Jones becomes the latest organization to be affected by an AWS cloud data leakage due to misconfiguration and user error.

A security researcher found yet another unsecured Amazon S3 bucket leading to more cloud data leakage due to user error.

The cloud data leakage of Dow Jones & Company customer data marked the latest in a line of Amazon Web Services (AWS) cloud data leakage incidents from the Republican National Committee (RNC), the WWE, the Department of Defense and Verizon — the last two via third-party contractors. Cybersecurity firm UpGuard, which also found and notified the other organizations listed, reported the potential cloud data leakage to Dow Jones in early June.

Dow Jones confirmed  the AWS data leak included customer names, email addresses and some partial credit card numbers, but said no full credit cards or account credentials were part of the cloud data leakage. Dow Jones claimed issue affected 2.2 million customers, but UpGuard estimated the number to be “closer to 4 million.”

While Dow Jones said the exposure was due to an “internal error,” UpGuard gave a more detailed account that stated that any user that had an AWS account would have been able to “download the data via the repository’s URL” due to the way permissions settings were configured.

“The revelation of this cloud leak speaks to the sustained danger of process error as a cause of data insecurity, with improper security settings allowing the leakage of the sensitive information of millions of Dow Jones customers,” Dan O’Sullivan, cyber resilience analyst at UpGuard, wrote in a blog post. “The data exposed in this cloud leak could be exploited by malicious actors employing a number of attack vectors already known to have been successful in the past.”

As with previous AWS cloud data leakage discoveries, Chris Vickery, director of cyber risk research at UpGuard, found the exposed Amazon S3 buckets. Experts and AWS documents said S3 buckets are private by default and require users to actively change the permissions settings and said this kind of misconfiguration far too common when making data shareable.

“Amazon defaults to provide and provides multiple security mechanisms to prevent S3 buckets from being made public accidentally. Right now it’s very easy to manage within AWS, but if you want to share data with someone outside AWS and you aren’t overly familiar with AWS security you might be tempted to just make the bucket public,” Rich Mogull, analyst and CEO at Securosis, told SearchSecurity. “That’s what I assume happened in most or all of these situations — someone needed to share data. They were using AWS but weren’t familiar with it and didn’t look up the documentation on how to handle this securely. They took the easy way out and made the bucket public.”

AWS permissions control

Scott Petry, CEO and co-founder of secure web browsing vendor Authentic8, agreed that user error was the primary cause of the cloud data leakage because “the free form nature of bucket creation and naming conventions make it more challenging.”

“The method for managing permissions in Amazon buckets is very powerful, but perhaps not as intuitive as it could be. When you create a bucket, it defaults to private permissions, available only to the bucket creator. The only other option at the bucket level is public where the data is available to all,” Petry told SearchSecurity via email. “In order to selectively provide access, you need to define identity and access management (IAM) policies. In order to manage more fine-grained access, you can create an IAM user for the person you want to share with. Then create an access permission for that user or users. If you want a process to access data stored in a bucket, you’d create that user and then allow authorized services to access that user account, which would have access to the data in the bucket.”

While Mogull agreed user error was at fault for the cloud data leakage, he said Amazon may need to consider risks surrounding less knowledgeable users.

“While users are mostly responsible for disclosures the mechanism for writing IAM and bucket policies could be simplified for less technical users,” Mogull said. “Right now it is really easy to make a bucket open to everyone, and although AWS warns you, setting more restrictive policies for non-AWS user access (like sharing with a peer organization) could be simplified.”

Brian Vecci, technical evangelist at threat protection vendor Varonis, noted that “many platforms have permissions interfaces that are unintuitive and contribute to user error, but the onus is on the organization to account for that.”

“There are also third party products that scan access controls and help illuminate situations where permissions may be less-than-ideal or downright broken. Enterprises should make use of these tools — especially if they’re dealing with sensitive data,” Vecci told SearchSecurity. “In the case of Dow Jones, they made matters worse by hosting their data at the easy-to-find subdomain ‘dj-skynet.’ Hackers and researchers can write scripts that programmatically try different strings. Much like brute force password attacks, the simpler the bucket address, the simpler it is to guess.”

Ben Johnson, CTO at cloud security provider Obsidian Security, said that it was both user error and Amazon shared blame for the series of cloud data leaks.

“In the end, Amazon needs to do more. It goes back to the challenge of too many security controls makes it harder to install, configure, deploy, and monitor your services and apps, and too little security controls leads to risk and vulnerability,” Johnson told SearchSecurity. “Amazon needs to take a stronger look at the built-in security, but it will always be first and foremost the responsibility of Amazon’s AWS customers to make sure their systems and data are appropriately protected.”

Cloud data protection on AWS and other services

Mike Shultz, CEO of risk governance company Cybernance, said he would be surprised “if Amazon doesn’t consider imposing greater restrictions and oversight on user data.”

“The processes could include requiring more detailed descriptions of the data and more widespread review of the policies under which it’s made available. The number one action companies can take is to instill and demand effective policies, processes and behaviors of people. Over time, much of this review could be automated,” Shultz told SearchSecurity. “AWS could and should develop tools and processes to help its clients make sure that they tighten up their applications and apply proper procedures. It remains in the best interests of all to be sure that data is safe from bad actors.”

Mogull said he “would be shocked” if similar user errors and misconfiguration didn’t exist on other cloud platforms like Microsoft Azure, Google Cloud and Dropbox.

“If the enterprise has a security team, they need to make sure people are trained at a technical level on cloud security. They also need to implement a cloud security program. I’m probably biased on these since it’s a big part of our business, but I think it’s just common sense,” Mogull said. “We see too many enterprises moving into cloud without a good technical cloud security program. There are multiple tools that can help reduce the risk of these kinds of exposures.”

Vecci said it’s “trivially easy for bad actors to get their hands on automated tools and scripts that scan for open Amazon S3 buckets or scrape the web for public Dropbox links and auto-aggregate any data they can get their hands on.”

“And it’s not just cloud platforms. You can go to Google search right now and type in: filetype:config inurl:web.config inurl:ftp and see tons of misconfigured FTP servers with exposed passwords,” Vecci said. “Misconfigurations are nothing new, but are much more discoverable on publicly facing servers that aren’t behind a corporate firewall.”

UpGuard’s O’Sullivan told SearchSecurity, “Ultimately, it is the responsibility of any user of a cloud-based storage service to ensure that their permission settings and accessibility configurations are appropriate to whatever servers they are administering. However, cloud storage providers should take note of any such issues and do their best to ensure default settings and user interfaces are easily formatted for securing data. If settings are sufficiently confusing to cause many administrators to make similar mistakes, perhaps such services can do more to ensure data security.”

via: techtarget

Often thought of as impenetrable, macOS is falling prey to a sneaky malware that’s stealing bank credentials, bypassing Gatekeeper, and disabling attempts to remove it.

macOS users aren’t as safe as they think they might be—there’s a new strain of malware going around that infects devices, fakes bank websites, and steals credentials. It’s a dangerous strain of the OSX/Dok malware and it goes deep into macOS’s configuration to prevent its removal.

OSX/Dok cases found in the wild have surged in the past few weeks according to Check Point Software Technology’s malware team, who say it’s only likely to become more of a threat due to the aggressive Apple certificate buying activities of the malware’s creators.

Apple’s computers are generally considered more secure than their Windows competitors, but this malware is proving that no one is exempt from the security concerns of the modern age.

OSX/Dok: What it does

OSX/Dok was initially discovered in May 2017. Back then it was only known to be spying on web traffic and stealing website credentials, but this newly discovered mutation is actively redirecting traffic to a command and control (C&C) server that spoofs bank login pages in the attempt to harvest user information.

When a computer gets infected, OSX/Dok goes to work disabling security updates and redirecting traffic to Apple servers (and others like Virustotal.com, the only known antivirus platform that detects it) back to the local machine. In this way the malware hides itself and prevents updates that can remove it or stop its operation.

After embedding itself, OSX/Dok downloads TOR and establishes a connection through the dark web to its C&C server, which it accesses using Onion routing. The malware also uses TOR to trace the physical location of the IP address of the infected computer in order to customize its attack. An infected machine from Switzerland, for example, had a proxy setup that redirected common Swiss bank websites to a local proxy and then through to the C&C server.

The C&C server contains a variety of spoof banking websites that try to trick the user into signing in, as well as downloading a mobile app and providing their smartphone number. It also prompts the user to install a legitimate secure messaging app called Signal, though no one knows what its purpose is yet.

OSX/Dok is also able to bypass Apple’s GateKeeper, which is designed to stop installations from apps that don’t have a legitimate Apple developer certificate. The malware’s developers are doing this by buying huge quantities of certificates and attaching them to the malware. Apple is cancelling them as fast as it discovers which ones have been compromised, but Check Point says it’s discovering new ones on a daily basis.

The one bright spot in the OSX/Dok outbreak

There isn’t much good to say about this rather sophisticated malware except for one thing: It’s spreading through phishing emails and requires the user to download and run an executable to install it. As long as users aren’t falling for the phish there’s nothing to worry about.

It falls to IT professionals to make users aware of threats like OSX/Dok, which lacks the ability to spread when a user isn’t tricked into installing it. Once the infection gets hold of a computer it’s a completely different, and much trickier, problem.

Apple may be continuing to revoke certificates compromised by OSX/Dok, but it has yet to issue a security upgrade that will prevent it from bypassing Gatekeeper.

Be sure you’re keeping all the macOS machines on your network up to date and keeping an eye on ones that aren’t able to do so—those machines may already be infected.

Top three takeaways:

1. A new, more dangerous form for of OSX/Dok is infecting macOS machines. Its objective is stealing banking account credentials.
   
2. The malware is able to bypass macOS Gatekeeper by using stolen developer certificates. Apple is revoking certificates as soon as it is made aware of their theft, but more are being discovered every day.
   
3. Machines are being infected through a phishing campaign that prompts users to download a zip file that contains an infected executable. IT professionals should inform their users of the OSX/Dok outbreak and ensure that they aren’t opening suspect messages.

via: techrepublic

WikiLeaks on Thursday published a user guide describing what appears to be a tool used by the U.S. Central Intelligence Agency (CIA) to intercept SMS messages on Android mobile devices.

Named HighRise, the version of the malware described in the WikiLeaks document is disguised as an app called TideCheck, and it only works on Android versions between 4.0 and 4.3.

According to its developers, the tool must be manually downloaded, installed and activated on the targeted device – this means that the attacker needs to have physical access to the smartphone or trick victims into installing it themselves.

The second scenario is less likely as activating the app requires the user to open the TideCheck app, enter the “inshallah” password (the Arabic expression for “God willing”), and select the “Initialize” option from the menu. The document shows that the app will automatically run in the background after a reboot once it has been manually activated.

HighRise can be used to proxy incoming SMS messages received by the compromised device to a remote server. The tool also includes functionality for sending messages to the server via a secure communications channel.

A different interpretation of the leaked document by The Hacker News suggests that HighRise is actually installed on the CIA operative’s phone and it proxies SMS messages from malware-infected smartphones to the agency’s servers. As the user guide describes it, the tool provides greater separation between the targeted devices and the CIA’s servers.

The user guide leaked by WikiLeaks is for version 2.0 of HighRise and it’s dated December 2013. Google has made numerous security improvements to the Android operating system since version 4 – the latest version is Android 7 Nougat – and malware such as HighRise may no longer work without significant updates.

On the other hand, cybercriminals have been keeping up with the improvements and they still manage to create profitable Android malware. Furthermore, given that HighRise requires a significant amount of user interaction, it’s possible that this or other similar projects are still successfully utilized by the CIA.

Over the past months, WikiLeaks has described several “Vault 7” tools allegedly used by the agency. The most recent leaks detail malware designed for redirecting traffic on Linux systems (OutlawCountry), stealing SSH credentials (BothanSpy), spreading malware on an organization’s network (Pandemic), locating people via their device’s Wi-Fi (Elsa), hacking routers and access points (Cherry Blossom), and accessing air-gapped networks (Brutal Kangaroo).

via:  securityweek

The Payment Card Industry Data Security Standard (PCI DSS) is the security standard for protecting payment card data. Navigating the requirements of the PCI DSS and implementing the technical security controls can be quite complicated.

If your systems touch credit card data in any way, your bank and the major card brands require you to be PCI compliant. Hardened systems managed by experienced security professionals who know how to implement the PCI DSS are the key to avoiding audit failures or, worse, breaches and expensive fines and reputational damage.

Your specific PCI compliance needs depend on exactly what you do with the card data (is card data stored or does it only pass through on the way to a payment gateway, etc.), as well as how many card transactions your company processes. This determines your verification requirements (whether you can self-assess or whether a third party auditor must attest to your compliance) and exactly what you must do to become compliant (which Self-Assessment Questionnaire) must be completed. It could be as simple as satisfying a dozen requirements or as complicated as several hundred.

Compliance vs. Security

All companies with a compliance obligation must remember that the point of compliance is to impose a certain level of security. Security is the ultimate goal, not necessarily compliance. Remember that the PCI DSS is the minimum acceptable practice for protecting payment card data.

Being compliant does not mean you are secure; it merely means you have “checked the boxes.” There are many things which could still result in a compromise such as an employee accidentally leaking his passphrase by getting his computer infected with malware, a bug in a web application exposed directly to the Internet, etc. Occasionally it becomes necessary to go beyond the security requirements spelled out in the “letter of the law.” Compliance requirements should be considered “minimal acceptable practice” and not strictly “best practice.”

What’s more, both compliance and security are ongoing efforts; the work is never-ending. There are always new vulnerabilities discovered, new versions of software coming out, and advances in the state of the art in terms of attacking and defending.

Prevention, Detection, Response

A solid PCI security program has three main components: prevention, detection, and response. Each of the security controls described herein can generally be classified as one of these. Using secure passwords (Requirement 8.2.3), keeping systems patched up (Requirement 6.2), and even employee background checks (Requirement 12.7) are considered prevention. These seek to avoid trouble in the first place.

But despite best efforts, there is no such thing as 100% security: prevention cannot always be successful. We must also plan to detect problems or situations which could lead to intrusion and limit damage. In addition, a plan must be in place to respond to an intrusion to prevent the situation from getting worse and to ultimately resolve the issue.

Risk Mitigation Is the Name of the Game

There is no such thing as perfect or complete security. Each security control implemented is designed to reduce the probability of having an incident in some way. Sometimes it may seem that any one particular security control may not be terribly critical but remember that probabilities add up and anything that can be done to reduce the probably by even 1% can be worth it. To be able to mitigate risk, an assessment must be done to identify the risk.

PCI DSS Scoping

The “scope” of a PCI Card Data Environment (CDE) environment is any system which contains payment card data and any system which touches or is directly accessible by a system which contains payment card data. There are some additional rules also but this covers the general idea. The PCI DSS is applicable to any systems which are “in scope,” and all such systems must be secured per the PCI DSS. A good secure server hosting company can help you analyze your systems, determine the scope, and most importantly minimize the scope. To minimize the scope of the CDE is to reduce risk, reduce expense, and reduce the burden of maintaining a compliant environment.

Security Controls

A security control is anything which reduces risk. Your host company should conduct a risk assessment of your environment and identify the risks. Each risk identified in the risk assessment must be addressed by a security control which is intended to reduce or mitigate that risk. In addition to the PCI DSS, publications such as NIST SP-800-53 can be used for additional guidance in implementing security controls.

The Requirements of the PCI DSS

The PCI DSS is a list of tasks you are required to complete in order to secure your Card Data Environment (CDE). While the PCI DSS has only 12 major requirements, each one can have a dozen or more sub-requirements. Exactly which of these requirements your company must meet depends on what you do with the card data. Ultimately, it is based on risk: If you store card data you will have to meet every one of the requirements. If you don’t actually store the data and only have it momentarily as it passes through your systems on the way to the payment gateway, you must only comply with a subset of the requirements.

Below, we take a quick look at the 12 major requirements and a few of the sub-requirements.

#1: Install and maintain a firewall configuration

In order to protect cardholder data, firewalls must be configured with both ingress and egress filtering. Most people are familiar with the idea of firewalls blocking inbound connections but blocking unusual outbound connections is also necessary to prevent many kinds of attacks from working as well as exfiltration of data. Firewalls logging blocked outbound connections is an excellent source of information about unusual things happening within the network.

Network segmentation is key in reducing the PCI scope of the CDE. The client’s environment will be maintained on its own private network separated from non-client systems via firewalls using VLANs. Web application servers, database servers, and development servers will all reside in their own separate VLANs and be protected from each other to the greatest extent practical. The CDE will reside in its own isolated subnet or subnets separate from other systems which are not involved in the processing of payment card data.

#2: Do not use vendor-supplied defaults for system passwords and other security parameters

This requirement covers not only using default passwords (which attackers frequently use to attempt access) but also ensuring that each system performs one task, disabling unused services, etc.
#3: Protect stored cardholder data

Your host server vendor and help to analyze the need to store cardholder data, what forms of data are permissible to store and what are not, and implement strong encryption or other security controls as required to meet Requirement 3. Proper key management is a big part of keeping encrypted data secure, and Requirement 3 has a number of sub-requirements in this regard.

#4: Encrypt transmission of cardholder data across open, public networks

When payment card data flows over open networks, encryption must be utilized: your vendor should use SSH for administrative functions, GPG for email, and SSL for webserving of such information. Standard Linux whole disk encryption is also available although generally only recommended for mobile devices such as laptops.

#5: Protect all systems against malware and regularly update anti-virus software or programs

Automation should ensure that anti-virus is installed on all systems, is up to date, and is configured to scan properly, generate audit logs, etc. Furthermore, systems are in place to provide monitoring and alerting to the discovery of viruses or malware on servers via a centralized log collection system.

#6: Develop and maintain secure systems and applications

Your vendor should go to great lengths to harden their systems to ensure they are as secure as possible. A solid Linux host hardening program is based on the NSA Linux Hardening Guide also known as the NSA Systems Network Attack Center (SNAC) hardening guide.

While not required by PCI, one of the best hardening measures is the use of an automated management system known as Puppet. This system automatically applies many configuration changes to a stock Linux server. It currently consists of over 3000 lines of code and covers automatic configuration and maintenance of a multitude of security controls. Implementing SELinux on all security hardened servers is also a good idea. This is a system of mandatory access controls (MACs) developed by the NSA.

Reviewing a number of sources of security information on a daily basis (Requirement 6.1); applying security patches within 30 days (Requirement 6.2); and the development of secure web applications (Requirement 6.3) are also critical.

#7: Restrict access to cardholder data by business need to know

This involves using standard access control methods provided by the operating system such as users, groups, etc. The systems will be configured to allow access only to those who have a business justification. Two-factor authentication, public key authentication, etc., should be used as appropriate.

#8: Identify and authenticate access to system components

This requirement says each individual user must have a unique user ID (no shared IDs) to ensure personal individual accountability (Requirement 8.1.1). It also calls for sound account management practices, strong passwords, and lockout after a particular number of failed authentication attempts.

#9: Restrict physical access to cardholder data

Data center facilities should be audited annually to SSAE 16 Type II and have a 24/7 manned physical presence. The data center should extensive video camera coverage (Requirement 9.1.1), and visitors should be logged by required sign-in (9.4.4) etc. All equipment should also be logged as it physically enters and leaves the datacenter. When equipment is retired it is disposed of properly to ensure that card data is not compromised including the secure wiping or physical destruction of media (Requirement 9.8).

#10: Track and monitor all access to network resources and cardholder data

Regular analysis of system log files is critical for detecting intrusions, intrusion attempts, and software misconfigurations. It is important to get the system log files off the server on which they are generated and onto a separate secured system to prohibit tampering. System log files will be sent in real-time to a central log server where they can undergo weekly audit log reviews per requirement 10.6. Other regularly scheduled audits will be conducted on a daily, weekly or quarterly basis.

#11: Regularly test security systems and processes

Requirement 11.4 calls for intrusion detection systems for information system monitoring, near real-time alerting of issues, etc. One of the best ways to monitor network activity and detect network attacks is to use a Network Intrusion Detection System (NIDS). Such a system inspects all traffic going into and out of the network and applies rules and heuristics to network traffic to attempt to detect attacks and alert security personnel of potential issues. Data coming from the NIDS must be reviewed regularly and in a timely manner to ensure early detection of issues.

#12: Maintain a policy that addresses information security for all personnel

The security policy is a required document which ensures that all personnel with access to the card data environment know their responsibilities with respect to security. It lays out the policies and procedures that personnel are expected to follow. A copy signed by each individual with such access must be kept on file. There are many risks for which there is no technical solution as the risk is due to individual behavior and actions.

Conclusion

The major points of PCI compliance have now been covered and we hope you have a better understanding of exactly what a PCI compliant hosting solution looks like. PCI compliance is a team effort, and the secure hosting company you choose should help your company move towards obtaining and maintaining PCI compliance — not just as a one-time task but as an ongoing campaign.

Additional Resources: For additional information please visit the PCI Compliance Website.

via:  enterprise-security-today

A quarter of CIOs have experienced ransomware attacks, survey finds

Research among CIOs and IT leaders has found that only half have implemented new security safeguards following the WannaCry ransomware attack, and only 15% plan changes in response to Petya.

This is despite 27% admitting their organizations have suffered ransomware attacks, according to IT governance non-profit ISACA’s survey of 450 CIOs.

The vast majority (76%) said that their organizations were either highly or somewhat prepared to deal with the increased frequency on ransomware style attacks against their networks. However, only 50% of organizations have carried out staff training programmers to help them deal with the threat.

The research also found that less than a quarter of organizations are applying the latest security software patches within the first 24 hours of release. In some cases it can take over a month before the software is updated.

What is particularly concerning is that almost 15% of respondents said that their organizations won’t take any further precautions following the Petya attack earlier this month, despite the fact that the vast majority (83%) expect further ransomware attacks in the future. Only 6% said they would pay the ransom.

“Our poll shows that more than one in four organizations typically wait longer than a month to apply the latest software patches,” said ISACA CEO Matt Loeb.

“Given the escalating volume and complexity of threats enterprises are facing, placing greater urgency on rapid, comprehensive patching is a critical component of protecting an organization from the business- and infrastructure-crippling consequences of an attack.”

The WannaCry attack in May affected over 300,000 computer systems globally, and while the ransom was fairly modest at $300, it highlighted a widespread vulnerability to this style of attack that would be exploited again by Petya the following month.

However, following analysis of the Petya malware, experts now believe that its main purpose was to destroy data, rather than generate cash.

Ahead of the upcoming GDPR regulations, companies will need to demonstrate they are doing all they can to protect the data they hold, including shoring up their security against malware.

via: itpro

A newly discovered Point of Sale (PoS) malware is being delivered via a dropper that is manually loaded and executed on the targeted systems, Arbor Networks Security researchers warn.

The new threat was associated with command and control (C&C) servers used by Flokibot in a campaign targeting Brazil. Dubbed LockPoS, the malware appears to have been compiled in late June and to use a dropper that injects it directly into the explorer.exe process.

After being manually loaded and executed, the dropper continues by extracting a resource file from itself. The resource contains multiple components that are injected into explorer.exe and which act as a second-stage loader. Next, it starts decrypting, decompressing, and loading the final LockPoS payload.

While analyzing the malware, Arbor Networks researchers discovered it uses a regular “registry run” method for persistence. The malware obfuscates important strings using XOR and a key of “A”. It also stores an initial configuration unencrypted as a binary structure.

The malware’s communication with the C&C server is performed via HTTP, using a very telling User-Agent. Information sent to the server includes username, computer name, and bot ID, Bot version (1.0.0.6), CPU, Physical memory, Display devices, Windows version and architecture, and MD5 hash of currently running sample.

“The malware’s PoS credit card stealing functionality works similarly to other PoS malware: it scans the memory of other running programs looking for data that matches what credit card track data looks like. Here’s a snippet of the matching function,” the security researchers explain.

Until now, the new malware has been distributed via a Flokibot botnet, and, with both threats sharing a common C&C server, the researchers believe that same threat actor controls both of them. Because the Flokibot campaign associated with the server was targeting Brazil, the researchers believe LockPoS will target the same country as well.

Although the same C&C at treasurehunter[.]at was used in another PoS malware campaign in what FireEye referred to last year as TREASUREHUNT, Arbor Networks says that LockPoS is a different malware family from TREASUREHUNT.

“It is currently unclear whether LockPoS is an exclusive malware associated with one threat actor or whether it will be sold on underground forums like Flokibot was. Based on the internals of the malware described in this post, LockPoS seems to be coded well and stable, but doesn’t particularly raise the bar when it comes to ‘highly advanced malware’, the researchers note.

via:  securityweek

By @AnnePMitchell

The Blue Whale Challenge, also known as the Blue Whale Game, is purported to be a deadly game which targets teenagers online and through social media. Said to be named after the way a blue whale will beach itself and die, Blue Whale consists of 50 challenges, increasingly harmful, photographic completion of which you send back to your handler (known as the ‘curator’ or the ‘administrator’), with the final fiftieth challenge being suicide, also broadcast via social media.

While the existence of Blue Whale Challenge has been debated since at least 2015, more and more evidence suggests that it is very real indeed. While perhaps it wasn’t a real thing back in 2015, it is most decidedly real now, whether because someone took up the reins after stories of Blue Whale surfaced, or because it was already real back then.

The most recent victim of the Blue Whale Challenge, just this week, is 15-year-old Isaiah Gonzales, of San Antonio, Texas, whose parents found him hanging in his bedroom closet, with his cell phone pointing to his limp body, broadcasting his final deed.

Isiah Gonzales

Credit: KSAT San Antonio

Isaiah’s heartbroken father, Jorge Gonzales, told San Antonio news station KSAT “I want [parents] to go through their phones, look at their [children’s] social media. If they’re on that challenge already, they can catch that from happening.”

Isiah’s family found pictures of Isaiah completing some of the earlier Blue Whale Challenges, which they say Isaiah had sent to friends, indicating what the 50th challenge would be.

Lament’s Isaiah’s sister, Scarlett, “They blew it off like it was a joke and if one of them would have said something, one of them would have called us, he would have been alive.”

Social media hashtags associated with the Blue Whale Challenge include #BlueWhale, #BlueWhaleChallenge, and #BlueWhaleGame, and also may include #F57, #F75, and #F58.

A few of the images found under the hashtags #BlueWhaleChallenge and #BlueWhaleGame on Instagram

A few of the images found under the hashtag #BlueWhaleChallenge on Instagram

The poster of the last image said, along with the picture, “I used only to drink coffee #bluewhalegame,” an apparent reference to the challenge where you have to drink bleach or another noxious substance.

There are some who still say that the game is urban legend. In fact, in February Snopes listed it as “unverified” (not disproven, just unverified).

However, the Wikepedia article on the Blue Whale Challenge cites nearly 200 citations demonstrating that the Blue Whale suicide game is all too real, even if originally it wasn’t. That article also cites incidents from 18 different countries which are purported to be linked to Blue Whale.

What many of the incidents have in common is that one of the first double-digit challenges (such as challenge #10 or #11) involve cutting, sometimes in a particular pattern, including, yes, a whale. (For more on the list of challenges, see this article at Heavy.com.)

The Wikipedia article also cites the arrest, in Russia, of Philipp Budeikin, who claims to have both invented Blue Whale, and to be personally responsible for the suicides of 16 teenaged girls. Budeikin says that he invented the game to cleanse society of those who have no value.

In a chilling interview with a StPetersburg.ru reporter, Budeikin says:

Question: Did you really push the teenagers to death?

Answer: Yes. I really did. Do not worry, you will understand everything. Everyone will understand. They were dying happy. I gave them what they did not have in real life: warmth, understanding, communication.

{Ed. note: The above is a small snippet – you can read the full interview here, but be warned, it is very disturbing.}

At this point, we feel that it almost doesn’t matter whether the Blue Whale Challenge is a real thing or not (although the evidence is pretty persuasive) – it’s clear that with all of the news coverage there is at very least a ‘copycat’ clone of what was being reported as the Blue Whale Challenge.

So, as Isaiah’s grieving father exhorts, and as you should be doing anyways, check your children’s social media accounts regularly. As we mentioned, hashtags associated with this game may include #BlueWhale, #BlueWhaleChallenge, #BluelWhaleGame, #F57, #F75, and #F58 (an explanation of the last three is in the interview with Budeikin).

via:  theinternetpatrol

How should organizations address the need to keep software up to date with security patches without it costing too much or being too labor intensive?

We often hear we need to keep software up to date by applying security patches as soon as possible, but this is not as simple as it sounds, because patching operating systems can cause some bespoke software to misbehave. So what exactly should we be patching, how quickly should we be patching and how do we ensure critical software runs properly on a newly patched system?

It is true that prompt patching is essential. When a new patch is released, attackers will use readily available software to compare the patch to the existing application to identify the vulnerability being patched. This can be done in minutes, rather than hours, meaning hackers often release malware (or adapt existing malware) to exploit that vulnerability within hours of the patch being released.

Estimates vary, but it is generally recognized that around 80% of attacks use vulnerabilities for which patches already exist, and most use vulnerabilities which could have been patched over a year before the attack. The statistics also show the majority of attacks use the most common exploits, so patching these first, in priority according to the threat level, will also help to reduce risk. Most guidance recommends patching within a week, but in practice this can be extended to a month (except for critical vulnerabilities) with little increase in risk.

Patching needs to include not only operating systems, but also office applications, bespoke applications and third-party applications. To be sure your patching is up to date, it is advisable to employ vulnerability checking tools or services which scan the environment and report any missing patches or known vulnerabilities. This will highlight any failed patches and unknown applications outside your patching regime.

Patching is becoming easier than it once was. In many cases it can be automated by the software provider and, if using software as a service(SaaS), it is done by the provider. Where using only Microsoft Office applications running on a Windows host, rigorous testing may not be necessary.

But mission critical applications will still need to be tested on newly patched operating systems before the patch is deployed across the enterprise. This inevitably delays the deployment of the patch, but while you may not be thanked for bringing down a business critical application to mitigate a “theoretical” risk of a cyber attack, you still need to patch.

Patching is therefore a risk management exercise of balancing the risk of an unpatched vulnerability against the risk of taking down a critical application with an untested patch. Where time is needed to test, it may also be possible to mitigate the risk through the use of existing security appliances such as web application firewalls, network firewalls and host firewalls, while mitigating intrusion to an acceptable level through other means.

If testing goes badly and a business-critical application fails, you will need to mitigate the risk until the application is updated to run on the patched system. Where you don’t have access to a test system, one approach can be a phased rollout starting with a limited number of users to minimize any impact caused by patching. In all cases, you will also need a rollback plan in case things go wrong.

In summary, patching should be treated as a risk management exercise. Patch as soon as is practical and use automated patching where possible to reduce cost. When testing critical systems, mitigate the vulnerability by other means to reduce the risk of the patch interfering.

via: computerweekly

Verizon, the major telecommunications provider, has suffered a data security breach with over 14 million US customers’ personal details exposed on the Internet after NICE Systems, a third-party vendor, mistakenly left the sensitive users’ details open on a server.

Chris Vickery, researcher and director of cyber risk research at security firm UpGuard, discovered the exposed data on an unprotected Amazon S3 cloud server that was fully downloadable and configured to allow public access.

The exposed data includes sensitive information of millions of customers, including their names, phone numbers, and account PINs (personal identification numbers), which is enough for anyone to access an individual’s account, even if the account is protected by two-factor authentication.

“The exposure of Verizon account PIN codes used to verify customers, listed alongside their associated phone numbers, is particularly concerning,” explained UpGuard’s Dan O’Sullivan in a blog post.

NICE Systems is an Israel-based company that is known for offering wide-range of solutions for intelligence agencies, including telephone voice recording, data security, and surveillance.

According to the researcher, it is unknown that why Verizon has allowed a 3rd party company to collect call details of its users, however, it appears that NICE Systems monitors the efficiency of its call-center operators for Verizon.

The exposed data contained records of customers who called the Verizon’s customer services in the past 6 months, which are recorded, obtained and analyzed by NICE.

Interestingly, the leaked data on the server also indicates that NICE Systems has a partnership with Paris-based popular telecommunication company “Orange,” for which it also collects customer details across Europe and Africa.

“Finally, this exposure is a potent example of the risks of third-party vendors handling sensitive data,” O’Sullivan said.

“NICE Systems’ history of supplying technology for use in intrusive, state-sponsored surveillance is an unsettling indicator of the severity of this breach of privacy.”

Vickery had privately informed Verizon team about the exposure in late June, and the data was then secured within a week.

Vickery is a reputed researcher, who has previously tracked down many exposed datasets on the Internet.

Just last month, he discovered an unsecured Amazon S3 server owned by data analytics firm Deep Root Analytics (DRA), which exposed information of more than 198 Million United States citizens, that’s over 60% of the US population.

In March this year, Vickery discovered a cache of 60,000 documents from a US military project for the National Geospatial-Intelligence Agency (NGA) which was also left unsecured on Amazon cloud storage server for anyone to access.

In the same month, the researcher also discovered an unsecured and publicly exposed database, containing nearly 1.4 Billion user records, linked to River City Media (RCM).

In 2015, Vickery also reported a huge cache of more than 191 Million US voter records and details of as many as 13 Million MacKeeper users.

via:  thehackernews

Hackers Steal Payment Card and Biometric Data From Avanti Kiosks

Micro markets solutions provider Avanti Markets has informed customers that their personal, payment card and biometric data may have been stolen by cybercriminals who managed to infect some of its kiosks with malware.

According to the company, which serves 1.6 million customers across 46 U.S. states, the malware was designed to harvest information such as cardholder name, credit and debit card number, and expiration date.

Depending on how the kiosk was configured and the service used by the customer, the malware may have also stolen names, email addresses and even biometric information in the case of customers who utilized the fingerprint scanner to pay for their items.

Avanti said the breach was discovered on July 4 and its internal response team has taken measures to secure systems, including changing passwords. Payment processing systems have been shut down at some locations while the malware is being removed. The company has notified law enforcement and it plans on offering credit monitoring services to affected individuals.

“We continue to assess and modify our privacy and data security policies and procedures to prevent similar situations from occurring. For instance, we are in the middle of implementing an end to end encryption solution for all of our kiosks, and are working on expediting that implementation,” Avanti told customers. “Theft of data and similar incidents are difficult to prevent in all instances, however, we will be reviewing our systems and making improvements where we can to minimize the chances of this happening again.”

While the firm has not named the piece of malware used in the attack, security blogger Brian Krebs revealed that a July 7 blog post from Risk Analytics describing a PoSeidon(FindPOS) infection on a break room vending kiosk at a customer’s office was actually part of the Avanti campaign.

“This is a textbook example of an Internet of Things (IoT) threat: A network-connected device, controlled and maintained by a third party, which cannot be easily patched, audited, or controlled by your own IT staff,” said Risk Analytics’ Noah Dunker.

The security firm detected the malware on its customer’s network using known indicators of compromise (IoC) for PoSeidon.

via:  securityweek