This article was inspired by a previous post on my personal blog: https://www.freeture.ch/?p=815
OpenSSH is a great tool, everybody knows that (even Microsoft). It’s commonly used to securely take control or copy a bunch of files to or from remote machines. Another common scenario is to have a machine between two networks that acts as a gateway or “jump-host” between those networks; you connect to this machine and from there you open another connection to the other network. Something annoying is when you want to transfer files between the two networks, you’ll have to copy the files two times, once from the source to the gateway and then from the gateway to the destination. So if your files are huge, it means having disk space available on the jump-host and if you do so frequently it’s a headache; and everybody knows that sysadmins are lazy guys.
This tutorial will explain how to copy files from the source to the target directly and vice-versa.
In my example, target server (srv2) is behind a firewalled + NATed connection at home2 and we have no access to the router, so we can’t configure port-forwarding. Outbound connection is not filtered though, so we will initiate a reverse-tunnel to join the jump-host (srv1.com) so connection can then be initiated from srv1.com to srv2 through that persistent tunnel. Then we will configure the client machine located at home1 to access srv2 through srv1.com reverse-tunnel. We will finish with a bunch of example on how to transfer files between the client and srv2. The whole setup will use public key authentication instead of static passwords.
Step 1: Let’s start srv2 and srv1.com reverse-tunnel configuration:
I recently attended the Positive Hack Days V forum which took place in Moscow over two days. Interesting and diverse presentations were given there together with some interesting contests.
The first contest started online one week before the forum itself. It was the Hash runner challenge which consisted of cracking password hashes. The algorithms to crack were NTLM, SHA-1, MD5, LM, SHA-256, and the Russian standard GOST R 34.11. The Hashcat team won this contest.
During the other contests, each team represented a group of hackers from the virtual state: the United States of Soviet Union. These groups were asked to compromise fictional companies such as a railway company (Choo Choo Pwn), or a mobile operator (MiTM Mobile). In addition, this year, an industrial system challenge was set up about a power plant (Digital Substation Takeover). A PHD Stock Market was also implemented to allow teams to sell their exploits and gain more points or even to be compromised themselves. Videos reporting news of the challenge advances were projected during the forum. More Smoked Leet Chicken won the contest. Last but not least the (in)famous 2drink2hack contest. The goal was to hack a Web Application Firewall while drinking a shot of tequila at each stage of the contest!!
After figuring out how to design secure ciphers, cryptographers tried to find how to make secure ciphers as simple as possible. Permutation-based cryptography is the latest trend in symmetric cryptography. For example, the SHA-3 winner Keccak is based on a simple construction that iterates XORs of message chunks with the internal state with permutations of the said state. The Keccak team extended this simplistic construction to other crypto functionalities such as pseudorandom generation and authenticated encryption. With permutation-based ciphers, you get rid of key schedules, for example. Overall, it’s less stuff to design, less stuff to code, to debug, and thus hopefully fewer design flaws and fewer bugs. This approach has been successful so far with Keccak, and in SipHash and NORX.
A May 18th Washing Post article by about Chris Roberts, the security researcher questioned by the FBI about monkeying with planes’ avionics via the entertainment system, caught my attention. Not because of the sensational headlines, but because of a sentence attributed to “other aviation and security experts.”
In an attempt to make it seem that it is very unlikely to access the avionics from the entertainment system, the article states that “hacking a plane’s engine controls through its entertainment system, they argue, is a bit like controlling a car’s steering wheel through its CD player.” Unfortunately, it is quite possible to control a car’s steering wheel through its CD player. This is due to the electric power steering assistance used on most new cars, and the fact that the CD player and power steering are often both on the CAN bus.
The fact that the CD player in modern vehicles is both often on the CAN bus and hackable is widely known. Noted security expert Bruce Schneier wrote about this topic in 2011. And, of course, once you have access to the CAN bus, you can control other things connected to it such as the electric power steering assistance.
As an example, we can take the modern Ford Mustang. From at least the 2012 model, the power steering has had 3 modes select-able via the instrument cluster screens which are driven by the CAN bus. (See “STEERING FEEL” on page 22 of the owner’s manual.) The CD player is also on the CAN bus, as that is where it gets the dimmer signal. Thus, if you were to hack the CD player, you could then use the CAN bus to control the steering.
In conclusion, I certainly hope that controlling a plane’s avionics via the entertainment system is more difficult than controlling a car’s steering via the CD player.
There are many peculiarities that must be taken into account when considering the safety of industrial systems and SCADA systems. One especially relevant is patching or updating the systems or software that they support. When through a security assessment of this type of system you get to the question: “how do you carry out maintenance of systems to patch known vulnerabilities?” We can find very different answers. Some examples:
Option 1: Poker face
We do not apply security patches. It is not necessary since our industrial network is completely isolated, we rely on the ‘air GAP’ to protect our systems and most vendors don’t publish security updates. On the other hand, sometimes the software upgrade also involves hardware changes, so budgetary constraints don’t permit such updates.
This answer or other similar ones are quite common. I do not think it is a crazy strategy to follow to not apply security patches when these conditions are met:
- A risk analysis was performed to clearly understand what the threats that may affect the non-patched systems and what impact such threats could have. Note that I do not mean to make a superficial risk analysis, but I mean analyzing risks in-depth. That is, know exactly what vulnerabilities are not patched up, how it could be exploited by an attacker and what compensatory measures are implemented to mitigate the risk of not patching it. When considering the threats one should pay particular attention to the perimeter of industrial systems, points of interaction with traditional networks and access points that are easily accessible by visitors or the general public.
- Once this risk analysis is done, if the problems, costs or difficulties that result from applying the patches are greater than the risk of non-patching, it make sense not to apply the patch.
- This decision should be carried out in an informed and conscious way by the risk owner.
- The risk level should be reviewed regularly.
On the other hand, it is clear that we must put pressure on vendors to implement vulnerability management processes for their products and this point should be a key criteria in the selection of these technologies. Continue reading
After taking down the Xbox Live and the Playstation Network gaming services, the Lizard Squad group came again in the spotlight after the leak of a database of their LizardStresser not-so-new booter (a service providing Distributed Denial of Service or DDoS against payment). The breach occurred mid-January and resulted in the release of a 19 MB sql file containing the database content, consisting of about 150000 lines. We analyzed the data, focusing on targets and on attacks. After a bit of scripting, behold!
First, here’s a summary of the quantities of attacks and of attackers, showing that only 1.95% of the registered users actually used the service and launched at least one attack:
Dyre is a banking malware discovered in middle of 2014. It can intercept HTTPS traffic, using techniques documented in this Introduction to Dyreza.
In the context of our review of malware faced by customers, we need to rapidly respond and assess the risk. Dyre is malware found in such context, and we are releasing a Volatility plugin that we are using internally to dump configuration in memory for Dyre (Dyreza) samples.