What more can I do to secure my service?

I suggest a more proactive approach as well by doing your own penetration testing against a non-production server setup specifically for this sort of thing.

We use BurpSuite's scanner feature to test our own products - it has really helped augment our quest to find vulnerabilities. ZAP is a free alternative I've heard good things about, but have not personally used it. Pay particular attention to any SQL injection issues they identify.


How to get SSL certificate of a mail server?

To get the SSL/TLS Certificate of an SMPT server pick the domain of one MX record from the answer section of your DNS query and feed it to openssl:

$ dig gmail.com mx
[...]
;; ANSWER SECTION:
gmail.com.      3599    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  30 alt3.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  10 alt1.gmail-smtp-in.l.google.com.
gmail.com.      3599    IN  MX  40 alt4.gmail-smtp-in.l.google.com.
[...]

$ openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
[...]

Note: it's not a safe assumption that the web server (if there is any) running on the same machine as the SMTP server uses the same certificate.

see also https://serverfault.com/questions/131627/how-to-inspect-remote-smtp-servers-tls-certificate#131628


SVG virus/ malware with an extension on Google Chrome (one)

The extension, which was in the Chrome store, is the Nemucod downloader, which harvests credentials and is capable of spreading malware.

If affected remove the malicious extension from the browser, run an antivirus scan and change the Facebook password afterwards. You should also notify any people who received a malicious file from you.


This is all to be expected.

A router with multiple interfaces can have services listen on just some interfaces.

You're right conceptually that NAT sits between the two interfaces, but normal outbound NAT does not create open ports.

Sit back and chill out :-)


Safety of exposing an internal web application to the internet using a reverse proxy in the DMZ

You are not adding much security doing it this way alone: if an attacker can find a fault in your web app, using a reverse proxy alone will not prevent anything.

However, the fact that your reverse proxy is the place where the SSL connection is terminated allow you to add other security systems in between the final app and the user: it could be a WAF, an IPS/IDS or both.


Why do public wifi networks often have a click screen to join?

This article has some legal advice for wifi hotspot owners.
It explains that a splash screen is a useful tool to make users explicitly accept the terms and conditions for using the hotspot and thereby reduces potential liability:

Consult your attorneys before setting up a Wi-Fi Hotspot at your business location. The following are some steps a business owner can consider in setting up a Wi-Fi HotSpot to reduce potential liability:
[...]
(b)   The Wi-Fi HotSpot access point can contain a use agreement and disclaimer (sometimes called a “splash page”) that requires the user to click through an agreement before enabling access;
(c)   The use agreement and disclaimer can disclose appropriate terms and conditions of use, which prohibit and do not authorize, for example, illegal activity, copyright violations, pornographic or corrupt content, spam, solicitations, advertising, or use of the service by unsupervised minors.


Is there anyway to probe open out ports?

For example I want to know whether the host has web browsing access (80) or not.

Outgoing TCP connection (like web browsing) have a source ip and port and a destination ip and port and sequence numbers. In order to get a response from the system your scan attempt would need to match all of these parameters, i.e. you need to guess the (more or less) random port number used by the client and the destination ip the client connects to using this port number and additionally the current sequence number.

Even if you want to know if the client is connected to a specific host you need to try thousands of possible port numbers and up to 65535 sequence numbers. While you've tried this the communication has probably already moved on which means that you now have to guess a different sequence number (i.e. moving target while you shoot). I'm not saying that this is impossible, but very unlikely.


As stated, your problem is simple. What you want is to embed in B_trusted a hash value, which is the result of hashing the concatenation of the "hardware key" and the second stage bootloader code. As long as the contents of B_trusted are indeed free from alterations, and the hash function is second preimage resistant, then the attacker will not be able to come up with an altered version of the second stage bootloader that B_trusted will accept to load and run.

No need to fiddle with encryption here; a simple hash suffices. However, this assumes that the two following properties are maintained:

B_trusted cannot be altered by the attacker.
Each individual device can get its own B_trusted personalized with the proper hash value.

If B_trusted is considered free of alterations because it is in some ROM, then it may be hard to indeed personalize its value for each device; it would have to be at least partly PROM and this may raise costs. An additional problem is that such a scheme precludes the possibility of firmware updates: once B_trusted is fixated with a hash value, it will load only one specific second-stage bootloader. The attacker cannot make an alternate version, but you neither. Hash functions make no prisoners.

To solve these potential issues, you have to use cryptography, and, in particular, keys. A key is something secret and its value is exactly the measure of how it is unknown to the attacker.

A first solution attempt is to use a MAC. That's what your construction amounts to: a custom, homemade MAC, by encrypting a hash output. In cryptography, "homemade" is a synonym for "probably weak". Instead, use an actual MAC. Since you have access to a hash function, then use HMAC. Compute HMAC over the second stage bootloader code, using the "hardware key" as key for HMAC; the second stage bootloader header contains the MAC value, and B_trusted checks that it matches what it has recomputed.

This ensures that the second stage bootloader is tied to the hardware, and an altered version will not be loaded, unless it was produced by you, because, using your knowledge of the "hardware key", you can compute the HMAC output for any ulterior bootloader version. However, this works only as long as the "hardware key" is secret. And that's not a given. Indeed, most of the time, such hardware keys are not secret; the attacker can recompute them. They are bound to the hardware and thus cannot be changed by the attacker, but if he knows that "key" then he can recompute MAC values at will.

In fact, I bet that your "hardware key" is not a key in the cryptographic sense; let's call it an "hardware identifier".

To fix that, we need a digital signature. The scheme is the following:

There is a unique asymmetric key pair (say, RSA) with a public key Kp and a private key Ks.
The first stage bootloader B_trusted contains a copy of the public key Kp.
The second stage bootloader is tied to the hardware and signed: for device with identifier I, a signature is computed (in factory) over the concatenation of I and the code of B. That signature is added to B as a header.
When B_trusted runs, it obtains I from the hardware, and verifies the signature on B.

This scheme does everything you want:

B_trusted is the same for every device instance, bit to bit. It can be mass-produced in ROM.
Neither B nor B_trusted contains anything secret, so there is nothing that would be a problem if the attacker reverse-engineered the whole lot.
You, as the owner of Ks, can generate signatures at will. When you sign a second stage bootloader, you are actually authorizing that specific version to run on the hardware whose identifier you include in the signature input. Firmware updates are now possible.

Technologically, this method implies the following:

You must add a header to the second-stage bootloader, with a signature value. A strong 2048-bit RSA signature has size 256 bytes. If that size overhead is not tolerable in your situation, you may try to use DSA or ECDSA (a good, strong signature of the same strength will be down to 56 bytes).
B_trusted must do a signature verification. RSA signature verification is efficient; it begins by hashing, then uses the hash value in a mathematical operation which can be completed by an anemic ARM core in less than 100000 clock cycles. I don't know what your system hardware is, but it seems improbable that you could not contrive to use a RSA signature verification (DSA and ECDSA imply higher costs, but maybe usable as well).


What technique should I use to prevent unpermitted access to my REST API

You have a lot of options and you should pick the best one based on your requirements.  Authentication systems aimed at automated systems have different usability requirements than users.

For example, users generally don't want to present their password with every request or handle long, complicated passwords.  The code calling your API doesn't have those issues.

Internally you should probably store api tokens or passwords the same way you do user passwords: salt them with a long random value and hash them with a reasonable algorithm.

You also have the option of using client certificates that are trusted by your app.  More complicated to set up but you don't have to pass the sensitive credentials materials between systems.

Again, all of these options should be vetted against the security requirements of the system.  If you're securing a bank or missile launch codes you're going to want to have higher standards than the API for a casual website.


Security risk of connecting to two networks simultaneously

The risk is not really for your own system but for the corporate network. I assume that the private network is only connected to internet through a secured firewall, and that through the VPN you get access to that private network.

If you manage to have your machine connected at the same time to a public network and to the VPN, it will constitute a new connection for the private network bypassing the main firewall. This is something that any security team sees as a terrible config: an external attacker could get access to the private network through your machine without hitting the firewall, and with no possibility for the sec team to have any trace of it.

Do not worry about it: this recommendation is common as soon as you get a corporate VPN.


Yahoo Email Compromised But No Suspicious Activity

I guess you gave permission to some App to Read contacts/Send email via Yahoo OAuth. I Mean, you singed in to some website/application using Yahoo credentials via Yahoo.

So, Just using the Access token that got created at that time you gave permissions, Its possible to send emails to all your contacts using the API of Yahoo.

In this case the App dont need to Login with your credentials. The Access token will suffice.

If this is the case, you can fix it by removing permissions to that App.


Why would the government collect Wi-Fi SSIDs via manual door-to-door questioning of citizens?

I see two possible uses of such information from a government perspective. None of them involves the password or actually using your WiFi access.

Forensic analysis: connected devices store an history of access points they were connected to, sometimes associated with "last seen" dates. Using this history, it is therefore possible to know where someone was and when, which can be very helpful for investigators.

Concrete example: someone is arrested, his cellphone and laptops are seized for investigation, and their WiFi history is analysed (actually, in some cases, with some devices being a bit too talkative, it is not even needed to actually seize the device, but let's stay on topic). This will reveal where the suspect has been and when (for the last time at least), and because we are talking about associated access points it strongly leads toward some sort of relationship between the suspect and the AP owner (you do not distribute your WiFi password to any strangers, do you?), helping to construct a map of the suspect relationships (here having the ability to associate an SSID (the WiFi name) to an owner name takes all his importance).
Geolocation: If by any means investigators can remotely access the list of the access points covering the area where a device is currently located, then it is possible to determine where the device (and most likely its bearer too) is located.

Concrete example: An implant (to borrow NSA's terminology) is installed on a device with Internet but no GPS capability (laptop, tablet, etc.) or where the user has disabled GPS geolocation for privacy purposes. The implant phones home on a regular basis, sending a list of currently visible WiFi networks with the associated signal strength (the device doesn't need to be associated to any of them). Associated to a map of SSID geographical locations, this effectively allows to track in real time the suspect's movements.

In this case however, collecting the owner's name in such visible actions is less needed, war drivers and other Google cars know this very well. However depending on the details of this procedure it may also limit the possibilities for people to freely change their WiFi SSID name (let's say the form forbid this, it would be trivial for the authorities to detect undeclared changes and associate it to a name), thus possibly providing more accurate information on the long-term.

Regarding your mention about the WiFi password, as long as the WiFi access has been hacked by finding the password and not due to another unrelated weakness and unless the attacker also hacked the access point itself (and replaced its firmware for instance), then changing the password by a stronger one is sufficient to block any further exploitation of this access.

Regarding what can be done using a compromised access point, this is worth a separate question but you may already find a lot of information in already existing posts on this site (basically an attacker would gain a Man-in-the-middle (MiTM) position to intercept/modify all of your communication, this also opens opportunities to attack other devices of your internal network, and depending on the device's reset abilities the attacker could also prevent the access point firmware from being cleaned, effectively requiring the device to be replaced).

And yes technically you could change your WiFi "name" any time you want, however it is possible that your government may request you to fill a form to officially declare this change (or they just assume that only a minority of users will do this so it does not worth to track such changes).


Possible to change the CA that a keypair is using?

It is perfectly possible to have the same public key in several distinct certificates. Mathematically, the public and private key are linked (in RSA parlance, they use the same modulus) and there is nothing that you can do for or against it. It just is.

Technically, a given machine may store certificates and private keys in some dedicated structures, and a private key should somehow be linked to the certificate, and/or vice versa, so that applications can get things going without much ambiguity.

In the Windows world (CryptoAPI and CNG), the link is from the certificate (in the "My" certificate store) to the private key (in an old-style CryptoAPI CSP, or a new-style CNG KSP). It is perfectly possible to have multiple certificates pointing at the same private key; this is even the normal situation in case of certificate renewal without creating a new key pair. Links from certificates to private keys can be set semi-automatically with certutil with the -repairstore sub-command (normally the certificate issuance process keeps track of the request and sets the link properly, but in some cases the link must be restored). It can also be done programmatically. The link is done by name (the "container name" in Microsoft terminology).

In PKCS#11 systems (e.g. Firefox, and most certificate-based things in Linux that are not purely software), certificates and keys are linked by virtue of having the same CKA_ID attribute, and since that attribute is supposed to be unique for a given object type, you may have trouble having two certificates simultaneously that point at the same private key.

In any case, a number of hardware devices that store and use private keys (in particular smart card) cannot really keep a many-to-one relationship from certificates to keys. Even with Windows' "Base Smart Card Provider" and its "MiniDriver" companion API, it is expected that only one certificate at a time may be stored on a smart card with a link to the private key. However, one can still have copies of multiple certificates in the certificate store (on the machine, not on the smart card), all pointing at the private key on the smart card.

Revocation is on per-certificate basis. What is revoked is the certificate (i.e. the binding between your key and your identity), not the key. Of course, if several CA have issued certificates that bind your key to your name, and your key gets stolen, then you would like all these certificates to be revoked. However, if one CA revokes your certificate for some other reason (e.g. you failed to pay a yearly "certificate maintenance" fee), then this has no impact on the revocation status of certificates issued by other CA, even if they contain the same name (yours) and the same public key (also yours) as the revoked certificate.


Make sure that your apache2 service is running

service apache2 start

Note that using SET on a virtual machine might cause problems sometimes.

And finally, i guess in the newer versions of SET you wont find the username and password on the terminal itself, instead you will find them in the www directory


How to prevent host header attack in Ubuntu Server 14.04?

First, this is not an attack against your server because no harm is done on the server. And, it is not specific to Ubuntu Server version whatever but is specific to the web server and its configuration, i.e. in your case nginx with unknown configuration.

By default the web server has no idea which names are valid for your system. You have to explicitly configure which names are valid and what the server should do if no host header was given or none of the configured host headers was given. With nginx as used on your system this means to configure virtual hosts for all the names you want to accept, configure a default server to reject all requests to unknown names and maybe configure a similar server in case you want to specifically deal with empty host names.
For more details see the nginx documentation, specifically the part about "How to prevent processing requests with undefined server names".


Does attacking difficulty of a block cipher depend on it's block length?

Does attacking difficulty of a block cipher depend on its block length

It depends on many things, and block length is part of it. A small block size (64 bit) is vulnerable. However, as soon as you reach a reasonable block size, increasing the block size does not really make things more secure. So I wouldn't say a 256 bit block size would be much safer than a 128 bit block size.
Besides block size, another property of block ciphers is they key size. These do not have to be the same. In general, larger keys are more secure, but here also there are diminishing returns when getting sufficiently large.

compared to a substitution cipher

Block ciphers are usually compared against stream ciphers. I wouldn't say one is more secure than the other.
Even if the cipher itself is perfectly secure, whether the system as a whole is secure depends on whether the cipher is used correctly.


Does authentication provider have access to site?

Let's unpack this into the specific questions. I'll try to be brief in my answers because the overall theme should give you an idea what the situation is...

  do they gain access to the data in my website?

Assuming the data is protected by access controls - and not already public - then it would be a violation of your trust in the third-party authorization provider for them to access your site's data directly. They are unlikely to do this, because the value of stealing your data would not be worthwhile given the lost value if they lose your trust.

But technically speaking, there's nothing in the OAuth protocol that would stop a provider from spoofing your user's identity. By using a third-party provider, both you and your users are placing your trust in them not to do this.

  Can they scrape it with a bot?

Given that they could spoof a user, they could presumably gain access to your site by performing an OAuth handshake. If it were authenticated and understand your authentication scheme (ie. you're using an auth cookie, or the bot knows how to use your Bearer Token scheme or similar), they could theoretically browse the authenticated portion of your site to scrape it.

But as mentioned above, they probably wouldn't. Again, this is the risk you take by using a third-party provider. You need to trust them.

  Can I prevent them from gaining this access?

Not really. If you're just worried about automated access, you could do something to obscure the authentication between the client and server so that a web scraper wouldn't likely know how to use the auth token. For example, you might change the header name. That said... this is probably a bad idea. There are a number of assumptions made by web servers and server monitoring tools that would help to keep from leaking Authorization headers, which might not be true for other headers.

All said and done, if you're going to use a third-party authorization provider, you need to trust that they will have appropriate safeguards on their end to protect your application from misuse. If placing this trust on the third-party is not appropriate for your level of risk acceptance, then don't use a third-party identity provider.


How to verify that the certificate of a file is trustworthy?

This answer has an implementation in C++:

BOOL bIsSuccess;
DWORD dwEncoding, dwContentType, dwFormatType;
HCERTSTORE hStore = NULL;
HCRYPTMSG hMsg = NULL;
PVOID pvContext = NULL;

// fill szFileName
...

// Get message handle and store handle from the signed file.
bIsSuccess = CryptQueryObject (CERT_QUERY_OBJECT_FILE,
                               szFileName,
                               CERT_QUERY_CONTENT_FLAG_ALL,
                               CERT_QUERY_FORMAT_FLAG_ALL,
                               0,
                               &dwEncoding,
                               &dwContentType,
                               &dwFormatType,
                               &hStore,
                               &hMsg,
                               &pvContext);

  To verify the signature of the file I would recommend you to use CertGetCertificateChain and CertVerifyCertificateChainPolicy to verify not only that the certificate is valid in general, but that it (or all its parents) is valid for authenticode (szOID_PKIX_KP_CODE_SIGNING). CertGetCertificateChain can be used for different revocation scenarios. You should do two separate calls with CERT_CHAIN_POLICY_AUTHENTICODE and CERT_CHAIN_POLICY_AUTHENTICODE_TS to verify that both Authenticode chain policy and Authenticode Time Stamp chain policy are valid.


Google custom Search Engine api key: is it confidential?

Google uses the API key to identify who is sending those requests.  Google will impose a quota.  As you've correctly identified, if Google receives too many requests using that API key, they'll blacklist the API key.  If that happens, your own site/app will stop working.

Therefore, there are risks to leaving the API key in the clear on your page.  These risks are somewhat modest: someone who gains the API key doesn't get root on your systems, but they might end up causing your app to stop working.

If this risk bothers you, then don't put the API key on your web page.  Instead, have the client issue an AJAX request to your server, and then have the server issue the request to Google and return the results back to the client.  This way, the Google API key is never exposed to the client.

The Referer header check prevents someone else from copying your API key and putting it in their own web page and using Javascript to query Google.  However, it does not prevent them from copying your API key and using it in requests they initiate from their own machines.  (If they use curl or some other similar library on their own machine, they can forge the Referer header and make it say whatever they want.  Therefore, the Referer check does not help prevent this scenario.  It only prevents others from embedding the API key in their web page and using it in Javascript that runs in the browser of folks who visit their web page.)


Grsecurity could be an alternative to selinux and apparmor on a linux machine. A comparison of the three tools is given over here.


SSH "on keyboard interactive devices" brute force vulnerability

`perl -e 'print "pam," x 10000'`

is executed in subshell, prints 10000 times pam divided by comma (,).
The returned string is used as an argument for -oKbdInteractiveDevices= option (see manual page for ssh):

KbdInteractiveDevices
Specifies the list of methods to use in keyboard-interactive authentication.  Multiple method names must be comma-sepa‐
rated.  The default is to use the server specified list.  The methods available vary depending on what the server supports.
For an OpenSSH server, it may be zero or more of: “bsdauth”, “pam”, and “skey”.

This vulnerability is already fixed on most of the systems. But there was bug on server, that didn't check if the "device" was already tried. This allowed to issue much more passwords attempts than if you would have to issue the whole new connection for three attempt (you could do 10000 for exmaple).
For the record, it is CVE-2015-5600 shortly described in this blog post


How do honeypots remain secure to 0days and newer exploits?

They're just as vulnerable as any other software would be to a vulnerability, so to your specific question it would be just as vulnerable. Remember though that in the case of shellshock the honeypot would have to be passing input to a bash shell to be vulnerable. Of course, is another component on the system is vulnerable, the honeypot could still be compromised using another vector.

The only difference between a honeypot and other software is that a honeypot is designed to be attacked, so they often put strict controls around whatever mechanism they use to capture malware, exploits, etc. It's unlikely that a honeypot would pass input to a bash shell given that it's known to be risky, but anything's possible.


It as everytime depends on the password too. A password protected .zip file should be fine. Another option would be to create a vera crypt file you can send via E-Mail if its small enough , too.


Does the WannaCry Ransomware affect VMs which are connected in Network?

Yes, VMs can be affected as much as "normal" hosts can. It can also affact Linux when you run the code with wine.
See also: https://askubuntu.com/questions/914623/what-is-the-wanna-cry-ransomwares-possible-impact-on-linux-users

Additional information:
Some derivatives of the malware may detect that you are running these OS's in a virtual maschine and don't go off, but i would not consider this as a comfortable position.


The default value of $GATEWAY_PROBE_HOST is 8.8.8.8, which the module initially contacts with a TTL value of 1. This is done to discover the current default gateway (since TTL will expire at the default gateway and it will send an ICMP time exceeded message). It seems like you have an invalid IP address in the GATEWAY_PROBE_HOST datastore option. Run the command in the terminal:

msfconsole
use auxiliary/dos/tcp/synflood
show advanced

and look at the configured value. To set it to 8.8.8.8 or any other external or internal host, use the set command. Further run

set GATEWAY_PROBE_HOST 8.8.8.8

Configure the required datastore options and run again.


MSFConsole/Kali Linux - gain root access to unix system

At this point you've achieved the basics of a compromise on the system and you're on to the common phase two of exploitation which is privilege escalation.

Exactly how you can achieve that depends very much on the system in question, what code is installed on it and how it's configured.  Some options for things to look for to get privilege escalation on a linux system

SetUID root binaries that are writable by the user you are running as.  if you can find something you can overwrite which, when executed, will run as root, you can use this to escalate your privileges.
Vulnerabilities in system services running as root. This will likely depend on the patch status of the system that you're running on.

Other things which apply more in "real-world" security tests but which are unlikely to apply to your situation

Credentials exposed in files on the system.  This can be a common way to exploit systems.
Password guessing attacks.  Guessing credentials is a good way to gain additional access
Pivoting from your attacked system to another one in the same network.  Typically once an attacker has a foothold in a network they will scan for other systems which may have additional mid-configurations that could be exploited.


How to whitelist an IP, but prevent others from DoS attacks

If you white list the IPs that you trust, that implies every other IP except those are blocked. That will effectively prevent other IPs from DOS attacks. The assumption of course is that the firewall configuration is not erroneous and/or the firewall itself is considered "secure" by any reasonable standards.

Where a tool like RDP Defender comes in to add value, is when you can't know the specific IPs that should be using your service and thus cannot white list them, and/or you don't want to assume those IPs are trustworthy.

RDP Defender, and tools like it, allow you to open up your services to IP's and then it looks for behavior patterns from those IPs and blacklists based on behavior criteria.

It is worth pointing out that, according to RDP Defender's site, this tool works by monitoring for failed login attempts and then leverages windows firewall to put rule(s) in place to block traffic from those IPs. This is important to think about for several reasons:

1) DOS/DDOS attacks don't necessarily leverage logon attempts, and thus will go undetected and unblocked.

2) The defense of blocking the IPs where suspicious traffic is generated, in itself, can be used as the attack method for DOS. If an attacker can embed itself into something a lot of people use, when that attack launches it will be coming from a lot of IP addresses. If your defense is to block each of those source IPs, some of those IPs might be valid customers of your service which are getting shut off. If your defense is to block entire sub nets, that will certainly have the potential to shut off a lot of IPs not trying to do harm. Lastly, if the attacker spoofs IP address, then they can target to make you shut down IPs as they wish.

Disclaimer - I never recommend that someone put a server onto the public Internet (especially Windows) without the expertise of someone who knows all the intricacies involved. Your best case scenario is a very hardened system that is as protected as is possible considering the nature of the services it has to provide to the public Internet, but still vulnerable in ways which you know and your business have assessed and decided risk accept. Your worst case scenario is thinking your server is well hardened and protected, but isn't and you find that out in a way that costs the business huge amounts of lost revenue, fines, legal liabilities, and/or impact to reputation. Moreover, even if the security is very effective at time of deploy, it is not untypical for that security to fade as time goes by -- so there is an ongoing operational aspect to think about.

My answer is not intended to do anything more than help you think about this.


Can SSL server choose a session ID '0' in the 'Server Hello' message?

From RFC 5246, section 7.4.1.3:

  The server
        may return an empty session_id to indicate that the session will
        not be cached and therefore cannot be resumed.

So yes, the server may return a session ID of length 0. This is allowed. Note that the server may also send a bunch of random bytes and simply refuse to resume any session; the overall effect would be identical.


Is there value to signing microservice calls with an HMAC derived from the same private key?

If client and server share the same private key, private key basically turns into as a symmetric secret, thus nullifying any use-case relevant for SSL, or, FWIW, any signing scheme.

It's basically integrity without authenticity.


array_rand calls mt_rand internally. This is a Mersenne twister algorithm with a state size of 624 numbers. This means that if you get 624 consecutive outputs of mt_rand, you know the whole state and can predict all future numbers.

As you correctly indicate it is pretty hard to obtain the output of mt_rand in real-life cases, because it is typically limited to some range. This is not necessarly a problem for the attacker: if the application calls mt_rand(0, 8) the attacker only knows three bits of the state, but he also needs to predict only three bits to predict the algorithms output.

Another practical problem with cracking PRNGs is that the attacker needs to request tokens from the same process, because different processes have different PRNG states. Typically when you connect to a server the request gets handled by a random process. You can do up to 100 requests on one connection, but this is still short of the 624 requests you need to get the state of mt_rand.

In your example you call array_rand 12 times, so the attacker does not get any intermediate output of mt_rand. There are too many combinations here to brute-force.

So this could be practically secure, but it would be risky. One application I looked into also used mt_rand for token generation, and then had another page that called mt_srand(). This made it possible to seed the PRNG with a known value. I also wrote something about cracking the PHP PRNGs, although it does not go into mt_rand state cracking.


Yes, 16 characters is more than sufficient, if they are randomly generated using a cryptographic-strength PRNG.  If you use lower-case, upper-case, and digits, and if you generate it truly randomly, then a 16-character password has 95 bits of entropy.  That is more than sufficient.  Actually, 12 characters is sufficient; that gives you 71 bits of entropy, which is also more than sufficient for security against all of the attacks that attackers might try to attack your password.

Once your password is 12 characters or longer, the password is extremely unlikely to be the weakest link in your system.  Therefore, there's not much point choosing a longer password.  I see people who recommend using a 60-character password, but I don't think there's any rational basis for doing so.  My view is that usability is very important: if you make the security mechanism too hard to use, people will get annoyed and may be more reluctant to use it in the future, which isn't good.  A secure mechanism that isn't used isn't doing anyone any good.  That's why I prefer to choose a shorter password, like 12 characters or 16 characters in length, as it is perfectly adequate and more usable than a monstrous 60-character beast.

Be careful how you choose the password.  You need to use a cryptographically-strong PRNG, like /dev/urandom.  For instance, here is a simple script I use on Linux:

#!/bin/sh
# Make a 72-bit password (12 characters, 6 bits per char)
dd if=/dev/urandom count=1 2>/dev/null | base64 | head -1 | cut -c4-15

Don't try to choose passwords yourself.  Human-chosen passwords are typically easier to guess than a truly random password.

One very important caveat: There are other issues as well, beyond password length.  It is very important that you turn off WPS, as WPS has major security holes.  Also, I recommend that you use WPA2; avoid WPA-TKIP, and never use WEP.


So the answer to this is that there is no exact right answer unless someone here has exploited the same exact issue in an almost exactly similar way before. Unless there are absolutely no protections against XSS on the site, then it’s usually a bit of a cat and mouse game between the server admin and the attacker (you). The server admin will attempt to thwart your attacks using methods such as HTTP headers set on the web server, Content Security Policy (CSP), escaping user input, validating user input, sanitizing user input, and many more.

In this case, it appears there are certain protections in place, so you need to learn how the code is working to be able to properly attack it. I would recommend looking at source code, using a proxy such as Burp Suite, looking at HTTP headers, and doing a bit of googling.

Since I’m lacking the surrounding information in this case, I’m unable to tell you exactly how to leverage the site with XSS.

But addition, any of the edits you are making are not being processed on the server. XSS is a client side attack that is loaded and executed in the browser, but in the case of persistent XSS is merely stored on the server and served to clients.


Penetration testing preventive or detective control?

It is always preventative.  Detective controls detect an intrusion in progress.  A penetration test is not an intrusion as it is an intended and approved use of the system, even if the use is simulating a breach.  It is a preventative measure to keep actual attacks from occurring by finding holes that need to be fixed.

The argument could possibly be made that they are also corrective if you characterized it as an attack, since the intent is to make corrections to the system, but I think this is a weak characterization as the entire point of the activity is to prevent a real attack in the first place, thus preventing the attack.


Is there a safe way to use external display with USB Type-C laptops?

You could disable removable storage devices using group policy while still allowing the other devices such as monitors to function. I believe this is something similar to what we do: https://serverfault.com/questions/576768/disable-usb-mass-storage-access-on-client-machines


In which settings is it possible to launch a HTTP Response Splitting Attack but not completely replace the HTTP message?

Let's see what are the usages of Splitting attacks.
But first thing to remember is that the final target is not the attacker, but HTTP agents between the attacker and the backend having the splitting issue. And one other detail, all this works using HTTP Pipelining (where you can send several requests without waiting for individual responses).
One of the first usage is security filter bypass. You send 2 requests, but the splitting occurs on the first one and the backend respond with 3 responses. The second one is the new one, it's based on a query that the first did not saw (let's say the  ssl terminator or a reverse proxy cache, or any http load balancer). or this agent there were request 1 and request 2, and when receiving back 3 responses it will usually discard the 3rd response. Then content of response 2 comes from a hidden request (like a request which was hidden in the 1st request body, and only 'discovered' by the backend -- because there's an HTTP splitting issue exploited on this backend).
The very fact that this request was hidden prevents the first agent from applying any security rule on this request (let's say this Load balancer should prevent access to /admin/* urls, now you can hide the /admin/ request and use splitting to get the /admin response on an innocent /foo query).
Attacker        Reverse Proxy cache         Backend
  |                  |                        |
 req1[reqA]------->req1[reqA]--------------->req1,
 ,req2               |                       reqA, <-- splitting issue
  |                 req2-------------------->req2
  |                  |                        |
  |                  |<---req1, respA, resp2--+
  |<--- req1, respA--+                        |

Next usages is Cache poisoning (instead of asking /admin in the hidden request you ask for /script.js and you set the 2nd request url to /, now / content will be replaced by the script content instead of the home page in the Reverse Proxy Cache).
Third classical usage is quite hard to implement, but it works with incomplete responses or incomplete queries. With responses or queries from other users completing the incomplete responses or requests. That's usually more a thing with request splitting than response splitting. But the main idea is to get a request or response with elements coming from other users (in the case of request you could get the cookie or bearer tokens of other users added to your headers, in case of response this is more about the page content). You can get more detail on this type of attacks on all HTTP smuggling papers.
I can think of another bad usage, the complete mix-up of all requests and responses. On my first example I've been nice saying that the 3rd response was discarded. Some bad HTTP agents could also become completely crazy when the counter of requests and responses are bad. And they could start sending wrong responses to everyone.


I am working at URIports and checked our stats:
We are processing millions of CSP reports daily and found 99 CSP violations on 14 different domains containing div.show since 2020-07-01. Triggered by multiple versions of Firefox and Chrome on Windows, Linux and MacOS. This is probably caused by a plugin or extension.


HTTPS icon red and crossed out - Chrome browser

When the https portion of the URL in Chrome has a red line through it, there is a problem with the security of the site you are going to.  To see exactly what the problem is, you need to click on the padlock and see the detailed connection info.

Detailed connection info is documented here.

If you see , then you've established a secure connection with a trusted site, and do not need to worry about MITM attacks.

If you see , then the connection is unencrypted, and subject to MITM attacks.

If you see  or , then either the connection is only partially encrypted or it's encrypted with a party that's not trusted (e.g., a self signed cert, name mismatch, or imposter).  In these cases you may be subject to a MITM attack.

With these last two, the level of exposure varies.  It might be that the remote site is properly encrypted, but just happens to have a few "IMG SRC=http://..." tags that cause mixed content.  That "mixed content" can be sniffed on the network.  Or, it might be that you've gone to an impostor site "gooogle.com" instead of "google.com", and everything you send is encrypted but going to a malicious attacker.  Or anywhere in between.  The rule of thumb is, essentially, unless you understand why it's red, you shouldn't trust it.


Block hex encoded requests using fail2ban

Fail2ban is nice to block attacks that generate a expected output, like login attemps or similar stuff. In your case, you are receiving requests with shellcode. That shellcodes are some kind of payload to try injections or similar (sqli, command injections, etc). So to protect to these kinds of attack what you need is a WAF (Web Application Firewall).


You can specify the DNS servers to use in your OpenVPN client configuration.

So for OpenDNS it would be the following:

dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220


Secure REST API that only works for users authenticated by App with SSO (OAuth?)

You need to setup something called Federation Services.

  AD FS in Windows Server 2016 [AD FS 2016] enables you to add industry
  standard OpenID Connect and OAuth 2.0 based authentication and
  authorization to applications you are developing, and have those
  applications authenticate users directly against AD FS.

Reference to first image
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers

Here is the tutorial for second image
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/single-page-application-with-ad-fs

If you are cloud friendly, it's pretty straight forward with Azure AD and there are plenty of guides available https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/what-is-single-sign-on


In openssl cipher suites, does AES128 imply AES128-CBC if another mode is not explicitly mentioned?

Yes. The OpenSSL names are slightly different to the standard names. The man page here has the mapping:

https://www.openssl.org/docs/man1.1.0/apps/ciphers.html

In particular see this:

TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA

So the OpenSSL name AES128-SHA corresponds to the standard ciphersuite using RSA and AES-128 in CBC mode.


If a file on USB drive shows a certain "date modified" time in the windows explorer, can the correct added date/time be checked for the file?

Can it be checked if the file/directory was actually copied to the drive at a later time and not at "date modified" time that shows on the usb-drive-2?

Date stomping is the problem.  It's a technique where nefarious behavior is masked by editing the dates of files.  And it's incredibly simple--here's an example on Windows in PowerShell:

(Get-Item '.\somefile.lnk').LastWriteTime = [datetime]"10/26/2018"

With that being said and forensically speaking, there are places in the Operating System (on Windows) where, while not impossible, is significantly harder to alter.  There is a master file table on Windows at the root of C:\$MFT which is hidden but tracks all file events.  These are commonly referred to as MAC times (modified, accessed, created).

There are tools in a number of different suites to interrogate these parts of the file system and create searchable timelines for file level events--this is often used in malware hunting.  SANS has a distro called SIFT workstation where forensic tools can analyze an offline disk or disk copy (via 'dd' or other disk cloning capabilities).  There are also expensive forensics tools that allow you to interactively pull this information from an online machine.  FTK, EnCase, and the Sleuth Kit are probably the most well known.

However, this only tracks traditional disk-level events.  USB device copying events are not tracked by Windows -- you need third party software for this.  With the aforementioned software though, you could get a better feel for what happened on drive-1 and then correlate those MAC times (via the $MFT) to what Explorer is saying for the USB drive to get a rough idea.


allowing users to add custom html/js code and show it only under another domain

Based on this description you have a "secure" and "insecure" domain. Both domains have the same possibilities, use the same layout etc. The only difference is that the insecure domain also allows insecure things in addition to all the other things.
In this case an attacker could likely motivate the user to actually use the insecure domain instead of the secure one. It looks the same and behaves the same so it seems to work. Only now attacks like XSS can be mounted successfully since insecure things are allowed on this domain.
To prevent this you not only need to allow insecure things only on the insecure domain but also prevent any confusion between these domains, best by not allowing sensitive things on the insecure domain at all (i.e. no login, no user sessions etc - or at least no shared user base).


possible to exchange public and private exponent in RSA?

Exchanging the public and private exponents in RSA incurs two problems:

It does not work.
It is insecure.

The "does not work" is about existing deployed implementations of SSL in clients. Though the formal definition of RSA allows for an arbitrarily long public exponent, some widely deployed implementations of RSA expect the public exponent to fit in a 32-bit integer (in particular, Windows' CryptoAPI).

The point about insecurity is that a too short private exponent weakens the system. An attack has been demonstrated, which shows how to recover the private key if the private exponent length is less than 29% of the modulus length; this means that if you use a 2048-bit RSA modulus (as you should), and you set the private exponent length to less than 600 bits, then an existing, already described an implemented attack applies. The collective wisdom of cryptographers is that private exponents significantly shorter than the modulus are too huge a risk.

Therefore: no, you should not try to shorten RSA private exponents, however tempting it may be.

If you are short in computing power, then you might want to investigate alternative algorithms based on elliptic curves. An "ECDSA_ECDHE" cipher suite would avoid RSA computations, and should provide substantially better performance for the TLS handshake (however, it won't be compatible with IE 8 on Windows XP as a client).


Combine SNORT detection and log with active response OSSEC

There is a solution from https://www.alienvault.com/. They offer a product that incorporates HIDS and NIDS in a box. They actually use Suricata and Ossec.


Which encryption algorithm is used in password protected *.pfx/PKCS 12 certificates?

All the specs for the PKCS#12 format are defined in RFC7292.

The short summary is that a .p12 file (and I assume also Microsoft's older PFX format, but I've never worked with them) is just a container format that specifies the structure of this file, but says nothing about what kind of data should go into it.

To use a very bad analogy, the spec for Microsoft Excel's .xlsx format specifies the structure of an Excel save file, but does not tell you anything about what data or formulas it is allowed to contain; that is controlled by which version of Excel you're running.

If you were to pop open a .p12 in a hex editor, you would find that one of the fields in the header is AlgorithmIdentifier: _____ where the program that created the .p12 records A) which encryption algorithm was used to encrypt the data, and B) which hash algorithm was use to turn the password into a key. As far as I know, there is no definitive list of what is allowed here; the program creating the .p12 can use any AlgorithmIdentifier it wants, including making up one.

For example, if I was writing software to read and write password-protected .p12 files, I could set AlgorithmIdentifier: AES256WithPBKDF2 and that would be fine. But I could also set AlgorithmIdentifier: MikesCipherWithCatDoodles, and as long the software at the other end known what to do with that, it's still fine.

TL;DR: The PKCS#12 format only specifies the structure of the file, it does not list which algorithms are legal, so the actual encryption algorithm used will depend on which software was used to create the .p12 file.

If you want to know which algorithms are used to protect your .p12 files, look up documentation on the software you are using to read / write them.


Secure copy-paste from phone to computer

I know this isn't a direct answer, but per your request in comments, I am submitting it.

Instead of rolling your own protocol, take advantage of existing protocols to do what you need. Your spec describes a web-based protocol with encryption and limited access to data passed from phone to PC. This web service needs high availability and uptime.

Twitter can fit your bill. Set up a separate Twitter account for this purpose and compose protected tweets that contain the password that you want to pass from your phone to the end point. The only thing you need to introduce (maybe!**) is a simple symmetric encryption of the password. So, your operational task is simple:

copy the password from your phone's Keepass
process the password through encryption
send the cypher text as a protected tweet to yourself
on the PC, capture the cypher text and decrypt it
paste into final application as the password

With the Twitter API publicly available, you could accomplish all this in a few lines of Python code.

**All of this complexity depends on your need for the password to be transmitted encrypted. If you use Twitter, the channel is encrypted (TLS), and if you use protected tweets, no one else can see the text. You could simply send the password as plaintext IF you determine the risk is acceptable. If you go the unencrypted route, I might suggest that your password be as random as possible so that if the plaintext did leak, it would not be obvious that you were sending yourself passwords (e.g. not "thisIsMyBankPassword1!").


What's a practical example of encryption "in use" or "in process"?

Lets first define what encryption-in-use is. Its a capabilitiy that lets you run your computation on encrypted data or run encrypted application.
There are two ways to do this. There are pros and cons to each, but they are complementary in most use cases.

Hardware-based trusted execution environment (TEE). Intel's SGX or ARM TrustZone is a good example.

Software-based. This is relatively new and not used much outside of the research currently. Multi-Party Computation (MPC) and Homomorphic Encryption are two popular choices.


Well, you can look at the transactions for every single bitcoin transaction that has ever happened, but that doesnt mean that the transactions will actually reveal the information about the wallet holder, other than their public key.

If you want to learn more about what transactions that account has been involved with, you can check out: Blockchain.info  or Block Explorer.

If you want to find the personal details about the account holder, you will probably need a warrant and go knocking on the exchanges associated with the account you have in mind.


"Phishing" red flags and countermeasures

Phishing "red flags":

Any un-solicited communication regarding any account you have.  Certainly, this criteria is the easiest one to have a false-positive hit on, and probably shouldn't be the only clue you act on,  but it's also your first clue.
Any un-solicited communication regarding any account you don't have.  There's definitely something wrong, if it appears that an organization with whom you have no business relationship is contacting you.  These require careful consideration, and may necessitate additional defensive actions.  Generally, a communication of this type is one of three things:

Spam
Phishing
Evidence of identity theft

Un-solicited, or unexpected e-mail attachments.  Anymore, I actually get a little irritated by anyone who sends me an attachment in e-mail without advance notice or request.  There's so many other ways to share data over the Internet and across intranets these days, that e-mailing it as an attachment is rarely an actual necessity.  If there's a form that you must fill out, or document you really need to read, most legitimate organizations will post it on their official website somewhere that you can access it with an appropriate level of security.
Requests for you to send your username and/or password, or other personal details.  No legitimate organization should be requesting any of this from you, via a contact that they initiated.  Also, no legitimate organization will ever ask you for your password via any person-to-person contact.  Common phrases used here are "verify your account" or "confirm billing information".
Proliferate spelling, grammar, or factual errors.  Some phishers are getting better about avoiding this, but it is still a common hallmark of cheap phishing attacks.
An overwhelming emphasis on urgency.  Phishers often want you to think you must rush to action, so that you might not take enough time to realize their scam.
Overly formal, yet very generalized salutations.  Stuff like "Mr/Mrs" or "Dear Sir or Madam" or "To Whom It May Concern".  Unless this is a message you're expecting, and the tone is appropriate for the context, the unnecessary cordiality is probably just being used to warm you up to buy snake oil.  Most legitimate organizations know their audience, and will customize their greeting to either identify you by your first and/or last name or username, or will have a greeting that specifically identifies you as their customer.
Anything "too good to be true".  You know the old saying.  This is also another very general indicator that should set off anyone's alarms, regardless of how the "deal" is conveyed.
FROM addresses that don't match the REPLY address.  This is another criteria that may be prone to false positives, but should still raise your level of suspicion.  Many legitimate organizations that send mass e-mails will more than likely be doing so from an address dedicated for that purpose.  So, a legitimate e-mail will probably include either non-e-mail-based follow-up instructions, separate follow-up e-mail addresses, specific instructions for replying to the e-mail (keywords for subject and/or body), and/or a specific notice stating that direct replies to the e-mail will neither be received nor answered.
Hyperlinked URLs whose targets do not match the link text.  Before you even think about actually clicking on any hyperlink in an e-mail, hover your mouse over it for a second to see where it really sends you.  If the link text is http://google.com/ but the link actually points you to somewhere else like http://lmgtfy.com/*, you probably don't want to go there.  Such link may appear like this:  http://google.com/  (Mouseover to see actual target.)
Hyperlinks that use shortened URLs.  This criteria may have a lot of false-positive hits, but still warrants some cautionary measures and perhaps a raised level of suspicion.
Hyperlinks with very long and complex targets, even to "legitimate" websites.  These may possibly be cross-site scripting attacks.

*http://lmgtfy.com is actually a benign website, and was only used to provide an example of URL link-text not pointing to where it says it's pointing.

Phishing countermeasures:

Stop, breathe, and think.  No matter what they tell you, don't let yourself get into any rush.  If someone is initiating a contact with you, taking time out of your day, they can stand to wait a few minutes (or even hours) while you sort things out for yourself, and decide what you're going to do.
Do not offer any information.  This is what phishers want.  Even if you're not giving them the specific information they're asking for, you may still be giving them something else they can use against you later.
Do not open any e-mail attachments.  Just.  Don't.  Do.  It.
Do not follow any hyperlinks or URLs.  Again, just don't.
Do your own research.  Google.  Wiki.  Snopes.  Repeat.
Do not do anything they ask, in the way they want you to do it.  If it's a legitimate communication, you'll be able to find your own way of doing what's asked of you without them.  For e-mails wanting you to go to a specific URL, instead go to the known-good-and-trusted HTTPS website of the organization and find your way to the requested function from there.  For phone, mail, or other interactions, end the conversation and go use Google or the organization's known-good-and-trusted homepage to find (or verify) the correct contact information for follow-up.
Do not reply.  This goes along with not doing what they ask, how they ask it.  Again, if the contact is legitimate, you should be able to follow up without actually answering back to the solicitor themselves.  Even if the e-mail appears to come from an address referenced on a legitimate website, do not use the reply function.  Instead, use a link or form on the known-good-and-trusted site, or manually fill in the e-mail address on a new message.
Just say no.  To drugs, and solicitors of every kind.  Whatever service they are offering is not one that you need them in order to acquire.  If the offer is legitimate, you will be able to find a comparable level of service via your own research, and likely through safer and more secure mechanisms.  If they really insist that they need to get credit for the service, take their information and do your own research and validation before doing any business directly with them.
Ask a pro.  When in doubt, ask someone you trust who's "in the know" about these things.  This may even just be part of the "Don't do what they ask." step - the purported organization's help desk (which you'll look up yourself) should definitely be able to tell you if the contact was legitimate.


Is SSH server secure from internet access outside private network?

SSH is a professional grade protocol, and most server and client SSH software have been intensively scrutinized for possible flaws, so if you use it in a conformant way it is secure.
Simply best practices recommend to have more than one defense line. If you want a professional grade security, you must behave as a professional admin:

if it is an option, prefere ssh keys to passwords, because they are deemed impossible to guess
add an additional defense line at the router level by ensuring that no input connection to a SSH port are allowed - for a private network, ensure that no incoming connection at all are allowed
add a last defense line at the server level by only allowing local addresses

It implies a bit of configuration but security only comes at that price.


Why are Certificate Revocation List periodically renewed?

A couple fundamental things:

The basis of a CRL is a promise for a certain time period.  That means a begin time and an end time.  Once a CRL is made and signed, it can't be changed, so it lasts as long as it lasts, and can't be trusted after that.
In essence, you won't know until you check.  A CRL in its regular form is one big list.  You can't assume that the size is an indication... the verifier needs to know exactly what Certificates are no longer trusted.  So you need to get a fresh copy, either way.  There's no protocol to check "is this the same as my old one?"
The primary implementation of CRLs is not "go get one when you need it" but "get it ahead of time, and check it when you need to".  Which means the primary mechanism of distribution is a series of file downloads and caches.  A server won't know that the next CRL is exactly the same as the currently expiring CRL until it has both - at which point, if you have a fresh version, why check?  If what is needed is a "ask when you need it, you'll always have access" sort of structure, then go with OSCP.
The basic rationale of validity dates is to allow PKI implementers to make a conscious decision about how long to go with out checking in with the CRL issuer.  A PKI system will make this decision on an issuer by issuer basis, in accordance with the risk to the system and the patterns of its intended usage.  It's a real challenge - the validity should be commensurate with the risk - how long are the system protectors willing to wait before checking in on the "known bad guy" list?
There's a basic premise here that I relate to looking at canned food in a submarine...  the expiration date is how long the manufacturer promises that it'll be OK to consume it.  Can you eat meat a day after the expiration date?  Yep.  In fact, day-old meat is a way better option than starving to death.  What about meat that is 6 months past it's expiration date?  Well.. what kind of germs are you up against?  There's a real possibility that this food will make you sicker than not eating anything (just shutting down and doing no transactions until you have a fresh CRL).  In all cases, the reality is, you weight the cost of doing business against the risk of uncertain data.

NOTE:  All this applies only to a general, garden variety CRL.  There's a number of alternate formats out there.  Last I looked, they were all proprietary... but it's been a while...  some of these alternate formats can work differently, as they all aim at simplifying.


In house mitigation for a volumetric DDoS attack

It depends a bit on what you consider "in house". You cannot filter volumetric attacks once they're on your network, since your external link(s) are saturated.  So the filtering has to be done before traffic hits your external link(s), for example by your upstream provider(s) or by some dedicated scrubbing service. This can either be blackholing (discarding all traffic to the target), or scrubbing (dropping unwanted traffic while letting valid traffic pass).

If your network is running BGP, the triggers for deciding to do this can often be coming from your network, for example by using a remotely triggered blackhole, which uses a BGP session to indicate to a BGP upstream that traffic to a specific target should be discarded, or by injecting more specific BGP routes which divert the prefix which contains the IP address which is under attack via a scrubbing center.

If your network isn't running BGP (but uses an upstream provider for this), an upstream provider may provide blackholing or scrubbing services, either automated (based on anomaly detection) via a customer portal or after contacting them.


provide data integrity of a file F with AES

One way to create a MAC from a block cipher is cipher block chaining message authentication code (CBC-MAC).

  I thought at the following protocol

I would think there is some way that you learned during the course. Such questions generally don't intend for you to come up with your own scure crypto protocol.

  Could this approach work well? How could the attacker do?

Basically you use the encryption of the file as the MAC. This is secure, but impractical. Your MAC would be about as big as your file, which doubles the size of every transfer.


How long is the key they provided? The strength of that key is the strength of any alphanumeric password of that length. Theoretically, anyone that random types characters may be able to guess your gmail password or any other password, but because the number of possible values is very large, the chance of doing so is very small (unless your password is "12345").

By having a key consisting of only letters and numbers, the possible password set is reduced, but if the key is long enough and random enough, you should be ok.

The strength of the password protection is actually given by many factors, the password strength being just one of them. A few others are:

Does the account block if you try a lot of keys? Are the keys associated with usernames, or they are the single information you need to access the website? Is https used (I saw that it is)?


How does gpg know that a passphrase is bad in symmetric encryption?

The answer is given in RFC4880, http://www.ietf.org/rfc/rfc4880.txt in section "5.7.  Symmetrically Encrypted Data Packet (Tag 9)"
In short, the key generated from the passphrase is used to encrypt a block of random data, and two last octets of the data are repeated. This encrypted data is included in every symmetrically encrypted message, in the packet. GPG first decrypts this block with a given key derived from the passphrase (see string-to-key in the RFC), and checks that the last two octets are repeats of the previous two octets. If not, the passphrase is definitely not correct. If yes, the passphrase MAY be correct. Then the decryption of data occurs.

Hence, no hash is stored in the data packet.


The complexity level will be down to the algorithm attempting to test against, the skill level of the attacker, the speed of the machine(s), and time.

Your scenario is a known plaint text attack. Where by the attacker adjusts their results based on what is inputting and then outputted.

You say attacking a TPM, while this is a reasonable example as the TPM in most modern computers makes use of strong algorithms such as AES I don't think even malware could conduct a meaninglful known plaint text attack against it in a feasible timeframe. Therefore in direct answer the complexity would be very difficult and impractical.


What is the deal with Valicert SSL root certificates?

The "ValiCert Class 2 Policy Validation Authority" root from 1999, along with about a dozen other roots from ValiCert and other CAs, are being phased out because they're only 1024 bits. 1024-bit RSA is increasingly close to being breakable1, so the community has decided to get rid of them in an orderly manner by 20112 to prevent a major security incident and panic in the coming years.

Mozilla's stated policy was to disable them some time after December 31, 2013, and they have been actively working with the CAs to do so.

In other words, yes, you have to replace it. What's the problem? I realize it's unpleasant3, but you have to renew it annually anyway, and this is less work. Maybe your CA will be willing to compensate you for the inconvenience you've suffered as a predictable consequence of their decision to use an obsolescent technology long after its sell by date.

1 I wouldn't be surprised if certain agencies could factor them -- slowly -- but I might be a little paranoid.
2 Wait, what's today's date again?
3 I remember Heartbleed.


How to hide local network traffic on my computer?

You would need a kernel level driver that could subvert the network stack.  Practically, it's going to be pretty difficult to do.  It would effectively require a rootkit since generally the IP stack on your computer (part of the OS) handles all traffic on behalf of apps and you would have to bypass this.


Scan multicast IP range on specific port using nmap

If you asking if nMap can scan networks based on a mask then,  yes it can do so.

The details have been given here:
http://nmap.org/book/man-target-specification.html

As for the error you are getting. Some quick web searches and previous programming in Python indicates a driver error, which may be resulting from a glitch wherein nMap can resolve the hosts IP for an undermined reason.

If getting the job done is priority try an alternative approach.

Use a mask converter or maths to get the range of IPs to scan.
http://jodies.de/ipcalc?host=239.35.0.0&mask1=16&mask2=
Then, issue this command in nmap. nmap 239.35.0.0-239.35.255.254

Note: Neither StackExchange or I promote unauthorized illegal port scan of networks. This answer is merely to inform you about the capabilities of nMap.


Why is it bad to connect internal systems to the Internet?

First, it might be best to fully understand the client (your boss's) needs. It's possible he or she only needs access to one small subset of the data on this server from anywhere and not necessarily all of it.

Where possible, instead of saying no in this situation come back with a few options.

VPN so people travelling, can access the data wherever they are at. If possible add additional security controls like internal firewalls and Data Loss Prevention (DLP) if needed. Harden and add additional security controls here as necessary.
Strong authentication and encryption to a separate server which contains a small subset of the data but possibly not all of the sensitive data. Harden and add additional controls here as necessary. Only allowing the server with the sensitive data to push data to the one that can be accessed publically and blocking all packets from the publically accessible server going back to the one containing the sensitive data can be a helpful trick (one-way firewall rule).
Create a secure front-end server which can be accessed from anywhere and has controlled access to the backend server. Harden and add additional controls here as necessary.
Harden the server itself and if applicable deploy a WAF, or other controls, in front of it.
Think of other creative solutions depending on your boss's actual needs (your question isn't specific about the actual needs).

No matter which option is chosen make sure you log and monitor access to the system. It would be wise to follow up with your boss after the system starts getting connections from other countries (or at least IP's that are obviously not from people who work with you) and show him or her the global connections to the system. Sometimes this real-world feedback is required for people to understand that the risk.

Use this as a chance to educate your boss but do so in a very humble manner sticking strictly to real data, he may have had too many people selling security to him with Fear, Uncertainty, and Doubt (FUD) and may simply not listen to anything that sounds similar regardless of how legitimate this information is. Beware of FUD fatigue. If he or she has reached their limit anything you say in this respect will have the opposite effect you want. When this occurs your best solution is delivering factual data and allowing him or her to come to their own conclusions.

Be a problem solver here, provide your boss with solutions, rather than simply with reasons to say no. Don't be afraid to propose expensive solutions that you think are too expensive for the company, your boss may be ok if it moves functionality forward quickly for him or her. That said when possible, always keep security as inexpensive as possible long-term (avoid recurring costs that may get cut during an economic hardship). View this as an opportunity for you to get more security in place by enabling the business rather than fighting it. If you show that you can empower the business and frame needs in terms of what moves the business forward or how things could affect the business you'll get much better response from people like your CEO. Understanding when the business is in a rush is important too, it's not uncommon for a company to pay more money for a solution or approve things which they might not otherwise approve if it can add value and be deployed quickly. To this end, knowing when to time requests and understanding the urgency of the projects in flight will also help you.

Think of this part of business as a martial art, you want to leverage your opponents energy and redirect it to a place you want them to go while minimising your own energy expenditure. If you can quickly grab his or her desire to have this accessible, now might be a great time to get a lot more security in place. Speed is important here and you need to get buy-in while it's hot so to speak.

Finally, recognize that you will be much better off addressing this as a business problem that you can help with, rather than just a technical security problem. Likewise, start looking for and anticipating additional security needs going forward and bring them to your boss early on so you look like someone helping the company rather than as a roadblock to progress. This bit of framing accomplishes the same objective but gets security in faster and with less conflict.

Addition after original post: One thing that may also be helpful for you is to create a long-term security roadmap and share that with your organization. What this entails will be different for every organization but it's very important to show the work you are not currently doing and also work that may be things your organization will never do internally (small start-ups are less likely to have forensic teams in-house). The reason for this is to help educate and also to help set expectations with your leadership team. This is something many security teams have in their head but formalizing a plan and showing a path forward can help you get more buy-in for your security program. A large part of this is about communication and having a shared vision business-wise but another part of this is about educating senior management about where they are risk-wise. I find that visualizing your organizations security-debt helps people automatically make more thoughtful decisions.


Is it possible to update the contact info (FN/LN, OU, Organization,..) of a certificate?

No, if you changed those informations on the certificate, the fingerprint changed, and the signature is invalid.
You will need to issue a new certificate.


How to determine which Browser Certs to reenable on a per-case basis?

AIA chasing?

  TLDR: How to see the root CA of a cert that Firefox does not recognize, from within Firefox itself?

You don't directly get to see the root CA. But you may be able to see the immediately superior CA.

Some certificates (all?) have an Authority Information Access field that allows a certificate to answer the Who's your daddy? question.

(To get to the Certificate Viewer window navigate like this:
I Understand the Risks | Add Exception... | View... | Details)

In the case of example.com it's this: http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt

Top 15 Root CAs to get you started

Here's the top 15 root CAs from a scan of the Alexa Top 1 Million (2015-10 by Hubert Kario):

Root CAs                                      Count     Percent
---------------------------------------------+---------+-------
(d6325660) COMODO RSA Certification Authority 113492    20.662
(2c543cd1) GeoTrust Global CA                 107601    19.5895
(eed8c118) COMODO ECC Certification Authority 48977     8.9166
(cbf06781) Go Daddy Root Certificate Authorit 47939     8.7276
(5ad8a5d6) GlobalSign Root CA                 44123     8.0329
(b204d74a) VeriSign Class 3 Public Primary Ce 29359     5.345
(244b5494) DigiCert High Assurance EV Root CA 25999     4.7333
(2e4eed3c) thawte Primary Root CA             23372     4.255
(157753a5) AddTrust External CA Root          20188     3.6754
(653b494a) Baltimore CyberTrust Root          12053     2.1943
(ae8153b9) StartCom Certification Authority   9139      1.6638
(fc5a8f99) USERTrust RSA Certification Author 8775      1.5975
(3513523f) DigiCert Global Root CA            8281      1.5076
(4bfab552) Starfield Root Certificate Authori 8226      1.4976
(480720ec) GeoTrust Primary Certification Aut 5570      1.0141

Miscellaneous

Certificate Patrol Addon?

Have you tried the Firefox Certificate Patrol addon? Seems up your alley.

EDIT2015-12-03: Why does this not work for Wikipedia? HSTS!

I guess this does not work for Wikipedia, because wikipedia.orgis HSTS preloaded in Firefox (archived here).

And the "I understand the Risks" button is missing because for HSTS errors a "no user recourse" rule is enforced. This is by design.


Could my bank's two-factor authentication be hacked?

You are right in that one of the ways an attacker could intercept the code is to hack your phone. An attacker could also:

Clone your phone's sim, and request a banking code to be sent to your phone's number. they could also possibly clone a non-sim phone as well
Steal your phone. Once they have your phone they could perform transactions
Perform a man in the middle attack when you use your banking site. This has been done already, an attacker uses malware installed on your computer (a man in the browser attack) to direct your banking traffic to a site set up to mimic your bank's page. Or an attacker may subvert a system to act as a proxy. Either way When you type in the code the attacker gets it, then uses the code to perform a transaction
Social engineer your bank to change your mobile phone details to a phone they control. If an attacker knows enough about you, and your bank's procedures aren't tight enough, then the attacker could call your bank pretending to be you and get them to change the mobile number

So what can you do?

Keep control of your mobile phone.
Make sure your computer is kept up to date with patches and anti-malware software
Do all your banking on a virtual machine, and never save its state. If your virtual machine gets hacked and you save the state then the malware will remain in the virtual machine, however if you never save its state the malware won't be able to remain on the virtual machine
Many banks use some sort of authentication code to verify the identity of people calling. Write these down but do not put them onto your computer or phone, that way there's still something an attacker does not know, even if they have full access to your computer and your online identity.

It's not all doom and gloom, most of the time banks can reverse transactions if caught quickly, if you suspect that a fraudulent transaction has taken place get onto your bank ASAP and get their investigators on it. How well this may go depends on what the local laws are and how good your bank is.


It certainly isn't common though not entirely unheard of.

In the UK for example, there is a specialist health WAN where the ISP provides pre-configured router/firewall infrastructure that meets the set requirements of the network's code of connection. However, the COCO is set by a central body not the ISP.

You would need to look at the contract.

In general, you would never really trust such a setup unless you have direct access to the configuration and any logs. You would also want alerting for any changes and probably would want to audit the configuration at least annually.


This is hard to answer, because, depending on how hard an entity might push, anyone might still give away information/unlock his/her phone under a threat. However:

To mitigate accidental unlocks, you might want to have a messenger app with it's own lock, besides the phone lock.
To not being identifiable by the phone number itself, use a messenger identity that is not tied to the phone number
To however, identify you as a trusthworty source among your peers, use an app that provides a safe way to assert identities, with public/private key cryptography.

Threema, as already mentioned by @defalt, does all three. It's not free though, so you might want to look into similar alternatives.


The most simple way to block traffic by IP address is to use pf (man pf.conf). Here's a simple script to help you get started.

Warning Be sure to read the manual pages for more information and before running this.

# enable: sudo pfctl -e -f pf.rules
# disable: sudo pfctl -d
set block-policy drop
set fingerprints "/etc/pf.os"
set ruleset-optimization basic
set skip on lo0
scrub in all no-df
table <blocklist> persist
block in log
block in log quick from no-route to any
pass out proto tcp from any to any keep state
pass out proto udp from any to any keep state
block log on en0 from {<blocklist>} to any

You can use pfctl -t blocklist -T add 1.2.3.4 to add hosts to the blacklist and pfctl -t blocklist -T show to view the blacklist itself. To view the pf log, create a network interface with sudo ifconfig pflog0 create and dump its packets with sudo tcpdump -ni pflog0.


Would DLL hijacking work with load-time linking?

There are two types of linking: static linking and dynamic linking.  DLL Hijacking is when a malicious program takes advantage of dynamic linking.  For dynamic linking to work there needs to be a list of paths to find the shared library that is being linked.  In Windows there are various ways for the search path to be affected.  But there is generally an order in how the search is performed, and most applications don't provide a fully qualified path (e.g. C:\WINDOWS\system32\kernel32.dll) for the shared object that they plan to load.

What happens is an attacker will place a DLL of the same name in a location searched before the location of the legitimate DLL.  For instance, lets say the search path when attempting to load kernel32.dll is first C:\Program Files\MaliciousDir\ and then C:\WINDOWS\system32\.  The application simply calls LoadLibraryW(L"kernel32.dll");.

As long as the attacker has their version of kernel32.dll in MaliciousDir, their version will get loaded not the legitimate version.  This can be mitigated by providing a fully qualified path to the library you're loading.

Static linking means that the entire library was built into the application.  An entire copy is kept by the application, and all function addresses to that library are resolved at compile time.  Which means that there is no searching for the library, and an attacker can't replace the library itself.  The downside to this is that the application becomes enlarged by the size of the library, and updating the library itself means that the entire application needs to be updated.

In this case DLL hijacking does not work.


Relying on openssl's certificate authority list or provide my own

OpenSSL does not come with a list of trusted certificate agencies, it only has a default path where it looks for these CA. On Linux and *BSD this path is usually populated by the OS, often based on the list Mozilla uses in the Firefox browser.

But, there is no such list on Windows, because OpenSSL can not deal with they way windows stores the certificates. There is also no such list on OS X, but Apple added a hack to OpenSSL as shipped on Mac OS X to somehow integrate into their native key chain.

This means, if you want to have a controlled behavior you better ship with your own list of trusted CA. And if the program should only connect back only to your server it might be the best to include only the CAs relevant for this task.


Would it matter if my miner was hashing random vs incremental values?

I'm not familiar enough with Klein, but if you're using a strong cryptographic hash function, then correlations in the input should not translate to any correlation in the output. So using incremental input vs random numbers shouldn't make any difference, at least in theory.

Of course any weakness in the hashing function may mean that this is not the case.

However, if you are not the only person searching then you want to avoid searching on places that many other people have searched through. You are less likely to find a better solution than the current best solution if you are searching through parts that have been extensively explored. Many people probably also starts the search incrementally starting with 1, which is a highly explored range, so you want to avoid increment from 1. You would want to start the search with a random number, then keep incrementing.


XSS prevention by securing cookies locally

You cannot prevent XSS by using cookies, but you can prevent successful XSS attacks from stealing your cookies by setting the HTTP-only flag. HTTP-only cookies are not visible in the context of the javascript engine. This is the only connection I can see between XSS and cookies.

What you should look into instead, is the CSP (Content Security Policy) HTTP-header. It instruct the browser where its allowed to load content and scripts from.

There are many questions and answers regarding CSP that can aid you here.
https://security.stackexchange.com/search?q=csp


How does DNS Changer malware detection work?

All of this depends on the DNS resolution. If the request goes through the 'good server', then you will get the green-page. If your settings are bad, you will get the red-page.

You can check your DNS settings by typing ipconfig /all in your command line.
Here you can see the list of the bad settings".

To check how it works you could use nslookup.

nslookup dns-ok.us 8.8.8.8 - this one returns Address: 38.68.193.96 and traffic goes through the 'good server'.

nslookup dns-ok.us 64.28.176.0 - this one returns Address: 38.68.193.97 and traffic goes through the 'bad server' (from linked list).

Now type that addresses into your URL bar:
http://38.68.193.97
http://38.68.193.96
and compare the results.


This is a quite normal way of protection against CSRF.

What is CSRF? It is when an attacker tricks your user to click a link/button and trigger a function in your application that user otherwise would not like to trigger. For instance, an attacker tricks a user to place an order in your application with the attackers delivery address.

It is considered a good practice that any operations that change any data are only triggered via POST, PUT, PATCH, DELETE and that GET does not change anything. Then what will happen if an attacker tricks a user to trigger some GET operation? User will receive the data from your application that he can anyway see. There is nothing harmful in this. That's why there is usually no sense in protecting GET requests against CSRF.

Update:

After comments from the author below it seems that it is a single page application, because if HTML was rendered on server, server could inject the token and it would be not needed to request the token separately.

The case with SPA is addressed already, for instance, see here:

https://blog.eq8.eu/article/rails-api-authentication-with-spa-csrf-tokens.html
https://stackoverflow.com/questions/50159847/single-page-application-and-csrf-token

It is not wrong to get token in such way. But permitAll() should no be used, otherwise an attacker can create a request with a correct token.


Yes HTTPS is used. The thread doesn't say that the web app will be completely insecure, instead it says

This effectively reduces the security of your end-to-end encrypted communication to that of your SSL connection to the server

Which means that anyone who can control the SSL connection to the server can now intercept and break your e2ee communications. So who exactly can control the SSL connection?
Well, if a (state-level) attacker controls/compromises a CA, they could issue a fraudulent certificate for the Signal server and attempt to MitM the SSL connection (this threat is limited by the use of certificate transparency.) As @multithr3at3d pointed out, TLS inspection proxies at workplaces are a much more likely form of MiTM and could cause problems if your employer was interested in compromising your private conversation. However, in such a case, the employer owns the machine and would probably just install a keylogger on it, so you have bigger problems.
However, the larger threat here is that the SSL connection, as well as the content being served, is controlled by the Signal server. This means that if the server is compromised or goes rogue (which can easily be achieved by a government serving Signal a subpoena or the like), then it can easily modify the js files served to the client in a way that allows them to intercept the communications. This effectively defeats the point of end-to-end encryption, which is that nobody other than the sender and the recipient should be able to read the contents of the communication, since the server now has the power to compromise the communications at will.
This threat is amplified by the fact that such malicious modification of the code served can be done in a targeted manner. The server can ensure that only a specific user/client is served the modified malicious code. This significantly reduces the chances of the modifications being detected and exposed.

Actually we want to develop some chat service like signal with web-client, but this article made us confuse about should we ship a web-client or not, can anybody please explain it?

This depends on your threat-model (or rather the threat-model of those who will be using your chat service). Will those people just be using it for chatting with friends or communicating with colleagues? Or will it be used by whistle blowers trying to coordinate the disclosure of classified information with journalists? You will have to consider whether the risk outweighs the benefits and decide for yourself whether or not to ship a web client.
If its the former, then having a web client will not be a very big issue. This is closer to the use-case of WhatsApp and WhatsApp does have a web client.
If its the latter, then you had best follow Signal and stick to using desktop clients and apps which can be signed and their integrity verified.

As evident from the comments some people are confused about why these issues don't apply to the app and desktop client.
The reason is simple. The app/desktop client has to be downloaded once. It is also digitally signed so its integrity can easily be verified. If you are paranoid, you can also download Signal's publicly available source code and compile it yourself. If Signal attempts to publish a malicious update, they will have to publish its source code as well, and the chances are much higher that someone will notice the unexplained changes before any damage happens.
With a web app things aren't so simple. First of all, even if the web pages are digitally signed, checking their integrity and ensuring they match the publicly available source code every time is absolutely impractical. Secondly, a web app consists of several web pages. Checking the integrity of all of these even once would be a painstakingly difficult task.


How safe is it to allow key-based SSH access within LAN?

You can use SSH Jump host (ssh -J) to connect to the internal machine via the external facing machine. This setup means that the key materials resides in your workstation instead of on the gateway. When using jump host setup, your local workstation negotiate the SSH connection to the internal machines directly, so an attacker that pwned the jump host cannot intercept the connection to your internal machine.

If you want to initiate connection after you are connected to the gateway, you can instead use agent forwarding (ssh -A). Note that this is less secure than the jump host setup, as an attacker that pwned the gateway can in use the forwarded agent socket to create new connections to the internal machine. To protect against this, you can configure your local ssh agent to display confirmation dialog before the agent needs to sign a new connection. Note also though, under this setup, the gateway can intercept communications as the session will be decrypted by the gateway before forwarding to the internal machine. In general the jump host is preferred, but there are situations where agent forwarding makes sense, for example, if you need to transfer files directly between the jump host and the internal machine, instead of having to route through your local workstation.


Does displaying javascript content in application qualify as XSS?

When this is the code the attacker tried to inject, then this is the intended behavior of a secure web application. The application apparently escaped the javascript code correctly and demonstrated the ability to output it as text without executing it. Note that <script>alert('you can also "inject" valid JavaScript code into Stackexchange without it getting executed by browsers of any other users')</script>.

A different solution would be to filter the user input to remove any "evil" characters like <, >, ' or ". But such solutions are only the second best, because they might result in unexpected behavior in form of overblocking non-malicious input (What do you mean, my username can't be <'_'>?) or might not catch every "evil" character an attacker might come up with.


Yeah, if you are describing it accurately this is completely broken, to the point of useless.

The initial AES key is compromised by being in the app, anyone with the app has access to the AES key.  If this is global, then it is well and truly screwed, if it is unique to each application, there may be a small sliver of hope.

The SHA-1 is completely replayable.  You mention no salt, but even if there is a salt, the attacker can replay it against a legit client as a MitM and then respond validly to appear as the client to the server.

The server would then provide the attacker with the public key, in encrypted form, which isn't particularly useful to the attacker, but it is also the public key... it is supposed to be public.  Having it private offers nothing.  If the client was ever compromised (or any client if the AES key is global), then the AES key is leaked by the application and the public key is also available to the attacker.

Additionally, if the AES key is compromised, the attacker can send a public key of their choice since the client has no way to verify the RSA public key.

An AES key being generated on the client is a decent enough idea, but so far, there is nothing to prevent the attacker from generating their own AES key.  Additionally, they could likely provide the client with their own public key so they can also fool the client.

Why is the data being encrypted with the RSA key?  What is the point of the temporary AES key then?  Is it really completely unused?  Encrypting long data with RSA is generally considered less secure than using symmetric encryption since it is requires more work to process and may have other security implications, the norm is just to exchange a symmetric key and use that for data exchange.

In short, the system is completely useless.

It would actually be far more useful if they simply embedded the public key of the server in the application and used that to have the client generate an AES key and exchange that for session communication.  It wouldn't validate anything about the client itself, but that could be done through passwords or other tokens after the session is initialized.  At that point you are pretty close to just using a self signed HTTPS though, but it could be used as a custom implementation if HTTPS isn't an option for some reason (such as not being able to add a trusted root certificate on the client devices.)


Why do many websites hide input when entering an OTP?

I'm basing my answer on the assumption that a One-Time Password is used as a second factor, in addition to a traditional username/password combination. If this is not the case, and the One-Time Password is the only factor, then Gilles' Answer is certainly more applicable.

Most likely due to Cargo Cult Programming, which means blindly following patterns that have been observed elsewhere, without understanding the real meaning behind them.

A developer may see the "password" in "One-time password" and happily make it <input type="password">. Afterall, that's what it's there for, right?

Is there a disadvantage?

Security-wise, no. Disclosing a one-time password to a third party (e.g. through shoulder surfing) is not as problematic, because the password loses validity after one use, or after a certain amount of time.

The only imaginable downside would be a lesser user experience, as a user might have trouble ensuring that what they have typed actually matches the password they received.