In another article I summarized the series of events that lead to a potentially huge number of iOS devices being overtaken by malicious actors. While increasingly more information about these incidents is revealed, one particularly interesting question should be raised: To what extent is Apple to blame?
Fast Reaction
Let’s start with the good news. As Project Zero researcher Ian Beer writes, they have informed Apple about two of the exploits on February 1st, 2019. Apple reacted within six days and released an emergency update (iOS 12.4.1) on February 7th. This short reaction time is exemplary (especially compared to Microsoft – it recently took them more than 90 days to fix a critical Windows vulnerability reported by Project Zero, which resulted in Google disclosing the vulnerability as previously announced).
Sloppy Quality Assurance?
However, this is where Apple’s exemplary behavior ends. Again according to Ian Beer, Project Zero has identified severe mistakes made by Apple that allowed the attackers to circumvent their security. Since Apple declined to comment on the current issue of exploits, his and his colleagues’ views are taken as the only reliable source of knowledge here.
On August 29th 2019, the British security researcher Ian Beer (@i41nbeer) from Project Zero at Google published multiple blog posts about a series of iOS exploits. According to their findings, those exploits have been used to completely take over iOS devices. This article provides focused answers to eleven questions about this series of events.
What is the overall impact of this attack?
If
you used an iOS device (iPhone, iPad, …) in the last two years and
visited a certain hacked site (more on that later)
your device could have potentially been overtaken by the attacker.
Overtaken means?
Complete access to all your data, including
All messages (even encrypted ones, even from WhatsApp and iMessage – of course also unencrypted texts)
Contacts
Passwords (iOS Keychain)
Emails
Third-Party Application Data (Facebook, Telegram, Skype, …)
This is going to be a short one. You may be experiencing troubles when installing Kali Linux via an USB flash drive:
You may be inclined to waste a few hours following one of the countless articles suggesting to manually open a shell, change the way your USB stick is mounted and try to fix the issue that way.
However, chances are there is a simpler solution in case you are using the popular “LiLi USB Creator” tool on Windows for preparing your flash drives. This solution is: forget LiLi USB Creator and use Win32 Disk Imager instead. Everything will work fine, you can thank me later.
Creating and persisting business objects using Spring Boot is amazingly easy. Assume you create an API for simple CRUD methods and want to create an entity based on data entered by your frontend users. In the old times, you would probably populate several POST fields in a key-value style and create your business object manually from those fields.
Spring Boot offers an easier solution. As long as your internal data model equals the frontend’s data model, you can use the @Valid On @RequestBody Controller Method Arguments to automatically create the object from a JSON-serialized request and execute the necessary validation logic.
Imagine you work on an application on a development server for several months until it is time to deploy it to a production system for the first time. Chances are, there are several necessary configuration tasks just waiting to be forgotten: firewall permissions, specific software libraries, file permissions and so on.
Ansible offers a reproducible and automatable way to take care of these configurational changes for you – and the beauty is: it does not depend on a specific Linux flavour and it works both for single-machine deployments and distributed systems.
If you were never wondering why your application exits with an HTTP error until you have noticed that the cache folder did not have the correct permissions, stop reading; if you have never forgotten which libraries you had to apt-get install before the Makefile finally completed without errors, this is not the guide for you. Otherwise, see how a simple 50 line yml file can take care of your deployment challenges.
Performance testing a REST API reveals its runtime behaviour under stress and can be an early indicator of QoS violations in production. Apache JMeter offers a GUI mode where such load tests can be created and their results be analyzed easily.
Installing JMeter is very simple once you have Java installed on your machine (there are numerous tutorials to install Java, so I won’t go into detail here).
Once you can run the following command, you can continue with JMeter:
java -version
Download JMeter from this link (select the ZIP archive) and unpack it. In the extracted folder, go to bin/ and execute jmeter.sh (on Linux) or jmeter.bat (on Windows). You should be greeted by the following GUI:
Create a Simple Load Test
We’ll add a Thread Group which represents a group of artificial users interacting with your API. In the left panel, right click on “Test Plan” and select “Add -> Threads (Users) -> Thread Group”:
Enter the following parameters on the right panel under “Thread Properties”:
The number of threads determines how many simulated users should connect to your REST API simultaneously. The ramp-up period defines how long JMeter waits before the next request is started.
For example, if we have 64 users and a ramp-up period of 100 seconds, JMeter would add a delay of 100 / 64 seconds between each user’s first request.
Define the Invoked Action
You now have to instruct JMeter on which action should be performed by the simulated users. First, we define the base URL. Right click on the Thread Group and select “Add -> Config Element -> HTTP Request Defaults”.
For my Rust application, I use the following settings:
The default protocol is HTTP and I use localhost:8000 since this is the default port for a Rocket web application.
Next, define which specific endpoint should be used by adding an HTTP Request via “Add -> Sampler -> HTTP Request”:
And enter the following settings:
Notice that protocol and server name / port are left blank because they were set by the HTTP defaults earlier.
In my example, I’m using a GET request on the endpoint /<count> which controls how many FizzBuzz iterations are computed. By changing this number, the computational load per request can be modified. For example, /5000 means that FizzBuzz is computed for the numbers 1 to 5000.
Generating a Response Time Graph
Since we want to monitor how our API performs, the response time graph is an illustrative way of showing the average response time per request. Add it by right clicking the Thread Group and selecting “Add -> Listener -> Response Time Graph”.
The resulting graph will display how long on average it takes for an API call to produce a result.
Run the Test
Although the GUI is not a reliable way to execute tests and the command-line interface should be used instead, you can quickly verify that your test is working correctly by selecting the play button ().
Before starting the test, make sure your API is running and accepting HTTP requests. For Rust and Rocket, you can either run the application with cargo run or compile it and run the resulting binary with cargo build --release and ./target/release/fizzbuzz.exe.
After pressing the play button to start your test, you can track how many connections have been opened on the upper right corner of the interface (14 of 64 users in this example):
While the test is running, the Rust console window is showing a large number of incoming connections when using cargo run:
Interpreting the Response Time Graph
During and after the test, you can have a look at the response time graph by selecting “Response Time Graph” in the panel on the left and “Display graph” in the panel on the right.
In this example, you can easily see that the average response time for 64 parallel users is about 1.3 seconds on my absolutely non-competitive hardware (after the ramp-up period where increasingly more users are added).
Keep in mind that there are many factors contributing to the fact that this number won’t match your real response time in production, including:
the fact that both JMeter and the API run on the same hardware and have almost no network latency
the execution of JMeter itself consumes a certain part of the hardware resources
in a production environment, a web server such as nginx would be used in front of the API
performance optimizations such as caching would be applied
However, a quick measurement such as this can be more than enough when you just want to verify that you can support a given order of magnitude of parallel requests in production.
Learn How to Create a FizzBuzz Implementation in Rust
FizzBuzz is a classical software developer interview question with the simple goal of writing an application that outputs “Fizz” for numbers divisible by 3, “Buzz” for numbers divisible by 5 and “FizzBuzz” for numbers matching both cases.
In this article, I will show you how to implement FizzBuzz using the Rust programming language and the Rocket framework.
Start by using Rust nightly and setting up a new Rust project using cargo:
rustup default nightly
cargo new fizzbuzz --bin
cd fizzbuzz
rustup update && cargo update
Edit Caro.toml and add the following dependency for Rocket:
Imagine someone watching all your daily activities from hundreds of meters in the distance. While walls can protect you from spy glasses and interested neighbours looking out of their windows, they are no obstacle for electromagnetic radiation. WiFi networks in particular often build the backbone of our homes’ communication infrastructure: when you come home, your phone connects to your WiFi; when you turn on your video gaming console, it connects to your WiFi; when you leave, the WiFi connection to your phone is removed.
There are ways to measure such WiFi activities which require nothing but some cheap pieces of hardware, the right software tools and a little bit of network knowledge. In this post series, I want to investigate this topic, present state of the art tools and ways to set them up and give advice on what can be done to protect against the described invasions of your privacy.
Part 1 explains how to install Kismet – the swiss army knife for network monitoring.
Easily share your code with the PHP community by contributing your library as a composer package: This article will show you how to publish your code on GitLab and as a package on packagist.org.
Writing Your PHP Code
Publishing open source code has never been easier. Using PHP’s package manager composer, thousands of freely available packages are only one composer require away.
Believe it or not, but there exists an npm package named “is-odd” with over 700,000 weekly downloads. Its sole purpose is to “compute” whether a number is even or odd. For this tutorial, we will replicate this essential functionality as a PHP package.
Recently, I needed to extract all email addresses from a document for further processing. While I ended up writing my own regular expression, in the beginning I wanted to search for a public web service for this task. Appearantly, there exist lots of such services. However, I could not find one that works without transmitting the entered plain text to some shady server where I have no control over the sent data. This is unacceptable since email addresses are almost always sensible data points.
Out of frustration, I decided to set up such a service myself. I used this opportunity to get my feet wet with Vue.js and GitLab Pages (as described in a previous blog post).
In case you wonder about the absence of buttons: Vue.js is able to process the entered input directly and immediately outputs the results as you type – which quite frankly is absolutely amazing. I did in fact test the performance of this feature with a few thousand paragraphs of “Lorem Ipsum” and correct results were generated in a few seconds.
As you can verify using Firefox’s network monitoring tool, the entered data is not sent to any web service; instead, Vue.js processes it as you type and extracts all strings that match my regular expression (please report if I missed some edge cases. Initially, I forgot about the + character that is used for example by Gmail).
Naturally, I also set up a Letsencrypt SSL certificate which also worked flawlessly using GitLab Pages.
Setting up this service was a fun way for getting to know Vue.js and I’m already looking forward to creating more similar ones in the future.
).
