Code:
athcon.org | |
Athens, 3-4 May, 2012 | |
Day2, Track1, 14:00-14:50 | |
"Why rootkits suck", | |
twogunz | |
| |
"Why rootkits suck" | |
| |
Rootkit malfunctions usually reveal that the rootkit is present on the system | |
| |
Rootkit overview | |
remote access | |
intercept data | |
etc | |
transforms the computer in a zombie | |
| |
Rootkits vs Botnets | |
share some common characteristics | |
but are not the same | |
| |
userland vs kernel-land rootkits | |
userland | |
binary replacing | |
binary injecting (detectable by tripwire) | |
process injecting | |
poor means to disguise the presence of the attacker | |
poor means to survive reboot | |
poor means to hide remote connections | |
kernel-land | |
need to interfere with binaries only during the booting phase | |
can provide extensive means for hiding and remote access | |
hard to detect | |
comple (compile? complete?) | |
| |
How do rootkits work | |
replace files on the system with backdoored versions | |
ring zero rootkits hijack function handler pointer in mem to alter normal behaviour | |
| |
Anti rootkits | |
rootkits make visible changes to the system | |
userland rootkits will alter timestamps, dir struct file size | |
kernel land rootkits alter system functions | |
most kernel rootkits focus on the syscall table | |
rootkits need to add files to the filessystem, need to add processes, open ports, etc. | |
anti rootkit tools, rkhunter, chkrootkit, etc. | |
signature scanning does not detect newer versions of rootkits unless they are updated | |
heuristics (didn't get the presenter point) | |
| |
Traditional rootkit detection | |
signature scanning vs integrity checks | |
signature scanning fails for the slightest change in the file structure of the rootkit | |
major fallback of integrity check anti-rootkits is that is relies on know to be sane system state - which makes sense | |
| |
Examples - traditional rootkit detection | |
Shown example: rkhunter - Adore rootkit | |
Shown example: rkhunter - suckit rootkit | |
Shown: Phalanax | |
It is clearly seen that it is easy to go undetected if a filename or directory structure changes | |
| |
chkrootkit uses grep-approach | |
| |
Traditional vs Heuristic Detection | |
Heuristic | |
detects signs of rootkit activity, not the rootkit files themselves | |
Soon available as online service | |
| |
So how are rootkits found | |
They hijack the predictable places | |
| |
Remote access | |
Suspicious signs of crypto inside the network (if there is encrypted traffic over a plain-text protocol) | |
| |
Surviving the reboot | |
need to insert persistent triggers in system files | |
the triggers can be found by analyzing these files (eg.: /etc/rc/init.d) | |
| |
The problem of complex code in Linux Kernel | |
Many changes in 2.6 branch | |
| |
Code quality in rootkit | |
same code does not work on different kernel subversions | |
insufficient testing of code | |
coded in a hurry | |
throwing together many functionalities without a plan | |
portable code vs stable code, but portable code is not necessary stable | |
| |
Rootkit exploits | |
They come with vulnerable code because of hurry development, insufficient testing | |
from buffer overflows to pure logic flaws | |
taking over rootkits in memory using exploits in rootkit itself (phalanx case) | |
magic user ID approach | |
rootkit writers consider that only remote access to shell of rootkit requires authentication, thus local connect to backdoor authentication is either poorly implemented or inexistent | |
a good method is to start PID_MAX - PID_PROCESS_NUMVER and if something fails, something is suspicious there | |
| |
Phalanx exploit - MAGIC_UID flaw | |
haxorgid variable of type gid_t | |
limits GID space 64k | |
bruteforce of GID is easy and see which one drops us to hacker shell | |
after a few little hacks we are in | |
example Phal-hack | |
| |
Compromising the rootkit | |
Full access to rootkit files | |
Recovering hackers password | |
Learn what hackers know about you | |
Learn hacking techniques | |
Important: possibly get a brand new 0day unknown to public | |
| |
Model of a winning rootkit | |
Describes how a perfect rootkit would look like | |
Kernel code is used as a framework to launch and manage userland code | |
good code testing | |
several different hooking techniques to make sure there is always a fallback scenario | |
Ideally, subliminal channel tcp/ip backdoor | |
Timed backdoor programmed to start at certain hours | |
Have several "survive the reboot" techniques | |
Nothing really has to be written to the disk |
Code:
athcon.org | |
Athens, 3-4 May, 2012 | |
Day2, Track1, 11:00-11:50 | |
"Smart Meter PLC - Communication Security worth 0.37 EUR", | |
Stefan Riegler & Johannes Greil | |
| |
"Smart Meter PLC - Communication Security worth 0.37 EUR", | |
| |
EEPROM Contents | |
48bit unique neuron id | |
Spoofing chip id | |
Use EEPROM_LOCK? | |
chip id is at address F000 | |
| |
PL3150 | |
PL 3120 and PL 3150 Power Line Smart Transceivers | |
Memory map - external boot ROM | |
write own neuron boot ROM | |
ignores read/write protects | |
| |
USB PLC Network Interface (U20) (PL20) | |
http://store.echelon.com/item.asp?PID=48 | |
A-band | |
C-band (consumer) | |
| |
Bands | |
CENELEC EN50065-1 | |
C-band consumer | |
HVAC | |
Automation | |
home network | |
| |
A-band utilities | |
reserved for power utilities | |
| |
PL20U (C-Band) vs PL20A (A-Band) | |
The crystal/oscillator | |
A-Band - 10 packets/sec, clock ~ 6Mhz | |
C-Band - 15 packets/sec, clock 10 Mhz | |
| |
U20 USB adapter | |
UID = 0x0920 | |
PID = 0x7500 | |
| |
Toolkit | |
perl p20-usb lonworks sniffer | |
plugin to the wireshark | |
| |
Oscillator soldering + perl kit = gets you transceiver for the A-Band | |
| |
Demo kit | |
Hardware | |
1 sniffer device | |
2 development kit, also support the chip | |
1 of the dev boards is a 3150 with the external boot-rom connected | |
The boards have custom devices with exchange some packets when pressed the power button | |
| |
Software | |
Echelon LonScanner FX Protocol Analyzer | |
| |
The demo | |
Demonstrated the use of the Echelon LonScanner proprietary software | |
Then it demonstrated the packets in the wireshark (saw just the serial unique id broadcast by the device) | |
Then started the perl p20 software in tandem with the wireshark showing packets flowing between the devices | |
| |
Other findings | |
communication channels besides PLC (GPRS, WiFi) | |
etc | |
| |
Further Attacks | |
Currently just the sniffer is implemented | |
Currently No crypto, or authentication attack implemented | |
| |
TODOs | |
cryptanalysis of used encryption | |
sniff/jam communication | |
dumping the firmware memory of dc/meter (external boot ROM) | |
spoofing of the chip id | |
rewrite chip ip through external boot ROM | |
attack the p2p network protocol/design | |
| |
Security implications | |
Disconnect homes (breaker unit) | |
Manipulation | |
Fraud (most likely from my point of view) | |
Privacy implications | |
| |
Conclusions | |
Still a lot of work to be done, it's just scratching the surface | |
Seems like a prospective avenue (especially in the fraud direction) | |
Security through obscurity does not work |
Code:
athcon.org | |
Athens, 3-4 May, 2012 | |
Day1, Track1, 18:00-18:50 | |
"0-Day - Comodo did it again" | |
Glafkos Chralambous & George Nicolaou | |
| |
0-Day - Comodo did it again | |
| |
Comodo Internet Security Home Intrusion Prevention System | |
| |
Disclosure timeline | |
bottom line, they hung up the phone while waiting for their director | |
| |
Comodo techniques | |
hook Nt* and Zw* functions for | |
file access | |
memory access | |
network access | |
registry access | |
placed the hooks on the "wrong" side (what does this exactly mean?) | |
| |
How? | |
inject a pyaload to install hooks in critical user mode functions in ntdll.dll | |
load a library guard.dll which installs the hooks | |
in win 7 64bit: replaces the first instr of the program's EP with a JMP <payload> | |
in other OS: replaces ZwTestAlert first instruction with JMP <payload> | |
| |
0day | |
There is TLS (Thread Local Storage) | |
We can use the TLS to uninstall JMP <payload> when the main thread is created | |
see _IMAGE_TLS_DIRECTORY32 structure | |
AddressOfIndex | |
AddressOfCallBacks; // PIMAGE_TLS_CALLBACK * - this is an interesting array | |
| |
Process of exploitation | |
Create a malicious executable | |
find somewhere to insert IMAGE_TLS_DIRECTORY and code to uninstall the JMP <payload> instruction (and insert it) | |
Point a TLS callback function to the code | |
| |
That’s not all | |
The <payload> address is constant address throughout all installations of the COMODO HIPS in ALL Windows OS | |
Add resource 71B00000 | |
And it contains executable code | |
Game over ASLR - can be used for ROP techniques from any other vulnerable application on the victim machine |
Code:
athcon.org | |
Athens, 3-4 May, 2012 | |
Day1, Track1, 17:30-17:50 | |
"Exploitation Toolkit Codename: Icarus" First Part, | |
Glafkos Chralambous & George Nicolaou | |
| |
"Exploitation Toolkit Codename: Icarus" First Part, | |
| |
Finding vulnerability | |
| |
Protocol analyzer (fuzzing or reverse engineering) | |
SPIEE | |
peach | |
General Purpose Fuzzer GPF | |
Sulley | |
Fuzzing is more effective when used in combination with binary analysis | |
| |
Binary analysis | |
Inspector (HB Gary) | |
SecurityReview (Veracode) | |
BugScan (IDA Plugin by Halvar Flake) | |
| |
Vulnerability testing | |
RATS | |
CodSecure | |
?? | |
| |
Reports | |
Crash reports | |
| |
| |
Exploit development | |
Vulnerability classification | |
Exploitability analysis | |
Design exploit skeleton | |
calculate the location in buffer | |
calculate where to close or open injection parameters | |
| |
Skeleton Implementation ANALYSIS | |
Constraints and barriers imposed on the exploit payload | |
Examples: | |
ASLR | |
Space limitations | |
Restricted characters | |
Character escape functions | |
| |
Exploit Generation | |
Generate the initial trigger payload | |
Building ROP technique | |
Encode the web-payload to bypass web-filter | |
Calculate offsets (for ASLR for example) | |
| |
Payload Generation | |
Payload generation | |
Bind shell | |
command execution | |
signed shellcode | |
eggshell | |
Payload "ninjification" | |
To evade the protection technique | |
Signature-based | |
Anomaly-based | |
Integrity checks | |
Code obfuscation | |
Code metamorphism | |
Optional technique | |
Tools: BH2009 ABCodeMutate | |
Payload normalizations | |
Ninjification can alter the code that it requires "normalization" | |
| |
Metasploit | |
Covers only a part of the proposed methodology of ICARUS | |
| |
ICARUS | |
Cover all the steps ("check all boxes") in the methodology | |
Targets multi-platforms (Intel IA32, Intel 64, ARM) | |
Windows/Linux/Other_OS Libraries | |
Input language interfaces: python, C#, etc. | |
Reporting and generating outputs in various formats | |
Reasons not to develop over metsploit the missing parts: | |
metasploit is more a database of exploits | |
icarus wants to be more than this, and not a database of exploits | |
metasploit is slow, runs as ruby/plugin | |
| |
| |
Have classes/interfaces: | |
encoders, elf parser, gen hex pattern, parsers, instruction, instr finder, instr obfuscator, windows aslr, windows dep, | |
| |
Code is about 5-6 k lines of code as of now |
UPDATE: His slides are announced here.
Code:
athcon.org | |
Athens, 3-4 May, 2012 | |
Day1, Track1, 15:00-15:50 | |
"Venue into my work uncovering and exploiting zero days vulnerabilities and advanced fuzzing techniques", | |
Nikolaos Rangos (Kingcope) | |
| |
"Venue into my work uncovering and exploiting zero days vulnerabilities and advanced fuzzing techniques", | |
| |
Very pragmatic and german-style rigorous lecture | |
| |
A very packed presentation of the current state of the art, tools and techniques for vulnerability finding/testing and exploit generation/testing | |
| |
Contained lots of illustrated and commented of examples from real-world 0days (mostly Linux and ProFTP) | |
| |
Need to get the recording and slides/whitepaper since it was a very packed presentation |
Code:
athcon.org | |
Athens, 3-4 May, 2012 | |
Day1, Track1, 12:00-12:50 | |
"Packing Heat!", | |
Dimitris Glynos | |
| |
METASM | |
Very interesting framework | |
in Ruby | |
| |
(lost the rest of the review) |
UPDATE: subscribe to postscript-sec@andreicostin.com mailing list for notifications and planned tools & PoC releases.
Securely yours,
Andrei
UPDATE: subscribe to postscript-sec@andreicostin.com mailing list for notifications and planned tools & PoC releases.
You can download my HITB2012AMS presentation here.
Also, thanks to authors of the below overview posts on my presentation:
You can also check the HITB2012AMS materials.
Securely yours,
Andrei
A deep dive into brain's curiosities
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| << < | Current | > >> | ||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |