Information Security News
Microsoft may phase out support for TLS certificates that use the SHA-1 hashing algorithm as early as June 2016. The decision comes in the wake of recent calculations that suggest generating collisions is quicker and cheaper than previously anticipated.
SHA-1 is a hash algorithm, used to derive a 160-bit value from an arbitrary input. Its intent is for collisions—different inputs that hash to the same 160-bit value—to be hard to generate. As compute power has steadily grown over the years, it becomes quicker and cheaper to generate collisions. It was previously projected by Bruce Schneier, based on the observed growth of compute power, that creating SHA-1 collisions would be within reach of criminals by 2018 at a cost of about $173,000. On this basis, Microsoft intended to cease supporting the use of new SSL/TLS certificates using SHA-1 on January 1, 2016 and all SHA-1 SSL/TLS certificates on January 1, 2017.
The new cost and performance estimates, however, suggest that the cost is both drastically lower—$75,000 to $120,000—and that the compute resources are immediately available through cloud services such as Amazon EC2. This has given browser vendors little option but to reconsider the previous 2017 timetable for retiring support of SHA-1.
by Sean Gallagher
What's the cost of giving up customers' information because of weak information security practices? For Cox Communications, the answer is a half-million dollar fine and having the Federal Communications Commission watching its every information security move for the next seven years. The FCC's Enforcement Bureau and cable and broadband Internet provider Cox Communications have reached a settlement over an August 2014 data breach involving a member of the Lizard Squad hacking group. The FCC announced the settlement on Thursday.
The hacker, who goes by the nom de guerre "EvilJordie," used one of the oldest social engineering tricks in the book to gain access to Cox's internal data: he convinced a Cox customer service representative and a Cox contractor over the phone that he was a system administrator in Cox's IT department and sent them a "phishing" link to a malicious website that mimicked a corporate intranet site, where they entered their login credentials
The Apache webserver has a very modular logging system. It is possible to customize what to log and how. But it lacks in logging data submitted to the server via POST HTTP requests. Recently, I had to investigate suspicious HTTP traffic and one of the requirements was to analyze POST data. If you already have a solution which performs full packet capture, youre lucky but it could quickly become a pain to search for information across gigabytes of PCAP files. In the past, ngrep (network grep">#ngrep-d eth1-q -s 0 -O /tmp/wordpress.pcap POST /wp-login.php port 80
This command will capture all Wordpress login attempts and write packets to a PCAP file. We have now only useful data but, here again, processing them remains a pain. Hlas, sniffing packets is not relevant against HTTPS traffic!
So,I searched for an alternative and decided to use the combination of mod_security and ELK.mod_security being available">SecAuditLogPartsABCIJDEFHZ
SecRuleREQUEST_METHOD POST id:1000,phase:2,ctl:auditEngine=On,nolog,pass
The first directive specify which sections will be logged. In our case, the most important if the C which contains the request body). Once done, restart Apache and check the log for new events.">Here is a typical rv:23.0) Gecko/20100101 Firefox/23.0
Thecombination mod_security/ELKwill help you:
WARNING: mod_security is an Apache module and has access to all data in clear text. Keep in mind that HTTP POST requestscould contain sensitive information (passwords, IDs, CC number, SSN, etc). You can sanitize sensitivedata directly within mod_security via the sanitseArg directive.
ISC Handler - Freelance Security Consultant