Week 7 - Threat of the Week - Denial of Service

In Week 7 we are nearing the end of STRIDE, and have come to Denial of Service.  A key component of security is availability.  In today's world of eCommerce and viral marketing companies all want to drive the most visitors to their site.  If the web servers are not able to handle the connections users will see the dreaded "Page Cannot Be Displayed" error message.  Why it's possible this is caused by a huge number of legitimate consumers, a sort of good problem, it's also possible that a DoS or DDoS attack is occurring.

Launching a Distributed Denial of Service attack sounds like it would be something only available to top hackers.  In a standard DoS attack simply blocking the traffic, or discarding all traffic, from the source IP address may be enough to end the attack.  With a DDoS attack there could be hundreds or many thousands of source IP addresses.  The attack could also evolve so the source addresses are changing throughout the attack.  That makes traditional mitigation methods entirely ineffective. 

Now for the even worse news. Bad actors have decided to offer up botnets for DDoS attacks using the same subscription model that modern companies use for their software.  It's possible for anyone that has access to the Internet, and in most cases some Bitcoin for payment, the ability to start launching DDoS attacks.  According to CSO Online the cost for renting that type of attack could cost as little as $10/month.  So not only does the attack not take any skill, it also is cheap enough that it's accessible to nearly anyone.  This price scales up, and there are indications that even the massive Mirai botnet with more than 400,000 devices can be rented. 

With the ease of the attacks now it can be difficult for companies to defend against them.  eSecurity Planet recommends that companies hosting web servers take some basic precautions.  Just like with other incidents you should have a DDoS policy and procedure to follow.  It's also a good idea to move websites to hosting companies.  Dedicated hosting companies have higher bandwidth and high performing routers that can better withstand the attacks.  Coupled with staff experienced in handling DDoS attacks a web host can be a great ally in your security team.




https://www.esecurityplanet.com/network-security/5-tips-for-fighting-ddos-attacks.html

https://www.bleepingcomputer.com/news/security/you-can-now-rent-a-mirai-botnet-of-400-000-bots/

https://www.csoonline.com/article/3180246/data-protection/hire-a-ddos-service-to-take-down-your-enemies.html

https://www.wired.com/story/reaper-iot-botnet-infected-million-networks/ 

https://www.cisco.com/c/en/us/products/collateral/security/traffic-anomaly-detector-xt-5600a/prod_white_paper0900aecd8011e927.html

Week 6 - Threat of the Week - Information Disclosure

In the world of IT security information disclosure boils down to people seeing information that they are not authorized to see.  This could be something as simple as having inadequate security controls on a file server allowing all users in the company to access employee review files.  More recently though there have been 2 information disclosure vulnerabilities published that affect nearly every device.

Of course the two vulnerabilities that I speak of are Meltdown and Spectre.  While the vulnerabilities are often reported together, they are two separate things, and they affect different CPU's.  The Meltdown is limited to Intel, while Spectre impacts essentially every CPU from Intel to AMD, to IBM to ARM.  The vulnerabilities are very similar in that they exploit the very way that processors were engineered for maximum efficiency.  Meltdown and Spectre use the speculation around memory access to leak data from the kernel that should in theory be inaccessible.

This is a huge deal not only because of the widespread nature of it, but also because there is not necessarily a simple fix.  While some software updates have been released to patch pieces of it, it may require new microcode to help fix remaining vulnerabilities.  Early patches that have been released have caused a lot of system instability, and as such many vendors are recommending you do not install the patches until they are fixed.  Bad actors are also taking advantage of this new fear to launch phishing campaigns promising to provide a download for the necessary patches to fix your system.

So in the end it doesn't matter if you prefer Windows, Mac, or Linux.  Information Disclosure is coming for you.

https://www.welivesecurity.com/2018/01/05/meltdown-spectre-cpu-vulnerabilities/

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/

Week 5 - Threat of the Week - Repudiation

Repudiation

Repudiation is commonly referred to as non-repudiation, however STNIDE doesn't roll off the tongue quite as nice, so we'll stick to repudiation.  The general idea with repudiation is that when a user or system performs an action, if they say they did not do it, can you prove that they did?  

In network and system infrastructure when you think of repudiation you think of logs.  Logging an action is only helpful if the right information is logged, and the logs are carefully protected against tampering.  Repudiation also comes up frequently when sending and receiving digital messages, especially as organizations look to go paperless.  When legally binding documents are involved, how do both parties guarantee that the document is in the original state when signed? 

I'm going to go a slightly different direction with the topic this week, not that there aren't interesting attacks related to repudiation, but there is a potential solution that also happens to be a current buzzword.  That solution is blockchain. 

Blockchain is essentially a distributed ledger system.  It is a decentralized system, so it does not require a central server to provide approval.  The nodes that are part of the blockchain come to a consensus, the block is updated, and the resulting transaction is immutable and irreversible.  The very way that blockchain works makes it impossible to repudiate the information in it.   

Companies are looking to put this technology to use in a number of ways.  One of the ways is a kind of enhanced digital signature.  Previous methods involved using some sort of trusted third party.  With the automation built in it's possible to setup a system where multiple parties are able to separately, and yet jointly, sign documents electronically.  Once completed another action could kick off.  A common example I saw was in real estate transactions that required multiple parties, including buyer/seller/buyers bank/sellers/bank/real estate agents/etc.  When all of the necessary signatures were obtained it could automatically kick off the resulting funds transfers to each of the parties.     

While it is certainly not mainstream it will be very interesting to see how rapidly this technology not only advances, but how it gets adopted for different uses. 

https://www.computerworld.com/article/3191077/security/what-is-blockchain-the-most-disruptive-tech-in-decades.html

http://www.businessinsider.com/what-is-blockchain-2016-3/#blockchains-are-ledgers-like-excel-spreadsheets-but-they-accept-inputs-from-lots-of-different-parties-the-ledger-can-only-be-changed-when-there-is-a-consensus-among-the-group-that-makes-them-more-secure-and-it-means-theres-no-need-for-a-central-authority-to-approve-transactions-1

https://digusign.com/legal  

https://blog.signatura.co/introducing-signatura-document-signing-on-the-blockchain-a662d6b4b0d8

Week 4 - Threat of the Week - Tampering

Tampering

In it's most simple definition tampering is just modifying something that you are not supposed to modify.  In a target system that could range from network traffic, to application data, to data in cold storage.  The focus of this post will be on web tampering, specifically HTTP Hidden Field tampering. 

HTTP Hidden Fields

A typical web application interacts with users using HTML forms.  Within a web application a developer may use a hidden field as a way to store status information.  OWASP provides an example of an e-commerce website that uses one of the hidden fields to store the cost of a particular item.  

There are a couple dangerous things about this.  The first is that the hidden fields are typically plain text (really more of an information disclosure issue, but still a vulnerability), and the second is that a bad actor could save a form, edit the hidden field, and then send it back to the server.  Hidden fields are usually considered trusted by the web application, so the web app will readily accept the altered hidden field data. 

There are some options to help mitigate the risk of http hidden field modification.  One way is to use an HTTP_REFERER, however that type of validation can often be defeated by a bad actor.  It seems to be the equivalent of closing an open door, but not locking it.  The closed door will prevent the most basic attempts, but anyone who puts in minimal effort to turn the knob can still do what they want.

A better option is to use a session ID and keep the option only stored on the server.  The browser and server communicate using the session ID, so it mitigates the risk of a bad actor being able to read stored data, and also prevents the data from being manipulated.  

https://www.owasp.org/index.php/Web_Parameter_Tampering

https://www.owasp.org/index.php/Unvalidated_Input

http://www.cgisecurity.com/lib/form-tampering.pdf

Week 3 - Threat of the Week - Spoofing

As I continue with the blog, and with threat modeling, I thought it may be interesting to post a weekly update that outlines a unique attack from each category of the STRIDE threat model.  When you threat model with STRIDE you start with Spoofing, so that seems like a great place to start for this blog as well.

SPOOFING

Well just what is spoofing anyway?  While spoofing can refer to impersonating any person, system or process, it very often manifests itself as a bad actor using stolen user credentials to access a system.  It is much easier to access a system using actual user credentials than it would be to gain unauthenticated access.

Credential Stuffing

With the increasing complexity of passwords users are creating password that are difficult to brute force.  For example a user may come up with a random string they can remember, such as:

f4T6*2jmB1($1

According to www.howsecureismypassword.net that particular complex password would take 3 million years to brute force.  So a user can feel really good about that and as such just use that 1 ultra secure password everywhere, right?

That's a great strategy until 1 of the numerous sites that the password was used on is breached, and now your user ID and password is known by the bad actor.  Running automated tools the same user ID and password is 'stuffed' into a huge number of websites hoping to find a match. For the bad actor the ideal match would be something like a banking or credit card web site, perhaps even a corporate system. 

According to OWASP credential stuffing is one of the most common techniques for account spoofing, so that definitely means it is something to keep an eye on.  OWASP does also suggest the use of multi-factor authentication as a preventative measure, and indeed MFA does solve many of the issues related to authentication.  There is of course a trade off as MFA can be complicated and expensive to deploy, and users are often resistant to anything that complicates the logon process. 

https://www.owasp.org/index.php/Credential_stuffing

https://www.owasp.org/index.php/Credential_Stuffing_Prevention_Cheat_Sheet

https://breachinsider.com/blog/2017/credential-stuffing-how-breached-credentials-are-put-to-bad-use/