STE WILLIAMS

Researchers have identified a new attack that uses computer-recovery tool LoJack as a vehicle for breaching a company’s defenses and remaining persistent on the network. The good news is that it hasn’t started specific malicious activity — yet.

Arbor Networks’ ASERT, acting on a third-party tip, found a subtle hack involving legitimate LoJack endpoint agents. The threat actors didn’t change any of the legitimate actions of the software. All they did was strip out the legitimate C2 (command and control) server address from the system and replace it with a C2 server of their own.

Richard Hummel, manager of threat research at NETSCOUT Arbor’s ASERT, says that the subtlety of the action means that most existing security software and systems will not provide any indication that something is going wrong. “If they’re running as an admin, they might not see it,” Hummel says. “This doesn’t identify as malicious or malware, so they might just see a subtle warning.”

The addresses of the new C2 servers are pieces of the analysis that led researchers to believe that the campaign is attributable to Fancy Bear, a Russian hacking group responsible for a number of well-known exploits. On initial execution, the infected software contacts on of the C2 servers, which logs its success. Then, the new LoJack application proceeds to … wait. It simply does what LoJack does, with no additional communication or activity.

Hummel says that the lack of activity and lack of steps to prevent legitimate activity means that most security software won’t recognize that the app is anything but legitimate.

Once in place, the nature of the LoJack system’s activities means that it’s very persistent, remaining in place and active through reboots, on/off cycles, and other disruptive events.

“This is basically giving the attacker a foothold in an agency,” Hummel says. “There’s no LoJack execution of files, but they could launch additional software at a later date.” And the foothold that the software gains is a strong one.

“If they’re on a critical system or the user is someone with high privileges, then they have a direct line into the enterprise,” Hummel explains, adding, “with the permissions that LoJack requires, [the attackers] have permission to install whatever they want on the victims’ machines.”

There is, so far, nothing about the attack that contains a huge element of novelty. As for the code, Hummel says that this particular mechanism for attack has been around since 2014, when the software that is now LoJack was called Computrace. Even then, Hummel says, “researchers talked about how LoJack maintains its persistence.”

And while Hummel’s team has suspicions about infection mechanisms, they aren’t yet sure what’s happening. “We did some initial analysis on how the payload is being distributed and other Fancy Bear attacks, and we can’t verify the infection chain,” Hummel says, though he’s quick to add, “We don’t think that LoJack is distributing bad software.”

With stealth and persistence on its side, how does an enterprise prevent this new attack from placing bad software on corporate computers? Hummel says everything begins with proper computer hygiene. “Users will be prompted for permission warnings — don’t just blow by them,” he says.

Next, the IT security team can scan for five domains currently used by the software:

• elaxo[.]org
• ikmtrust[.]com
• lxwo[.]org
• sysanalyticweb[.]com (2 forms)

Each of these domains should be blocked by network security mechanisms.

It’s rare to have warning of an active infection method prior to damaging attacks using the infection target. Organizations now have time to learn about the tactic and disinfect compromised endpoints before the worst occurs.

Related Content:

• Destructive and False Flag Cyberattacks to Escalate
• 8 Nation-State Hacking Groups to Watch in 2018
• Lazarus Group, Fancy Bear Most Active Threat Groups in 2017
• Why OAuth Phishing Poses a New Threat to Users

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/lojack-attack-finds-false-c2-servers/d/d-id/1331691?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A new study out today shows that DevSecOps could stand to use a healthier dose of OpSec, as many DevOps tools are left exposed on the public Internet with little to no security controls.

So much of the education about the intersection of DevOps and security focuses on application security testing and secure development practices. But DevSecOps is about more than just securing the software product itself. It’s also crucial to protect the “factory” that produces those applications — namely, the development infrastructure and DevOps toolchain.

Unfortunately, according to a new study conducted by researchers with IntSights, a statistically significant number of DevOps organizations are falling down on that second part of the equation.

“Given DevOps tools sit in the cloud, they are more vulnerable to reconnaissance by hackers,” says Alon Arvatz, co-founder of IntSights. “As opposed to traditional IT tools and servers that are still protected by the company network, a misconfigured DevOps tool will expose its data directly to the Internet, meaning hackers don’t need to use any special hacking tools, just simple scanning tools that are available online.”

Arvatz and his team examined nearly 26,000 URLs of different DevOps tools and servers from a range of organizations and did a simple test by trying to connect to them through a browser.

“No fancy attack tools, or port scanning, or any preliminary data, except for using open OSINT [open source intelligence] tools and websites to create the list,” the report explains.

They found that more than 23% of those tested were accessible from the Web, with a range of access levels.

“Some were totally exposed without any user/password combination, exposing company data, user lists, internal server names, etc.,” the report explained. “Most were protected with a simple login page, and a minority with a more robust cloud access security broker.” 

The trouble is that even those tools and servers that did have nominal security controls in place still left enough breadcrumbs and openings to make it easier for attackers to gain entry. For example, many organizations used DevOps tool names for a Web-facing server — such as Jenkins, Kibana, Trello, Jira, and so on. Additionally, most tools don’t have built-in multifactor authentication, leaving the security of the system up to a simple username and password combo.

Ideally, many standard technologies and practices of DevOps can be used advantageously for security purposes. For example, the use of infrastructure as code and automation of systems can provide a very efficient means for helping organizations consistently lock down their development and production application infrastructure. 

“Because we have this infrastructure as code, we’re getting a lot of reuse,” explains Paula Thrasher, director of digital services for General Dynamics, a large federal IT integrator, who says that prior to a DevOps-oriented pipeline, her teams could expect 60% reuse of design patterns and infrastructure. Now that number is pushing 90%. “Which basically means 90% of the stuff in our production is a reusable standard, and not a special-snowflake bespoke server. That’s huge, because it just takes down the attack surface.”

Of course, on the flip side, that means that one mistake is amplified across an entire organization. As an organization scales, a misconfiguration makes it into every single instance a team fires up rather than just the one in a single insecure bespoke server. So, the stakes are higher. 

Arvatz explains that DevOps can do a lot to help raise security posture in an organization and most of the tools involved have the capability to be used securely. But at the same time, organizations need security-conscious administrators in charge.

“Some [DevOps] tools do offer inherently higher security in their basic configuration, and most cloud platforms offers robust security defenses, but some tools rely entirely on their operator knowledge and expertise,” he says. “The general shortage of experienced employees in the DevOps and security fields and the fact that most if not all tools are cloud-based make them prone to human errors.”

In addition to renaming DevOps tools on Web-facing servers and implementing multifactor authentication, Arvatz and his team suggest a number of other best practices for these tools. These include using proxy servers, stopping the use of default ports, and meticulously keeping up on the patching of infrastructure. They also suggest blocking access to the servers altogether from the Web when feasible, though they acknowledge that may not always be practical.

Related Content:

• 10 Security Innovators to Watch
• Trust: The Secret Ingredient to DevSecOps Success
• DevSecOps: The Importance of Building Security from the Beginning

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Article source: https://www.darkreading.com/operations/are-you-protecting-your-devops-software-factory/d/d-id/1331692?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A rare hands-on analysis of the antivirus software that North Korea provides its citizens shows the proprietary tool is based on a 10-year-old version of Trend Micro’s AV scanning engine that also was customized to ignore a specific type of malware rather than flag it.

Researchers at Check Point today published new research from their exclusive study of the so-called SiliVaccine AV program that is used only inside the cloistered nation. North Korea blocks its citizens from the public Internet and runs its own intranet; only North Korea’s ruling elite are allowed access to the global Internet.

Check Point obtained a sample of the malware from a freelance journalist specializing in North Korean technology who had received a suspicious email message with a link to the AV program. The researchers say it’s unclear just how North Korea got its hands on Trend Micro’s AV engine, but since Trend doesn’t do business with North Korea, it’s most likely a case of stolen intellectual property.

Jon Clay, director of global threat communications at Trend Micro, told Dark Reading that the software was not stolen via a hack of Trend Micro systems. Rather, Trend Micro suspects its software was pirated somehow. “We strongly believe this is a case of software piracy, in which our software is being used illegally. North Korea has been repackaging software for sale locally for years, including Adobe Reader in 2013,” for example, he says.

“This was not a data breach and no evidence suggests they are using stolen source code,” he says. “It appears they obtained a public version of our scan engine DLL and modified it.”

What is clear is that the North Korean AV was built to appear as its own software. “Every aspect was well-written and they had a lot to hide … the signatures are encrypted and the fields are protected,” says MichaelKajiloti, malware research team leader at Trend Micro.

SiliVaccine uses Trend-Micro AV pattern files but renamed Trend’s malware signature names with names of its own, for example, and the Trend Micro engine’s identity is well-masked, according to Check Point.

“They went the extra mile to hide the fact they stole intellectual property,” says Mark Lechtik, one of the Check Point security researchers who studied SiliVaccine.

But Trend Micro’s Clay maintains that North Korea’s SiliVaccine does not have access to Trend Micro’s AV signature updates, and that the AV program instead is using homegrown signatures of its own.

Malware Whitelist

SiliVaccine operates with another hidden twist: it whitelists a specific malware signature that Trend Micro identifies as MAL_NUCRP-5, which detects files that employ behavior patterns used in various types of malware, including fake antivirus installers and droppers, Check Point found. That may allow the North Korean government to run malware on its citizens’ machines without their knowledge, possibly for some type of surveillance, according to the researchers. “Or the signature gives them the option to create any malware they want to target citizens and build it in such a way that the AV will never catch it,” says Kajiloti.

Lechtik says Check Point’s team concluded that the development of SiliVaccine has been ongoing for several years. “I highly doubt it was reverse-engineered,” he says. “We think its more likely that it’s much more a part of their” getting access to the software, he says.

Check Point shared its findings with Trend Micro, which confirmed that the software uses a module based on an older version of its AV scanning engine from more than ten years ago – VSAPI Scan Engine 8.9x – and that no source code is included in the software. Trend believes it’s a case of software piracy, and that the fraudsters reverse-engineered the software as its own.

“It appears that a compiled code library was illegally copied, repacked, and then wrapped with additional application code not originating from Trend Micro to build a normal AV scanning application called SiliVaccine,” Trend Micro’s Clay says. “The authors of the SiliVaccine product intentionally removed a specific heuristic detection in their product’s version of the pattern file.”

In the end, there doesn’t appear to be any risk to legitimate users of Trend Micro’s AV software since it’s such an old version, and SiliVaccine has its own encrypted files that can’t be used by existing Trend Micro AV products. “The result is that it would be impossible for a Trend Micro product to accidentally or even intentionally use a SiliVaccine modified pattern file since Trend Micro products perform pattern integrity checks,” Clay says.

Clay says the incident suggests that North Korea has programmers with reverse-engineering skills. “As such, any software vendor should be concerned that North Korea could do the same with their code.”

It also indicates they didn’t want to develop their own AV scanner: “They needed an AV scanner and did not want to put in the time or effort to develop their own so they illegally obtained a publicly available scanner and modified it for their own use,” Clay says.

Dark Hotel Clue

Journalist Martyn Williams in July 2014 received a sketchy email from a purported Japanese engineer with a news tip that included a Dropbox-hosted zip file with SiliVaccine software and a file posing as a patch for the AV program. The phony patch turned out to be a camouflaged piece of JAKU malware, which is a Trojan dropper which has been tied to DarkHotel, a North Korean cyber espionage group.

The JAKU file was also signed with a certificate from the same “company” that had also signed malware files for the Dark Hotel nation-state hacking group thought to be out of North Korea.

“We can’t really say the JAKU bundled in was part of SiliVaccine; it might be … but more likely Martyn [Williams] was the target here” of a cyber espionage campaign, Lechtik says.

JAKU to date has infected 19,000 victims mostly via malicious BitTorrent share files. It’s typically known for targeting and monitoring individuals in South Korea and Japan who work for non-governmental organizations, engineering firms, government, as well as academia.

Related Content:

• North Korea Ramps Up ‘Operation GhostSecret’ Cyber Espionage Campaign
• North Korea-Linked Cyberattacks Spread Out of Control: Report
• Lazarus Group Attacks Banks, Bitcoin Users in New Campaign
• 8 Nation-State Hacking Groups to Watch in 2018

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

Article source: https://www.darkreading.com/endpoint/privacy/north-koreas-av-software-contains-pilfered-trend-micro-software-/d/d-id/1331686?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Part 2 of our series DPO’s Guide to the GDPR Galaxy 

Today, we’re mapping our GDPR journey and focusing on the key steps to implement the basic building blocks of a “privacy by design” program.

1. Assemble your privacy building blocks. If you don’t already have a foundational privacy program, now is the time to roll up your sleeves and start one. While we’ve been focusing on GDPR, chances are this isn’t the only privacy law your organization is subject to, which is why it’s critical to set clear goals. The very first goal you should make is creating the privacy vision and mission statement. The intention is to create a clear, concise message to communicate the purpose of the program to all key stakeholders and to circulate it and gain buy-in from your business executives.

2. Define the scope of your privacy program. Once you’ve established your privacy vision and mission statement, you can begin to determine the program scope. If GDPR is your sole focus, then you would want to find out if you are in scope for GDPR by reviewing the 99 articles that comprise the law. For organizations outside of the European Union, one rule of thumb to follow here is that if you process data that belongs to EU citizens, then your organization falls under GDPR. From there, you must figure out if you are a controller (the natural or legal authority that, either alone or jointly, determines the purposes and means of processing personal data), processor (the natural or legal authority that processes personal data on behalf of the controller), or possibly both.

3. Build your privacy and GDPR army. Start by referencing GDPR Articles 37–39 to determine if you need to appoint a data protection officer (DPO). If after reviewing those articles, your company decides to appoint a DPO, even if not legally required to, you must then adhere to GDPR requirements. If you don’t need a DPO, it’s a good idea to appoint a privacy champion. Ensure your DPO or privacy champion is empowered to execute on the program vision and mission statement and that this person has the support of the C-suite.

GDPR responsibilities don’t solely rest on the shoulders of your DPO or privacy champion, so you’ll need to look at all affected areas of your organization. With GDPR, that’s probably every department if you have employees in the EU. There are many resources on the internet to help you with this decision if you need a quick gut check.

Begin building support and gathering information from key internal partners such as security, human resources, legal and information technology teams, and any other relevant departments. Work with your partners/stakeholders to help them understand why it’s necessary to document how and what type of data flows through each group in order to meet the rigorous records of processing activities requirements in GDPR Article 30.

4. Next stop on your privacy program road map — creating an actual road map! Every program needs a framework to build from and expand over time. Frameworks help provide structure and guidance such as requirements in policy or process. They help reduce risk and show compliance with best practices. Some examples of privacy frameworks to reference and leverage when building your own include, but are not limited to, Privacy by Design, Fair Information Practice Principles (FIPPs), and ISO 29100 Privacy Data Protection Standards.

As you start to work with your internal technical stakeholders, it’s imperative they are committed to building privacy into every aspect of the product. Walk them through GDPR Article 25, which focuses on data protection by design and by default, and be sure to include security in the conversation because you can’t have privacy without security. Baking those in from the very beginning is an important foundational piece of a solid privacy program and of GDPR. As a best practice (and per GDPR Article 32), the controller and processors must implement appropriate technical and organizational measures to ensure a level of security that is appropriate to the risk.

As a key part of your road map, privacy impact assessments and, when appropriate, data protection impact assessments (DPIAs) must be performed if processing data could result or lead to identity theft, damage to a person’s reputation, discrimination, or any other sort of physical, material, or nonmaterial damage. (For more information on DPIAs, see GDPR Article 35.)

5. Establish processes and metrics for accountability and benchmarking. Other elements that are key to a successful privacy and security program include identifying and establishing metrics and instituting a life cycle management process (think software development life cycle but for privacy) to ensure that controls are working as designed and are effective to continue to support and maintain the program. Additionally, there must be measures in place to respond to incidents and events such as breaches, legal holds, and requests for information.

At any point in the process of building or enhancing your program, you may decide to perform a gap assessment against your requirements or hire an independent third party to carry out the assessment. Performing a gap assessment against your privacy framework will highlight the areas that still need addressing. There is nothing wrong with self-assessments; however, using a third party helps demonstrate to customers that the program has been reviewed by independent, impartial parties.

Related Content:

• DPO’s Guide to the GDPR Galaxy
• GDPR Compliance: 5 Early Steps to Get Laggards Going
• How GDPR Forces Marketers to Rethink Data Security
• GDPR: Ready or Not, Here It Comes

Jen Brown is Sumo Logic’s compliance and data protection officer (DPO) and is responsible for leading compliance, risk, and privacy efforts for the company, including GDPR, PCI DSS, ISO 27001, HIPAA, SOC2, and FedRAMP, as well as several other regulations. Prior to Sumo … View Full Bio

Article source: https://www.darkreading.com/endpoint/a-data-protection-officers-guide-to-gdpr-privacy-by-design/a/d-id/1331640?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

When it comes to the password behaviors of computer users, there’s bad news and there’s more bad news.

A new survey by LogMeIn of some 2,000 individuals in the United States, Australia, France, Germany, and the UK has revealed what can only be described as broad apathy among a majority of users on the issue of password use.

Though 91% of the respondents profess to understand the risks of using the same passwords across multiple accounts, 59% said they did so anyway. For 61%, it is the fear of forgetfulness that was the primary reason for password reuse. Fifty percent say they reuse passwords across multiple accounts because they want to know and be in control of their passwords all the time.

The situation is equally depressing around the issue of password change. More than half – 53% – of the respondents confess to not changing their passwords in the past 12 months even though they were aware of the risks, and despite news of a data breach involving password compromise. Not only did nearly six in 10 of the users polled use the same password across accounts, they rarely if ever change the password over time. In fact, 15% of the respondents say they would rather do a household chore or sit in traffic (11%) than change their passwords.

Exacerbating the situation is the sheer number of online accounts that users have these days. Nearly eight in 10 (79%) of the LogMein survey takers have between one and 20 online accounts for work and personal use.

Forty-seven percent don’t do anything differently when creating passwords for personal and work use; less than one-fifth (19%) create more secure passwords for work. A surprisingly high 62% reuse the same password for work and personal accounts.

The LogmeIn survey results are another reaffirmation of the notoriously poor password behaviors of online users. Previous studies have revealed a similarly lackadaisical attitude when it comes to selecting and managing passwords controlling access to online accounts.

Default and easily guessable passwords (12345 anyone?) have led to countless individual and corporate account takeovers and compromises in recent years, and prompted widespread calls for a move away from password-based authentication mechanisms altogether.

“I’d say the biggest surprise is that even though people are aware of the major cyberattacks and increases in costly data breaches, it’s still not translating to better password security practices,” says Sandor Palfy, CTO of identity and access management at LogMeIn.

Risky Business

This password neglect is creating huge risks and undermining overall security both for individual users and for employers. “The lesson for enterprises is most of their employees do not recognize the critical role that passwords have in protecting their personal and work information,” Palfy says.

Many employees seem unaware or uncaring of the fact that weak passwords can potentially put the organization at risk, he says. “Enterprises need to rethink security policies and implement ways to centralize, automate, and securely store employee passwords.”

The most common mistake that organizations can make is to underestimate the danger posed by weak passwords. The reality is that each password is like an entry point into the enterprise and needs to be secured like any other entry point. “Organizations need to take steps to both regularly educate and communicate password best practices to all employees, including how and why to use strong passwords,” Palfy says.

Organizations also need to ensure they have the right password management tools and processes for enforcing strong password practices across the enterprise. “The organizations that can rapidly and effectively address that challenge are well-positioned to keep their businesses safe,” Palfy notes.

Related Content:

• ‘Starwars’ Debuts on List of Worst Passwords of 2017
• Millions of Office 365 Accounts Hit with Password Stealers
• Passwords: 4 Biometric Tokens and How They Can Be Beaten

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

Article source: https://www.darkreading.com/informationweek-home/password-reuse-abounds-new-survey-shows/d/d-id/1331689?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple