Researchers Find and Decode the Spy Tools Governments Use to Hijack Phones

Standard

From: http://www.wired.com/2014/06/remote-control-system-phone-surveillance/


 

whistleblower-inline

Newly uncovered components of a digital surveillance tool used by more than 60 governments worldwide provide a rare glimpse at the extensive ways law enforcement and intelligence agencies use the tool to surreptitiously record and steal data from mobile phones.

The modules, made by the Italian company Hacking Team, were uncovered by researchers working independently of each other at Kaspersky Lab in Russia and the Citizen Lab in Canada, who say the findings provide great insight into the trade craft behind Hacking Team’s tools.

The new components target Android, iOS, Windows Mobile, and BlackBerry users and are part of Hacking Team’s larger suite of tools used for targeting desktop computers and laptops. But the iOS and Android modules provide cops and spooks with a robust menu of features to give them complete dominion over targeted phones.

They allow, for example, for covert collection of emails, text messages, call history and address books, and they can be used to log keystrokes and obtain search history data. They can take screenshots, record audio from the phones to monitor calls or ambient conversations, hijack the phone’s camera to snap pictures or piggyback on the phone’s GPS system to monitor the user’s location. The Android version can qlso enable the phone’s Wi-Fi function to siphon data from the phone wirelessly instead of using the cell network to transmit it. The latter would incur data charges and raise the phone owner’s suspicion.

“Secretly activating the microphone and taking regular camera shots provides constant surveillance of the target—which is much more powerful than traditional cloak and dagger operations,” notes Kaspersky researcher Sergey Golovanov in a blog post about the findings.

It’s long been known that law enforcement and intelligence agencies worldwide use Hacking Team’s tools to spy on computer and mobile phone users—including, in some countries, to spy on political dissidents, journalists and human rights advocates. This is the first time, however, that the modules used to spy on mobile phone users have been uncovered in the wild and reverse-engineered.

Kaspersky and Citizens Lab discovered them after developing new methods to search for code fragments and digital certificates used by Hacking Team’s tools.

The modules work in conjunction with Hacking Team’s core surveillance tool, known as the Remote Control System, which the company markets under the names Da Vinci and Galileo.

In a sleek marketing video for Galileo, Hacking Team touts the tool as the perfect solution for obtaining hard-to-reach data—such as data taken by a suspect across borders or data and communications that never leave the target’s computer and therefore can’t be siphoned in transit.

“You want to look through your targets’s eyes,” says the video. “While your target is browsing the web, exchanging documents, receiving SMS….”

Hacking Team’s tools are controlled remotely through command-and-control servers set up by Hacking Team’s law enforcement and intelligence agency customers to monitor multiple targets.

Kaspersky has tracked more than 350 command-and-control servers created for this purpose in more than 40 countries. While Kaspersky found only one or two servers in most of these countries, the researchers found 64 in the United States—by far the most. Kazakhstan followed with 49, Ecuador with 35 and the United Kingdom with 32. It’s not known for certain whether law enforcement agencies in the U.S. use Hacking Team’s tool or if these servers are used by other governments. But as Kaspersky notes, it makes little sense for governments to maintain their command servers in foreign countries where they run the risk of losing control over the servers.

Map showing the number of countries where command-and-control servers for the Hacking Team are currently being used.

In addition to the modules that were uncovered, Citizen Lab obtained from an anonymous source a copy of the lengthy user’s manual that Hacking Team provides customers. The illustrated document explains in detail how to build the surveillance infrastructure needed to deliver implants to targeted devices and to use the software tool’s dashboard to manage intelligence gleaned from infected computers and phones.

“This gives new visibility into the operational procedures of lawful intercept malware,” says Citizen Lab researcher Morgan Marquis-Boire. “Previous research has allowed us to understand how the software works. This allows us a holistic view of how this type of targeted surveillance is conducted.”

Image from Hacking Team's user manual showing the interface for managing hacked systems and data siphoned from them.

The modules and training manual all show that Hacking Team is well aware of the attention its products have received from researchers in recent years and has taken several steps to thwart attempts to understand how its spy tools work.

“They are well aware that their product may show up on the analyst chopping block at some stage, and they’re taking various steps to mitigate this risk,” says Marquis-Boire.

The Android spy module, for example, uses obfuscation to make it harder to reverse-engineer and examine the module. And before installing itself on machines, Hacking Team’s main spy tool has scouting agents that conduct reconnaissance to identify anything on a system that might detect it.

Once on a system, the iPhone module uses advance techniques to avoid draining the phone’s battery, turning on the phone’s microphone, for example, only under certain conditions.

“They can just turn on the mic and record everything going on around the victim, but the battery life is limited, and the victim can notice something is wrong with the iPhone, so they use special triggers,” says Costin Raiu, head of Kaspersky’s Global Research and Analysis team.

One of those triggers might be when the victim’s phone connects to a specific WiFi network, such as a work network, signaling the owner is in an important environment. “I can’t remember having seen such advanced techniques in other mobile malware,” he says.

Hacking Team’s mobile tools also have a “crisis” module that kicks in when they sense the presence of certain detection activities occurring on a device, such as packet sniffing, and then pause the spyware’s activity to avoid detection. There is also a “wipe” function to erase the tool from infected systems. Hacking Team asserts that this will uninstall and erase all traces of the tools, but Citizen Lab discovered that initiating a wipe on some mobile phones creates telltale signs. On a BlackBerry, for example, it causes the device to automatically restart. On Android devices, the uninstall can, under certain conditions, cause a prompt to appear onscreen asking permission from the user to uninstall an application called “DeviceInfo”—the name the Android spy tool uses for itself.

In addition to the variety of obfuscation measures the tools use, Hacking Team also advises customers to set up several anonymous proxy servers through which to route data stolen from victim machines. In this way, researchers and victims won’t be able to easily follow the path the data takes back to command servers. Oddly, Hacking Team borrows the logo of the hacktivist group Anonymous—an empty black business suit—to designate the anonymized proxy servers in its user manual.

Hacking Team borrowed the logo of the hacking group Anonymous to designate anonymized proxy servers in its user manual.

Hacking Team first developed its Remote Control System spy suite in 2001. Initially it was a free, open-source tool for conducting man-in-the-middle attacks and was used by hackers and security researchers alike. Soon, however, police in Milan contacted the two authors of the tool—Alberto Ornaghi and Marco Valleri—for help developing something to eavesdrop on Skype communications. Work on this tool evolved into RCS.

Hacking Team has long argued that its products are intended for lawful governmental interception only and that it won’t sell its products to repressive regimes and countries blacklisted by NATO. But its spy suite reportedly has been used to spy on the citizen journalist group Mamfakinch in Morocco and appears to have been used by someone in Turkey to target a woman in the U.S. who was a vocal critical of Turkey’s Gulen movement.

Indeed, the Android spy module that Citizen Lab uncovered was masquerading as a legitimate news app for Qatif Today, an Arabic-language news and information service that covers the Qatif region in eastern Saudi Arabia. The government of Saudi Arabia has faced off several times in the last few years against Shia protestors in the Qatif region who have demanded political reform from the Sunni government and the release of political prisoners.

Although the Citizen Lab researchers are careful to point out that they don’t know for certain that the Saudi government is using the Hacking Team tool to spy on political dissidents, circumstantial evidence shows this may be the case.

The malicious Qatif Today app was discovered after someone uploaded the file in March to the VirusTotal web site—a site owned by Google that aggregates several dozen antivirus scanners to detect malware. The file was signed with a bogus certificate that appeared to belong to Sun Microsystems. Citizen Lab found evidence that a Twitter account of interest to Shiites in Qatif may have been used to tweet a link to the malicious file to lure targets into downloading it onto their phones.

While Hacking Team’s core Galileo tool for spying on computers is valuable for governments, the mobile spy modules are particularly attractive to repressive regimes where activists and others use their mobile phones to organize and stay connected during protests.

Cops can install the phone implants directly onto a mobile device if they have physical access to it. But they can also install the implants if a user connects the mobile device to a computer—for example, to charge the device—and the computer is already infected with Da Vinci or Galileo.

The iOS spy module works only on jailbroken iPhones, but agents can simply run a jailbreaking tool and then install the spyware. The only thing protecting a user from a surreptitious jailbreak is enabling a password on the device. But if the device is connected to a computer infected with Da Vinci or Galileo software and the user unlocks the device with a password, the malware on the computer can surreptitiously jailbreak the phone to install the spy tool.

So far, the researchers haven’t uncovered any methods used for remotely infecting phones with the Hacking Team malware via a phishing attack or a malicious web site.

Citizen Lab points out in its report on the malware that it’s important to understand how Hacking Team’s tools work, since they are powerful weapons, no different from the types of tools used by nation states against one another. But in this case they’re employed by government customers not against other government targets but against ordinary citizens.

“This type of exceptionally invasive toolkit, once a costly boutique capability deployed by intelligence communities and militaries, is now being marketed for targeting everyday criminality and ‘security threats,’” they write. “An unstated assumption is that the entities able to buy these tools will use them correctly, and primarily for law enforcement purposes. As our research has shown, however, by dramatically lowering the entry cost on invasive and hard-to-­trace monitoring, it lowers the cost of targeting political threats” too.

638 total views, no views today

Security Checklist for Linux System

Standard

From: http://www.bartbania.com/index.php/security-checklist-for-linux-system/#logging


Security Checklist for Linux System

I don’t really know why this subject is routinely ignored by users regardless of device or OS. Everyone seems to be concerned with their own security, but it all ends merely on complaining and blaming others, not ourselves.

Maintaining security of an operating system is one of the primary responsibilities of any Linux system administrator. I must say that, its also one of the toughest tasks. You can never be certain, that the machine you’re working on is secure. To be honest, there is no way a machine connected to the Internet, can be called as a secure machine. To be honest, there is no such thing as security the moment you connect to the Internet.

securityBefore we proceed I must tell you something. Don’t get fooled by the phrase –

Linux system administrator.

Don’t think this post is for some geek with glasses, sitting in a dark, smelly room, with empty cans and fast-food containers lying around, staring at thousands of computer screens doing his computer voodoo. No. This post is mainly for you, the Linux user. Believe it or not, you ARE a Linux administrator. You use, maintain, update your Linux system, don’t you? Even if it’s merely a small Raspberry Pi, a laptop or XMBC server, it doesn’t matter at all. Those are still Linux machines, nothing else, and they need your care and attention!

Let’s get back to our point. The only way you can make your computer to be the most secure machine in the world, just by pulling out the Network cable, or ripping your WiFi card out of your computer. If you think a bit deeper you will realize, that its quite true. You cannot make a system completely secure. Even if you don’t connect to the Internet (yeah, you don’t), there still exists a risk for your system to be at risk. You use removable media, mount USB sticks and CD/DVD/Blu-Ray disks that were not created by you. Unix/Linux viruses do exist. Threats to Linux systems are also posed by other forms of malware, such as Trojan horses, rootkits, and spyware. Yeah, don’t believe anyone saying there is no virus for Linux and that Linux is safe and secure! It’s completely untrue! Unix/Linux viruses do exist. Your system won’t be secure unless you take care of it!

In this post, I have created a mini security checklist for a Linux server, consisting of things I think are crucial for maintaining a sane server. I know that not all of them can be implemented everywhere, but for a general Linux usage, they’re an imperative.

Note: As said, this checklist won’t make your system a secure one. However, it would surely reduce the risk of your system being compromised.

  1. Keep the system updated with latest security patches
  2. Keep yourself updated with latest vulnerabilities through mailing lists, forums etc.
  3. Stop and disable unwanted services
  4. Use SUDO to limit ROOT Access
  5. SSH security settings
  6. Tunnel all of your XWindow sessions through SSH
  7. Create only a required number of users
  8. Maintain a good firewall policy
  9. Scan for viruses and other malware!
  10. Configure SSL/TLS if you are using FTP
  11. Secure your communication with GPG
  12. Check file permissions across filesystems
  13. Bootloader and BIOS security
  14. Enable remote Logging
  15. Keep a good password policy

 

Keep the system updated with latest security patches

You must be aware that this is the first and the most important thing to do for your system. There really exists a widespread belief that Windows should be updated, but Linux is much secure even without the patches and updates. This is totally wrong.

If you have a look at any security report, you will realize that out of all the compromises that took place, most of them occurred because of old vulnerable version of software packages or kernel.

CVE (Common Vulnerability Exposures) vulnerability details, always point towards a specific version of the package and the vendor of the package most of the times already roll out their patches.

Use 

 or 

 package manager, to keep the packages updated. If using Debian-based system, add the security repository to your 

.

Also, patch your kernel in an organised manner from time to time with latest patches available.

[^TOP^]

Keep yourself updated with latest vulnerabilities through mailing lists, forums etc.

Many open source mailing lists (product specific as well as Linux general), offer detailed information and the relevant fixes required for the latest vulnerabilities.

You should always keep yourself updated about a specific product by subscribing to security mailing lists. Don’t consider it a spam and forget about it. Read the messages posted there at least from time to time.

Examples:

[^TOP^]

Stop and disable unwanted services

You should get to know all the services running on your system, and periodically consult with other users to ensure that only services that are required are running. No unwanted service should be running on your server. Making a list of boot up services from 

 or 

 can provide you with a list of services that will come up at boot time. Disabling unwanted services on the server will also improve the server performance wise. Webmin, a web-interface for your system, might come in hand if you don’t feel comfortable enough with command line.

[^TOP^]

Use SUDO to limit ROOT Access

Using 

 to restrict user to some critical commands, is advisable. You can easily achieve this by modifying 

 files. 

 can be configured on a command by command basis, 

 file can be used to control the commands with restrictions.

[^TOP^]

SSH security settings

Almost all Linux machines use SSH service for remote login. You use SSH to access your Raspberry Pi, don’t you? Although SSH is pretty secure by itself, it doesn’t have the ability to protect the server against human mistakes. Some precautions must always be done regarding the SSH protocol.

First of all, disable 

 login through SSH protocol, by modifying the

 file and setting:

Make sure that SSH protocol version 2 is used instead of 1 (latest version of the packages use version 2 by default, so no need to modify):

Bing the default SSH port from 22 to any other (as well as IP, pointing to your machine’s IP):

Disable Host-Based Authentication:

Limit only specific users to access your machine via SSH:

Disable password-based authentication and allow public key based authentication. This will help to securely allow users whose public key is deployed on the server to login through SSH. This can be done by modifying the 

 file on the server as below:

For more tips, head to nixCraft website.

[^TOP^]

Tunnel all of your XWindow sessions through SSH

This will harden the graphical communications which is normally unencrypted. To do this, you need to have the following entry in your 

 file.

Now you can connect the server using

The 

 option allows us to use forwarded XWindow system.

The 

 designates port to connect to if using different port than the default 22.

And 

 option is a nice way to compress the traffic. Its a good option is you have low bandwidth.

[^TOP^]

Create only a required number of users

This is self-explanatory. There is no need to create thousands of user accounts. Make a list of all user accounts you have on the server, and delete all unwanted users on the system.

[^TOP^]

Maintain a good firewall policy

Write down the IP/subnets that you want to allow access to the machine and allow only them. It’s a good idea to make a firewall script for both inbound and outbound connections and enable the script for the firewall rules.

On most of the Linux firewalls, the order in which the rules are applied matters. So as mentioned, managing all rules for the firewall with a firewall script, and checking periodically the set of rules applied is a good idea.

There are a lot number of firewall’s available for Linux out there, some of them are mentioned below.

  • iptables
  • ufw
  • checkpoint
  • shorewall
  • pfsense

The important thing that matters is how you configure them, because almost all of them are good at what they do. According to me, iptables, the default firewall for most of the distributions out of the box, will be a good point to start with. You can do almost everything, that you need with this firewall. If you’re interested, here ismy post about iptables, and here you can find an example iptables script.

On top of a firewall, you might want to use additional software, like fail2ban orsnort that running along with your firewall, harden your system.

[^TOP^]

Scan for viruses and other malware!

As mentioned at the beginning, Linux is not virus-proof. In fact, Any computer that is attached to a network is not immune to viruses. The next thing you might want to do is to take a critical look at who’s knocking at your doors. You should also scan your machine for viruses.

To make sure everything that gets into your system is clean and safe useClamA[nti]V[irus]:

To install:

To update:

To inspect e.g. your download folder:

This will ClamAV do a scan recursively, i.e. also scan the content of folders and inform you about possibly infected files.

To inspect your whole system:

Remember: ClamAV is known for its tight nets. That means that you are likely to get some false positives from time to time. Do a web-search if you’re in doubt in regards to its findings.

To hunt down any rootkits that might infect your system, use RKHunter – which is short for [R]oot[K]itHunter. Installation, again, is simple:

The best is to run rkhunter on a clean installation – just to make sure nothing has been tampered with already. Directly after commands like apt-get update && apt-get upgrade run:

This tells rkhunter: It’s all good.

To run rkhunter:

You find rkhunter’s logfile in 

. So when you get a warning you can in detail check out what caused it.

To set up a cronjob for RKHunter:

insert and change the mail-address:

make the script executable:

update RKHunter:

and check if it functions the way it’s supposed to do:

Another neat tool with similar functionality is 

. To install:

To run:

[^TOP^]

Configure SSL/TLS if you are using FTP

FTP is considered to be an insecure protocol. It is advisable that you do the following things while working with FTP service:

  • Use the latest version of the FTP package
  • Force only required users to login through FTP
  • Allow only TLS with FTP access to the server.
  • If possible, keep the user in chroot jail.

[^TOP^]

Secure your communication with GPG

You can encrypt communication going from your machine using GPG. It’s a good practice, ensuring no unauthorized access to critical data, like logwatch, system reports, but also protects your own mail and conversations. For more information on GPG head here: GNU Privacy Guard – The Basics.

[^TOP^]

Check file permissions across filesystems

As you might already know, the file permissions play an important role in securing a Linux server. You need to periodically make sure all your important files are given permissions correctly.

Things to check regarding file permissions:

  • Check and confirm, if the UMASK value is as required
  • Periodically search for files with absurd permissions set on them. Like globally writeable files etc. You can search them using command:

  • Use tools like adeos for potential file state. Scanning the whole system with tools like adeos for files with dangerous permissions is a good method to follow. You can get the tool from here. It will search for files which are world writable, SUID etc.

[^TOP^]

Bootloader and BIOS security

Normally, people ignore this step as they always think attackers and intruders are always remote people tying to gain access over the Internet.

Access to BIOS means access to do anything… You can easily boot the system from any disk or other media if you have access to BIOS. So keep a secure password for BIOS. Also, protect your boot loader (GRUB, LILO) with a secure password, so that no one would change your boot options without password.

[^TOP^]

Enable remote Logging

Most of the time intruders and attackers after gaining access to the system, delete the system logs in order to delete any trace of their intrusion. However, if you have remote logging enabled, the attacker now needs to compromise multiple systems to delete the logs (which most of the times is not that easy). You can achieve remote logging with multiple tools like the following:

[^TOP^]

Keep a good password policy

Understand the usage of 

 command and use it effectively to modify password setting per user. By default, the command will show you the password information of a particular user.

Modify the password expiry per user with the help of 

 command.

Modify the 

 file to suite your needs. Also check and confirm /

 (this sets the default settings when a user is created) is as required.

[^TOP^]


I hope you enjoyed the read and found at least one useful thing for your system.

If you have any other tips for keeping the system secure, please let me know, and, most of all, leave a comment.

Pass this on:

Google+

POSTED: 11.12.2013

PREVIOUS ENTRY

NEXT ENTRY

5 Responses to “Security Checklist for Linux System”

  1. Michael says:

    Great article and nice tips! For automated testing and hardening, have also a look at my open source auditing tool Lynis.

    Project page: http://www.rootkit.nl/projects/lynis.html

    Happy hardening!

  2. Great post ! Thanks for sharing with us :-)

  3. planetscape says:

    Just what I needed, thank you!

  4. santhosh says:

    Every system administrator need to follow this checklist to make system more secure.

    Great post! Thanks for sharing.

406 total views, 1 views today

Bypassing Seagate ATA Security Lock

Standard

From: http://feedproxy.google.com/~r/hackaday/LgoM/~3/2sk-aqNfkZ0/


Bypassing Seagate ATA Security Lock

November 29, 2013 by  15 Comments

seagate

Here’s a common story when it comes to password retrieval: guy sets up a PC, and being very security-conscious, puts a password on his Seagate hard drive. Fast forward a few months, and the password is, of course, forgotten. Hard drive gets shuffled around between a few ‘computer experts’ in an attempt to solve the problem, and eventually winds up on [blacklotus89]‘s workbench. Here’s how he solved this problem.

What followed is a walk down Hackaday posts from years ago. [blacklotus] originally foundone of our posts regarding the ATA password lock on a hard drive. After downloading the required tool, he found it only worked on WD hard drives, and not the Seagate sitting lifeless on his desk. Another Hackaday post proved to be more promising. By accessing the hard drive controller’s serial port, [blacklotus] was able to see the first few lines of the memory and the buffer.

Two hours and two Python scripts later, [blacklotus] was able to dump the contents of his drive. He then took another Seagate drive, locked it, dumped it, and analyzed the data coming from this new locked drive. He found his old password and used the same method to look for the password on the old, previously impenetrable drive. It turns out the password for the old drive was set to ’0000′, an apparently highly secure password.

In going through a few forums, [blacklotus] found a lot of people asking for help with the same problem, and a lot of replies saying. ‘we don’t know if this hard drive is yours so we can’t help you.’ It appears those code junkies didn’t know how to unlock a hard drive ether, so [blacklotus] put all his tools up on GitHub. Great work, and something that didn’t end up as a Hackaday Fail of the Week as [blacklotus] originally expected.

465 total views, 1 views today