by Javantea
May 24, 2008
It seems like automatically generated steganographic-quality images are going to be a regular feature since everyone likes them so well. Today I'll just focus on the algorithm and why it works.
I started with a very non-random image used as an initial seed.
I added another very non-random image for another seed.
I added a fairly random cross hatch image as another initial seed, still not nearly good enough for steganography.
I added a very random hurl (seed 4262833791, 60% random, repeat 11) for an even random seed, almost good enough for steganography, but not good enough for plausible deniability.
Together, this is what they look like:
I then did a gaussian blur radius 50 twice and a sharpen 99:
This is the style that most people recognize as being my style.
I can then change the levels to fit my color and sharpness requirements and did a final blur to ensure the histogram is flatter:
At this point, the image is finished. Why does it work? First of all, a requirement of a steganography-quality image is random seed as seen in picture 4. A random seed alone is not good enough for plausible deniability because no one sends a picture with simple noise (unless they're talking about noise like I am now). The other seeds I added give the picture a very pronounced human texture. This helps with plausible deniability, randomness, and coverage. Adjusting the colors makes the image very pronounced so that a person can claim plausible deniability. This is a valid steganography algorithm because it adds human input, random data, blur, another non-trivial algorithm (sharpen), and a flat histogram with only a few spikes. The important parts of steganography are: anti-brute force, anti-reverse, flat histogram, plausible deniability, and easy generation. This image fits all requirements easily.
Read more »
jvoss@altsci.com
jvoss@myuw.net
April 18, 2008
AltSci IAX2 0.7
[sig]
AltSci IAX2 0.6
[sig]
UPDATE May 24, 2008
I have done a mildly thorough investigation of 1.4.19.1 (the fixed version) and I understand their solution (verify a pseudo-random call number). The solution is as good as I recommended. It does not solve the non-spoofed DoS attack since the attacker can use the call number it receives from the accept packet, but it does make the spoofed DoS attack much less useful (1:5 amplification is practically worthless). I consider this grevious security bug to be fixed. I have not tested backwards compatibility of devices and software versions. I plan to test whether this can be recreated via uncommon use cases such as psuedorandom guessing, sending random commands, etc. I hope that Asterisk will accept my apologies for releasing the exploit before they had a chance to respond. I plan to disclose all future vulnerabilities full disclosure after a timely opportunity for the vendor to respond. I encourage all other security researchers who use my tools to release the vulnerabilities that they find in a similar manner for the benefit of the community.
UPDATE April 24, 2008
Asterisk has responded to the release of my second exploit and framework with a set of patches to SVN. They have made the bug report above publicly available which pleases me. I haven't tested this to make sure that it isn't vulnerable, but I can assure you that I will. I will also spend time to see if their patch is backwards compatible with other versions of Asterisk and soft phones. I applaud Asterisk for their work toward fixing this obvious flaw. Together I believe that we can write and test a good VoIP protocol.
I am a hacker, a self-employed programmer, an open-source advocate, a scientist, and an independent security researcher.
Read more »