It's been quite a long time since our last update so let me show you what has been going on these last weeks.
Inguma 0.5
After the last Bokken release we have focused on Inguma 0.5 development and now I'm going to show you some of the new features we have been working on.
We've done some GUI improvements in order to make it simpler, cleaner and to integrate the last Bokken release:
Look at the new main button that integrates all the common tasks and the simplified toolbar. Also the right panel has been improved by adding expand/collapse buttons as well as filter buttons by Target OS.
The Vulnerabilities panel has gained in eye candyness and functionality with the expand/collapse buttons or the "Open with Bokken" menu option.
Most of the work for this release has been focused on the Terminals tab, which has been redesigned and greatly improved.
As you can see, it now features many buttons to manage terminals and its contents as well as a filesystem panel that integrates perfectly with terminals and the rest of the GUI. From here you can import and load host lists, nmap scans, Inguma modules... and more.
Finally, the new feature that joins all the new changes is what we have called Listeners. By creating listeners you can now connect with your compromised targets and go ahead with post-explotation. :) Let's see how it works.
In order to listen for reverse connections, or directly connect to a exploited target, simply create a local or remote listener on the toolbar popup.
You will see the newly created listener in the right panel, under Listeners tab, as well as its status: connected or listening. From here you can disconnect or destroy them using the menu.
Once you have connection with a compromised target you will be able to interact with it on the Terminals tab, but this is still WIP :)
Of course Bokken has been updated to the latest release on the Reversing tab.
RootedCon 2012
On March 1st, 2nd and 3rd the RootedCon security event was held in Madrid and one of our developers, Hugo Teso, was there to talk about Inguma, Bokken and how to use it in security research.
The talk, entitled Inguma 0.5 RedWagon, exposed the ability of Inguma and Bokken to study the security of an uncommon system, in this case Unmanned Aerial Vehicles (UAS), both amateur and comercial ones. For this purpose a special edition of Inguma was coded, featuring UAV Command and Control software, with more protocols added to the network fuzzers among others.
The UAV C&C is an integrated WASP Ground Control Station, modified to be able to handle different UAV Autopilots (AP), from configuration and compilation to run and control:
Within the C&C tab many APs can be configured and run, either in SITL or HITL, such as ArduPilot Mega, Paparazzi or WASP. After using the Fuzzers to find vulnerabilities, either the Networking or the C&C tabs can be used to exploit a vulnerable UAV, depending if the vulnerability affects the GCS or the UAV directly.
In order to reverse-engineer the vulnerable AutoPilot or Ground Control Station, Bokken with Radare2 core was used, so the whole process of vulnerability finding, development and exploiting has been done with Inguma and Bokken :)
As you can see, the lack of news doesn't mean lack of activity as we have been really busy :) Stay tuned for more updates and upcoming releases!
7 comments:
Inguma 0.5 is nice. I wish you could discuss more about it soon. My Arizona SEO team mates appreciates everything you have shared. Keep blogging!
So is the special version of inguma available? I am just starting to try and formulate a formalized repeatable test plan for the Ardupilot 3.x+ code and I would like to include your tool as one of the recommended test tools for autopilots..
Hello, witnessdigital. Thank you for including our tool in your recommendations!
The development of Inguma Red Wagon (that's the name of the branch with the airplanes code) has been done off-line to allow having code potentially dangerous be developed for the proofs of concept that Hugo has been using for the talks. So there's some responsible disclosure involved as well as a potential license issue to be cleared up.
I don't know exactly the extent of the changes that we will finally publish, but we have been talking about this internally, and we would like to push to the public mercurial as much as we can. Please ping us again in a month or so as we should have a pretty good idea or even a code drop of this version.
Thanks again for your patience.
Hi Ender,
have you seen the latest from http://samy.pl/skyjack/... . Other scenarios of course use say an active jammer on the 2.4Ghz RC/control link.. or say a 433 RC link jammer to direct control and telemetry to an at present vulnerable control channel ,the present comms have quite a large attack surface..
and the other thing is while I have the ability and hardware/software to encrypt my links(I actually use a gumstix overo as a mission/vpn processor(and considering moving to a navstic for my autopilot from pixhawk. navstic direcly interfaces ..)
Other do not and if you have been on dirdrones.com things move very slowly for mavlink and the 3dr radios(this issue has been jawed to death and the fields needs the shock of samy et al(and soon to be metasploit) in the UAV/UAS security arena. Inguma-red-wagon presents some interesting possibility as a research tool but only if it is available for researchers to work with and prove to developers that they are living in glass houses on the security/integrity of these protocols.
Ie I am presenting using RFCat and a HackRF board will be arriving soon to help along with 3dr boards in 915 and 433 MHZ to facilitate this study.
Hi Ender,
my worries are that Openpilot/Ardupilot/NAZA/MAVLINK based systems which have not undergone ANY sort of security testing are being used to control increasingly larger craft such as full sized boats and in one case a kitfox airplane. That and the fact the code is NOT secure against even trivial attacks makes me extremely nervous.. sort of like the whole P25 radio encryption being able to be jammed by a 30.00 girls toys here in the US.
I think for a first proof of concept for the vulnerabilities I am aiming at is to create "evil" versions of the 3DR radio software.. at a minimum a scanner/monitor mode that would allow one to scan for in progress mavlink transmissions, and of course various attack and attack assist modes. Its relatively cheap to attack this radio and its embedded protocol(ie 3-4 radio boards in each frequency, a jtag debug/programming adapter for same(38.00 or so).. and the results given the numbers of ground stations and autopilots using same should be worthwhile, if only to force the hand to a more secure radio/protocol, vendors/programmers/users wont move until they are forced to which in this case means some fairly weighty objects descending at 9.8m2/s(kitfoxes etc). So I think this research is fairly important.
Post a Comment