Tuesday, April 28, 2020

How do you verify authenticity and integrity for open source software downloads?



Note from Tom: If you’re only looking for today’s pandemic post, go to my new blog (and if you’re not subscribing to that blog, sign up for it. This blog will increasingly be devoted to cybersecurity/NERC CIP discussions, although I’ll continue to post the pandemic posts here as well – but they won’t get picked up by the email feed on days when I post on both topics). If you’re looking for my cyber/NERC CIP posts, you’re come to the right place.

As you probably know, CIP-013-1 R1.2.5 requires “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System.” And CIP-010-3 R1.6 requires NERC entities with High and Medium impact BES Cyber Systems, “when the method to do so is available to the Responsible Entity from the software source”, to:

1.6.1. Verify the identity of the software source; and
1.6.2. Verify the integrity of the software obtained from the software source.

Of course, all three of these requirement parts focus on the “vendor”. In the case of open source software, there is no vendor. A vendor is (or at least should be) ultimately responsible for making sure you have a way to verify that you downloaded the software from their site wasn’t tampered with on its way to you. But there’s nobody who is directly responsible for performing this function for open source software; whether you will get a digital signature and/or a hash value to verify authenticity and integrity is never certain. Does this mean you don’t need to worry about open source software when you verify software integrity and authenticity?

The recent NERC Supply Chain FAQ includes a question “Is open source software in scope for CIP-013-1 and CIP-010-3?” The answer is “The Supply Chain Standards are silent on terms and conditions for procured products or services that registered entities may install. A registered entity should implement its risk identification and assessment methodology for all procurements and installations of open-source software on applicable BES Cyber Systems.”

Further down in the FAQ, the question is asked “How do you perform authenticity checks for open source software?” The answer is “The ERO Enterprise also recognizes not all software sources have secure methods for verifying the integrity of the software, so it recommends the registered entity document these exceptions in the supply chain cyber security risk management plan. If there is an instance where a method is not available to verify the integrity and authenticity of software, the ERO Enterprise recommends the registered entity to document the exception and any mitigating measures afforded internally to reduce the supply chain risk of introduction of malware or counterfeit software. Some examples include, but are not limited to, thoroughly research where the software is being downloaded, ensure the name of the file downloaded from the source matches what is being installed, and verify the checksum values and signature files if available. Pursuant to CIP-013-1, Requirement R1, Part 1.2.5, the registered entity should document its verification process of the authenticity of the open source software. In instances where authenticity checks are unavailable, the registered entity should consider documentation outlining the risk factors identified and security controls used to prevent impact to reliability and security. Some example evidence may include change tickets, checklists, results of the evaluation, etc.”

I think these two answers are good. They’re essentially just variations of the basic answer I give whenever someone asks whether something should be “in scope” for their CIP-013 supply chain cyber security risk management plan. I always answer “Could this pose any risk to the BES, if you procure (although “obtain” might be a better word when it comes to open source software) and install the product?” If so this should be in your plan. If not, it shouldn’t.

As an aside, sometimes someone will acknowledge that the item in question (in this case, the integrity and authenticity of open source software) definitely poses a risk to the BES, but they’ll say the risk “doesn’t apply to us” for one reason or another (e.g. “We never do X”, or “We never allow Y”). My response to that is always “All legitimate BES supply chain cyber risks – that could apply to any North American electric power organization – apply to you. However, in many cases (perhaps most), you will have mitigated the risk already, or perhaps your environment has done it for you.”

To use the current example, you might say “Well, we don’t allow open source software to be installed on BCS in the first place, so this risk doesn’t apply to us.” I always respond “This risk applies to you, but you’re saying that you have already mitigated it – in this case, by not allowing open source software to be installed in the first place. Rather than simply remove this risk from your list and not mention it at all in your CIP-013 program, I have a better idea: List this as a risk, and then show that you’ve mitigated it with your policy to forbid open source software. That way, you’ll get brownie points for mitigating another supply chain cyber risk to the BES, even though you didn’t have to do anything more than you were already doing!”

There are probably at least as many risks that apply to open source software as apply to commercial software. The risk of downloading a patch that is unauthentic or compromised in transit is certainly one you need to consider (in fact, since it’s required by the two requirement parts mentioned above, you don’t have the option not to consider it). If you think the risk is already mitigated in your environment – for example, if you don’t allow open source software to be installed on BCS in the first place - document that!

But let’s say this risk isn’t already mitigated in your environment; what options do you have to verify integrity and authenticity of open source software? I used to think they were really limited, unless you were an enormous software geek. However, in November I met Dick Brooks, who spent a long career with ISO New England, when we both spoke at the IEEE Smart Grid Security conference in Atlanta (do you remember face-to-face meetings? It sometimes seems like they were a great thing we used to do in the last century, but nowadays we wouldn’t think of doing them anymore. I seriously wonder if we’ll have face-to-face meetings again, at least for a long time).

Dick is a software engineer with a very impressive resume, who worked for ISO New England from 2004 until he retired last year (I believe) and formed his own company, Reliable Energy Analytics. Dick has been after me to look at his SAG-PM product for verifying software authenticity and integrity. I frankly resisted him at first, since I thought most NERC entities would be content with the digital signatures and hash values provided by many (most?) commercial software vendors. However, two things led me to pay much more attention to his product:

  1. A number of people brought up the question of verifying authenticity and integrity of open source software, including in the Supply Chain Working Group’s webinar yesterday on guidelines for Procurement Language (which ended up being a more general – but good – discussion of risk management, since the guidelines themselves are still being drafted).
  2. I had assumed this would be a fairly pricey service, since it will allow you to verify authenticity and integrity for all software, not just open source. However, when I asked Dick what it cost yesterday, his answer blew me away (I won’t say what he said, since he’s still working out the details of his offering. You can reach him at dick@reliableenergyanalytics.com). You might not be able to put together the annual cost by rummaging in your couch for spare quarters, but it’s not too far from that.

Dick provided me with a good demonstration of what SAG-PM can do, shown below. While this is a long printout, he summarized what makes it a very interesting demonstration of what SAG-PM can do: “Notice the Suricata example I sent to you contains a good digital signature, but there is a malware warning, from Virus Total. This is why you can’t trust digitally signed software and the key to a trustworthy outcome is based on corroborating evidence, which is a key philosophy built into the SAGScore algorithm.”



Here is one example of SAG-PM output of the open source Suricata IDS software, downloaded from (Source Location): https://www.openinfosecfoundation.org/downloads/windows/Suricata-4.1.4-1-64bit.msi

SAG Point Man performs a risk analysis on 7 control functions that results in a SAGScore (trustworthiness score):
  1. Perform introspection of software object looking for risk
  2. Verify Download Server Source Location/Certificate
  3. Perform Virus Scan using online Service
  4. Verify Digital Signature of software object
  5. Perform Vulnerability (CVE) Search
  6. Perform Vendor Verification using Questionnaire data
  7. Perform Man in the Middle Check
  8. Generate SAGScore™ (Trustworthiness Score)
  9. Generate CIP-010-3 R1, Part 1.6 Proof of Verification/Evidence record, SAGPOV™
  10. Save all findings and results in F850CR evidence file

Here are the SAG-PM results from the Suricata software object that was downloaded:

C:\Users\Dick>sag comprehensive \Users\Dick\Downloads\Suricata-4.1.4-1-64bit.msi ReliableEnergyAnalytics\SAG_Output
Starting SAG-PM(TM) at: 2020-04-27 18:59:34.815452 using Version: BETA_20200501_3

Please provide the URL of the Server that provided this software object: https://www.openinfosecfoundation.org/downloads/windows
Performing program introspection for risks...
*************** PROPERTIES *******************
----> Manufacturer Open Information Security Foundation
----> ProductCode {42AB4288-8940-4B7D-97E2-75901A1D188F}
----> ProductName Suricata IDS/IPS 4.1.4-1-64bit
----> ProductVersion 4.1.4
*************** FILES AND COMPONENTS *******************
----> Executable; FileName:  suricata.exe  in module:  MainExecutable
----> Executable; FileName:  -heb0dku.dll|liblzma-5.dll  in module:  MINGW64_liblzma_5.dll
----> Executable; FileName:  msvcrt.dll  in module:  MINGW64_msvcrt.dll
----> Executable; FileName:  l9yzergb.dll|libpcre-1.dll  in module:  MINGW64_libpcre_1.dll
----> Executable; FileName:  zlib1.dll  in module:  MINGW64_zlib1.dll
----> Executable; FileName:  gryxskud.dll|libwinpthread-1.dll  in module:  MINGW64_libwinpthread_1.dll
----> Executable; FileName:  liblz4.dll  in module:  MINGW64_liblz4.dll
----> Executable; FileName:  pakgywbh.dll|WinDivert.dll  in module:  MINGW64_WinDivert.dll
----> Executable; FileName:  2slm-vhk.dll|libGeoIP-1.dll  in module:  MINGW64_libGeoIP_1.dll
----> Executable; FileName:  lua53.dll  in module:  MINGW64_lua53.dll
----> Executable; FileName:  libnspr4.dll  in module:  MINGW64_libnspr4.dll
----> Executable; FileName:  nss3.dll  in module:  MINGW64_nss3.dll
----> Executable; FileName:  nssutil3.dll  in module:  MINGW64_nssutil3.dll
----> Executable; FileName:  libplc4.dll  in module:  MINGW64_libplc4.dll
----> Executable; FileName:  mqsrvtkk.dll|libyaml-0-2.dll  in module:  MINGW64_libyaml_0_2.dll
----> Executable; FileName:  libplds4.dll  in module:  MINGW64_libplds4.dll
----> Executable; FileName:  qx4jerae.dll|libjansson-4.dll  in module:  MINGW64_libjansson_4.dll
----> Executable; FileName:  batch.bat  in module:  Win_suricata_batch.bat
A trust score of: 87.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Verifying Source Server ...
---->Company Name:*.openinfosecfoundation.org
---->Issuer Name: DigiCert Inc
---->WARNING: Vendor: Open Information Security Foundation Not Found in database
A trust score of: 22.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Performing Malware Scan(this takes a few moments...)
('---->Engine: ESET-NOD32', 'result:', True, 'reason:', 'a variant of Win64/WinDivert.A potentially unsafe')
---->Vulnerabilities found: 1 Total Scans performed:  62
A trust score of: 0.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Verifying Digital Signature on Software Object...
----> :Verifying: \Users\Dick\Downloads\Suricata-4.1.4-1-64bit.msi

----> :Unable to verify this file using a catalog.

----> :Signature Index: 0 (Primary Signature)

----> :Hash of file (sha1): 5D7B378B7D105AF0E1B0CEA2ABF25766BB2FD925

----> :Signing Certificate Chain:

----> :    Issued to: COMODO RSA Certification Authority

----> :    Issued by: COMODO RSA Certification Authority

----> :    Expires:   Mon Jan 18 19:59:59 2038

----> :    SHA1 hash: AFE5D244A8D1194230FF479FE2F897BBCD7A8CB4

----> :        Issued to: COMODO RSA Code Signing CA

----> :        Issued by: COMODO RSA Certification Authority

----> :        Expires:   Mon May 08 19:59:59 2028

----> :        SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47

----> :            Issued to: OPEN INFORMATION SECURITY FOUNDATION INC.

----> :            Issued by: COMODO RSA Code Signing CA

----> :            Expires:   Sat Jul 11 19:59:59 2020

----> :            SHA1 hash: BF84333A357D0136EB4E89197494BC11629620E5

----> :The signature is timestamped: Tue May 14 02:30:33 2019

----> :Timestamp Verified by:

----> :    Issued to: Thawte Timestamping CA

----> :    Issued by: Thawte Timestamping CA

----> :    Expires:   Thu Dec 31 19:59:59 2020

----> :    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

----> :        Issued to: Symantec Time Stamping Services CA - G2

----> :        Issued by: Thawte Timestamping CA

----> :        Expires:   Wed Dec 30 19:59:59 2020

----> :        SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

----> :            Issued to: Symantec Time Stamping Services Signer - G4

----> :            Issued by: Symantec Time Stamping Services CA - G2

----> :            Expires:   Tue Dec 29 19:59:59 2020

----> :            SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4

----> :Successfully verified: \Users\Dick\Downloads\Suricata-4.1.4-1-64bit.msi

----> :Number of files successfully Verified: 1

----> :Number of warnings: 0

----> :Number of errors: 0

---->WARNING: Unable to match digital signature with Vendor Database: VERY HIGH RISK
A trust score of: 67.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Performing Common Vulnerability Search (this takes a few moments ...)
----> Mitre search string:  https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Suricata IDS/IPS 4.1.4-1-64bit
CVEID_1 Suricata before 4.0.4 is prone to an HTTP detection bypass vulnerability in detect.c and stream-tcp.c. If a malicious server breaks a normal TCP flow and sends data before the 3-way handshake is complete, then the data sent by the malicious server will be accepted by web clients such as a web browser or Linux CLI utilities, but ignored by Suricata IDS signatures. This mostly affects IDS signatures for the HTTP protocol and TCP stream content; signatures for TCP packets will inspect such network traffic as usual.


CVE-2018-6794
Suricata before 4.0.4 is prone to an HTTP detection bypass vulnerability in detect.c and stream-tcp.c. If a malicious server breaks a normal TCP flow and sends data before the 3-way handshake is complete, then the data sent by the malicious server will be accepted by web clients such as a web browser or Linux CLI utilities, but ignored by Suricata IDS signatures. This mostly affects IDS signatures for the HTTP protocol and TCP stream content; signatures for TCP packets will inspect such network traffic as usual.


CVE-2015-2878
Multiple cross-site request forgery (CSRF) vulnerabilities in Hexis HawkEye G 3.0.1.4912 allow remote attackers to hijack the authentication of administrators for requests that (1) add arbitrary accounts via the name parameter to interface/rest/accounts/json; turn off the (2) Url matching, (3) DNS Inject, or (4) IP Redirect Sensor in a request to interface/rest/dpi/setEnabled/1; or (5) perform whitelisting of malware MD5 hash IDs via the id parameter to interface/rest/md5-threats/whitelist.


CVE-2014-3402
The authentication-manager process in the web framework in Cisco Intrusion Prevention System (IPS) 7.0(8)E4 and earlier in Cisco Intrusion Detection System (IDS) does not properly manage user tokens, which allows remote attackers to cause a denial of service (temporary MainApp hang) via a crafted connection request to the management interface, aka Bug ID CSCuq39550.


CVE-2014-2103
Cisco Intrusion Prevention System (IPS) Software allows remote attackers to cause a denial of service (MainApp process outage) via malformed SNMP packets, aka Bug IDs CSCum52355 and CSCul49309.


Press enter to continue...

CVE-2007-2734
The 3Com TippingPoint IPS do not properly handle certain full-width and half-width Unicode character encodings in an HTTP POST request, which might allow remote attackers to evade detection of HTTP traffic.


CVE-2007-2690
Multiple IBM ISS Proventia Series products, including the A, G, and M series, do not properly handle certain full-width and half-width Unicode character encodings, which might allow remote attackers to evade detection of HTTP traffic.


CVE-2007-2689
Check Point Web Intelligence does not properly handle certain full-width and half-width Unicode character encodings, which might allow remote attackers to evade detection of HTTP traffic.


CVE-2007-2688
The Cisco Intrusion Prevention System (IPS) and IOS with Firewall/IPS Feature Set do not properly handle certain full-width and half-width Unicode character encodings, which might allow remote attackers to evade detection of HTTP traffic.


CVE-2006-4910
The web administration interface (mainApp) to Cisco IDS before 4.1(5c), and IPS 5.0 before 5.0(6p1) and 5.1 before 5.1(2) allows remote attackers to cause a denial of service (unresponsive device) via a crafted SSLv2 Client Hello packet.


Press enter to continue...
CVE-2005-2695
Unspecified vulnerability in the SSL certificate checking functionality in Cisco CiscoWorks Management Center for IDS Sensors (IDSMC) 2.0 and 2.1, and Monitoring Center for Security (Security Monitor or Secmon) 1.1 through 2.0 and 2.1, allows remote attackers to spoof a Cisco Intrusion Detection Sensor (IDS) or Intrusion Prevention System (IPS).


----> More than 10 vulnerabilities found - stopping search
----> Total Vulnerabilities Found:  10
A trust score of: 0.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Performing Vendor Verification...
---->WARNING: Vendor Data Missing:  VERY HIGH RISK
---->WARNING: Vendor Questionnaire Data Missing:  VERY HIGH RISK
---->WARNING: Unable to verify software product information in Vendor Questionnaire: VERY HIGH RISK
A trust score of: 0.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Performing Man in the Middle Trace(this takes a few moments...): www.openinfosecfoundation.org
---> ('<DNSBLResult: 52.14.249.179  (0/52)>', 'AMAZON-02, US')
---> 192.168.1.1 is a Reserved Address
---> ('<DNSBLResult: 208.236.210.1  (0/52)>', 'WGELD-ASN, US')
---> 172.17.1.146 is a Reserved Address
---> ('<DNSBLResult: 40.131.63.252  (0/52)>', 'WINDSTREAM, US')
---> ('<DNSBLResult: 40.136.115.30  (0/52)>', 'WINDSTREAM, US')
---> ('<DNSBLResult: 40.128.249.56  (0/52)>', 'WINDSTREAM, US')
---> 99.82.180.98 is a Reserved Address
---> 52.93.4.91 is a Reserved Address
---> 52.93.4.36 is a Reserved Address
---> 150.222.243.213 is a Reserved Address
---> 54.239.45.238 is a Reserved Address
---> ('<DNSBLResult: 52.95.1.122  (0/52)>', 'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.133  (0/52)>', 'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.216  (0/52)>', 'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.195  (0/52)>', 'AMAZON-02, US')
---> ('<DNSBLResult: 52.95.1.4  (0/52)>', 'AMAZON-02, US')
Man in the Middle Trace Process Failed
A trust score of: 0.0 has been calculated for this step. Do you wish to assign a passing grade (Y)/N?

Final SAGScore: 14.35 Please assign a final grade for this verification (PASS)/FAIL:

You MUST provide a reason for assigning this grade, enter your reason here: Very poor results due to missing vendor data and poor SNR on CVE search

Cut and paste the following Proof of Verification into your Change Management System, then press Enter to continue
------------------------------------------------
{'TransactionID': '2020-04-27_22_59_35_477048_ONLINE_08753f13-3b25-4959-ab5e-2cdfa31f36ee', 'SAGScore': 14.35, 'FINAL GRADE': 'PASS', 'FinalGradeReason': 'Very poor results due to missing vendor data and poor SNR on CVE search', 'Product': 'Suricata IDS/IPS 4.1.4-1-64bit', 'Version': '4.1.4', 'Filename': '\\Users\\Dick\\Downloads\\Suricata-4.1.4-1-64bit.msi', 'Licensor': 'Open Information Security Foundation', 'SAGPOVID': 'fae6b436-7c6c-4af0-9be7-1f54bd95200b'}
------------------------------------------------
Press Enter to continue, AFTER copying SAGPOV to CM System...

Saving F850CR Evidence File...
F850CR Contents have been saved to file:  ReliableEnergyAnalytics\SAG_Output//2020-04-27_22_59_35_477048_ONLINE_08753f13-3b25-4959-ab5e-2cdfa31f36ee.txt

  
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!

No comments:

Post a Comment