Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
TechEd Developers 2007
October 12, 2007
Looks like I’ll be in Barcelona this year for TechEd EMEA. Very excited! Don’t yet know exactly what I’ll be doing there – I’m still working on that. Anyway, hope to see you there!
Permalink | Comments (0)
Line of Business Application Security
October 11, 2007
The description in that blog post regarding an ERP tool for Information Security is plenty vague, and the analogy to VSTS is perhaps even more so, but I’m hoping what he means is that they’re going to make the lives of countless security auditors simpler. Easier said than done, but it’s worth trying . . .
Permalink | Comments (0)Fun High-Integrity 64-bit Debugging
October 10, 2007
It gets worse. Running the 64-bit custom action code as an interactive user worked fine. It was only in the context of MSI that was failing. Initially, I wasn’t even sure it was the custom action causing it – it could have been any other piece of the MSI (for example, the install payload includes an NT service that could have been tanking).
However, before I learned about that useful logging information, I was trying to figure out how to get the custom action to run in the debugger. I first tried setting up msiexec.exe to always launch in ntsd.exe via Image File Execution Options in the registry. No luck. The first instance would start fine and kick off the install sequence. But the second instance – the one that hosts the custom action – was failing the debugger attach with Access Denied. Painful!
So then I learned about the log file stuff which confirmed the custom action as the 100% culprit. That inspired me to focus on getting this thing in a debugger, one way or another. I knew MSI was running my custom action as Local System, and the Access Denied made me suspect a privilege issue (even though I was running all of these tests as local admin). Thus, my next approach was to configure my x64 (Vista) test machine with a kernel debugger.
I first tried setting a global breakpoint in the kd on nt!NtCreateProcess, but that didn’t work; it never fired. I may not have been in the correct context for that to work. So then I thought – what the heck? – add a hard DebugBreak to the custom action DLL entry point. It’ll either take out the host process or cause it to break into my kd. Fortunately it did the latter!
Anyway, once you’ve got the thing running in a proper debugging environment, you know it’s just a matter of time before the bug is squashed. Turns out the line of code that sets a Group name (via the resource-based “indirect string” syntax) for the new firewall rule was throwing a COM exception. Admittedly, I still don’t know exactly why that only fails in the 64-bit system scenario; I still need to try using a full path to the binary with the resource for the group name. For the purpose of this sample, it was fine to just leave that property blank – problem solved.
kd> !process -1
User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Groups:
00 S-1-16-16384 (no name mapped)
Doh! That last SID represents the System Integrity Level (per SECURITY_MANDATORY_SYSTEM_RID in winnt.h). Now, Image File Execution Options will cause a debugger to be launched at system, but apparently not with sufficient juice to debug a high-integrity process. Anyone confirm this?
Permalink | Comments (0)
The Internet2 Network Diagnostic Tool
October 9, 2007
I decided to try it out. There’re two versions of their Windows client – Java-based and command-line. The latter requires cygwin to build and I couldn’t find any working links to built bins. The former required me to install the Java runtime on my Vista machine, but that ended up being totally painless (see one of the first links at http://www.java.com/en/download/manual.jsp)! If anyone at E2EPI is listening – please fix your links …
TCP/Web100 Network Diagnostic Tool v5.2.1e
running 10s inbound test (server to client) . . . . . . 874.46kb/s Web100 reports the Round trip time = 364.34 msec; the Packet size = 1460 Bytes; and No packet loss was observed.
Increasing the current receive buffer (64.0 KB) will improve performance This connection is network limited 12.34% of the time.
Interesting article in the October 2007 Communications of the ACM entitled “Current Issues Faced by Technology Entrepreneurs”. (Nice how that usage of the word “issues” can now show up in the title of an article in a scientific journal. But I digress.)
The link to the article is here - http://portal.acm.org/citation.cfm?id=1290963&jmp=abstract&coll=Portal&dl=ACM&CFID=38204135&CFTOKEN=22949127, but unfortunately like most ACM stuff, this isn’t free.
Anyway, the highlight of the article is its evolution of the traditional Technology Acceptance Model into a new concept: the Technology Acceptance and Market Success Model (TAMSM). The TAMSM (I wish I could at least find their block diagram somewhere on the web, but again it doesn’t seem to show up anywhere free yet) is broadened to include success metrics for a post-bust, post-bubble IT start-up. That is, we’ve been through the bubble, we’ve been through the bust period immediately following when no money was available, now we’re here. The TAMSM includes the following features: - Availability of financial resources, skilled employees and co-founders in the same geographical area, and potential outsourcing
- Creation of “products perceived to be easy to use and useful”
- Presence of a suitably educated customer base with the ability and intention to use the product
No, this isn’t new information, but it is a new way to look at the TAM, and “models” in general can be a good way to make even obvious concept memorable.
Testing & Debugging IPsec Security Associations
October 5, 2007
I was recently doing some IPsec debugging and found myself in a situation where I needed to know exactly which machine certificate was being used for the AuthIP authentication. That is, it wasn’t enough to know that the connection was established; I needed to ensure it was using right cert. Unfortunately, the IP Security Monitor MMC snap-in doesn’t help - it gives the source, destination, authentication method, and encryption algs, but it doesn’t give the identity of the cert.
Ditto fo netsh.exe, which gives roughly the same information:
>netsh ipsec dynamic show mmsas
IKE Main Mode SAs at 10/2/2007 9:51:31 AM
———————————————————————-
Cookie Par :clclb5a7f901784c:374d415ff84d7e99
Sec Methods :3DES/SHA 1/2/28800
Auth Mode :RSA Signature
Source :192.168.1.177 ,port 500
Destination :192.168.1.184 , port 500
But then it occurred to me that the IPsecPing.exe sample could probably be extended to provide this information. Sure enough! The IKEEXT_CERTIFICATE_CREDENTIAL0 structure is populated with a cert hash, and is included in the IKEEXT_CREDENTIAL0 structure when its IKEEXT_AUTHENTICATION_METHOD_TYPE is set to IKEEXT_CERTIFICATE (see iketypes.h in the SDK). Simple matter to dump that hash out to the console with everything else.
First delete the existing security associations:
>netsh ipsec dynamic delete sa
OK.
Then run the new and improved IPsecPing (noting the new cert hash displayed in the middle of the fourth line of output):
>IPSecPing.exe -v -4 jwsecure-v8
Create socket <AF_INET, SOCK_STREAM, IPPROTO_TCP>, return code=0
TCP over IPsec connect to dest: jwsecure-v8, addr 192.168.1.184:135…
TCP over IPSec WSAConnect: success, 0.09s from 192.168.1.177:49723 to 192.168.1.184:135
IKEMM: 3DES, SHA1, DH_2, Certificate [ D30D68BE5288FE2EDAEFF20E204E0F1BE2D0E3FE ], 28800s,
192.168.1.177, 192.168.1.184, icookie=0xa7b5c1c1, rcookie=0×5f414d37
IKEQM: transport, SHA1, 3DES, 100000kb, 3600s, 192.168.1.177, 192.168.1.184, idletime=300s
Disconnecting, IKE MM and QM deleted
Then feed that hash to certutil to verify it’s the one I’m expecting: >certutil.exe -store MY D30D68BE5288FE2EDAEFF20E204E0F1BE2D0E3FE MY ================ Certificate 0 ================ Serial Number: 19448d66000000000027
Issuer: CN=LHTest-CA1, DC=LHTest, DC=local NotBefore: 9/28/2007 5:45 PM NotAfter: 9/27/2008 5:45 PM Subject: EMPTY (DNS Name=jwsecure-v6.LHTest.local)
Non-root Certificate Template: Workstation, Workstation Authentication Cert Hash(sha1): d3 0d 68 be 52 88 fe 2e da ef f2 0e 20 4e 0f 1b e2 d0 e3 fe
Key Container = 52170cddeeaf13800cf207cbdf975d48_e0d1ac96-454a-4e9d-acd5-01f307e67f97 Provider = Microsoft RSA SChannel Cryptographic Provider Private key is NOT exportable Encryption test passed CertUtil: -store command completed successfully.
