Skip to content

Full Disclosure Mailing List Shutting Down

Sadly, the last post on Full Disclosure mailing list was by John Cartwright stating that he is suspending the list indefinitely. He lists his reasons below:

Hi

When Len and I created the Full-Disclosure list way back in July 2002,
we knew that we’d have our fair share of legal troubles along the way.
We were right. To date we’ve had all sorts of requests to delete
things, requests not to delete things, and a variety of legal threats
both valid or otherwise. However, I always assumed that the turning
point would be a sweeping request for large-scale deletion of
information that some vendor or other had taken exception to.

I never imagined that request might come from a researcher within the
‘community’ itself (and I use that word loosely in modern times). But
today, having spent a fair amount of time dealing with complaints from
a particular individual (who shall remain nameless) I realised that
I’m done. The list has had its fair share of trolling, flooding,
furry porn, fake exploits and DoS attacks over the years, but none of
those things really affected the integrity of the list itself.
However, taking a virtual hatchet to the list archives on the whim of
an individual just doesn’t feel right. That ‘one of our own’ would
undermine the efforts of the last 12 years is really the straw that
broke the camel’s back.

I’m not willing to fight this fight any longer. It’s getting harder
to operate an open forum in today’s legal climate, let alone a
security-related one. There is no honour amongst hackers any more.
There is no real community. There is precious little skill. The
entire security game is becoming more and more regulated. This is all
a sign of things to come, and a reflection on the sad state of an
industry that should never have become an industry.

I’m suspending service indefinitely. Thanks for playing.

Cheers
- John

Ref: http://lists.grok.org.uk/

Lets hope this is just a haox, or maybe the list comes back in another shape or form.

Easy String Encryption With Bouncy Castle and Jasypt

At times you want a an easy and straightforward way to encrypt strings without the hassle of undocumented cryptographic libraries *cough* bouncy castle *cough*. This is where Jasypt comes in. It is a powerful encryption library that makes cryptography fun and easy! What makes Jasypt nice is that it can perform simple encryption using passwords very quickly. That is quickly in terms of development time.

Below is a simple example of using Jasypt to encrypt a string using BouncyCastle as the provider.

PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
encryptor.setProviderName("BC");
encryptor.setAlgorithm("PBEWITHSHA256AND256BITAES-CBC-BC");
encryptor.setPoolSize(4);
encryptor.setSaltGenerator(new RandomSaltGenerator());
encryptor.setKeyObtentionIterations(100000);
encryptor.setPasswordCharArray("BadAssPassword12345!".toCharArray());
		
String crypted = encryptor.encrypt("Hello World!");
System.out.println(crypted);
		
String plain = encryptor.decrypt(crypted);
System.out.println(plain);

The above code should work, but you will need to download Jasypt and BouncyCastle libraries and set them on your classpath.

The Legion of the Bouncy Castle – Listing Public Key Certifications

Instead of calling this post Part 6, I’ve decided to just give them nice and descriptive names from now on.

When managing your PGP Keys you often need to know who you trust and who you do not trust. All we need is the public key file (ASCII armored or binary). I have nested the operation in 3 different methods, mainly done for readability.

public void listPublicKeyCertifications() {
	String keysDir = System.getProperty("user.dir")+File.separator+"src/george/crypto/pgp/keys";
	File publicKeyFile = new File(keysDir+File.separator+"MrBilly.asc");
	
	try {
		System.out.println("The public key was certified by: ");	
		List<String> keyIds = listCertifications(publicKeyFile);
		for (String keyId : keyIds) {
			System.out.println("\t"+keyId);
		}
	}
	catch(Exception ex) {
		ex.printStackTrace();
	}
}

public static final List<String> listCertifications(File publicKeyFile) throws IOException {
	FileInputStream keyInputStream = new FileInputStream(publicKeyFile);
	List<String> keyIds = getCertifications(keyInputStream);
	return keyIds;
}

private static final List<String> getCertifications(InputStream input) throws IOException
{
	List<String> keyIds = new ArrayList<String>();
	
	PGPPublicKeyRing pgpPubRing = new PGPPublicKeyRing(PGPUtil.getDecoderStream(input), new JcaKeyFingerprintCalculator());
	PGPPublicKey pubKey = pgpPubRing.getPublicKey();
	
	@SuppressWarnings("unchecked")
	Iterator<PGPSignature> sigIter = pubKey.getSignatures();
	while(sigIter.hasNext()) {
		PGPSignature pgpSig = sigIter.next();
		long keyId = pgpSig.getKeyID();
		keyIds.add(Long.toHexString(keyId).toUpperCase());
	}
	
	return keyIds;
}

Read more…

PGP Cryptography With The Legion of the Bouncy Castle – Part 5

We’re back! Back to PGP Cryptography tutorials!! Because when I want to learn something new I learn faster by writing a tutorial about it, sharing code and receiving feedback.

So in Part 4 I apologized that I did not have a lot of time and just showed how to integrate Bouncy Castle with Android by using SpongyCastle. Now I will go through how to generate and verify detached signatures. This has become important since Part 2 did teach how to sign and verify files, but the signature was embedded inside the file. Though this works, it did not work when trying to verify the file using a regular program like GPG / Kleopatra. Also not all PGP clients support ZLIB compression which could break compatibility. So I decided that the need to generate detached signatures was important.

Continuing with the previous examples we have the PGPTools file which I wrote to make cryptography easier with BC (Full source can be found here). Generating a detached signature file needs the following:

  • The file you want to sign
  • The name of signature file that will be generated
  • The PGP Key ring that contains your secret and public keys

Another interesting thing to know to go by is the naming convention of these files. Most programs look for it and makes it easier for the user to utilize and for programs to find. Supposed there is a file called “TheFile.txt”, below is how the signature file would be named:

  • ASCII Armored Signature: TheFile.txt.asc
  • Binary Signature: TheFile.txt.sig

This is not mandatory, but a nice convention to follow.

Read more…

U.S. Nuke Silos Protected by Stupid All Zero Password

The tile of this post says it all.

Please visit For Nearly Two Decades the Nuclear Launch Code at all Minuteman Silos in the United States Was 00000000 for more details.

I just cannot be bothered to write more about it, I hope they change it. I hope the Russians didn’t do anything this stupid as well.

Alpha Networks Inc. Want to Backdoor Your Router

In recent news posted on the Dev ttyS0 blog that a spin-off company of D-Link called Alpha Networks Inc. has embedded a backdoor to various D-Link and Planex firmware.

The blog post titled “Reverse-Engineering a D-Link Backdoor” really does a great job showing the step-by-step process the author took find the back door. There are nice visual diagrams and code fragments too.

In a nut shell, the genius programmers at Alpha Networks Inc. wrote some programs or services that needed to change the routers settings remotely. Knowing that the HTTP server on the device could do this, they thought to re-use its functionality. Yeah, 1 step forward, but it needs a password to log in so they though to add a routine to by-pass the authentication check based on a static user-agent, 2 steps backwards or rather 100 steps backwards into a pit of stupidity.

It’s bad enough they got one or more programmers who thought of doing this, it is even worse when you see what the user-agent string is; here have a look:

xmlset_roodkcableoj28840ybtide

Now for the grand moment of where genius meets idiot, spell that backwards!

editby04882joelbackdoor_teslmx

Yeah, Thanks “Joel” and I bet 04882 must be your employee ID code or something else that might be personally or professionally related to you. Thanks for backdooring D-Link firmware. This was already found by Russian hackers in 2010, so who know how long this might have been exploited for.

*** Update ***
Posted buffer overflow exploit proof of concept code on devttys0.com check it out here

Follow

Get every new post delivered to your Inbox.