amjo324 · HackerTrans

vor 10 Jahrendiscuss

The truth is that when reputable information security specialists are engaged to perform a no holds barred internal network penetration test or red teaming exercise for a client, they will gain full administrative access of the network in more than 9 out of 10 cases. There are well known and documented techniques for escalating privileges and traversing through a network. This is just the reality if you operate a typical Windows corporate network of a sufficient size.

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).

amjo324

vor 10 Jahrendiscuss

Although not a good read (in terms of being engaging or interesting), you'll find that a lot of security professionals will use something like the Center for Internet Security (CIS) benchmark when doing a formal audit or configuration review of RHEL (or any major Linux distribution for that matter). They will run a command line tool that will check the system's config against every item in the benchmark. The tool will generate a report with pass/fail outcomes for each item plus hardening advice. It's not perfect but it can be a decent starting point before you do further manual analysis of your system.

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...

amjo324

vor 10 Jahrendiscuss

Great idea for a project. Nice job.

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...

amjo324

vor 10 Jahrendiscuss

"NoSQL, or rather NoAuthentication, has been a huge gift to the hacker community. Just when I was worried that they'd finally patched all of the authentication bypass bugs in MySQL, new databases came into style that lack authentication by design"

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

amjo324

vor 10 Jahrendiscuss

"We are currently utilizing advanced protocols including double salted hashes"

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...

amjo324

vor 10 Jahrendiscuss

When an application residing at one.example.com sets a cookie, the browser by default resubmits the cookie in all subsequent requests to one.example.com and also to any subdomains, such as sub.one.example.com. It does not submit the cookie to any other domains, including the parent domain (example.com) and any other subdomains of the parent, such as two.example.com.

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).

amjo324

vor 10 Jahrendiscuss

Sure. But it would be a stretch to find any financial institution with as many as 360 million customer records. Maybe one of the state-owned commercial banks in China being the exception.

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.

amjo324

vor 10 Jahrendiscuss

"The passwords are stored as SHA1 hashes of the first 10 characters of the password converted to lowercase. That's right, truncated and case insensitive passwords stored without a salt"

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.

amjo324

vor 10 Jahrendiscuss

This is one of those cases where it's the responsibility of the bug bounty platform operator (HackerOne) to ensure that its customer (PornHub) deals appropriately with bug bounty participants. If PornHub doesn't offer a clear scope and fair reward for effort, penetration testers may be disillusioned with the HackerOne brand also and choose not to partake in other bug bounty programs it oversees. And of course the platform cannot thrive without a large number of skilled and active testers.

amjo324

vor 10 Jahrendiscuss

A similar anti-CSRF measure is implemented in some application frameworks by default. For example, When performing XHR requests in AngularJS, "the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain could read the cookie, your server can be assured that the XHR came from JavaScript running on your domain. The header will not be set for cross-domain requests."

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.

amjo324

vor 10 Jahrendiscuss

I'm a few chapters into Silence on the Wire and enjoying it. Zalewski is brilliant. It's very theoretical however. I'd only recommend it if your motive for reading it is pure interest rather than a desire to pick up practical skills that are immediately actionable.

amjo324

vor 10 Jahrendiscuss

Agreed. However, in a formal penetration testing engagement, the tester will usually only record and document their exact steps because they have to provide a detailed report to their client. This hacker didn't have that same obligation. I'm speculating that he is probably a habitual note taker. In this way, if he ever comes across similar challenges when attacking a new target, he has his notes to refer to.

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.

amjo324

vor 10 Jahrendiscuss

Bcrypt has built-in salts to prevent rainbow (i.e. lookup) table attacks. More to the point, modern password cracking doesn't usually involve the use of rainbow tables anyway. GPU speed has improved at such a rate that it's actually more practical to just compute all possible hashes from plaintexts (in a word list) to find a match rather than performing a lookup against a rainbow table that might have to be terabytes in size to be useful.

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.

amjo324

vor 10 Jahrendiscuss

"The rationale was that as technology progressed and password cracking became easier, users could be contacted to update their password."

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.

amjo324

vor 10 Jahrendiscuss

I say use secure templating because you need highly contextual encoding. As this article points out, escapes for HTML will not work in Javascript

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.

amjo324

vor 10 Jahrendiscuss

I can't live without vimperator nowadays. It's the only thing stopping me from switching to Chrome from FF (and yes, i know there are other similar vi extensions for Chrome but none seem as good as vimperator for FF).

amjo324

vor 11 Jahrendiscuss

As per my other comment below, the intended use case for SQLmap is more around exploitation rather than identifying injection points. Penetration testers will usually identify the injectable parameters through other means (e.g. using purpose built security HTTP proxy software such as 'Burp Suite' and 'Zed Attack Proxy'). After they have confirmed the existence of SQLi, they will then feed the HTTP request and vulnerable parameter into SQLMap to automate exploitation (i.e. dump DB contents and hashes etc).

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.

amjo324

vor 11 Jahrendiscuss

In my opinion, this is not really SQLMaps intended use case. It's essentially an exploitation tool for penetration testers and doesn't provide a proper mechanism to just scan your app looking for SQL injection points. There are better tools for that (google 'Burp Suite') and if your app requires a high security level you should be engaging a full time infosec professional to manually assess it.

amjo324

vor 11 Jahrendiscuss

I've been doing penetration testing of web applications professionally for about 5 years now. The incidence of SQLi has definitely decreased over the years but I would estimate that we still identify it on approximately 1 of every 5 web apps that we test for our clients. Usually, the more obvious SQLi has been found and patched already years ago. An example of obvious SQLi is 'error based SQLi' where the application returns verbose error messages such as:

  "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"

As soon as we see an error message like this, we know we can dump the entire database in a matter of minutes.

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...

amjo324

vor 11 Jahrendiscuss

Yes, this class of web vulnerability is called Cross-Site Request Forgery or CSRF (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...). The Same Origin Policy (SOP) prevents one domain from receiving the HTTP responses for requests it sends to other domains. As you suggest however, the request itself can sometimes be enough to cause adverse side effects on the target server (that may be beneficial to an attacker).

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...).

comments