True Digital Security Blog en-US daily 1 The PCI Penetration Test Scoping Mistake You Don't Want to Make the-pci-penetration-test-scoping-mistake-you-dont-want-to-make Wed, 05 Oct 16 13:06:12 +0000 Most penetration testers are focused on one thing and one thing only: compromising the client. Heck, that's what they are being paid for, right?

That doesn't even make my top four goals. I see a penetration test as a building block for a larger security program.

My goals are simple:

  • Deliver a Penetration Test Report that the client can understand.
  • Deliver a Penetration Test Report that provides clear, prioritized recommendations.
  • Deliver a Penetration Test Report that helps a client fulfill their compliance requirements.
  • Don't bring down the network or interrupt business.

If I manage to compromise a system along the way, that's an added bonus.

Recently, I was performing a penetration test for a client who processes a significant amount of credit card transactions. The organization is required to undergo a formal PCI audit annually using a PCI Qualified Security Assessor (QSA). Now, I am not this organization's QSA. I do, however, perform their annual PCI Penetration Test to meet requirement 11.3 of the PCI DSS.

The report I deliver to the client goes directly to their QSA for inclusion in the audit, and for this reason it is imperative their PCI Penetration Test is audit-ready. It was during this penetration test that I uncovered the client had made a major scoping mistake that would prevent the resulting report from being audit-ready.

Here's how it went down. During the kickoff, I was given two scopes to work with. The PCI Scope was all assets in-scope for the PCI Penetration Test (or so they thought). The Non-PCI Scope was all assets not in scope for PCI. Two reports were requested. The PCI Scope report would be given to the PCI QSA in support of their audit, while the Non-PCI Scope report would be disseminated internally. The idea here is to only give the QSA information relevant to PCI compliance. I fully support this approach, even though it means I have to write two reports instead of one.

As I was working on the Non-PCI Scope penetration test, I was able to compromise a ManageEngine Desktop Central server. I was logged in as admin. With this level of access I can remotely install software, make configuration changes, and remotely login to managed systems. Then, I looked at the list of managed systems. I found many systems from the PCI Scope in the list. The ManageEngine Desktop Central could essentially remotely control systems in the CDE.

The client had made a scoping error. Key systems had been omitted from their PCI Scope including systems management servers, Active Directory domain controllers, and antivirus management servers. Even though these systems were outside the CDE, they could still affect the security of the CDE.

According to official PCI Guidance, "The scope of a penetration test, as defined in PCI DSS Requirement 11.3, must include the entire CDE perimeter and any critical systems that may impact the security of the CDE as well as the environment in scope for PCI DSS."

As originally scoped, the PCI Scope left out critical systems that could impact the security of the CDE. This omission could have caused the client to fail Requirement 11.3. I quickly brought this scoping issue to the attention of the client, we made some adjustments, and they are now in a much better position to pass their audit.

Are you confident in your PCI Penetration Test scope?

What OCR Breach Data Tells Us about Healthcare Information Security what-ocr-breach-data-tells-us-about-healthcare-information-security Thu, 29 Sep 16 15:09:32 +0000 Is your healthcare information security program aligned with the current threat landscape?

I periodically review the DHHS Office of Civil Rights (OCR) Breach Portal Data to better understand the US healthcare threat landscape.

Here's what I found with the major breach cause categories: ocr-reportedhealthcaredatabreachesbycause

The following trends jump out at me:

Hacking/IT Incident Is Surging

Healthcare needs to pay close attention to the Hacking/IT Incident threat category. Ransomware has received a ton of press this year, indicating a real threat to healthcare organizations. In fact, the OCR's recent ransomware fact sheet finally removes any doubt that a HIPAA breach occurs when ransomware encrypts ePHI.

Healthcare organizations must have a plan to prevent and to respond to these threats.

Effective preventative controls include removing administrator privileges from standard employees, patching commonly targeted applications (e.g. Java Runtime, Adobe Reader), and ensuring an updated antivirus client is installed on all systems (even servers).

To limit the impact of these incidents, healthcare organizations need to have well defined response processes, utilize intrusion detection technology, have solid backups, and periodically test their restoration procedures.

A HIPAA Risk Analysis will reveal additional controls that will further address this threat in your unique environment.

Theft-Related Breaches Are Rapidly Declining

In 2010, device theft was the clear leading cause of reported breaches. Since then, theft-related breaches have been on the decline. The occurrence of theft itself is not rapidly declining. Rather, the healthcare industry is learning to prevent unencrypted ePHI from being stored on theft-prone devices.

I work with many healthcare organizations who are severely restricting the ability to export and print data from their EHR. If the PHI can't be taken out of the secured facility, then it is less likely to be stolen.

Additionally, most healthcare organizations I work with now have a defined process in place to encrypt laptops and portable devices. If you can prove that the stolen device was properly encrypted, the organization may satisfy the Safe Harbor provision and avoid a HIPAA breach.

Unauthorized Access/Disclosure Is Still Leading

The most common cause of US healthcare breaches is Unauthorized Access/Disclosure.

The details of these breaches reveal the many cases where authorized individuals and Business Associates mishandled protected health information. Most cases are non-malicious and could have been prevented with awareness & training, third party risk assessments, and with improved data handling processes:

  • In August 2016 Bon Secours Health System reported that one of their Business Associates, R-C Healthcare Management, had inadvertently exposed personal information of 650,000 Bon Secours patients to the Internet.
  • In February 2016 Washington State Health Care Authority discovered that the PHI of 91,187 individuals was mishandled. Two employees exchanged spreadsheets containing ePHI without proper authorization.
  • In June 2016 the University of New Mexico Hospital inadvertently mailed PHI to incorrect addresses due to an error in their billing systems.

Revisiting this reported data periodically is crucial because it gives us insight into the healthcare threat landscape. It is clear to me that in 2016, a risk-based healthcare security program will prioritize efforts to mitigate the Unauthorized Access/Disclosure threat, and will closely follow that with efforts to address the Hacking/IT Incident threat.

Is your security program aligned with the current threat landscape?

TRUE helps healthcare organizations develop risk-based security programs that are simple to follow yet flexible enough to address newly identified threats. If your name ever ends up on the OCR data breach portal, having an audit-ready program in place can be your saving grace, greatly reducing the penalties and keeping the auditors satisfied.

Key Application Security Questions for IT Organizations key-application-security-questions-for-it-organizations Thu, 29 Sep 16 14:39:28 +0000 It's time we give application security the attention it requires. All IT organizations need to address application security. It doesn't matter if you develop applications in-house or buy third party-developed applications.

According to the Ponemon Institute's recent Application Security in the Changing Risk Landscape report:

  1. The frequency and severity of application layer attacks is greater than network layer attacks.
  2. Network security is better funded than application security.


This may sound backward, and it is! The investment in network security heavily outweighs application security.

Here are the key application security questions IT organizations should consider:

  1. Are you centrally patching all third party applications on a routine basis? Commonly targeted applications (e.g. Adobe Reader, Java Runtime, Firefox, etc.) are most critical to update and can give the attacker a backdoor into your network.
  2. Do you routinely test your applications (e.g. mobile apps, web apps) for security flaws? Keep in mind, applications change over time, and periodic testing should be performed.
  3. For third party-developed applications, do you evaluate the security practices of the software providers? Not all vendors treat your data with the same level of security. You need a repeatable process to evaluate the security posture of software vendors and other third parties that present a risk to your organization.
  4. If you develop software in-house, do you utilize secure development practices in all phases of the software development life cycle? Do you train developers on secure coding practices?
  5. Are application logs retained for a reasonable period of time and protected from tampering?
  6. Does your information security team have application security expertise? If not, can you partner with a security provider that can provide this expertise?


What application security challenges does your organization face?

This Printer Configuration Can Compromise Your Entire Windows Domain this-printer-configuration-can-compromise-your-entire-windows-domain Fri, 02 Sep 16 10:29:24 +0000 printer1 The first time I compromised a Windows domain using this printer misconfiguration my jaw dropped to the floor. I had to walk away from the computer for a minute to soak it in.

I had just escalated from zero access to Domain Administrator in under two minutes through the printer user interface. The keys to the kingdom were in my hands. It doesn't get much better than that for a penetration tester. And, it doesn't get much scarier than that for an organization.

Luckily, the vulnerable organization had hired me to perform a penetration test on their network. I told them exactly how I was able to gain Domain Administrator access, and they were able to quickly reconfigure the printer to plug the hole.

Imagine if I had been the bad guy. How long (if ever) would it have taken the company to realize the attacker used a printer misconfiguration to escalate privileges?

Fast forward a month, and I find this same vulnerability in another penetration test for a different organization. Again, I escalated from zero to Domain Administrator with little effort, all thanks to a printer.

I wonder how many organizations are vulnerable to this very issue. Does your penetration test include printers? It should.

I'm going to walk you step-by-step through the exact process I used to compromise two different companies using a printer misconfiguration. Then, I will tell you exactly how to fix the vulnerability. By the end of this blog I can pretty much guarantee that you will be checking your printer configurations.

The Process

During penetration tests I always review systems for default passwords. There's a reason why the PCI DSS has a dedicated requirement (requirement 2.1) for changing default passwords. Inevitably I find a handful of systems with default or easily guessed passwords configured. Most of the time IT admins are unaware these default accounts even exist.

Printers are by far the biggest offenders. Typically, printers are set up hastily, because why secure a printer anyway, right?

Well, I'll tell you why.

One of the more useful features in modern printers is the ability to scan a document at the printer and email it to someone from the printer. In order to facilitate this, many printers integrate with the LDAP server to retrieve a list of valid email addresses.

Then, instead of having to remember the recipient's email address and type it on a clunky touchscreen, the printer can auto-populate the recipient's email address as you begin to type.

Many printers have an LDAP Authentication or Configuration setting section where you can input credentials for the printer to connect to the LDAP server and retrieve valid email addresses.

In these two vulnerable organizations the IT admins did not follow the principle of least privilege, and configured the LDAP connection settings with a Domain Administrator account.

If you configure a password in the printer's web user interface, it will usually appear masked. Instead of the characters of the password you will see a series of dots or stars where the password should be.

IT Admins see that the password is masked and think the password is secure. If the IT Admin can't see the password, then an attacker won't be able to, right?

Wrong (sometimes).

Printers are not the most secure devices. Printer companies make money on the speed, quality, and reliability of the printer. They don't make money on how secure the user interface is. So you end up with features like LDAP integration that are often inadequately secured.

About half of the printers I come across mask passwords in the user interface, but reveal the password in the web source. I use a free Firefox extension called Web Developer. The Web Developer extension has a "Display Password" tool that visibly unmasks passwords. Below is a screenshot from a recent penetration test after I used Web Developer to display passwords.


I've blacked out the sensitive information, but you get the idea. Once I have a Domain Administrator's password it's pretty much game over. I have administrator access to all Windows systems on the domain.

The Fix

The remediation instructions to these organizations are pretty clear.

  • Configure non-default administrator passwords on all printers.
  • Disable LDAP authentication if not needed. If needed, configure LDAP authentication with a least privileged account (e.g. a non-privileged, dedicated Active Directory account).
  • *BONUS POINTS* There's also one more issue with the configuration in the screenshot above. Any idea what it is?

    The LDAP Server Bind Method should be changed from "Simple" to "Simple over SSL." This will encrypt the credentials when they are sent to the LDAP server over the network.

    The Takeaways

    A penetration test can help you identify your most critical, exploitable vulnerabilities. These companies are fortunate that these critical risks were found by me and not by the adversary.

    It still amazes me how small misconfigurations can lead to large consequences.

    Learn from these organizations' experiences and follow my three takeaways:

    • Ensure your penetration testing scope includes more than just your workstations and servers. The scope should include printers, VoIP phones, switches, and other embedded devices. These devices are often the biggest security offenders and can leave your organization exposed.
    • Ensure your penetration testing methodology includes testing all systems for default passwords.
    • Use a professional penetration testing company. Even if you have a highly qualified internal resource with significant experience, a second set of eyes will likely identify additional risks.

    Reach out to True to discuss your next penetration test. Our penetration tests are high quality and provide you with concise, prioritized remediation instructions. Your network will be more secure and you will sleep better at night.

True Proudly Supports TU's CTF and CCDC Teams true-proudly-supports-tus-ctf-and-ccdc-teams Fri, 13 May 16 15:14:40 +0000 CCDC3

True is honored to support the Tulsa community. Since we opened our doors in 2004, that support has taken many forms from volunteering for community outreach events and work days to donating funds to local causes. In recent years, that support has expanded to include sponsoring and mentoring the University of Tulsa (TU) security and hacking competitive teams. Currently, these include the TU Capture the Flag (CTF) Team and the TU Collegiate Cyber Defense Competition (CCDC) Team. We have been working closely with team members over the past two years, developing and building their skill sets as well as sponsoring events.

CCDC is a competition in which a blue team (representing a security team and in this case is the competing collegiate team) is given an environment or set of servers to manage. The servers represent a mock business and are already pre-configured to meet the needs of that business. The goal is to identify any gaps in the security of the servers, close any ports open unnecessarily, update any out-of-date machines or software packages, identify rogue processes and eliminate them, monitor inbound and outbound traffic, and ultimately, prevent a red team (representing malicious actors or hackers) from gaining access to their environment. All must be done while maintaining business continuity, performing business tasks (injects) and configuring new services at the demand of the CEO.

The TU CCDC Team competed in and won the CCDC 2016 Southwest Regional Competition held at Texas A&M University ? San Antonio, which was open to collegiate teams from Texas, Oklahoma, New Mexico, Louisiana and Missouri.

Although TU CCDC Teams placed 3rd in 2011 and 2nd in 2015, this marks the first year that TU has placed 1st in CCDC Southwest and earned the chance to compete in CCDC Nationals, which were also held in San Antonio. The Nationals competitors were the winners of the 2016 regional competitions.

In preparation for their trip to CCDC Nationals, the team decided they needed to work on their image. The results won the red team over. For starters, they had trading cards made that not only reflected their experience, but their interests and personalities as well.


They also decided that being election year, there were plenty of slogans and catch phrases to spoof.


The final standings of the CCDC Nationals placed the TU CCDC team in 4th place for the main competition, which was purely defensive. On the final day, the TU CCDC team took 1st place in the optional "Penopoly": an offensive, penetration testing competition.


TRUE is extremely proud of this team and expects great things from their future endeavors. We intend to continue sponsoring and mentoring the TU CCDC and CTF teams and to build up and support the Tulsa community.

Day of Caring 2015 day-of-caring-2015 Thu, 08 Oct 15 15:11:30 +0000 DSC_0481 DSC_0488 DSC_0489 DSC_0491]]> The DEFCON 2015 Experience - The Interns' Perspective the-defcon-2015-experience-the-interns-perspective Wed, 07 Oct 15 16:18:11 +0000 CSAW: Reverse Engineering for 500, Please. csaw-reverse-engineering-for-500-please Mon, 28 Sep 15 09:12:44 +0000 intriguing write up of a 2014 FlareOn challenge. Since reading that solution, I have wanted to try to solve a CTF problem by using nothing but the instruction count of an execution attempt. The thought of solving a CTF challenge purely by analyzing a program's instruction count seemed like a much easier solution than staring at assembly code until your head hurts. After the CSAW CTF ended, I decided I would try to use Intel's Pin tool to solve the 500 point reverse engineering question, wyvern. As a side note, this is not how our team managed to solve this challenge during CSAW; rather, one of our members did a lot of reversing (major kudos to Michael F. for that). After finishing my solution, this is definitely one of the first things I will try with similar problems in the future. For those who were not a part of CSAW, wyvern was a 64-bit ELF that, when ran, would ask for a secret phrase (password) and would then either tell you the input was wrong, or presumably it would present you with the flag. ryanwyvernblog I began my adventure by first downloading Intel's Pin tool. (You can find a download here.) After playing around a little bit, I got a basic idea of how to use it. Pin can perform many different types of dynamic analysis on various programs, but for my case, I was wanting to use Pin to run a program and analyze how many instructions were executed by that program. My goal was to take the number of instructions executed by wyvern and interpret that in such a way that I could correctly determine the correct length of the phrase wyvern was expecting and then begin intelligently brute-forcing the individual characters of the secret phrase. To those of you who are interested, this is called a side-channel attack. I started off by trying a single ?z' as input, and I would tack on another ?z' to the end of the input string until one of the executions produced a significant change in the total instruction count. My program claims the average number of instructions executed was 1,411,355, but an input of length 28 causes 1,424,423 instructions to be run. The fact nearly 13,000 more instructions were executed can let us safely assume this is the correct length of the secret phrase. (Because my team had already solved this challenge, I knew this was the correct length, thus solidifying my faith in Pin). At this point, without having to look at any assembly code, I could safely assume the secret phrase was 28 characters long. What I really wanted was to figure out what each character should be by using this same method. Taking the same concept described above, I began trying to solve for the first character in our secret phrase. In order to speed up my program, I ordered characters based upon the frequency they appear in English and put common leet-speak characters next to their substitutes, much like what was described in the aforementioned blog. I did make a slight change and put the ?z' at the beginning and end of my list so that it could be used as a baseline for the number of instructions executed. (I figured it would be unlikely that a ?z' would occur, and even if it did, the average would have leveled out, and the ?z' at the end of the list should differ enough from the average to be caught by my program.) My algorithm roughly went as follows. I took my answer string and appended the next character in my frequency list to it. I then filled the rest of the string with a's until I had a string of length 28. I then ran this through Pin and saw if the number of instructions executed was significantly higher than my baseline. If it was, I assumed that was the correct character and began looking for the next character. If the instruction count was not larger than then baseline, I calculated the average number of instructions executed and used that in my following tests. When I finished scripting this in Python, I was left with a program I feel can be easily modified to solve similar challenges in the future. During CSAW, several hours were spent analyzing and solving the program wyvern, but this relatively simple script will determine the correct argument length and find the correct key in approximately 16-20 minutes. I thought this was a really intriguing example of how someone could determine so much about a program by only looking at the number of instructions executed. I'm also not complaining about staring at less assembly!]]> CSAW 2015 Crypto 500 - Bricks of Gold Writeup csaw-2015-crypto-500-bricks-of-gold-writeup Tue, 22 Sep 15 10:16:53 +0000

Crypto 500 - Bricks of Gold We've captured this encrypted file being smuggled into the country. All we know is that they rolled their own custom CBC mode algorithm - it's probably terrible.

The challenge consisted of a single encrypted file and the challenge description above. We are given the clue that CBC mode is used; however, we don't know the actual encryption algorithm. Given that this is a challenge designed for undergraduate students, I surmised that we are probably dealing with XOR. Examining the file, a few items stand out. Firstly, the end of the file contains the text: THE_SECRET_IV=CASH. Not only does this give us the IV for CBC mode, but we can also assume the block size is 4, further confirmed by the fact that the file size is now an even multiple of 4 (when the IV message is removed). Secondly, near the end of the file we see multiple repeating patterns of encrypted bytes with very low entropy, giving more weight that a simple XOR operation is being used for encryption. Reviewing CBC mode, it's apparent that since XOR is a reflexive operation, we can easily remove the chaining by simply XOR'ing each 4 byte ciphertext block with the previous block, leaving us with a standard 4 byte repeating XOR key cipher. Depending on the plaintext filetype, we can apply several methods toward breaking the cipher, including English frequency analysis or identifying the most frequently used bytes. However, in my case, when I was reviewing the first few bytes of the encrypted file, the pattern looked very familiar
0000000: 2458 4d54 4b20 393d 034c a782 b3e0 167f $XMTK 9=.L......
The first few bytes appeared very similar to the PDF file header of "%PDF-1.3%" and indeed XOR'ing this against the ciphertext and IV gives us the encryption key of "BIZZ", which can then be used to decrypt the rest of the PDF. The quick Ruby script below gave us the full PDF.
block_size = 4
iv = "CASH".bytes
key = "BIZZ".bytes
data = iv + IO.binread(ARGV[0]).bytes

decoded = []
block_size.upto(data.length - 1) do |i|
    decoded << (data[i] ^ data[i - block_size] ^ key[i % block_size])

print decoded.pack('c*')
The decrypted PDF Crypto500]]>
Mitigating Spear Phishing through Increased Awareness mitigating-spear-phishing-through-increased-awareness Fri, 05 Jun 15 09:59:24 +0000 Armed with this information, an attacker can target a specific employee or group of employees based on their position(s) within the organization and their perceived level of access to systems or information, and make contact via email or phone, pretending to be a legitimate contact within or outside of the organization. With email spear phishing, an attacker creates a "spoofed" (or imitation) email that is sent to targets. To help make the email appear legitimate, the attacker may register a domain name that is nearly identical to that of the target organization in order to instill a false sense of security at first glance. The content of phishing emails differs from attack to attack. Some include links to malicious websites (that look real) in order to infect the target's computer or steal login credentials. Others articulate fake scenarios that sound plausible in an attempt to get the target to transfer funds to a "client," divulge confidential information, or assist the attacker with gathering other useful information for use in further attacks. Attackers also use the phone systems, taking advantage of caller ID spoofing technology, which allows the attacker to call from anywhere but change the caller ID number to a number they choose, such as a number internal to the organization. Attackers can pretend to be anyone in the organization and use name dropping (acquired from their web research) in an attempt to fool targets. They may set the stage by telling you they are a representative from your IT department and had issues updating your computer, or a special update is required that needs to be performed by you. They may spell out a link for you over the phone or email it to you on the spot. If you visit the link, a malware-loaded package automatically downloads, and a backdoor gets installed on your computer. Other infections could take place at the same time such as http redirects, key loggers, etc. Whichever method, once the malware has been downloaded the attacker has gained access to your machine. Spear phishing attacks are one of the most successful types of attack and can also represent the highest risk because the attacker chooses the target specifically, approaches the attack with a strategy in mind, and has definite goals. They often believe the person they are targeting has the access they want. Furthermore, no amount of security software can completely mitigate this threat. The only way to reduce the level of risk is to regularly reinforce Information Security Training & Awareness for your organization and to develop (and practice) Incident Response procedures. The spear phisher's entire attack hinges on the "sense of security" and users' lack of attention to every detail. In order to mitigate the risk of falling vulnerable to this type of attack, the following steps are recommended:
  • - Limit the number of corporate documents that are available on the Internet that could aid an attacker's strategy.
  • - Avoid providing employee names or email addresses on the corporate website unless absolutely necessary.
  • - Increase phishing awareness by ensuring employees understand the risks spear phishing poses to the organization and are regularly receiving the latest information about spear phishing and how to mitigate it by teaching them to:
  • o Pay close attention to any email that "needs" something from you whether it be information or to perform a task, the sending email address, and overall legitimacy.
  • o Contact the supposed sender of the email if there are inconsistencies or if you question whether the email is legitimate. Do not respond directly to the email or call a phone number contained in the email, but rather find this information from a legitimate source before attempting contact.
  • o Ensure that any links in the email are not misspelled.
  • o Ensure that once at a link that requires logging in, https:// precedes the website and not just http://.
  • o Ensure that if a link uses https://, there is a small lock to the left or right of the link in the address bar (to the left in Chrome and Firefox, and to the right in Internet Explorer).
  • o Instruct employees to never provide login credentials over the phone or in email, no matter how convincing the request.
  • - Perform Email and Phone Phishing Social Engineering Assessments to test employee knowledge about phishing and the internal processes in place to respond to these attacks, and use the actual testing and results to educate users on the techniques malicious actors use to attempt to gain access to the network.
  • - From a technology perspective, at a minimum, using a customizable, server-side spam filter is recommended.
Please feel free to share this article with your organization to assist with your Security Awareness Training efforts. ]]>
Can You Capture the Flag? can-you-capture-the-flag Thu, 04 Jun 15 14:29:55 +0000 CTFs typically occur in two distinct variants: attack and defend or jeopardy style. The attack and defend style is mainly used at competitions where the participants are physically present. The name aptly describes how the competition style works, competitors are given computers that are running intentionally vulnerable services and must defend their own computers while attacking their competitors' computers. Jeopardy style CTFs are easier to host on the Internet and make remotely available. In this variant, there are a compilation of tasks in areas such as exploitation, reverse engineering, algorithms, cryptography and web with new questions being unlocked in a rolling fashion. Of these CTFs, the most highly regarded tend to be the ones hosted by DefCon each year. Throughout the year, there are several CTFs that act as a qualifier for the attack and defend CTF hosted each year at the DefCon security conference. This year, DefCon's own qualifier was hosted May 15th through May 17th. During the 48 hour competition, questions were unlocked by whichever team solved the most recently unlocked challenge. In this international competition, over 1,000 teams registered, and, of those, only approximately 300 teams ended up solving a challenge. When the dust settled, True came in 112th place overall and managed to solve four challenges. True's write-ups for these challenges can be found under the "Completed Write-ups" section of the GitHub page linked here. (mathwiz and babycmd are the current write ups contributed by True.)]]> POODLE Attack on SSL 3.0 poodle-attack-on-ssl-3-0 Thu, 28 May 15 09:32:50 +0000 The Negotiation Phase During the negotiation phase of protocol selection, the client sends a "ClientHello" to the server along with a requested protocol version number. The server then responds with a "ServerHello" and the version number of the protocol it is capable of using. If the client's requested version number matches what the server can use, communication begins. If it does not, and the server's protocol is lower than the client's request, the client decides whether or not it is willing to downgrade to the server's version. If it is not, the communication ends with a security validation error. If it is willing, communication begins with the decided upon version. During the negotiation phase, POODLE requests SSL 3.0 rather than TLS 1.0/1.1/1.2. If the other end approves the connection, then the attacker is able to use this interoperability feature to eventually decrypt the website authentication cookie. The attacker only needs to make on average 256 SSL 3.0 requests per byte of data. Approximately once every 256 requests, one request will get approved by the server, revealing one byte of the cookie. The attacker then shifts that cookie's data and repeats the attack until every byte of the cookie has been discovered. This is possible due to the way blocks of data are encrypted within SSL 3.0. The most common implementation of this attack is performed as a man-in-the-middle attack. Threat Likelihood The likelihood that this specific vulnerability presents a threat to you is low because although this vulnerability has existed for a long time, there are no recorded incidents of its exploitation; it takes man-in-the-middle access, a lot of time, and ultimately a lot of effort. Unless you are a high-profile entity, you will probably never see it in use. The moral of the story, however, is still quite important: keep a close eye on the encryption algorithms you are using. It is easy to assume you are protected because you are using encryption, but if you are using an encryption algorithm with known weaknesses you could be introducing an undetermined level of risk to your environment. Mitigation Techniques Here are some steps you can take to mitigate risk associated with POODLE:
  • ? NOTE: There is currently no "fix" for this vulnerability in that the feature being taken advantage of serves a necessary purpose: the interoperability of legacy software.
  • ? If possible, disable SSL 3.0 on devices to prevent protocol downgrade. (This action may cause compatibility issues with other systems/software.)
  • ? On the server side OpenSSL should be upgraded to the latest versions.
Logjam Vulnerability logjam-vulnerability Thu, 21 May 15 13:19:44 +0000 RSA-EXPORT History RSA-EXPORT was purposefully included in SSL and TLS to introduce a cryptographic weakness into the protocols. It was included in an effort to comply with U.S. cryptography export regulations from the 1990s. These regulations required developers who wanted their software to be used abroad to limit the cryptographic strength of "secure" communications so the FBI, NSA and other U.S. agencies could more easily break foreign entities' encryptions. At the time, only organizations with a lot of computing power could hope to crack even 512-bit encryption, but by the early 2010s cloud-based solutions could more than handle it. RSA-EXPORT was originally intended to only exist in software that was being exported, but software companies grew tired of designing two copies of the same applications. Instead, they started making only the one copy that included RSA-EXPORT, but had it disabled by default and enabled it if exported. The FREAK attack vulnerability was announced in March 2015, and was quickly patched by all the popular web browsers. These patches were not made to remove the RSA-EXPORT functionality, however, but merely to prevent the FREAK attack from gaining access to it. How is Logjam different? Logjam differs from FREAK in that it doesn't use the same straight-on approach. Instead, it attempts to force RSA-EXPORT by targeting the Diffie-Hellman key exchange or "handshake." The "handshake" is the initial communication between client and server where protocol negotiations are performed. In other words, Logjam attacks before the client and server have even agreed on which protocol to use. Again, Diffie-Hellman is not inherently weak but was weakened by the use of RSA-EXPORT. Once the encryption has been downgraded to 512-bit encryption, the attacker needs only to use the number field sieve algorithm to crack the key. At this point, the attacker can use the cracked key to monitor traffic in real-time using a Man-in-the-Middle attack. What can be done? The threat level for this attack is high in that if successfully implemented, an attacker can gain access to any transmitted data. For most entities, however, the actual level of risk is low for the following reasons:
  • ? Man-in-the-Middle (MITM) attacks are still difficult.
  • ? The value of the data would need to exceed the cost, time, effort, and risk involved.
  • ? Both the server and client would have to support RSA-EXPORT.
Ultimately, as is the case for most encryption vulnerabilities or threats, a high level of risk only exists for high-profile targets such as government agencies, educational institutions, and large corporations. In order to limit the likelihood of a successful attack, the following mitigations should be implemented:
  • ? Ensure all software that implements SSL/TLS is updated regularly.
  • ? If you are a server administrator, ensure DHE_EXPORT ciphersuites support is disabled.
  • ? Further instruction for securely deploying Diffie-Hellman in TLS is available here.
SSL/TLS Protocol Version Negotiation ssltls-protocol-version-negotiation Thu, 21 May 15 11:26:15 +0000
  • First, it assumes that the certificates being used are legitimate. In other words, that the certificate in use has been signed by a legitimate, secure Certificate Authority (CA).
  • Second, it assumes that the server or client has not been infected, thus compromising one or more of the endpoints.
  • Lastly, it assumes that the protocol being used is a secure one, which is the focus of this post.
Using an SSL or TLS protocol is substantially more secure than not using one, but not all cryptographic protocols are created equal. For example, TLS is the new and improved version of SSL. It would have been unnecessary to produce a new protocol if SSL was sufficient. The following is a list of the different cryptographic protocols in use historically:
  • SSL 1.0 - Developed in 1993; only lasted one year; had inherent flaws: did not provide data integrity protection; if used with the RC4 cipher, was vulnerable to guided-guessing plain-text attacks; and was vulnerable to replay attacks.
  • SSL 2.0 - Developed in 1994; was vulnerable to guided-guessing plain-text attacks; did not have protocol negotiation protection, allowing for man-in-the-middle protocol downgrade attacks; and was vulnerable to truncation attacks.
  • SSL 3.0 - Developed in 1996; vulnerable to guided-guessing plain-text attacks; vulnerable to replay attacks on anonymous key exchange; and allows weak cipher suite options from SSL 2.0 as well as introducing strong options such as Diffie-Hellman.
  • TLS 1.0 - Developed in 1999 and referred to as SSL 3.1; fixed cipher suite requirement issues from SSL 3.0 (forced Diffie-Hellman and Triple-DES); and shares some vulnerabilities with SSL 3.0 (replay attack and plaintext attack vulnerabilities).
  • TLS 1.1 - Developed in 2006 with protection against cipher block chaining attacks implemented.
  • TLS 1.2 - Current standard developed in 2008 with hash function MD5-SHA-1 combination replaced throughout the protocol with cipher-suite specified hash algorithms.
As observed in the above outline, each successive protocol was an improvement on the last. The reason TLS did not eliminate the use of SSL completely is the need for backwards compatibility. SSL 3.0 was in use by servers all over the Internet. Although it is far less prevalent, SSL 3.0 can still be found in use today. Due to the use of SSL 3.0 by older applications, servers that need to communicate with those applications maintain it as well. Due to the servers that maintain the use of SSL 3.0, browsers such as Internet Explorer still allow SSL 3.0 communication by default. NEGOTIATION In order to decide what protocol to use, when the client side requests a secure connection it sends a "ClientHello" with the version number of the desired protocol (0x0300 for SSL 3.0, 0x0301 for TLS 1.0, etc). The server then responds with a "ServerHello" and the version number it is capable of using. For example, if the client requests 0x0302 for TLS 1.1 but the server is only capable of protocols up to TLS 1.0, it will respond with 0x0301. That leaves the connection decision up to the client. If the client's minimum protocol requirement is TLS 1.1, it will drop the connection as being insecure. Otherwise, it will downgrade to TLS 1.0 and establish the connection. Although this allows for backward compatibility and prevents a lot of communication errors, it does present security risks. For instance, if a client's browser supports automatic protocol downgrades to SSL 3.0, it is possible for a man-in-the-middle attack to occur that forces the downgrade and allows for seemingly secure communication to be intercepted.]]>
Merchant Readiness for the October 2015 Liability Shift merchant-readiness-for-the-october-2015-liability-shift Wed, 13 May 15 15:26:11 +0000 For example, if a merchant has EMV-compliant POS terminals and the customer's bank does not issue EMV cards, then the customer's bank would be liable for the fraud. Conversely, if the merchant does not have EMV-compliant POS terminals, then the merchant and/or the acquirer would be liable for fraudulent transactions if the customer has a chip card. The biggest PCI implication of moving to EMV-compatible technology is audit and breach penalty relief from the card brands. If more than 75% of a merchant's transactions originate from EMV-compliant POS terminals that support both contact and contactless transactions, most card brands will offer relief from PCI audit requirements (you still have to be PCI compliant) and decrease the financial penalties associated with a credit card breach. This audit and breach penalty relief clause is already in effect. Here's what I recommend merchants do in regard to dealing with the October 2015 deadline: 1. Talk with your acquiring bank to see what their plans are to rotate out POS terminals to meet the EMV October 2015 mandate. Card brands have been offering incentives to acquiring banks to speed this along. 2. Read the contract that you have with your acquiring bank to see if it addresses this liability shift. You will want to know if after October 1, 2015 will you bear the full liability, will the acquiring bank, or will it be shared? ]]> Michael Oglesby Takes Second in 2015 Verizon DBIR Cover Challenge michael-oglesby-takes-second-in-2015-verizon-dbir-cover-challenge Wed, 13 May 15 10:26:53 +0000 Michael, an avid puzzle solver, - You should see his collection of Rubik's Cubes - has placed third or higher four times in the past six years, going to back to when he was a champion of the contest in 2010. Jeff Harris, President & CFO of True, said of Michael, "He [Michael] is one of the brightest people you will ever have the pleasure of meeting. He is unbelievably gifted and talented in the security space, and we are very blessed to have him as a key part of our management and leadership team here at True." To learn more about this year's Cover Challenge and the steps involved in creating and solving the complex puzzle, read the DARKReading article, Verizon 2015 Data Breach Cover Puzzler Solved: Defending Champs Win. ]]> Martin McCurdy Named All Oklahoma/All USA Academic Team martin-mccurdy-named-all-oklahomaall-usa-academic-team Mon, 11 May 15 11:19:23 +0000 "The awards ceremony was empowering. This was my first time in the Capitol building and being surrounded by all the marble and artwork exceeded my expectations," said McCurdy, who was also presented with a Citation of Recognition by State Sen. Roger Thompson. "It was inspiring to engage with other All Oklahoma/All USA Academic Team members and sharing our experiences in receiving this award." According to the article, McCurdy was selected because of his grade point average of at least 3.5 and provided examples on how he demonstrated his leadership skills in the classroom, on campus and in the community. "This is a great honor bestowed on one of our newest employees, and we are very proud of his effort in striving for excellence in all that he does. Martin is a very bright young man," said Jerald Dawkins, CEO of True Digital Security. Click here to access the full article from OSU Institute of Technology. ]]> True Employees Support Tulsa Area United Way true-employees-support-tulsa-area-united-way Mon, 24 Nov 14 14:24:19 +0000 Living True's core values of Stewardship and Teamwork, True employees have actively contributed to the Tulsa Area United Way this year by participating in Day of Caring as well as completing our annual fundraising campaign.

This year's Day of Caring Project benefited the Girl Scouts of Eastern Oklahoma. Following blueprints, True's team of volunteers cut lumber to size and skillfully constructed four extremely sturdy picnic tables for the Girls Scouts' Camp Tallchief at Zink Ranch.

We enjoyed the outdoors during this team building activity and were even treated with our favorite Girl Scout cookies for dessert!

True was recognized by the Tulsa Area United Way for raising over 10% more than our previous year's campaign. All employee donations raised this year are being matched by True to benefit the St. Pius X Catholic School Capital Campaign for students Mackenzie, Connor and Cooper Kelley.

jerry-jeff group-cookies tables blog-group]]>
Innotech Prize Drawing Winner innotech-prize-drawing-winner Mon, 27 Oct 14 11:58:22 +0000 Innotech-booth The official winner of True's iPad Air random drawing is Jenny Grimm of Edmond Public Schools. Congratulations, Jenny! ]]> True Interns Shine at OCAST 2014 Oklahoma Technology Showcase true-interns-shine-at-ocast-2014-oklahoma-technology-showcase Wed, 03 Sep 14 16:55:29 +0000 Last month the Oklahoma Center for the Advancement of Science and Technology (OCAST) held their Third Annual Oklahoma Technology Showcase at the University of Central Oklahoma. The showcase featured nine Oklahoma businesses that have received OCAST support demonstrating their innovation, along with three OCAST-supported undergraduate interns presenting their Intern Partnership Program projects. Two of those three distinguished interns were True's very own Ryan McCarthy and Martin McCurdy!

To qualify for this distinction and compete for scholarship funding, Ryan and Martin, along with other active OCAST intern participants across the state, each submitted an essay that described their OCAST-funded internship project, its goals, their role, results of the project, and benefits, in hopes to be selected as one of the three scholarship finalists to present at the showcase.

Following their presentations, Ryan McCarthy was awarded first place and a $2,500 dollar scholarship for his contributions and research on an exploitation application in development for True, while Martin McCurdy was awarded second place and a $2,000 scholarship for his contributions and research on PCI-DSS compliance and point-of-sale malware.

True is extremely proud of our interns and has enjoyed mentoring, developing, and challenging these bright young men as they prepare for their future as information security professionals.