STE WILLIAMS

6 Best Practices for Managing an Online Educational Infrastructure

Universities must keep pace with rapidly changing technology to help thwart malicious hacking attempts and protect student information.

Retailers, healthcare providers, and social media platforms may be the first organizations that come to mind regarding consumer data security. However, other organizations — including institutions of higher education — are also tasked with the responsibility of protecting their customers’ sensitive and valuable personal information from cybercriminals.  

Because increasing numbers of students opt for some level of distance learning, today’s institutions of higher education are collecting vast amounts of virtual data. And as in any industry, universities must keep pace with rapidly changing technology to help thwart malicious hacking attempts and protect student information. 

This is especially important for universities that serve primarily nontraditional students — for example, adults taking online classes. To improve validation of the student population, universities collect and store information ranging from physical addresses, email addresses, Social Security numbers, birth dates, and more. Protecting all of this data warrants a cybersecurity strategy that exceeds students’ expectations for a quality learning experience that extends further than typical security.

We have experienced protecting all of this data first hand at University of Phoenix. Last year, the university taught approximately 123,900 students, the majority of which were working adults who primarily took their classes online. These students may live states or even countries away and must trust their information with an institution they may have never physically seen or visited.

While the basic principles of security create the foundation for an efficient experience, protecting data can be the unseen — and often unnoticed — component of a satisfactory college experience. A conscientious balancing act comes into play when the quality that a student sees and experiences — namely, availability, and accessibility — are considered. Personally identifiable information (that is, information to identify and contact a student) must be accessible for the student to review and update at all times but simultaneously remain secure from unauthorized access and unintended use. Any information that identifies a person (for example, a photo, name, or email address) is considered sensitive data and should be handled as such.

This creates a delicate balance between accessibility and security. To reach this equilibrium, the network must be resilient and self-healing to provide availability to students where and when it is needed. When it comes to managing an online security infrastructure for an educational institution, here are six important cybersecurity components to keep in mind.

1. Create a Hierarchy When Logging Data
Security logging of systems, applications, and network devices is critical when investigating suspicious activity, from attacks to user activity. With tens or even hundreds of thousands of students enrolled in online courses at any given time, the number of logs that are generated at an online institution can become daunting. Based on the amount of security an organization has to have for its system, a balance must be struck between generating loads of logs and analyzing the most important data. It’s important to focus on the logs that are most likely to give you data and information that could reveal suspicious or fraudulent activity.

2. Establish a Risk Baseline for Network Monitoring
A risk baseline must be established so analysts can differentiate between normal and suspicious activity on the network. Establishing what is normal, ordinary, and healthy behavior on the network is crucial, making it easy to flag any excessive or exceptional behavior and quickly understand if there is a current threat of or an actual cyberattack.

3. Integrate Effective Identity Management Solutions
Identity management should provide a pleasant user experience while protecting sensitive student information. Identity management is a constant balance between security and convenience. An organization could have the most secure network in the world, but it will not be used if it is too difficult to access. The best solution is multifactor authentication, to prove a valid user by password, using a coded token, or through a fingerprint or an iris scan. The most secure systems require all three of these elements and accomplish the goal of establishing the user without making the process too onerous.

4. Involve Students in Communication and Training
A security awareness program must be well communicated to keep students informed about attacks targeting people (phishing, for example). This typically takes the form of an annual training program that users must complete so that organizations have a record and a confirmation of users understanding the security basics, including but not limited to phishing, passwords, etc. When users have accounts that are safe, the organization has fewer ways for hackers to enter its system.

5. Layer Your Defense for Optimal Protection
Defense should be in layers because no single solution can defend against everything. Each layer must be appropriate for the data and systems it’s protecting. Different kinds of cyberattacks need different solutions. Multiple layers of defense provide varied solutions. It also is important to communicate with the Community Emergency Response Team (CERT) and all security vendors. This will provide the most up-to-date information and alert professionals to bigger attacks that may be happening across the nation and worldwide.

6. Expect Failure — and Have a Backup
Systems sometimes fail, which requires a documented and tested incident-handling process to meet and exceed minimum recovery time objectives. It seems like common sense, but when systems fail, an organization needs to have a backup plan. For example, if a server goes down, there should be a plan in place to take care of users. This should include overall instructions, what information they are able to access, and the recovery time on fixing the system. In some cases, there may be a need to have secondary equipment available for use and alternate ways to access data servers.

Related Content:

  • 7 Places Where Privacy and Security Collide
  • Privacy Futures: Fed-up Consumers Take Their Data Back
  • Cryptographic Erasure: Moving Beyond Hard Drive Destruction
  • Cybersecurity at the Core

Jamie Smith is the Chief Information Officer for University of Phoenix. Smith holds a Bachelor of Arts in Business Administration from Iowa State University and has served as a board member for Junior Achievement and the Memphis IT Council.
Larry Schwarberg is the Chief … View Full Bio

Article source: https://www.darkreading.com/endpoint/privacy/6-best-practices-for-managing-an-online-educational-infrastructure/a/d-id/1333552?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Google: G Suite Now Alerts Admins to Data Exfiltration

New additions to the G Suite alert center are intended to notify admins of phishing and data exports.

Google is ramping up the G Suite with new security alerts designed to notify administrators of Gmail phishing attacks and intruders’ data exfiltration processes.

Only admins are affected by the G Suite changes, which also include a new alert deletion option and a link to audit logs for G Suite Business and Basic domains, Google explains in a blog post, according to the company. Phishing alerts will generate notifications for suspicious looking emails in Gmail inboxes; admins in G Suite Enterprise domains can investigate them and, if necessary, remove bulk messages.

The “data export initiated” alert comes in when a domain data export begins, and is designed to help notify admins of potentially malicious activity. Admins can also delete alerts as they are resolved or are no longer needed. Audit logs provide data on past user activity related to alerts.

Users need to be a super admin or alert center-delegated admin to use G Suite’s alert center, which serves as a single place for admins to view security-related notifications, alerts, and actions across G Suite. Admins can access the alert center by going to Admin console Menu Security Alert Center, and access the Help Center to learn more about the tool.

Read more details here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/google-g-suite-now-alerts-admins-to-data-exfiltration/d/d-id/1333627?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Consumers Demand Security from Smart Device Makers

Poll shows individuals want better security from IoT device manufacturers as connected products flood the market.

More than 90% of people want manufacturers to step up their security practices, and 74% would pay more for a product with additional security built in, Microsoft reported today.

There will be 25 billion Internet of Things (IoT) devices connecting the world by 2021, Gartner research indicates, and two-thirds of them will be for consumers. To learn more about consumer demand for connected products, their demand for security, and who they consider responsible for security, Microsoft teamed up with Greenberg Strategy to poll 3,000+ people across the US, UK, and Germany.

They learned security is the top consideration among people shopping for an IoT device — and most buyers don’t think companies are doing enough to protect them. Researchers say this creates an opportunity for device manufacturers to gain a competitive edge with security.

“Consumers have become more aware that smart devices bring risks into their homes, although they are often confused on exactly what those risks are and how probable they are,” says Galen Hunt, distinguished engineer and managing director for Microsoft’s Azure Sphere.

Some of the bigger IoT attacks — for instance, the 2016 attacks on Dyn using Mirai — became public knowledge. People often see IoT security risks in the news, reading about baby monitors becoming spying devices and hackers controlling connected cars. Security attacks feel like an invasion of privacy they generally want to avoid when they buy devices.

Most people say they’re likely to shop for a smart device in the next year. A smart TV is highest on their list (41%), followed by home security camera (36%), home security system (32%), lighting (31%), thermostat (26%), and speakers (23%). Smart ovens came in last (18%). Connected devices are pervasive, Hunt points out, and they all bring a similar risk level.

“Each node, or device, is connected to the broader network, and any link that breaks creates vulnerability to the network as a whole,” he explains.

Security Comes Top of Mind
When asked what factors play into their shopping decisions, security came on top at 21%, followed by value for money (20%), ease of use (11%), trusted brand (9%), and ease of setup (7%). Ninety percent of consumers think any piece of smart tech can be hacked, according to the survey.

But what are consumers worried will happen? More than half (52%) are most concerned about a personal data breach, while 19% fear their physical safety will be at risk. Nine percent are worried about personal privacy, 8% about government spying, 8% about corporate data misuse, and 3% about botnets. Unfortunately, their fears don’t translate to smart security practices.

“People generally do want to take the right steps,” says Hunt, pointing to a campaign for AV software installation on consumer PCs about 20 years ago. People recognize the need to put AV on their computers; when they don’t, machines will start showing signs of infection. “In today’s threat landscape, IoT devices won’t show as many visible signs — no noticeable lethargy, no visible popups — that give consumers clues there may be something amiss,” he adds.

Users think about security in their day-to-day lives: They lock their doors (82%) and close their windows (72%) before leaving their homes. But device security leads to false assumptions and resignation as people are both confused and unaware of how to approach security, researchers say. Sure, 90% accurately say software updates help maintain device security, but 65% think they can improve device security by avoiding sensitive conversations around their smart products.

Because they’re unsure of device security, consumers want manufacturers to do better. Sixty-five percent wouldn’t buy a smart product that had been hit with a security breach, researchers found. Further, says Hunt, the attack landscape for smart devices is so complex, it would be impossible for customers to take any action that mitigates all the risks their devices bring.

“This is why we feel it is imperative that manufacturers assume responsibility by building highly secured devices from the beginning,” he adds. One of his greatest concerns is that today, security is an afterthought — a problem that device makers assume they can solve later. In truth, Hunt notes, no amount of bolt-on security will protect users from dogged adversaries.

He’s also concerned device manufacturers are confused about the level of security they need. Many security solutions are on the market, says Hunt, but not all security is built equally. There’s a big difference between secured devices and devices with a few security features. Thankfully, he says, companies are becoming aware of the risk security can bring to their brand. Companies that seize responsibility today will have an “incredible advantage” in the future.

Related Content:

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

Article source: https://www.darkreading.com/threat-intelligence/consumers-demand-security-from-smart-device-makers/d/d-id/1333621?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Election Security Isn’t as Bad as People Think

Make no mistake, however: We’ll always have to be on guard. And we can take some lessons from the world of industrial cybersecurity.

When the 2018 midterm elections took place on November 6, the country held its collective breath waiting for news of a major election cyberattack. A few election-related hacking incidents occurred leading up to the midterms, including the recently revealed breach of the National Republican Congressional Committee, but things remained relatively quiet on Election Day.

Although Russia’s information operations continued, we didn’t see the kind of malicious cyber activity around voter registration databases or the hack-and-release of emails that occurred in 2016. Steps taken by election officials, political parties, and federal agencies are making it harder for adversaries to pull off those kinds of disruptions. But we should assume their tactics will change — and we must prepare for the next round. 

When it comes to election security, it’s easy to play into the FUD (fear, uncertainty, and doubt). But for all the talk around election security, the problem isn’t as bad as many people think — and it is getting better. One thing is for sure: We’re in better shape today than we were two years ago.

Growing Awareness Has Led to Progress
Most security researchers focus on the security of voting machines, but so much more comes into play and must be protected, including voter registration databases, the process of preparing and loading ballots into the machines, vote tabulation, and getting results to secretaries of state and the news outlets. Election infrastructure is much more complicated than just voting machines, and since 2016 government officials on both federal and state levels have taken strides to ensure the resilience of our elections against cyber threats. Communication has greatly improved between federal and state officials, improvements have been made to voting infrastructure, and election officials have received extensive training.

As awareness has grown, progress has been made — but there’s still more to be done. I was in charge of cyber and infrastructure security at the Department of Homeland Security (DHS) when we officially designated election infrastructure as critical infrastructure. There are many parallels between election systems and other forms of critical infrastructure, such as industrial systems. Just like with operational technology (OT) networks, the move to digitization has resulted in gaps in cybersecurity that must be addressed. I believe election officials can learn a lot from the advances made by industrial cybersecurity professionals to close those gaps and resolve vulnerabilities. For example:

  • Improve communication between siloed groups. Information technology (IT) and OT groups within industrial organizations have historically operated in siloes; however, digitization has led to the convergence of IT and OT, which has created the need for close cooperation between previously siloed groups. The same is true for the groups involved in election security. Election officials can learn from industrial leaders by focusing on clarifying responsibilities, putting communication processes in place, and planning workshops to reconcile perspectives, resolve clashing cultural issues, and establish trust.
  • Provide education. Cybersecurity education should be provided to all individuals involved in the election process on a regular, ongoing basis. Industrial cybersecurity leaders understand that the entire organization needs continuous education and often turn to widely used reference documents available from public cybersecurity organizations. For election officials and political candidates, cybersecurity playbooks developed by the Defending Digital Democracy project at Harvard’s Belfer Center, where I am on the advisory board, are great resources. In addition to furthering education, implementing and enforcing clear cybersecurity policies and procedures is vital.
  • Safely integrate new technology with legacy systems. In the rush to digitize, industrial organizations have been challenged to integrate new technology with legacy systems. Election officials are faced with the same challenge and often struggle with understanding how to close cybersecurity gaps. Because it’s unrealistic to expect all legacy systems to be replaced, it will be important to implement cybersecurity technology that offers real-time monitoring, providing visibility into all systems across the environment.
  • Put a comprehensive incident response plan in place. Assuming an adversary may overcome your defenses and ensuring that you can mitigate the consequences of an attack is an essential element of building resilience. Industrial leaders understand the importance of a comprehensive incident response plan that goes beyond just the computer network problems and addresses the operational impact. Creating an incident response plan that will allow a quick and safe response to identified threats is a must-have for election officials. The plan should have concrete guidelines and should clearly map out each individual’s role. As a group, election workers should do practice drills to ensure readiness should a significant cyberattack occur. And any plan must include public communication to shore up public confidence.

As a country, we learned a lot from the 2016 elections. Great effort has been put forth to ensure the integrity of our election systems, and as those efforts continue, election officials can learn a lot from other critical infrastructure organizations that have a head start in improving cybersecurity in the face of digitization. With heightened attention on this urgent need, I am optimistic that things will get better from here — in 2020, 2022, and into the future. Beyond election security, we must continue to improve critical infrastructure in all its forms — our way of life depends on it.  

Related Content:

 

Former Under Secretary for the National Protection and Programs Directorate (NPPD) at the US Department of Homeland Security (DHS), Ms. Spaulding has been addressing national security issues for more than 25 years. At the DHS, she managed a $3 billion budget and a workforce … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/election-security-isnt-as-bad-as-people-think-/a/d-id/1333579?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Ryuk Ransomware Attribution May Be Premature

The eagerness to tie recent Ryuk ransomware attacks to a specific group could be rushed, researchers say.

Security researchers are keen to link a recent outbreak of Ryuk ransomware to a specific attacker. Some have suggested North Korea, a decision some experts say could be rushed.

Last week a cyberattack caused print and delivery problems for newspapers owned by Tribune Publishing, including the Chicago Tribune and Baltimore Sun, as well as the Los Angeles Times. The issue affected the timeliness and, in some cases, the completeness of printed papers. At the time, people with knowledge of the incident said it appeared to be Ryuk ransomware.

Some parties, including Check Point Research, connected this particular Ryuk campaign and some of its inner workings to the Hermes ransomware – a form of malware commonly linked to the North Korean APT Lazarus Group. Unlike most ransomware, they say, Ryuk is only used for tailored attacks and its encryption scheme is purposefully built for small-scale operations.

But was North Korea behind the Tribune campaign? Not necessarily, McAfee Labs experts say.

To determine who may have launched the Ryuk campaign, some experts have looked at past research comparing Ryuk’s code with older Hermes ransomware. In October 2017, McAfee Labs investigated an attack on a Taiwanese bank in which actors used a ransomware outbreak to distract IT staff at the same time they were stealing money. The malware used was Hermes 2.1.

Back at the time of the bank attack, McAfee didn’t do much digging into the ransomware itself, says John Fokker, head of cyber investigations for McAfee Advanced Threat Research. When it was investigating North Korean attribution for the recent Ryuk campaign, they found an Aug. 2017 posting in an underground forum where a Russian-speaking actor was selling Hermes 2.1.

“It looks like a regular cybercrime kit you can buy and perhaps tweak to your liking,” he explains. “If we backtrack to the investigation, there’s a probability Lazarus bought this kit to use as a distraction.”

While most nation-state groups tend to build and use attacks they developed, as Lazarus typically does, it wouldn’t be out of the question for a group to purchase malware that would serve as a diversion. “It makes sense if you want to go for distractions, or want to create a false flag, you might go out and buy something,” Fokker adds, saying it’s a likely hypothesis.

Given Hermes 2.1 went on sale long before the bank heist in Oct. 2017, several people could have purchased and altered it, he continues. “We’ve shown that it’s for sale, anyone with skill and money could buy this,” says Fokker. “It opens to a wide variety of potential actors.”

McAfee Labs says Ryuk and Hermes 2.1 are generally equal. “There is a very high overlap,” he continues. “They’re almost identical.” If changing the name, and implementing a ransom note, are both part of the “fine tuning” process involved with editing Hermes 2.1 into a slightly different threat, then Ryuk is likely an edited version of it, researchers explain.

So Whodunnit?

McAfee Labs suggests the most likely hypothesis in the Ryuk case is that of a cybercriminal operation developed from a toolkit offered by a Russian-speaking actor. Evidence shows sample similarities over the past several months, which indicate a toolkit is being used. Researchers don’t currently know who is responsible, but Fokker points to some defining traits.

The author and seller of Hermes 2.1 advertises a kit, not a service, meaning whoever bought it would need to set up a distribution method and infrastructure to make it work, McAfee Labs researchers explain in a blog post. Fokker also predicts the attacker has a skill in targeting.

“They’re doing reconnaissance on the victim to find out if the victim is interesting and if they have money to pay up,” he says. “It’s less opportunistic, and more targeted. That shows to me a certain level of skill – not necessarily technical skill, but a skill that you can find your victim and select them.” If it’s not North Korea, it could also be a well-organized criminal group.

Fokker also points to general problems with attribution. It’s understandable experts want to attribute an attack, he says, but oftentimes the process for doing so is flawed – especially when it comes to linking incidents with state-sponsored actors.

“There is a strong movement toward the ‘who’,” he says. “Everyone wants to figure out who is responsible … but you often don’t have all the pieces to the puzzle.”

McAfee Labs’ approach is to analyze competing hypotheses, researchers say. An investigation involves several views, comparing different pieces of evidence to support each hypothesis, and also finding evidence that falsifies hypotheses. This method ensures the strongest hypothesis is not the one with the most verified evidence, but the one with the least falsifying evidence.

Related Content:

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

Article source: https://www.darkreading.com/vulnerabilities---threats/ryuk-ransomware-attribution-may-be-premature/d/d-id/1333628?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Supreme Court refuses to hear Fiat Chrysler appeal in Jeep hacking case

The US Supreme Court on Monday refused to hear Fiat-Chrysler’s appeal in a lawsuit over security holes that famously let researchers paralyze a Jeep Cherokee that should have been zooming down the highway instead of waiting for an 18-wheeler to catch up and turn it into oily pudding.

(Which, thankfully for driver and Wired journalist Andy Greenberg, it did not.)

The court’s action means that one of the first legal cases involving cybersecurity risks in cars will go to trial in October.

The car company’s wish for the class action suit to go away is based on the fact that, as it’s pointed out, none of the cars belonging to (or leased by) the 200,000 class members actually got hacked. Besides, it fixed the bug, it said.

Well, we never would have bought the cars in the first place if we’d known about the security holes in your entertainment system, the class members say. Besides, the suit argues, the cars are worth a whole lot less now because of those vulnerabilities. The class members are seeking $50,000 per affected car to offset the loss in resale value.

Four owners or lessees of Chrysler vehicles brought the suit (PDF) against the car company in 2015, after renowned automobile/security researchers hackers Charlie Miller and Chris Valasek remotely took over a Jeep Cherokee from 10 miles away.

They were able to control the Jeep’s brakes and accelerator, as well as other less-essential components like radio, horn and windshield wipers, by exploiting the Jeep’s entertainment system, called uConnect, over a cellular network.

That led to a historic recall of a whopping 1.4 million vehicles. The researchers’ response? You ain’t seen nuthin’ yet.

A year later, they were back to show what they could have done if they’d continued to work on the attack in secret, as malicious hackers might have done. Namely, in spite of Fiat-Chrysler’s patch, Miller and Valasek came up with yet another attack in which they managed to spin a steering wheel 90 degrees while the car was traveling at 60 mph. Another year, another Jeep stuck in a ditch next to a cornfield.

The plaintiffs in the class action suit, filed against the US subsidiary of Fiat-Chrysler and the manufacturer of the uConnect software, contend that the company knew about the vulnerability for three years and failed to fix it.

If you’re curious about the technical details of how the researchers pried open the Jeep’s Controller Area Network (CAN), you can check out the pair’s research notes, which they released in 2017.

They weren’t the first to gift the world with automotive hackery, either: open source software tools and hardware designs that support car hacking include a toolset called CANtact; GoodThopter, an open-source board with a built-in CAN interface; and the open source EVTV Due CAN sniffer. In fact, the plaintiffs in the class action say that the vulnerabilities were first revealed as early as 2011.

Fiat Chrysler put out a statement saying that it was looking forward to presenting its case in court:

None of the more than 200,000 class members in this lawsuit have ever had their vehicles hacked, and the federal safety regulators at NHTSA (the U.S. National Highway Safety Administration) have determined that FCA US has fully corrected the issues raised by the plaintiffs.

Some say that the “yea, but we fixed it” defense doesn’t cut it. Chris Wysopal, for one, co-founder and CTO of Veracode, said that a big time lag between bug discovery and patch issuance leaves the transmission stuck in “risky!” for consumers:

Chris Wysopal ‏ @WeldPond
Fiat Chrysler defense is “we fixed it”. But how long it takes to be fixed should matter. In this case the plaintiffs allege it was 4 years. Consumers often only find out about the risk after the fix is made available.

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

Before you slink off to the pub, be sure to patch these 19 serious vulns in Juniper Networks kit

Juniper Networks has had its first big bug day in months, with 19 patches announced covering everything from third-party package catchups to critical errors in password handling.

For the sake of organisation, let’s pick up patches in the Junos OS first (there being so many patches, The Register will focus on those rated “High” and “Critical”).

First on the critical list is CVE-2019-0006, which affects Junos OS 14.1X53, 15.1, and 15.1X53 running on EX, QFX and MX units. A crafted HTTP packet can be sent to the target, and this “can result in a crash of the fxpc daemon or may potentially lead to remote code execution”.

The software inherited third-party vulnerabilities disclosed in this list of eight CVEs associated with libxml2, some dating back to 2016, and some of which are rated Critical. Versions from 12.1X46 through to 18.2X75 are affected.

High-rated CVE-2019-0001 affects MX Series devices configured with dynamic VLANs, running Junos OS 16.1 through to 18.2. A malformed packet can trigger “an uncontrolled recursion loop in the Broadband Edge subscriber management daemon (bbe-smgd)”.

Junos OS 12.1X46, 12.3, 12.3X48, 14.1X53, 15.1, 15.1F, 15.1X49, 15.1X53 are subject to CVE-2019-0003, also rated High. A malicious flowspec BGP update can crash the router daemon.

BGP is also the vector for CVE-2019-0012 (High). If Junos OS 12.1X46, 12.3, 12.3X48, 14.1X53, 15.1, 15.1X49, 15.1X53, 16.1, 16.2, 17.1, 17.2, 17.3, 17.4, or 18.1 is configured as a VPLS PE (provider edge), an attacker can craft a BGP message to crash the router daemon.

In CVE-2019-0010, crafted HTTP traffic can exhaust the memory of SRX Series devices running Junos OS 12.1X46, 12.3X48, and 15.1X49.

QFX and PTX Series devices running OS 17.2X75, 17.4, 18.1, or 18.2 can be crashed with a malformed J-Flow sampling packet (CVE-2019-0014, High).

Junos OS also inherited a buggy expat XML parser library from FreeBSD, in versions 12.3, 12.3X48, 14.1X53, 15.1, 15.1F, 15.1X49, 15.1X53, 16.1. Dating back to 2015, in CVE-2015-1283 a remote, unauthenticated attacker can send crafted XML to hose the target with either an out-of-memory condition or buffer overrun.

The other third-party vulnerability inherited by the operating system was in OpenSSL, with two CVEs affecting Junos OS 12.3X48 through to 18.4R1 and all subsequent releases.

OK, I’ve patched Junos OS. What next?

The company has disclosed that Juniper ATP 5.0.3 and 5.0.4 has a delightful collection of 14 CVEs, including a hardcoded salt for DES password hashing, and four other cases of hardcoded credentials, so that advisory is rated Critical.

Junos Space has multiple CVEs listed here, including a Critical integer overrun in the process browsing procps-ng library, a directory traversal in the yum-utils component reposync.

As well as an SSL protocol fix, the company’s Session and Resource Control software has been patched to fix the High-rated CVE-2016-2183, aka “Sweet32”, a birthday attack against the DES and Triple-DES ciphers. These are fixed in SRC 4.12.0-R1 and newer versions. ®

Bootnote

It is just over three years since Juniper Networks was caught out by unauthorised code that acted as an effective backdoor to its ScreenOS firewall operating system. The diligent effort that leads to big patch efforts is more to be welcomed than condemned.

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/01/10/juniper_january_2019_patch_day/

Baddies linked to Iran fingered for DNS hijacking to read Middle Eastern regimes’ emails

Infosec biz FireEye has suggested Iran may be responsible for what it claims are DNS hijacking attacks aimed at snooping on the contents of Middle Eastern governments’ email inboxes.

illustration showing russian president vladimir putin winking

That Saudi oil and gas plant that got hacked. You’ll never guess who could… OK, it’s Russia

READ MORE

The firm’s incident response and intelligence teams said they had spotted miscreants logging into pxy1, described as “a proxy box used to conduct non-attributed browsing and as a jumpbox to other infrastructure”.

From there they were seen to use previously stolen DNS admin creds to change basic DNS A records to point to IP addresses the bad actors controlled, establishing a man-in-the-middle setup. The researchers said the crew used a load balancer to ensure the technique passed through genuine web traffic, helping keep it invisible to users.

A Let’s Encrypt free SSL certificate was used to get around any problems with mismatched certificates in the instances highlighted by FireEye. The company did point out that it had also seen “multiple Domain Control Validation providers being utilised as part of this campaign” so that particular part of the attack is not solely dependent upon Let’s Encrypt certs.

Fireeye said it had also watched the manipulators using broadly similar techniques to fiddle with DNS nameservers, with the same ultimate aim of getting their hands on the contents of targets’ email inboxes.

“While we do not currently link this activity to any tracked group, initial research suggests the actor or actors responsible have a nexus to Iran,” mused FireEye in its blog post about the research.

The firm said that while it “suggested” people in Iran were involved with “moderate confidence”, based on geolocation of IP addresses, the attack techniques “may not be exclusive to a single threat actor as the activity spans disparate timeframes, infrastructure, and service providers”.

It also noted that “the activity aligns with Iranian government interests”.

Those same IPs, however, “were previously observed during the response to an intrusion attributed to Iranian cyber espionage actors”.

Iran, like other pariah states throughout the world, has some capable cyber-folk working for it. Back in August last year a potential BGP hack routed messages from chat app Telegram through Iran, while a staggering failure of basic opsec techniques helped Iranian counter-espionage units round up and neutralise American spies operating in their country – all thanks to a Google search. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/01/10/fireeye_iran_dns_hijacking/

The D in SystemD stands for Dammmit… Security holes found in much-adored Linux toolkit

Security biz Qualys has revealed three vulnerabilities in a component of systemd, a system and service manager used in most major Linux distributions.

Patches for the three flaws – CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 – should appear in distro repos soon as a result of coordinated disclosure. However, Linux distributions such as Debian remain vulnerable at the moment, depending on the version you have installed.

“They’re aware of the issues and they’re releasing patches,” said Jimmy Graham, director of product management at Qualys, in a phone interview with The Register. “I don’t believe Red Hat has released one but it should be coming shortly.”

The bugs were found in systemd-journald, a part of systemd that handles the collection and storage of log data. The first two CVEs refer to memory corruption flaws while the third involves an out of bounds error that can leak data.

CVE-2018-16864 can be exploited by malware running on a Linux box, or a malicious logged-in user, to crash and potentially hijack the systemd-journald system service, elevating access from user to root. CVE-2018-16865 and CVE-2018-16866 can be exploited together by a local attacker to crash or hijack the root-privileged journal service.

While systemd isn’t universally beloved in the Linux community, Graham sees nothing unusual about the presence of the three flaws in the software. “The noteworthiness to me is that it is very commonly found in most major disruptions,” he said.

Qualys contends all systemd-based Linux distros are vulnerable, though the vulnerabilities cannot be exploited in SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 because their user space is compiled with GCC’s -fstack-clash-protection option.

CVE-2018-16864, the company says, entered systemd‘s codebase in April 2013 (systemd v203) and became exploitable in February 2016 (systemd v230). While working on an exploit for another Linux flaw, Qualys researchers found that if you pass several megabytes of command-line arguments to a program that calls syslog(), systemd-journald will crash.

That led them to look for another instance of an attacker-controlled alloca() function, which they found. CVE-2018-16865 appeared in December 2011 (systemd v38) and became exploitable in April 2013 (systemd v201), Qualys says.

Sad penguin photo via Shutterstock

The D in Systemd stands for ‘Dammmmit!’ A nasty DHCPv6 packet can pwn a vulnerable Linux box

READ MORE

The security biz calls it a simplified stack clash – where the size of the stack gets changed to overlap with other memory areas – because it only requires the last two steps in a four step process: Clashing the stack with another memory region, moving the stack-pointer to the stack start, jumping over the stack guard-page into another memory region, and smashing the stack or memory space.

The third bug, CVE-2018-16866, appeared in June 2015 (systemd v221) and, Qualys says, was fixed inadvertently in August 2018. In code where the flaw still exists, it could allow an attacker to read out of bounds information, resulting in information leakage.

“The risk [of these issues] is a local privilege escalation to root,” said Graham. “It’s something that should still be a concern because usually attackers don’t just use one vulnerability to comprise a system. They often chain vulnerabilities together.” ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/01/10/systemd_bugs_qualys/

Who cracked El Chapo’s encrypted chats and brought down the Mexican drug kingpin? Er, his IT manager

In an extraordinary twist, it was revealed on Tuesday that the man most likely responsible for bringing drug kingpin “El Chapo” Joaquin Guzman to justice was none other than his sysadmin.

Two months into the trial in New York, the FBI admitted that it had been able to access hundreds of phone calls made by Guzman and his associates via a custom encryption system because they had flipped the IT guy that set it up, systems engineer Cristian Rodriguez.

The trial had heard several recordings previously but, starting this week, the prosecutors started playing more in which Guzman discussed cocaine deals, warned his bodyguard not to kill policeman and even had a brief conversation with a corrupt police commander who he had just put on the payroll.

The recordings were made possible because nearly a year earlier a federal agent posing as a Russian gangster sat down with Rodriguez at a New York hotel and said he needed a system to make calls without law enforcement being able to listen in.

Rodriguez had just set up such a system for Guzman after he was recommended to the Mexican by Colombian drug lord Jorge Cifuentes. Rodriguez could set up a totally secure comms network, Cifuentes told El Chapo, using a closed, encrypted VoIP network.

And so Rodriguez traveled to Guzman’s headquarters in the Mexican county Sinaloa and did exactly that. Guzman logged into the network with his home Wi-Fi and made encrypted business calls that the authorities were unable to listen into.

But the Feds were onto the IT guy and approached him pretending to be in need of a similar network. At some point, they managed to flip Rodriguez and he then undermined Guzman’s network by shifting servers from Canada to the Netherlands – claiming it was an upgrade – and giving the FBI the network’s new encryption keys.

From that point, the authorities were able to grab recordings of El Chapo’s calls and their contents seem likely to put the drug lord away for life.

Tap tap tap

The details were outlined in court by FBI special agent Steven Marston, who said that with Rodriguez’ help they had managed to tap more than 1,500 calls on the encrypted system between April 2011 and January 2012.

Amazingly, it seems the lot of a sysadmin is the same regardless of who you are working for. A transcript of one call made between Rodriguez and Cifuentes’ brother, who was with Guzman in the Mexican mountains at the time, sees Rodriguez being castigated for the encrypted network being down.

The call was intercepted because it was carried out over an unencrypted cell phone. Rodriguez tries to reason with Cifuentes, saying all he has to do is buy a computer and he will head over and configure it.

But the drug trafficker isn’t happy, complaining about having to get the computer himself, and about the long password needed to get into a different machine: A situation that every sysadmin on the globe will recognize. Except with one big difference – your boss is unlikely to track you down and kill you if you upset him.

“You didn’t send me the engineer to install my machine. So, then, it’s all your fault,” Jorge Cifuentes complained. “No!” responded to Rodriguez.

“It’s all your fault.”

“No, Don Jorge, don’t stress me out more, man, because…”

“Don’t complain that I… what can I do? I haven’t been able to do it.”

“Hadn’t we agreed that you were going to buy a mini computer and you were going to call us to configure it?”

“I’m so busy. I didn’t even have time to breathe… I have a computer but, you know that I haven’t been able to open it? A Vaio… Do you remember the small Vaio?”

“Yes, sir.”

“Good, but that has a very long password.”

“Yes, sir.”

“The long one, that password that you place…is this the password?

“Yes, sir.”

“What a drag! It has symbols and things.”

Breakdown

It’s safe to assume that as soon as the Feds heard this exchange, they figured that Rodriguez could be their way in. And he was, although it wasn’t easy on him.

GTA IV

Notorious Mexican drug kingpin nabbed thanks to drones and spyware

READ MORE

Prosecutors told the court earlier in the trial that a key witness – which turns out to be Rodriguez – had suffered a “nervous breakdown” in 2013 because of “stress” of working for El Chapo – although the stress was more likely due to the fact that he was working undercover for the Feds while in charge of the comms network of an extremely violent criminal enterprise.

Eventually, Rodriguez left the cartel – it’s not clear under what circumstances or if the Feds helped. But by then Guzman and Cifuentes had grown suspicious that their IT guy may have flipped and various enforcers turned up looking for Rodriguez – something that didn’t exact improve his sense of personal safety.

Rodriguez is still expected to appear as a witness at some point in the trial: The sysadmin who took down a drug lord. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/01/09/drug_kingpin_el_chapo_sysadmin/