RE: [ActiveDir] Risks of exposure of machine account passwords
I agree with Joe, I trust very FEW things, or people, you don't meet my standards, sorry no access, it might be harse, but it's a CYA measure. Z Edward E. Ziots Network Engineer Lifespan Organization MCSE,MCSA,MCP+I,M.E,CCA,Network+, Security + email:[EMAIL PROTECTED] cell:401-639-3505 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, January 08, 2007 10:01 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Risks of exposure of machine account passwords You can't treat everyone inside your network like criminals or you'll never get anything done. I don't completely agree with this. When you are an admin, especially a DA, you need to be etxremely paranoid about things and trust very little that you don't directly control when using your ID. When I see folks who aren't running separate accounts for admin work and normal work I know they aren't paranoid enough. Then if someone had two accounts the next question is are the passwords synced which is pretty normal to see but almost as bad as using your DA ID to log into your PC and doing work in which you aren't specifically making changes. The next thing to do to cut down on risk is do interactive auth as well as application auth to servers and DCs as little as possible with enhanced IDs. Just too many possible ways to get screwed whether on purpose or by accident to treat anything but proven trusted systems and people as anything but a danger. Yes it slows you down, but folks need to be very careful with their most powerful IDs. If people follow these guidelines it is considerably more difficult to compromise them through social engineering types of attacks such as outlined. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: Michael B Allen [mailto:[EMAIL PROTECTED] Sent: Monday, January 08, 2007 5:35 PM To: ActiveDir@mail.activedir.org Cc: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Risks of exposure of machine account passwords On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) If you already own a machine with an FQDN and you can send email to people as someone internal then it would be pretty hard to keep you out since you're already somewhat trusted. You can't treat everyone inside your network like criminals or you'll never get anything done. And if you do have a criminal inside you should take it up with HR not IT. But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
RE: [ActiveDir] Risks of exposure of machine account passwords
Hi Michael, I'm not sure what we are gaining here. You talking about When the client sends the password hashes you send them to the target server. So the web client doesn't authenticate with the web server it authenticates directly with the target server by proxying the NTLMSSP tokens Are you talking about transitioning the protocol as well? e.g. Client -- HTTP -- Your Website/PC -- RPC -- Domain Controller Cheers Ken From: Michael B Allen [mailto:[EMAIL PROTECTED] Sent: Tue 9/01/2007 5:24 PM To: ActiveDir@mail.activedir.org Cc: Ken Schaefer Subject: Re: [ActiveDir] Risks of exposure of machine account passwords On Tue, 9 Jan 2007 14:13:33 +1100 Ken Schaefer [EMAIL PROTECTED] wrote: I'm not sure what NTLM SSO Pass-Through is, but NTLM is not natively delegatable, so you can't (in the normal course of events) use this to create an account anywhere except on the local machine. There may be easier ways to create accounts on local machines. Perhaps proxy would be a better term. When the web client requests the challenge you request it from the target server (e.g. the DC) and send it back to the client. When the client sends the password hashes you send them to the target server. So the web client doesn't authenticate with the web server it authenticates directly with the target server by proxying the NTLMSSP tokens. This is effectively a man-in-the-middle attack. Digital signatures are used to twart an MITM so if you require SMB signing you can prevent such an attack (although if you can authenticate LDAP with NTLM you might be able to get around that). Actually now that I think about it I think W2K3 requires SMB signing so maybe this permutation wouldn't work. But workstations do not require SMB signing. One could authenticate back to the client and place and create an account or simply place an executable in their Startup. But again, if you're already trusted on the network it's game over. Mike On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/
Re: [ActiveDir] Risks of exposure of machine account passwords
I haven't tried it, but I would have assumed (I know, I know) that if somebody *could* gain the computer account password: 1) you have much bigger issues 2) they would have access to a machine. See #1 3) they would have access to anything that authenticated users have access to. See #1 4) they know enough about your systems to mount a pretty good attack. See #1 IIRC, machine accounts can get old for various but legitimate reasons. Consider a laptop that hasn't been back on your trusted network for over 30 days. It would have an old password, but it may be legitimate and may come back to your network in the next 60 and would be able to synchronize it's password changes then. You really have to protect the source of the machine account password which is random and is not readily available. Do you have a way to get the machine account passwords? If so, why? And if you have them, why don't you just go after the user passwords? On 1/8/07, Mr Oteece [EMAIL PROTECTED] wrote: What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Otis
Re: [ActiveDir] Risks of exposure of machine account passwords
The question is whether having the machine account password and access to that system gives you any ability to impersonate users or elevate your access to other systems. Presumably, if you could get into the protected store, you could compromise any locally cached tickets for other users to specific services on remote systems. This is perhaps non-trivial on Windows systems, but becomes a lot easier when you are root on a *nix system that is using Kerberos against AD. Sticking just to Windows, could you conceivably forge new tickets to remote resources as an arbitrary user? That would be the rationale for attacking the computer account rather than a user account. More bang for the buck. On 1/8/07, Al Mulnick [EMAIL PROTECTED] wrote: I haven't tried it, but I would have assumed (I know, I know) that if somebody *could* gain the computer account password: 1) you have much bigger issues 2) they would have access to a machine. See #1 3) they would have access to anything that authenticated users have access to. See #1 4) they know enough about your systems to mount a pretty good attack. See #1 IIRC, machine accounts can get old for various but legitimate reasons. Consider a laptop that hasn't been back on your trusted network for over 30 days. It would have an old password, but it may be legitimate and may come back to your network in the next 60 and would be able to synchronize it's password changes then. You really have to protect the source of the machine account password which is random and is not readily available. Do you have a way to get the machine account passwords? If so, why? And if you have them, why don't you just go after the user passwords? On 1/8/07, Mr Oteece [EMAIL PROTECTED] wrote: What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Otis
RE: [ActiveDir] Risks of exposure of machine account passwords
If an attacker gets access to a machine account password they can connect to AD as that computer which is usually just normal user access rights. In fact, if you set up an auth as the computer and tap an ADAM instance and look at the RootDSE it will show you the groups you are a member of that are right for that context. For example: tokenGroups: TEST\TESTCMP$ tokenGroups: TEST\Domain Computers tokenGroups: Everyone tokenGroups: BUILTIN\Users tokenGroups: NT AUTHORITY\NETWORK tokenGroups: NT AUTHORITY\Authenticated Users tokenGroups: NT AUTHORITY\This Organization I don't think overall that computer accounts are any more risky than normal userids. On the flip side, I think it is silly to leave enabled machine accounts lying around for computers that you are relatively sure will never reconnect. That is why I wrote oldcmp and make it available to everyone. The key part is as Al mentioned, how did they get that password? I don't recall seeing anything that will extract that from a machine and even so, I expect it is much easier and useful to target user passwords than computer passwords - primarily admin type user's. A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mr Oteece Sent: Monday, January 08, 2007 1:39 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Risks of exposure of machine account passwords What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Otis
RE: [ActiveDir] Risks of exposure of machine account passwords
Actually Machine password can be extracted from LC3 and higher, done it myself, and it seems that Windows Choice of Secure password with the DC's insist that hard to crack. You can also use Opcrack with rainbow tables, and cachedump or pwdump3e to get the computer account hash and crack that bugger simply. I agree, its gotta usuallybe an inside job to get it, and the computer account could prove less fruitful, than a juicer user account with higher level access, but its an interesting way to hack I suppose. TY Z Edward E. Ziots Network Engineer Lifespan Organization MCSE,MCSA,MCP+I,M.E,CCA,Network+, Security + email:[EMAIL PROTECTED] cell:401-639-3505 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, January 08, 2007 3:33 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Risks of exposure of machine account passwords If an attacker gets access to a machine account password they can connect to AD as that computer which is usually just normal user access rights. In fact, if you set up an auth as the computer and tap an ADAM instance and look at the RootDSE it will show you the groups you are a member of that are right for that context. For example: tokenGroups: TEST\TESTCMP$ tokenGroups: TEST\Domain Computers tokenGroups: Everyone tokenGroups: BUILTIN\Users tokenGroups: NT AUTHORITY\NETWORK tokenGroups: NT AUTHORITY\Authenticated Users tokenGroups: NT AUTHORITY\This Organization I don't think overall that computer accounts are any more risky than normal userids. On the flip side, I think it is silly to leave enabled machine accounts lying around for computers that you are relatively sure will never reconnect. That is why I wrote oldcmp and make it available to everyone. The key part is as Al mentioned, how did they get that password? I don't recall seeing anything that will extract that from a machine and even so, I expect it is much easier and useful to target user passwords than computer passwords - primarily admin type user's. A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mr Oteece Sent: Monday, January 08, 2007 1:39 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Risks of exposure of machine account passwords What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Otis
Re: [ActiveDir] Risks of exposure of machine account passwords
I'm not sure I could forge new tickets as an authenticated user, to be honest. I never really tried though I suspect that's more difficult than I need to attempt because if I have that information, I already know enough and have enough to mount a plausible attack. In short, I never took it to the next step because that's more work than needed. As joe points out, you have authenticated user rights. That's no different than any other type of security account. So your implied question, Can I elevate my credentials if I have access to your network as an authenticated user is the one I think is relevant here. I don't differentiate between a computer sec prin and a user sec prin. They are the same as far as I'm concerned and for the intents and purposes of this conversation. The short answer = I have a lot better chance of elevating my privs if I have access to your network than if I don't, whether as a user or not. Just because the user is an inanimate object doesn't make them any less/more of a risk than a computer ;) Al On 1/8/07, Mr Oteece [EMAIL PROTECTED] wrote: The question is whether having the machine account password and access to that system gives you any ability to impersonate users or elevate your access to other systems. Presumably, if you could get into the protected store, you could compromise any locally cached tickets for other users to specific services on remote systems. This is perhaps non-trivial on Windows systems, but becomes a lot easier when you are root on a *nix system that is using Kerberos against AD. Sticking just to Windows, could you conceivably forge new tickets to remote resources as an arbitrary user? That would be the rationale for attacking the computer account rather than a user account. More bang for the buck. On 1/8/07, Al Mulnick [EMAIL PROTECTED] wrote: I haven't tried it, but I would have assumed (I know, I know) that if somebody *could* gain the computer account password: 1) you have much bigger issues 2) they would have access to a machine. See #1 3) they would have access to anything that authenticated users have access to. See #1 4) they know enough about your systems to mount a pretty good attack. See #1 IIRC, machine accounts can get old for various but legitimate reasons. Consider a laptop that hasn't been back on your trusted network for over 30 days. It would have an old password, but it may be legitimate and may come back to your network in the next 60 and would be able to synchronize it's password changes then. You really have to protect the source of the machine account password which is random and is not readily available. Do you have a way to get the machine account passwords? If so, why? And if you have them, why don't you just go after the user passwords? On 1/8/07, Mr Oteece [EMAIL PROTECTED] wrote: What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Otis
Re: [ActiveDir] Risks of exposure of machine account passwords
Assuming you have LC3 still around... now you have to use other tools. However, the cracking ease is dependent upon the lanman hash settings. If you have 98/NT, other alternative OSs and have to have lanman enabled.it's trivial if you are on the lan to crack the passwords using (and I forget the group that took LC3 and now have made it opensource) LC3's equivalent. Ziots, Edward wrote: Actually Machine password can be extracted from LC3 and higher, done it myself, and it seems that Windows Choice of Secure password with the DC's insist that hard to crack. You can also use Opcrack with rainbow tables, and cachedump or pwdump3e to get the computer account hash and crack that bugger simply. I agree, its gotta usuallybe an inside job to get it, and the computer account could prove less fruitful, than a juicer user account with higher level access, but its an interesting way to hack I suppose. TY Z Edward E. Ziots Network Engineer Lifespan Organization MCSE,MCSA,MCP+I,M.E,CCA,Network+, Security + email:[EMAIL PROTECTED] cell:401-639-3505 *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *joe *Sent:* Monday, January 08, 2007 3:33 PM *To:* ActiveDir@mail.activedir.org *Subject:* RE: [ActiveDir] Risks of exposure of machine account passwords If an attacker gets access to a machine account password they can connect to AD as that computer which is usually just normal user access rights. In fact, if you set up an auth as the computer and tap an ADAM instance and look at the RootDSE it will show you the groups you are a member of that are right for that context. For example: tokenGroups: TEST\TESTCMP$ tokenGroups: TEST\Domain Computers tokenGroups: Everyone tokenGroups: BUILTIN\Users tokenGroups: NT AUTHORITY\NETWORK tokenGroups: NT AUTHORITY\Authenticated Users tokenGroups: NT AUTHORITY\This Organization I don't think overall that computer accounts are any more risky than normal userids. On the flip side, I think it is silly to leave enabled machine accounts lying around for computers that you are relatively sure will never reconnect. That is why I wrote oldcmp and make it available to everyone. The key part is as Al mentioned, how did they get that password? I don't recall seeing anything that will extract that from a machine and even so, I expect it is much easier and useful to target user passwords than computer passwords - primarily admin type user's. A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Mr Oteece *Sent:* Monday, January 08, 2007 1:39 PM *To:* ActiveDir@mail.activedir.org *Subject:* [ActiveDir] Risks of exposure of machine account passwords What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Otis -- Letting your vendors set your risk analysis these days? http://www.threatcode.com If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will hunt you down... http://blogs.technet.com/sbs List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
Re: [ActiveDir] Risks of exposure of machine account passwords
On Mon, 8 Jan 2007 10:39:17 -0800 Mr Oteece [EMAIL PROTECTED] wrote: What are the risks associated with the exposure of machine account passwords in Active Directory? Passwords are changed for machine accounts regularly, but they don't really expire and can get rather old. If an attacker has access to this password, what sort of access would he have to other systems on the network via Kerberos? i.e., would he be able to forge service tickets as other users and elevate his access elsewhere? The laxness of policy surrounding these accounts suggests that this is not a huge risk. Should we be more concerned with these old passwords? Those passwords are long, random and changed automatically over an schannel NETLOGON pipe. I don't know how their stored by the client but I think it's highly unlikely anyone would be able to actually extract one or snoop it. Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
Re: [ActiveDir] Risks of exposure of machine account passwords
On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) If you already own a machine with an FQDN and you can send email to people as someone internal then it would be pretty hard to keep you out since you're already somewhat trusted. You can't treat everyone inside your network like criminals or you'll never get anything done. And if you do have a criminal inside you should take it up with HR not IT. But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
Re: [ActiveDir] Risks of exposure of machine account passwords
Just one? I prefer the on|off bit to be flipped. What was your method? :) On 1/8/07, Michael B Allen [EMAIL PROTECTED] wrote: On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) If you already own a machine with an FQDN and you can send email to people as someone internal then it would be pretty hard to keep you out since you're already somewhat trusted. You can't treat everyone inside your network like criminals or you'll never get anything done. And if you do have a criminal inside you should take it up with HR not IT. But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
RE: [ActiveDir] Risks of exposure of machine account passwords
You can't treat everyone inside your network like criminals or you'll never get anything done. I don't completely agree with this. When you are an admin, especially a DA, you need to be etxremely paranoid about things and trust very little that you don't directly control when using your ID. When I see folks who aren't running separate accounts for admin work and normal work I know they aren't paranoid enough. Then if someone had two accounts the next question is are the passwords synced which is pretty normal to see but almost as bad as using your DA ID to log into your PC and doing work in which you aren't specifically making changes. The next thing to do to cut down on risk is do interactive auth as well as application auth to servers and DCs as little as possible with enhanced IDs. Just too many possible ways to get screwed whether on purpose or by accident to treat anything but proven trusted systems and people as anything but a danger. Yes it slows you down, but folks need to be very careful with their most powerful IDs. If people follow these guidelines it is considerably more difficult to compromise them through social engineering types of attacks such as outlined. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -Original Message- From: Michael B Allen [mailto:[EMAIL PROTECTED] Sent: Monday, January 08, 2007 5:35 PM To: ActiveDir@mail.activedir.org Cc: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Risks of exposure of machine account passwords On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: A dirty trick I have used in the past to disprove how secure an environment was was to set up a web site on a workstation, enable basic auth only, write a little perl cgi script to write the creds sent to the website to a log file and throw up a website unavailable screen and then tell admins that I have a web site that doens't seem to authenticate users properly could they try to logon to see if it is just my test IDs or a permission problem. I would say at least 50%-60% of the time the admins will go to the page and type in their creds. Alternately try to get an admin to log into a workstation I control. In far too many cases I think you will find admins are user's too... :) If you already own a machine with an FQDN and you can send email to people as someone internal then it would be pretty hard to keep you out since you're already somewhat trusted. You can't treat everyone inside your network like criminals or you'll never get anything done. And if you do have a criminal inside you should take it up with HR not IT. But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
RE: [ActiveDir] Risks of exposure of machine account passwords
I'm not sure what NTLM SSO Pass-Through is, but NTLM is not natively delegatable, so you can't (in the normal course of events) use this to create an account anywhere except on the local machine. There may be easier ways to create accounts on local machines. Cheers Ken From: [EMAIL PROTECTED] on behalf of Michael B Allen Sent: Tue 9/01/2007 9:34 AM To: ActiveDir@mail.activedir.org Cc: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Risks of exposure of machine account passwords On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike
Re: [ActiveDir] Risks of exposure of machine account passwords
On Tue, 9 Jan 2007 14:13:33 +1100 Ken Schaefer [EMAIL PROTECTED] wrote: I'm not sure what NTLM SSO Pass-Through is, but NTLM is not natively delegatable, so you can't (in the normal course of events) use this to create an account anywhere except on the local machine. There may be easier ways to create accounts on local machines. Perhaps proxy would be a better term. When the web client requests the challenge you request it from the target server (e.g. the DC) and send it back to the client. When the client sends the password hashes you send them to the target server. So the web client doesn't authenticate with the web server it authenticates directly with the target server by proxying the NTLMSSP tokens. This is effectively a man-in-the-middle attack. Digital signatures are used to twart an MITM so if you require SMB signing you can prevent such an attack (although if you can authenticate LDAP with NTLM you might be able to get around that). Actually now that I think about it I think W2K3 requires SMB signing so maybe this permutation wouldn't work. But workstations do not require SMB signing. One could authenticate back to the client and place and create an account or simply place an executable in their Startup. But again, if you're already trusted on the network it's game over. Mike On Mon, 8 Jan 2007 15:33:01 -0500 joe [EMAIL PROTECTED] wrote: But I can add an improved permutation to your dirty trick. Send out an email with a link to your site but use NTLM SSO pass-through to create a bogus account with a predefined password. If someone with domain admin privs so much as stumbles across your site they will create the said account and not even know they did it. No credentials necessary and no SSO account necessary. Just a website with an FQDN. There is one simple security setting that will thwart this attack though. For bonus points, does anyone know what it is? :- Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
