Monthly Archives: September 2016

Debunking fuel in the gas tank, case closed.

Picking up from yesterday’s post:

Imagine a time when carburetors ruled the earth (or at least car’s fuel systems), and a time before emissions controls extended to evaporating fuel vapor, say perhaps in the 70s when I began my career as a mechanic, working on cars of that era and older.  Back then, in ye olden days, fuel systems were open to the environment, both in cars and in the tanks at gas stations.  That meant that water vapor could condense in the fuel tanks and drip or run down the sides and pool at the bottom of the tanks.  This is why the fuel pickups in gas stations’ underground tanks were a few inches above the bottom, and why we always used water-detecting paste on the giant tank sticks used to measure the amount of fuel in the ground.  An inch or two of water at the bottom of the tank and no one cared as long as the amount didn’t increase rapidly- it would stay down there harmlessly.  Unless, of course, you got a fuel delivery which churned up everything on the bottom of the tanks, water, sediment, whatever.  Still, it would eventually settle back down- but if you happened fill up your car while the much was stirred up you could get the nasties, including water, into your car’s tank.  And no, most stations didn’t have great fuel filtration between the tank and the pumps.  To this day I avoid filling up my vehicles if I see a fuel truck in the gas station lot- I had to deal with too many dirty fuel systems to take the chance.  And even if you didn’t get water from a bad gas station fill up you could build up water from condensation on the roof of your fuel tank settling to the bottom.

Now we have a couple of paths to getting water into your car’s gas tank, where does that take the sugar myth?  It doesn’t take a lot of water to dissolve sugar that finds its way into the tank, especially given the constant vibration and sloshing that happens in a moving vehicle, so now we can move the sugar solution along with the gasoline towards the engine.  We still have a fuel filter to deal with, but they were generally simple paper filters designed to stop solids, not liquids, so our mix of gasoline and sugar water wouldn’t get stopped there.  This assumes that the vehicle has a fuel filter at all- which is not a safe assumption if you go far enough back in time, or if you happen to be dealing with someone who bypassed their fuel filter “because it kept clogging up”.  (If you think no one would ever do something that dumb, you have probably never worked a helpdesk).

And now the fuel hits the carburetor, where a little bowl acts as a reservoir for fuel before it finds its way into the intake system.  Carburetors are full of tiny orifices, the kind that don’t like dirt, or much of anything other than clean gasoline and clean air.  Sugar water can gum things up, block holes, or settle out into the bottom of the fuel bowl- and that’s where things are no longer theoretical.  I had to clean out a few carburetors with sticky goo in them in my “gas station mechanic” days, and I recall one where we dropped the gas tank and found an ugly mess in the tank.  Sugar in the tank could, under some circumstances, be annoying.  Not catastrophic but mildly disruptive, and a genuinely unpleasant thing to do to someone.

What’s the moral of the story?  I don’t think there is one, other than exaggeration and hyperbole feed urban legends whether they’re based on complete nonsense or a tiny grain of truth.

Bottom line, don’t put sugar in gas tanks.  Not just because it won’t work, but because it’s a rotten thing to do.

 

Jack

Debunked debunking, part 2

Another “debunked” automotive urban legend is the “Sugar in the gas tank will destroy your engine!!!11!” story.  Let’s take a look at this tale, and look at a few angles folks often miss when discussing it.  This myth has been thoroughly debunked, by people both smart and not-so-smart, but let’s look at it again.

First and foremost, sugar does not dissolve in gasoline.  You might be able to stir it into some kind of suspension, but it won’t really dissolve.  (Sugar doesn’t dissolve well in alcohol, either, but that’s a topic for my other blog.)  That would seem to thoroughly debunk the story by itself, and in modern vehicles in good condition it pretty much does.

Modern, good condition… I just opened two interesting views into one angle to the tale.

Second, modern (there’s that word again) vehicles have very thorough fuel filtering which will prevent sugar granules from making it anywhere near the engine.

And finally for this post, even if sugar did dissolve in gas (which it doesn’t) and sugar made it through the filter(s) (which it won’t), the sugared fuel would only flow through the fuel, intake, and exhaust systems.  I suppose it might make it into the lower parts of the engine if the pistons/rings/cylinder walls were junk but then the engine is already trashed.

Let’s talk about what could happen in the scenario above, assuming sugar did dissolve in gas and/or filtration didn’t stop it.  It is a safe bet that fuel injectors wouldn’t like it, they might gum up eventually as the sugar burned (caramelized?) due to engine heat.  I suppose, since we’re suspending disbelief, that sugar could build up on the valves and contribute to burned valves- but the operating temperatures of modern valves are extremely high and  since they’re designed to function at such temperatures that I doubt it would be a problem as the sugar would burn off without building up.  Continuing with the fantasy, maybe turbochargers and catalytic converters wouldn’t enjoy the sugar solution- but again the extreme heat would burn the sugar somewhere in the process and probably burn it cleanly with no significant ill effects.

So there we have it, thoroughly debunked.  Except maybe not.  What if we scale back the expected damage from catastrophic to annoying, and go back in time?  In the first post on debunking going back in time was also a key to understanding the battery myth.

The rest of this story comes tomorrow (really).

 

Jack

Evolution of Locky – A Cat & Mouse Game

1

In the on-going game of cat and mouse between cyber attackers and defensive internet security providers, the appearance of a new tactic from the Locky family of Ransomware comes as no surprise.

As we discussed in February this year, Locky targets victims through seemingly legitimate email attachments. Once the victim clicks on the attachment the malicious macro begins encrypting the users’ files.

Given the nature of this environment, security experts are constantly working on ways to stop Locky, coming up with solutions that will render it ineffective.

Distribution of the latest attack

In the latest development, cyber attackers have come up with new tactics to bypass security. The malware is still distributed via email attachments, but no longer uses a Trojan. These emails have varying names and subject lines to attract the victims’ attention and usually contain Zip files.

locky-2
The Malware skips the downloader Trojan and gets the Locky variant in DLL format, and is then executed using Windows rundll32.exe. By using a script file as well as a DLL, instead of a Trojan and .exe, Locky is not immediately detected and blocked, and the Ransomware can begin its course.

To further ensure its success cyber attackers have given Locky an added fall-back mechanism, this means that the malware will still be able to complete its actions even in cases where it can’t reach command and control servers. The weak point in this is that the encryption key is the same for every computer.

These attacks appear to present in weekly waves and have already targeted victims in North and South America, and Europe, as well as attacks in Africa and Asia.

3

In order to protect yourself, security experts suggest setting up filters for script files that arrive via email, as well as ensuring your antivirus is up to date. Advanced solutions such as Panda’s Adaptive Defence allow for active classification of every running application by leveraging Endpoint Detection & Response (EDR) technologies. This means that you have a greater chance of defending your network against today’s advanced threats.

The post Evolution of Locky – A Cat & Mouse Game appeared first on CyberSafety.co.za.

Fox stealer: another Pony Fork



Gift for SweetTail-Fox-mlp
 by Mad-N-Monstrous


Small data drop about another Pony fork : Fox stealer.
First sample of this malware I saw was at beginning of September 2016 thanks to Malc0de. After figuring out the panel name and to which advert it was tied we were referring to it as PonyForx.

Advert :
2016-08-11 - Sold underground by a user going with nickname "Cronbot"

--------
Стилер паролей и нетолько - Fox v1.0

Мы выпускаем продукт на продажу. Уже проходит финальная стадия тестирования данного продукта.

О продукте : 
1. Умеет все что умеет пони. + добавлен новый софт.
2. Актуален на 2016 год.
3. Написан на С++ без дополнительных библиотек.
4. Админка от пони.

Условия : 
1. Только аренда.
2. Распространяется в виде EXE и DLL.
3. Исходники продавать не будем.

Аренда 250$ в месяц.
Исходники 2000$ разово.

----Translated by Jack Urban : ----

Password stealer and more - Fox v.1.0
We are releasing the product for general sale. Final stage of testing for this product is already underway.
About the product:
1. Is able to do everything that pony does. + new software has been added.
2. Relevant for 2016.
3. Written in C++ without additional libraries.
4. Admin from pony.
Conditions:
1. For rent only.
2. Distributed as an EXE and DLL.
3. We will not be selling the source.
Rent is $250 a month.
Originals are a 2000$ one time fee. 

--------

It's being loaded (with Locky Affid 13) by the Godzilla from ScriptJS (aka AfraidGate) group .

MISP taxonomy tags reflecting ScriptJS activity in the last months
(note : it's not the first time this group is pushing a stealer, they were dropping Pony with their Necurs between August and December 2015 [1] )

2016-09-26 - ScriptJS infection chain into Neutrino into Godzilla loader into PonyForx and Locky Affid 13
Here we can see the browsing history of the VM being sent to PonyForx (Fox stealer) C2

Fox stealer (PonyForx) fingerprint in Cuckoo

Sample :
Associated C2:
blognetoo[.]com/find.php/hello
blognetoo[.]com/find.php/data
blognetoo[.]com|104.36.83.52
blognetoo[.]com|45.59.114.126
Caught by ET rule :
2821590 || ETPRO TROJAN Win32.Pony Variant Checkin

[1] ScriptJS's Pony :
master.districtpomade[.]com|188.166.54.203 - 2015-08-15 Pony C2 from ScriptJS
​js.travelany[.]com[.]ve|185.80.53.18 - 2015-12-10 Pony C2 from ScriptJS

Read More : 
http://pastebin.com/raw/uKLhTbLs few bits about ScriptJS

Security Weekly #467 – It’s Not About the Gin

This week we interview Jon Searles and Will Genovese, the founders of the NESIT hacker space and organizers of Bsides Connecticut.

Security Weekly Web Site: http://securityweekly.com Follow us on Twitter: @securityweekly

Full Show Notes: http://wiki.securityweekly.com/wiki/index.php/Episode467#Interview:_Jon_Searles_and_Will_Genovese_from_BSidesCT_and_NESIT

Untangling quantum entanglement

Symmetrical encryption is far quicker and less resource-intense than public/private key encryption, but has the downside that the symmetrical key needs to be distributed among parties. For this reason, we use public/private key encryption to secure the transfer of the symmetrical key, and then use symmetrical encryption to secure the actual data that needs to …

Internet of Broken Things: Threats are changing, so are we ?

Hi Folks, this is another blog-post on internet of "broken things". As many of you are familiar with MQTT is one of the most used protocol over the Internet of Things. It's widely used in private area network - to make communications quick and light - and on public network as well - to build communication channels between sensors end / or servers messages -

MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. t is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.

Inspired by Luca Lundgren talk on Defcon 24 titled: "Light Weight Protocol! Serious Equipment! Critical Implications!" I decided to verify myself the state of the art on MQTT implementations.

How MQTT works:


Understanding how MQTT protocol works, invented by Andy Stanford-Clark di IBM and Arlen Nipper Cirrus Link Solutions, is crucial to figure out why poorly authentication implementations will cause serious information disclosure issues.. MQTT stands for Message Queue Telemetry Transport and now is an OASIS standard. It has been designed for sending telemetry data and often runs the challenge against REST HTTP API in modern IoT environments. While is not a common protocol to build communication between clouds (and servers) since AMQP (Advanced Message Queuing Protocol) is much more expressive and performant it is often preferred to to build communication between small objects (things) to small objects (things). 

The protocol relays on a central node called "Broker" who is organised in specific programmable topics. Publishers (things) are able to publish informations to specific topics (such as but not limited to: temperature, localization, humidity, etc. ) while subscribers (applications) are able to get data from an interested and explicit topic. The following image represents a general architectural view. It's clear that a poorly implemented authentication mechanism will let the subscribers free to get the overall published data.

MQTT Architecture Flow
The beauty of unauthenticated MQTT sessions is in the subscriber topic list.  Indeed it is able to subscribe to every topic on the selected brokers by simply putting an # as topic even if it does not know the topics list.


Simple Experiment:

Let assume we might find some unauthenticated MQTT brokers, what kind of message could be identified ? Hopefully not sensible data. Let's see it !

Step 1: Discovery.
masscan even if not  assiduously upgraded is still one of my best solution to map Internet. I performed a simple massive scan in order to figure out servers with open ports on 1883 (it's the default MQTT broker port). I know... if a server owns a 1883 open port does not mean it runs a MQTT broker on it.. I totally agree but my point is not a quantitative analysis but a quality analysis, so I do not care about how many real MQTT brokers are out there but if I can find sensible data on one of them. 

sudo bin/masscan 0.0.0.0/0 --exclude 255.255.255.255 -p1883 --max-rate 10000 -oX mas1883.xml 

After few hours thousands of ip populate my "mas1883.xml" file


Step 2: Identification.
Assuming we get thousands of valid IPs running MQTT brokers we need to try to subscribe to all of them and try to subscribe to every topic. Let's write a quick'n dirty 20 lines of code to make it happens. 

Quick'n dirty script automation subscriptions (click to enlarge) 
Step 3: Results Analysis
After few running hours, I've got back interesting results (they were piped into different files from the launch bash script, so simple I did not even mentioned it). In order to describe the results I'd like to classify them into two simple sections: Note sensible data and Sensible data.

Not sensible data. MQTT messages that does not refer directly to sensible information but still interesting from attackers such as: Temperature,  Presence,  Lights sensors and commercial. If those informations get to malicious physical attacker's hands he can figure out if when to physically attack the building since it is easy to detect human presence. The following image shows  records belonging to Presence Sensors (PIR), Power Sensors, Humidity Sensors, Temperature Sensors and Noise Sensors.


Anonymised Not Sensible Data (click to enlarge)
For example an attacker could use those data to understand if in a room -- of such anonymised building -- are people in there (thanks to the value of the PIR sensor) or if someone is close to the room (thanks to noise sensors) or if somebody has been in the room (thanks to delta temperature sensors). Those informations are useful to plan an attack. So even these informations are not sensible per se it is still important to protect them. 

Another great example comes from an unauthenticated server hosting Samsung Smartthings devices.

Samsung Smartthings devices data (click to enlarge)
As you might see (enlarging the previous image.. :) we can totally monitor the "building". We know where sensors have been placed (network_cabinet, master_bedroom, parkers_closet, garage_door, home_assistant)  and what value do they have. It is not hard to find an empty room or an empty room_door_path to a target in the building.


Sensible data. MQTT data that directly refers to private information such as (but not limited to): Text Messages and Phone Geolocalization.  The following image shows text messages between two users. The used language is Italian and a close translation could be:
- "Talk to you soon"
- "Bye"

Anonymised Private Messages (click to enlarge)


The following image shows private information between pharmaceutical products (please do not ask me more about it... I wont give out much details, the pharmaceutical service has been alerted).

Anonymised Private Message between pharmaceutical services (click to enlarge)

The following image shows an interesting "spying" service (actually it's owntracks.org) which communicates geo-location over MQTT unauthenticated brokers.

Geo-location tracks (click to enlarge)



Naturally such a private information should not be freely accessible. For example knowing where people are without their permissions is illegal in many states, or reading their application messages without judiciary consent is illegal in many states as well. Naturally the correlation to such information is illegal as well. Unfortunately attackers are everywhere and thanks to internet and telecommunication their malicious activities could have global impacts. Nowadays everybody has got a smart devices, everybody keeps trace of own steps, everybody keeps monitored own heart and everybody put everything on a cloud who does not belong to him. On the other hand applications are not always well protected making data freely available and exposing data owner to incredible indirect risks.

Final Thoughts:
Unfortunately Is not possible to stop this process: Tomorrow there will be more smart things that today. Unfortunately is not possible to protect everything: products have to get to the market as quick as possible to gain market. This process is quicker than the ability of the security community to safely test everything. De facto we will continue to use even more "smart things" which will monitor everything about our life.

Threats are changing, so are we  ?  




Toolsmith In-depth Analysis: motionEyeOS for Security Makers



It's rather hard to believe, unimaginable even, but here we are. This is the 120th consecutive edition of toolsmith; every month for the last ten years, I've been proud to bring you insights and analysis on free and open source security tools. I hope you've enjoyed the journey as much as I have, I've learned a ton and certainly hope you have too. If you want a journey through the past, October 2006 through August 2015 are available on my web site here, in PDF form, and many year's worth have been published here on the blog as well.
I labored a bit on what to write about for this 10th Anniversary Edition and settled on something I have yet to cover, a physical security topic. To that end I opted for a very slick, maker project, using a Raspberry Pi 2, a USB web cam, and motionEyeOS. Per Calin Crisan, the project developer, motionEyeOS is a Linux distribution that turns a single-board computer into a video surveillance system. The OS is based on BuildRoot and uses motion as a backend and motionEye for the frontend.
  • Buildroot "is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation."
  • Motion (wait for it) is a program that monitors the video signal from cameras and is able to detect if a significant part of the picture has changed; in other words, it can detect motion.
  • motionEye is also Calin's project and is web frontend for the motion daemon.

Installation was insanely easy, I followed Calin's installation guidelines and used Win32DiskImager to write the image to the SD card. Here's how straightforward it was in summary.
1) Download the latest motionEyeOS image. I used build 20160828 for Raspberry Pi 2.
2) Write the image to SD card, insert the SD into your Pi.
3) Plug a supported web camera in to your Pi, power up the Pi. Give it a couple minutes after first boot per the guidelines: do not disconnect or reboot your board during these first two minutes. The initialization steps:
  • prepare the data partition on the SD card
  • configure SSH remote access
  • auto-configure any detected camera devices
4) Determine the IP addressed assigned to the Pi, DHCP is default. You can do this with a monitor plugged in the the Pi's HDMI port, via your router's connected devices list, or with a network scan.
For detailed installation instructions, refer to PiMyLifeUp's Build a Raspberry Pi Security Camera Network. It refers to a dated, differently named (motionPie) version of motionEyeOS, but provides great detail if you need it. There are a number of YouTube videos too, just search motionEyeOS.

Configuration is also ridiculously simple. Point your browser to the IP address for the Pi, http://192.168.248.20 for me on my wired network, and http://192.168.248.64 once I configured motionEyeOS to use my WiFi dongle.
The first time you login, the password is blank so change that first. In the upper left corner of the UI you'll see a round icon with three lines, that's the setting menu. Click it, change your admin and user (viewer) passwords STAT. Then immediately enable Advanced Settings.
Figure 1: Preferences

You'll definitely want to add a camera, and keep in mind, you can manage multiple cameras with on motionEyeOS devices, and even multiple motionEyeOS systems with one master controller. Check out Usage Scenarios for more.
Figure 2: Add a camera

Once your camera is enabled, you'll see its feed in the UI. Note that there are unique URLs for snapshots, streaming and embedding.

Figure 3: Active camera and URLs
When motion detection has enabled the camera, the video frame in the UI will be wrapped in orange-red. You can also hover over the video frame for additional controls such as full screen and immediate access to stored video.

There are an absolute plethora of settings options, the most important of which, after camera configuration, is storage. You can write to local storage or a network share, this quickly matters if you choose and always-on scenario versus motion enabled.
Figure 4: Configure file storage
You can configure text overlay, video streaming, still images, schedules, and more.
Figure 5: Options, options, options
The most important variable of all us how you want to be notified. 
There are configuration options that allow you to run commands so you script up a preferred process or use one already devised.
Figure 6: Run a command for notification

Best of all, you can make uses of a variety of notification services including email, as well as Pushover, and IFTTT via Web Hooks.
Figure 7: Web Hook notifications
There is an outstanding article on using Pushover and IFTTT on Pi Supply's Maker Zone. It makes it easy to leverage such services even if you haven't done so before.
The net result, after easy installation, and a little bit of configuration is your on motion-enabled CCTV system that costs very little compared to its commercial counterparts.
Figure 8: Your author entering his office under the watchful eye of Camera1
Purists will find image quality a bit lacking perhaps, but with the right camera you can use Fast Network Camera. Do be aware of the drawbacks though (lost functionality).

In closing, I love this project. Kudos to Calin Crisan for this project. Makers and absolute beginners alike can easily create a great motion enabled video/still camera setup, or a network of managed cameras with always on video. The hardware is inexpensive and readily available. If you've not explored Raspberry Pi this is a great way to get started. If you're looking for a totally viable security video monitoring implementation, motionEyeOS and your favorite IoT hardware (the project supports other boards too) are a perfect combo. Remember too that there are Raspberry Pi board-specific camera modules available.

Ping me via email or Twitter if you have questions (russ at holisticinfosec dot org or @holisticinfosec).
Cheers…until next time.

Best toolsmith tool of the last ten years

As we celebrate Ten Years of Toolsmith and 120 individual tools covered in detail with the attention they deserve, I thought it'd be revealing to see who comes to the very top of the list for readers/voters.
I've built a poll from the last eight Toolsmith Tools of the Year to help you decide, and it's a hell of a list.
 Amazing, right? The best of the best.

You can vote in the poll to your right, it'll be open for two weeks.

Toolsmith Release Advisory: Kali Linux 2016.2 Release

On the heels of Black Hat and DEF CON, 31 AUG 2016 brought us the second Kali Rolling ISO release aka Kali 2016.2. This release provides a number of updates for Kali, including:
  • New KDE, MATE, LXDE, e17, and Xfce builds for folks who want a desktop environment other than Gnome.
  • Kali Linux Weekly ISOs, updated weekly builds of Kali that will be available to download via their mirrors.
  • Bug Fixes and OS Improvements such as HTTPS support in busybox now allowing the preseed of Kali installations securely over SSL. 
All details available here: https://www.kali.org/news/kali-linux-20162-release/
Thanks to Rob Vandenbrink for calling out this release. 

Toolsmith Tidbit: Will Ballenthin’s Python-evtx

Andrew Case (@attrc) called out Will Ballenthin's (@williballenthin) Python-evtx on Twitter, reminding me that I'm long overdue in mentioning it here as well.
Will's Python-evtx description from his website for same follows:
"python-evtx is a pure Python parser for recent Windows Event Log files (those with the file extension “.evtx”). The module provides programmatic access to the File and Chunk headers, record templates, and event entries. For example, you can use python-evtx to review the event logs of Windows 7 systems from a Mac or Linux workstation. The structure definitions and parsing strategies were heavily inspired by the work of Andreas Schuster and his Perl implementation Parse-Evtx."

Assuming you've running Python 2.7, install it via pip install python-evtx or download source from Github: https://github.com/williballenthin/python-evtx