Understanding Scope in Go

As per my New Year's resolution, I've been learning to program in Go and reading The Go Programming Language.   On page 141 of the book, there are a couple of code examples to explain scoping rules and how variables are bound to anonymous functions.  This short post is just me making sure I grok what's in the book and sharing in case its helpful to anyone else.

MD5 should not be used in forensics (or anywhere else)

A few days ago, I drafted (but had not yet published) a post about using MD5 for validating or authenticating evidence in digital forensics.  MD5 has had security problems for twenty years, but it's still been used in forensics, although the trend has been toward SHA-1 (which has some problems of its own) and SHA-2.

After drafting the post, I discovered that the Scientific Working Group on Digital Evidence has released a draft endorsing the use of MD5 and SHA-1.  I wrote in to share my concerns, but I also reached out to some cryptographers via Twitter.  Dr. Marc Stevens, a cryptographer known for his expertise in attacking MD5 and other hash functions, released a series of tweets that was even more critical of MD5 than I anticipated and that was incredibly damning for any forensic expert who continues to rely on MD5.

Analyzing infected documents

Occasionally, users ask me to take a look at a document (usually .docx or .pdf) that they are unsure of.  It might be that the sender is someone known to them but they weren't expecting a report or an invoice, or perhaps they don't know the sender but the message seems legitimate.  As a part of our security awareness campaigns, I have repeatedly encouraged them to ask.  I'm glad they do.

Other times, it comes to my attention that a user has, or might have, opened a malicious attachment.  In these cases also I need to find out what I'm dealing with.  Is the document malicious?  What does it do if you open it (and Enable Content)?  Does it actually execute code or just link to a phishing site?

My favorite tool for analyzing these documents is https://www.hybrid-analysis.com.  This site makes it very easy to figure out if a document is malicious, analyze its behavior, and identify potential indicators of compromise.  The following is a quick walk-though the highlights some of the information that is provided when you analyze a document on the site.

What is a server?

I have a new post up on my company webpage.  I've been meaning to post this for a while.  After the DNC was hacked in 2016, there were questions (mostly by people chasing one conspiracy theory or another) that the FBI made a mistake by not taking the DNC's server.  Not only is taking the server not a typical practice (especially where the owner is a victim and not a perpetrator), it would be extraordinarily difficult.  This post breaks down what a server actually is.  For readers who are working in IT, there's probably nothing new to see here.  For readers coming from a non-technical background, I hope this will prove interesting and informative.

The gist of my post is that, at one time, many servers were basically souped-up desktop computers.  This is generally not the case anymore.  The resources that ultimately make up a server may span several physical devices and each of those devices may support dozens of servers.  It's a many-to-many relationship.  Check out the post:

What is a server?

If you need a computer or mobile forensics consultant, I'm available: Trace Digital Forensics, LLC.

Consulting: Trace Digital Forensics, LLC

I haven't blogged here much recently.  A couple of years back I started a digital forensics consulting firm, Trace Digital Forensics, and have been doing most of my blogging over there.  I'm going to try to get back to posting some security, crypto and IT related content here and will cross-post some of the forensics content.

If you need a digital forensics consultant, email me.  I can handle most cases involving Windows, Mac, Android and iOS. I'm also working on an arrangement to subcontract for audio and video specialty work. I am open to working either side of a case and am happy to evaluate reports from opposing experts and/or recommend lines of questioning. 

Safari Plugin Forensics - com.apple.Safari.plist

I'm posting this later than promised but this is a slightly revised version of what I submitted for Guidance Software's forensic bug bounty on BugCrowd.

In OS X 10.9, Apple started tracking which sites were configured to play Flash video in the file /Users/[user]/Libary/Safari/PlugInOrigins.plist. I originally discovered this while working on a case where a user had been browsing adult websites at work. The user's browser history (if I'm remembering this correctly) did not have any entries showing his visits to these sites but there was an entry in PlugInOrigins.plist showing that he had enabled Flash for one of them.  I eventually found a lot of other material to support the accusation and the user admitted what he had been up to.

As of OS X 10.10, the PluginOrigins.plist file is no longer used. The setting is now saved in /Users/[user]/Library/Preferences/com.apple.Safari.plist. 

The file is stored in binary xml format and can be converted with the cmd "plutil -convert xml1 com.apple.Safari.plist". A sample portion of this file is below. There is an entry for each configured site showing whether Flash should play, not play, or ask the user. It also tracks the last visited date and time. This artifact can be used to show whether a computer/account was used to visit a particular site. For example, the artifact in the file below would demonstrate that the computer was used to visit the HBO Now service on August 1st at 5:57 AM GMT.

 <key>com.macromedia.Flash Player.plugin</key>
    <dict>
        <key>PlugInDisallowPromptBeforeUseDialog</key>
        <true/>
        <key>PlugInFirstVisitPolicy</key>
        <string>PlugInPolicyBlock</string>
        <key>PlugInHostnamePolicies</key>
        <array>
            <dict>
                <key>PlugInHostname</key>
                <string>play.hbonow.com</string>
                <key>PlugInLastVisitedDate</key>
                <date>2017-08-01T05:57:45Z</date>
                <key>PlugInPageURL</key>
                <string>https://play.hbonow.com/</string>
                <key>PlugInPolicy</key>
                <string>PlugInPolicyAllowWithSecurityRestrictions</string>
                <key>PlugInRunUnsandboxed</key>
                <false/>
            </dict>

This file also contains artifacts for other plugins such as SilverLight, e.g.:

<key>com.microsoft.SilverlightPlugin</key>
   <dict>
        <key>PlugInDisallowPromptBeforeUseDialog</key>
        <true/>
        <key>PlugInFirstVisitPolicy</key>
        <string>PlugInPolicyBlock</string>
        <key>PlugInHostnamePolicies</key>
        <array>
            <dict>
                <key>PlugInHostname</key>
                <string>amazon.com</string>
                <key>PlugInLastVisitedDate</key>
                <date>2017-07-17T03:20:55Z</date>
                <key>PlugInPageURL</key>
                <string>https://www.amazon.com/Dawn-Planet-Apes-Andy-Serkis/</string>
                <key>PlugInPolicy</key>
                <string>PlugInPolicyAllowWithSecurityRestrictions</string>
                <key>PlugInRunUnsandboxed</key>
                <false/>
            </dict>
        </array>

Notice in this example that it shows the specific URL that was visited.

Exporting text messages from an iPhone

Last week, I was asked to acquire the text messages from an iPhone and to pull out only the messages that were to/from a particular party in a particular date range.  This took a little research to pull off so I'm posting this to share the steps we took.  I hope that this will be useful to others doing forensic investigations or e-discovery.

The first phone we needed to pull messages from was an iPhone.  To start with, we backed up the phone to the user's computer via iTunes.  On Mac OS X, the backups are stored in ~/Library/Application Suppport/MobileSync/Backup/{UDID}.  The individual backup files have no extension and the names of the files are the SHA-1 hashes of the original file path and name from the phone.  In this particular instance, the name of the database containing the SMS messages was 3d0d7e5fb2ce288813306e4d4636395e047a3d28, the same name cited in other articles.  Be careful, however, as this name can change.  If your backup does not contain this file name, a quick grep for 'chat_handle_join' (or any other tell-tale sign) should show you the correct sms.db file.

Dual EC SRP (in SageMath)

I've been using SageMath to work some example numbers for proposal to adapt Secure Remote Passwords to elliptic curves.  For anyone who might want to play around with it, you can read the code below or find the pastebin copy here.

I'm very new to Sage so I apologize if the code stinks.  

Note 1: In order to distinguish between Alice and Bob's variables, Alice variable's all begin with "A_" and Bob's with "B_".  Shared parameters (such as the curve E) do not have a prefix.

Note 2: I'm using static values for everything.  In reality, a, b and r should be random.  Feel free to change the values.  Alice and Bob should still agree on their shared key S.

Note 3: I don't use a salt value.  It's important in real life, but not necessary here.


# NIST Parameters
NIST_p = 115792089210356248762697446949407573530086143415290314195533631308867097853951
NIST_r = 115792089210356248762697446949407573529996955224135760342422259061068512044369
NIST_b = Integer(0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b)
NIST_Px = Integer(0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296)
NIST_Py = Integer(0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5)
NIST_Qx = Integer(0xc97445f45cdef9f0d3e05e1e585fc297235b82b5be8ff3efca67c59852018192)
NIST_Qy = Integer(0xb28ef557ba31dfcbdd21ac46e2a91e3c304f44cb87058ada2cb815151e610046)

# Construct E and Q using NIST parameters
F = GF(NIST_p)
E = EllipticCurve(F, [0, 0, 0, -3, NIST_b])
print "E: " + str(E)
print
Q = E(NIST_Qx, NIST_Qy)
print "Q: " + str(Q) + "\n"

# Use Alice's password hash to determine P
x = Integer(0x4efa264f5ef3e1a5c95736e07544ebf0)
print "MD5 Hash of \"curve\", x = " + str(x)
P = x*Q
print "P = x*Q = " + str(P) + "\n"

#Create Alice's public key
A_a = Integer(0xd103fb3406c351a03578097503d26fa5)
A_A = A_a*Q
print "Alice's secret key a = " + str(A_a)
print "Alice's public key A = a*Q = " + str(A_A) + "\n"

#Give Alice's key to Bob
B_A = A_A

# Create Bob's public key, Bprime
B_b = Integer(0x6abd98d8b311a26ab2cab394e1ecb8af)
print "Bob's secret key b = " + str(B_b)
B_Bprime = B_b*Q
print "Bob's value of Bprime = " + str(B_Bprime) + "\n"

# Generate Tp and Tq
B_r = Integer(0xdfd98dc638b36d4f86712de2e3bd37de)
print "Bob's random value r = " + str(B_r)
B_Tq = B_r*Q
B_Tp = B_r*P
print "Bob's Tq = r*Q = " + str(B_Tq)
print "Bob's Tp = r*P = " + str(B_Tp)

# Mask Bob's public key using Tp
B_B = B_Bprime+B_Tp
print "Bob's value of B = " + str(B_B) + "\n"

# Give B and Tq to Alice
A_Tq = B_Tq
A_B = B_B

# Calculate Alice's Tp
A_Tp = x*A_Tq
A_Bprime = A_B - A_Tp
print "Alice's Tp = " + str(A_Tp)
print "Alice's Bprime = " + str(A_Bprime) + "\n"

# Alice's calculation of the shared key
A_S = A_a*A_Bprime
print "Alice's S = " + str(A_S)

# Bob's calculation of the shared key
B_S = B_b*B_A
print "Bob's S = " + str(B_S)


Here's a screen capture of the output:

Click for full size

Dual EC SRP (request for feedback)

I'm looking for feedback on a proposal for adapting Secure Remote Passwords (SRP) to Elliptic Curves.  

Update: Steve Thomas provided an attack on this proposal.  I've been trying to find a way to protect against it without introducing new flaws but I have not been able to do so.  I will post about these efforts soon and link to the new post here.

For readers already familiar with elliptic curves and SRP, the very short version is this: I propose a protocol based on SRP and Diffie-Hellman using a public point Q and a secret point P=xQ where x is the user's password hash. The exchange of public values A and B is modified slightly. The server will generate a value B' = bQ but will also generate a random number r and multiply both P and Q by r. the value rQ is sent to the client along with the value B = B' + rP. The client must calculate the value rP = xrQ and subtract rP from B to get B'. A wrong value of B' resulting from the client's lack of knowledge of x or the server's lack of knowledge of P (in the case of an impostor) will result in a wrong value of S where S=aB'=bA=baQ. After calculating S, the client sends a verifier M1=H(A,B,S) which the server authenticates and responds to with H(A,M1,S).

I look forward to your comments. The (very rough) version follows below.

Abstract

Secure Remote Passwords (SRP) is a password authentication protocol based on Diffie-Hellman Key Exchange (DHKE).  SRP resists both passive and active attacks and does not store a password-equivalent on the authenticating server.  There has  been interest in adapting SRP to work on elliptic curves, but elliptic curves provide only an additive group whereas SRP requires a field (with addition and multiplication of field elements).

Secure Remote Passwords

Secure Remote Passwords (SRP) is a password authentication and key exchange protocol based on Diffie-Hellman Key Exchange (DHKE).  All computations in SRP are done in a finite field _n^* where n is a large prime(Wu, 1998).  The verifier stored on the server is the value g^x where g is a generator of _n^* and x is the SHA-1 hash of the user's password (Wu, 1998; Wu, 2000).  In addition to the verifier, the server stores a salt value s which is not secret and is used to compute the salted hash of the user's password.  The salt for each user should be unique.

The steps in the SRP protocol, illustrated in Table 1, are as follows:

1. The client signals his intent to log in and transmits his username, I,  to the server.  The server looks up the user's verifier v=g^x mod n and the salt value s.
2. The server responds to the client with the salt value s.  The client uses the hash function H to hash the salt, username and password into the digest value x.
3. The client generates a secret ephemeral value a, computes A=g^a and sends A to the server.  The server computes B = 3v + g^b = 3g^x + g^b.  Notice that this value of B is different than what we would expect in a Diffie-Hellman Key Exchange.  The addition of the value 3v serves two purposes.  First, the addition of v integrates the verifier into the protocol so that the server can prove knowledge of v and the client can prove knowledge of x.  Second, the multiplication by three introduces an asymmetry that prevents a novel (but not very serious) attack where an active attacker attempting to impersonate the server can make two guesses at the password (Wu, 2002).
4. The server sends the value B to the client and both sides hash the public values A and B to compute u.  The value u is used to ensure that the following computations are specific to this choice of public values (and therefore the ephemeral keys a and b) in order to prevent attacks where the client knows the verifier and can construct A to cancel out v in the server’s calculation of S.
5. Both sides compute the value S which will be hashed to create the key in step 8.
1. The client computes S = (B - 3g^x)^a+ux = (3g^x + g^b - 3g^x)^a+ux = (g^b)^a+ux = g^ba+bux
2. The server computes S = (Av^u)^b = (g^a(g^x)^u)^b = (g^a+ux)^b = g^ba+bux
6. The client hashes the values A, B and S to create the verifier M₁ and sends it to the server which verifies M₁ using its own calculation for S.
7. The server calculates M₂ by hashing the values A and M₁ along with its own calculated value for S and sends the result to the client.  The client verifies M₂.
8. The client and server both hash their previously calculated values of S (which should be equal) to create the session key K.

Step	Client	Traffic	Server
1		I = username ---->	Lookup the salt s and verifier v=gx
2	x=H(s, H( I:P))	<-----s
3	A=ga	A---->	B = 3v + gb
4	u = H(A,B)	<----B	u = H(A,B)
5	S = (B - 3gx)a+ux		S = (Avu)b
6	M1 = H(A,B,S)	M1---->	(verify M1)
7	(verify M2)	<----M2	M2 = H(A, M1, S)
8	K = H(S)		K= H(S)

Table 1: The SRP-6 Protocol (Wu, 2002).

A Critical Component of SRP

One of the most critical steps in SRP, and the one that makes it difficult to adapt SRP to elliptic curves is the calculation of B in step 3.  The server adds the user's verifier and the server's public key (g^b)  to produce the value B; the client then subtracts out the verifier exponentiating by a+ux.  This critical piece allows the client to prove knowledge of x without giving away any knowledge of what he thinks x is.  Suppose instead that both sides simply calculated g^abx.  An attacker posing as the server would be able to assemble g^ab and mount a dictionary attack to discover x since he would be able to check his guesses against the client's value for g^abx (using S).  The mechanism used by SRP does not allow this to happen.

The Elliptic Curve Discrete Logarithm Problem

The elliptic curve discrete logarithm problem (ECDLP) is similar to the ordinary discrete logarithm problem except that it involves point addition on elliptic curves instead of exponentiation.  It is also considered to be a hard problem.  Given a starting point P and an ending point T, the ECDLP challenges us to find the value x such that T = xP = P +...+ P (x times) (Paar and Pelzl, 2010, pg. 247). 

Dual_EC_DRBG

Dual_EC_DRBG is a random number generator that uses elliptic curve operations.  (See Figure 1).  In 2007, Shumow and Ferguson discovered that it was possible to backdoor Dual EC by selecting the points P and Q such that P = dQ for some value d.  Since it is relatively easy to reconstruct R*Q (or a handful of possibilities for R*Q) from T, an attacker who knows the value d can calculate R*P = d*(R*Q) which allows him to predict the next state value S.

 Figure 1

Dual EC SRP

The SRP protocol cannot be directly adopted for elliptic curves because elliptic curves provide only an additive group whereas SRP requires a field (with addition and multiplication of field elements).  This paper proposes an adaptation of SRP for elliptic curves using a mechanism inspired by the Dual EC DRBG backdoor to establish a shared parameter.  

Note: this isn't Dual EC DRBG.  I just came about the idea while studying elliptic curve cryptography and Dual EC DRBG.  The two points stored by the server in my scheme aren't necessarily any different than in a previous scheme proposed by Wang, but my proposal is simpler.  

In this protocol, the server stores two points on an elliptic curve, P and Q where P = xQ and where x is the hash of the user’s password (using a strong password hashing function).  The point Q is public.  The point P is the verifier which must be kept secret.  An attacker can use knowledge of P to impersonate the server or to mount a dictionary attack on x (by guessing values x’ and checking whether P = x’Q.

  

Step	Client	Traffic	Server
1	I = username	I ---->	Lookup the salt s and verifier P = xQ .
2	x=H(s, I, P)	<-----s
3	A=aQ	A----->
4		<----B, Tq	Generate random values r and b.  Calculate Tp = rP and Tq = rQ B = Tp + bQ B’ = bQ
5	Tp = xTq S = a(B – Tp) = aB’		S = bA
6	M1 = H(A,B,S)	M1---->	(verify M1)
7	(verify M2)	<----M2	M2 = H(A, M1, S)
8	K = H(S)		K= H(S)

Table 2: Dual EC SRP

The steps for the proposed Dual EC SRP protocol are as follows:

1. The client signals his intent to log in and transmits his username, I, to the server.  The server looks up the user’s verifier P=xQ and the salt value s.
2. The server responds with the salt value.  The client uses the hash function H to hash the salt, username and password into the digest value x.
3. The client generates a secret ephemeral value a, computes A = aQ and sends A to the server. 
4. The server generates random values r and b and computes B’ = bQ, T_p = rP and T_q = rQ.  The server sends T_q and B to the client.  T_p is never transmitted.
5. The client uses his password hash to compute T_p = xT_q then calculates B’ = B – T_p.  Finally, S = aB’.
6. The client calculates and sends M₁ = H(A, B, S).
7. The server calculates and responds with M₂ = H(A, M₁, S).
8. Both sides compute K = H(S).

Notes and Analysis

The structure of this protocol is very close to SRP, but the calculation of B and S is different and the value u=H(A,B) is missing entirely.  The value u is not used because the verifier P is not used directly in the calculation of S.  Rather, P is used to generate T_p which is calculated indirectly by the client as xT_q.  An attacker with knowledge of the verifier  cannot determine T_p from T_q and cannot trick the server into cancelling it out.

The server does not directly use either T value in the calculation of S.  Instead, the client must be able to determine T_p in order to subtract it from B to learn B’.  The server always knows B and B’.

Notice that the server does not directly use either the verifier or T_p in order to calculate the key.  If an attacker poses as the server without knowing P or x, the attacker will be able to generate the “correct” key: bA = baQ.  The client, however, does use the value T_p in order to determine B’ and will arrive at a different result.  The attacker cannot use the client’s calculation of S to mount a dictionary attack either since the client’s calculations require both T_p and a.  Put differently: the client and server must agree on the value of T_p or the client will end up with the wrong value for B’.

For a passive eavesdropper, the security of Dual EC SRP reduces to Elliptic Curve Diffie-Hellman Problem and the reduction is simpler than in SRP.   The Elliptic Curve Diffie-Hellman Problem asks us to determine the value S=baQ from the values A=aQ and B = bQ.  The best known method for doing so is to compute the discrete logarithm of A or B, but it has not been proven whether the Diffie-Hellman and discrete logarithm problems are actually equivalent.

Here, the only complication is the addition of the value T_p to the server’s transmitted value of B.  The client subtracts out T_p from B and computes aB’.   Assume that the passive observer is able to recover  x or T_p and can calculate B’.   The eavesdropper then has the values A = aQ and B’ = bQ. 

The transmitted values s and T_q do not carry any information about the values a or b.  As with SRP, the verifiers M₁ and M₂ must be computed using a secure cryptographic hash function in order to prevent pre-image attacks which might reveal information about the computed value S.

Questions

What have I overlooked?

Can an active attacker gather enough information to mount a dictionary attack on the user’s password?

Update: There isn't much in the literature about adopting SRP to elliptic curves, but there have been prior proposals.  The only one I have a copy of, by Yongge Wang, was proposed in 2001.  I believe that my scheme is simpler, easier to analyze and has a more straightforward reduction to the EC Diffie-Hellman Problem.  

References

Hoffstein, J., Pipher, J., & Silverman, J.  (2008).  An Introduction to Mathematical        Cryptography.  New York, NY: Springer.

Paar, C., Pelzl, J.  (2010).  Understanding Cryptography: A Textbook for Students and

            Practitioners.  New York, NY: Springer.

Wu, T.  (1998).  The Secure Remote Password Protocol.  In Proceedings of the1998 Internet

Society Network and Distributed System Security Symposium, San Diego, CA .  Retrieved from http://srp.stanford.edu/doc.html

Wu, T.  (2000).  The SRP Authentication and Key Exchange System.  In Network Working

Group, Request for Comments: 2945.    Retrieved from http://tools.ietf.org/rfc/rfc2945.txt

Wu, T.  (2002).  SRP-6: Improvements and Refinements to the Secure Remote Password

            Protocol.   Retrieved from http://srp.stanford.edu/srp6.ps