Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Retrieving remote file access details

midimanmidiman Member Posts: 6
Hello FSD Forum,

Would anyone be able to perhaps shed some insight on this [hopefully] interesting question, please:

I am writing an FSD filter driver, and all is working fine.
I can detect remote access IRPs through a combination of techniques described elsewhere on this site (e.g. detect system process, token impersonation etc.)

What I'm trying to find out is if there is anywhere stored the machine name/ip address/netbios name of the machine that initiated the request (if it's a local access, it's a moot point really, only useful for remote accesses).

I have retrieved the (Client) Access Token from the IRP_MJ_CREATE message, but I can't see if/where the remote machine name/address details are stored.

I could enumerate LSA sessions up in user mode for the given LUID, but this is inefficient at best, and potentially can give incorrect results if the same user is logged on from multiple remote points.

Another somewhat 'heavyweight' technique would be to maintain my own logon session table using an SSPI or similar DLL.

Has anyone come across this issue and been able to find remote machine name/address details for IRP_MJ_CREATE requests initiated from a remote machine?

Many thanks,
psturge

Comments

  • Doug_NDoug_N Member - All Emails Posts: 97
    I opened a support request with Microsoft and spoke with a file system
    engineer and a network stack engineer and they both said it can't really be
    done in any kind of safe/supportable way. But if you find anything new,
    please let us know!!

    Doug

    > -----Original Message-----
    > From: xxxxx@lists.osr.com [mailto:bounce-348858-
    > xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
    > Sent: Tuesday, December 30, 2008 9:08 AM
    > To: Windows File Systems Devs Interest List
    > Subject: [ntfsd] Retrieving remote file access details
    >
    > Hello FSD Forum,
    >
    > Would anyone be able to perhaps shed some insight on this [hopefully]
    > interesting question, please:
    >
    > I am writing an FSD filter driver, and all is working fine.
    > I can detect remote access IRPs through a combination of techniques
    > described elsewhere on this site (e.g. detect system process, token
    > impersonation etc.)
    >
    > What I'm trying to find out is if there is anywhere stored the machine
    > name/ip address/netbios name of the machine that initiated the request
    > (if it's a local access, it's a moot point really, only useful for
    > remote accesses).
    >
    > I have retrieved the (Client) Access Token from the IRP_MJ_CREATE
    > message, but I can't see if/where the remote machine name/address
    > details are stored.
    >
    > I could enumerate LSA sessions up in user mode for the given LUID, but
    > this is inefficient at best, and potentially can give incorrect results
    > if the same user is logged on from multiple remote points.
    >
    > Another somewhat 'heavyweight' technique would be to maintain my own
    > logon session table using an SSPI or similar DLL.
    >
    > Has anyone come across this issue and been able to find remote machine
    > name/address details for IRP_MJ_CREATE requests initiated from a remote
    > machine?
    >
    > Many thanks,
    > psturge
    >
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    > For our schedule debugging and file system seminars
    > (including our new fs mini-filter seminar) visit:
    > http://www.osr.com/seminars
    >
    > You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
    > To unsubscribe send a blank email to xxxxx@lists.osr.com
  • There is no general solution. The pattern in which are files accessed from servers (e.g. SMB, IIS, Apache, 3-rd party...) is not easily predictable. E.g. Files can be accessed asynchronously from system worker thread. I can imagine proprietary TDI filter cooperating with FSF/mini-filter for some specific protocol with strong limitations. E.g. If SSL is used you cannot easily inspect protocol to find out relations between protocol command (TCP/IP connection) and IRP/IPRs. You can probably use man-in-the-middle attack for SSL but it is quite high price with low benefit. Note that not all SSPI providers are available in kernel mode. Furthermore it seems there is only server side implementation available.
    -bg
  • > Furthermore it seems there is only server side implementation available.
    Correction: It concerns the authentication protocols like NTLM so probably it is not case of SSL provider.

    -bg
  • midimanmidiman Member Posts: 6
    Many thanks for your informative replies.
    It's looking like the solution will have to be a co-operation between gathered FSD IRPs and some other [external] auth pkg auditor. This will most likely be in a user-mode service (e.g. SSPI DLL) - TDI will be too problematic for the reasons stated above.
    When I have reached a solution, I'll post a reply for others looking for similar functionality.

    Thanks!
    - Peter
  • Malcolm_SmithMalcolm_Smith Member Posts: 124
    How would any such solution work if the mapping between remote accesses
    and local accesses is not 1:1? If client A access a file and triggers
    an IRP_MJ_CREATE, then client B accesses the file and this request is
    satisfied from the existing handle (does not trigger an IRP_MJ_CREATE),
    would your filter still behave correctly?

    - M

    xxxxx@yahoo.com wrote:
    > Many thanks for your informative replies.
    > It's looking like the solution will have to be a co-operation between gathered FSD IRPs and some other [external] auth pkg auditor. This will most likely be in a user-mode service (e.g. SSPI DLL) - TDI will be too problematic for the reasons stated above.
    > When I have reached a solution, I'll post a reply for others looking for similar functionality.
    >
    > Thanks!
    > - Peter
    >
    >


    --
    This posting is provided "AS IS" with no warranties, and confers no rights
  • midimanmidiman Member Posts: 6
    An excellent question.
    From my [admittedly limited] testing so far, if client A and client B are different hosts, an IRP_MJ_CREATE is generated for each, even when the handles are the same (a symptom of Windows security, perhaps?). As I've only performed limited testing in this regard (AD auths on Win2k3), this may not always be the case. For scenarios where IRP_MJ_CREATEs are not generated, an FSD dispatch hook routine would never catch this in any case, regardless of any external login id mapping. Yes, it's true that an IRP_MJ_CREATE is needed in order to capture the Client/PrimaryToken of the caller.
    The 'mapping' technique to be used for any solution relies on the fact that LSA generates unique LUIDs for every logon, remote and local, including multiple logons from the same user (SID). These are the same LUIDs as stored in Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary] -or- [Client]Token.
    Once the FSD has captured the LUID, this can be 'looked-up' in LSA to find the assoicated logon session. It is this lookup mechanism that is being investigated (so far, a security pkg DLL is the front-runner for achieving this, as it holds both LUID and client data).
    Any insight/advice into potential issues regarding Malcolm's question about 'missing' IRP_MJ_CREATES would be greatly appreciated.
    Thanks!
    - Peter
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    You are asking about specific server behavior, so the answer may very
    well end up being dependent upon even the specific patch release of the
    given server.

    In my experience, SRV will impersonate the remote user for each
    IRP_MJ_CREATE. When it has an existing handle (such as for the "root
    directory" of the share) it will re-open (So,
    FileObject->FileName.Length = 0 and FileObject->RelatedFileObject != 0)
    precisely to ensure that a correct security check is done (otherwise, it
    would be an information exposure issue, since SRV shouldn't be making
    those security decisions.) If you find a case in which this is not
    true, I would expect you could report it as a security bug (that doesn't
    mean it cannot happen...)

    However, let's not lose sight of the fact that you have at least two
    other standard file servers currently shipping: DAV (the "Distributed
    Authoring and Versioning" protocol extensions to HTTP) and NFS. In the
    former case, you'd now have to be concerned about how the DAV server
    (which is IIS as far as I know) implements its own logic. I must admit,
    I've never investigated that at all. NFS Server is now shipped in the
    distribution kit for Windows Server 2008 (versus previously when it was
    in a separate package called "Services For Unix" but available for
    Windows 2000 Server and Windows Server 2003.) I would expect that to be
    more complicated because it is performing its own security mapping
    (e.g., from the NFS uid/gid protocol model to the Windows security
    model.)

    I said "at least" because we also have the RDP file sharing component; I
    suppose one could consider that to have a server component as well.
    I've just never had much interaction with the server side component.

    If all you care about is SRV, then I would expect you would be satisfied
    with it's use of impersonation credentials along the lines you've
    described. If your concerns go beyond that, I would not be satisfied
    with the level of information I have seen about how security is
    implemented to make such assumptions.

    Tony
    OSR
  • Sarosh_HavewalaSarosh_Havewala Member Posts: 122
    RDR/SRV may collapse several opens from the same client to a single open
    on the server.

    However, SRV will issue a distinct IRP_MJ_CREATE for each client trying
    to access the file. This is required at minimum to guarantee cache
    consistency for remote access through the oplock mechanism offered by
    the local file systems.

    In W7, creates from SRV will be tagged by an ECP that identifies the IP
    of the client among other things. I am working on getting this into
    ntifs.h and into the MSDN docs. So expect to see this soon on MSDN
    online and in the W7 WDK.

    Regards,
    Sarosh.
    File System Filter Lead
    Microsoft Corp

    This posting is provided "AS IS" with no warranties, and confers no Rights


    xxxxx@yahoo.com wrote:
    > An excellent question.
    > From my [admittedly limited] testing so far, if client A and client B are different hosts, an IRP_MJ_CREATE is generated for each, even when the handles are the same (a symptom of Windows security, perhaps?). As I've only performed limited testing in this regard (AD auths on Win2k3), this may not always be the case. For scenarios where IRP_MJ_CREATEs are not generated, an FSD dispatch hook routine would never catch this in any case, regardless of any external login id mapping. Yes, it's true that an IRP_MJ_CREATE is needed in order to capture the Client/PrimaryToken of the caller.
    > The 'mapping' technique to be used for any solution relies on the fact that LSA generates unique LUIDs for every logon, remote and local, including multiple logons from the same user (SID). These are the same LUIDs as stored in Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary] -or- [Client]Token.
    > Once the FSD has captured the LUID, this can be 'looked-up' in LSA to find the assoicated logon session. It is this lookup mechanism that is being investigated (so far, a security pkg DLL is the front-runner for achieving this, as it holds both LUID and client data).
    > Any insight/advice into potential issues regarding Malcolm's question about 'missing' IRP_MJ_CREATES would be greatly appreciated.
    > Thanks!
    > - Peter
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Sarosh,

    Does the same thing apply for DAV and NFS vis-?-vis the ECP information in Win7?

    Tony
    OSR
  • Tracy_CampTracy_Camp Member - All Emails Posts: 82
    Any chance go getting this into a W2K8 SP?

    t.


    On Sat, 3 Jan 2009, Sarosh Havewala wrote:

    > RDR/SRV may collapse several opens from the same client to a single open
    > on the server.
    >
    > However, SRV will issue a distinct IRP_MJ_CREATE for each client trying to
    > access the file. This is required at minimum to guarantee cache consistency
    > for remote access through the oplock mechanism offered by the local file
    > systems.
    >
    > In W7, creates from SRV will be tagged by an ECP that identifies the IP of
    > the client among other things. I am working on getting this into ntifs.h and
    > into the MSDN docs. So expect to see this soon on MSDN online and in the W7
    > WDK.
    >
    > Regards,
    > Sarosh.
    > File System Filter Lead
    > Microsoft Corp
    >
    > This posting is provided "AS IS" with no warranties, and confers no Rights
    >
    >
    > xxxxx@yahoo.com wrote:
    >> An excellent question.
    >> From my [admittedly limited] testing so far, if client A and client B are
    >> different hosts, an IRP_MJ_CREATE is generated for each, even when the
    >> handles are the same (a symptom of Windows security, perhaps?). As I've
    >> only performed limited testing in this regard (AD auths on Win2k3), this
    >> may not always be the case. For scenarios where IRP_MJ_CREATEs are not
    >> generated, an FSD dispatch hook routine would never catch this in any case,
    >> regardless of any external login id mapping. Yes, it's true that an
    >> IRP_MJ_CREATE is needed in order to capture the Client/PrimaryToken of the
    >> caller.
    >> The 'mapping' technique to be used for any solution relies on the fact that
    >> LSA generates unique LUIDs for every logon, remote and local, including
    >> multiple logons from the same user (SID). These are the same LUIDs as
    >> stored in
    >> Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary]
    >> -or- [Client]Token.
    >> Once the FSD has captured the LUID, this can be 'looked-up' in LSA to find
    >> the assoicated logon session. It is this lookup mechanism that is being
    >> investigated (so far, a security pkg DLL is the front-runner for achieving
    >> this, as it holds both LUID and client data).
    >> Any insight/advice into potential issues regarding Malcolm's question about
    >> 'missing' IRP_MJ_CREATES would be greatly appreciated.
    >> Thanks!
    >> - Peter
    >>
    >>
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    > For our schedule debugging and file system seminars
    > (including our new fs mini-filter seminar) visit: http://www.osr.com/seminars
    >
    > You are currently subscribed to ntfsd as: xxxxx@openmars.com
    > To unsubscribe send a blank email to xxxxx@lists.osr.com
    >
  • Rick_WRick_W Member Posts: 126
    There is a way to get this information in some cases. It is fairly straightforward to get the SID from the security information when the file is opened. You can also query for the token source, which will tell you where the request came from (Lanman server, unix server, mac server, local system, etc.) Once you have the SID pass it to user mode and get the user name via WIN32 calls. If the request came from the lanman server you can query the sessions and with the right info level you get all the sessions for that user with the machine name(s). In most cases there will be only one entry and it will be the one you are looking for. If there is more than one then you need more information. There is an authentication token that is unique per session (you can get it at create time also). If you have code running on the client systems (in the current users context) you can ping them and have them connect to a named pipe that you manage in your user mode app. When you get the message you can impersonate the user and get the authentication ID and match it to the correct machine. Beware of creating a security breach though - do not have your client app just connect to any named pipe that it gets pinged with as a rouge app could fake this and impersonate the user and do bad things.

    I know this works for Windows clients, although remote sessions pose a problem in that you do not know which remote session it came from. It may also work for other clients if the server API's are available.

    This clearly does not work in all cases but depending on what you need it for it may be enough.
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    Note that the token source is just an arbitrary, unvalidated string and doesn't have any secured or validated meaning. Any code using that for a security decision is broken, as it could be faked by a non-admin user mode program calling LsaLogonUser directly (in Windows XP or later).

    - S

    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
    Sent: Monday, January 05, 2009 3:28 PM
    To: Windows File Systems Devs Interest List
    Subject: RE:[ntfsd] Retrieving remote file access details

    There is a way to get this information in some cases. It is fairly straightforward to get the SID from the security information when the file is opened. You can also query for the token source, which will tell you where the request came from (Lanman server, unix server, mac server, local system, etc.) Once you have the SID pass it to user mode and get the user name via WIN32 calls. If the request came from the lanman server you can query the sessions and with the right info level you get all the sessions for that user with the machine name(s). In most cases there will be only one entry and it will be the one you are looking for. If there is more than one then you need more information. There is an authentication token that is unique per session (you can get it at create time also). If you have code running on the client systems (in the current users context) you can ping them and have them connect to a named pipe that you manage in your user mode app. When you get the message you can impersonate the user and get the authentication ID and match it to the correct machine. Beware of creating a security breach though - do not have your client app just connect to any named pipe that it gets pinged with as a rouge app could fake this and impersonate the user and do bad things.

    I know this works for Windows clients, although remote sessions pose a problem in that you do not know which remote session it came from. It may also work for other clients if the server API's are available.

    This clearly does not work in all cases but depending on what you need it for it may be enough.

    ---
    NTFSD is sponsored by OSR

    For our schedule debugging and file system seminars
    (including our new fs mini-filter seminar) visit:
    http://www.osr.com/seminars

    You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ''
    To unsubscribe send a blank email to xxxxx@lists.osr.com
  • midimanmidiman Member Posts: 6
    Excellent and useful comments - many thanks to all for providing these useful insights.

    With regards using the token source - I've found that this value can vary hugely depending on the platform/client type, Kerberos vs NTLM etc. etc. It can give a hint into the client source, but it's really no more than a hint.
    Querying LSA sessions with the LUID (in user mode) is good for gathering the user name, but the client workstation is not included - at least, not in any documented structures that I could find (if anyone knows of any undocumented LSA structures that includes the machine name, please let us know!). Rick is correct that the client can be found in other places if there is only one login from a given user. When there's more than one, there's no (documented) way to tell which session maps to which address.
    This is where the SSPI AP DLL comes in handy. If the DLL implements the AuditLogin function, it will be called whenever a login takes place on the machine, and provides ID, user and importantly, machine details. This API is normally for custom login mechanisms (fingerprint/retina scanners, etc.), but it can be used for this purpose as well. The main caveat is that the DLL needs to be registered and loaded before the FSD starts sending data. If the app is a service, this is not generally a problem, unless you need to catch service logins from services that loaded before your own.
  • Sarosh_HavewalaSarosh_Havewala Member Posts: 122
    Yes - there will be a similar ECP for opens from the inbox NFS server.
    There is no such support for DAV.

    Regards,
    Sarosh.
    File System Filter Lead
    Microsoft Corp

    This posting is provided "AS IS" with no warranties, and confers no Rights


    Tony Mason wrote:
    > Sarosh,
    >
    > Does the same thing apply for DAV and NFS vis-à-vis the ECP information in Win7?
    >
    > Tony
    > OSR
    >
    >
    >
  • Sarosh_HavewalaSarosh_Havewala Member Posts: 122
    You would need to pursue this through your PSS contact. I see no reason
    this cannot be back ported to the platforms that support ECPs.

    Regards,
    Sarosh.
    File System Filter Lead
    Microsoft Corp

    This posting is provided "AS IS" with no warranties, and confers no Rights


    Tracy Camp wrote:
    > Any chance go getting this into a W2K8 SP?
    >
    > t.
    >
    >
    > On Sat, 3 Jan 2009, Sarosh Havewala wrote:
    >
    >> RDR/SRV may collapse several opens from the same client to a single
    >> open on the server.
    >>
    >> However, SRV will issue a distinct IRP_MJ_CREATE for each client
    >> trying to access the file. This is required at minimum to guarantee
    >> cache consistency for remote access through the oplock mechanism
    >> offered by the local file systems.
    >>
    >> In W7, creates from SRV will be tagged by an ECP that identifies the
    >> IP of the client among other things. I am working on getting this into
    >> ntifs.h and into the MSDN docs. So expect to see this soon on MSDN
    >> online and in the W7 WDK.
    >>
    >> Regards,
    >> Sarosh.
    >> File System Filter Lead
    >> Microsoft Corp
    >>
    >> This posting is provided "AS IS" with no warranties, and confers no
    >> Rights
    >>
    >>
    >> xxxxx@yahoo.com wrote:
    >>> An excellent question.
    >>> From my [admittedly limited] testing so far, if client A and client B
    >>> are different hosts, an IRP_MJ_CREATE is generated for each, even
    >>> when the handles are the same (a symptom of Windows security,
    >>> perhaps?). As I've only performed limited testing in this regard (AD
    >>> auths on Win2k3), this may not always be the case. For scenarios
    >>> where IRP_MJ_CREATEs are not generated, an FSD dispatch hook routine
    >>> would never catch this in any case, regardless of any external login
    >>> id mapping. Yes, it's true that an IRP_MJ_CREATE is needed in order
    >>> to capture the Client/PrimaryToken of the caller.
    >>> The 'mapping' technique to be used for any solution relies on the
    >>> fact that LSA generates unique LUIDs for every logon, remote and
    >>> local, including multiple logons from the same user (SID). These are
    >>> the same LUIDs as stored in
    >>> Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary]
    >>> -or- [Client]Token.
    >>> Once the FSD has captured the LUID, this can be 'looked-up' in LSA to
    >>> find the assoicated logon session. It is this lookup mechanism that
    >>> is being investigated (so far, a security pkg DLL is the front-runner
    >>> for achieving this, as it holds both LUID and client data).
    >>> Any insight/advice into potential issues regarding Malcolm's question
    >>> about 'missing' IRP_MJ_CREATES would be greatly appreciated.
    >>> Thanks!
    >>> - Peter
    >>>
    >>>
    >>
    >> ---
    >> NTFSD is sponsored by OSR
    >>
    >> For our schedule debugging and file system seminars
    >> (including our new fs mini-filter seminar) visit:
    >> http://www.osr.com/seminars
    >>
    >> You are currently subscribed to ntfsd as: xxxxx@openmars.com
    >> To unsubscribe send a blank email to xxxxx@lists.osr.com
    >>
    >
  • cyzcyz Member Posts: 1

    Hey, midiman

    I am working on a similar problem. Did you find the solution eventually? Thanks !!!!

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,151

    This thread is over 10 years old...Start a new thread with a new question.

    -scott
    OSR

This discussion has been closed.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA