DevCentral

F5 Networks Response to US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security Summary When properly configured, the F5 BIG-IP addresses nearly all the concerns, and avoids nearly all the risks, specified in US-CERT Alert (TA17-075A). This is the key point; on BIG-IP most of the functionality, and the level of security, is determined by the customer created configuration. Whether certificates are validated, and the level of validation, is determined by the configuration, as are the specific cipher suites and protocols that are supported, etc. There are a couple of corner cases, as explained below, where the BIG-IP does not fully meet the recommendations; F5 Networks is continuously improving our products and working to address these areas in future releases. In short, when properly configured, the F5 BIG-IP or SSL Orchestrator can perform SSL Interception without compromising overall security. Detailed Examination A great deal of interest has been generated by the recent publication of US-CERT Alert (TA17-075A) HTTPS Interception Weakens TLS Security. This is of interest to F5 customers as we do support SSL Intercept on BIG-IP, as well as commonly being used for SSL/TLS termination. While the US-CERT Alert does not name F5 Networks, a primary reference for the alert is a two year old blog post, The Risks of SSL Inspection, which does. It is important to acknowledge upfront that the concern, in general, is not unwarranted. Any point where encrypted communications are decrypted, such as for SSL Intercept, is a potential weak link in the chain, a point of increased vulnerability. But it is equally important to acknowledge that such interception may be necessary as part of a comprehensive security solution. Interception allows for traffic inspection, such as to protect networks from malware or phishing attempts. It is also used for scanning inbound & outbound traffic for evidence of data extraction or an existing intrusion. Without the use of SSL/TLS Interception at an ingress or egress chokepoint, the same level of protection could only be achieved by monitoring every end-point device on the network. End-point protection is much more resource intensive, and it may not be practical to do so on appliances such as routers, switches, or even networked printers. With the growth of the Internet of Things (IoT) endpoint-based protection is increasingly unfeasible. It is not possible to run detection software on every connected thermostat or lightbulb. Malware is increasingly using encrypted communication to hide from conventional detection systems, and interception is required to level the playing field. In response to the question of ‘why use or support SSL/TLS interception at all?’ consider an even larger question: If not SSL/TLS interception, how do you provide equivalent protection? Using interception may add some risk, but there are greater risks in not detecting and blocking malware, phishing attempts, intrusions, etc. Security is about minimizing the overall risk, and tradeoffs are required. SSL/TLS interception is a useful tool and when used well it adds minimal risk while providing a great security benefit. While the US-CERT Alert generalizes, the cited blog post raised specific technical concerns which have subsequently been raised by customers. These points are addressed in Appendix A. A second reference cited in the alert, a research paper, The Security Impact of HTTPS Interception, touches on several other potential issues. This include the protocols supported by the interception device (allowing a protocol downgrade), the ciphers allowed by the device, etc. On F5 products these are configurable in the associated profiles. The level of security, or vulnerability, is determined by the configuration used by the customer – and not F5 or the BIG-IP inherently. Customers who had additional concerns, or who desire assistance in configuring their BIG-IP to meet their specific needs, are encouraged

My mother used to always tell me two things before I left for school in the morning. Be wary of what ciphers your application supports Never use the Default cipher list unless you have compatibility concerns You may have had a different upbringing from me but my mom's lessons still apply to anyone using SSL/TLS enabled systems. We know from Señor Wagnon's Security Sidebar: Improving Your SSL Labs Test Grade how cumbersome modifying lengthy cipher strings can be to keep your SSL Labs A grade.  We know as BIG-IP matures we update the DEFAULT cipher list to remove deprecated entries and introduce fancy new ones. This causes negative affects on those legacy applications we like to keep lying around.  Lastly, we know that not everyone appreciates meditating in SSH sessions; pondering countless tmm --clientciphers commands to figure out what cipher string they'll need in order to get achieve an SSL Labs A+ grade.  We have a solution for you. Cipher Rules & Groups BIG-IP version 13 introduces Cipher Rules & Groups; an alternate way to visualize, organize, and apply cipher suites to your client and ssl profiles.  You still need a basic understanding of cipher strings and I recommend you review Megazone's article: Cipher Suite Practices and Pitfalls article before gallivanting through Cipher Rules & Groups; you'll stub a toe. Cipher rules and the subsequent groups that contain them allow the same boolean operators used in tmm cipher strings. Boolean Operations in Cipher Groups UNION = Allow the following: INTERSECT = Restrict the Allowed List to the following: DIFFERENCE =Exclude the following from the Allowed List:   F5 includes 5 default cipher rules and applies them via 5 default cipher groups of the same name (included is the tmm command to view each cipher list used): f5-aes = tmm --clientciphers AES f5-default = tmm --clientciphers DEFAULT f5-ecc = tmm --clientciphers ECDHE:ECDHE_ECDSA f5-secure = tmm --clientciphers ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES f5-hw_keys = tmm --clientciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:RC4-SHA:RC4-MD5:DHE-RSA-DES-CBC-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:!TLSv1:!TLSv1_1:!SSLv3:!DTLSv1 The last one related to HSM ciphers was crazy long wasn't it. This is why we built cipher rules and groups; to prevent you from banging your head on the table because you got the operand wrong somewhere after ECDHE-RSA-AES128-GCM-SHA256. The F5 provided rules and groups are read-only and should used as a reference or starting template. If you rely only on the default F5 cipher rules/groups they will change as our cryptographic requirements change and you could end up with a bunch of incompatible legacy clients. Building A Cipher Rule Because Cipher Rules and Groups are applied to SSL Profiles, you can find them under Local Traffic in the web GUI. Clicking into Local Traffic => Ciphers gives you two options: Cipher Rules and Cipher Groups. I'll create one Cipher Rule based on tmm cipher string ALL:SSLv3:EXPORT. This is only for display purposes to better illustrate the boolean operations when we build the Cipher Group. Current ciphers based on BIG-IP version and Hotfix are listed in the NATIVE cipher list. Remember, we have to support a lot of ciphers that may not be appropriate for public consumption. Building Cipher Groups Now we'll build a Cipher Group

Cipher Suite Practices and Pitfalls It seems like every time you turn around there is a new vulnerability to deal with, and some of them, such as Sweet32, have required altering cipher configurations for mitigation. Still other users may tweak their cipher suite settings to meet requirements for PCI compliance, regulatory issues, local compatibility needs, etc. However, once you start modifying your cipher suite settings you must take great care, as it is very easy to shoot yourself in the foot. Many misconfigurations will silently fail – seeming to achieve the intended result while opening up new, even worse, vulnerabilities. Let's take a look at cipher configuration on the F5 BIG-IP products to try stay on the safe path. What is a Cipher Suite? Before we talk about how they're configured, let's define exactly what we mean by 'cipher suite', how it differs from just a 'cipher', and the components of the suite. Wikipedia had a good summary, so rather than reinvent the wheel: A cipher suite is a named combination of authentication, encryption, message authentication code (MAC) and key exchange algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS) / Secure Sockets Layer (SSL) network protocol. When we talk about configuring ciphers on BIG-IP we're really talking about configuring cipher suites. More specifically the configured list of cipher suites is a menu of options available to be negotiated. Each cipher suite specifies the key exchange algorithm, authentication algorithm, cipher, cipher mode, and MAC that will be used. I recommend reading K15194: Overview of the BIG-IP SSL/TLS cipher suite for more information. But as a quick overview, let's look at a couple of example cipher suites. The cipher suite is in the format: Key Exchange-Authentication-Cipher-Cipher Mode-MAC Note that not all of these components may be explicitly present in the cipher suite, but they are still implicitly part of the suite. Let's consider this cipher suite: ECDHE-RSA-AES256-GCM-SHA384 This breaks down as follows: Key Exchange Algorithm: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) Authentication Algorithm: RSA Cipher: AES256 (aka AES with a 256-bit key) Cipher Mode: GCM (Galois/Counter Mode) MAC: SHA384 (aka SHA-2 (Secure Hash Algorithm 2) with 384-bit hash) This is arguably the strongest cipher suite we have on BIG-IP at this time. Let's compare that to a simpler cipher suite: AES128-SHA Key Exchange Algorithm: RSA (Implied) – When it isn't specified, presume RSA. Authentication Algorithm: RSA (Implied) – When it isn't specified, presume RSA. Cipher: AES128 (aka AES with a 128-bit key) Cipher Mode: CBC (Cipher Block Chaining) (Implied) – When it isn't specified, presume CBC. MAC: SHA1 (Secure Hash Algorithm 1; SHA-1 always produces a 160-bit hash.) This example illustrates that the cipher suite may not always explicitly specify every parameter, but they're still there. There are 'default' values that are fairly safe to presume when not otherwise specified. If an algorithm isn't specified, it is RSA. That's a safe bet. And if a cipher mode isn't specified it is CBC. Always CBC. Note that all ciphers currently supported on BIG-IP are CBC mode except for AES-GCM and RC4. ALL. I stress this as it has been a recurring source of confusion amongst customers. It isn't only the cipher suites which explicitly state 'CBC' in their name. Let's examine each of these components. This article is primarily about cipher suite configuration and ciphers, and not the SSL/TLS protocol, so I won't dive too deeply here, but I think it helps to have a basic understanding. Forgive me if I simplify a bit. Key Exchange Algorithms As a quick review of the difference between asymmetric key (aka public key) cryptography and symmetric key cryptography: With the asymmetric key you have two ke

The government and cloud security's relationship is surprisingly hands off. Current regulations already extend their umbrellas over our data in flight and rest regardless who's IaaS/SaaS you're using. For us traditional enterprise administrators, the regulations are established and and we follow them to because we're all perfect and deserve raises. But when it comes to "the cloud" we've introduced developers and application admins releasing services to the general public with great hates; sometimes without the checks and balances needed for compliance.  The results are mixed.  Increasingly popular scan-all-the-things method of finding vulnerable systems are weeding out quite a few unprotected cloud-connected data sets. Even the smallest vendor needs to validate their compliance requirements and implement them at the same pace they're implementing publicly available applications. HIPAA The Health Insurance Portability and Accountability Act of 1996 (HIPAA) completed enforcement of security policies on personal health care information (PHI) in 2006. HIPPA includes polices related from control and auditing to intrusion prevention and alerting, data validation, authentication practices, and risk analysis and remediation plans (and a host of other things we admins don't care as much about). We know we're getting compliance wrong because as of January 31st of 2017, the Office of Civil Rights has received since 2003 over 148,292 complaints of violation (complaint != violation). 2017 will see more and more companies deploying cloud services that will start to gray the area between basic PII and PHI.  Think Strava recording your epic bike ride or your Garmin tracking your last run... all store data relevant to you and how it relates to your physical condition. What's more interesting to investigate is what are your rights to your last bike ride's information?  Can it be sold with only basic de-identification? The boundaries between PHI and PII are blurring from our desires to connect our selves so expect a lot of angry people when an insurance provider is found denying a claim based off "acquired" Fitbit data. SOX Thanks ENRON (and Tyco/WorldCom) for getting the Sarbanes-Oxley (SOX) Act of 2020 thrust onto all publicly traded companies.  SOX regulates financial practices and corporate governance divided into 11 titles most of which are related to enforcing basic ethics we apparently take for granted.  Section 802 is a whole different InfoSec ball game regulating data retention, classification, and records keeping to ensure the shredder doesn't get used too much.  And the cloud has made complying with 802's requirements much. Data governance tools, DLP, and enhanced record keeping tools are being introduced into all of our favorite cloud apps from Office 365 to Slack.  It's assumed SOX will play a requirement for many cloud applications so the needed technologies should exist out of the gate.   FIPS The Federal Information Processing Standards (FIPS) standardizes government use in computer systems by non-military agencies and contractors.  Most people are familiar with FIPS 140-2: Security Requirements for Cryptographic Modules because it's so cool and interesting.  FIPS 200: Minimum Security Requirements for Federal Information and Information Systems will be more prevalent as federal providers are encouraged/forced to use authorized cloud resources to migrate off existing internal government IT disasters and deprecating systems.  The massive failure of the Office of Personnel Management and the years-blame game still underway is making private could resources more attractive to existing government entities.  FIPS 200 will play a vital role for those Iaas/Saas providers to ensure they can receive those federal dollars.  It's going to happen, it's already happening; maybe we can stop

Security is a chess board. Of the primary fundamentals in chess the King is the most valuable piece and the Queen is the most powerful piece (in terms of potential flexibility/impact). Stay with me... if we relate these rules to security we can assert the following supposition: Data at rest = King: If you lose your data or worse, data is stolen and exposed, the game is over.  You lost the security game. Data at motion = Queen: Data in motion gives us admins the most flexibility/impact for infrastructure planning and solution choices.  akin to the Queen, it offers flexibility and options but if exposed or captured, the death knell may be near. If security is our chess board; the adoption of cloud infrastructure and resources increase the size of the board (IaaS, SaaS, and private cloud for this metaphor). Seriously... stay with me... if your board size increases, do you: Replace one-for-one the existing pawns with new ones? Not sure why you would do this because they have the same function... maybe you want new pieces on the board to make you feel like you're playing a new game. Change your style of gameplay to hopefully create value-add off existing game pieces? You can increase their usefulness across the larger board by being creative... right? Add additional pieces to compliment the existing pieces? Imagine if you had three more pawns, an extra rook, bishop, and knight? If you didn't guess already, the other pieces on the board represent your IT security solutions. You could get by for a while with answer B but sooner or later, your opponent is going to whittle you down. If you answered A go into sales or marketing because you're selling up technology as a solution to a problem you never understood. If you're someone who evaluated changes in the chess board and chose additional pieces to play, you know answer C is the correct one. Don't sabotage your existing security model because there's a few new pieces to play with. The new game board allows for NEW attack vectors against your King, it doesn't necessarily remove the old ones. By the way, pieces != vendors, they represent solutions to prevent those spaces from exposure and exploitation. Our metaphor is mostly but you saw where I was going right?   Cloud Security Is The Same Security With A New Home Security trends for 2017 seem to lead us towards new technology under the guise that we'e been doing it wrong this whole time and new product X will solve all your security needs. Threatstack summary of Gartner's 2017 Cloud Security key findings confirm what we already know: Consensus doesn't exist on what constitutes best practices for cloud security; this is creating organizational issues for control process Vendor focus on specific areas of cloud technologies (IaaS) is drawing attention away from other control vectors (SaaS) but is yet no less critical Gartner's findings marry well to previous risk analysis; CSA's 2016 study of top 12 threats remain mostly unchanged (including top 5): Data breaches (Losing your King) Weak Identity, Credential, and Access Management Insecure APIs Account Hijacking Malicious Insiders Emerging acronyms in cloud security deserve closer inspection which aim to address Gartner and CSA's analysis.   An Extra Knight For The Board: Cloud Access Security Brokers CASBs are security policy enforcement points, placing inline security policies, encryption, identity management, and a host of other features against cloud service consumers and providers. Yes, it's existing technologies wrapped up with a nice bow but is no less important on premise or in the cloud.  If you're already playing in the cloud chances are you already have some form of CASB, and if you're a datacenter traditionalist, you definitely have some of these services (TACACS, SSO/Federation services, RBAC). CASB's do encapsulate a lot of disparate solutions into a service offering which may allevi

We are mobile, our devices are mobile, the networks we connect to are mobile and the applications we access are mobile. Mobility, in all its iterations, is a huge enabler and concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. If the last 10 years wasn’t warning enough, 2017 will be a huge year for mobile…again. Every year, it seems, new security opportunities, challenges and questions surround the mobile landscape. And now it encompasses more than just the device that causes phantom vibration syndrome, it now involves the dizzying array of sensors, devices and automatons in our households, offices and municipalities. Mobile has infiltrated our society and our bodies along with it. So the security stakes are high. The more we become one with our mobile devices, the more they become targets. It holds our most precious secrets which can be very valuable. We need to use care when operating such a device since, in many ways, our lives depend on it. And with the increased automation, digitization and data gathering, there are always security concerns. So how do we stay safe? The consumerization of IT technologies has made us all administrators of our personal infrastructure of connected devices. Our digital self has become a life of its own. As individuals we need to stay vigilant about clicking suspicious links, updating software, changing passwords, backing up data, watching financial accounts, having AV/FW and generally locking down devices like we do the doors to our home. Even then, the smartphone enabled deadbolt can be a risk. And we haven’t even touched on mobile payment systems, IoT botnets or the untested, insecure apps on the mobile phone itself. Cybersecurity is a social issue that impacts us all and we all need to be accountable. For enterprises, mobile devices carry an increased risk, especially personal devices connecting to an internal network. From regulatory compliance to the disgruntled employee, keeping sensitive information secret is top concern. BYOD policies and MDM solutions help as does segmenting those devices away from critical info. And the issue isn’t so much seeing restricted information, especially if your job requires it, it is more about unauthorized access if the device is compromised or lost. Many organizations have policies in place to combat this, including a total device wipe…which may also blast your personal keepsakes. The endpoint security market is maturing but won’t fill the ever-present security gaps. From your workforce to your customers, your mobile web applications are also a target. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. Around 230,000 unique phishing campaigns a month, many aimed at mobile devices arriving as worrisome text messages. Late 2016 saw mobile browsing overtake desktop for the first time and Google now favors mobile-friendly websites for its mobile search results. A double compatibility and SEO whammy. And those two might not be the biggest risk to an organization since weakest link in the security ecosystem might be third-party vendors and suppliers. On the industrial side, tractors, weather sensors, street lights, HVAC systems, your car and other critical infrastructure are now mobile devices with their own unique security implications. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, farms, and even entire cities. The Digital Dress Code has emerged and with 5G on the way, mobile device security takes on a whole new meaning. ps Related: Mobile Trends For 2017 And Beyond Perspectives on Securing Mobile and Social Business, 12 Months On R

When your business is facing a security crisis, F5 has a team dedicated to helping you through it – the F5 Security Incident Response Team (F5 SIRT). During a security incident, the F5 SIRT engages rapidly with the resources you need to respond. The F5 SIRT also evaluates potential and published vulnerabilities and provides timely alerts to help you manage risks and deploy mitigation – before an attack brings down your business. Dedicated to quickly and effectively mitigating attacks and vulnerabilities to get your operations back to business as usual, this focused team of expert F5 security engineers, available globally and 24/7, applies passion and a proven process to mitigate new attacks, manage investigations, and help you address any vulnerabilities related to F5 products and services. Backed by extensive F5 insight and security experience, the F5 SIRT works with you to immediately address issues and enhance your protection going forward. The F5 SIRT works to protect your user identities, applications, corporate assets, and customer data. The team’s engineers coordinate with other F5 groups to develop ready-to-deploy technical countermeasures, share them with you, and help you put them in place. But the response doesn’t stop when the attack does; the team looks beyond the reported incident to reduce the overall harm to your organization, as well as understand, anticipate, and deter future threats. The F5 SIRT is composed of experienced security engineers who are well-versed in a broad range of security threats and incident handling methodologies and backed by the full F5 organization.  The F5 SIRT follows industry-standard incident response methodologies and adheres to the ISO 9001-certified F5 Quality Management System, including the creation of procedures to drive mitigation of security incidents, attack analysis, vulnerability response, and reporting.   How do I engage the F5 SIRT? Customers primarily engage the F5 SIRT via the Emergency Security Response Process (ESRP).  The ESRP is designed to bring the appropriate resources to bear on your security emergency, quickly; getting your operations back to business as usual.  The ESRP may be triggered by any F5 customer with a valid support agreement: simply inform the F5 support representative that you’re experiencing a security related emergency, such as an ongoing attack, when opening a case.  The F5 support representative will invoke the ESRP to engage the most appropriate resources to address your issue, including the F5 SIRT. The reality of the Internet today is that every connected network could be attacked at any time.  No one wants it to happen to them, but if it does you want experienced professionals in your corner, ready to work with you.  The ESRP establishes standardized procedures and guidelines for F5 support to provide you with the most effective emergency response, bringing F5’s resources to bear when you need them most.  You may also benefit from the work of the F5 SIRT by signing up for the F5 Security Alerts.  The F5 SIRT is also involved in the creation of many of the Security Advisories published on AskF5.  You may wish to create an RSS feed for new and updated security advisories so you’re always up to date on the latest notices from F5. Additionally, if you discover any potential security issues or vulnerabilities relating to F5 products or services, we encourage you to report them.  We recommend that existing F5 customers do so by opening a support case through normal channels.  For those who are not existing F5 customers, such as security researchers, we ask that you follow responsible disclosure and email the F5 SIRT at [email protected].  We’ll respond to arrange a secure communications channel, and investigate immediately.  For more information, see our Vulnerability Policy. The security and availability of customer and company da

Ransomware is a specific type of malware that encrypts important information and keeps it encrypted until the ransom (typically money) has been paid.  Until very recently, ransomware was not a widely-used type of malware, but it has absolutely exploded in popularity in the past few years.  SonicWall reported 3.8 million ransomware attacks in 2015 and then 638 million attacks in 2016!  That 167 times larger...in just one year.  If ransomware is growing this quickly, then it's fair and responsible to talk about it and figure out what to if you ever get attacked with it. Ransom (noun):  money that is paid or demanded for the release of someone or something from captivity The following graph shows various examples of ransomware over time.  Notice the concentration in the past few years.  This shows that many attackers are focusing their coding efforts on ransomware, and would-be criminals have a seemingly endless selection from which to choose.     Why the sudden rise in ransomware, you ask?  Great question.  The answer: it works, and it's lucrative.  In 2016 alone, an estimated $1 Billion was paid out in ransomware fees.  Ransomware has always been a technical option for attackers (it's not entirely hard to plant malware on someone's computer and encrypt a bunch of their files), but the main problem rose out of the payment part of the ransom.  In years past, attackers didn't have a convenient and reliable way to anonymously accept ransom payment.  But now, they have a very easy way to conduct anonymous financial transactions online...it's called Bitcoin.  Bitcoin plays a huge role in ransomware because it is both anonymous and popular as a form of online payment.  Before Bitcoin, it was nearly impossible to accept payment for the ransom without getting caught.  Now, you can exchange money via Bitcoin and no one can track it.  Since anonymous payment options are available and ransom malware is easily accessible, ransomware has become a very popular tool for attackers.   When a person or company is the target of ransomware, the fundamental decision of that person or company centers around the payment of the ransom.  Do you pay or not?  If you don't pay, you definitly won't get your data back.  Of course, even if you do pay, there's no guarantee that you'll get your money back.  In 2016, less than half of all companies that were attacked actually recovered all of their data.  It's good to discuss these decisions prior to getting attacked.  Here are some recent examples of companies that were attacked and chose to pay the ransom:  Feb 2016 - Hollywood Presbyterian Medical Center in Los Angeles payed 40 Bitcoin ($17,000 at the time) to get its data back April 2016 - The Lansing Board of Water & Light (BWL) paid $25,000 to get their data back May 2016 - Kansas Heart Hospital was attacked and paid the ransom only to have the attackers demand more ransom and still not give access to their data September 2016 - Hosted desktop and cloud provider VESK paid 29 Bitcoins (about $23,000 at the time) to get their data back. November 2016 - Hackers demanded 100 Bitcoins (about $73,000 at the time) from the San Francisco Municipal Transit Authority to get their systems back online.   December 2016 - The Cockrell Hill Police Department was attacked with ransomware and the demand was $4,000 in Bitcoin I could go on with many more examples, but you see the point.  Ransomware attacks are on the rise, and you need to be prepared for one.  In just about every one of these cases, the ransomware was planted via a malicious file attached to an email or website.  The old idea of "don't open suspicious attachments" and "don't click on suspicious links" still completely rings true today. &nbs

FINISH HIM!  SSHowDowN Wins!  The proxy attack Akamai published on last October of 2016 sound like a character from Mortal Kombat. That would be a fun MK character, a little digitized malware-bot killing Sub-Zero or Goro.  In reality and actually a real world threat, SSHowDowN's a proxy exploit of OpenSSH daemons running on exposed devices (yes, the same devices that everyone's pwning these days). Where Mirai exploited user failure to change default username/password combos (and disable telnet), SSHowDowN exploited 12 year old vulnerability CVE-2004-1653 which allows OpenSSH to be used a a TCP tunnel for malicious traffic not originating on system.  The issues are two-fold, A) we have devices shipping with SSH exposed and tunneling features enabled on public interfaces, and B) it's been out there for 12 years.  We have to assume exploits exist we don't know about and enterprise-adopted source code is public; both good and bad users now have chances to pour over decades of material, looking for these hidden gems.  2016 gave us many more exploits of old known bugs so why are old bugs still causing us heartache?   What The Experts Say HPE Security Research's 2016 Cyber Risk Report listed 7 major themes for the previous year; them three strike chords related to this article: Theme #5: The industry didn't learn anything about patching in 2015 Theme #6: Attackers have shifted their efforts to directly attack applications Theme #7: The monetization of malware Additionally, patching vulnerabilities involves 4 generalized steps: Researcher uncovers vulnerability; reports to vendor Developers implement a fix Vendor releases a patch End user deploys a software update The first step is usually made through a bug bounty program and here we run into a flaw: White versus Gray versus Black markets have made bugs a very lucrative mini-industry.  Monetizing exploits is now big business and creates divergent paths for fixing known vulnerabilities for the various hat-colored people. White Hats make money via bug bounties, Gray Hats make money by selling through private brokers who supposedly resell to ethical and approved sources.  And then there's Black Hats and they do what they do best.   An Update Is Available... But You Can Keep Your Vulnerabilities April of 2016 saw Oracle publish technical information to the public on the known vulnerabilities of older editions of Java and steps to reduce client risk. This alerted the general public that newer versions of Java installed along side previous versions instead of overwriting the previous install.  Some developers do require multiple versions of Java and that's a handy feature. For most people installing Java (read consumers) this was an unknown. This allowed old public vulnerabilities to coexist with their patched counterparts, undermining patching efforts.  Oracle did create uninstall procedure instructions and published alerts through various media outlets; because it was required to by the FTC.  In this case because known vulnerabilities were listed as fixed in release notes, a malicious user could simply read Oracle's documentation on how to bypass older versions.   That Bug Is Old Enough To Drink May of 2016 saw Slackware releasing a patch for a 21-year-old bug which allowed a malicious user to execute remote DoS attacks by exploiting CVE-2016-10087; a null-pointer-deference bug in png_set_text_2 ().  The Libpng owners in their own documentation warned of the flaw since July of 2000.  Now pause... the CVE is new, the library's been around for a long time, and the flaw was known and documented.  This re-raises public discussion on ownership's responsibility of code made popular during the Shellshock and Heartbleed blame games.  What CVE-2016-10087 does illustrate is a lot of open source is capable of being investigated and potentially exploited.  Mind

The term pervasive insecurity defines widespread and unwelcome instability or weaknesses in standardized systems. These systems are usually complex and can include poverty, political landscapes, or civil unrest. It's also a fantastic term to illustrate the train wreck of information systems security failures and publicized vulnerabilities last year.  Over the last year we've seen booming trends against embedded device exploits, data ransoming, and similar public displays of nefarious behavior.  Why was 2016 such a banner year for exploitation?  Who got pwned? What's our next steps to not protect ourselves but prevent our selves from being unknowing agents in coordinated attacks across the internet?   The Data Didn't Look Good Then, Do You Think It Got Better? In 2010 researchers at Columbia University published results of a internet scan including basic analysis of connected devices and their potential for exploit using only low or basic levels of effort.  Researchers were trying to discern past exploits, large scale attack feasibilities, amount of discoverable devices, and potential methods of securing devices.  The numbers they published would be intimidating by today's standards but given we've had 6 years to continue the trend of inscurity, it's only getting worse. Creepy Results Of Default Credential Scan (2010) IP's scanned: 3,223,358,720 Devices Targeted Post Discovery: 3,912,574 Vulnerable Devices: 540,435 Vulnerability Rate: 13.81% Section 4.1 of the paper specifically calls out the DDoS potentials of devices identified in the study.  Remember... 2010 people.  If this threat isn't new and was well documented back in 2010, why is 2016 special?   Infecting the Internet Of Things In You House Mirai was your big news source of late 2016 not because it exploited what the Columbia researchers knew in 2010, it was the largest publicized example that insecure connected systems pose.  First KrebsOnSecurity experienced a ~620Gbps DDoS attack and shortly after OVH Cloud Solutions experienced a 1Tbps peak bandwidth attack.  The reported 150,000+ connected home devices participating provided from 1Mbps to 30Mbps of bandwidth; together it was the largest known DDoS attack published to date.  The true reasoning theorized by Brian Krebs may or may not be true but we didn't witness the potential Mirai posed.  By releasing the source code Mirai's secret weapon of quietly locking systems could be outdone by someone willing to modify the code further.  Diluting the compromised devices with multiple sources  reduce each command and control servers effective attacking potential and so far, exploiters haven't been known to work together yet.   You Didn't Do What To The Database?!?  And Our Data Is Where?!? Poor MongoDB.  It was the first public name associated with a string of database ransom requests starting late in 2016 and extending to... well... it's still going. Bleepingcomputer's coverage on security researchers Victor Gevers and Niall Merrigan investigation of multiple groups responsible for deleting databases and leaving ransom notes (not per the norm of encrypting and leaving on service).  To date the attacks are against MongoDB, CouchDB, Hadoop, and Elastic Server services.  Reading the tweets by Victor and Niall, the fever pitch of updates is comparable to race track announcers.  And just like the Columbia researchers warned, these are not high level complex attacks.  The systems compromised were exposed instances with no modified access controls or elevated authentication and the combined tally of pwned systems is hitting 50,000.  As of today, Cassandra databases are now receiving threats to secure data.  This is becoming a Game Of Thrones nailbiter and I want to keep reading! Someone is warning unaware unprotected Cassandra database (https://t.