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 »
by Joel R. Voss aka. Javantea
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.
April 19-27, 2008
This program was written in a few days to solve the issue of watching network traffic in realtime. I split packets into groups of IP, TCP, UDP, and non-IP as well as in/out and update the screen every second. It shows packets per second, kilobits per second, and horizontal lines show how much data. The bars switch to yellow when the traffic increases over 1Mbps and to red when it increases over 5 Mbps.
