Cognitive and Scientific Brainology

Security - consulting,assessment,research,solutions,penetration tests.
Face - detect,track,recognize,extract features,learn emotions,character animation.

Category: AthCon

AthCon3 2012 Day2, Track1, 18:00-18:50 "Advances in BeEF: RESTful API, WebSockets, XssRays enhancements"

09/19/12 | by zveriu | Categories: Conference, AthCon, Write-up

Download here.

Code:

	`athcon.org`
	`Athens, 3-4 May, 2012`
	`Day2, Track1, 18:00-18:50`
	`"Advances in BeEF: RESTful API, WebSockets, XssRays enhancements",`
	`Michele Orru`

	`"Advances in BeEF: RESTful API, WebSockets, XssRays enhancements"`

	`BeEF`

	`Demo Using the BeEF restuful api`
	`1. beef programatically accessing metasploit`
	`2. injects beef into some victim browser`
	`3. inject an applet, then use the javascript to java communication to ge tthe hava version based on the hdk`
	`4. then in meterpreter sysinfo to get the system info`
	`5. then inject the "execute calc.exe" in the victim's machien thru the injjected java applet`

	`New additions`
	`ajax calls posioning (xml request object is overriding)`
	`the module can have the target+_blank not to lose the victim`
	`getting the Persistence (history) from the civtim vrowsaer`

	`New feature (in a testing branch - to be added soon)`
	`websocket support`
	`currently beef uses XHR, but for speed needs websocket`

	`XHR in beef`
	`pro - works everywhere (ie, chrome)`
	`cons - (TODO)`

	`if beef.browser.hasWebSocket(), don't use XHR pollin, open a websocket channel`
	`support: firefox, chrome, safari, also mozwebsocket`
	`https://github.com/radoen/beef-radoen - the experimental phase`

	`Possibilities with WS`
	`real time VNC like hooked browser control`
	`faster tunneling proxy (fuzzin thru the hooked browser 4-5 times faster)`
	`general faster communication`


	`Demo - BeEF with WS`
	`launch 1000 XHR-polling vs WS-based request`

	`XssRays`
	`originally as pure JS-based XSS scanner, then integarted in beef`

	`xssrays operation`
	`a page with links/forms which do get/post request intra or cross domain`
	`it adds the hidden iframe for each of the requests`
	`if the iframe is loading, then the resource was XSS-vulnerable`
	`it also works CROSS-DOMAINS (respecting the SOP!)`

Leave a comment •

AthCon3 2012 - Overview

07/01/12 | by zveriu | Categories: Conference, AthCon, Write-up

AthCon3 (2012) was a pleasant surprise - Kris and Kyp and their crew did a great job putting it all together so nicely!

It was a very technical, 1-track 2-day conference in Athens, or better said in a very nice green&quiet country club right outside of Athens.

I have been surprised also by the following facts:

the audience was mostly young professionals
the number of attendees was pretty impressive for a hacker/security scene which is not much advertising itself
the audience definitely featured a pool of both raw and polished talent which could be a gold mine for headhunters

Leave a comment •

AthCon3 2012 Day1, Track1, 14:00-14:50 "PostScript: Danger Ahead"

06/15/12 | by zveriu | Categories: Conference, AthCon, Write-up

UPDATE: subscribe to postscript-sec@andreicostin.com mailing list for notifications and planned tools & PoC releases.

You can download the presentation here.

Securely yours,
Andrei

Leave a comment •

AthCon3 2012 Day2, Track1, 14:00-14:50 "Why rootkits suck"

06/11/12 | by zveriu | Categories: Conference, AthCon, Write-up

Download here.

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

Leave a comment •

AthCon3 2012 Day2, Track1, 11:00-11:50 "Smart Meter PLC - Communication Security worth 0.37 EUR"

06/11/12 | by zveriu | Categories: Conference, AthCon, Write-up

Download here.

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`

Leave a comment •

:: Next Page >>

HIRE! - My Resume

Contact

Upcoming talks

PHDays
Hack In Paris
BlackHat USA