11–20 of 33 posts
I wonder why they use MD5 hashes and not something more collision attack resistant.
Because it would be very hard to find a collision of a file that behaves exactly like a ZipFile. To make a collision work, you would need to inject the payload into the program, and find a specific blob to put into the zip file, that once compressed and hashed would cause a collision. This isn't computationally efficient.
#!/bin/bash
echo ""
echo " FInstaller 1.0"
echo "-----------------------"
export TMPDIR=`mktemp -d /tmp/selfextract.XXXXXX`
ARCHIVE=`awk '/^__ARCHIVE_BELOW__/ {print NR + 1; exit 0; }' $0`
echo ""
echo "Extracting Installation Files..."
echo ""
tail -n+$ARCHIVE $0 | tar xzv -C $TMPDIR
echo ""
echo "Launching Installer..."
echo ""
CDIR=`pwd`
echo CDIR
echo $CDIR
echo TMPDIR
echo $TMPDIR
cd $TMPDIR
./installer
cd $CDIR
rm -rf $TMPDIR
exit 0
__ARCHIVE_BELOW
That ggi file is a self-extracting bash script. #!/bin/bash echo "" echo " FInstaller 1.0" echo "-----------------------" export TMPDIR=`mktemp -d /tmp/selfextract.XXXXXX` ARCHIVE=`awk '/^__ARCHIVE_BELOW__/ {print NR + 1; exit 0; }' $0` echo "" echo "Extracting Installation Files..." echo "" tail -n+$ARCHIVE $0 | tar xzv -C $TMPDIR echo "" echo "Launching Installer..." echo "" CDIR=`pwd` echo CDIR echo $CDIR echo TMP…
#!/bin/bash
TOP_INSTALL_DIR=/
echo "Stopping FFRelay"
monit stop ffrelay
sleep 3
killall -9 -q ffrelay
echo "Extracting Software Files..."
tar --directory $TOP_INSTALL_DIR -xvf ./*relay*.tar
echo ""
echo "Running Post-Installation Steps..."
SECONDS=1
MAX_SECONDS=10
while [ "$SECONDS" -lt "$MAX_SECONDS" ]
do
if [ -e "/var/run/ffrelay.pid" ]; then
sleep 1
else
SECONDS=$MAX_SECONDS
fi
done
echo "Starting FFRelay"
monit start ffrelay
echo ""
echo "FFRelay Installer done."
echo ""
I wonder why they use MD5 hashes and not something more collision attack resistant.
I can't think of a purpose where a collision of a non-malicious sample with a malicious file can be used by an attacker (let alone the same attacker). In addition, there are lots of historical threat data (tactical intelligence) that is based on md5sums. Newer tools support newer checksums, but will more than likely just increase the types of checksums supported, and not deprecate them.
Checksums are less and less useful when the malware can be configured, recompiled and re-assembled for a particular target. There are some good discussions on HN more fuzzy detection techniques that can't be evaded by changing inert parts of the payload, but that is orthogonal to using stronger checksums. Indicator of Compromise data including md5sums can be useful for general security, but because a determined attacker will mutate the files it is better suited to more commodity malware.
I wonder why they use MD5 hashes and not something more collision attack resistant.
Finding a collision in MD5 is costly, finding a collision in MD5 which is within -+10% of the actual size is extremely costly (technically possible, but maybe not in your lifetime).
As to the other reply "because it is zip something something" I disagree. Zip is an extremely good format for crafting fake files which match a checksum. Really any format which can take arbitrary metadata (which is MOST) is pretty easy.
I suspect the reason they use MD5 is because everywhere supports it and it is "good enough," particularly with file size. Plus the person downloading them knows the files are malware, so what could the security services do, inject an even more malware-malware that they then expect the user to run?! Seems dumb. You're likely more at risk from day to day applications installers which aren't digitally signed.
I wonder why they use MD5 hashes and not something more collision attack resistant.
Use SHA256, SHA-3 or MD6 (I like MD6, others may disagree. Disclaimer I worked on proving the differential resistance of MD6).
I wonder why they use MD5 hashes and not something more collision attack resistant.
Collisions aren't a major risk with MD5 when you also give someone the file size (even approximate). Finding a collision in MD5 is costly, finding a collision in MD5 which is within -+10% of the actual size is extremely costly (technically possible, but maybe not in your lifetime). As to the other reply "because it is zip something something" I disagree. Zip is an extremely good format for crafting fake files which m…
MD5 collisions with 10% of the size of the file can be found in seconds on a old laptop computer. I've done it, we assign it as HW in class.
Read this http://www.mathstat.dal.ca/~selinger/md5collision/
Notice that the two colliding exe are exactly the same file size. These attacks have only gotten better.
>Zip is an extremely good format for crafting fake files which match a checksum. Really any format which can take arbitrary metadata (which is MOST) is pretty easy.
The example I gave uses windows and linux executables. No zip files in sight. These attacks are from 2009.
I wonder why they use MD5 hashes and not something more collision attack resistant.
Collisions aren't a major risk with MD5 when you also give someone the file size (even approximate). Finding a collision in MD5 is costly, finding a collision in MD5 which is within -+10% of the actual size is extremely costly (technically possible, but maybe not in your lifetime). As to the other reply "because it is zip something something" I disagree. Zip is an extremely good format for crafting fake files which m…
Not at all; look up "md5coll" and "fastcoll", released nearly 10 years ago, could generate a pair of colliding blocks in under an hour. Testing them now on my machine (which is already a few years old) it generated them in under a second(!)
This has been used to create executables that behave differently but that's because they can inspect themselves; on the other hand I think generating two .zip files with the same hash but different (valid) contents would be rather more difficult, but it's probably still quite feasible today.