a security barrier device that can protect critical data regardless of os or applications by just...
DESCRIPTION
A Security Barrier Device protects PC and other control devices by relaying every port between the motherboard and the peripherals. The SBD is totally transparent from the PC and can be installed regardless of OS or application. At this presentation I will discuss the storage securing function achieved by the SBD relaying the SATA port. The SBD has a security information disk only accessible to itself where it stores the access privilege information of the original disk in the PC. When the PC issues a data access request to the original disk, the SBD will reference the access privileges of that particular sector, if the sector is read-deny then returns dummy data of 0 , if the sector is write-deny then it won’t write to that sector. The SBD not only allows for sector based protection but also a file based protection. In case of a file write-deny, there were some issues with the disc related cache in memory not being synchronised or the pointer’s position to the file in regards to its directory being shifted , but I will show how it was solved. I will also talk about the fact that a SBD is an effective protection against any malware that attempts to manipulate the boot data sector or system files, once it detects any access right violations it can shutdown the ethernet port remotely and thwart the spreading of malware. Kenji Toda At the National Institute of Advanced Industrial Science and Technology conducted research and development of 30 Gbps intrusion detection systems , 60 Gbps URL filtering systems and or network devices testing equipment for such systems. Currently co-developing security barrier devices with the Research and Development Control System Security Center. (Presented at international conferences regarding MST and real-time systems) http://codeblue.jp/en-speaker.html#KenjiTodaTRANSCRIPT
Security Barrier Device Protects Critical Data Regardless of OS
and Applications by Just Attached
Kenji TODA, Ichiro EBIHARA, Koji SEGAWA, Koichi TAKAHASHI and Kazukuni KOBARA
The National Institute of Advanced Industrial
Science and Technology (AIST) in cooperation with
Control System Security Center (CSSC)
Contents
• Background • Concept of SBD • Data Protection Mechanism • Hardware and Security Tag • Sector Based Access Control • File Based Access Control • Malware Prevention • Demonstration Video • Future Work
Currently NTFS is implemented. EXT and FAT are under development.
Applicable for other file systems.
2
Background: PC and/or Server
• Hard to fix all the vulnerabilities of complex OS and applications.
• There exists undefended period called zero-day exposing unknown or discovered-but-not-yet-fixed vulnerabilities.
#Identified Vulnerabilities in a year
(http://www.symantec.com/ja/jp/threatreport/topic.jsp?id=vulnerability_trends&aid= total_number_of_vulnerabilities) 3
Background: Control System
• Additional security software is not affordable for restricted hardware resources and / or realtime systems
• Outdated OS and applications might be used without any security patch.
We develop SBD, the hardware solution of easy attachable regardless of any OS and applications without software installation.
4
SBD – Easy Attaching
Target System
Just insert SBD between IO Ports on the original hardware.
Protecting important data regardless of OS and applications. 5
SBD: Data Protection Mechanism
①The target system issues an IO request to the original HDD.
②SBD reads the security information of corresponding IO blocks.
③Data access is handled according to the information (permitted / inhibited / queried) .
① ②
Added HDD: Security Information ←Invisible from the System!
Original HDD: Data
RW=10
③ Read〇 Write×
6
ＳＢＤ: Full View
Security Barrier Device FPGA board developed for SBD
7
Security Barrier Device (SBD): Board and Specifications
• Board size: PCI Express card (230mm x 110mm) • FPGA chip： Xilinx Kintex-7 676pin XC7K325T • Configuration Flush Rom: for power-on-write to FPGA • Memory I/F: DDR3 SODIMM×1 • Display input: HDMI×1 • Display output: HDMI×1 • Optical audio: input×1, output×１ • Storage I/F： SATA (7pin)×5 • Ethernet I/F： 1G/100Mbit Ether (RJ-45) ×2 • USB I/F： USB (Type A)×6 (USB2.0) • SBD host PC I/F： PCI Express×1 8
SBD Board Connections
SBD Control PC
SBD Board
Target Control Device
USB0
Ethernet (LAN)
HDMI
SATA0
PCIe(card slot)
SATA1
USB1
SATA0
SATA1
USB0
USB1
HDMI
Ethernet (LAN)
Peripherals of Target Control Device
9
Security Barrier Device (SBD): Security Tags (sector based control)
Security Barrier Device (SBD)
Additional Storage for SBD Security
Target Control Device
User Login to SBD
SBD PASSWORD FILE
USER NAME
PASSWORD(root)
UID0
GID
SBD Control PC(Linux kernel 2.6 or above)
SBD Board
OWNER GROUP OTHER
RqraWqra RqraWqra RqraWqraRqraWqra
UID GID
Original Storage of Target Control Device
SBD SECURITY TAGs for corresponding BLOCK
BLOCK
Original Data in Target Storage
USER NAME
PASSWORDUID1
GID
Storage Access Storage Access
Additional Storage Access
Loop Back
...
LoopBack / AccessControl:{Query - assert / negate},
{Recording - all / no},{Alert - no}
SBD SECURITY MODEfor storage access
(R: read, W: write, q: query, r: record, a: alert)
USB
USB
HDMI
SATA
PCIe
UID
SBD DEFAULT UID & GID
Ethernet
Loop Back
GID
• SATA Port Handling Logic is implemented.
• Ethernet can be cut-off. 10
Security Barrier Device (SBD): Sector Based Access Control
The target of storage access control is block devices such as HDD / SSD / USB memory.
Since storage access is performed sector based (512Byte unit),
implementation of sector based access control is straightforward.
• Defense of disk regions and partitions is OK! • Gathering to-be-write-protected data and system files
to write-protected partitions. • Gathering to-be-read-protected data to read-protected
partitions. 11
SBD: File Based Access Control Motivation
File based access control extends defense coverage and improves convenience dramatically: • Critical system and user data is mostly files. • No need to gather important files to protected partitions • Original data disk can be protected as is. • Easy assigning and releasing of protection on files. • No stress on attaching and detaching of SBD (just plug
in/out IO connectors).
12
SBD: File Based Access Control Requirements
Commonly-used file systems: • NTFS (Windows, …） • EXT(Linux, Android, …） • FAT(old Windows, MS-DOS, VxWorks, USB memory,..） • HFS+(Mac OS X,…) Requirements to handle the above file systems: • On access control of data blocks, →〇 sector based control is appropriate; →〇 read access control is appropriate; →×write access control is NOT appropriate because pointers to the data blocks may change their locations.
In non-resident data file and parent directories 13
SBD: File Based Access Control Fine Grain Control
Protection is required on data of file and path from the root.
Access granularity for directories and pointer areas ≦ sector size (512B)
1. Put access control granularity to the security information
corresponding to a sector. 2. In case of write to a sector, in addition to the security
information, the content of the sector is also read. Then the write protected portion of the read data is used instead of the sector data intended to write. Consequently, fine grain control is achieved.
14
Security Barrier Device (SBD): File Read Protection (no difficulty)
In case SBD returns zeroes for read protected data: An error message on opening protected data on a target system (Ubuntu) →
15
SBD: Requirement for Write Protection -- EXT2（Linux）
• /appdata/app_critical is a write protected file. Path from the root directory needs protection. 16
SBD: File Based Access Control Remaining Difficulties
Problems of write protection on NTFS file: ① Inconsistency between disk-relating caches on the memory of a
defense target system and the disk may destroy file system and cause OS crash.
② The locations of pointer entries relating the write protected file in its parent directories may change by addition or deletion of other non-protected files. Because, the location is rearranged by balanced tree algorithm in NFTS. (←SBD achieves high performance by means of FPGA circuit assuming fixed location.)
17
SBD: File Based Access Control Disk-Relating OS Caches
[Problems] Linux (also Windows) utilizes following caches for performance:
• Superblock (block group descriptor, bitmaps of free block and free i-node, …)
• i-node cache • Directory entry cache • Buffer cache (for disk block data) • Page cache (for file data)
Write inhibition on the disk causes inconsistency between OS caches and the disk!
18
SBD: File Based Access Control Solution
Problems of write protection on NTFS file: ① Inconsistency between disk-relating caches on the memory of a
defense target system and a data disk may destroy file system and cause OS crash.
② The locations of pointer entries relating the write protected file in its parent directories may change by addition or deletion of other non-protected files. Because, the location is rearranged by balanced tree algorithm in NFTS. (←SBD achieves high performance by means of FPGA circuit assuming fixed location.)
By observing OS behavior using
SBD
→SBD makes the OS handle an accessed write-protected file entry as a (pseudo) bad block by returning a disk access error to the OS!
→The pointer location to its patent directory is never changed as long as its directory pass is not changed! 19
SBD: File Based Access Control Write Protection Procedure
Write protection on NFTS file: ① In case of write, if rename or deletion is performed to the write
protected file, the operation is done on caches and appears successful.
② In a short period, the contents of the caches are written to the disk, then SBD detects it.
③ SBD returns a device error on the file access and issues an alert to a user. OS handles the file entry as it is in a (pseudo) bad block.
(An Ethernet port can be shut-off by the alert as a trigger.)
① When a user reboots the OS, SBD restores the write protected files in prior to OS booting. Hence, the OS can be booted as it was.
SBD makes write protection consistent with the OS!
The pseudo bad blocks are restored from $BadClus file. 24
SBD: File Based Access Control Mechanism
Security Barrier Device (SBD)
Additional Storage for SBD Security
Target Control Device
User Login to SBD
SBD PASSWORD FILE
USER NAME
PASSWORD(root)
UID0
GID
SBD Control PC(Linux kernel 2.6 or above)
SBD Board
OWNER GROUP OTHER
RqraWqra RqraWqra RqraWqraRqraWqra
UID GID
Original Storage of Target Control Device
SBD SECURITY TAGs for corresponding BLOCK
BLOCK
Original Data in Target Storage
USER NAME
PASSWORDUID1
GID
Storage Access Storage Access
Additional Storage Access
Loop Back
...
LoopBack / AccessControl:{Query - assert / negate},
{Recording - all / no},{Alert - no}
SBD SECURITY MODEfor storage access
(R: read, W: write, q: query, r: record, a: alert)
USB
USB
HDMI
SATA
PCIe
UID
SBD DEFAULT UID & GID
Ethernet
Loop Back
GIDDetecting information is
prepared in prior to detection. File system Dependent
Detection is performed in fine grain, byte unit,
by FPGA. File system Independent
25
ＳＢＤ： Performance of Access Control
In case of fine grain, byte unit, detection (at high overhead sate) = File based access control (read / write) is enabled:
Experimentally 100MByte/s Measuring Condition： A original data disk and a security information disk: Samsung SSD 830, 128GB Benchmark Program: Read-Only Benchmark, Ubuntu Disk Utility
Sector-wide comparator with byte unit mask circuit + Multi-sector IO buffer circuit
26
Security Barrier Device (SBD): Malware Prevention
Protection by SBD： • Bootkit • Rootkit
27
28
Bootkit: Definition and Win32/Gapz
• The most dangerous infectious form bootkit launches before Windows and hides in between hardware and OS. Hence, it becomes undetectable and accesses system resources unlimitedly. 。(technet.microsoft.com)
• Win32/Gapz: Advanced Evasion Techniques VBR infection type replaces only a few bytes in BIOS Parameter Block. Hence, it is hard to detect. (Evolved form of MBR infection type） (blog.eset-smart-security.jp)
29
Bootkit Win32/Gapz MBR Infection type
• Fig shows the infection sequence of MBR infection type （Traditional Techniques） ① Bootkit code is loaded from disk,
Int 13h disk handler is hooked.
② ntldr, bootmgr, winload.exe and loInitSystem are hooked in series, kernel mode code (rootkit) is launched.
30
Bootkit Win32/Gapz VBR
Infection type
• VBR Infection Type disk image (Advanced techs)
① Hidden Sectors (4B) at
BIOS Parameter Block in Volume Boot Record is modified.
② Bootkit is launched instead of IPL by mean of skipping whole NTFS volume in front of bootkit
31
Bootkit: ELAM
• ELAM（Early Launch Anti-Malware Module）, introduced in Windows 8, does not work. (blog.eset-smart-security.jp)
32
Bootkit Win32/Gapz
• VBR Infection Type disk image (Advanced techs)
① Hidden Sectors (4B) at
BIOS Parameter Block in Volume Boot Record is modified.
② Bootkit is launched instead of IPL by mean of skipping whole NTFS volume before bootkit
③ The rest is the same as MBR Infection type.
SBD protectable!
34
Bootkit: Secure Boot • On the secure boot, UEFI (Unified Extensible Firmware
Interface) verifies boot loader in advance of its loading. In case the boot loader is modified or replaced (by bootkit), the secure boot prevents its execution. (technet.microsoft.com, blogs.msdn.com)
The boot loader code itself is not protected!
The boot loader is stored in a
file for verification!
35
Bootkit: Secure Boot • On the secure boot, UEFI (Unified Extensible Firmware
Interface) verifies boot loader in advance of its loading. In case the boot loader is modified or replaced (by bootkit), the secure boot prevents its execution. (technet.microsoft.com, blogs.msdn.com)
The boot loader code itself is not protected!
The boot loader is stored in a
file for verification! SBD protectable!
36
Rootkit: Definition and Sample
• Generic name of tool which invades and modifies computer
system with root (system manager) privilege (ASCII.jp)
• Typical rootkit hides Logon, Process, File and Log. It often monitors input from network and/or keyboard. In many cases, rootkit is also Trojan Horse. (Wikipedia)
• SONY BMG CD XCP case: It is audio player software with Copy Guard function, on the side, access control (permitting outgoing transmission and system invasion) using rootkit is installed. It transmits data on computer and also prevents other media player software from playing a music CD and/or copying to disk. Its vulnerability was found and abused by malware. （→Currently, Windows update has fixed it.） (Wikipedia)
System files are modified!
37
Rootkit: Definition and Sample
• Generic name of tool which invades and modifies computer
system with root (system manager) privilege (ASCII.jp)
• Typical rootkit hides Logon, Process, File and Log. It often monitors input from network and/or keyboard. In many cases, rootkit is also Trojan Horse. (Wikipedia)
• SONY BMG CD XCP case: It is audio player software with Copy Guard function, on the side, access control (permitting outgoing transmission and system invasion) using rootkit is installed. It transmits data on computer and also prevents other media player software from playing a music CD and/or copying to disk. Its vulnerability was found and abused by malware. （→Currently, Windows update has fixed it.） (Wikipedia)
System files are modified! SBD protectable!
SBD prevents write on boot area and shut-off Ethernet, and stops Remote Control.
Attacker
Victim Network is shut-off.
Defense by SBD
38
Future Work
• Feasibility study and its feedback to SBD at Control System Security Center (CSSC) • Linux EXT families and widely-used FAT families are under development.
(Applicable for other file systems also.) • Improvements on performance and robustness • Tests using various malware • Extension of SBD defense ability by developing
Ethernet, USB and HDMI port-supervisory circuit. • Downsizing (such as a SBD storage)
39
FIN
40