hey, we need to check that your connection works, torrent this file and md5 it

http://services.2014.shallweplayaga.me/hackertool.torrent_fe3b8b75e9639d35e8ac1d9809726ee2

The torrent file when loaded into Vuze showed that the file name was every_ip_address.txt. So I downloaded some of the file and observed the format. The format of the file was “0.0.0.1\n0.0.0.2\n…. “.

So I wrote a quick python script to calculate the md5:

#!/bin/python
import hashlib
m = hashlib.md5()
fsize = 0
a = ''
for i in xrange(256):
    for j in xrange(256):
        for k in xrange(256):
            for l in xrange(256):
                a = str(i)+'.'+str(j)+'.'+str(k)+'.'+str(l)+'\n'
                fsize += len(a)
                m.update( a )
print m.hexdigest()

The flag was “1a97f624cc74e4944350c04f5ae1fe8d”.

I’ve often tried to use MS Word tables and do computations with the values in the tables. Example:

Suppose, the following conditions hold true:
c1 = a1xb1
c2 = a2xb2
a3 = a1 + a2
b3 = b1 + b2
c3 = c2 + c2

Click on the c1 cell, click on the “Layout” button, click on “Formula” button, in the Formula field, enter the following:
=PRODUCT(a1:b1)
Similarly, for c2 use =PRODUCT(a2:b2).
For a3,b3,c3 use =SUM(ABOVE)

Finally, the CSCI 599 course on Search Engines concluded. The presentation went off pretty well.
The worst part was that an effort of 5 straight days went down the drain trying to go through the Nutch code. I think the Nutch developer community needs to get a little more matured and help newbies like me else new people would not join the movement! Eventually, I had to make my own focused crawler, query interface web data crawled and query interface.
I also got my CSCi558L scores which were ok…94,99,100 so things look ok so far but now the main effort is just starting off to get the Worm fingerprinting with ITrace going. Let’s hope things turn off well.

Come end of semester and the project deadlines start impending! The situation I am in is one of great thrill and rush! For the CS558L I’m doing this project in which I have to implement an automated worm fingerprinting mechanism but not only that combining it with ITrace I want to make Worm attacks and DDoS attacks a thing of past!
The scheme in plain English is to detect automatically if your network is being attacked by looking at the traffic and if so communicate this information to whoever you are forwarding this packet to! The ICMP messages that will be forwarded will carry information about who sent this traffic and other such information (including the signature of attack traffic). The receiver with all this information could gather the source of attacks. If all the routers followed this scheme then we will be able to reconstruct the entire path of the attack so the entry point of the attack could also be sealed….(hopefully leading to a Worm and DDoS attack-free internet)!!!
Really hopeful…aren’t I??? 😉
But again this technique has the same single flaw as the other techniques in that it needs co-operation between ISPs.
I am currently coding this scheme in the Linux Kernel 2.6.11.7 and this is my first tryst with linux kernel programming…let’s see what future holds for me!

Cisco ASDM is quirky in the sense that if the right Java version is not found it will just puke with errors that make no sense. This is what my java log looks like:
Application Logging Started at Fri Aug 01 11:01:11 EDT 2010
---------------------------------------------
Local Launcher Version = 1.5.41
Local Launcher Version Display = 1.5(41)
Cannot read profile file C:\Documents and Settings\abcdef\.asdm\data\deviceinfo.conf.
OK button clicked
Trying for ASDM Version file; url = https://www.example.com/admin/
Server Version = 6.2(1)
Server Launcher Version = 1.5.41, size = 476672 bytes
Launcher version checking is successful.
invoking SGZ Loader..
Cache location = C:/Documents and Settings/abcdef/.asdm/cache
Exception in thread "SGZ Loader: launchSgzApplet" java.lang.NoSuchFieldError: b
at dac.setLevel(dac.java:65)
at dac.(dac.java:44)
at gd.(gd.java:78)
at f5.a(f5.java:117)
at com.cisco.dmcommon.util.DMCommonEnv.(DMCommonEnv.java:38)
at com.cisco.pdm.PDMApplet.updateProgress(PDMApplet.java:300)
at com.cisco.pdm.PDMApplet.init(PDMApplet.java:63)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:409)
It happens because the ASDM launcher is not capable of running on newer JVMs. Since I had older JVMs, I went into Control Panel -> Java. Click on the Java tab, followed by clicking the “view” button. This will show you the current JVM being used. If you have older JVMs click on Find (you will have to select the folder where you suspect older JVMs to be…which in my case was c:\Program Files). If you don’t find an older JVM then just install an older version and it will work.

Yesterday the whole day was spent in trying to go through the Nutch source code. Chris and Ashish helped me out alongwith this link
Dissecting the Nutch Crawler. This showed me that :
The file Fetcher.java has a reference to the “content” variable (which is of type Content). I found that initially only the URLs are stored during the crawl, then a request is sent. Then based on the MIME type of the content returned, the ParserFactory class creates a parser (html parser, pdf parser etc.). The code for these parsers can be found at nutch-0.6/src/plugin/. These plugins do the parsing and get the content as a “Parse” object. Using the Parse.getText() method (which we also felt was interesting) we can get the text content of any page!!!!!

On April 15, 2015 the PCI SSC released the PCI DSS v3.1.  The main cause for concern for most merchants and other entities (called “entities” hereonforth) that store, transmit and process cardholder data is the prohibition of using SSL and “Early TLS”.  The PCI SSC also released a supplement to assist entities in mitigating the issue.   The supplement references the NIST guideline SP800-52 rev1 for determining which are good ciphers and which are not.

The key point being what does “Early TLS” mean?  Does it mean TLSv1.0 and TLSv1.1 OR does it mean only TLSv1.0?  Are the entities supposed to disable all ciphers except anything that’s TLSv1.2?

Answer is (in consultant speak) “it depends”. 🙂

TLSv1.1 does theoretically have ciphers that are not ideal.  Example: CBC mode ciphers that are TLSv1.1 but there may be a potential for attacks on them given that in the past couple of years CBC has fallen multiple times (BEAST, POODLE).

Google Chrome lists the use of CBC-based ciphers (despite the fact that they’re TLSv1.1) to be obsolete.  Google Chrome essentially makes “obsolete cryptography” a function of using TLS v1.2-based ciphers.

Firefox allows the configuration of disabling TLSv1.0 and that can be done by typing “about:config” in the address bar.  The security.tls.version.min = 0 (means SSLv3), 1 (means TLSv1.0), 2 (means TLSv1.1) and 3 (means TLSv1.2).  The following screenshot shows the configuration snapshot (here the lowest allowed version is TLSv1.0).

Let’s start with what is definitely ok for PCI:

https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites

 TLS_RSA_WITH_NULL_SHA256                  NULL-SHA256
 TLS_RSA_WITH_AES_128_CBC_SHA256           AES128-SHA256
 TLS_RSA_WITH_AES_256_CBC_SHA256           AES256-SHA256
 TLS_RSA_WITH_AES_128_GCM_SHA256           AES128-GCM-SHA256
 TLS_RSA_WITH_AES_256_GCM_SHA384           AES256-GCM-SHA384

 TLS_DH_RSA_WITH_AES_128_CBC_SHA256        DH-RSA-AES128-SHA256
 TLS_DH_RSA_WITH_AES_256_CBC_SHA256        DH-RSA-AES256-SHA256
 TLS_DH_RSA_WITH_AES_128_GCM_SHA256        DH-RSA-AES128-GCM-SHA256
 TLS_DH_RSA_WITH_AES_256_GCM_SHA384        DH-RSA-AES256-GCM-SHA384

 TLS_DH_DSS_WITH_AES_128_CBC_SHA256        DH-DSS-AES128-SHA256
 TLS_DH_DSS_WITH_AES_256_CBC_SHA256        DH-DSS-AES256-SHA256
 TLS_DH_DSS_WITH_AES_128_GCM_SHA256        DH-DSS-AES128-GCM-SHA256
 TLS_DH_DSS_WITH_AES_256_GCM_SHA384        DH-DSS-AES256-GCM-SHA384

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256       DHE-RSA-AES128-SHA256
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256       DHE-RSA-AES256-SHA256
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256       DHE-RSA-AES128-GCM-SHA256
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384       DHE-RSA-AES256-GCM-SHA384

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256       DHE-DSS-AES128-SHA256
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256       DHE-DSS-AES256-SHA256
 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256       DHE-DSS-AES128-GCM-SHA256
 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384       DHE-DSS-AES256-GCM-SHA384

 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256      ECDH-RSA-AES128-SHA256
 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384      ECDH-RSA-AES256-SHA384
 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256      ECDH-RSA-AES128-GCM-SHA256
 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384      ECDH-RSA-AES256-GCM-SHA384

 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    ECDH-ECDSA-AES128-SHA256
 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    ECDH-ECDSA-AES256-SHA384
 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    ECDH-ECDSA-AES128-GCM-SHA256
 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    ECDH-ECDSA-AES256-GCM-SHA384

 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256     ECDHE-RSA-AES128-SHA256
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384     ECDHE-RSA-AES256-SHA384
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     ECDHE-RSA-AES128-GCM-SHA256
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     ECDHE-RSA-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   ECDHE-ECDSA-AES128-SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   ECDHE-ECDSA-AES256-SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   ECDHE-ECDSA-AES128-GCM-SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   ECDHE-ECDSA-AES256-GCM-SHA384

 TLS_DH_anon_WITH_AES_128_CBC_SHA256       ADH-AES128-SHA256
 TLS_DH_anon_WITH_AES_256_CBC_SHA256       ADH-AES256-SHA256
 TLS_DH_anon_WITH_AES_128_GCM_SHA256       ADH-AES128-GCM-SHA256
 TLS_DH_anon_WITH_AES_256_GCM_SHA384       ADH-AES256-GCM-SHA384

 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 ECDHE-ECDSA-CAMELLIA128-SHA256
 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 ECDHE-ECDSA-CAMELLIA256-SHA384
 TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256  ECDH-ECDSA-CAMELLIA128-SHA256
 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384  ECDH-ECDSA-CAMELLIA256-SHA384
 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256   ECDHE-RSA-CAMELLIA128-SHA256
 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384   ECDHE-RSA-CAMELLIA256-SHA384
 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256    ECDH-RSA-CAMELLIA128-SHA256
 TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384    ECDH-RSA-CAMELLIA256-SHA384

Now let’s see what may potentially be good from TLSv1.1 perspective (from NIST SP8000-52 rev1):

TLS_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA
TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA

Here’s a problem though per OpenSSL man page:

If you’re using OpenSSL, how do you ensure that the browser is not negotiating the vulnerable TLSv1.0 ciphers? The only real answer seems to be by providing a cipher order for negotiation and hoping the client doesn’t cheat.  Most likely, the browser will negotiate a better cipher when it exists in the server and on the client and you’d avert the possibility of negotiation of a bad cipher.

According to experts, anything that uses CBC is inherently broken.  But disabling TLSv1.0 may make the server inaccessible to various older Android devices.  Also, if you’re using older Java Development Kits (JDK7 and below), do remember that the default ciphers may not hit the spot for PCI.

There’s an excellent site to help you configure each type of the server so you could become PCI compliant. This is an excellent site by Ivan Ristic to test your Internet-facing servers for configuration of SSL/TLS encryption.

In conclusion, configure browsers to minimally allow TLSv1.1 and configure servers to use TLSv1.2 to be PCI DSS compliant.  The road to TLSv1.1 compatibility and PCI DSS is filled with potholes and death-falls so do it at your own risk.