Fighting advanced malware using machine learning (Japanese)FFRI, Inc.
n this paper, behavioral-based detection powered by machine learning is introduced. As the result, detection ratio is dramatically improved by comparison with traditional detection.
Needless to say that malware detection is getting harder today. Everybody knows signature-based detection reaches its limit, so that most anti-virus vendors use heuristic, behavioral and reputation-based detections altogether. About targeted attack, basically attackers use undetectable malware, so that reputation-based detection doesn't work well because it needs other victims beforehand. And it is a fact that detection ratio is not enough though we use heuristic and behavioral-based detections. In our research using the Metascan, average detection ratio of newest malware by most anti-virus scanner is about 30 %( the best is about 60 %).
By the way, heuristic and behavioral-based detections are developed by knowledge and experience of malware analyst. For example, most analysts know that following features are indicator that those programs are malicious.
- A file imports VirtualAlloc, VirtualProtect and LoadLibrary only and has a strange section name
- An entry point that does not fall within declared text or code section
- Creating remote threads into a legitimate process like explore.exe
- After unpacking, calling OpenMutex and CreateMutex to avoid multiple infections
- Register itself to auto start extension points like services and registry
- Creating a .bat file and try to delete own itself through executing the file with cmd.exe
- Setting global hook to capture keystroke using SetWindowsHookEx
Heuristic and behavioral-based detections are developed based on those pre-determined features like above. Analysts are finding those features day by day. But, this kind of work is not appropriate for human. Therefore we classified programs as malware or benign by machine learning through dynamic analysis results. Thereby, detection ratio is dramatically improved and we could recognize that which features are strongly related to malware by numeric score. And then, we could find the features which we’ve never found by this method. Finally, the outlook and challenges of this method will be tackled.
Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARMFFRI, Inc.
In 2017, Microsoft announced the ARM version of Windows. The number of devices with ARM version of Windows is increasing, such as Surface Pro X series and HP ENVY x2, and it is gradually becoming popular.
When using these ARM devices, there is a compatibility issue that existing x86/x64 applications cannot be used.
However, this problem has been addressed by providing x86/x64 emulation capabilities. In recent years, ARM64EC has been announced, allowing for the gradual migration of x64 applications to ARM. The aggressive introduction of these compatibility technologies is a sign of Microsoft's strong will to promote the ARM version of Windows.
On the other hand, doesn't the introduction of new compatibility technologies provide a new avenue of attack for attackers? As far as we know, this point has not even been discussed much at this point. Therefore, we reverse engineered the compatibility technology that exists in Windows on ARM and examined its exploitability.
We found that various techniques are available, such as code injection by modifying XTA cache files, and obfuscation by exploiting newly introduced relocation entries. All of these techniques have in common the characteristic that the binary "appearance" and runtime behavior are different, making them difficult to detect and track. In addition, some of the techniques can be widely exploited to interfere with static analysis or sandbox analysis. Therefore, there is a high possibility that they will become a threat to the ARM version of Windows in the future.
In this presentation, we will explain the details of our new method and its features with demonstrations. We hope that this presentation will be a good opportunity to develop and promote the security research of Windows on ARM.
The PoC code and detailed reverse engineering results will be available on GitHub.
Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARMFFRI, Inc.
In 2017, Microsoft announced the ARM version of Windows. The number of devices with ARM version of Windows is increasing, such as Surface Pro X series and HP ENVY x2, and it is gradually becoming popular.
When using these ARM devices, there is a compatibility issue that existing x86/x64 applications cannot be used.
However, this problem has been addressed by providing x86/x64 emulation capabilities. In recent years, ARM64EC has been announced, allowing for the gradual migration of x64 applications to ARM. The aggressive introduction of these compatibility technologies is a sign of Microsoft's strong will to promote the ARM version of Windows.
On the other hand, doesn't the introduction of new compatibility technologies provide a new avenue of attack for attackers? As far as we know, this point has not even been discussed much at this point. Therefore, we reverse engineered the compatibility technology that exists in Windows on ARM and examined its exploitability.
We found that various techniques are available, such as code injection by modifying XTA cache files, and obfuscation by exploiting newly introduced relocation entries. All of these techniques have in common the characteristic that the binary "appearance" and runtime behavior are different, making them difficult to detect and track. In addition, some of the techniques can be widely exploited to interfere with static analysis or sandbox analysis. Therefore, there is a high possibility that they will become a threat to the ARM version of Windows in the future.
In this presentation, we will explain the details of our new method and its features with demonstrations. We hope that this presentation will be a good opportunity to develop and promote the security research of Windows on ARM.
The PoC code and detailed reverse engineering results will be available on GitHub.
Fighting advanced malware using machine learning (Japanese)FFRI, Inc.
n this paper, behavioral-based detection powered by machine learning is introduced. As the result, detection ratio is dramatically improved by comparison with traditional detection.
Needless to say that malware detection is getting harder today. Everybody knows signature-based detection reaches its limit, so that most anti-virus vendors use heuristic, behavioral and reputation-based detections altogether. About targeted attack, basically attackers use undetectable malware, so that reputation-based detection doesn't work well because it needs other victims beforehand. And it is a fact that detection ratio is not enough though we use heuristic and behavioral-based detections. In our research using the Metascan, average detection ratio of newest malware by most anti-virus scanner is about 30 %( the best is about 60 %).
By the way, heuristic and behavioral-based detections are developed by knowledge and experience of malware analyst. For example, most analysts know that following features are indicator that those programs are malicious.
- A file imports VirtualAlloc, VirtualProtect and LoadLibrary only and has a strange section name
- An entry point that does not fall within declared text or code section
- Creating remote threads into a legitimate process like explore.exe
- After unpacking, calling OpenMutex and CreateMutex to avoid multiple infections
- Register itself to auto start extension points like services and registry
- Creating a .bat file and try to delete own itself through executing the file with cmd.exe
- Setting global hook to capture keystroke using SetWindowsHookEx
Heuristic and behavioral-based detections are developed based on those pre-determined features like above. Analysts are finding those features day by day. But, this kind of work is not appropriate for human. Therefore we classified programs as malware or benign by machine learning through dynamic analysis results. Thereby, detection ratio is dramatically improved and we could recognize that which features are strongly related to malware by numeric score. And then, we could find the features which we’ve never found by this method. Finally, the outlook and challenges of this method will be tackled.
Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARMFFRI, Inc.
In 2017, Microsoft announced the ARM version of Windows. The number of devices with ARM version of Windows is increasing, such as Surface Pro X series and HP ENVY x2, and it is gradually becoming popular.
When using these ARM devices, there is a compatibility issue that existing x86/x64 applications cannot be used.
However, this problem has been addressed by providing x86/x64 emulation capabilities. In recent years, ARM64EC has been announced, allowing for the gradual migration of x64 applications to ARM. The aggressive introduction of these compatibility technologies is a sign of Microsoft's strong will to promote the ARM version of Windows.
On the other hand, doesn't the introduction of new compatibility technologies provide a new avenue of attack for attackers? As far as we know, this point has not even been discussed much at this point. Therefore, we reverse engineered the compatibility technology that exists in Windows on ARM and examined its exploitability.
We found that various techniques are available, such as code injection by modifying XTA cache files, and obfuscation by exploiting newly introduced relocation entries. All of these techniques have in common the characteristic that the binary "appearance" and runtime behavior are different, making them difficult to detect and track. In addition, some of the techniques can be widely exploited to interfere with static analysis or sandbox analysis. Therefore, there is a high possibility that they will become a threat to the ARM version of Windows in the future.
In this presentation, we will explain the details of our new method and its features with demonstrations. We hope that this presentation will be a good opportunity to develop and promote the security research of Windows on ARM.
The PoC code and detailed reverse engineering results will be available on GitHub.
Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARMFFRI, Inc.
In 2017, Microsoft announced the ARM version of Windows. The number of devices with ARM version of Windows is increasing, such as Surface Pro X series and HP ENVY x2, and it is gradually becoming popular.
When using these ARM devices, there is a compatibility issue that existing x86/x64 applications cannot be used.
However, this problem has been addressed by providing x86/x64 emulation capabilities. In recent years, ARM64EC has been announced, allowing for the gradual migration of x64 applications to ARM. The aggressive introduction of these compatibility technologies is a sign of Microsoft's strong will to promote the ARM version of Windows.
On the other hand, doesn't the introduction of new compatibility technologies provide a new avenue of attack for attackers? As far as we know, this point has not even been discussed much at this point. Therefore, we reverse engineered the compatibility technology that exists in Windows on ARM and examined its exploitability.
We found that various techniques are available, such as code injection by modifying XTA cache files, and obfuscation by exploiting newly introduced relocation entries. All of these techniques have in common the characteristic that the binary "appearance" and runtime behavior are different, making them difficult to detect and track. In addition, some of the techniques can be widely exploited to interfere with static analysis or sandbox analysis. Therefore, there is a high possibility that they will become a threat to the ARM version of Windows in the future.
In this presentation, we will explain the details of our new method and its features with demonstrations. We hope that this presentation will be a good opportunity to develop and promote the security research of Windows on ARM.
The PoC code and detailed reverse engineering results will be available on GitHub.
TrustZone use case and trend (FFRI Monthly Research Mar 2017) FFRI, Inc.
Table of Contents
• About TrustZone
– Use case of TrustZone
– Cortex-A TrustZone
– Cortex-M TrustZone
– TEE implementation
• Vulnerability of TEE implementation
• Conclusions
• References
Android Things Security Research in Developer Preview 2 (FFRI Monthly Researc...FFRI, Inc.
Table of Contents
• Background • Use case and Weave
• Android Things Security Considerations
• Android Things Version Information
• File system information • Firewall setting
• ADB port setting
• SELinux setting
• Conclusions
• Reference
An Overview of the Android Things Security (FFRI Monthly Research Jan 2017) FFRI, Inc.
• Security incidents related to IoT devices
• About the Android Things
• Major features
• Installation and Settings
• Accessible network service
• Security configurations
• Conclusions
• References
Black Hat Europe 2016 Survey Report (FFRI Monthly Research Dec 2016) FFRI, Inc.
• About Black Hat
• Intriguing reports – Breaking BHAD: Abusing Belkin Home Automation Devices – (PEN)TESTING VEHICLES WITH CANTOOLZ YACHT – YET ANOTHER CAR HACKING TOOL – Mobile Espionage in the Wild: Pegasus and Nation-State Level Attacks
• Conclusions
• References
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)FFRI, Inc.
• About threat analysis support tool
• Examples of tools
• Analysis target system
• Analysis result
– How to read result
– Overview of threats
• Effective usage
– About template
– Additional definition of threat information
• Conclusions
• References
Black Hat USA 2016 Survey Report (FFRI Monthly Research 2016.8)FFRI, Inc.
• About Black Hat USA
• Hot Research
• Vehicle
– CANSPY: A Platform For Auditing CAN Devices
– Advanced CAN Injection Techniques For Vehicle Networks
– Can You Trust Autonomous Vehicles: Contactless Attacks against Sensors of Self-driving Vehicle
• IoT
– Into The Core – In-Depth Exploration of Windows 10 IoT Core
– GATTAttacking Bluetooth Smart Devices
– Introducing A New BLE Proxy Tool
– GreatFET: Making GoodFET Great Again
• Conclusions
• References
Black Hat Asia 2016 Survey Report (FFRI Monthly Research 2016.4)FFRI, Inc.
The document summarizes key presentations from Black Hat Asia 2016 on mobile, IoT, and Windows security. It discusses research on detecting Android commercial spyware, demonstrating iOS malware techniques on non-jailbroken phones, mapping vulnerabilities in wireless IoT devices, hacking a professional drone via MITM attacks, and a novel Windows DSC attack framework to persistently infect systems. The document provides context and the researcher's comments on each presentation.
ARMv8-M TrustZone: A New Security Feature for Embedded Systems (FFRI Monthly ...FFRI, Inc.
In this slide, we introduce the TrustZone of information that has published at this time in relation to ARMv8-M.
It is possible to separate/isolate the security level by adding the security state.
ARMv8-M architecture has a different mechanism than TrustZone to provide traditional ARMv8-A architecture, which is optimized for embedded systems.
CODE BLUE 2015 Report (FFRI Monthly Research 2015.11)FFRI, Inc.
•CODE BLUE 2015 had over 600 visitors from many countries.
–It had started two track presentation and youth track.
–Two teenagers and a student were on stage.
•IoT Security
–Medical equipment and social infrastructure were studied.
–The white hackers reported these vulnerabilities.
•Bug Bounty
–Japanese bug hunters are active in the world.
–There are things to learn from their way.
•APT
–APT would have invaded various organizations in Japan.
–Forum for information exchange, such as the CODE BLUE is required to counter APT.
Latest Security Reports of Automobile and Vulnerability Assessment by CVSS v3...FFRI, Inc.
•Automobile security is hot topic in many conferences.
•Cyber security measures are essential for the automobile.
•We summarize the following topics based on the above background.
–Presentations at the conferences other than Black Hat USA 2015 and DEF CON 23.
–Introduction of vulnerability assessment methods of automobile security by CVSS v3.
Black Hat USA 2015 Survey Report (FFRI Monthly Research 201508)FFRI, Inc.
This document summarizes security research presented at the Black Hat USA 2015 conference. Several talks demonstrated remote attacks against vehicles, including exploiting vulnerabilities in Chrysler Jeeps and Tesla Model S vehicles. Other research targeted IoT devices, like hacking a Linux-powered rifle and exploiting vulnerabilities in ZigBee wireless protocols. Additional briefings covered mobile and malware attacks, like exploiting the TrustZone security architecture on Android and using return-oriented programming for antivirus evasion. The document provides high-level overviews and comments on many of the featured talks from Black Hat USA 2015 and related conferences.
A Survey of Threats in OS X and iOS(FFRI Monthly Research 201507)FFRI, Inc.
This document provides an overview of threats to OS X and iOS. It summarizes recent malware cases like iWorm and WireLurker that infected devices through pirated software or sync functions. It also describes vulnerabilities like those allowing denial of service attacks or unauthorized access. The document outlines infection routes like drive-by downloads and recommends security settings for Macs and iPhones like installing updates, using passwords, and adjusting privacy and firewall settings.
Security of Windows 10 IoT Core(FFRI Monthly Research 201506)FFRI, Inc.
•Windows 10 IoT is successor platform of Windows Embedded that optimized for embedded devices.
•Windows 10 IoT Core Insider Preview has been provided for single-board computers such as the Raspberry Pi 2.
•We show tutorial about security of Windows 10 IoT Core using the Raspberry Pi 2.
Trend of Next-Gen In-Vehicle Network Standard and Current State of Security(F...FFRI, Inc.
Background
•Automobiles equip a lot of ECUs which communicate mutually on In-Vehicle Network to control engine, power window, and so on
•IVI devices such as navigation system and ADAS*known-as lane-keeping or brake-assist systems often are connected in the same network
•BecauseIn-Vehicle network becoming complicated by various devices, next-generation In-Vehicle network attracts interest as feasible technology at low cost
•This slide summarized about following topics
–Ethernet prospective as next-generation In-Vehicle network
–Recent security research about conventional In-Vehicle network andproposal of measures for the CAN
1. Fourteenforty Research Institute, Inc.
1
Fourteenforty Research Institute, Inc.
“FFR EXCALOC”
- コンパイラのセキュリティ機能に基づいたExploitabilityの数値化 -
Fourteenforty Research Institute, Inc.
株式会社 フォティーンフォティ技術研究所
http://www.fourteenforty.jp
シニアソフトウェアエンジニア
石山智祥
2. Fourteenforty Research Institute, Inc.
2
はじめに
• 最近のコンパイラには、セキュリティを強化する機能が追加されている
• しかし、市場に流通しているソフトウェアには、コンパイラのセキュリティ機能が利
用されていないケースが多い
• そのため、従来の手法でExploit可能となる脆弱性が多く発見されている
• 今回、実行ファイルを解析し適用されているセキュリティ機能を検出し、
Exploitabilityを数値化することに挑戦
3. Fourteenforty Research Institute, Inc.
3
Agenda
1. コンパイラ, OSの提供するセキュリティ機能と実装
2. Exploitability計算のための特徴パラメータ検出
3. FFR EXCALOCを用いたExploitabilityの数値化
4. 今後の課題
5. Fourteenforty Research Institute, Inc.
5
Visual C++ (2005以降)
• /GSオプション
• 最適化によるセキュリティを考慮したスタックレイアウト
- Canaryを使用したローカルバッファのオーバーフロー検出
- Visual Studio .NETでは回避方法が存在したが、2005で改良された
- ポインタ変数やポインタ引数をレジスタを使用するように最適化
- これにより、ポインタを経由したメモリ上へのデータ書き込みを防ぐ
6. Fourteenforty Research Institute, Inc.
6
Visual C++ /GS
• 関数リターン時に、Canaryが書き換えられているか確認し、オーバーフ
ローを検出
引数
リターンアドレス
Saved EBP
ローカル変数(int a, char c)
ローカルバッファ(char buf[])
引数
リターンアドレス
Saved EBP
Canary
ローカル変数(int a, char c)
ローカルバッファ(char buf[])
スタックの成長方向
ローカルバッファの書き込み方向
書き換え!
書き換え検出!
7. Fourteenforty Research Institute, Inc.
7
Visual C++ /GS
int vuln(char *arg)
{
char buf[128];
strcpy(buf, arg);
printf("buf = %s¥n", buf);
return 0;
}
Canary(cookie)を確認
Canary(cookie)を設定
8. Fourteenforty Research Institute, Inc.
8
Visual C++ 最適化によるStack Layout
• ローカルバッファの後ろに存在するローカルポインタをレジスタを使用し、
スタック上に領域を設けない
• ポインタを渡す引数をレジスタでの引数として渡す
引数(char *arg2)
引数(int arg1)
リターンアドレス
Saved EBP
ローカル変数(int a, char c)
ローカルポインタ(char *p)
ローカルバッファ(char buf[])
引数(int arg1)
リターンアドレス
Saved EBP
ローカル変数(int a, char c)
ローカルバッファ(char buf[])
スタックの成長方向
ローカルバッファの書き込み方向
9. Fourteenforty Research Institute, Inc.
9
Visual C++ 最適化によるStack Layout
void vuln(char *s, int l)
{
char *a;
char buf[32];
a = buf;
while (*s != '¥0') {
*a++ = *s++ + 1;
}
printf("buf = %s¥n", buf);
return ;
}
ローカル変数をレジスタで使用
ポインタ引数がレジスタ渡し
10. Fourteenforty Research Institute, Inc.
10
SSP (Stack Smashing Protector)
• スタックオーバーフローを検出し、任意コードの実行を抑制
- IBM 江藤氏が考案したProPolice(*1)の再実装
- GCC 4.1より正式に組み込まれている
- Canaryを使用したオーバーフローチェック
- Ideal Stack Layoutによるポインタ変数、ポインタ引数の保護
*1 http://www.trl.ibm.com/projects/security/ssp/main.html
11. Fourteenforty Research Institute, Inc.
11
SSP - Canary -
void vuln(char *s, int l)
{
int len;
char buf[32];
len = strlen(s);
printf("length = %d, %d¥n",
len, l);
strcpy(buf, s);
return ;
}
Canaryを確認
Canaryを設定
12. Fourteenforty Research Institute, Inc.
12
SSP - Ideal Stack Layout -
• ローカルバッファの後ろにローカルポインタが存在しないようにレイアウト
• ポインタを渡す引数は、一度ローカル変数にコピーしてから使用する
引数(char *arg2)
引数(int arg1)
リターンアドレス
Saved EBP
ローカル変数(int a, char c)
ローカルポインタ(char *p)
ローカルバッファ(char buf[])
引数(char* arg2) Not use
引数(int arg1)
リターンアドレス
Saved EBP
ローカル変数(int a, char c)
ローカルバッファ(char buf[])
ローカルポインタ(char *p)
コピーした引数(char *arg2)
スタックの成長方向
ローカルバッファの書き込み方向
13. Fourteenforty Research Institute, Inc.
13
SSP - Ideal Stack Layout -
void vuln(char *s, int l)
{
int len;
char buf[32];
len = strlen(s);
printf("length = %d, %d¥n",
len, l);
strcpy(buf, s);
return ;
}
引数arg_0をsrcに代入
14. Fourteenforty Research Institute, Inc.
14
SafeSEH
• 実行可能な例外ハンドラをあらかじめテーブルに設定しておくことで、例
外ハンドラを経由した任意コードの実行を防ぐ
- Windows XP SP2から実装
- 例外が発生した際に、KiUserExceptionDispatcher(ntdll.dll)内で、例外
ハンドラテーブルをチェック
- 例外ハンドラテーブルに含まれているハンドラであれば実行
15. Fourteenforty Research Institute, Inc.
15
例外ハンドラテーブル(SEHandlerTable)
• 実行ファイルのLOAD_CONFIGデータディレクトリに存在
LOAD_CONFIGデータディレクトリ
0x00 0x48(サイズ)
….
0x40 SEHandlerTableへのアドレス
0x44 SEHandlerCount(エントリ数)
SEHandlerTable
0x0000XXXX
….
….
….
17. Fourteenforty Research Institute, Inc.
17
Heap Management (Windows(HeapAlloc/HeapFree))
• Windowsの提供するHeap Manager
- HeapCreateを使用することで、Heap Managerを分けることが可能
- 実装はntdll.dll内のRtlAllocateHeap/RtlFreeHeap
- FreeListでDoubleLinkedListを使用
- Windows XP SP2以降では、バウンダリチェックやSafe Unlinkといった
セキュリティ機能が実装されている
18. Fourteenforty Research Institute, Inc.
18
Heap Management (Windows(HeapAlloc/HeapFree))
…
…
Segments[]
…
FreeList[]
…
HEAP
…
Signature(0xFFEEFFEE)
HEAPへのアドレス
…
FirstEntryへのアドレス
…
HEAP_SEGMENT
サイズ
前領域のサイズ
…
ユーザ使用領域
HEAP_ENTRY
19. Fourteenforty Research Institute, Inc.
19
Heap Management (Windows(HeapAlloc/HeapFree))
…
Signature(0xFFEEFFEE)
HEAPへのアドレス
…
FirstEntryへのアドレス
…
HEAP_SEGMENT
サイズ
前領域のサイズ
…
ユーザ使用領域
サイズ
前領域のサイズ
…
ユーザ使用領域
HEAP_ENTRY
28. Fourteenforty Research Institute, Inc.
28
Heap Management (Delphi (GetMem/FreeMem))
• Borland DelphiのGetMem, FreeMemにて使用するHeap Manager
- 要求サイズごとに確保されたメモリブロックから割り当てる
- 要求サイズごとに、メモリブロックの管理を行うHeap Headerが存在
- FreeListではSingle Linked Listを使用
- セキュリティ機能は実装されていない
29. Fourteenforty Research Institute, Inc.
29
Heap Management (Delphi (GetMem/FreeMem))
Heap Header[0]のオフセット
Heap Header[1]のオフセット
…
HeapHeader[0]
HeapHeader[1]
HeapHeader[2]
…
…要求サイズを元に、対応するオフセット
を取得
Heap Headerオフセットテーブル Heap Header
30. Fourteenforty Research Institute, Inc.
30
Heap Management (Delphi (GetMem/FreeMem))
要求サイズ
…
未使用領域のアドレス
Heap領域のアドレス
Heap領域のサイズ
…
HeapHeader[0]
HeapHeader[1]
HeapHeader[2]
…
…
HeapHeaderのアドレス
…
FreeList
確保数
ユーザ使用領域
未使用領域
HeapHeapHeader
31. Fourteenforty Research Institute, Inc.
31
Heap Management (Delphi (GetMem/FreeMem))
HeapHeaderのアドレス
…
FreeList
確保数
ユーザ使用領域
未使用領域
Heap
Heapの先頭アドレス
ユーザ使用領域
Heapの先頭アドレス
ユーザ使用領域
Heapの先頭アドレス
ユーザ使用領域
32. Fourteenforty Research Institute, Inc.
32
Heap Management (Delphi (GetMem/FreeMem))
HeapHeaderのアドレス
…
FreeList
確保数
ユーザ使用領域
未使用領域
Heap
FreeBlockへのアドレス
ユーザ使用領域
FreeBlockへのアドレス
ユーザ使用領域
0x00000000
ユーザ使用領域
33. Fourteenforty Research Institute, Inc.
33
Heap Management (Delphi (GetMem/FreeMem))
• GetMem実行時(FreeListから確保)
オフセットテーブルからHeapHeaderを取得
FreeListから確保メモリを取得
44. Fourteenforty Research Institute, Inc.
44
例外ハンドラの検出
• アセンブラコード上での例外ハンドラを使用している関数の特徴
- fs:0の読み込みと書き込みを行っている
- fs:0の値をスタックにPUSHしている
- fs:0をPUSHするひとつ前のPUSH命令のオペランドが例外ハンドラ
- コンパイラの種類や、最適化のオプションによっては例外ハンドラ設定
関数を使用している場合がある
45. Fourteenforty Research Institute, Inc.
45
例外ハンドラの検出
関数内で例外ハンドラの設定(VC)
fs:0の値を更新してリターン
例外ハンドラ設定関数(VC)
fs:0の値を更新してリターン
例外ハンドラ設定関数(BCC)
関数内で例外ハンドラの設定(Delphi)
fs:0をEAXに格納してからPUSH
fsのオフセット指定にレジスタを使用
46. Fourteenforty Research Institute, Inc.
46
Canaryの検出
• アセンブラコード上でのCanaryの特徴
- コンパイラによって実装が異なるが大きな流れは同じ
- 関数の最後のチェック処理は別関数の可能性がある
- コンパイラごとに検出処理を分ける必要もある
- 関数のはじめで、特定の値を設定している
- 関数の最後で、値のチェック処理を行っている
47. Fourteenforty Research Institute, Inc.
47
SafeSEHの検出
• SafeSEHが有効になっているバイナリファイルの特徴
- PEヘッダのDataDirectoryにLOAD_CONFIGディレクトリが存在する
- LOAD_CONFIGディレクトリのフォーマットが特定のフォーマットになって
いる
48. Fourteenforty Research Institute, Inc.
48
Heap Managerの検出
• 使用しているHeap Managerを検出
- 独自実装のHeap Managerを検出するのは困難
- Import Tableから使用しているAPIを列挙し、メモリ確保系のAPIの使用
頻度から利用しているHeap Managerを判断
49. Fourteenforty Research Institute, Inc.
49
使用しているコンパイラの検出
• DOSヘッダからPEヘッダへのオフセットの値
• DOSプログラムとして起動した際に実行されるコード
• これ以外にもいくつか検出方法が存在…
- DOSヘッダからPEヘッダのオフセットの値は、コンパイラによって異な
る。
- DOSヘッダからPEヘッダのオフセット値は、コンパイラが同じであれば
同じになる可能性が高い
- DOSプログラムとして起動した際に実行されるコードでは、コンパイラ
によって実行コードに違いがある
52. Fourteenforty Research Institute, Inc.
52
FFR EXCALOC
• 動作環境
• 開発環境
- IDA Pro Version 5.2 のプラグイン
- 対象フォーマットはPEファイル
- 現時点では、静的解析のみで特徴パラメータの抽出を行う
- Windows XP SP2
- Visual Studio 2008
53. Fourteenforty Research Institute, Inc.
53
特徴パラメータの検出
• PEファイル全体に影響するパラメータ
• 関数単位で影響するパラメータ
- 使用しているコンパイラ
- Heap Manager
- SafeSEHの有効/無効
- 適用されているセキュリティ機能
- 関数内のローカルバッファの検出
- 関数内のポインタの検出
- 関数内の例外ハンドラの検出
54. Fourteenforty Research Institute, Inc.
54
特徴パラメータの抽出例 (1)
Compiler Type Visual C++
Stack Protection /GS
Safe SEH あり
Heap Manager Windows Heap Manager
• ブラウザソフトI
アドレス サイズ 参照数 配列 ポインタ 例外ハンドラ
0x00401609 0x88 0x02 なし あり なし
0x00401887 0x14D 0x01 あり あり あり
0x00401DE4 0x2AB 0x01 あり あり なし
…
55. Fourteenforty Research Institute, Inc.
55
特徴パラメータの抽出例 (2)
Compiler Type Visual C++
Stack Protection なし
Safe SEH なし
Heap Manager なし
• グラフィックソフトH
アドレス サイズ 参照数 配列 ポインタ 例外ハンドラ
0x00401000 0xDC 0x01 あり なし あり
0x004010DC 0x08 0x01 なし なし なし
0x004010F0 0x59 0x01 なし なし あり
…
61. Fourteenforty Research Institute, Inc.
61
より正確なExploitabilityを計算するために…
• より正確な要素の検出
• 動的解析を併用したExploitabilityの計算
- 配列と構造体の区別
- 関数ポインタの検出
- …
- 対象アプリケーションをデバッガで起動させ、実行コードの流れから
Exploitability計算に必要な要素を検出する
• 関数のパラメータ
• ヒープバッファ
• …
62. Fourteenforty Research Institute, Inc.
62
ありがとうございました
Fourteenforty Research Institute, Inc.
株式会社 フォティーンフォティ技術研究所
http://www.fourteenforty.jp
シニアソフトウェアエンジニア
石山智祥 <ishiyama@fourteenforty.jp>