amjo324

In the past, companies mostly just accepted this risk and focused on protecting their network perimeter. Over time, this attitude has shifted and organisations now recognise the insider threat (e.g. a rogue employee/contractor or an external attacker who has already breached the perimeter).

More info about the CIS benchmarks: https://benchmarks.cisecurity.org/downloads/benchmarks/

The RHEL 7 benchmark: https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_E...

It says in the About section on the home page "Unless someone can intercept your local traffic and our traffic to a site, you'll be able to spot MITM attacks". I'd argue that this is not entirely true. If an attacker operating as a MITM can intercept all local traffic (e.g. via some form of DNS attack), they do not need to control the traffic from hash-archive.org to 3rd party sites. They simply need to control how hash-archive.org is presented to the victim. In theory, the attacker could serve up a bogus version of hash-archive.org that appears to be legitimate but is returning falsified hashes that match the malicious downloads they have intercepted elsewhere.

You might claim this is not possible because hash-archive.org runs over HTTPS so an attacker would also have to somehow generate a valid SSL certificate signed by a trusted CA. This is true but if someone types hash-archive.org into their browser URL bar, the initial request is made over HTTP. The legitimate hash-archive.org redirects the client to HTTPS seamlessly but a fraudulent hash-archive.org could just keep the victim on HTTP.

To provide some mitigation against this type of attack, you could do a couple things:

* Only allow hash-archive.org to be accessed over HTTPS (port 443). Close port 80. [EDIT: in fact, this doesn't really help all that much because the MITM can still try serve their bogus version of hash-archive.org over HTTP]

* Set the HTTP Strict Transport Security header (HSTS) [1]. After the first visit to the legitimate hash-archive.org, compliant browsers will only ever allow future visits to be made over HTTPS.

For good measure, you could also set up HTTP Public Key Pinning (HPKP). HPKP is a 'security feature that tells a web client to associate a specific cryptographic public key with a certain web server to prevent MITM attacks with forged certificates.' [2]

[1] https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_s...

[2] https://developer.mozilla.org/en/docs/Web/Security/Public_Ke...

https://ghostbin.com/paste/6kho7

Shudder. Whenever someone starts talking about double salting, triple salting or even just salting, it's usually a sign that they are doing password storage all wrong.

Salting only thwarts attacks against pre-computed lookup (i.e rainbow) tables and most attackers don't use rainbow tables nowadays to reverse hashes. Increases in GPU power have meant that it's more practical to just enumerate through all password permutations on-the-fly than do a lookup in an enormous file.

If a company is using a modern hashing algorithm purposefully designed for password storage (e.g. PBKDF2, bycrypt or scrypt), they need not even consider salts because they are automatically incorporated into the algorithm and are transparent to the implementor.

In my opinion, the best article describing the current state of play with respect to password storage is the following:

https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

A server can override this default behavior by including a domain attribute in the Set-cookie instruction but this is pretty uncommon. Cookie scoping (and therefore cross-domain protection) can be managed differently if the default behaviour is not intended and HTTPOnly is not relevant here. HTTPOnly is really only a simple mitigation against the most obvious and trivial Cross-Site Scripting (XSS) exploitation technique (i.e stealing a session token).

And more to the point, the corresponding email addresses and/or usernames in the MySpace breach are leaked along with the password hashes. The same email address and password combinations will be tried on other web sites (e.g. Amazon, Facebook) with a reasonable chance of success. No brute force necessary.

I'm surprised this fact is not getting more attention. In theory, this means that a MySpace account with a password of Welcome1234567 could be logged into with a password attempt using any of the following examples:

* Welcome123

* welcome123

* WeLcOMe123456789

* welcome123anythingafterthe10thcharacterdoesntmatter

In essence, case sensitivity and the 11th character onward are completely ignored. This vastly reduces the total key space. To compound the problem, SHA-1 has been used which is not suitable for password storage (salted or otherwise) because it's an intentionally fast algorithm. This means an attacker can more efficiently run all permutations through the hash function to find a hash match and hence the password. In fact, as I've described above, the attacker doesn't even need to retrieve the exact password to gain access to the account. They just need an input that will produce an identical SHA-1 hash (i.e. an input containing the same first 10 (case insensitive) characters as the original password).

Based on the work I've done reversing password hashes in bulk (legitimately for clients in penetration testing engagements), I'd suggest that at least 80% of the reported ~360 million hashes could be reversed within a few days with access to the full data set and $5k worth of commodity GPU hardware. And you can guarantee that these passwords will be used in future attacks against other web sites because of how common password reuse is. Frightening.

Reference: https://docs.angularjs.org/api/ng/service/$http

This is an effective approach because unless an attacker has already compromised the relevant cookie, they will be unable to spoof the X-XSRF-TOKEN header in a cross-origin request. On the server-side, you just need to validate that (a) the X-XSRF-TOKEN header was sent and (b) it contains the expected value for each HTTP request received.

I was curious to read this piece to see how closely the approach, techniques and tools he uses compare to how penetration testers are formally trained in the info sec industry. For what it's worth, the methodology in terms of reconnaissance, privilege escalation and lateral movement within the network are typical. Also, most of the tool set he uses (e.g. mimikatz, responder, meterpreter, powersploit, psexec) are part of any good penetration tester's arsenal.

I'm not trying to down play the achievement though. He is clearly very skilled and knowledgeable. Of particular note, it seems that the initial intrusion was only possible because 'after about two weeks of reverse engineering, I discovered a remote root exploit' in an embedded system. He doesn't provide technical details of the exploit but finding a 0-day in an embedded system is usually far from child's play.

Essentially, if you ever find yourself having to think about manually creating and incorporating salts into your password hashing mechanism, it's a telltale sign that you are using an unsuitable password hashing algorithm to begin with. Instead, you should almost always be using bcrypt, scrypt or PBKDF2 as per current best practice.

I would argue that this a misguided motivation for storing the password entropy. Bcrypt is purposefully designed to combat the problem of more efficient brute-forcing due to future GPU/CPU speed improvements by incorporating a 'work factor'. At any time, application owners can specifically increase the work factor and the hashing process will be intentionally slowed further. In this way, the future reversibility of the password hashes can be reduced without requiring that users update their passwords.

I just wanted to reinforce this comment because I work in infosec (mostly web app security) and many of our clients make mistakes in this area. If you don't encode depending on context, you're going to have a bad time.

Most developers are aware of URL encoding and HTML encoding but then you also need to consider other encoding techniques for contexts such as JavaScript and CSS. As an example the single quote when:

URL encoded is %27

HTML encoded is '

JS encoded is \x27

CSS encoded is \000027

It gets way too difficult and cumbersome to manually write encoding code for all these different contexts and deal with the endless number of edge cases. Don’t go hunting for single quotes or angled brackets and then replace them what what you think it should be. Rather, you should rely on encoding libraries available in your framework. As an example, in .NET you can import the AntiXSS package and then you have a number of library functions such as CSSEncode(), HTMLEncode() and JavascriptEncode() at your disposal. Similar libraries exist for other major development frameworks.

I would say that SQLmap is normally effective at determining whether a HTTP parameter is injectable with a high degree of confidence. However, sometimes there will be Web Application Firewall (WAF) filters or unusual/inconsistent application behaviour on certain inputs which means it can't confirm whether the parameter is definitely vulnerable or not (less than 10% of the time in my experience). For the same reasons, often it won't be able to successfully automate the exploitation for you. On those occasions, we have to craft our queries manually to exfiltrate database contents and so forth.

  "You have an error in your SQL syntax; check the manual
  that corresponds to your MySQL server version for the
  right syntax to use near '\'' at line 1"

These days, we usually have to work a bit harder to find the more difficult to identify and exploit SQLi (e.g. boolean-based blind and time based) but the end result is the same once we do. SQLMap is a standard tool in a any good web app penetration tester's toolkit. It's not always going to work but when it does it automates away a lot of the grunt work. I applaud the SQLMap developers who seem to know SQL inside out and actively acknowledge feedback from the community.

For any devs, this is decent guide for preventing SQLi:

https://www.owasp.org/index.php/SQL_Injection_Prevention_Che...

It continues to be a common security issue among web applications and is why all sensitive actions should be protected with unique anti-CSRF tokens (most good development frameworks provide support for this).

If you need to relax SOP restrictions between sites you control, the modern and recommended way is via Cross Origin Resource Sharing or CORS (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...).