Monthly Archives: July 2017

Mystery “FruitFly” Malware Infected Macs For Years, No One Noticed It Until 2017

Short Bytes: Two malware which go by the name FruitFly and FruitFly 2 have been discovered over the course of the last few months, starting Janaury this year. The malware, known to have infected hundreds of Macs, are being assumed as surveillance tools instead of some ransomware or some other type of malware.

Adistant malware, designed to infect Apple’s macOS, is leaving a bewildered look on the face of the security researchers. The first variant of the malware called FruitFly, aka the first Mac malware of 2017, was discovered earlier this year by the security firm Malwarebytes and analyzed by Thomas Reed.

Back then, an IT admin at the firm had spotted some unusual outgoing traffic from a particular Mac. The “simplistic” malware consisted of only two files, carrying some “ancient” obfuscated Perl. Some of the code even dates back to 1998, before the existence of macOS. The malware could take screenshots, log keystrokes, spy through web cams, and it was known to have targeted some biomedical research centers as well. According to Malwarebytes, an update was released by Apple to take care of the same.

Fast forward a few months, another malware with similarities to FruitFly was detected by ex-NSA hacker Patrick Wardle who is now a security researcher at Synack. Known as FruitFly 2, it’s assumed that the malware is in existence for a decade or so, undetected by many antivirus software.

During the breakdown, Wardle found that FruitFly 2 could connect to a C&C server and send the data back to to the hackers, Motherboard reports. Backup servers were also present if some issues occur with the primary ones. More than 400 victims were discovered when Wardle infected his virtual machine after registering a domain that hackers planned to use as a backup.

FruitFly mac malwareList of detected IP addresses. (Credit: Patrick Wardle/Twitter)

He could see the IP addresses of the victims and even the names of the Mac computers. However, this number might increase as Wardle didn’t have access to all the C&C servers used to control the malware. Wardle contacted law enforcement and reported his findings. He has also talked about his findings at this year’s Black Hat conference.

Both Wardle and Reed are unaware of the origins of malware, who made it, and what is its purpose. In the case of the Wardle, around 90 percent of the FruitFly 2 victims are living in the US or Canada.

The possibility of the malware being baked by a federal body gets thinner as the malware isn’t sophisticated enough and it hasn’t targeted any high-profile individuals, writes Motherboard. FruitFly 2 isn’t a ransomware and it doesn’t log keystrokes. But, according to Wardle, both FruitFly malware might have been designed to perform surveillance.

FruitFly 2 is also written in Perl and allows the attacker to control the mouse and keyboard remotely. It even notifies the attacker when the victim starts using the mouse and keyboard.

Wardle said that malware seems to have been to target specific individuals, maybe normal Mac users or families, but the intentions are unclear. He calls the situation “worrisome.” He warns Mac users to be cautious while using their machines. “Just because they have a Mac, it doesn’t mean that they’re safe.”


via:  fossbytes

NIST SP 800-171 Deadline at End of 2017 – Is Your Organization Ready?

The National Institute of Standards and Technology (NIST) has released Special Publication 800-171. The document covers the protection of Controlled Unclassified Information (CUI) in Nonfederal Information Systems and Organizations.

The document was designed to provide guidance on ensuring that all systems that process, store, or transmit CUI information are secured and hardened. Compliance to the 800-171 standard is enforced by a set of technical policies. NIST SP800-171 outlines those policies. A deadline to comply or to report delays in compliance has been set for December 31, 2017.


Executive Order 13556 (11/10/2010) designated the National Archives and Records Administration (NARA) as the Executive Agent to implement the CUI program, for which the Information Security Oversight Office (ISOO) of the National Archives and Records Administration is responsible. In April of 2013, ISSO issued a memorandum to government agency leads on the management of the CUI program.

In September 2016, ISOO released notice 2016-01 outlining the implementation guidance for CUI, and a later notice 2017-01 was issued in June of 2017 with recommendations for implementation of the CUI program. Below are excerpts of that notice (2017-01).

A bit of background

“The Information Security Oversight Office (ISOO) exercises Executive Agent responsibilities for the CUI Program. In consultation with the Office of Management and Budget and affected agencies, on September 14, 2016, ISOO issued CUI Notice 2016-01, ‘Implementation Guidance for the Controlled Unclassified Information Program.’ CUI Notice 2016-01 outlines the phased implementation deadlines for agencies and describes the significant elements of a CUI Program.”

Program management

“ISOO’s memorandum to the heads of executive departments and agencies, “Appointments of Senior Agency Official and Program Manager for the Controlled Unclassified Information (CUI) Program Implementation,” dated April 11, 2013, requested that agencies affirm or update their initial designations of their CUI Senior Agency Official (SAO) and also requested that they assign a CUI Program Manager (PM).”


Anyone (individual or business/contractor) who processes, stores, or transmits information (that falls into one of many CUI categories) for or with federal or state agencies is impacted. This includes all governmental contractual relationships.

A list of categories of CUI information has been made available by NARA here.


There are 14 categories of security requirements that must be met. Each category has a unique set of policy tests in which affected programs must meet.

  1. Access Control
  2. Audit and Accountability
  3. Awareness and Training
  4. Configuration Management
  5. Identification and Authentication
  6. Incident Response
  7. Maintenance
  8. Media Protection
  9. Physical Protection
  10. Personnel Security
  11. Risk Assessment
  12. Security Assessment
  13. System and Communications Protection
  14. System and Information Integrity

For a complete list of policy tests included under each of the 14 categories, please refer to the NIST SP800-171 web page:

To find out more about NIST SP 800-171, join me, David Henderson, and federal security and compliance expert Sean Sherman for a webinar on July 27th to learn:

  • What the regulation means for you
  • How this standard is enforced though FAR and DFAR
  • How Tripwire’s security solutions map to the new 800-171 control families
  • How to use Tripwire to prove and maintain compliance with this new standard

You can register for the webcast here.

Whilst you wait, you can learn more about how Tripwire solutions can help you meet the requirements NIST 800-171 here.

Or you can view the current list of 800 policy/platform combinations that are available to help you continuously monitor, assess and harden your systems here.


via:  tripwire

Update Your iPhone, iPad To Squash Dangerous Wi-Fi Bug

Apple  made a number of security updates to its iOS mobile operating system, including a fix for a Wi-Fi chip vulnerability that could let hackers gain wireless access to iPhones and iPads.

The iOS 10.3.3 update addresses nearly four dozen security flaws, one of which, called “Broadpwn,” lies in the Broadcom Wi-Fi chip used in many iPhones and Android devices. Google announced an Android fix for Broadpwn earlier this month. Apple’s patch is available for the iPhone 5 and later, 4th-generation and later iPads, and the 6th-generation iPod touch.

The vulnerability could allow a remote actor to trigger a memory corruption error via Wi-Fi on a user’s mobile device, according to details on Broadpwn from Security Tracker. That error could then enable the hacker to execute arbitrary code on the device without any actions by the user.

Chip Vulnerability on ‘Millions’ of Devices

Apple credits discovery of the Wi-Fi vulnerability to Nitay Artenstein, a security researcher with Exodus Intelligence. Artenstein is scheduled to discuss his findings later this month during a briefing at the Black Hat information security conference in Las Vegas.

“Remote exploits that compromise Android and iOS devices without user interaction have become an endangered species in recent years,” Artenstein said in a description of his coming Black Hat presentation. “Such exploits present a unique challenge: Without access to the rich scripting environment of the browser, exploit developers have been having a hard time bypassing mitigations such as DEP and ASLR.”

Rather than targeting a mobile device’s operating system, though, Broadpwn takes aim at the Wi-Fi system on chip (SoC) that’s used to handle a device’s wireless connectivity. The vulnerability exists on “millions” of Android and iOS devices featuring the Broadcom SoC, Artenstein said.

“The Broadcom BCM43xx family of Wi-Fi chips is found in an extraordinarily wide range of mobile devices — from various iPhone models, to HTC, LG, Nexus and practically the full range of Samsung flagship devices,” he noted.

‘Critical’ Vulnerability, Easy To Deploy

In its July 5 Android Security Bulletin, Google described the severity of the Broadcom vulnerability as “critical.” The U.S. Computer Security Resource Center’s National Vulnerability Database, which published details about the vulnerability early last month, noted that taking advantage of the security flaw was not complex.

Wi-Fi SoCs are designed to handle a broad range of processing tasks related to wireless networking, Google security researcher Gal Beniamini wrote in an April blog post for Project Zero, Google’s research program aimed at finding zero-day exploits. While such SoCs help to reduce power consumption and free up mobile device operating systems to focus on other tasks, they come with a cost, he added.

“Introducing these new pieces of hardware, running proprietary and complex code bases, may weaken the overall security of the devices and introduce vulnerabilities which could compromise the entire system,” Beniamini said, adding that Broadcom’s Wi-Fi SoCs are the most common Wi-Fi chipsets used on mobile devices.

Beniamini noted that Broadcom has said newer versions of its Wi-Fi SoC use a memory protection unit, “along with several additional hardware security mechanisms.” He called such improvements “a step in the right direction.”


via:  enterprise-security-today

The biggest cybersecurity breaches of 2017 so far

What can we learn from the latest cybersecurity breaches

The frequency and impact of cybercrime has been steadily escalating for several years now, but 2017 has been one of the worst– at least in terms of media headlines. Worse still, we’re only half way through the year.

So what has happened, and what can you learn?

NSA hacking tools are stolen and leaked

The National Security Agency – the US body responsible for “intelligence” – maintains an impressive array of tools that allow their analysts to hack computers belonging to foreign spies, terrorists or suspected criminals. Many of these tools use vulnerabilities that had were previously unknown even to the most successful cybercriminals.

However, these tools were stolen and leaked online earlier this year. Details of the exploits were also published on Wikileaks, throwing a spotlight onto US intelligence activity. Once the NSA tools were leaked, hackers immediately began to use them against innocent people.

How to protect yourself:

The NSA tools work by exploiting gaps and bugs in operating systems and software, like Windows 8 or Apple’s MacOS. You should regularly check for updates, and install patches as quickly as possible – this closes the loopholes used by the hackers, rendering their malware ineffective.

The WannaCry outbreak

Ransomware has been gaining popularity in recent years as a way to extract extort money from people by infecting their computer and encrypting their files. The only way to recover data is to pay a ransom to the hackers.

In May, WannaCry went global, infecting thousands of computers across the world. In the UK, several NHS trusts were affected, taking clinical systems offline, and forcing the cancellation of planned operations as engineers tried to reverse the damage.

Although the source of the WannaCry infection remains in dispute, security analysts agree that the malware uses one of the vulnerabilities exposed in the NSA theft. Some believe that the outbreak was planned by the North Korean government as a way to raise revenue – however the malware was more effective than expected, leading to the global outbreak.

The Petya outbreak

Just one month after WannaCry wreaked havoc, another malware variant burst onto the scene. Using the same NSA exploits, Petya (also known as NotPeya, Nyetya and Goldeneye) managed to compromise several major companies, including pharmaceutical giant Merck, shipping company Maersk and the Russian oil firm Rosnoft.

Unlike WannaCry which was global in its reach, Petya appears to have been targeted at businesses in Ukraine. The central bank, several power companies and the public transport network were particularly badly affected.

How to protect yourself:

The success of the NSA hacking tools relies on security vulnerabilities that are not known by a software vendor, and have not yet been repaired, called zero day exploits. Every computer is in danger of being exploited until these loopholes are closed.

You can improve protection by installing an anti-malware tool

Anti-malware cannot detect zero day exploits, but it can recognise malware by the way it acts – and block it automatically before damage is done to your data.


In fact, you can (and should) install an anti-malware tool. Download one now, and you’re well on the way to protecting your data through the rest of 2017.


via:  pandasecurity

Patching Not Enough to Stop Petya

Voluminous amounts of information have already been disseminated regarding the “Petya” (or is it “NotPetya”?) ransomware that hit the Ukraine hard along with organizations such as “the American pharmaceutical giant Merck, the Danish shipping company AP Moller-Maersk, the British advertising firm WPP, Saint-Gobain of France, and the Russian steel, mining and oil firms Evraz and Rosneft”.

Not surprisingly, nearly every Petya write-up references the WannaCry outbreak that wreaked havoc about a month-and-a-half ago. This is reasonable given the recentness of WannaCry and that both malwares are ransomware known to leverage the EternalBlue exploit against patched vulnerability MS17-010.

Amidst this deluge of information (and misinformation), we wanted to make sure that the association of Petya with WannaCry did not obscure some important differences. In particular, the EternalBlue-based propagation mechanism, mitigated by patching MS17-010, is not the only method employed by Petya to spread. Another propagation method employed by Petya is not thwarted by simply patching. According to Kaspersky, once Petya has compromised a machine, it will begin to hijack local credentials from the Windows Local Security Authority (lsass.exe) then leverage those credentials via PsExec or WMI in an attempt to remotely compromise other systems on the local network. In many enterprises, this activity will not be blocked and is likely to fly under the radar as typical remote administration activity. Afterall, PsExec is a legitimate Windows SysInternals command line tool and WMI stands for Windows Management Instrumentation. If a widely used administrative credential is compromised, it could very quickly be game over for many systems regardless of whether the patch for MS17-010 has been applied or not.

Another important difference between Petya and WannaCry is that there is no “KillSwitch” for Petya. Indeed, contrary to many reports, ASERT has found no evidence that Petya has any form of command-and-control.

In conclusion, avoid any false sense of security that may derive from patching MS17-010 and heed the longstanding calls for appropriate network segmentation to limit the damage from Petya and other malware. Finally, note that the following ET Pro rules appear to fire on Petya propagation behavior and, thus, can be used for detection using network security products such as Arbor Networks Spectrum:

  • 2001569 – ET SCAN Behavioral Unusual Port 445 traffic Potential Scan or Infection
  • 2012063 – ET NETBIOS Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference
  • 2024297 – ET CURRENT_EVENTS ETERNALBLUE Exploit M2 MS17-010


via:  arbornetworks

Another AWS cloud data leakage due to misconfiguration

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

macOS users beware: A new and nearly undetectable malware is on the rise

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, 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

‘HighRise’ Android Malware Used by CIA to Intercept SMS Messages

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


PCI Compliance: For Payment Card Industry, Now More Than Ever

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.


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

Only 50% of CIOs improve cyber security after WannaCry

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