#setrules | Explore Tumblr posts and blogs

terabitweb · 6 years ago

Text

Original Post from McAfee Author: Sam Quinn

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke.

With that in mind, I began to investigate the Mr. Coffee Coffee Maker with Wemo since we had previously bought one for our research lab (and we don’t have many coffee drinkers, so I didn’t feel bad about demolishing it!) My hope was to build on previous work done by my colleague Douglas McKee (@fulmetalpackets) and his Wemo Insight smart plug exploit. Finding the similar attack vector absent in this product, I explored a different avenue and was able to find another exploit. In this post I will explore my methodology and processes in detail.

All Wemo devices have two ways of communicating with the Wemo App, remotely via the internet or locally directly to the Wemo App. Remote connectivity is only present when the remote access setting is enabled, which it is by default. To allow the Wemo device to be controlled remotely, the Wemo checks Belkin’s servers periodically for updates. This way the Wemo doesn’t need to open any ports on your network. However, if you are trying to control your Wemo devices locally, or the remote access setting is disabled, the Wemo app connects directly to the Wemo. All my research is based on local device communication with the remote access setting turned off.

To gain insight on how the coffee maker communicates with its mobile application, I first set up a local network capture on my cellphone using an application called “SSL Capture.” SSL Capture allows the user to capture traffic from mobile applications. In this case, I selected the Wemo application. With the capture running, I went through the Wemo app and initiated several standard commands to generate network traffic. By doing this, I was able to view the communication between the coffee maker and the Wemo application. One of the unique characteristics about the app is that the user is able schedule the coffee maker to brew at a specified time. I made a few schedules and saved them.

I began analyzing the network traffic between the phone application and the Mr. Coffee machine. All transmissions between the two devices were issued in plaintext, meaning no encryption was used. I also noticed that the coffee maker and the mobile app were communicating over a protocol called UPNP (Universal Plug and Play), which has preset actions called “SOAP ACTIONS.” Digging deeper into the network capture from the device, I saw the SOAP action “SetRules.” This included XML content that pertained to the “brew schedule” I had set from the mobile application.

A Mr. Coffee “brew” being scheduled.

At this point I was able to see how the Wemo mobile application handled brewing schedules. Next, I wanted to see if the coffee maker performed any sort of validation of these schedules so I went back into the mobile application and disabled them all. I then copied the data and headers from the network capture and used the Linux Curl command to send the packet back to the coffee maker. I got the return header status of “200” which means “OK” in HTTP. This indicated there was no validation of the source of brewing schedules; I further verified with the mobile application and the newly scheduled brew appeared.

Curl command to send a “Brew” schedule to the Wemo Coffee maker.

Screenshot of the Curl command populating the Wemo app with a brew schedule

At this point I could change the coffee maker’s brew schedule without ever using the Wemo mobile application. To understand how the schedules were stored on the Wemo coffee maker, I decided to physically disassemble it and look at the electronics inside. Once disassembled, I saw there was a Wemo module connected to a larger PCB responsible for controlling the functions of the coffee maker. I then extracted the Wemo module from the coffee maker. This looked almost Identical to the Wemo module that was in the Wemo Insight device. I leveraged Doug’s blog on exploitation of the Wemo Insight to replicate the serial identification, firmware extraction, and root password change. After I obtained root access via the serial port on the Wemo device, I began to investigate the way in which the Wemo application is initiated from the underlying Linux Operating System. While looking through some of the most common Linux files and directories, I noticed something odd in the “crontab” file (used in Linux to execute and schedule commands).

It appeared the developers decided to take the easy route and used the Linux crontab file to schedule tasks instead of writing their own brew scheduling function. The crontab entry was the same as the scheduled brew I sent via the Wemo application (coffee-3) and executed as root. This was especially interesting; if I could add some sort of command to execute from the replayed UPNP packet, I could potentially execute my command as root over the network.

With the firmware dumped, I decided to look at the “rtng_run_rule” executable that was called in the crontab. The rtng_run_rule is a Lua script. As Lua is a scripting language, it was written in plaintext and not compiled like all the other Wemo executables. I followed the flow of execution until I noticed the rule passing parameters to a template for execution. At this point, I knew it would be useless trying to inject commands directly into the rule and instead looked at modifying the template performing the execution.

I went back to the Wemo mobile application network captures and started to dig around again. I found the application also sends the templates to the Wemo coffee maker. If I could figure out how to modify the template and still have the Wemo think it is valid, I could get arbitrary code execution.

Template with the correct syntax to pass Wemo’s verification

There were 3 templates sent over, “do,” “do_if,” and “do_unless.” Each of the templates were Lua scripts and encoded with base64. Based on this, I knew it would be trivial to insert my own code; the only remaining challenge would be the MD5 hash included at the top of the template. As it turned out, that was hardly an obstacle.

I created an MD5 hash of the base-64 decoded Lua script and the base64 encoded script separately, simply to see if one or the other matched the hash that was being sent; however, neither matched the MD5 being sent in the template. I began to think the developers used some sort of HMAC or clever way to hash the template, which would have made it much harder to upload a malicious template. Instead, I was astounded to find out that it was simply the base64 code prepended by the string “begin-base64 644 ” and appended with the string “====.”

At last I had the ability to upload any template of my choice and have it pass all the Wemo’s verification steps necessary to be used by a scheduled rule.

I appended a new template called “hack” and added a block of code within the template to download and execute a shell script.

Within that shell command, I instructed the Mr. Coffee Coffee Maker with Wemo to download a cross-complied version of Netcat so I can get a reverse shell, and also added an entry to “rc.local.” This was done so that if the coffee maker was power cycled, I would have persistent access to the device after reboot, via the Netcat reverse shell.

The final aspect of this exploit was to use what I learned earlier to schedule a brew with my new “hack” template executing my shell script. I took the schedule I was able to replay earlier and modified it to have the “hack” template execute 5 minutes from the time of sending. I did have to convert the time value required into the epoch time format.

Converting time to Epoch time.

Now, I sat back and waited as the coffee maker (at my specified time delay) connected to my computer, downloaded my shell script, and ran it. I verified that I had a reverse shell and that it ran as intended, perfectly.

This vulnerability does require network access to the same network the coffee maker is on. Depending on the complexity of the user’s password, WiFi cracking can be a relatively simple task to accomplish with today’s computing power. For example, we demonstrate a quick and easy brute force dictionary attack to crack a semi-complex WPA2 password (10 characters alpha-numeric) in the demo for the Wemo Insight smart plug. However, even a slightly more complex password, employing special characters, would exponentially increase the difficulty of a brute force attack. We contacted Belkin (who owns Wemo) on November 16th, 2018 and disclosed this issue to them. While the vendor did not respond to this report, we were pleasantly surprised to see that the latest firmware update has patched the issue. Despite a general lack of communication, we’re delighted to see the results of our research further securing home automation devices.

This vulnerability shows that not all exploits are overly complicated or require an exceptional amount of effort to pull off, if you know what to look for. This vulnerability exists solely because a few poor coding decisions were made in conjunction with a lack of input sanitation and validation. Even though this target does not contain sensitive data and is limited to your local network, it doesn’t mean malicious hackers are not targeting IOT devices like this. These devices may serve as a sought-after target as they are often overlooked from a security standpoint and can provide a simple and unmonitored foothold into your home or business network. It is very important for any consumer, when purchasing new IOT gadgets, to ask themself: “Does this really need to be connected to the internet?” In the case of a coffee maker, I’ll let you be the judge.

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.

Go to Source Author: Sam Quinn Your Smart Coffee Maker is Brewing Up Trouble Original Post from McAfee Author: Sam Quinn IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples.

#McAfee Security

0 notes

eijun-enjoyer · 6 years ago

Link

by Bright_Moon_Beam, orangenseok

The way he saw it, Min Yoongi had two options: stay in the confines—and admittedly, safety—of his bedroom like his parents and brother would want, continuing to observe the outside world like a bird in a cage, or finally work up the balls to disobey the rules his parents had set—rules that had become such a fundamental element of his being—sneak out of his proverbial cage, and spread his wings.

That window was the boundary between two worlds: the world of his home, safety—the only world he’d ever known—and the world of the outside, with its unpredictability, that he had always merely observed with a deep longing in his chest. Could he disobey the rules that had governed his life thus far and cross the unseen barrier?

He could.

Words: 6432, Chapters: 1/?, Language: English

Series: Part 1 of Superhumans

Fandoms: 방탄소년단 | Bangtan Boys | BTS, GOT7

Rating: Teen And Up Audiences

Warnings: Graphic Depictions Of Violence

Categories: Gen

Additional Tags: Non-Human Humanoid Society, Fighting, Angst, Angst and Humor, Angst and Feels, Angst and Tragedy, Corruption, Mutant Society, War, Coming of Age, Isolation, Loss of Parent(s), Murder, Suicide Attempt, Attempted Murder, Hurt/Comfort, Friendship, Government Conspiracy, Government Experimentation, Kidnapping, Family Drama, Dysfunctional Family, Emotions, Emotional Manipulation, Emotional Baggage, Emotional/Psychological Abuse, Manipulation, Mind Manipulation, Mind Control, Abandonment, Alternate Universe - Superheroes/Superpowers, Superpowers

#taegi vsuga

0 notes

mlbors · 8 years ago

Text

First steps with continuous integration

In this post, we are going to overview some tools to use continuous integration.

Continuous integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. CI originated from within the extreme programming paradigm, but the principles can be applied to any iterative programming model, such as agile programming.

There are many tools that we can use and one of the most famous is probably Jenkins, written in Java. But we are not going to talk about Jenkins in this post. Instead, we are going to generate a really small project with some other tools. For that, we need Git, Ruby, PHP, Composer, PHPUnit, PHP-CS-Fixer, GitHub, Travis, StyleCI and Codecov. We may think that is a lot of stuff, but there is no reason to be afraid.

Definitions

First of all, a few and short definitions!

Git

Git is a free and open source distributed version software for tracking changes in computer files and coordinating work on those files among multiple people. It was created by Linus Torvalds.

GitHub

GitHub is a web-based Git that got a mascot called Octocat, a cat with five tentacles and a human-like face. It was created by Chris Wanstrath, PJ Hyett and Tom Preston-Werner.

Ruby

A famous programming language. We will need it to install gems (Ruby Libraries).

PHP

Another famous programming language. We will create our project with it.

Composer

A dependency manager for PHP that was initially developed by Nils Adermann and Jordi Boggiano.

PHPUnit

A framework for unit testing for PHP created by Sebastian Bergmann.

PHP-CS-Fixer

A tool to automatically fix PHP coding standards issues.

Travis CI

A continuous integration service used to build and test software projects hosted at GitHub.

StyleCI

StyleCI makes sure that all code on our PHP project is written to a consistent standard.

Codecov

Codecov provides metrics and insights into the results of tests through code coverage.

For the sake of this article, we are not going to discuss here about test driven development (TDD), how to write good and efficient tests and things like that. These are other subjects. The aim of this post is to see how to install and use all of those tools.

Installation

Composer

Installing Composer is really easy. We just have to go to https://getcomposer.org/download/ and follow the instructions. On Windows, there is an installer.

PHPUnit

Again, we have to go to https://phpunit.de/manual/current/en/installation.html and follow the instructions. On Windows, globally install PHPUnit is a bit trickier.

Ruby

On a Linux system and on macOS, Ruby is already here. On Windows, we have to download the installer from https://rubyinstaller.org/downloads/.

Git

We just need to go here https://git-scm.com/downloads and follow the instructions.

PHP-CS-Fixer

On a Linux system and on macOS, we can globally install PHP-CS-Fixer by following the instructions written here https://github.com/FriendsOfPHP/PHP-CS-Fixer.

GitHub, Travis CI, StyleCI, Codecov

We just have to go on GitHub (https://github.com/) and create an account. We will then have access to Travis CI (https://travis-ci.org/), StyleCI (https://styleci.io/) and Codecov (https://codecov.io) with that same account.

Travis gem

The gem can be install by doing the following command in the terminal:

gem install travis

Setting up the project

Now that we have all our new tools, we can move to the next step and set up our project.

Composer

The first thing we need to do is to create a composer.json file at the root of our project. We can create it manually or by doing the following command:

composer init

Command

{ "name": "mlbors/simple-travis-codevoc-styleci", "description": "Simple project using Composer, PHPUnit, Travis, Codecov, PHP-CS-Fixer and StyleCI", "license": "MIT", "require": { "php": ">=5.6", "ext-curl": "*", "friendsofphp/php-cs-fixer": "2.0.0" }, "require-dev": { "phpunit/phpunit": "5.7.*", "vlucas/phpdotenv": "^2.0" }, "autoload": { "psr-4": { "mlbors\\SimpleApp\\": "app/" } }, "autoload-dev": { "psr-4": { "mlbors\\SimpleApp\\Tests\\": "tests/" } }, "homepage": "https://github.com/mlbors/simple-travis-codevoc-styleci", "authors": [ { "name": "mlbors", "email": "[email protected]", "homepage": "http://www.mlbors.com/" } ] }

composer.json file

In the above example, in the require section, we say that we need PHP 5.6 or higher, Curl and PHP-CS-Fixer. In require-dev, we have PHPUnit and PHPDotEnv. In the autoload and autoload-dev sections, we say that we use the PSR-4 standard and how our namespaces will be.

It is time to do the following commands to install and generate the autoload:

composer install composer dump‑autoload -o

GitHub

First of all, we create two files: .gitignore and .gitattributes.

/vendor /node_modules .env .php_cs.cache composer.lock npm-debug.log

.gitignore file

/.gitattributes export-ignore /.gitignore export-ignore /phpunit.xml export-ignore /.env export-ignore /.env.example export-ignore

.gitattributes file

Then, we go on GitHub and create a new repository. Then, on our system, at the root of our project, we do the following commands:

git init git add . git commit –m "First commit" git remote add origin https://github.com/user/repository.git git push –u origin master

Replace user and repository by your username and your repository

Now we can go on Travis CI, StyleCI and Codecov and link our repository to those services.

StyleCI

Now, at the root of our project, we create the styleci.yml that will tell StyleCI file which rules we use.

preset: psr1

.styleci.yml file

.env File

The .env file allows us to place some values that we do not want to appear in our code. In our example, we can load them with PHPDotEnv. The .env file will be ignored by Git but we can create a .envexample file with fake values just to tell the world that we need a .env file.

SIMPLE_KEY="someValue"

.env file

Travis CI

Now we can create the .travis file that will tell Travis CI what to do with our files. We can also include critical values in that file, for example, the ones that are in the .env file, by encrypting them like so:

travis encrypt SOMEVAR=secretvalue

Command

language: php php: - 5.6 - 7.0 install: - sudo pip install codecov before_script: - composer self-update - composer install --no-interaction after_success: - bash <(curl -s https://codecov.io/bash) script: - vendor/bin/phpunit --coverage-clover=coverage.xml env: - SIMPLE_KEY=someValue notifications: email: false

.travis file

In the above example, we tell Travis CI a few things: we state that we use PHP and our app will have to work on PHP 5.6 and PHP 7. We also install the Python codecov package with pip for code coverage. Our dependencies will also be installed with Composer and PHPUnit will be executed. If everything is alright, we send the information to Codecov.

More information about how to customize the build are available here!

PHP-CS-Fixer

The .php_cs file tells PHP-CS-Fixer the rules that we use.

notPath('vendor') ->in(__DIR__) ->name('*.php') ->ignoreDotFiles(true) ->ignoreVCS(true); $rules = [ '@Symfony' => true ]; return PhpCsFixer\Config::create() ->setRules($rules) ->setFinder($finder) ->setUsingCache(false);

.php_cs file

PHPUnit

We create a phpunit.xml to tell PHPUnit how to run our unit tests. We also set the processUncoveredFilesFromWhitelist attribute for code coverage.

<?xml version="1.0" encoding="UTF-8"?> <phpunit backupGlobals="false" backupStaticAttributes="false" bootstrap="vendor/autoload.php" colors="true" convertErrorsToExceptions="true" convertNoticesToExceptions="true" convertWarningsToExceptions="true" processIsolation="false" stopOnFailure="false" syntaxCheck="false"> <testsuites> <testsuite name="SimpleApp Test Suite"> <directory suffix="Test.php">./tests/</directory> </testsuite> </testsuites> <filter> <whitelist processUncoveredFilesFromWhitelist="true"> <directory suffix=".php">./app</directory> </whitelist> </filter> </phpunit>

.phpunit.xml

In the above example, among other things, we tell PHPUnit where our test suite will be and how to compute the code coverage.

README

The README.md file tells the world about our project. We can also include into it the badges that Travis CI, StyleCI and Codecov will generate.

[![Build Status](https://travis-ci.org/mlbors/simple-travis-codevoc-styleci.svg?branch=master)](https://travis-ci.org/mlbors/simple-travis-codevoc-styleci) [![StyleCI](https://styleci.io/repos/75407002/shield?branch=master)](https://styleci.io/repos/75407002) [![codecov](https://codecov.io/gh/mlbors/simple-travis-codevoc-styleci/branch/master/graph/badge.svg)](https://codecov.io/gh/mlbors/simple-travis-codevoc-styleci) Simple project using Composer, PHPUnit, Travis, Codecov, PHP-CS-Fixer and StyleCI

.README.md file

Let's use all those tools

PHP-CS-Fixer

To use PHP-CS-Fixer, we can enter the following commands in our terminal:

$ php php-cs-fixer.phar fix /complete/path/to/dir $ php php-cs-fixer.phar fix /complete/path/to/file

On Windows we can do it like so:

php path\to\project\vendor\friendsofphp\php-cs-fixer\php-cs-fixer fix path\to\fileordir

PHPUnit

To run our tests, we just have to use

phpunit

On Windows, we can do it like so:

php path\to\project\vendor\phpunit\phpunit\phpunit

And we push

It is time! Now we can do

git add . git commit –m "This is a commit" git push origin mybranch

If everything is alright, our files will be send to GitHub, then to Travis CI and StyleCI. Travis CI will do what we wrote in our .travis file then send coverage information to Codecov. And voilà!

Advantages

Continuous integration advantages are several:

Integration bugs are detected early and are easy to track down

Constant availability of a "current" build for testing, demo, or release purposes

Frequent code check-in pushes developers to create modular, less complex code

Enforces discipline of frequent automated testing

Immediate feedback on system-wide impact of local changes

And so on. On the other hand, we can state that continuous integration requires a considerable amount of work and time. And 100% code coverage doesn't mean that every execution path is tested and our software is bug free.

You can find the complete example on my GitHub (https://github.com/mlbors/simple-travis-codevoc-styleci).

#ci #travisci #codecov #styleci #git #github #composer #phpunit #php #unit testing #continuous integration

0 notes

mattatabot · 8 years ago

Text

mattata's Channel's Post @ March 1, 2017 at 09:16PM

I can perform many administrative actions in your groups, just add me as an administrator and send /administration to adjust the settings for your group. Here are some administrative commands and a brief comment regarding what they do: - /pin <text> - Send a Markdown-formatted message which can be edited by using the same command with different text, to save you from having to re-pin a message if you can't edit it (which happens if the message is older than 48 hours) - /ban - Ban a user by replying to one of their messages, or by specifying them by username/ID - /kick - Kick (ban and then unban) a user by replying to one of their messages, or by specifying them by username/ID - /unban - Unban a user by replying to one of their messages, or by specifying them by username/ID - /setrules <text> - Set the given Markdown-formatted text as the group rules, which will be sent whenever somebody uses /rules - /setwelcome - Set the given Markdown-formatted text as a welcome message that will be sent every time a user joins your group (the welcome message can be disabled in the administration menu, accessible via /administration) - /warn - Warn a user, and ban them when they hit the maximum number of warnings - /mod - Promote the replied-to user, giving them access to administrative commands such as /ban, /kick, /warn etc. (this is useful when you don't want somebody to have the ability to delete messages!) - /demod - Demote the replied-to user, stripping them from their moderation status and revoking their ability to use administrative commands - /staff - View the group's creator, administrators, and moderators in a neatly-formatted list - /report - Forwards the replied-to message to all administrators and alerts them of the current situation - /setlink <URL> - Set the group's link to the given URL, which will be sent whenever somebody uses /link - /links <text> - Whitelists all of the Telegram links found in the given text (includes @username links) By: Matt via mattata's Channel

#telegram #mattata #mattatabot #bot #lua #open source #wrxck #api #telegram bot #bot api

0 notes