Discussion:
Ping-Paul Ransomware Questions
(too old to reply)
jetjock
2018-03-10 17:54:11 UTC
Permalink
Raw Message
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
me to some questions:

1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.

2. If Carrie would have had a backup image of her drive, which, since
she is supposedly a hotshot CIA agent, she most likely would have had,
would just recovering the backup have solved her problem? If not, why?

In all that has been written about the scourge of ransomware, I have
never read anything that would answer these questions. Would be nice
info to have.
David E. Ross
2018-03-10 19:11:00 UTC
Permalink
Raw Message
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
According to US-CERT (an agency within the U.S. Department of Homeland
Security), JPEG, GIF, BMP, and PNG image files have been known to
contain serious malware.

[snipped]
--
David E. Ross
<http://www.rossde.com/>

President Trump: Please stop using Twitter. We need
to hear your voice and see you talking. We need to know
when your message is really your own and not your attorney's.
Ken Blake
2018-03-10 20:02:41 UTC
Permalink
Raw Message
On Sat, 10 Mar 2018 11:11:00 -0800, "David E. Ross"
Post by David E. Ross
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
According to US-CERT (an agency within the U.S. Department of Homeland
Security), JPEG, GIF, BMP, and PNG image files have been known to
contain serious malware.
Moreover, the file that appears to be a .jpg file may not actually be
one.
Mayayana
2018-03-10 21:55:13 UTC
Permalink
Raw Message
"David E. Ross" <***@nowhere.invalid> wrote

| > 1. I didn't think a .jpg file could be infected. Don't know where that
| > idea came from, but I seem to remember reading it quite some time ago.
| > Can they be the vector for such a program (Ransomware), or could the
| > ransomware file just be named as a .jpg.
|
| According to US-CERT (an agency within the U.S. Department of Homeland
| Security), JPEG, GIF, BMP, and PNG image files have been known to
| contain serious malware.
|

Links? Scaremongering from DHS, and flakey TV
shows, are not very good security information. There's
been exactly one image vulnerability that I know of:

https://docs.microsoft.com/en-us/security-updates/securitybulletins/2004/ms04-028

It was a bug in a Windows graphics library,
gdiplus.dll, not a bug in a JPG per se. I don't
know of any way to rig an image because viewer
software that processes images doesn't execute
code. A BMP, for instance, is little more that a
record of color values for pixels in the image.
A bitmap. A faulty BMP might cause some
poorly designed software to crash, but that's
always true, with any file. There's no way to
put malware inside a BMP. It would just show
up as a distorted part of the image.

As always, it's executable code that's the main
problem. Javascript or Java or Flash or anything
else that actually takes actions by design. Or on
Windows it can be EXE, BAT, etc. If a malware
program is renamed to picture.jpg it's going to be
pareed as a JPG image, not run as a program. The
result should be a message that the image type is
not supported. (Though IrfanView is clever: Drop
an EXE onto the IV window and it extracts the
first icon from the EXE resources. :)
David E. Ross
2018-03-10 23:18:04 UTC
Permalink
Raw Message
Post by Mayayana
| > 1. I didn't think a .jpg file could be infected. Don't know where that
| > idea came from, but I seem to remember reading it quite some time ago.
| > Can they be the vector for such a program (Ransomware), or could the
| > ransomware file just be named as a .jpg.
|
| According to US-CERT (an agency within the U.S. Department of Homeland
| Security), JPEG, GIF, BMP, and PNG image files have been known to
| contain serious malware.
|
Links? Scaremongering from DHS, and flakey TV
shows, are not very good security information. There's
How about the National Institute of Standards and Technology (formerly
named the National Bureau of Standards)? See the following (all just a
few months ago):
<https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-16374>
<https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-16383>
<https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-16387>
Post by Mayayana
https://docs.microsoft.com/en-us/security-updates/securitybulletins/2004/ms04-028
[snipped]
Post by Mayayana
As always, it's executable code that's the main
problem. Javascript or Java or Flash or anything
else that actually takes actions by design.
[snipped]

NOTE WELL: Yes, a bug in an executable code is the problem. However,
such a bug can cause damage when the executable is asked to process a
non-executable file such as a JPEG or GIF file. Indeed, if you review
the never-ending stream of Microsoft's security updates, most
descriptions refer to an executable opening a specially constructed
non-executable file.
--
David E. Ross
<http://www.rossde.com/>

President Trump: Please stop using Twitter. We need
to hear your voice and see you talking. We need to know
when your message is really your own and not your attorney's.
Mayayana
2018-03-11 00:54:24 UTC
Permalink
Raw Message
"David E. Ross" <***@nowhere.invalid> wrote

| > Links? Scaremongering from DHS, and flakey TV
| > shows, are not very good security information. There's
| > been exactly one image vulnerability that I know of:
|
| How about the National Institute of Standards and Technology (formerly
| named the National Bureau of Standards)? See the following (all just a
| few months ago):
| <https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-16374>
| <https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-16383>
| <https://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-16387>
|

Interesting, but all 3 are related to JPG in Adobe
Acrobat Reader, which is already risky, bloated
software that no one should be running. It
*especially* shouldn't be allowed to open PDFs
online. And it shouldn't have javascript enabled.

So basically you're saying the same as I said:
One might be able to dredge up an obscure issue,
but they'll be rare. That's a long way from "DHS
says image files can contain malware". They can't.
(There was once an issue with EMF files, but
those are custom, semi-executable, image storage
files rather than actual images.)

Of course I'll be the one surprised if I download
a photo and it makes IrfanView send all my data
online. :) But I'm not going to worry about that.
There are real issues and there are theoretical
possibilities.
KenW
2018-03-10 19:14:28 UTC
Permalink
Raw Message
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
2. If Carrie would have had a backup image of her drive, which, since
she is supposedly a hotshot CIA agent, she most likely would have had,
would just recovering the backup have solved her problem? If not, why?
In all that has been written about the scourge of ransomware, I have
never read anything that would answer these questions. Would be nice
info to have.
I got nailed by a zip file. It was very very close to a file I was
looking for.


KenW
J. P. Gilliver (John)
2018-03-10 23:47:52 UTC
Permalink
Raw Message
Post by KenW
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
Malicious code can be put in anything, but unless it is _executed_, it's
perfectly safe. There was a bug in some (IIRR Microsoft) libraries that
were used for processing images (IIRR it was a buffer overflow thing),
which _could_ be used to cause execution of such code. If you used image
handling software (such as IrfanView) that never used such libraries,
having such an image file would do you no harm.
Post by KenW
Post by jetjock
2. If Carrie would have had a backup image of her drive, which, since
she is supposedly a hotshot CIA agent, she most likely would have had,
would just recovering the backup have solved her problem? If not, why?
If you boot from something you made before you were infected, such as
the Macrium CD (which you should have made soon after you started using
Macrium, or other similar [personally, I always use Macrium booted from
the CD even when _making_ images, though you don't have to]), and having
so booted then restore an image that was made before you were infected
(and has been kept isolated), and you restore to a new disc, you should
be all right so far. I'm not sure if the new kind of BIOS (UEFI?) can
retain infection, but I haven't heard of this happening so far.
Post by KenW
Post by jetjock
In all that has been written about the scourge of ransomware, I have
never read anything that would answer these questions. Would be nice
info to have.
I think the above (boot, restore from, and restore to, things made
before you were infected, or new) _has_ been written, just not in the
popular media, as (a) it's too detailed for them to understand
completely and (b) it makes a better story, either to scare or to
unnecessarily reassure, both of which are bad in their own ways.
Post by KenW
I got nailed by a zip file. It was very very close to a file I was
looking for.
KenW
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

_____
___ |[]|_n_n_I_c
|___||__|###|____)
O-O--O-O+++--O-O
jetjock
2018-03-11 15:34:53 UTC
Permalink
Raw Message
On Sat, 10 Mar 2018 23:47:52 +0000, "J. P. Gilliver (John)"
Post by J. P. Gilliver (John)
Post by KenW
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
Malicious code can be put in anything, but unless it is _executed_, it's
perfectly safe. There was a bug in some (IIRR Microsoft) libraries that
were used for processing images (IIRR it was a buffer overflow thing),
which _could_ be used to cause execution of such code. If you used image
handling software (such as IrfanView) that never used such libraries,
having such an image file would do you no harm.
Post by KenW
Post by jetjock
2. If Carrie would have had a backup image of her drive, which, since
she is supposedly a hotshot CIA agent, she most likely would have had,
would just recovering the backup have solved her problem? If not, why?
If you boot from something you made before you were infected, such as
the Macrium CD (which you should have made soon after you started using
Macrium, or other similar [personally, I always use Macrium booted from
the CD even when _making_ images, though you don't have to]), and having
so booted then restore an image that was made before you were infected
(and has been kept isolated), and you restore to a new disc, you should
be all right so far. I'm not sure if the new kind of BIOS (UEFI?) can
retain infection, but I haven't heard of this happening so far.
Is it really necessary to restore to a new disk? Does the restore not
write over everything on the original disk?
Post by J. P. Gilliver (John)
Post by KenW
Post by jetjock
In all that has been written about the scourge of ransomware, I have
never read anything that would answer these questions. Would be nice
info to have.
I think the above (boot, restore from, and restore to, things made
before you were infected, or new) _has_ been written, just not in the
popular media, as (a) it's too detailed for them to understand
completely and (b) it makes a better story, either to scare or to
unnecessarily reassure, both of which are bad in their own ways.
Post by KenW
I got nailed by a zip file. It was very very close to a file I was
looking for.
KenW
J. P. Gilliver (John)
2018-03-11 15:52:14 UTC
Permalink
Raw Message
In message <***@4ax.com>, jetjock
<***@example.com> writes:
[]
Post by jetjock
Is it really necessary to restore to a new disk? Does the restore not
write over everything on the original disk?
[]
1. In theory, yes. If you can be sure that at no time during your
restore process is there any chance of anything on the original disc
being run, then you're probably OK.
2. Most restore processes, at least on the default settings, will just
overwrite what they need to to restore the image. The remaining parts of
the disc surface - which would now be considered free available space -
might still contain (the remains of) infected files. Normally, this
would not be a problem: most of the time, those parts of the surface
would not be accessed except to write over them anyway. I suppose some
badly-written software [including the OS (-:] might allocate sections of
disc (e. g. for use as buffers [including page file and similar?]), not
use it all, and subsequently save those buffers - including the
non-overwritten infected bits. However, I think this is unlikely; I
posit this just as a way infected code _could_ survive both a restore
and subsequent use. Such code would _still_ be safe unless executed,
which if it's only part of a video buffer or similar is unlikely.

Hopefully, ransomware is so rare that, for a lot of people, it might
happen at a time when - or server as a trigger for - they decide to,
say, get a bigger disk anyway.

Has anyone _here_ had ransomware? (I know we're far from a
representative sample, but still, out of curiosity. Perhaps some of
those here who support others have at least encountered it.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)***@T+H+Sh0!:`)DNAf

... referendum coverage is available with subtitles for the deaf, audio
description for the blind, and ITV for the thick. - Dead Ringers, 2016-6-25
jetjock
2018-03-11 20:02:57 UTC
Permalink
Raw Message
On Sun, 11 Mar 2018 15:52:14 +0000, "J. P. Gilliver (John)"
Post by J. P. Gilliver (John)
[]
Post by jetjock
Is it really necessary to restore to a new disk? Does the restore not
write over everything on the original disk?
[]
1. In theory, yes. If you can be sure that at no time during your
restore process is there any chance of anything on the original disc
being run, then you're probably OK.
2. Most restore processes, at least on the default settings, will just
overwrite what they need to to restore the image. The remaining parts of
the disc surface - which would now be considered free available space -
might still contain (the remains of) infected files. Normally, this
would not be a problem: most of the time, those parts of the surface
would not be accessed except to write over them anyway. I suppose some
badly-written software [including the OS (-:] might allocate sections of
disc (e. g. for use as buffers [including page file and similar?]), not
use it all, and subsequently save those buffers - including the
non-overwritten infected bits. However, I think this is unlikely; I
posit this just as a way infected code _could_ survive both a restore
and subsequent use. Such code would _still_ be safe unless executed,
which if it's only part of a video buffer or similar is unlikely.
Hopefully, ransomware is so rare that, for a lot of people, it might
happen at a time when - or server as a trigger for - they decide to,
say, get a bigger disk anyway.
Has anyone _here_ had ransomware? (I know we're far from a
representative sample, but still, out of curiosity. Perhaps some of
those here who support others have at least encountered it.)
Thanks John. Paul said much the same, just more detail. I appreciate
the reply. As I said, a lot of knowledgeable folks here.

Paul
2018-03-11 16:24:38 UTC
Permalink
Raw Message
Post by jetjock
Is it really necessary to restore to a new disk? Does the restore not
write over everything on the original disk?
Actually, no it doesn't.

VSS based restores, only write to the specific areas of the
disk needing the clusters put back. Say for example, my "test.txt"
file used two 4KB clusters (a total of sixteen 512byte sectors).
My file was fragmented, so the clusters weren't right next to each other.

The restore software puts back the two clusters and *doesn't touch*
the area between them. This is the so-called white space between
files or fragments.

<--cluster --> <-- cluster -->
<--- white space ---->
(this part is
not written on
restore and contains
random bytes from before)

Now, logically speaking, that white space is of no
consequence. It shouldn't be influencing anything. In theory.

However, if you backed up malware, and the malware relied on
something stored in the white space areas, it *might* make a
difference. This is particularly true up near the end of the
partition, where there is less than 8MB of "slack space" which
never gets written, so malware "like it up there".

*******

If you as the user, want to be in complete control, try this.

1) Boot your Windows installer DVD. There should be a recovery
option to open a Command Prompt. We're doing this step *before*
using the backup software to do a restore.

2) Use the diskpart program in the Command Prompt window

diskpart
list disk <=== the disks are numbered like in Disk Management
Use the disk total size as a hint as to which is which
sslect disk 2
clean all <=== this takes *hours*. No data on disk 2 will be
recoverable after this step. The entire drive
gets zeroed. No byte is untouched.
exit
(reboot)

3) On this reboot cycle, we use the emergency boot CD for the
backup/restore software, and restore the clusters to the disk.
Now, we have taken the time to define *every* sector on the disk.
Every sector has been written at least once.

The above method is appropriate for *whole disk* restores.
And not for other flavors.

Malware has plenty of tricks to put stuff back. But what you've done by
using the disk erasure step, is made sure that no "persistent" info could
be passed from one session to another. When the restored image is booted,
the malware will have to start whatever it was doing from scratch. Which,
of course, is very easy for it to do.

It's only for cases where you feel the persistent information is
potentially important, that full erasure like this is of value.
If there is info you absolutely don't want people to find
(like some "erased" file), these extra steps are worth it.
Photorec or Recuva won't be able to find *any* erased files
after doing these steps. The backup software only backs up
the "visible" files. Erased files are ignored. Their clusters
are not recorded.

HTH,
Paul
jetjock
2018-03-11 19:59:39 UTC
Permalink
Raw Message
Post by Paul
Post by jetjock
Is it really necessary to restore to a new disk? Does the restore not
write over everything on the original disk?
Actually, no it doesn't.
VSS based restores, only write to the specific areas of the
disk needing the clusters put back. Say for example, my "test.txt"
file used two 4KB clusters (a total of sixteen 512byte sectors).
My file was fragmented, so the clusters weren't right next to each other.
The restore software puts back the two clusters and *doesn't touch*
the area between them. This is the so-called white space between
files or fragments.
<--cluster --> <-- cluster -->
<--- white space ---->
(this part is
not written on
restore and contains
random bytes from before)
Now, logically speaking, that white space is of no
consequence. It shouldn't be influencing anything. In theory.
However, if you backed up malware, and the malware relied on
something stored in the white space areas, it *might* make a
difference. This is particularly true up near the end of the
partition, where there is less than 8MB of "slack space" which
never gets written, so malware "like it up there".
*******
If you as the user, want to be in complete control, try this.
1) Boot your Windows installer DVD. There should be a recovery
option to open a Command Prompt. We're doing this step *before*
using the backup software to do a restore.
2) Use the diskpart program in the Command Prompt window
diskpart
list disk <=== the disks are numbered like in Disk Management
Use the disk total size as a hint as to which is which
sslect disk 2
clean all <=== this takes *hours*. No data on disk 2 will be
recoverable after this step. The entire drive
gets zeroed. No byte is untouched.
exit
(reboot)
3) On this reboot cycle, we use the emergency boot CD for the
backup/restore software, and restore the clusters to the disk.
Now, we have taken the time to define *every* sector on the disk.
Every sector has been written at least once.
The above method is appropriate for *whole disk* restores.
And not for other flavors.
Malware has plenty of tricks to put stuff back. But what you've done by
using the disk erasure step, is made sure that no "persistent" info could
be passed from one session to another. When the restored image is booted,
the malware will have to start whatever it was doing from scratch. Which,
of course, is very easy for it to do.
It's only for cases where you feel the persistent information is
potentially important, that full erasure like this is of value.
If there is info you absolutely don't want people to find
(like some "erased" file), these extra steps are worth it.
Photorec or Recuva won't be able to find *any* erased files
after doing these steps. The backup software only backs up
the "visible" files. Erased files are ignored. Their clusters
are not recorded.
HTH,
Paul
I knew you would jump in eventually! (GBG)

Thanks for all the info. I plan to save it for the unlikely event it
is ever needed. I'm very careful about where or when I "click", but
one can never say never! It is truly amazing the amount of knowledge
available from the members of this group.
Mayayana
2018-03-11 00:57:00 UTC
Permalink
Raw Message
"KenW" <kenw@ noplace.com> wrote

| I got nailed by a zip file. It was very very close to a file I was
| looking for.

I regularly receive rigged ZIP files in email. I've
forgotten exactly how they're made. I think it's
actually some kind of EXE that's been distorted
to make a vulnerable program run malware when
it's opened. But I don't know what the bug(s) is
that they're targetting.
jetjock
2018-03-11 15:39:28 UTC
Permalink
Raw Message
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
2. If Carrie would have had a backup image of her drive, which, since
she is supposedly a hotshot CIA agent, she most likely would have had,
would just recovering the backup have solved her problem? If not, why?
In all that has been written about the scourge of ransomware, I have
never read anything that would answer these questions. Would be nice
info to have.
I figured this would be right up Paul's alley, but I guess not.
Thanks to all for the info. So far, (almost) everyone has confirmed
what I thought to be true.
Paul
2018-03-11 16:46:48 UTC
Permalink
Raw Message
Post by jetjock
Post by jetjock
I watched "Homeland" the other day--the one where Carrie picks up
Ransomware by clicking on a .jpg file. Started me thinking which led
1. I didn't think a .jpg file could be infected. Don't know where that
idea came from, but I seem to remember reading it quite some time ago.
Can they be the vector for such a program (Ransomware), or could the
ransomware file just be named as a .jpg.
2. If Carrie would have had a backup image of her drive, which, since
she is supposedly a hotshot CIA agent, she most likely would have had,
would just recovering the backup have solved her problem? If not, why?
In all that has been written about the scourge of ransomware, I have
never read anything that would answer these questions. Would be nice
info to have.
I figured this would be right up Paul's alley, but I guess not.
Thanks to all for the info. So far, (almost) everyone has confirmed
what I thought to be true.
A .jpg, a .tif, and a .png can be infected. We had a good scare
about this, a long time ago.

It takes older versions of libjpeg to be vulnerable though.
I don't remember all the history, but for some reason
Microsoft gdiplus was also involved.

Older software didn't do good bounds checking. There were
actually languages with built-in bounds checks, but they
weren't involved. With the C language, you can fall off
the end of an array as easy as can be.

And one of the crimes committed, was the lack of "software review"
for FOSS libraries. Many commercial companies re-used the libraries
on the assumption that "one of my competitors has already reviewed
this library and given the developers shit for their bad practices".
When in fact, nobody had reviewed the software. Shock and long
faces all around, when they later find out what is inside.
"You mean Apple didn't review this? I thought Apple used this."

Some software is not properly reviewed, because no third-parties
can actually read the source and make sense of it. And this is why
such a library got rewritten a couple of times. One company
felt it was in their best interest, to write their own version. As
Ripley would say "nuke it from space, to be sure" :-) That
was software that involved crypto, and the code was
uncommented. While people could spot stack smashing attacks
on something like that (i.e. spot the occasional bad programming
practice), they couldn't spot the logical errors in the code.

And there are some software we never get right, because
the spec was so poorly written. Try and find two implementations
of the AVI2 software, that do exactly the same thing. No amount
of review helps with that problem, because every reviewer looks
at the spec, and the spec isn't precise enough to make comments
possible. "It could be this way, or it could be that way, and
according to the spec, both are OK." When you play your AVI2
video, maybe the shuttle controls don't work right, and you
can't move backwards and forwards in the movie without problems.
Maybe you move backwards once, and when you push play, there is no
sound. You can thank a rushed spec for some of these issues.
Reviewing the code won't help. Recognizing the spec needs to
be fixed is fine, but *nobody owns the standard for it* :-)

*******

Ransomware is the "payload". It's the bad thing delivered by
any available exploit.

In fact, for ransomware, the preferred method is to just
put a fake invoice as an attachment to an email. If you're
a guy who does a lot of business, gets a lot of invoices
delivered to a certain email box, you probably just
double-click the attachments like there is no tomorrow.
All they have to do, is make the filename invoice.pdf.exe
(you glance at it and see the invoice.pdf part),
and you click, and kaboom, your disk is encrypted and a
red banner says "we'd like 0.3 bitcoins please, sent
to this address". One of the people in my other groups
had this happen, and that's exactly how they did it.
It was a "GoDaddy invoice" attachment, a fake one. Never
be in too much of a rush to click shit in your email client :-/
Detach the attachment. Scan it. Examine it under a microscope.
Let your dog sniff it. Did your dog growl ?

https://en.wikipedia.org/wiki/Godaddy

Paul
Loading...