Port forwarding and port blocking security concerns

Let me make a few assumptions to try to simplify this:

You're talking about a home or SOHO network, and not an enterprise environment.
Your router performs Network Address Translation (NAT), hence the need for port forwarding.
You're interested in explicitly blocked traffic vs a lack of forwarding.

So let's compare what happens in each case.  For the case where you have explicitly told your router to drop incoming traffic on port 3389:

A TCP SYN packet comes in with destination IP set to your router and destination port 3389.
Your router consults pf/iptables/whatever vxworks uses and determines the packet should be dropped.
The packet is dropped, the router forgets about it, and no response is sent to the attacker.

For the case where you just have nothing forwarded:

A TCP SYN packet comes in with destination IP set to your router and destination port 3389.
Your router consults pf/iptables/whatever and finds no explicit direction to handle it. (Including no port forwarding!)
Your router consults its network state table, finds no matching connection (either established or "related"), so the packet does not need to be forwarded on via NAT.
Your router checks for a listening service on port 3389 itself.
Since 2/3/4 struck out, the router has no idea what this packet is supposed to do, so it sends a connection reset (TCP RST) back to the requesting host.

In either case, no TCP connection is actually established.  Some people believe that dropping packets is better because it "hides your presence" online.  I guess that's potentially true, but then you need to drop on every port and have no port forwarding.  Otherwise, it's clear to an attacker that your IP is alive.  Furthermore, most SOHO users should be most concerned about opportunistic attacks rather than targeted -- in that case, attackers will just be scanning large blocks of IPs looking for port 3389 open.  Dropping a packet or resetting makes little difference to this attacker.


How to verify my connection is not going through MITM proxy?

Of those three points you mentioned, none of them can be used to reliably detect a Man-in-the-Middle attack.

  Checking who issues the certificate and see if it is a self-signed one installed in my own root certificate store.

All of the root certificates are self-signed. That, and the fact that they are capable of being Certificate Authorities, is what makes them a root certificate.

What you can do, however, is compare your certificate store manually with a known good certificate store. Microsoft and Apple, for instance, publish which root certificates they trust by default. If your configuration varies inexplicably, it may be a sign of compromise.

Of course, in a company environment, your IT department is very likely to have their own CA, which they deployed on your machine. So check with them if you worry about a company computer being compromised.

  Checking if I am being served web content from a local IP instead of the outside server IP and if the local IP is always the same.

If you are in a home network, you don't get the content directly from the web server, but instead have it routed to you over many network nodes. Each one of those, theoretically, could change the source IP address.

Imagine your home router was compromised and would conduct a Man-in-the-Middle attack. They could, theoretically, just change the destination of your IP packets and have them end up at the attacker. Upon replying, the router could then mangle the packets back, making them look as if they came from the correct source.

Of course, this would be noticeable, since if you use HTTPS, the attacker will likely not have a valid certificate for the site, unless they also have installed a compromised root certificate on your machine.

  Checking if my system proxy settings are configured to localhost.

The system proxy settings are only relevant for applications that care about them. In fact, an application can simply decide not to use the system proxy settings. This is vital, because otherwise, proxies running on localhost would try to call themselves and end up in an endless loop.

Furthermore, a proxy configuration only instructs your computer to send all traffic to the proxy, expecting the proxy to take care of the responses. This is, in essence, the same job as a router. As such, if your traffic goes through a router, you can think of them as a "proxy" of sorts. Of course, that's not entirely true, but for the sake of brevity, it's close enough.

However, if you see a proxy configuration that you didn't put there, it can be a sign of compromise. It doesn't need to be to localhost, however.

  How can I detect a proxy if the above things look normal?

You probably can't. If you are completely certain that no strange root certificates have been installed, then you likely are not being attacked with a Man-in-the-Middle attack. Or at least, you would know about it, as long as you use HTTPS. For plaintext communication, you have no way of knowing at all.

  How can Avast use a Man-in-the-Middle Proxy to scan websites, even if I see no evidence of it?

A number of things may be possible:

Since you installed Avast, it may have installed a root certificate.
Since anti-virus software loves going really deep into the OS, it may have inserted a proxy system that every connection has to follow, even if not visible to the user.


Is it secure to make a publicly available Web App that has URL's generated from a hash?

Your scheme is moderately secure provided the random value is long enough and random enough, however it has a number of flaws:

Passing your authentication token in the URL means it'll be in HTTP server logs, browser history, etc. Data in these places is not usually stored in an especially secure way.
You have no way to revoke access (eg. if an employee leaves or if your system is compromised somehow)
There's no time limit to the validity of the tokens

Ideally you'd have some kind of global method to authenticate all users (eg. everyone registers an account on your system), but if you have nothing other than email addresses to authenticate with then I'd suggest the following:

The link emailed to the user is a link to an authentication page with the content/QA ID and user's email as parameters.
The authentication page generates a hash/signature containing the content/QA ID, the user's email, an expiry timestamp (expiring in say 30 minutes) and a unique ID which can only be accepted once (ie. nonce), and emails a new link with the hash/signature to the user
The user follows the second link in the new email containing the hash/signature and the parameters (expiry, content/QA ID, nonce and email) and the page checks the validity of the parameters before displaying the content.

Having to wait for an email containing a second link every time might be slightly annoying, but it has the following advantages over your scheme:

URLs in server logs / browser history won't be a security issue because they can only be used once thanks to the nonce.
When someone leaves the company their email can be invalidated, therefore their URLs won't be accepted any more
The expiry timestamp will ensure old unused links will be benign

I'd also recommend using JSON web tokens instead of rolling your own signature/hashing scheme.


Is it safe to connect an M.2 SATA SSD (via USB 3.0 adapter) from a hacked Windows computer to a Mac?

First check if any launch agents or daemons are enabled which may try to access the USB storage when detecting a new device is connected. Also, use using launchctl to view and disable any automatically run programs which may be accessing the USB storage.

Since there have been instance of cross-platform malaware (e.g. some of whom have used Java), its best to remain cautious.

I would recommend installing an anti-virus/anti-malaware temporarily on the mac for precaution, before connecting the drive.


Google/Github should be able to help you with this question.
The language a tool was written in only matter if you're looking at the source to extend/enhance/troubleshoot the tool and in that case the usefulness of haskell is increased for people that know haskell and decreased for people who don't know haskell
You can write exploits in any language, you don't even need programming at all to write exploits, in many cases a text/hex editor is all that is required.


The hard way of doing this is by implementing a PROXy. You may create just a socket to which you will connect and then create a socket to the destination server. You analyze the traffic of HTTP header and if it requests aaa.html you change request to the bbb.html or different domain.

The more sophisticated way of doing that would be for example using libpcap. You just listen on the interfaces and pass them or redirect them. The same thing you may accomplish with the firewall. All depends on the scenario you have.

But in general you want to have something like:

      --------        ----------------------------------          --------
-----| client |----> | your interface/process/something |------->|server|
      --------        ----------------------------------         -------

Please remember that you may get encrypted traffic. In that scenario, you need somehow to generate a trusted cert. In most cases, you have to somehow install your own CA in the client.

If you are controlling DNS server you also may just return different records to the different clients.

Those this answare your question?


Is it possible to determine the specific version of a website's web server?

There is no general way to reliably determine the exact server version from remote and it is not even possible to reliably get the more general type of server (i.e. apache, nginx, IIS ...).

While the server might include its version in the Server field of the response header or in error messages, this might be only the type of server and not the exact version. And even if there seem to be detailed information available they might not be true - it is not that unusual to provide fake information there is order to lead potential attackers to a false track.


A QR code is nothing more than an encoding of data.  URLs being encoded as QR codes are just one specific usage.  As you say, it suffers the same problems as URL-shorteners in that you might never actually know where it goes until it takes you there.  However, any decoder could provide a safe landing zone before allowing a browser to be launched.

Because the QR code can encode any data up to a specific maximum, the use of the QR code is only limited by the applications which scan them and make use of the data.  This allows a wide and blind attack area.  Furthermore, the decoder itself could have a variety of buffer overflows to exploit.


How does an offline CA revoke certificates?

A CA must indeed publish CRL regularly, and if the CA is offline, then human intervention is needed. Each CRL has an issuance date (thisUpdate) and a provisional date of next publication (nextUpdate) which everybody uses as an end-of-validity date for the CRL. The next CRL must be published before reaching the nextUpdate date of the current CRL; otherwise, verifiers will begin to reject the certificates.

Common practice is to have an offline root CA which issues relatively long-lived CRL (e.g. one CRL every three months, with a nextUpdate set to current time + 4 months). That root CA is used to issue only a single certificate, for an intermediate CA, which is online, and does the bulk of certificate issuance (and that intermediate CA publishes CRL much more regularly). The offline root CA is kept as a "last recourse": if the intermediate CA is compromised, then the root can revoke it, so there is a "bad period" to suffer (until the end of validity of the current root CRL, at most), but the root key distribution needs not be redone when the new (intermediate) CA is built and started.

A niftier method is to have a semi-offline root CA: the root CA is linked with the outer world through a physically one-way canal (I have done it with an audio cable: the "line out" jack on the server is inherently one-way, so no risk of intrusion coming up that cable). This allows the root to publish CRL often (e.g. one per week, even one per day) without needing human intervention. Actual revocation would still need physical intervention, so an intermediate CA as described above would still be highly recommended.

Note that an offline or semi-offline CA cannot synchronize itself with network time sources, so the root CA clock may drift. Since the CRL have a validity period, this requires some supervision (you can tolerate a drift of a few minutes, so this is no hardship, but you'd better keep an eye on it anyway).


How to verify a private key has not been compromised?

You need a Hardware Security Module (HSM), as there's no reliable way to detect if someone else have your key. It's the same issue of knowing if someone have your password: you can only know if someone else uses the password on a place you can monitor.

With an HSM, the key never leaves the secure environment, your signing code can run inside of it, and its security provisions can erase the keys in an event of tampering.


Routers route packets, regardless of their size, therefore it's more interesting to use small packets. Small packets can saturate your link a lot faster than large packets. In practice routers can't route at a certain speed expressed in Mbit, those speeds are calculated based on the average packetsize multiplied by the amount of packets the router can route.


Very Strange Access Request to my website

Solved: Did some digging and it turns out to be an old exploit for wifi routers.
https://www.exploit-db.com/exploits/28558
https://www.youtube.com/watch?v=fgbfVBr65e4


How to optimize compressed file cracking?

Any good encryption generates a uniform distribution of characters, making it look very close to randomness.  Thus you cannot figure out what kind of crypto simply by looking at the ciphertext.

I guess the closest you could come to that is if crypto X produces output in 128byte increments and crypto Y produces 64byte blocks, then if your ciphertext is on a 64byte boundary that isn't also a 128byte boundary then it, then it has to be crypto Y.  The problem is a lot of cryptos produce similarly sized blocks so you're guessing among many different algorithms.


Risk of giving untrusted IOT Device access to wifi

This is a broad question and will take a broad answer.

Brutally, what is an IoT device?
It has (at least) a processor, a firmware and a nic.

All of that together can be compared, more or less, to a computer; usually with *nix software onboard.

From here, you can go for whatever you like, but to better understand the risks, you have to ask yourself, "What can a computer do when it is connected to my network?"

Let's pretend that your IP cam has a second wireless card that can be set in monitor mode.
It can be used to sniff all the traffic, because it already has your AP password.

You can't find a clear answer because theoretically there is not limit.

Being paranoid, not only you have to be worried about your live stream being exposed, but you also have to be worried about every piece of information in the other devices connected on the same network.

A simple misconfiguration of whatever device can be dangerous (E.G. ssh without password or a weak one, not patched machines, etc.)

Obviously, there are a lot of things that are very unlikely to happen, but backdoor'd software isn't that hard to find, specially in closed-source software.


If you go to Google My Account Permissions and expand "WhatsApp Messenger":

View and manage its own configuration data in your Google Drive
View and manage Google Drive files and folders that you have opened or created with this app

I am not an expert on Google Apps permissions, but the wording would indicate that it is limited to files WhatsApp wrote to Google Drive itself: "opened or created with this app".


Why do some large companies still store passwords in plain text/decrypt-able format?

There's a lot of issues here.

First, a lot of companies just don't really see this as a vulnerability. They think encryption is enough and they think that they're not really a target anyway. They won't realize that they're wrong until after someone breaks into their database and steals all of the passwords they stored.

Next, there's some knowledge issues. How do you securely store passwords? Salting and hashing with MD5/SHA like you mentioned is actually not secure. You should use adaptive hashing algorithms like bcrypt. Many developers just don't know the correct way to do things like this, especially since the most-secure method changes fairly often.

There's also the issue of usability. If you hash the password, you cannot offer your users the ability to retrieve their password. Most users don't realize that this is a vulnerability and want this as a feature. The companies probably value usability over security. This goes back to the companies thinking that they're not a target, so they don't need to bother with adding all these security features. Also designing a proper password reset is non-trivial to get right.


I used to work in a phone unlocking store in the UK, so my knowledge doesn't cover anything in the past 5 years or so, and it may be a little UK/euro-centric but I'll attempt to answer.

There are two major types of "unlocking". One is called a "carrier unlock", which allows the phone to be used on any carrier. A carrier lock is commonly used on contract phones, in order to ensure that you continue to use the device with that carrier if your contract ends. The other type is called "unbarring", which changes the IMEI of the phone so that it no longer matches one on the barred list. In the UK this is illegal, because barred phones are ones which have been reported stolen.

The IMEI is not a hash. It is a (usually) unique identifier for mobile devices which are GSM capable. When a phone is placed on the barred list, the carriers all get a copy of this list, and their towers will simply send back a "barred" rejection if a barred IMEI tries to register on the system. The hardware's support for programming the IMEI is variable, though many baseband implementations nowadays have a write lock which can't be undone once set (at least without serious trickery). The usual way in which people get around barred IMEIs is to take a non-barred donor board from another device with severe physical damage (e.g. smashed screen and case) but with an otherwise functioning mainboard. This is a legal grey area, because it can be construed as transplanting working peripheral parts from a barred phone onto an unbarred phone which was damaged. Some older phones can have their IMEI changed via programming, but that is flat out illegal. There may be ways to do this on modern devices, but I've never seen it in action.

If you're just talking about a carrier unlock, the answer is (sometimes; see comments) as simple as a firmware flash. With some phones you can do this simply by putting it into a debug mode (e.g. ADB mode on Android, DFU mode on iOS) and using freely available software to flash a stock carrier unlocked firmware onto the device. It's a five minute job. On other devices, particularly pre-smartphone where you're not running Android, iOS, but rather a custom OS for that particular phone or manufacturer, there's no USB flash support. In these cases people had to get hold of leaked schematic diagrams and build devices which could hook up to test points on the board and flash the firmware. When I worked in phone repair we had at least four different cables and devices for this purpose, each of which had a range of devices it could work on. They also used special software and the process could be quite involved, usually requiring at least two or three stages of flashing, but sometimes more; an extreme example is one of the LG phones which required you to flash a very old base firmware, then upgrade through each of the ten or so updates one by one.

The more legitimate way of performing a carrier unlock is via an NCK code. The NCK code algorithm is entirely proprietary, and where it is implemented varies entirely on the device and the carrier. Usually the NCK validation algorithm is implemented in the phone's firmware, but this doesn't necessarily mean that knowing the validation algorithm does you any good. From what I've read, modern iOS devices implement NCK using something analogous to public key cryptography, with the carrier unlock data sent via SMS.

In the olden days (we're talking Nokia 3210 era) the NCK algorithm was known and anyone could unlock them, and in some cases there were even key sequences (like *#06#) which could be used to do a carrier unlock. In fact, going back to the mid 90s, there were even codes which stopped the "SIM clock" (not sure if that's the legit term) to make your calls entirely free, aside from the connection charge. This was, of course, fraud, but this didn't stop a lot of people from doing it.


Are HTTPOnly Cookies submitted via XmlHTTPRequest with withCredentials=True?

Yes, they are submitted.  See the W3C spec.

HTTPOnly is intended to mitigate attacks like XSS, but if an attacker has an XSS in your site, they don't need a CSRF.  Have you considered the Encrypted Token Pattern?


The PTES -- http://www.pentest-standard.org -- has one aspect the other frameworks do not, actionability from tools -- http://www.nothink.org/metasploit/documentation/metasploit_msf_analysis_ptes.pdf

An updated version of the tools to perform a PTES-based pen test, including the MSF analysis is available here -- https://github.com/trustedsec/ptf

OSSTMM does have a tool component, but only available from the expensive training. SANS has developed similar criteria to establish testing frameworks through expensive training, but they do have a great GPWN mailing list that is open to the public.

IMO, NIST Special Pubs do not cover pen testing per se, because even SP 800-115 doesn't take into account the complexities necessary to define or organize the best-practice thought around pen testing as performed by Veris Group, Silent Break Security, Mandiant, or similar outfits. The PCI-DSS guidelines go a lot further than what NIST provides, but it is still a bit lackluster -- https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf

To answer your question directly, I would say that the pen testing standards you referenced are outdated, while PTES is the commonly-held 2016 worldwide standard. There are also standards for the UK, namely CHECK, CREST and CBEST.


Lost RAR password, is there any way to access my data?

It depends on the strength of your password. Winrar implements proper AES-128 encryption with 262144 iterations of KDF, there's no known bypass for that. You need to estimate the number of possible passwords (what's the length, what characters were used, did it contain words, etc.), and if it is large enough to not be bruteforceble there's nothing you can do, cryptographically speaking.

The other avenue is to find the password. If it was stored in a file then you can recover it for some time after the deletion, this may well be the easiest way.


Thousands of 28000 "no pg_hba.conf entry for host" logs from Postgres - is this an attack?

I've seen the same behavior in a few of the apps I manage. I also saw this tweet - https://twitter.com/testflyjets/status/1102410441723015168 - so I don't think these are targeted attacks, but rather an un-targeted effort to find vulnerable Postgres databases.

Most of the attempted connections were with the username "postgres", but I also saw attempts with "root", "pgsql" and "pgbouncer".


What day-to-day activities can compromise a person's information security

I very often hear people on the bus calling companies and doing personal identification by answering questions such as their Address, Date of Birth, Full name, National Insurance Number (Social Security Number) and what not. I think this is a pretty bad one. By just listening to that you can get a whole bunch of information about the same person within minutes without doing anything: besides all the standard questions, you can hear their cases, their reference numbers and even their bank account details to set up a direct debit.

Also, Shoulder Surfing: less than three weeks ago I went to a big department store to get a contract phone and the chap serving me opened a page on their browser, typed an address and typed his password quite slowly with his two index fingers... I can tell you the username had only 5 characters (what I assumed to be his first initial concatenated to his surname) and a very, very short password of no more than 6 characters.


Can OSSTMM RAVs be the base for a risk assessment methodology compliant with the new ISO 27001:2013 and ISO 31000?

I only have auditing & review experience for ISO 27001 compliance but not for 31000, so my answer will focus on this one. To summarize, the answers are:

Is the matching correct? Yes.
Is it possible to use OSSTMM as a risk assessment methodology for ISO
27001/31000 ?
It depends, see below.
Any fundamental requirement that makes it impossible? No.

ISO 27001 Risk Assessment Methodology

First, it should be noted that there is no requirement in ISO in the risk assessment methodology. The ISO standard typically defines what an organisation should do as opposed to how to do it. So you are correct and you can use the OSSTMM, attack surface and RAV calculation as your methodology for risk assessment.

For example in ISO 27001:2013, we can see in chapter 8.2 "Information security risk assessment", that:

  The organization shall perform information security risk assessments
  at planned intervals or when significant changes are proposed or
  occur, taking account of the criteria established in 6.1.2 a).

  The organization shall retain documented information of the results of the information security risk assessments."

And the criterias in chapter 6.1.2 are:

  6.1.2 Information security risk assessment

  The organization shall define and apply an information security risk
  assessment process that:

  a) establishes and maintains information security risk criteria that
  include:

  1) the risk acceptance criteria; and

  2) criteria for performing information security risk assessments;

  b) ensures that repeated information security risk assessments produce
  consistent, valid and comparable results;

  c) identifies the information security risks:

  1) apply the information security risk assessment process to identify
  risks associated with the loss of confidentiality, integrity and
  availability for information within the scope of the information
  security management system; and

  2) identify the risk owners;

  d) analyses the information security risks:

  1) assess the potential consequences that would result if the risks
  identified in 6.1.2 c) 1) were to materialize;

  2) assess the realistic likelihood of the occurrence of the risks
  identified in 6.1.2 c) 1); and

  3) determine the levels of risk;

  e) evaluates the information security risks:

  1) compare the results of risk analysis with the risk criteria
  established in 6.1.2 a); and

  2) prioritize the analysed risks for risk treatment.

Using OSSTMM RAV in an ISO 27001 compliant Risk Assessment

Now as you mention, the important part here is the probabiliy / likelihood factor. It is stated in ISO 27001:2013 that the methodology used for risk assessment must:

  2) assess the realistic likelihood of the occurrence of the risks
  identified in 6.1.2 c) 1);

The OSSTMM v3 describes RAV as a scale measurement of the attack surface. It is not intended to measure risk, instead it is used as an operational metric that is much more detailed and pragmatic than traditional risk calculation like:

  Risk = Threat x Vulnerability x Asset

OSSTMM purposely avoid the likelihood factor as it is very biaised and not necessarily objective. Then RAV cannot be used as-is to perform a probabilistic risk assessment, which is indeed a requirement of the ISO standard, and the answer to your second question would then be no.

However, based on my experience, companies tend to adapt the Risk Assessment methodology / framwework they are using, being OSSTMM or any other methodology (e.g. Octave, NIST framwerork, TRA etc.), to fit with their specific context and needs.

So at the end, you would have to integrate a likelihood factor to OSSTMM/RVA to use it as an ISO 27001 compliant RA methodology. It does not have to be complicated, again ISO doesn't say how you must do it.

Other considerations

On a side note, a typical recommendation is to align each department's methodology with the global/standard company risk assessment methodology, notably for calculation methods, as it basically makes life easier for management to evaluate risk on a homogenous basis. If you're not doing that, and have different methodologies in use within your company, you will have to harmonize results and sometimes will compare apples to bananas.

For this reason, I wouldn't recommend to use OSSTMM RAV as the methodology for Risk Assessment. It's too specific and operational to be efficiently matched and compared with other risks elsewhere in the company.


Windows 7 consent.exe attempting to access the internet

You asked 1) if consent.exe is a legitimate program, 2) if its use of the network is legit (why does it attempts to connect to an external server), and 3) if there is any reason to allow it.

Your questions (and some commentary) follow.  The short answer is that it is OK, and no, you don't want to block it:

Legit?  Kudos for checking the genuine M$ origins of the file on your system.
Assuming that the copy of consent.exe on your system is good, then what is it doing anyway?
Consent, is part of the user access control (UAC) system.  Among many other things, before it allows anything to run based on signatures & certificates, it wants to check to see if any certificates have been revoked.
To check the revocation information consent has to 'phone a friend'.  Consent does this for all of your certificates each time that it does not have current, trusted information.
Can you block it from network access? Well there are 2 reasons that you may not want to do this:

Going back to a really trusted root gives you a bit more safety.  It is of course your choice, but as for me and my machines, we will check the root.
For me, when I did not provide access to all of the Trusted Roots the UAC prompt took almost 30 seconds to come up.
This was a mystery to me, and might be to you. I was using self-signed machine-specific code-signing certificates rooted from my machines at work.  These certificates were being checked via a ROOT that was not accessible.   Unfortunately, the internal work network is usually behind a firewall.  This means that the revocation check has to timeout.

So in summary:

Yes
Yes
Yes

Happy hunting.

Ah, so what did I do?  I removed all of the offending certificates -- my UAC prompt now comes up faster than I can blink.


It wouldn´t be more of a threat since using a high privileged account by itself won´t  give you any problem but it IS more of a risk if your application is somehow compromised by maybe a SQL Injection. It is recommended to run applications with just the level of privilege needed and not more, it is a security best practice known as the principle of least privilege.

http://en.wikipedia.org/wiki/Principle_of_least_privilege


How to secure email validation endpoint?

Edit to answer actual question

Sorry for misunderstanding your question. That being said, here is an answer.  If your goal is to make it so that no one knows what email addresses you have registered on the system (which is a good goal), then the simple answer is that you can't verify before hand if the email address is taken, and then let them know if so.  Regardless of what security measures you put in place, you will still have a place where people can come and ask "is this person on your site?".  Even rate limiting doesn't really do it, as a malicious attacker might be targeting a specific user.  If they already know the person's email address before hand they only have to go to your register form and see if the email is taken.  Instead, you are going to have to adjust your registration step:

You can always validate that it is an actual email address (telling them that the email address isn't an email address will protect against typos and obviously won't reveal anything sensitive).
Make them type the email address twice: this will, again, help prevent typos, which will be a big aid in the next step:
Force the user through an email validation process, like I outline below: send them an email with a key that they must use to activate their account.  This provides a couple layers of protection.  If someone is using your registration form to sniff for used email addresses, they won't find out anything.  In all cases your registration form returns a generic message "Please check your email for instructions on how to activate your account".  If the email address already exists then, rather than sending activation instructions, you can send a "You just tried to register but already exist in our system.  Click here to recover your password.  If you didn't try to register, please click this link and then disregard this message" (or something like that).  Otherwise, do the normal email validation message.

Since you don't want to tell people if they try to register with an email that already exists, you will get three different people who submit your registration form:

New people who are trying to register (these people will have no problem at all)
Old people who are already registered but forgot: your alternate email will help them get in very quickly.
People who are trying to scrape your email list.  They will get nothing at all.

As a result, malicious actors will be shut out and your legitimate users will get through without problem.  A good mix between usability and security (IMO).

previous answer: mildly applicable

Proper email validation shouldn't result in someone being able to check for the existence of email addresses in your system.  You may need to include more details about what exactly you are doing.  That being said, it's always worth explaining what the answer should be:

Email validation should be done by a cryptographically-secure and random key that is emailed to the user.  At that point in time validation can be as simple as clicking a link that you send to the user that looks something like:

https://example.com/verify_registration?key=LONGANDRANDOMSTRING

Things to keep in mind:

Make sure the validation key is generated with a proper CSPRNG: if the user can guess the key from their input, it is useless.
The user's email address is not part of the input and is not needed at any step in the validation process.  The fact that the user knows the random key, which is only handed out via email, is what verifies that the user owns the email address.  As a result, there should be no opportunity for people to scrape a list of email addresses.
Make sure that your key has enough random bytes that it can't feasibly be guessed
Normally you would only use POST requests for making changes, and therefore you want to make sure that this endpoint has CSRF protection.  However, that is not necessary here.  The reason is that the key itself is sufficiently random that no one but the person with the email should have it anyway.  So it's better to make the validation process happen via a simple link and GET request.  Even if the user just has to copy and paste the key from their email to a web form, someone will get it wrong.  The way this works is simple enough and secure enough that (IMO) a simpler UI is perfectly reasonable.
Worth mentioning because I see this all the time: hashes don't add randomness to a string.  Use an actual CSPRNG to make the random string.  Don't just take some otherwise simple data and hash it.  Hashes don't add entropy: they must make it look random.


Maybe sort of.

The DUKPT algorithm is defined to use "two-key triple-DES", or formally TDEA Keying Option 2 from SP800-57 or originally FIPS46-3. Every key in this algorithm (BDK, device initialization key(s), future keys, and working key(s)) is a "double-length key" consisting of two classic-DES (DEA) keys, each 56 real key bits plus 8 bits reserved for parity and today often ignored, stored and transmitted and used as 64 bits, totalling 128-bits.

Some implementations of triple-DES aka TDEA aka DESede (possibly including yours) require you always represent the key in full-length 192-bit or 24-octet form. Given a double-length key, you create a triple-length key by duplicating the first half, i.e. if the double-length key is (k1) (k2) then the triple-length key is (k1) (k2) (k1) . The result occupies 192-bits but only contains 112-bits of "real cryptographic keyosity".


What are the security implications of linking a domain account with a personal Microsoft account in Windows 8?

I assume this question is in regards to a bring your own device policy.

The biggest security risk of allowing someone access to link a domain and personal account is the ability for them to offload company files on various subjects (customer data, credit card numbers, corporate plans etc.) to their own accounts and to their personal PC. They wouldn't even need to be able to pull off any serious hacking, you've already given them all the access they need.

If the employee does not have the intent to cause malicious harm, a remote attacker or virus on the employees personal computer would be your second greatest risk. Anytime someone gains access to routes that are only meant to be seen by a device physically inside your network or virtually inside your network (VPN) you run the risk of a remote attacker knowing the IP scheme and naming conventions of internal devices as well as the DNS and Domain Controllers contained inside. They may not see the encrypted traffic but the packet still has a visible route. This allows someone to sabotage your network with greater ease because they know the routes and their targets.


Is there any benefit using a two-step salted hash?

This does not have any serious benefits as far as I can tell.
To summarize the content you linked, the idea is that you don't have a row with the username and hashed password:
users = [
  {"username": "admin", "salt": "PyoBT3KBnn31qDP9", "password_hash": "e53992bb5f7af6f51773ad8ea3033d66"},
  {"username": "someuser", "salt": "2IY3VczmbhHyEMQJ", "password_hash": "a7d38c0493cf0ff4af602b92c4f77a81" }
]

Instead, you remove the password_hash from the users table, and store them separately in a hashes table:
hashes = [ "e53992bb5f7af6f51773ad8ea3033d66, "a7d38c0493cf0ff4af602b92c4f77a81" ]

(Note that the article from gosquared also has a second hash and second salt, but that is pointless as well---I'll get to that later.)
If you store the username and hash together, an attacker can do a guess, for example that the password is "Pizza7!", compute the hash with the salt, and check if it's correct. When separated, an attacker has to check the result against every entry in the hashes table.
If you have 100 users, an attacker has to match the result against 100 hashes. But only one in 256 hashes has a matching first byte, so most of the time that already won't match. Almost all the time, you're just checking the first 1-2 bytes of the result against the first 1-2 bytes of every user's hash (with some shuffling for cache locality, that can be said to be instant). That is why the author advises to inject bogus hashes, so the table becomes huge. Or maybe you just have a billion users, and your table is huge as well.
If you have a huge table, looping through every hash is not efficient. An attacker would take the first, say, five bytes of every hash in the table, sort it, and keep that in memory. That's five gigabytes for a billion hashes, which easily fits in the RAM of an ordinary computer. Then you apply binary search (also known as bisection search) to find a match in about O(log n) complexity. So for a billion rows, that would be something like 9 lookups.
So you bloated your database to be a billion rows, and all the attacker needs to do extra is a handful of lookups.
But the 5GB database is way too large for a GPU. You can't reduce it to, say, three bytes, because (almost) all possible three-byte values will occur, and regardless, three gigabytes still doesn't fit in these tiny cores. So you made it impossible to do the comparison part on a GPU. However, the hash iterations from something like PBKDF2 or Bcrypt can still be done on the GPU. Only the result needs to be compared against the database in the computer's main memory. Unless you use Scrypt or Argon2, the attacker loses virtually no speed at all. You might as well increase the cost parameter of Bcrypt or the iterations parameter of PBKDF2 (they do the same thing).
Why are Scrypt or Argon2 special? Because they're "memory hard": they already have a memory parameter that allows you to require it to use a lot of memory. Sound familiar? Indeed, that's pretty much the same as using a huge table, except that this prevents the attacker from using a GPU at all.
If you don't use any iterations, for example if you use sha256(password+salt), then this scheme might help you because you add lookups which are a tiny bit slower. If you do something sane (any slow hash), I don't see an advantage in doing this.

The scheme I explained above does not match the gosquared article. They used the scheme as described in the follow-up post from opine.me. There they add a second salt. If you use a secure hashing algorithm, a random salt will always result in a unique hash, so there will not be any collisions in the hashes table, so that is not why. Instead, the reason they give is this:

If an attacker is able to both steal a user’s salt value, and insert a specific hash of their choosing into the Hashes table, they can grant themselves access to a specific user’s account

So the scenario is that an attacker can add values to the hashes table, but not the users table. Let me repeat that: they are trying to block an attacker who is able to write values to one user-related table (hashes), but not to some other user-related table (users). Privilege separation strict enough to create a scenario in which an attacker can write to some tables but not to your users table is very rare to begin with, but I'm all for layered defenses. However, your account creation script will need to write to both tables. And any login checking script need to write to neither. Being able to write to one but not the other is an inconceivably unlikely scenario, there will never be a database user with such a set of permissions.
Furthermore, the author that cooked this up argues the following:

First, I didn’t do a good job in the previous post stating my design goals. scrypt already does a perfectly fine job of letting you tune the CPU and RAM cost of completing a single hash. There’s absolutely no need for any other method than scrypt if all you want to do is tune the CPU and RAM burden on your attacker. What I want to do is two-fold:

Impose additional costs (other than RAM and CPU) on an attacker
Make it easier to detect if attackers start stealing your hashes

[...]
So this approach focuses on increasing the disk storage and bandwidth requirement of copying hashes from a target site.

Even petabytes of data would not do much to the lookup speed. It would no longer fit in RAM, but on-disk lookups can use binary search just as well. You can log in fast enough, so an attacker can do the lookups fast enough as well. You are likely to reduce your security by making your hashing algorithm faster, so that your slow lookups don't make the user wait too long.
Buying loads of hard drives to achieve all this is possible (remember that you also need to make backups of all of this), and I guess if you indeed have a few dozen terabytes of password hashes, it might actually prevent an attacker from getting all of it. Anything less is not going to be useful: network speeds are fast enough, and bandwidth and storage is cheap enough. A few terabytes won't faze any attacker. There are already password dumps of 500GB floating around the internet as torrents.
So then a, say, 40TB hashes table would actually work? The author thinks that you'll detect breaches. In practice, breaches very often go undetected for months. Some companies may notice it fast, but an equal number will be compromised for multiple years before they notice. 40TB takes (40*8*1024/3600/24=) 4 days to transfer over an ordinary gigabit connection. Another issue is storing the data, which would indeed be non-trivial at that size. They would probably have to ask friends and then probably still pool some money for a few extra hard drives. Nothing insurmountable, though. And with 40TB stored on slow, spinning drives, you're almost certainly degrading the slowness of your hashes to accommodate this scheme. And even if you succeed in thwarting the attackers, and they manage to get only 1TB (that fits on any modern laptop), then they still have the hashes from 1 in 40 users, plenty to be a big deal.
It's a huge amount of bulk for a very small amount of gain, assuming you don't degrade the quality (slowness) of the hashes.


System Information on which the SD card was used last time

AFAIK, there isn't a reliable, universal way to detect the last device a usb drive was plugged into. The best you can do is infer it from the modification times of system-specific file metadata (e.g. thumbs.db on Windows, .DS_Store on Mac) or recycle bin folders ($Recycle.Bin on Windows, .Trash-xxxx on some Linuxes).


DNS Spoof saves IP to Domain Name after attack is finished, Is there a way to stop this?

DNS TTL is used to decide how long we want the entry to be cached on the local machine. Advertise smaller TTL (DNS server/Responder does this) so that the entry will be flushed at the configured time :-)

Try it out. Its fun.

Good luck.


Does Google Chrome read the contents of screen

No, not chrome itself. That would be illegal perceived as a huge breach of trust. But what they do is use analytics like tracking pixels to see what sites you visit. This is metadata everyone shares. Where the problem lies, is that the page you visit is usually public enough for google to know the content. So they can match your visit with what they know about the page, in effect reading the page you're visiting. The D&D example you mention is probably coincidence, but the general tought is correct, they do that a lot.


Tools and computer specs for password cracking

Your question is very broad, so honestly all I can do is give some very broad advise. You need to provide more information to get a more precise answer. In particular, try to ask yourself:

What is your budget, both monetary and power-wise?
How fast do you need these hashes cracked?
How many hashes do you have that you will try to crack?
What kind of people are creating the passwords? What language do they speak?

Without knowing this, only a very vague, broad answer can be given.

  What tools would be the most effective and cost/time-efficient for such a job? Googling seems to point at hashcat or John the Ripper.

Those are both two of the most efficient hash crackers. Hashcat in particular supports extremely efficient GPU-based hash cracking using OpenCL and hand-optimized shader kernels.

  What would be the recommended computer specs for a workstation for such a task?

This entirely depends on how fast you want to achieve success. A fast GPU (or better yet, multiple GPUs) would be a must if you want ideal performance. Historically, AMD GPUs tend to be better for this than Nvidia GPUs. AMD often has simpler and more limited cores, but a huge number of them. Nvidia has fewer cores, but they are more sophisticated. Since all you need to do is process NTLM hashes, a fast GPU with a large number of simple cores is ideal. The faster the better.

This question lacks information. Depending on your exact situation, you could use anything from a single slightly-overclocked i7 processor and a popular wordlist to a tower of fast servers with 16 high-end GPUs each and a very large and heavily-customized wordlist. Or 50 acres of Cray supercomputers and a private power plant. What is your budget? Etc.

  Regarding the computer specs it seems like most of the tools either rely on GPU or CPU. Is there anything else I should consider?

If you wish, you can buy an ASIC which is designed specifically for processing hashes. You will likely need to use a custom program for this, but a high-quality ASIC can be extremely efficient for a single task. Most likely however, for NTLM, all you will need is a good GPU (or several).

  Any other aspects I should be aware of?

You can greatly improve efficiency by using better dictionaries, better hybrid rules (Hashcat supports a number of good rulesets), etc. Raw hash-rate is only one part of the equation.

Although you can use a rainbow table, the best rainbow tables for brute forcing NTLM hashes go up to around 10 characters. Since you said all the passwords were longer than 14 characters, this may not be useful for your use-case. A (hybrid) dictionary attack may be all you can do.


Impersonated user using JSessionID for session puzzling or session hijacking

Thank you. It is actually session hijacking. So anyone having admin user JSessionID can impersonate and perform admin function. To mitigate the session hijacking issue following measures can be taken

Have XSS validation in place for your application
change your JSessionID after login ie avoid session fixation
Provide strict transport layer security ie deploy your application in HTTPS (SSL/TLS)
The seesion time out should b reduced as much as possible
The cookies should be set to HTTPONLY and secure.
OWASP Recommendation


As you correctly state the PKCS#11 standard defines an API called Cryptoki. OpenSSL allows to use an engine that connects to a DLL/SO implementing this API ("Cryptoki library"). It's the nature of DLL/SO that this needs to be done locally. The Cryptoki library then talks to the "cryptographic token", which is an HSM in your case.
You should, therefore, look at the documentation of the Cryptoki library of your HSM how to specify a remote HSM instead of a local one. This is beyond the standard and vendor specific.
But every vendor provides this functionality. However, it also requires some daemon on the server where the HSM is installed to accept incoming connections from remote libraries. Usually, vendors sell PCI cards that you can use locally and network appliances that you can use remotely.
An option could be PKCS#11 forwarding. You might have a look at https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html but I have never use that tool.


Malicious email containing PDF attachments

I work at a University Security department. If you want up to date, out in the wild, evil PDF attachments try the CERT of your university (might be called SCIRT depending on where you live). We get them on a daily basis.

You could also try to get that sort of data from the anti-virus suppliers, managed Security Operation Centers (SOC).

You can always dive deep into the darkweb. :)

I am not aware of a up-to-date corpus containing these sort of attachments otherwise.


What are the most common password salting methods?

Using the login name as salt is common but not really recommended: it does only part of the job. The point of a salt is to be as unique as possible among all instances of hashed passwords, so as to thwart any attempt as parallel attacks (attacking several hashed passwords simultaneously, using precomputed tables such as rainbow tables... are parallel attacks). On distinct systems, several users may share the same login name (there are so many Jones and Smiths out there). Also, a given user may change his password while keeping his name; but even an old password is valuable for an attacker (if only because an old password is often a password that the user will reuse the next time he is being instructed to change his password; also, many users will use identical passwords on other systems).

The recommended way to generate a salt is to use a good random number generator (ideally cryptographically strong RNG) and have it produce a bunch of random bytes. If the salt is long enough (16 bytes or more) then this ensure the required uniqueness with overwhelming probability, and without much hassle (no need to lookup in a database of existing salts, for instance).

We can only hope that this recommended way is also, or will soon become, the "most common" way.


Is switching protocols a security measure worth implementing?

Switching protocols as you describe essentially requires to analyze the syntax and semantics of the transferred data in order to translate the data into a new protocol. It also means that you need to have clearly defined semantics in the first place. Having clearly defined semantics itself can already improve security. And that these semantics gets implicitly enforced  when translating the data into a new protocol additionally lessens the ability of an attacker to exploiting the recipient.

Defining and enforcing the semantics could also be done without translating into a new protocol. But to translate into a different protocol
a more strict definition of syntax and semantic is needed and it is harder to make shortcuts to skip some checks. Insofar requiring protocol switching is a neat idea in order to make sure that developers actually know how the data should look like in the first place and that they also enforce it.

Of course, this only works if there is a real translation necessary. This would in your example be the case between HTTP and JDBC but not between HTTPS and HTTP. Since HTTPS is just HTTP over TLS and it would be enough to strip the TLS layer instead of enforcing protocol semantics.


If the user account you are using is not in the Administrator group, it will make it harder for a Rubber Ducky to operate.
The weakness of the Rubber Ducky is running pre created scripts (payloads), and most of them are meant to accounts that like most Windows PCs are in the Administrator group. In a limited account, you will need to enter the Administrator credentials to do certain actions (i.e. change a Registry value) or run certain programs and without these credentials, the Rubber Ducky won’t be able to proceed.


Is it possible to intercept and modify a wireless TCP transmission?

Yes, there are ways. One of them is ARP spoofing. In it, the MITM can link their MAC address with the IP address of a legitimate computer or server on the network. Then, any messages to the intended IP address will be sent to the attacker.

Visit https://www.veracode.com/security/arp-spoofing to learn more about ARP spoofing.

More examples of it would be:

DNS Spoofing
mDNS Spoofing
Read this to learn more: https://www.rapid7.com/fundamentals/man-in-the-middle-attacks/


Granularity for data assets when determining risk during software development

The way I'd reason about this is to go back to the initial decision, which was to focus on assets.  Asset-driven approaches to threat modeling tend to end up with a problem like yours, which is "Make a list of everything."  That long list makes it hard to focus.  (The other problem they encounter is "what's an asset?")

Most engineering groups find it easier to make changes in the areas that they're making changes to the system, and so focusing on the software/system that's in scope for the current sprint/iteration helps you find threats that become actionable.

If, rather than focusing on the asset, you focus on the software, and ask "does this expose us to new threats" then your question is easier to answer.  For minor modules, that question can be focused on "does this add an API, change an API arguments, or change the data this module is processing?"

If so, you can use a mnemonic like STRIDE to look for spoofing, tampering, repudiation, info disclosure, denial of service or elevation of privilege to examine the changed elements.

Additional Answers
(SE lost my previous attempt at this; this is shorter)

First, if your client is demanding that you provide a threat model focused on assets, then that's your answer to what matters.  You absolutely run the risk you identify, "we risk missing out on specific assets which might turn out insufficiently protected," but if you have no budget, you face that risk anyway. SE cannot tell you what asset categorization rules will make your customer happy.  (bold text added here to fix an edit failure)

Second, it sounds like you're trying to do something like risk=probability*impact.  Neither input is defensible. You need to fix the easy stuff, and then focus on having a dialog about the potentially difficult fixes.

Lastly, your third question puts the cart before the horse.  You threat model to determine what's important,  not determine what's important, then threat model that.  If you're focused on assets, what assets does your active directory hold?  What does your firewall hold?  I bet both are important to keeping your system secure, not because of the assets they store.

Lastly, if your issue is budget, the changes you're making, as you document, are not fixing that problem. You need to find a way to get some quick wins, and use those to justify appropriate budget.


How to start pentesting/reverse engineering/cracking a software on Linux? (Docker based)

Use a debugger! Dynamic analysis is an exceptional way to learn how a "product" works.
What do you mean with "cracking a software which is installed with Docker on Linux"? It depends on which technology make that software run on the Linux OS. Is it an ELF? It is a Java JAR? A shell script? Basically, reverse engineering is about understanding how the software is running and what it does, but it really depends on which kind of software you want to analyze.


Can a website detect my local WIFI network I am in?

In theory, yes, the webrtc standard let's a website determine your local ip address, so it can create a direct connection for you to a another web-browser, allowing direct connections between browsers to set up video streaming for example.

This website has a proof of concept showing you your internal and external ip address:
https://www.privacytools.io/webrtc.html

Once the website has both internal ip addresses, it can use javascript to try to set up a connection over the internal ip's from pc1 to pc2, if this succeeds, it knows these 2 pc's are in the same local network.

remark: Chrome on iOS, Internet Explorer and Safari do not implement WebRTC yet, see https://www.privacytools.io/#webrtc for more info.

Update 23/08/2018:
Another possible attack vector has come to my attention lately:

DNS rebinding, from wikipedia:

  In this attack, a malicious web page causes visitors to run a client-side script that attacks machines elsewhere on the network. In
  theory, the same-origin policy prevents this from happening:
  client-side scripts are only allowed to access content on the same
  host that served the script. Comparing domain names is an essential
  part of enforcing this policy, so DNS rebinding circumvents this
  protection by abusing the Domain Name System (DNS).

  This attack can be used to breach a private network by causing the victim's web browser to access machines at private IP addresses and
  return the results to the attacker. It can also be employed to use the
  victim machine for spamming, distributed denial-of-service attacks or
  other malicious activities.

This works by having a malicious website/dns server setting a very low ttl for it's dns requests, and then having javascript running scripts on the original website's address.
Half of the time the dns will respond with the correct external ip, so the website will load, but after a few minutes when the javascript kicks in and tries to access the website again the dns will respond with a local ip adres (e.g. 192.168.0.1, this can change every few minutes) and the browser will run the javascript and connect to devices on the local network!


How safe is TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA?

It is safe, but not ideal. Let's break it up into its individual components:

ECDHE - This is the key exchange mechanism. It is diffie-hellman key exchange using an elliptic curve, typically a NIST curve such as P-256. It provides forward secrecy, because each key exchange uses a different, randomly generated private key.
ECDSA - This is the algorithm used to sign the certificate. Like DSA, each signature requires high-quality random numbers. The failure of the RNG during even one signature can reveal the private key. This makes it rather fragile, but when used correctly, it is secure. The alternative is RSA which is the industry standard, but uses bulkier keys and signatures.
AES_128 - The symmetric cipher is 128-bit AES, a secure block cipher and the NIST standard. Virtually all TLS connections use AES. Most key exchange algorithms do not provide much more than 128 bits of security anyway, so there is little reason to use a larger key size.
CBC - Block ciphers require a mode of operation, and CBC is one of them. While it is fine in theory, it is notoriously easy to get wrong and has been the source of numerous padding vulnerabilities in the past. Any modern version of TLS should not be vulnerable to these, even with CBC. CBC is an unauthenticated mode, which brings us to...
SHA - An HMAC, a type of keyed hash, is used to provide integrity. It is given a secret key which allows each side of the connection to verify that the data has not been tampered with in transit. In this cipher suite, SHA-1 is the algorithm used with HMAC. While SHA-1 has been found vulnerable to a collision attack, that is not relevant for its use in HMAC.

Rather than just using this one cipher suite, why not follow best practices?


Assuming IIS 7.x the settings you're looking for are located here:
Start > gpedit.msc > Computer Configuration > Admin Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order

To set the order in such a way as to eliminate your issues, check my answer here:
How to fix SSL 2.0 and BEAST on IIS

Also, though I doubt it's as comprehensive as your PCI compliance scans, you can check your setup at Qualys SSL Labs Server Test as an indicator of how you're progressing with the fix.

Unfortunately these settings are baked in for IIS 6.0 with no solution available.


Powerful security tools to use in penetration testing

I couldn't agree more with @spinkham's answer.  That is the best answer.

To add to @ygjb's power tool list, on the web app side, these tools are excellent for extracting data

  First use the Burp Suite to identify points of opportunity - this tool can be challenging to gain proficiency in  if you're new to how web apps work

Powertools to help you exploit SQL injection vulnerabilities

  sqlmap & sqlninja
  sqlmap & sqlninja have been invaluable to me - the information revealed from extracting the data in target databases (usernames, password hashes, trust relationships, etc.) was key to attacking/compromise additional devices

Also, there are many commercial exploit kits, to name a few:

  White Phosphorus Exploit Pack http://www.immunityinc.com/products-whitephosphorus.shtml
  Agora Exploit Pack http://gleg.net/agora.shtml
  VulnDisco Exploit Pack Professional http://www.intevydis.com/vulndisco.shtml
  D2 Exploitation Pack http://www.immunityinc.com/products-dsquare.shtml


Access based on type of information requested and access grant

Disclaimer: I work for Axiomatics, the leading fine-grained authorization vendor.

Hi Prakharjain,

What you are describing is the basis for Attribute-Based Access Control (abac). With ABAC you define access based on user attributes as you would in RBAC (e.g. user identity, role, group) but also other user attributes (department, date of birth, location...) as well as resource attributes, action attributes, and environment attributes (IP address, time, device).

In your case, you want to control access to assets e.g. a document. You state that your document has different attributes. In ABAC, you can define a document owner, whitelist, blacklist, type, sensitivity, department, etc... You can have as many attributes as you like.

Once you've defined your attributes (essentially your information model), you can start defining your authorization policies. This is the key here. Rather than define permissions in a table or matrix (which are hard to define, maintain, keep up-to-date, and audit), you define authorization entitlements using policies. A policy looks like the following:

  A user can view a document in their department.

This is the baseline Permit policy. It grants access provided the user and the document are in the same department. A rewritten (broken down) version would look like:

  A user can do action == "view" on asset of type == "document" if user.department == asset.department

And you can add more policies to the baseline one. For instance, you could state that

  If the user is not the owner and the document is private, then deny access.
  If the user.clearance < document.classification, then deny access.
  If the user is in the whitelist, then allow access.

You can choose how policies get combined together.

In addition to defining attributes and a policy model, ABAC also defines an architecture:

the Policy Decision Point (PDP): the core of the architecture where policies are evaluated and decisions are reached. The PDP is to XACML what the Supreme Court is to US law.
the Policy Enforcement Point (PEP): the integration items which can be anywhere in an application architecture. PEPs are extremely versatile depending on where they enforce access control. The PEP is to XACML and the PDP what police officers and judges are to courts and the law
The Policy Information Point (PIP): in ABAC and XACML, there is a need for attributes. Attributes are there to describe users, services, resources, actions, and the environment. Policy Information Points are attribute stores. They can be any format and located anywhere. PIPs are to XACML what the DVLA, the set of police records, the census bureau, etc… are to a nation and its citizens.
The Policy Administration Point (PAP): this is where you manage your policies.

There is one major standard which implements ABAC and that is XACML (eXtensible Access Control Markup Language). What you need is a XACML implementation such as Axiomatics Policy Server.

Also have a look at this question I replied to.

HTH,
David.


What happens when attacker disrupts the ssl handshake?

Typically, controls are put in place to prevent "access to any upstream server". This includes:

Proper device hardening for routers and switches
Properly configured DNS servers
Network monitoring solutions to detect MiTM attacks on the local LAN
Certificate Authorities (CAs) to verify that the correct cert is used in the SSL handshake with the server

You'll have to clarify what you mean by "stop packets from going to a particular website". How would someone perform a MiTM if the attack if the packets are stopped. Do you mean redirected to a malicious site that the MiTM attacker owns? In that case, the CAs and the cert itself are the mitigating controls for this type of attack (think cert warnings by the browser).


Hashed passwords - How many variations of rainbow tables?

Hum many questions in one

Rainbow tables are designed for one particular hashing algorithm.
It is difficult to say which algorithm is used, but the hash length can give you hint.
For shadow files you can see : https://serverfault.com/questions/88284/how-is-a-password-hash-encoded-in-the-shadow-password-file


Is a users mobile number available to a web service?

Technically possible? Yes, legally possible, no.

When using a data connection via any of the UK carriers, it is not possible to determine the subscriber number from data available to the server. They must have had your subscriber number in order to levy charges against your phone account.

It is theoretically possible that you have some malware in your phone which is exposing your phone number to some (or all?) sites.

It is also possible that they provide a text input on their site to enter a mobile number and then send charges to that number - this breaks OFFCOM rules.

Further, when you are subscribed to a billed service such as this, the organization providing the service is required to send you notifications at commencement and regular intervals throughout your subscription.

I worked for a similar company a number of years ago - and would trust a rabid crocodile more than anyone involved in mobile phone micropayments. Sadly my experience was that the primary function of OFFCOM was to act as a firewall protecting such people from angry customers.

Under law you are entitled not only to your money back but any expenses (including your time) incurred in resolving the issue. But good luck with that!

Update

My information was somewhat out of date.

I am somewhat alarmed to discover that even Offcom were failing to adequately undermine consumer's rights and have now delegated that responsibility to Phonepayplus, adding further complication to resolving inappropriate or unlawful practices by PRS providers.

Could it get worse?

Yes, PhonePayPlus have removed the requirement (see section 2) for PRS operators to notify you that you are subscribed to a premium rate SMS service.

I was also wrong about the current state of affairs regarding divining one's mobile number from the IP address. And PhonePayPlus's definition of "Robust verification" of consent to charge (see section 2.14) says that retrieving a page from the website containing the terms is adequate.

So its completely legal if a provider makes up data or have bugs in their software. After all, who could possibly fake a screenshot (2.14b)?

I'm off to write a clickjacking site.


The tl;dr reply is: Yes, your understanding is correct.

In TLS mode, OpenVPN establishes a TLS session to perform a key exchange over that TLS session to obtain the keys used to encrypt/authenticate the tunnel payload data. This is a normal TLS session, just as if you'd open a HTTPS website in your browser, except that it won't just perform server authentication but also client authentication and thus the client will require a cert with private key, too.

The TLS session exchange on itself should be secure, after all it's all that you have when you visit an online banking site for example but that's only the theory. In practice every protocol has weaknesses and even if the protocol would not have any, the protocol implementation can have weaknesses, too. To make it even harder for an attacker to make use of such weaknesses, you can use tls-crypt, which will encrypt and authenticate the TLS packets using keys from a static key file. Now an attacker would also need to get his hands on a copy of that key file, otherwise even knowing an usable attack and having the possibility to pull it off (e.g. being able to monitor traffic or perform a man-in-the-middle attach) won't help him.

With tls-crypt, all data running on the "TLS channel" is encrypted and authenticated with the same algorithms as the tunnel payload data and with the keys from the static key file. For the TLS payload data (user authentication, key exchange, config push, etc.) this means, this data is encrypted and authenticated twice. Once by tls-crypt and once by the TLS session itself, as a TLS session itself is used to encrypt and authenticate data and, of course, even if tls-crypt is not used, the user authentication, the key exchange, and the configuration push must be encrypted and authenticated; otherwise how would the whole protocol be secure if that wasn't the case?

Despite adding extra security for the paranoid VPN admin (albeit, considering the horrible SSL/TLS bugs found the last couple of years, these people appear much less paranoid as they used to), it also has another positive effect: It prevents certain kind of denial of service attacks. Even if an attacker cannot break into your VPN, he may still try to open thousands of TLS sessions at the same time. Not being able to provide a valid certificate, all of these sessions will fail in the end but until that is the case (will take 60 seconds by default), a TLS session object can use a significant amount of memory resources for a small embedded device and opening thousands of these can quickly bring such a device down. With tls-crypt, already the first packet sent will not authenticate/decrypt correctly and thus is immediately discarded. There is no need to even create a TLS session object in that case.


If you do not authentify NXDOMAIN responses, then any attacks where the vilain can send the victim a NXDOMAIN reply before/in place of the correct answer, would be accepted by the victim's resolver and hence the attacker is able to make any domain disappear (in the view of the victim) without the victim being able to detect this attack. Hence NSEC, NSEC3 or NSEC5.

Dropping NSEC replies would be seen by the resolver, it would retry the query and then bail out saying "network error", so if this an attack it gets detected. Same for corrupting valid NSEC/NSEC3 records, since they are signed with the accompanying RRSIG record, a change in them would be detected by the victim.

And the victim knows that there is a DNSSEC enabled zone by seeing the DS record in the parent zone, needed to follow the chain of trust.


Will changing permission of /bin & /usr/bin increase security?

Sabotaging the normal usability of your system probably does not increase your system's security.

Of course, root, and thus, much of the system "maintenance" and startup mechanism will still be able to work normally, but you'll run into problems very quickly – what if your webserver writes logs and uses some external command to rotate them? That'll lead to hard-to-predict bugs, potential insecurities …

Even if that was not the case, an attacker that is able to escape their environment (e.g. the PHP interpreter) by executing files from /bin/ will usually also have the privileges to simply write the binaries they need into some other writable directory, mark them as executable and execute them (or they'll just load them as shared objects – or a lot of other things. Basically, the moment an attacker can exec anything, you've given them access at the level that the process is running at, nothing helps there anymore).


I don't know anything about the internals of the App Store, but I suspect this is a result of Certificate Pinning implemented by the App store.

This essentially means that their certificate validation won't just accept any old CA signed certificate, it'll only accept specific certificates or certificates signed by specific CA's.

This seems to be supported by the mitmproxy documentation:

  Some traffic is is protected using certificate pinning and mitmproxy's interception leads to errors. For example, Windows Update or the Apple App Store fail to work if mitmproxy is active.

It looks like there's other ways to intercept App Store traffic, but it's not as simple as proxying traffic via a MITM. It looks like it requires a jail-broken device to physically disable certificate validation: https://nabla-c0d3.github.io/blog/2013/08/20/intercepting-the-app-stores-traffic-on-ios/

Generally certificate pinning is considered good practice when the client knows it'll only be connecting to specific services and therefore can validate certificates more strictly. Unfortunately certificate pinning is far rarer in mobile Apps than it should be, especially considering users can't typically verify certificate information manually in an App like they can in a browser.


Authentication in WPA from a user's perspective

Though you wanted to know the authentication part, here I will be trying to explain a bit more than that which may help us build up some basics about this.

WLAN Encryption Methods: 5 types -

802.11 Legacy or WEP
WPA Personal
WPA Enterprise
WPA2 Personal-802.11i
WPA2 Enterprise-802.11i

Wired Equivalence Privacy (WEP): IEEE released the initial 802.11 standard, all of the security relied on the Wired Equivalent Privacy(WEP) algorithm. This algorithm was responsible for both authentication and encryption. WEP support 40-bit key and 104-bit key with 24bit IV.
The procedure of authentication and encryption of user end are described bellow:

Generating a unique key using 24-bit random IV (Initialization vector) + 40/104 bit key.
Generating a random number stream with RC4 using the unique key.
Generating the hash value using CRC-32 of the plaintext message.
Append the hash value with plaintext message to create payload.
Then the payload gets encrypted with random number stream (created by RC4 at step 2) to create Cipher text.
Then cipher text append with same 24-bit IV (used at step 1) in plaintext and transmitted to air.

Decryption procedure (AP end) is slightly reverse the procedure above.

WiFi Protected Access (WPA): WiFi protected access or WPA is also known as 802.11i. This is a whole lot more complicated than WEP. But to make things simple I will skip lots of detailed concepts. Let's see how 802.11i works.

802.11i consist of following phases:

1. Key Configuration: Dynamic encryption key management is much more complicated under the 802.11i. In this phase Access Point and client, both will engage in a key generation mechanism just to securely transmit broadcast and multicast traffic. Procedure at client-end are:

Store your Pre-shared key as Pairwise Master Key(PMK)
Create Pairwise Transient Key(PTK) from Pairwise Master Key.
Dividing pairewise transient key into 3 important key. i) KCK ii) KEK iii) Temporal Key (TK)
Temporal Key is then used for unicast frame encryption and further used as an input key at the encryption phase.

Access Point also goes through several steps to create a key called GTK (Group Temporal Key).

2. Authentication: To authenticate, 802.11i follows the following procedure:

Initiation: By frequently transmitting EAP-request(Extensible Authentication Protocol) frame to AP/Client from Client/AP, any one of them responds with EAP-respond frame which includes devices MAC address. Then AP forward this response to the authentication server (RADIUS SERVER).
EAP Negotiation: After having EAP-respond from AP, authentication server then forwards request to follow EAP procedure to AP  and then AP send that to Client.
If the client agrees with that procedure then client complete authentication by following EAP. If everything goes smoothly, the authentication server generates a Master Session Key(MSK) and delivers it to the client and then to the AP. The client and AP derive the PMK from the MSK and then begin the 4-way handshake

3. 4-way handshake: After completing authentication successfully Client and Access Point engaged in a 4-way handshake to establish a connection. 4-way handshake has shown bellow are drawn with ASCIIFlow.com and shamelessly copied fromThe Evolution of 802.11 wireless security by Kevin Benton

 +----------------+            +-----------------+
 |     Client     |            |   Access Point  |
 +-------+--------+            +--------+--------+
         |                              |
         |                     +--------+--------+
         |Cleartext "AckNounce"| Generating a    |
         |   <-----------------+ random Number   |
         |           1         | "AckNounce"     |
+--------+--------+            |                 |
| Generating a    |            +--------+--------+
| random number   |                     |
| "SynNounce"     |                     |
|                 |                     |
+--------+--------+                     |
         |                              |
+--------+--------+ Cleartext SynNounce |
|PTK=PRF(PMK,     | +KCK - Encrypted    |
|Client Mac,      | MIC                 |
|AP MAC, AckNounce+----------------->   |
|,SynNounce       |        2            |
+---------+-------+                     |
          |                    +--------+--------+
          |                    |                 |
          | KEK - Encrypted GTK|PTK=PRF(PMK,     |
          | + KCK - Encrypted  |Client Mac,      |
          | MIC                |AP MAC, AckNounce|
          |   <----------------+,SynNounce       |
+---------+-------+    3       +--------+--------+
|                 | KEK - Encrypted GTK |
| Verifies AP     | + KCK - Encrypted   |
| if AP has correct MIC                 |
| PTK by          |                     |
| decrypting      +---------------->    |
| Messege and M IC|       4             |
|                 |            +--------+--------+
+---------+-------+            |Verifies AP      |
          |                    |if AP has correc |
          |                    |PTK by           |
          |                    |decrypting       |
          |                    |Messege and M IC |
          |                    +--------+--------+
          |                             |
          +                             +

4. Encryption: When client successfully complete key configuration, authentication, and 4-way handshake then regular traffic get encrypted by Temporal Key Integrity Protocol (TKIP) or the Counter Mode with Cipher
Block Chaining Message Authentication Code Protocol (CCMP). Both TKIP and CCMP use Temporal Key as input key for encrypting traffic.

Basic difference between these 5 methods are,

+------------------------+--------------------------------------------------------------+
|Standard                | Authentication method      |Encryption Method  |Cipher       |
+---------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------+
|802.11 / WEP            | Open System or Shared Key  |WEP                |RC4          |
+---------------------------------------------------------------------------------------+
|WPA Personal            | WPA Passphrase             |TKIP               |RC4          |
+---------------------------------------------------------------------------------------+
|WPA Enterprise          | 802.1x/EAP                 |TKIP               |RC4          |
+---------------------------------------------------------------------------------------+
|WPA2 Personal/802.11i   | WPA2 Passphrase            |CCMP (default)     |AES (default)|
|                        |                            |TKIP (optional)    |RC4 (optional|
+---------------------------------------------------------------------------------------+
|WPA2 Enterprise/802.11i | 802.1x/EAP                 |CCMP(default)      |AES (default)|
|                        |                            |TKIP (optional)    |RC4 (optional|
+------------------------+--------------------------------------------------------------+


Understanding the details of SPI in IKE and IPsec

Security Parameter Indexes (SPIs) can mean different things when referring to IKE and IPsec Security Associations (SAs):

For IKE two 64-bit SPIs uniquely identify an IKE SA. With IKEv2 the IKE_SA_INIT request will only have the locally unique initiator SPI set in the IKE header, the responder SPI is zero. The responder will set that to a likewise locally unique value in its response. The two SPIs will only change when the IKE SA is rekeyed.

The two fields in the IKE header that are now called Initiator/Responder SPI were previously called Initiator/Responder Cookie in RFC 2408 (ISAKMP). This could be confusing as IKEv2 uses COOKIE notification payloads to thwart denial of service attacks.
For IPsec a 32-bit SPI semi-uniquely identifies an IPsec SA. Since these SAs are unidirectional the ESP/AH header contains only the SPI of the destination's inbound SA (unlike the IKE header which always contains both SPIs). Since the SPIs are locally unique this and the destination address is usually enough to uniquely identify an SA. But it could be problematic e.g. if two clients behind the same NAT allocate the same local SPI when they connect to the same VPN gateway. The combination of SPI and destination address would be the same on the public side of the NAT, which is why UDP encapsulation is required. The UDP ports allow the NAT to direct the inbound packets to the right client. Likewise, the gateway has to take measures to differentiate the two SAs so that the right SA is used when sending traffic to each client.

  Does this mean, that the SPI a party sets is the SPI used for the incoming SA, not the outgoing one?

Yes, each peer sends the SPI of its inbound SA to the other peer.

  Additionally my notes say that the initiator uses the SAD_ADD method while the responder uses SAD_GETSPI and SAD_UPDATE.

The process of establishing an IPsec SA using e.g. a CREATE_CHILD_SA exchange in IKEv2 could roughly be visualized like this:

Initiator                               Responder
SAD_GETSPI (inbound SA)  ----------->   {select algorithms and derive keys}
                                        SAD_ADD (outbound SA)
                                        SAD_GETSPI (inbound SA)
{derive keys}            <-----------   SAD_UPDATE (inbound SA)
SAD_UPDATE (inbound SA)
SAD_ADD (outbound SA)

The initiator sends the SPI of its inbound SA together with a proposal of cryptographic algorithms and, if perfect forward secrecy is used, its Diffie-Hellman factor, to the responder.
The responder selects suitable algorithms and derives the keys (optionally using DH) and proceeds installing the SAs.
Then it returns its inbound SPI together with the selected algorithms (and optionally its DH factor) to the initiator, which is now able to install the SAs on its side.

Additionally, the two peers exchange traffic selectors that specify the network traffic that is to be covered by the established SA.

  SAD_UPDATE: "Please update SPI x, set SPI to y."

That's not what SAD_UPDATE does. It actually does not change the SPI at all, but rather all (or some) of the other aspects of the SA, and these are mainly the encryption/integrity algorithms and keys (but may also include other things, like encapsulation or the anti-replay window size).

The reason you usually want to call SAD_GETSPI and SAD_UPDATE instead of simply SAD_ADD for inbound SAs (even on the responder, where all the information would be available) is that the SAD is usually managed by the operating system's kernel, while IKE daemons operate in userland. And therefore, calling SAD_GETSPI will ensure that the SPI is actually locally unique. Which might not be guaranteed if e.g. two IKE daemons (for IKEv1 and IKEv2) or even tools to manually manage SAs (like ip xfrm or setkey) are used concurrently on a system.

But it is imaginable that on some systems there could be a simplification that would allow a responder to call SAD_ADD without specifying an SPI, and the SAD would then allocate one, install the SA, and return the new SPI.  But that would require special handling for this particular case by the keying daemon (otherwise it could simply call SAD_ADD for outbound SAs and SAD_GETSPI/SAD_UPDATE for inbound SAs, no matter if it does so as initiator or responder).

RFC 2367 (PF_KEYv2) provides more information on these operations.


Is there a tree hash form of MAC that can be used when encrypting data for storage on S3 using multipart upload?

The GHASH component of AES GCM is linear. If you know the lengths of all file parts and the order in which they will be assembled, you can use this linearity to compute the polynomial value you need, and then add in the random part that makes GHASH into GCM. The spec for GCM should provide enough guidance on how to do it.


Is "sign in with Facebook", "sign in with Google", etc. bad for security?

Most of the websites that potentially use "Sign in with Google" type features, use your email address as a fallback to reset forgotten passwords.  For all these websites, your email address (where ever that is; be it gmail or some other provider) is a single point of failure.

In fact, if you use a Google account with say 2-factor authentication and strong passwords it's quite good for security, as now effectively everything uses 2-factor auth with a strong password.

It also makes is a better user experience as you only need to remember one strong password, versus remember unique strong passwords for every web service you sign up for.  (You should not reuse passwords as you are not sure if some web services are malicious/incompetent and record your passwords/password attempts in cleartext or with weak hashes).

(The major exception to the email based password reset in my experience is banks, where you typically have to talk to someone in person/over the phone and answer several security questions/provide documentation if you forgot your password.  I do think it would be a mistake for banks to let you login through Facebook/Google, though I have never seen it in practice.)


Logging attackers will be highly dependent on how you set up the honeypot system you describe. What methods you expect (or don't expect) attackers to use to acquire access and what they do within the system there.

Secondly you will need a method of identifying malware. How in depth you want to set up logging on the operating system is up to you here. You can log a lot of things... You have to draw the line somewhere.

As for quarantining malware for analysis, the accepted method is to archive or encrypt it. The professional community prefers the encryption method because only the researcher who encrypted it can decrypt it (avoiding the whole "Hey! whats in here?" problem with archives with no password).

Encrypted malware can be safely transported to the analysis machine for debugging and examination. The analysis machine should be a VM. This way once the analysis is complete, the VM is simply nuked from orbit and restored, ready for the next test. The reason we do it this way is to avoid missing a piece of malware somewhere and contaminating a subsequent analysis.

Hope this helps!

EDIT:

I missed the bit where you state "freezing the malware before it executes". You can't. You can use the same heuristics and detection as the antivirus to get known malware before it runs. But then, it's known. Why would you want to analyze these. The unknown ones are, by definition, unknown. Therefore there will be no reliable way to stop them. You will only know after the fact they are malware.

I think a better way to do this would be to replace your windows7 component with a VM in the DMZ, then you can isolate and encrypt the malware through whatever method you wish and then transport it for analysis. Then nuke the DMZ VM and replace it with a fresh version along with your analysis VM. This way, you always revert to the same uninfected configuration. You can also activate the antivirus in the DMZ VM and set it to only quarantine in the case you wish to analyze known malware also.


The concept of the proxy leaves the question of authentication up to you.  As you know the basic idea is that you create a server-based service that is a facade for communicating with Flickr.  The UWP apps communicate only with your web service, which in turn holds your secrets and uses them to communicate with Flickr, returning only the results to the end user, never exposing the secrets.

This model leaves the question of end-user authentication up to you.  You can create a mechanism that forces your UWP app users to authenticate individually with your web service before communicating with Flickr, or you can allow them to access your web service unauthenticated.

Even if they are un-authenticated, however, this model provides you with several critical advantages.

You can monitor access to the service.  If the secrets are embedded in the app, as you've noted they can be stripped out and abused by a malicious user, and you'll never know the difference and have no ability to intervene.  If the requests need to go through a service you control, you have the ability to spot potentially abusive patterns, and at least know what is going on, and hopefully have the ability to mitigate the abuse as well by identifying and blocking offending clients.
If there are issues with the credentials, such as they're blocked or expire and need to be changed, you can update them on the server-side without having to push updates to every single client.    In the current model, if the creds cease to be valid for any reason, all of your clients are broken until you can publish an update with new secrets, and every client installs it.  In this model, the clients are only broken until you update the secrets on the service, and then they magically work again.


Opening mail from IMAP with no risk for the user

By controlling the presentation layer, you may display a confirmation pop-up before redirecting to the target URLs. While requesting confirmation, the pop-up would highlight the target domain and include a reminder about dangers related to malicious websites


Sure enough Thomas, the decryption constant 0xC6EF3720 is simply 0x9e3779b9*ROUNDS and needs to be adjusted accordingly.


About DMG and AES in general

https://apple.stackexchange.com/questions/110369/are-the-files-in-an-encrypted-dmg-actually-in-plain-text-on-the-hard-disk/110618
https://stackoverflow.com/questions/16537418/how-secure-is-aes-128

About DMG "cracking" (infact he just bruteforces it because he knows most of the password and just has to test about 22k password combinations):

https://www.whitehatsec.com/blog/cracking-aes-256-dmgs-and-epic-self-pwnage/

At least there are no known implementation failures of which I am aware (there was some kind of bug around 2006).

With DMG Encryption on Mac OSX AES 128/256 is used which is commonly considered to be a safe encryption method (of course depending on your password).

So if your password is good (long, lower/uppercase letters, special characters, etc.) then it is safe


Auditing EXEs to ensure buffer overflow protections are in place? (such as SEHOP, ASLR, and DEP)

For Windows binaries you might want to take a look at BinScope from Microsoft.


Is there a security vulnerability in setting a public DNS entry to a private IP Address?

You can point a domain name to a private IP address.  As a random example, the company I work for has a domain name local.example.com that points to 127.0.0.1.  Not that the details matter much, but it uses this for providing MFA to command line tools - the local application will launch a browser window with our SSO/2FA provider, and the return URL for the login process is local.example.com, which (as mentioned) points to 127.0.0.1.  Before starting this the command line tool temporarily starts up a web server that is only accessible locally (i.e. at 127.0.0.1), and so when the web browser redirects to local.example.com it is redirecting to a web server accessible only on the local machine, and the command line tool uses the web server to extract the necessary access tokens from the SSO provider.
What you're proposing to do is pretty much the same thing.  While I've never attempted your particular use case, I see no reason why it shouldn't work.  I don't believe there are any particular security concerns related to this.
As for how to automate your certificates with certbot, you could do it without opening up your service to the outside world, although it depends on the capabilities of the DNS host.  There are two key points:

The certbot command line tool has options that allow you to inject your own custom scripts into the renewal process
certbot can also prove ownership for issuing certificates by having you create DNS entries for the domain, without needing to connect to a webservice.

Therefore, if your DNS host supports it (the larger ones do), you could imagine attempting this flow:

Adjust certbot to use DNS validation.  In essence, it will request that you create DNS records on your domain with certain values
Use the API of your DNS provider to automatically create these entries
Ask certbot to validate the records.  It will then check for the DNS entries (and happily wait reasonable amounts of time for DNS propagation)
Once the DNS propagates and is verified, certbot will give you your certs

Note that this process is not necessarily as involved as it sounds.  Certbot already has plugins available for many DNS hosts, and you may find near-complete examples of this process online.
The other option would be to run a private DNS server on your local network, and update your network configuration (or the client machines) to point to it.


Doesn't plaintextoffenders.com just provide attackers with a good list of sites to attack for passwords?

Not really.

Knowing that example.com is a plaintext offender doesn't help me much in mass-compromising accounts for that website. I could try to compromise their peering-router to sniff all their outgoing emails, but that would be quite difficult, because that router is likely to be properly secured. Trying to attack their website itself is likely more promising.

The more plausible attack scenarios which become possible through plaintext offenders target the individual user and all websites they use, not all users of the individual service. When an attacker could read the mail communication of a private user (much more plausible than with a professionally administrated system), they can obtain their login credentials for all plaintext-offending services they register to. That means an attacker would rather be interested in finding vulnerable users so they can get logins for random websites, not finding a vulnerable website to get logins from random users.

Besides, finding out which sites are PTOs is trivial: You just have to register an account and you know. Fully automatic account registration is something spammers got frighteningly efficient at.


Why only Google warn us about attackers?

There are so many search engines like ask.com, yahoo.com and many more, but only Google warn us about attackers. Why so?

Just because it says Google it does not mean it is related to the search engine.

Google Safe Browsing is a service run by Google, but it is not directly related to their search engine, same as Google Cloud, Youtube etc. are not directly related to the search engine either. Use of Google Safe Browsing is integrated into at least Chrome and Firefox.

The is a similar service for Microsoft browsers (Microsoft SmartScreen), which is run by Microsoft and which is also not directly related to their search engine. Several security companies have similar services for their firewalls (i.e. blacklisting malicious sites) even though they don't have a search engine at all.