University of Copenhagen associate professor Carsten Schuermann discusses his forensic analysis of decommissioned WinVote voting machines, considered the worst voting machine ever, and whether they were tampered with, or used for anything suspicious. Filmed at the Dark Reading News Desk at Black Hat USA 2018.
No matter what side of the political divide on which one falls, everyone agrees that the security and integrity of elections are critical. Throughout history, foreign adversaries have attempted to influence election outcomes to their benefit and, in 2016, the efforts escalated to cyberattacks. For this reason, the security of US elections and election infrastructure remains a top national concern, and in early 2017, the government designated the election system as one of our critical infrastructures. With the number of cyberattacks growing every day, improving cybersecurity will be a mandatory component in preserving our political process.
The US Department of Homeland Security (DHS) confirmed that at least 21 states have had their networks scanned by Russian adversaries. Scanning is the cyber equivalent of checking for holes in a fence, an unlocked door, or an open window. There are also confirmed reports of a few specific intrusions into government-owned voter registration databases.
The recent FBI indictments validate an organized cyberattack campaign that targeted political organizations, specifically the Democratic Congressional Campaign Committee and the Democratic National Committee. Not surprisingly, this attack began with spearphishing that resulted in network access, the planting of malware, lateral movement, and the exfiltration of sensitive data.
Federal, state, and local governments are responding with initiatives to improve the security of election infrastructure. Earlier this year, the federal government approved $380 million to be used by the states to improve election security. Currently, more than 20 states have requested access to funds and this should increase as we approach the 2018 midterm elections. The funds are being used to improve voter registration databases, election management systems, electronic voting machines, and election night reporting systems.
Ways to Improve Election Infrastructure Security
Election infrastructure is a complex web of systems and networks that involves more than 8,000 entities with resources distributed across both state and local governments. Notably, election infrastructure is not just the systems that support the actual election process but also includes the operations of candidates and campaigns. Improving election infrastructure security requires a combination of a renewed focus on basic cyber hygiene, as well as the strategic use of advanced security technologies, threat intelligence, and information sharing.
1. Revisiting Basic Cyber Hygiene
Whether we are talking about election infrastructure or corporate IT infrastructure, organizations often don’t focus enough on cyber hygiene. Just focusing on the basics, which include hardening systems, ensuring proper access controls, and conducting security awareness training to mitigate the risk of users clicking on malicious links, can strengthen security posture. (Yes, John Podesta — we’re talking about you!)
State and local governments can take advantage of complimentary DHS services when testing their election infrastructure, which include cyber hygiene scans on Internet-facing systems and risk and vulnerability assessments.
2. Deploying Next-Generation Cyber Technologies
Cybersecurity is an ongoing race between attackers and defenders. Therefore, it’s critical that organizations incorporate more contemporary and advanced security technologies into cyber defense efforts.
Current systems are overwhelmed, and hackers have been able to fly under the radar through encrypted communications such as Secure Sockets Layer. Utilizing next-generation security solutions is another way to increase election infrastructure security. It is no longer good enough to solely rely on firewalls and intrusion detection and prevention systems to protect our political system.
3. Using and Sharing Threat Intelligence
Threat intelligence and information sharing has become a critical element of cyber frameworks like the NIST Cybersecurity Framework. With election infrastructure spread across federal, state, and local government, it is imperative that these organizations not only use but also share threat intelligence.
The good news is there is a significant amount of organized threat intelligence and intelligence-sharing efforts that can be leveraged to improve election infrastructure security. Organizations such as DHS and the FBI are valuable partners in these efforts.
There is also the Multi-State Information Sharing Analysis Center (MS-ISAC), whose stated mission is “to improve the overall cybersecurity posture of the nation’s state, local, tribal and territorial governments through focused cyber prevention, protection, response, and recovery.” MS-ISAC serves as a central hub for members to access, contribute, and exchange threat intelligence. Earlier this year, MS-ISAC formed the Elections Infrastructure ISAC (EI-ISAC) to specifically support the needs of election infrastructure. EI-ISAC provides members sector-specific threat intelligence products, incident response and remediation, threat and vulnerability monitoring, cybersecurity awareness, and training products.
Thinking Ahead
To ensure our electoral system is protected for years to come, federal, state, and local governments have significantly increased investments in election infrastructure security. While no one thing will solve this problem overnight, by revisiting basic security hygiene, deploying next-generation technologies, and using, sharing, and acting on threat intelligence, we will begin to move forward in mitigating the massive amount of cyber-risk that currently threatens our election system.
Related Content:
Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early-bird rate ends August 31. Click for more info.
Todd Weller, Chief Strategy Officer at Bandura, works with large organizations in acting on their threat intelligence to prevent future attacks. He brings over 20 years of cybersecurity industry experience with a unique blend of operational and hands-on proficiency. He … View Full Bio
Article source: https://www.darkreading.com/iot/the-votes-are-in-election-security-matters/a/d-id/1332564?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple
Hijacking systems to mine cryptocurrency is a growing IT security issue. Now a cyber insurance company has announced an insurance product to protect organizations against the crime.
San Francisco-based Coalition’s Service Fraud coverage reimburses organizations for direct financial losses from charges incurred through fraudulent use of software-as-a-service (SaaS), infrastructure-as-a-service (IaaS), network-as-a-service (NaaS), and telephony services, among other business services. The coverage isn’t limited to cryptomining incidents, though. It also covers all forms of illicit use of services including toll fraud and unauthorized use of cloud services.
In announcing Service Fraud, Coalition cited Check Point research that shows 42% of organizations were impacted by cryptomining malware in the first half of 2018, an increase from 20.5% from the previous six months.
Read here for more.
Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early bird rate ends August 31. Click for more info.
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
A tool sold by Germany-based firm Breaking Security as legitimate software for remotely managing Windows systems is instead being widely used by threat actors in multiple malicious campaigns.
Researchers at Cisco Talos say that Breaking Security’s Remcos software is a sophisticated Remote Access Trojan (RAT) that attackers can use to fully control and monitor any Windows computer from XP onward, including those running server editions of the operating system.
Breaking Security has said Remcos is only sold for legitimate uses and that it will revoke the license of any users caught using the software for malicious purposes. However, the product — which sells for anywhere from around $57 to $450 — is being widely advertised and sold on numerous hacking-related forums apparently with Breaking Security’s knowledge and, in some cases, active participation, Talos said in an advisory Wednesday.
Despite Breaking Security’s claims about revoking licenses, multiple unrelated adversaries are using Remcos in a variety of different threat campaigns, including one targeting defense contractors in Turkey, Talos said.
But Francesco Viotto, an individual who identified himself as an administrator and developer at Breaking Security, says that Talos’ analysis is incorrect, incomplete, and damaging. In emailed comments to Dark Reading, Viotto said Remcos — an acronym for Remote Control Surveillance — is simply a powerful tool for carrying out multiple remote administration, remote support, surveillance, and remote proxy tasks.
Breaking Security has many customers, he said, including those in IT management and cybersecurity, as well as business owners and private users. “Now, due to the power and versatility of this software, some users abused it by using it to control machines where they didn’t have ownership on,” he wrote. “This is explicitly forbidden by our Terms of Usage, which any user must accept prior to registering and buying on our site.”
Viotto said each Remcos user has a unique license code that makes it easy to spot when the software has been installed on unauthorized systems. In the event Breaking Security discovers a user is abusing the software, the license can be immediately revoked, he explained, plus the company offers a dedicated email on its site that security researchers can use to report abuse. However, Talos never reported any such abuse prior to the report, Viotto said.
“If the researchers who wrote, ‘I sell Remcos to cybercriminals’ did their homework well, why didn’t they mention all the anti-abuse code which I programmed into Remcos?” he wrote. “Why should I include these protection methods and ruin my business if these accusations are true?”
Viotto added that if Cisco Talos had been really interested in stopping the malicious campaigns, the easiest method was to report the abuse to the company first.
Cisco Talos’ analysis has revealed several attempts by adversaries to install Remcos on various endpoints via different distribution methods, including specially crafted spear-phishing emails. Among the organizations that one attacker has targeted using Remcos are news agencies, diesel equipment manufacturers, HVAC service providers, and organizations within the energy and maritime sector.
Remcos is not the only ostensibly legitimate tool that attackers can obtain from Breaking Security.
The firm also offers an encryption tool called Octopus Protector that attackers can use to hide malware from threat detection tools; a keylogger for capturing and transmitting keystrokes on infected systems; a mass-mailing tool for sending spam; and a DynDNS service for post-compromise command and control. The firm even has a YouTube video on its site showing potential buyers how they can use the Octopus Protector to bypass antimalware tools.
Breaking Security’s portfolio of products and services, when combined with Remcos, gives attackers all the tools required to build and maintain a potentially illegal botnet, Cisco Talos said.
From a functionality and use case standpoint, Remcos is a fairly standard-issue RAT. What makes the tool interesting is how it is being openly sold as a legitimate tool for remote administration of Windows systems, says Craig Williams, director of outreach with Talos.
“The fact that [Breaking Security’s] business model involves openly selling tools which appear to be widely used by malware authors is fairly unusual,” he says.
There have been other instances where someone has openly advertised and sold malware under the guise of it being a legitimate tool, but those have been reasonably rare. “Gray area software is something to be concerned about,” Williams says.
Arguably, tools such as Remcos can have a legitimate purpose, which is possibly why Breaking Security is selling it openly. “If someone wanted to monitor and keylog a computer remotely with binaries that evaded antivirus through a DynDNS C2 mechanism for legal purposes, this may be useful,” Williams says.
The tool is especially useful if the initial install vector needed to be a phishing email, he notes. But, otherwise, few other legitimate use cases for the tool appear to exist.
Businesses like Breaking Security highlight the reasons why one should never buy so-called “administrative tools” from questionable companies, Williams said.
To assist organizations that may have become victims of Remcos, Talos is providing an open source tool capable of extracting the C2 server address and other information needed to block the threat, he adds.
Related Content:
Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early bird rate ends August 31. Click for more info.
Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio
The Democratic National Committee (DNC) was alerted this week to an attack attempt on its voter database, CNN reports.
Cloud service provider and security firm Lookout reported to the DNC that a phony login page spoofing Votebuilder, a service used by party officials and campaigns, had been discovered attempting to grab usernames and passwords to the database. DNC officials then contacted the FBI.
According to CNN, a Democratic source told the media site that it’s unclear who is behind the attack just yet, and that there’s no indication that voter file was hacked by the attackers.
Read more here.
Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early bird rate ends August 31. Click for more info.
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/dnc-reports-attempted-cyberattack-on-its-voter-database/d/d-id/1332633?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple
Winter is indeed coming, Ned Stark, but it’s looking more like pirates than white walkers: a new report found that thieves may have put your HBO GO account on the auction block on the Dark Web.
The report from Irdeto found that thieves are selling hundreds of stolen logins for popular “over-the-top” (OTT) services such as pay TV and video on demand on Dark Web marketplaces.
Besides HBO GO credentials, the company spotted listings for logins to 42 services, including Netflix, DirecTV and Hulu. All told, during the month of April, Irdeto spotted 854 sets of credentials, listed by 69 separate vendors on 15 marketplaces.
On average, an account’s credentials are fetching $8.71 (about £6.60) for one-time use. Some Dark Web sellers are also selling bundles of credentials for several services at higher prices.
Granted, Irdeto has an interest in bringing attention to piracy and other illicit activities, given that it sells content security and monitoring solutions and services to media and entertainment customers. But there’s no denying that cyber thieves will grab, and sell, these credentials.
Netflix, for one, keeps an eye out for its customers’ credentials turning up in batches of data ripped off in various breaches. Like many online services – including Facebook and Amazon, for example – Netflix’s routine security monitoring includes sniffing around online to see if it can find its user IDs circulating in breach lists.
(It’s worth noting that online services that do this look for account names that seem to match up with those of their own users. If they find any, they try to hash the revealed-somewhere-else passwords against hashed passwords of their own users. If they find that some of the passwords, once hashed, match their own customers’ hashed passwords, it translates into users having used the same password on multiple sites.)
That’s how Netflix wound up closing the accounts, or resetting passwords, of some customers in 2016: after finding their account credentials floating around online, the company zipped up the accounts to keep them from being hijacked.
That’s a good move. Who wants pay for crooks to watch Breaking Bad? Or Disney films, for that matter?
Irdeto recommends that we all keep our eyes out for unusual or unfamiliar activity on our accounts. It also suggests changing passwords regularly, but that won’t do you much good if you’re using weak passwords, or, worse still, re-using passwords.
Be they strong as steel or weak as wet tissue, reusing passwords means that if one service gets breached, crooks can try the same credentials on all your other accounts. Here’s a detailed explanation of the dangers of password reuse, and here’s how to make every one of those passwords robust.
You well might have passwords coming out your ears, and we know it’s tempting to more or less just give up when it comes to creating unique, tough-to-crack passwords for all your accounts. Instead of giving up on security, though, consider using a password manager.
We think they’re a great tool. All you have to remember is one good, strong master password for the manager.
Some, if not all, password managers will run through your passwords and flag any that have been reused, prompting you to come up with stronger, unique passwords that they’ll then store so you don’t have to scribble them down or remember them.
Whatever you choose to do, make sure you’ve got a unique, hefty password before Game of Thrones Season 8 debuts next year, and the pirates storm your cyber fortress.
Here’s how!
(No video? Watch on YouTube. No audio? Click on the [CC] icon for subtitles.)
Follow @LisaVaas
Follow @NakedSecurity
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/5OVfkvNkFA4/
Worried about enterprise security, access control, and GDPR? Relax, the standards bods at European Telecommunications Standards Institute (ETSI) have you covered.
Covered, that is, if you implement its latest encryption standards. ETSI’s Technical Committee on Cybersecurity announced it has released two Attribute-Based Encryption standards designed to help organisations apply access controls to the personal data that European companies have to protect to comply with GDPR.
The aim is to make sure that personal data can only be decrypted if the attributes on a user’s key match the encryption attributes.
ETSI reckons attribute-based encryption makes it easier to protect data with “secure by default” access control – access isn’t bound to user name and password, for example, but rather to pseudonymous or anonymous attributes. Standardisation also makes interoperability easier, the standards body says.
ETSI’s announcement gives HR access as an example: a user could be restricted from accessing employee pay data if they have the attributes of an HR employee, and have been working in the organisation for more than 12 months.
The standards body said using encryption to enforce access control provides better security than software-based solutions, and a given data set can be protected by one encryption attribute, making it efficient.
The specifications in question are ETSI-TS-103-458 and ETSI-TS-103-532.
ETSI-TS-103-458 defines the high-level requirements for attribute-based encryption, covering IoT devices, WLANs, cloud services, and mobile services.
Its four use cases protect data when access is coming from an untrusted mobile network; WLAN access, in which data protection has to take into account end user credentials presented over different wireless networks; network edge and IoT environments, in which data access could be controlled either in the network or on the device; and cloud environments.
The standard, here (PDF), notes that in the mobile use-case, for example, a user’s IMEI might be exposed when travelling in a foreign country. Attribute-based encryption would, in that case, help protect stored data in the presence of a hostile listener on the network.
By providing user identity protection across its different use-cases, ETSI-TS-103-458 is designed to reduce the risk that a malicious third party could grab user credentials to access personal data in systems like corporate databases.
The other standard, ETSI-TS-103-532 (PDF here), goes into the technical implementation details of attribute-based encryption.
As ETSI’s announcement explained, this “provides a cryptographic layer that supports both variants of ABE- Ciphertext Policy and Key Policy”, with various levels of security assurance to suit the cloud, mobile and IoT use-cases.
ETSI-TS-103-532 includes an extensible cryptographic layer so it can be extended with new crypto schemes in the future, all the way up to the emerging “post-quantum cryptography” world.
Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/08/22/etsi_cryptobased_standards/
While law enforcement continues its worldwide crusade against chat apps with end-to-end encryption, the Internet Engineering Task Force has proposed standards designed to let everybody have message security.
One Internet Draft describes the requirements for Message Layer Security (MLS); the other is an MLS protocol standard.
There are some heavy-hitters onboard. The requirements draft has people from Google, French research institute INRIA, Mozilla, Twitter, MIT, and the Wire collaboration platform, while the protocol’s authors come from Cisco, Facebook, Google, the University of Oxford, and Wire.
As the requirements draft notes, MLS isn’t designed as a chat protocol, but rather “is intended to be embedded in a concrete protocol”, providing abstract data structures that can be mapped on encodings such as TLS 1.3 and JSON.
The architecture assumes that a messaging service needs an authentication service to maintain user identities, let them authenticate each other, and allow users to find each others’ identity keys – and a delivery service that handles message-passing.
In an encrypted messaging platform like Signal, these two operations might be part of the same software, running on the same server, but they’re logically distinct.
The delivery service (DS) also handles the public key processes needed to set up group keys (in the case of end-to-end encrypted group chats).
The draft explained that there’s good reason to separate the logical processes. For example, it allows identity and authentication to exist in other processes (such as OAuth).
The authors believe the architecture should scale up to support at least 50,000 clients and those who access chat systems from multiple devices.
The privacy of message content isn’t the only thing that can compromise users, as anyone familiar with metadata collection knows, and the draft acknowledged that.
“The protocol is designed in a way that limits the server-side [authentication service (AS) and DS] metadata footprint,” the document said. “The DS must only persist data required for the delivery of messages and avoid Personally Identifiable Information (PII) or other sensitive metadata wherever possible. A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS.”
They said message authentication is important to make sure that members can neither impersonate other members, nor deny messages they sent. ®
Article source: http://go.theregister.com/feed/www.theregister.co.uk/2018/08/22/ietf_draft_proposes_encrypted_message_security_for_all/
Mozilla has wiped 23 extensions from its directory of Firefox browser add-ons after finding what it says were inappropriate functions in the code.
The incident follows a report last week that German security add-on ‘Web Security’ had been misbehaving. Mozilla had highlighted the add-on in a blog post promoting a collection of security-focused extensions to the browser. That prompted eagle-eyed techies to pick apart the program and find out exactly what it was doing. They discovered it assigning each user an ID and sending information labelled ‘old-URL’ and ‘new-URL’ to a consistent IP address.
Mozilla did not immediately remove Web Security from its list of available extensions, although it did axe it from the blog post. Then, however, Mozilla engineer Rob Wu dug deeper, analysing the add-on’s code to understand its algorithm. He then checked all other browser extensions in the Firefox portfolio for similar patterns and found 22 of them.
Wu divided the patterns into two groups. The first sends browsing information to a remote server which could potentially launch a remote code execution attack on the client. Several of the now-banned extensions communicated with the same web server as Web Security.
The second doesn’t collect URL information, but is still able to launch a remote code execution attack on the client. This code was heavily obfuscated, said Wu.
Speaking to Bleeping Computer, Wu said:
All of these extensions used subtle code obfuscation, where actual legitimate extension functionality is mixed with seemingly innocent code, spread over multiple locations and files. The sheer number of misleading identifiers, obfuscated URLs / constants, and covert data flows left me with little doubt about the intentions of the author: It is apparent that they tried to hide malicious code in their add-on.
The discovery led Mozilla to take down a total of 23 add-ons from the Firefox extension collection. Going further still, engineers disabled the add-ons in users’ browsers, effectively wiping them from the entire ecosystem.
Some of the offending add-ons, including Web Security, came from German software developer Creative Software Solutions. Managing director Fabian Simon is less than impressed with Mozilla’s move. He commented directly on the bug report produced by the Mozilla engineers:
We use the ID to build a security chain that can consist of up to 5 consecutive requests. Should the user enter a malicious website, then the transferred “old URL” and the “new URL” can be used to track from which website the user came to this malicious website.
Malicious pages get a ‘red’ rating, he explained, adding that pages linking to them are tagged ‘yellow’. In addition to the ID and old and new URL data, the extension also sent information labelled ‘hash’, ‘app’, ‘agent’ and ‘language’. He said:
All this data is used to improve our heuristics and threat analysis. The transmitted data is stored for a maximum of 15 minutes on our German servers and cannot be used to identify a natural person.
Simon added that the company would remove this data in the next update.
He ‘fessed up to poor encryption measures in the software, adding that the company has now introduced SSL encryption on the server side and has updated the add-ons to support it on the client side, should Mozilla reinstate them. He concluded:
We regret the incident and would like to have the opportunity to regain the confidence placed in us by the users.
On Sunday, Mozilla had not responded to his comments in that thread.
Regardless of which side you come down on, the incident highlights the fact that browser add-ons can often do things without the knowledge of users. In July, researchers discovered an extensive list of add-ons for both Chrome and Firefox that made a list of every address of every webpage ever visited, combining it with a unique identifier. When it comes to browser privacy, that’s an unequivocal fail.
Follow @DannyBradbury
Follow @NakedSecurity
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/GWTi--T1kjA/
You’re in a long queue at the station and your train is due soon, but there are four ticket windows open and things are moving quickly and smoothly.
You’ll have plenty of time to buy your ticket, saunter to the platform and be off on your journey.
But then one of the ticket officials puts up a POSITION CLOSED sign and goes off shift; IT arrives to service the credit card machine at the second window; the third window gets a paper jam…
…and you hear the customer at the last working window say, “I’ve changed my mind – I don’t want to travel via Central London after all, so I’d like to cancel these tickets I just bought and find a cheaper route.”
A delay that would have been little more than a irritation at any other time ends up causing a Denial of Service attack on your travel.
It won’t take you an extra hour to buy your ticket, but it will take you an extra hour to wait for the next train after you’ve narrowly missed the one you thought you’d timed perfectly.
If this has ever happened to you, you’ll appreciate this research paper from at the recent USENIX 2018 conference: Freezing the Web: A Study of ReDoS Vulnerabilities in JavaScript-based Web Servers.
The connection between missed trains and frozen websites might not immediately be obvious, so let’s explain.
Old-school (OK, old-school-ish) web servers like Apache typically use a separate process or thread to handle each connection that arrives.
Processes and threads aren’t quite the same – typically a process is a running app in its own right; each process can then subdivided into a number of sub-applications called threads, sometimes referred to as lightweight processes. Nevertheless, you can think of a both processes and threads as programs – they’re created, launched, scheduled, managed and killed off by the operating system. This means there’s quite a lot of overhead in starting, switching and stopping them – load that can really get in the way on a busy web server that’s handling hundreds or thousands of short-lived connections every second.
In our station ticket office analogy, a multi-process or multi-threaded web server wheels out your very own temporary ticket window when you arrive, and you’re assigned to it regardless of what’s going on at other ticket windows.
Under modest load, this works really well, because you’re insulated from the effects of being mixed in with other travellers, some of whom might ask questions that unexpectedly take a long time to answer and hold everyone up.
But under heavy load, the the multi-process model starts to get sluggish – the server and operating system take longer building separate ticket windows for everyone than they do issuing tickets, so everyone waits longer than necessary.
Many modern web servers, therefore, notably those written in JavaScript using progamming environments such as Node.js, are event-driven rather than connection-driven.
Loosely speaking, the system assigns one process to handle all the network traffic, working on any user’s outstanding transactions only when there’s something new to go on.
This model is more like the waiting area in a burger joint or a fish-and-chip shop, where you place your order on arrival; when it’s ready, someone calls your number so you can collect your food and leave.
While you’re waiting, there’s no point in having a member of staff assigned specially to look after you, or a cash register already allocated to you but tied up until it’s your time to pay.
The staff in a burger bar or chip shop might as well ignore you while you’re waiting – you’ll be waiting anyway, after all – and get on undistracted with other work.
As long as they alert you promptly enough when your order is ready, overall efficiency will typically be higher and therefore everyone’s overall waiting time will be shorter.
That’s the theory, anyway.
The event-driven model does have one weak spot: it can clog up disastrously if even a few key steps in the process take longer than anticipated.
That’s a bit like seeing your burger congealing slowly and sadly behind the counter if you’re order number 32 but the person who calls out the orders is side-tracked trying to sort out an argument with customer 31.
In other words, event-driven servers can be highly efficient…
…provided that they don’t get bogged down dealing with unusual or unexpected events.
And that’s what our researchers went looking for: routine content-handling code in JavaScript web servers that handled unexpected data badly.
As you can imagine, web servers need to do a lot of text-based pattern matching in order to deconstruct incoming web requests, which might look like this:
GET /products/info.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept-Language: en;q=0.5
The jargon term for pulling text input apart into its important components is parsing.
In the web request above:
GET line needs to be chopped up at each space character.
Accept-language header then needs splitting up at the semicolon.
q=0.5 need to be broken into “key=value” form at the equals sign. (Q is HTTP header shorthand for ‘quality’, although here it rather meaninglessly denotes ‘preference’.)
In many modern programming languages, notably JavaScript, the go-to technique for text matching is a tool called the Regular Expression, or RE for short.
That’s where the cool-sounding threat name ReDoS in the paper title comes from: it means Denial of Service (bogging down the server) through Regular Expressions.
Let’s look at the problem of taking the text string q=0.5 and splitting it up into q and 0.5, so we can interpret its meaning.
The old-school way of doing it, familiar to anyone who’s used BASIC, would be to code it by hand, starting with something like this:
POS = FIND(STR$,'=')
We’re assuming that that FIND looks for the position of the first ‘=’ character sign in the text variable STR$, and returns its position, from 1 (the offset of the first character) to LEN(STR$), the length of the string (the offset of the last character).
If FIND comes back with zero, it means it found nothing; otherwise, it tells us where the match happened, so we know where to split the input into the key (the left-hand side) and the value (the right-hand side).
We need to take (POS-1) characters from the left of the equals sign for the key; for the value, we take POS characters less than the length of the string from the right hand end:
POS = FIND(STR$,"=") : REM Look for an equals IF POS 0 THEN : REM If there is one... KEY$ = LEFT$(STR$,POS-1) : REM ...chop from the left VAL$ = RIGHT$(STR$,LEN(STR$)-POS) : REM ...and to the right END
That code is fairly easy to understand, and very efficient, because it precisely encodes the simple algorithm of “look for the splitting point and then do the chopping”.
But it’s a bit of a pain to have to spell out the process of matching the pattern instead of just being able to express a pattern and let a matching utility do the work, which is what you can do with regular expressions.
Here’s an RE that could be used, not correctly but effectively enough, in place of the hard-wired code above: (.+)=(.+).
REs look cryptic, because of the weird and confusing way they use characters as abbreviations – indeed, their cryptic look makes them easy to get wrong:
Once you get used to REs, however, they’re hard to wean yourself off, because they’re simple and, well, expressive.
In a contemporary programming language, you might be able to replace something like this, where str.find matches a character and str.sub explicitly extracts a substring…
pos = str.find('=')
if pos then
key = str.sub(1,pos-1)
val = str.sub(pos+1)
else
key = nil
end
…with the rather more elegant-looking, and more easily tweaked, use of an RE-matching library:
key,val = str.match('(.+)=(.+)')
The problem, as the researchers of the ReDoS paper point out, is that REs like the one above do the job you want, and easily pass software acceptance tests, yet do their job wrongly.
The problem is that the RE above matches anywhere in the input text, and the str.match function tries as hard as it can to find a match – a time-consuming side-effect that you probably won’t notice until:
Note that the only character this RE has to latch onto explicitly is an equals sign.
If there isn’t an equals sign, the RE will try to match its pattern starting at offset 1 in the input string, but will fail; the matcher will then try again from offset 2, and fail again; then from the third character along; and so on.
As a result, it will test out its pattern against characters 1 to LEN in the input; then redundantly against characters 2 to LEN, which will fail again; and so on until there are fewer than three characters left. (The RE can’t match fewer than three characters – the pattern calls for at least one before the equals, the equals itself, and at least one after it.)
If there are LEN characters in the input, the matching function ends up running LEN times, against an average of LEN/2 characters, which is proportional to the square of LEN, causing a massive crunch in performance as LEN increases.
You need to tell the RE matcher to lock the match to the start of the input so that it only goes through the input data once.
For that, you can use the special RE characters ^, which means “match only at the very start”, and $, which means “match only the the very end”.
This is known as anchoring the search.
The difference in performance is enormous, and gets quadratically worse for the unanchored match as the input gets longer.
Note that in the graphs below, the axis showing the linear performance of the anchored match tops out at 2/1000ths of second for a 100K input string, while the quadratically performing unanchored match takes more than one full second for the same job.
That’s 500 times slower because of the missing lockdown character ^ at the start of the RE, with the discrepancy getting worse at an ever increasing rate as the input size increases further:
The ReDoS paper isn’t terribly bad news, but it is a potent reminder that code that looks right, and that actually works, may fail badly in real life.
In particular, clogging up an event-driven web server with pathologically devised HTTP headers – parsing that is performed as matter of routine for every incoming request – could make an otherwise-secure server easy to “freeze” with a ReDoS attack.
The researchers discovered numerous examples of real-world code that could, in theory, very easily be brought to its knees because of an overly casual use of regular expressions to pre-process web headers.
If you can figure out a malformed header that a badly-chosen string matching RE will choke on, you’ve got the raw material for a ReDoS.
In some cases, the risky REs – the possible causes of a ReDoS – were not unique to one company’s customised code, but were inherited from a standard programming library.
Fortunately, the problems are easily fixed:
Follow @NakedSecurity
Follow @duckblog
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/SkZOE8raC-M/