(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(credit: Employees of MGM)

Researchers have uncovered one of the most advanced espionage apps ever written for the Android mobile operating system. They found the app after it had infected a few dozen handsets.

Pegasus for Android is the companion app to Pegasus for iOS, a full-featured espionage platform that was discovered in August infecting the iPhone of a political dissident located in the United Arab Emirates. Researchers from Google and the mobile-security firm Lookout found the Android version in the months following, as they scoured the Internet. Google said an Android security feature known as Verify Apps indicated the newly discovered version of Pegasus had been installed on fewer than three-dozen devices.

"Pegasus for Android is an example of the common feature-set that we see from nation states and nation state-like groups," Lookout researchers wrote in a technical analysis published Monday. "These groups produce advanced persistent threats (APT) for mobile with the specific goal of tracking a target not only in the physical world, but also the virtual world."

Read 8 remaining paragraphs | Comments

Ninka CVE-2017-7239 Security Bypass Vulnerability
Multiple IBM Products CVE-2016-6100 Cross Site Request Forgery Vulnerability
collectd CVE-2017-7401 Multiple Denial of Service Vulnerabilities
IBM Business Process Manager CVE-2017-1140 Cross Site Scripting Vulnerability
LibTIFF CVE-2016-10271 Heap Based Buffer Overflow Vulnerability
HelpMeWatchWho CVE-2017-7387 Cross Site Scripting Vulnerability
radare2 CVE-2017-6448 Stack Buffer Overflow Vulnerability

[This is a guest diary by Paul Bolton]

First I it is not a new attack against sha1.

When Google announced a sha1 collision in February (here) it reminded me of a detour I took in Nov 2015 when downloading some software, which I think is relevant when we consider these types of announcements.

We talk about things that the most people can relate to, as this is the most effective way to communicate the issue. When talking about hashing algorithms such as sha1 this naturally tends towards is my Internet banking or other browsingis still safe.

In these cases at a technical level not only do we have the challenge of finding a collision but a collision in a highly structured format such as an SSL cert or the issue of time, which make the attack less feasible.

However, standard algorithms tend to be used for more than one thing, and in the case of hashing algorithms, if we can find a more malleable format to abuse or better still one that is also not time bound like a web page loading is, we have a better chance of success.

And this is where the story moves onto ISO images.

As Im sure many people reading this know, ISO images are usually accompanied by two further files, a file containing the hash of the image (the hash file) and a file containing the PGP signature validating the hash file.

In this case, you already have (or obtain via other channels) the PGP public key of the organization attesting to the validity of the image. They sign the hash file with their PGP key, which you can then validate. Given that, you can then validate the ISO image by computing the hash of it and comparing it with the validated hash file. If they match then all is good.

This allows you to download the software from (mirror) sites you don but wait, the ISO image was odd literally plus I liked the nice symmetry of use.

Lets take the Kali mini iso:

[[email protected] sans]$ openssl sha1 kali-linux-mini-2.0-amd64.iso
SHA1(kali-linux-mini-2.0-amd64.iso)= 5639928a1473b144d16d7ca3b9c71791925da23c
[[email protected] sans]$ fgrep kali-linux-mini-2.0-amd64 SHA1SUMS
5639928a1473b144d16d7ca3b9c71791925da23c kali-linux-mini-2.0-amd64.iso

Lets now generate some random data.

[[email protected] sans]$ dd bs=64 if=/dev/urandom of=./padding-pseudo-random.tmp count=16384
16384+0 records in
16384+0 records out
1048576 bytes (1.0 MB) copied, 0.138081 s, 7.6 MB/s

Appending this to a new copy of the ISO generates a new untrusted file which passes a simple iso file integrity check.

[[email protected] sans]$ cp kali-linux-mini-2.0-amd64.iso fake-kali.iso
[[email protected] sans]$ cat padding-pseudo-random.tmp fake-kali.iso
[[email protected] sans]$ ls -l kali-linux-mini-2.0-amd64.iso padding-pseudo-random.tmp fake-kali.iso
-rw-r--r--. 1 paul paul 31457280 Apr 1 11:04 fake-kali.iso
-rw-r--r--. 1 paul paul 30408704 Apr 1 10:58 kali-linux-mini-2.0-amd64.iso
-rw-r--r--. 1 paul paul 1048576 Apr 1 11:02 padding-pseudo-random.tmp
[[email protected] sans]$ isovfy fake-kali.iso
Root at extent 14, 6144 bytes
[0 0]
No errors found

Now, the litmus test. Can we mount it without error:

[[email protected] sans]# mount -o ro `pwd`/fake-kali.iso /mnt
[[email protected] sans]# cd /mnt/.disk cat info
Debian GNU/Linux 2.0 (sana) amd64 - netboot mini.iso 20150422+kalinext2

How about booting it as a DVD in VMWare Workstation 12.5?

Booting it:

Copying over to windows and then burning a real CD works as well. Nice!

As an attacker, this is really good news. We can append arbitrary data to an ISO file and it will still function as expected.

In other words, we can take an ISO of our choosing (in the example the mini iso), append random data so it is of the same size as one we would wish to impersonate (in the example the full-size iso), and then there is just that annoying matter of matching hashes.

So, how easy could it be to find a collision? Well no harder than finding a collision in a small file.

The performance improvements rely on two facts:

  1. You have the original ISO image you wish to impersonate, and
  2. The fake ISO is smaller than the original.

First, a simplistic review of SHA1. You have a set of registers that are initialized towell-knownn values. The data you wish to hash is padded with a defined sequence of data and, importantly, the encoded size of the original data so that it is an exact multiple of the block size of 512 bits. You compute each block which modifies the registers, which then feeds into the next block. The hash you get are the resulting registers though probabilities and other cryptanalysis suggest the number of tests is much less for finding just one collision, which is all we need).

So, as in the demonstration earlier, if you can append arbitrary data without error to the given format, you have the ideal situation to find a collision with a real-life and common use case.

More explicitly, as you have the original ISO (I) you can extract the registers at any part of the computation (before the padding). Therefore you can append to your impersonated ISO (I) random data up to block In, say. This would have the registers set to Rn. In your original ISO at In the registers would be Rn.

In the original ISO the processing of block n will change the registers to Rn+1. Therefore, providing any appended data in I for blocks after block n are the same as in I, if we can set block n in I to contain data that yields Rn+1 = Rn+1 we have a collision. (Remember they are the same size)

As we can append arbitrary data this constraint on later blocks is trivial to meet.

Other than looking at the image itself, would there be any clues as to the fact that something is not right? Im sure readers will be able to mention a few ideas. One which could stand out is the size of the mounted partition if the fake is very much smaller:

[[email protected] sans]$ cp kali-linux-mini-2.0-amd64.iso fake-kali-2.iso
[[email protected] sans]$ cat kali-linux-mini-2.0-amd64.iso fake-kali-2.iso
[[email protected] sans]$ ls -l kali-linux-mini-2.0-amd64.iso fake-kali-2.iso
-rw-r--r--. 1 paul paul 60817408 Apr 1 13:56 fake-kali-2.iso
-rw-r--r--. 1 paul paul 30408704 Apr 1 10:58 kali-linux-mini-2.0-amd64.iso
[[email protected] sans]# mount -o ro `pwd`/fake-kali-2.iso /mnt df -k /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 22662 22662 suggesting something isnt quite right if it isn a collision. Alas, my pockets are nowhere near as deep nor my crypto-fu as strong as Google.

note, I think the main take for me is-

If the security of a particular algorithm or protocol is shown to be less than ideal then you should consider how all your use cases could potentially be abused. You may find that whilst the headline examples offer some comfort, they may hide some other use cases that are more attractive to an adversary.

Here we have a practical example how we can potentially take advantage of a weak algorithm, and thus further evidence we should move away from sha1 as a hashing function.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.


iOS 10.3.1 is out. The release notes don't specify what it fixes that wasn't addressed in the wide-ranging iOS 10.3 update released just a week ago, but we do know that this new update includes bug fixes and improves the security of your iPhone or iPad. Specifically, according to the more detailed notes on Apple's security page, 10.3.1 addresses a buffer overflow that could be exploited to execute code on your phone or tablet's Wi-Fi chip.

The bug is credited to Google's Project Zero, which discloses bugs to the public 90 days after telling companies about them to encourage faster security patches.

Apple released a beta of iOS 10.3.2 last week shortly after releasing iOS 10.3. It will likely go through a handful of additional beta builds and be released to the public in a month or two. We don't expect it to change much, given that the public reveal of iOS 11 in June is just a couple of months away.

Read 1 remaining paragraphs | Comments

Magmi 'magmi/web/ajax_gettime.php' Cross Site Scripting Vulnerability
Openeclass 'webconf/webconf.php' Multiple Cross Site Scripting Vulnerabilities
SocialNetwork CVE-2017-7390 Cross Site Scripting Vulnerability
podofo Null Pointer Dereference Denial of Service and Heap Based Buffer Overflow Vulnerabilities
Apple iOS/macOS/WatchOS/tvOS CVE-2017-2490 Memory Corruption Vulnerability
Linux Kernel CVE-2017-7374 Local Denial of Service Vulnerability
SEC Consult SA-20170403-0 :: Misbehavior of PHP fsockopen function
PHP CVE-2017-7272 Server Side Request Forgery Security Bypass Vulnerability
Rancher Server CVE-2017-7297 Security Bypass Vulnerability
Multiple GIGABYTE Products VU#507496 Multiple Security Bypass Vulnerabilities
Ceragon FibeAir IP-10 Web Interface Authentication Bypass Vulnerability
LastPass Isolated World Global Properties Remote Code Execution Vulnerability

I have been looking for a while for inline proxy that is easy to setup and manage and a co-worker suggested trying IPFire[1]. IPFire is a Linux based hardened OS compiled from sources and takes about 15 minutes to do the basic installation. Before starting, you need to determine how many interfaces (zones) you need to setup (2 to 4); mandatory green for internal, red for Internet and you can also have blue for wireless and orange for the demilitarized zone width:159px" />

Obviously, if you are an business, you can purchase a IPFire hardware appliances for enterprises, large businesses and SOHO. If you are interested in an easy to use household multipurpose Security Gateway, give this one a try.

[1] http://www.ipfire.org/features
[2] http://wiki.ipfire.org/en/start
[3] http://wiki.ipfire.org/en/addons/start
[4] http://www.ipfire.org/download

Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Splunk Enterprise Information Theft CVE-2017-5607
Internet Storm Center Infocon Status