Author : Rajesh Nath
Introduction
Plug-n-Play USB mass storage devices have become one of the biggest Information Security threats. USB Mass Storage Devices (MSD’s) can be used to carry out data in huge volumes that can prove vital for an organization’s data secrecy policy. USB Drives are small, cheap, easily available, easy-to-use and can carry huge data and thus can be used to take complete copies of original software or can prove threat to confidential documents.
Background
IT and ITES Organizations dealing with huge amounts of business-related sensitive data must take into account all proactive measures to defend inadvertent data leakage or deliberate data theft by employing end-point security solutions. We have poking around for sometime now, to look for concrete ways, to defend data leakage using USB thumb drives. We are presenting below a methodology to prevent the same in a Windows Domain based networked infrastructure of an organization.
The CORE Idea
The core idea is to secure data that is or can be sensitive for an organization. But alas! We can’t mark (or watermark) files that are sensitive and insensitive, since that would require a much more elaborate application with complete File System auditing capabilities. In turn we were looking for a simpler approach that can provide definite security. The idea we conceptualized, is to encrypt all the contents which is written from machine to a USB MSD and decrypt in vice-versa communication for a particular domain. This encryption/decryption is performed on the fly without any user intervention. One of the possible methodologies to achieve this task is to use a combination of User Mode NT Service and a Kernel Mode Filter Driver. We are presenting the core concept below with some pseudo code. Detailed implementation can be found in the attached source files. The main components of the project are:- 1) USB Controller NT Service: - This is a NT Service written in C++ with Win32 APIs. It is used for detecting the insertion of USB MSD into the machine. Furthermore, this service performs the functionality of checking whether valid domain user is logged into the machine or not. If yes, then only decryption of data is performed, otherwise not. 2) File System Filter Driver (FSFD):- This File system driver module handles the encryption and decryption of data read/write from/to USB MSD. The process of encryption and decryption is performed on the fly
Basic Control Flow
The basic control flow is explained in the below mentioned steps:- 1. Kernel mode FSFD is loaded at the time system boots up. 2. User Mode NT Service (nick named USB Controller) also gets started at the time of system start up. 3. Our service waits for any user to insert USB MSD into the machine. The FSFD waits for IOCTL’s from our NT Service so that it can perform desired operation (encryption/decryption). 4. As soon as an user inserts a USB MSD into the machine, USB Controller service detects the same and checks whether the user is a valid domain user or not. 5. If the user is a valid domain user, then USB Controller signals the FSFD to carry on with encryption/decryption of data that is written/read from the USB Drive. 6. If the user is not a valid domain user, then data written to the USB Drive is encrypted, but the data read from the drive is not decrypted and hence the data becomes obsolete for the user. NOTE: - The functionality achieved with this solution is that domain specific data would be available in a meaningful format for valid domain users. Invalid domain users would see the data as junk … since it would be encrypted for them. A strong encryption algorithm would mean stronger security which would be nearly impossible to break.
USBController NT Service
Why in a first place would a service be required? If someone asks me this question, then I would suggest that go …. get your Windows Basics correct first…. and then read this article. Well, Yes! An NT Service is an obvious choice for all security software since NT Services are the most reliable user more applications of Windows NT/2K/XP/Vista which provides more flexible start up options with running under admin privileges. USB Controller Service that I am presenting below runs under the SYSTEM account (which is the most privileged account under NT). This service is made Auto-start so that Windows starts this service at the time of Boot-up. Inside service_main function, we register for device notification using the RegisterDeviceNotification API. I have provided the Device Class GUID of USB Mass Storage Devices in the NotificationFilter.dbcc_classguid parameter so that I receive notifications of the devices that belong to this device class.
NotificationFilter.dbcc_size = sizeof(DEV_BROADCAST_DEVICEINTERFACE);
NotificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
NotificationFilter.dbcc_classguid = GUID_DEVINTERFACE_USBSTOR;
//NotificationFilter.dbcc_classguid = GUID_DEVINTERFACE_CDROM;
HDEVNOTIFY hDevNotify = RegisterDeviceNotification( sshStatusHandle,
&NotificationFilter,
DEVICE_NOTIFY_SERVICE_HANDLE);
For more details of RegisterDeviceNotification, go through the API documentation on MSDN. (http://msdn2.microsoft.com/en-us/library/aa363431.aspx) Whenever Windows detects any USB MSD insertion, it calls the HandlerEx function of our service with SERVICE_CONTROL_DEVICEEVENT event. In our case the HandlerEx function is service_ctrl(). Also, Windows supplies the type of Event received (DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE or other) with a pointer to a buffer which contains the device specific information. As soon as a Device Arrival Event is received, we enumerate the logged-in users and check whether they are valid domain users. This functionality is achieved by the help of LsaEnumerateLogonSessions and LsaGetLogonSessionData APIs. LsaEnumerateLogonSessions enumerates the Logon sessions that are currently active on that machine. In addition to the active directory user logon session, this API also provides the information of local machine authentication information for NT AUTHORITY domain and NTLM domain. Here, the catch is to use the information pertaining to our need only and discard the rest.
PLUID sessions;
ULONG count;
retVal = LsaEnumerateLogonSessions(&count,&sessions);
For more information on LsaEnumerateLogonSessions, refer to its MSDN documentation (http://msdn2.microsoft.com/en-us/library/aa378275.aspx). LsaGetLogonSessionData gets the information for each of the logon sessions enumerated using LsaEnumerateLogonSessions API. This information contains the domain name and the Authentication Package that was used to authenticate the user. Furthermore, it contains the type of logon performed (such as interactive logon).
PSECURITY_LOGON_SESSION_DATA sessionData = NULL;
retval = LsaGetLogonSessionData (session, &sessionData);
For more information on LsaGetLogonSessionData, refer to its MSDN documentation (http://msdn2.microsoft.com/en-us/library/aa378290.aspx). If the user is a valid domain user, then we get the drive letter of the USB Drive and send this drive letter to our driver. The driver uses it for encryption/decryption. If the user is not a valid domain user then data read from USB is not decrypted, and the user sees the data as junk since it is encrypted. Although, the above mentioned API’s are documented for Windows Vista, but I have not tested them for Vista. KNOWN LIMITATIONS OF USBCONTROLLER:- 1. For Windows Vista or XP Fast User Switching enabled machines, additional logic has to be implemented to determine which logged on user inserted the USB. That is we have to determine, which logged-in user’s session is currently active among, say 4 user sessions. To know how to do it, kindly mail me. :D
USB File System Filter Driver
The data flow for a file system driver takes place through two distinct interfaces.They are: a) IRP dispatch routines: b) FastIo routines. Hence its obvious that a file system filter driver has to work by intercepting the following requests a) IRPs a.1)Read (Completion Routine) a.2)Write. b)FastIo b.1)FastIoRead b.2)FastIoWrite Intercepting IRPs: a)Read IRP:Occurs when reading from the disk.We decrypt the buffer contents here before sending it to the application.This operation is done in the completion routine of the read. b)Write IRP:Occurs when writing to the disk.We encrypt the buffer contents here before sending it to the disk.This operation is done in the write dispatch routine. Intercepting FastIos: a)FastIoRead:Occurs when the reading is taking place from the cache. We decrypt the buffer contents. b)FastIoWrite:Occurs when the writing is taking place to the Cache.We encrypt the buffer contents here. Other than these two interfaces,the OS may do some memory-mapped IO wherein certain portions of the data/image file is mapped in the memory space within the Os.Next time whenever that file is opened the request for that opening does not reach the file system filter driver and the OS sends the request to the VM manager asking it to extract the requisite data from the mapped portions in memory.
Known Limitations of the Filter Driver
1)There is a “non completed” IRP problem when trying to unload the file system filter driver.This prevents the driver from being stopped and unloaded cleanly. 2)Although all the possible paths ie IRPs,Fast IOs and memory-mapped IO has been dealt with,there still is a problem related to encryption/decryption of certain files like .xls files.
Download
Introduction
Plug-n-Play USB mass storage devices have become one of the biggest Information Security threats. USB Mass Storage Devices (MSD’s) can be used to carry out data in huge volumes that can prove vital for an organization’s data secrecy policy. USB Drives are small, cheap, easily available, easy-to-use and can carry huge data and thus can be used to take complete copies of original software or can prove threat to confidential documents.
Background
IT and ITES Organizations dealing with huge amounts of business-related sensitive data must take into account all proactive measures to defend inadvertent data leakage or deliberate data theft by employing end-point security solutions. We have poking around for sometime now, to look for concrete ways, to defend data leakage using USB thumb drives. We are presenting below a methodology to prevent the same in a Windows Domain based networked infrastructure of an organization.
The CORE Idea
The core idea is to secure data that is or can be sensitive for an organization. But alas! We can’t mark (or watermark) files that are sensitive and insensitive, since that would require a much more elaborate application with complete File System auditing capabilities. In turn we were looking for a simpler approach that can provide definite security. The idea we conceptualized, is to encrypt all the contents which is written from machine to a USB MSD and decrypt in vice-versa communication for a particular domain. This encryption/decryption is performed on the fly without any user intervention. One of the possible methodologies to achieve this task is to use a combination of User Mode NT Service and a Kernel Mode Filter Driver. We are presenting the core concept below with some pseudo code. Detailed implementation can be found in the attached source files. The main components of the project are:- 1) USB Controller NT Service: - This is a NT Service written in C++ with Win32 APIs. It is used for detecting the insertion of USB MSD into the machine. Furthermore, this service performs the functionality of checking whether valid domain user is logged into the machine or not. If yes, then only decryption of data is performed, otherwise not. 2) File System Filter Driver (FSFD):- This File system driver module handles the encryption and decryption of data read/write from/to USB MSD. The process of encryption and decryption is performed on the fly
Basic Control Flow
The basic control flow is explained in the below mentioned steps:- 1. Kernel mode FSFD is loaded at the time system boots up. 2. User Mode NT Service (nick named USB Controller) also gets started at the time of system start up. 3. Our service waits for any user to insert USB MSD into the machine. The FSFD waits for IOCTL’s from our NT Service so that it can perform desired operation (encryption/decryption). 4. As soon as an user inserts a USB MSD into the machine, USB Controller service detects the same and checks whether the user is a valid domain user or not. 5. If the user is a valid domain user, then USB Controller signals the FSFD to carry on with encryption/decryption of data that is written/read from the USB Drive. 6. If the user is not a valid domain user, then data written to the USB Drive is encrypted, but the data read from the drive is not decrypted and hence the data becomes obsolete for the user. NOTE: - The functionality achieved with this solution is that domain specific data would be available in a meaningful format for valid domain users. Invalid domain users would see the data as junk … since it would be encrypted for them. A strong encryption algorithm would mean stronger security which would be nearly impossible to break.
USBController NT Service
Why in a first place would a service be required? If someone asks me this question, then I would suggest that go …. get your Windows Basics correct first…. and then read this article. Well, Yes! An NT Service is an obvious choice for all security software since NT Services are the most reliable user more applications of Windows NT/2K/XP/Vista which provides more flexible start up options with running under admin privileges. USB Controller Service that I am presenting below runs under the SYSTEM account (which is the most privileged account under NT). This service is made Auto-start so that Windows starts this service at the time of Boot-up. Inside service_main function, we register for device notification using the RegisterDeviceNotification API. I have provided the Device Class GUID of USB Mass Storage Devices in the NotificationFilter.dbcc_classguid parameter so that I receive notifications of the devices that belong to this device class.
NotificationFilter.dbcc_size = sizeof(DEV_BROADCAST_DEVICEINTERFACE);
NotificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
NotificationFilter.dbcc_classguid = GUID_DEVINTERFACE_USBSTOR;
//NotificationFilter.dbcc_classguid = GUID_DEVINTERFACE_CDROM;
HDEVNOTIFY hDevNotify = RegisterDeviceNotification( sshStatusHandle,
&NotificationFilter,
DEVICE_NOTIFY_SERVICE_HANDLE);
For more details of RegisterDeviceNotification, go through the API documentation on MSDN. (http://msdn2.microsoft.com/en-us/library/aa363431.aspx) Whenever Windows detects any USB MSD insertion, it calls the HandlerEx function of our service with SERVICE_CONTROL_DEVICEEVENT event. In our case the HandlerEx function is service_ctrl(). Also, Windows supplies the type of Event received (DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE or other) with a pointer to a buffer which contains the device specific information. As soon as a Device Arrival Event is received, we enumerate the logged-in users and check whether they are valid domain users. This functionality is achieved by the help of LsaEnumerateLogonSessions and LsaGetLogonSessionData APIs. LsaEnumerateLogonSessions enumerates the Logon sessions that are currently active on that machine. In addition to the active directory user logon session, this API also provides the information of local machine authentication information for NT AUTHORITY domain and NTLM domain. Here, the catch is to use the information pertaining to our need only and discard the rest.
PLUID sessions;
ULONG count;
retVal = LsaEnumerateLogonSessions(&count,&sessions);
For more information on LsaEnumerateLogonSessions, refer to its MSDN documentation (http://msdn2.microsoft.com/en-us/library/aa378275.aspx). LsaGetLogonSessionData gets the information for each of the logon sessions enumerated using LsaEnumerateLogonSessions API. This information contains the domain name and the Authentication Package that was used to authenticate the user. Furthermore, it contains the type of logon performed (such as interactive logon).
PSECURITY_LOGON_SESSION_DATA sessionData = NULL;
retval = LsaGetLogonSessionData (session, &sessionData);
For more information on LsaGetLogonSessionData, refer to its MSDN documentation (http://msdn2.microsoft.com/en-us/library/aa378290.aspx). If the user is a valid domain user, then we get the drive letter of the USB Drive and send this drive letter to our driver. The driver uses it for encryption/decryption. If the user is not a valid domain user then data read from USB is not decrypted, and the user sees the data as junk since it is encrypted. Although, the above mentioned API’s are documented for Windows Vista, but I have not tested them for Vista. KNOWN LIMITATIONS OF USBCONTROLLER:- 1. For Windows Vista or XP Fast User Switching enabled machines, additional logic has to be implemented to determine which logged on user inserted the USB. That is we have to determine, which logged-in user’s session is currently active among, say 4 user sessions. To know how to do it, kindly mail me. :D
USB File System Filter Driver
The data flow for a file system driver takes place through two distinct interfaces.They are: a) IRP dispatch routines: b) FastIo routines. Hence its obvious that a file system filter driver has to work by intercepting the following requests a) IRPs a.1)Read (Completion Routine) a.2)Write. b)FastIo b.1)FastIoRead b.2)FastIoWrite Intercepting IRPs: a)Read IRP:Occurs when reading from the disk.We decrypt the buffer contents here before sending it to the application.This operation is done in the completion routine of the read. b)Write IRP:Occurs when writing to the disk.We encrypt the buffer contents here before sending it to the disk.This operation is done in the write dispatch routine. Intercepting FastIos: a)FastIoRead:Occurs when the reading is taking place from the cache. We decrypt the buffer contents. b)FastIoWrite:Occurs when the writing is taking place to the Cache.We encrypt the buffer contents here. Other than these two interfaces,the OS may do some memory-mapped IO wherein certain portions of the data/image file is mapped in the memory space within the Os.Next time whenever that file is opened the request for that opening does not reach the file system filter driver and the OS sends the request to the VM manager asking it to extract the requisite data from the mapped portions in memory.
Known Limitations of the Filter Driver
1)There is a “non completed” IRP problem when trying to unload the file system filter driver.This prevents the driver from being stopped and unloaded cleanly. 2)Although all the possible paths ie IRPs,Fast IOs and memory-mapped IO has been dealt with,there still is a problem related to encryption/decryption of certain files like .xls files.
Download
4607
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
