I was the subject of a low-impact DNS attack. What do I need to do?

If the A record was visible in your NameCheap web interface, then your account will have been compromised. Probably via a weak password.

However, it is possible that NameCheap's servers are also compromised, you really have no way of knowing unless you put in a new, very strong password and/or 2FA as you have and then you get the same problem again. Any decent hacker though would detect that you'd undone the hack and would avoid you.

The other possibility is that your PC is compromised so you should double check that.

I also recommend that you set up an automated monitor using one of the many free services. It should check the content of your page and if it changes, you should get a notification.


Should I be concerned if my employer is performing man-in-the-middle HTTPS attacks?

As promised, here is a copy&paste of my answer to your previous question.

Ok, you've found your company's CA cert in your java trust store. That tells us that they have the ability to perform the MitM attack that you are describing, but it does not prove that they are actually doing it. That cert may be there for a completely legitimate reason, like for example so your VPN client can authenticate the VPN server, or so you don't get certificate errors when connecting to internal network resources. As @schroeder says, this is completely normal behaviour for companies that issue laptops or have BYOD policies. In this case, it seems like they installed the certificate so they they can code-sign their java applets. It also sounds like they did a bad job of setting up their CA since they have not provided revocation information for the certs. There is nothing in your question to indicate that they are doing any HTTPS interception.

To be sure that they are inspecting HTTPS traffic, you need to actually catch them in the act. When you make a TLS connection that you suspect of being MitM'd, look at the server cert you are presented; if it chains to your company's CA then that connection is being MitM'd and you'll have proof, but if it chains to a publicly trusted CA then it's secure.

You'll need to do some digging about the java application you're using to figure out how to see the details of each TLS connection (you may be able to do this through JVM settings, but I'm not sure). Browsers, for example, are quite good about showing you the details of the TLS connection.


Found some malicious Javascript - how did it get there?

If you have access to the access logs and the ftp logs scan them. In the access logs if you see a long line (scroll all the way to the right, then scroll down) see if that line is returning a non-404 response code. Then see if that line has some of the following:

../../../../
base64_decode

If you have a line in the access log that returns a 200 response and has one of the above strings, then see what file that line is targeting. It could be that is the file the hackers are exploiting to infect your website.

In Joomla based sites, there are many outdated plugins. You can check all of your plugins against the Joomla Vulnerable Extensions list:

http://docs.joomla.org/Vulnerable_Extensions_List

Then, verify that you're also at 1.5.23 if on the 1.5 version. Otherwise, if your site is based on Joomla 1.6, verify that you're on 1.6.3.

If you have the FTP logs, scan them to see what might have been uploaded to your site. There might be backdoor file on your site.

Scan all files for any Perl files (.pl)
Scan all .php files for:

passthru
system
base64_decode
edoced_46esab (above reversed)
cmd
getenv
gzinflate
stripslashes
exec
r57
c99
c100
function_exists

These will get you started. If you find these strings in a .php file, you need to closely examine the file to see if has the usual Joomla "stuff" at the top of the file. If not, it may be a backdoor.

So, a likely scenario is this:

The site was not updated immediately or there is a vulnerable plugin.
Hackers found the site and uploaded a backdoor shell script, or they found a vulnerability in an extension and it allows them to send a string to a component and that string contains code to automatically infect the site.
You keep cleaning the code, but it keeps returning

You won't stop this until you find out how the hackers got in originally. Many people say to wipe the site clean of all files and reload. However, if you reload the same vulnerable component/extension/plugin, the hackers will be back.


SSL certificates and cipher suites correspondence

For the server certificate: the cipher suite indicates the kind of key exchange, which depends on the server certificate key type. You basically have the following:

For TLS_RSA_* cipher suites, key exchange uses encryption of a client-chosen random value with the server's RSA public key, so the server's public key must be of type RSA, and must be appropriate for encryption (the server's certificate must not include a Key Usage extension that says "signature only").
For TLS_DHE_RSA_* cipher suites, key exchange uses an ephemeral Diffie-Hellman, and the server signs its part of the DH key exchange with its RSA key. So the server's public key must be of type RSA, and must be appropriate for signatures (there again, the certificate must not restrict the key usage to only encryption).
TLS_DHE_DSS_* and TLS_DHE_ECDSA_* cipher suites use an ephemeral Diffie-Hellman key exchange, and the server's key must be of type, respectively, DSA and EC, and must be appropriate for signatures.
TLS_ECDHE_* cipher suites are similar to TLS_DHE_* cipher suites, except that the Diffie-Hellman key exchange is an elliptic curve variant. Conditions on the server's certificate remain the same.
TLS_DH_* and TLS_ECDH_* cipher suites are different (mind the lack of 'E' after the 'DH'). For these suites, the server's certificate directly contains a Diffie-Hellman public key (or an elliptic curve variant thereof), and the cipher suite then qualifies the algorithm used by the issuing CA to sign the certificate. For instance, TLS_DH_RSA_* means "server has a DH public key stored in a certificate that was signed by some CA with RSA". This is the only case where the signature type on the certificate has any relation with the cipher suite. Since in practice nobody uses that kind of certificate, this case can be neglected.

For the client certificate: the client presents a certificate when the server asks for it. The client certificate type has no relation whatsoever with the cipher suite (except for the extremely rare case of static DH certificates, but I have never seen that used in practice). The client certificate must be appropriate for signatures. As part of the handshake message that requests a client certificate, the server sends some information about the supported algorithms (see the standard). In fact, TLS 1.2 further expands that mechanism by giving a flexible list of supported algorithm and hash function combinations.


Why is using a password manager better than a simple passwords.txt file?

With a password manager, your passwords are not stored in plaintext on your computer. In other words, even if a malicious actor gains access to your system they will still not have your passwords.

Password managers also do a good job of helping you create long and complex passwords (vs. smashing on the keys in an Excel document), in the event that the site you are logging into becomes compromised. You can also have different passwords for each site, further reducing your risk. Additionally, you can have a USB key that is required to access those passwords, so when you aren't near your computer you take away the access key. Attackers can brute force all day long, chances are they won't get access to the passwords. This beats a password protected file all day long.

Side note: when doing penetration tests, after gaining internal network access, one of the first things I do is search all shares on the Domain for the string: "Password". I get hits every time :(  don't let that be you.


Session resumption essentially means to continue with an already established TLS session, i.e. where the certificate was checked, the common cipher determined and the key exchange was done. The idea behind this is similar to a session cookie in HTTP which is used to continue with an already existing session instead of requiring the client to login again and again.

And similar to a HTTP cookie a server might simply not support (or has it disabled) session resumption in which case it will not provide such a session "cookie" (i.e. session id or session ticket in TLS) and the client has to do a full handshake every time. And the client might also not send a previously provided session id or session ticket back to the server in which case also a full handshake need to be done.


Is HelloSign actually compliant with EU Regulation 910/2014 (eIDAS)?

I researched exactly this question some time ago, and here is my conclusion. I am not a lawyer so take anything I say with a grain of salt.

What I found out is that it seems like HelloSign takes great care to never actually state that they support advanced electronic signatures according to eIDAS.

eIDAS also states (quote from wikipedia) "no electronic signature should be denied legal effect or admissibility in court solely because it is not an advanced or qualified electronic signature".

What that means is, if you scribble your name in paint in a PDF, the court can't deny the legal effect of that signature because of that. They have to check if it is plausible/likely that you signed that. The same for HelloSign signatures. You can argue in court that the signature is valid and hand in the documentation that HelloSign provides. The court will then decide if the signature is valid.

What hello sign doesn't provide is a advanced or even qualified electronic signature.
This might be a problem in court.

From my layman understanding, with such a signature the court would likely believe the signature is valid, and one would have to prove that it isn't. With a HelloSign signature you would have to prove that the signature is valid.

eIDAS also states that qualified electronic signatures have the same legal effect as handwritten signatures. Thats also obviously not valid for HelloSign signatures.


How can I force a specific device to re-authenticate?

The best approach is to simply change the Wi-Fi SSID password. You could even change the SSID itself.

You could add their MAC address to a block list if you know it, that will also block them but it isn't 100% effective as they could change their MAC address in a number of ways. The easiest being to use a different Wi-Fi card.


How many passwords does the average user know?

This is a bit old (2006), but may be helpful towards your goal.
http://usabilitynews.org/password-security-what-users-know-and-what-they-actually-do/

It is based on a study of 328 undergraduate and graduate level college students from Wichita State University volunteered to participate in the survey, and these students were also regular users of the Internet with one or more password protected accounts.

  Overall, 74.9% of respondents (236) reported that they have a set of predetermined passwords that they use frequently, of those 98.3% (232) reported an average of 3.1 (SD = 2.028) passwords. More than half (59.7%, 188) reported that they do not vary the complexity of their password depending on the nature of the site they are using

The study also goes on to talk about their password creation details, complexity, etc...


Password Storage - Self Encryption vs Hashing?

Very interesting thought.

But we have one problem here, regular hashes have always the same size, your hash will have different sizes depending on the input.

So it can be considered less secure that a regular hash.

Hash function definition:

  A hash function is any function that can be used to map digital data
  of arbitrary size to digital data of fixed size (...)


Should different versions of SSH give different VisualHostKeys?

The problem is in the thing, that the randomart is based on the fingerprint and not on the key itself. This implies that the hashes are different and therefore the ASCII arts too. For example my output when using the same client version and same key:

Host key fingerprint is SHA256:v0I6xgzhRSheT19KVcglIbLven9u/xAaVC/GlpjODpo
+---[ECDSA 256]---+
|     .. .o+=o .  |
|  . o oo..+. = o |
| . o +.o o  + * .|
|  . . o.o  + o . |
|   . o  S . + .  |
|    o  ..+ o o . |
|     + oE . o .  |
|      *.o  .o  . |
|     ..o oo+.....|
+----[SHA256]-----+
Host key fingerprint is MD5:22:0c:a2:6b:87:80:26:ee:0f:5c:62:1d:5c:e1:cd:48
+---[ECDSA 256]---+
|     E.          |
|  . + +          |
|. .o o o         |
|o..o.            |
|=+ oo . S        |
|B.+  . .         |
|.* .             |
|o o              |
| ...             |
+------[MD5]------+

The root of the change is that md5 is obsolete and new verison uses sha256 by default. But still you can force the client to use the md5 version, which should result in the same randomart:

ssh -oFingerprintHash=md5 you_host

or with the option in ssh_config:

FingerprintHash md5


How do I actually air gap my CA computer?

All Windows updates are available as downloads that you can apply locally, similarly for Linux. Enterprise management tools can also be used to provide networked updates without needing to connect the CA machine to the Internet. You could temporarily connect to the local network with a Windows firewall rule that only allows a connection to the address of the management server.
Intermediate Certificates act like the root cert but have a more limited scope. So you can create a set of intermediate certs for specific signing purposes and with short expiry dates to limit the impact of them being compromised. Yes, you still need to keep the intermediate certs secure but the impact of compromise is a lot less if done correctly.

If you need to create a new Intermediate certificate, you do so on the CA machine with clean USB stick or similar.

Clearly, you will understand that you must keep the CA machine physically secured. It should be in a secured cabinet in a secured room. Access to the machine must be tightly controlled and all access carefully recorded.

UPDATE: Someone else mentioned using a hardware encryption module (HSM). Certainly this would also improve security on the CA machine making it much harder to compromise the keys and is highly recommended. I should have included that before.


Security of email sent/received on iPhone via Mail app

Well, it depends. (Which is the usual answer to this sort of question!)

By default, Internet email is not at all secure; the underlying protocols like SMTP and IMAP are plain text and have no security.

However, sensible email providers will use an additional protocol, TLS, to encrypt the connection between your phone and their servers. Modern versions of Exchange use TLS by default; so does Gmail.

This secures the communications between you and the mail server. (There are some situations in which a bad guy can break TLS if they can intercept your network traffic and persuade you to accept a fake certificate. They're not common but a real threat and in particular your phone company can often do this fairly easily.)

More importantly, there is an aspect of email security that is usually forgotten; you can secure the sending part as much as you like, but you can't do anything about the receiving side. The person you are sending the mails to might not be using TLS; they might be very insecure.

In practical terms: email is secure enough for "regular use" if you have a reasonable email provider and are careful about not accepting bad certificates and avoiding dubious WiFi. However, if you have anything very sensitive to send, you should try and encrypt it separately before sending. (Which might be tricky on an IOS device.)

In a comment you ask if it makes any difference which client you use where you have an option, Apple Mail? Gmail or OWA apps? Web mail in the browser? These all use more or less the same methods to protect your mail from snoopers, so all are roughly equivelant in security from that perspective.

Google would say that using their Gmail app or the browser are slightly more secure, because only they support 2-factor, which is true. We always like 2-factor here - iF you don't have it enabled, go do it now!

However, because the second factor for gmail is "having your phone with you" it doesn't help much with the security when you are reading your mail on the same phone.


Should untrusted strings be sanitized server-side if they're inserted into the document body through document.createTextNode?

The input to createTextNode, textContent, and the non-standard innerText all take plain JavaScript strings. You do not need to and should not encode that input as HTML, plain JS strings are all you need.

That being said, you do still need to properly encode the message from the server. If you are outputting the text as HTML, you would encode it with HTML entities. If you are outputting the message as JavaScript or JSON, you would typically encode it with a JSON encoder. The correct encoding depends on the context it is output and is not always HTML.


What to do if a user loses access to his authenticator code?

You can use a mix of time delay and backup codes. When the user activates 2FA, show him a couple Backup codes (like Google does) and ask them to save it somewhere, and ask one of the codes on the next screen. This will save you some trouble later.

From time to time, ask the user one of the backup codes when he logs in, even if he submits the 2FA token. If he does not know/don't have the backup codes, generate new ones, send to the user, ask him to save the codes, ask another random one in the next screen. User will be educated that the backup codes are special.

If user loses both the 2FA and the backup codes, create a very long process to retrieve the codes. Show him the necessary steps, how long they will take, and where he is:

User asks for a 2FA reset, send him a link and state that the link will be available from 24h to 48h AFTER he clicks the link
User receives a link telling someone with this IP/OS/browser asked to reset the 2FA, and if was him, he have to wait until next day and click the link.
The next day, user clicks the link and receives another mail with a link and a reset token that must be entered on the site in 24h to 48h later. Add the same message that someone, maybe him, with this IP/OS/browser tried to reset his 2FA.
Next day, user clicks the link, loads a page, enters your site, and enters the token. Tell him he will have to login in 24h to 48h again and 2FA will be disabled.
User logs back in after 4 days, after receiving at least 3 emails telling him someone is trying to reset his 2FA.

I think 4 days is long enough for a hacker to lose interest in the account and a good timeframe to any user to detect and stop any account hijack. If 4 days is not enough, you can increase the time between each email. And any user really interested on recovering his account will follow the instructions.


Keeping information in RAM can enhance security, if done right and if the requirements allow it. I'm going to show two security architectures where keeping the data in RAM provides a security benefit. These are fairly specific scenarios; most of the time keeping data in RAM doesn't help.

Protection against file dump attacks

Consider a web application that manipulates files on the server. One kind of vulnerability that it might have is to allow users to download files that are not supposed to be exposed remotely at all. If a piece of critical data is only stored in the memory of some process(es) (here it's not RAM that's relevant, but virtual memory as opposed to the filesystem), then it will not be revealed by a file exposure vulnerability.

Of course, the data may be revealed through other vulnerabilities, for example with an attack chain that first arranges to have the confidential data written into a file (such as an error dump of some kind) and then to have the dump file exposed.

Keeping the data in memory only helps if it isn't loaded from a file in the first place. Where do you get the data after boot? The data could be stored encrypted, but that requires someone to enter the decryption key after a reboot; this is no good for most web applications as they can't afford the downtime. The data can be stored in a file that requires additional privileges that the web server does not have: the web server process would start with elevated privileges, read the file, then drop privileges. This raises the bar for an attacker since they would have to find a local privilege escalation vulnerability in addition to the remote vulnerability that gave them a foothold. The benefit remains small because many attacks that give the attacker unprivileged local access also provides a way to inspect the memory of active processes.

Defense against some attacks with physical access

Information in RAM disappears if the RAM is powered off. Hence, if the attacker can only manage to grab hold of the target system by powering it off, he will have more trouble accessing data if it's only in RAM. However, storing the data in RAM won't do much good on its own, because RAM has some data remanence of a few seconds to a few minutes. (See also Recover the prior contents of RAM from a turned-off PC?). This is enough to reboot the computer into an operating system that's controlled by the attacker or to transfer the RAM sticks into another computer. (See also Are there volatile memory chips which dont retain data after power off?)

Encrypting the data helps, but you have to store the encryption key somewhere. And if you're going to encrypt the data, you can do this on a disk anyway. Encrypting most the sensitive data does help in that if the attacker is unlucky enough that the key is lost, the data is safe.

So in order for storing the data in RAM to enhance security, there have to be additional physical security measures. If the RAM is inside a tamper-resistant case that causes the power to be turned off if opened, it might be enough to exceed the RAM's remanence. For better results, tamper attempts should cause the motherboard to zero out the RAM before turning off the power (which means the motherboard should have a small battery). Encrypting the data helps because then only the key needs to be zeroed out, which takes less long. Even if the anti-tampering measures can be defeated with good enough tools, it makes the attack more difficult than a simple pass-and-snatch (an intruder with a bolt cutter is more noticeable than an attacker with a circuit board inside a cellphone case).

Going further, it can be worthwhile to encrypt RAM, and ensure that the key is kept in the processor cache or registers. The attacker typically has to reboot to try obtaining the key; rebooting quickly enough to find a pristine cache and without clobbering the cache is harder, and unplugging the CPU is harder than unplugging RAM.

There is of course always the problem of where the data is loaded from (or if it's encrypted, where the key is stored). Some use cases value confidentiality over availability and can afford to require someone to come and enter a key after each reboot (e.g. a big datacenter might have someone available to do it around the clock, in case an intruder gets that far). This security measure can also benefit systems that process data but do not store it.


Retrieving saved password from Firefox on Linux

Yes it's possible, even over ssh and quite trivial to do.  Enable X11 forwarding over ssh (e.g., -X option), start firefox, go to Preferences -> Security -> Saved Passwords -> Show Saved Passwords.

You could also find them in the relevant files in ~/.mozilla/firefox/{ user_profile } specifically key3.db for the encryption key and signons.sqlite for the encrpyted passwords.  (They aren't in plaintext.)


How to secure my ajax call to the backend?

I think you are trying to solve the wrong problem. The main issues with Ajax requests is not the integrity of data, but XSS(cross site scripting), CSRF (cross site request forgery), and authentication bypass.

If you are properly using SSL (not accepting self signed certificates, invalid certificates, and so), you can be sure that nobody can intercept and modify the data. Nobody can, except the government.

You must be sure that Ajax requests obey the authentication framework you have in place. So, try to access it directly without the frontend, save sessions and try to replay them, and catalog all the answers. You must be sure that invalid or unexpected input don't show undesirable data to the attacker.

You must be sure that all user supplied data is properly sanitized before being processed or echoed back. Failure to sanitize data can lead to XSS, SQL injections, local and remote file inclusion, and a host of other problems.

And must be sure that every request is protected against cross site requests, by implementing anti-CSRF tags. Ignoring it can expose your users to some problems, like account takeover, fraudulent requests, and so.

SSL infrastructure is very good, but all the layers above it are much more problematic. People writing SSL software are hardened professionals, but you can find lots and lots of inexperienced developers writing PHP, SQL and Javascript code those days.


Why isn't an Expect-CT violation report sent when I use a certificate generated with Burp Suite?

Certificate Transparency (CT) does not apply to non-public root Certificate Authorities. CT only validates that certificates issues by trusted public CAs were issued legitimately.

Your Burp Suite certificate is configured on your system as a trusted root certificate and no CT policy will therefore be applied to it.

The Mozilla MDN page on Expect-CT also explicitly states this behaviour:

  Root CAs manually added to the trust store override and suppress Expect-CT reports/enforcement.


is there a risk in increasing esmtp header line length against rfc5822 - asa/pix question

This link below could be the answer I'm looking for, please review and comment:-

http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Mail-server-related-injections-Whose-problem/ba-p/6640176

It suggests compliance to rfc2822 (superseded by rfc5822) may save the proverbial:
"Although not mandatory, complying with this guidance may help prevent SMTP header injection."

I could be barking up the wrong tree and would appreciate some opinions on this :-)


How to securely store and use a password for certificate authority

I work with a product called SAP Single Sign-On that can be used to issue certificates as a Certification Authority or use a third-party Remote Certification Authority.

Our solution for this is called Hardware Security Module that is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. As described in the product documentation, hardware security module (HSM) boards or other PKCS#11-enabled devices can be used as external user Certification Authorities (CAs). In this case, the external CA acts as a key store entry of the type user CA.

Therefore instead of memorizing some password, using a HSM is a secure option to manage private keys.


A (spoofed?) trusted device has logged in from an unrecognized location

Sounds like it's plausible that it could be a session hijack? If they were able to get past that many security barriers without triggering anything besides the geo-location, but there's a lot you'd need to question in order to narrow it down. Do you have any add-ons? Do you use google-chrome? Have you checked your login information against haveibeenpwned.com ?


How to configure hashcat to only hash fixed length passwords with N digits?

There's no native way to do this with hashcat. Instead, you must generate a list of masks that contain all of the permutations that fit your criteria.

The common tool for this is policygen from the PACK toolkit. My answer here outlines how to use it.

For your use case, it would be something like this (assuming 8-character passwords and a minimum of 3 digits):

$ policygen --minlength=8 --maxlength=8  --mindigit=3 \
    -o len8mindigit3.masks

               _
     PolicyGen 0.0.2  | |
      _ __   __ _  ___| | _
     | '_ \ / _` |/ __| |/ /
     | |_) | (_| | (__|   <
     | .__/ \__,_|\___|_|\_\
     | |
     |_| iphelix@thesprawl.org

[*] Saving generated masks to [len8mindigit3.masks]
[*] Using 1,000,000,000 keys/sec for calculations.
[*] Password policy:
    Pass Lengths: min:8 max:8
    Min strength: l:None u:None d:3 s:None
    Max strength: l:None u:None d:None s:None
[*] Generating [compliant] masks.
[*] Generating 8 character password masks.
[*] Total Masks:  65536 Time: 76 days, 18:50:04
[*] Policy Masks: 21067 Time: 3 days, 8:11:03

$ head len8mindigit3.masks
?d?d?d?d?d?d?d?d
?d?d?d?d?d?d?d?l
?d?d?d?d?d?d?d?u
?d?d?d?d?d?d?d?s
?d?d?d?d?d?d?l?d
?d?d?d?d?d?d?l?l
?d?d?d?d?d?d?l?u
?d?d?d?d?d?d?l?s
?d?d?d?d?d?d?u?d
?d?d?d?d?d?d?u?l

$ tail len8mindigit3.masks
?s?s?s?s?d?d?d?s
?s?s?s?s?d?d?l?d
?s?s?s?s?d?d?u?d
?s?s?s?s?d?d?s?d
?s?s?s?s?d?l?d?d
?s?s?s?s?d?u?d?d
?s?s?s?s?d?s?d?d
?s?s?s?s?l?d?d?d
?s?s?s?s?u?d?d?d
?s?s?s?s?s?d?d?d

You would then supply that file of masks to hashcat.


1- Can someone explain how to extract the actual public key from the the ssh key public key (removing all the extra stuff and leaving just the key)?

The format of public key is described as the part of known_hosts section of manual page for sshd:

  keytype, base64-encoded key, comment.

So lets create a key to see what is there.

$ ssh-keygen -t ed25519 -f ed25519
$ cat ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE8C+wgMJ89PV5cQZxfCpq+GB/gZ0zO7JQhnVBIh2gOj comment

Using cut we can select only the key blob, which is LV (length value) structure, containing (once again) key name and then the actual PK value:

$ cat ed25519.pub | cut -d' ' -f2 | base64 -d | hexdump -C
00000000  00 00 00 0b 73 73 68 2d  65 64 32 35 35 31 39 00  |....ssh-ed25519.|
00000010  00 00 20 4f 02 fb 08 0c  27 cf 4f 57 97 10 67 17  |.. O....'.OW..g.|
00000020  c2 a6 af 86 07 f8 19 d3  33 bb 25 08 67 54 12 21  |........3.%.gT.!|
00000030  da 03 a3                                          |...|
00000033

We can once again get rid of the key name to get the string representing the PK only. The Length is represented always using 4 bytes: 00 00 00 0b (11) is the length of the ssh-ed25519 string (hex: 73 73 68 2d  65 64 32 35 35 31 39) and then follows the PK length 00 00 00 20 (always 32 bytes) and the key itself (hexadecimal):

4f 02 fb 08 0c 27 cf 4f 57 97 10 67 17 c2 a6 af 86 07 f8 19 d3 33 bb 25 08 67 54 12 21 da 03 a3

  2- Could someone put in human speak (or code) an example of encoding the public key?

The above is bash and manual version of extracting the PK value from OpenSSH public key. I believe you will be able to implement that in Python from the above description.


This blog post does a pretty good job at explaining what requires NetBIOS. It includes a few examples of programs that need it as well.

To summarize, every machine with NetBIOS will broadcast its name, IP, and any services every 60 seconds. If there is a WINS server configured they will register with the WINS server instead and the network will be much quieter, but EVERY machine needs to be configured with WINS, the ones that aren't configured will continue broadcasting every minute.

NetBIOS is needed to join a domain and there are quite a few legacy apps that were designed around it and therefor need NetBIOS to function properly. Here is a short list taken directly from the above blog post link.

Exchange 2003 with certain Outlook features
McAfee Enterprise ePolicy Orchestrator
Symantec Endpoint Protection
Symantec Backup Exec
Computer Associates AV
SQL
Mapped Drives
Printer sharing (not published in AD)

Full credit for this information should go to the author of the referenced blog post Ace Fekay


How do I sandbox user JS without using a VM, transpiler, or whitelist-based API?

The software engineering definition of a sandbox is an execution environment with specific security constraints maintained.  This means that the user JavaScript should not be able to either leverage or impact the JavaScript of the containing web page.

An iframe implementation will neither

Guarantee that the sandbox code run-time conditions will be the same as if it ran in an independent document nor
Ensure the parent document will not be impacted and possibly crashed by the sandbox code.

If you have sufficient network and web server control, you can establish fairly secure independence and an authentic execution environment by allowing an authenticated user via HTTPS to provide sand-boxed JavaScript to a completely independent secondary site or sites.  Use of sub-domains can reduce the cost of this approach.   You may have to use the target='_blank' hack that some consider a violation of the www model.

To be careful not to create security holes with this arrangement, there are a few recommendations.

Use a server-side include that precisely acquires the sandbox code.
Carefully tighten all web server directory access.
Validate the syntax of the JavaScript.


The nice part of SFTP is that it's incorporated within SSH. Which means that you needn't install additional software. Security-wise, I'd say they are equally secure. There are however a few pros and cons:

FTPS

Pros:

Widely known and used
The communication can be read and understood by humans
Provides services for server-to-server file transfer
SSL/TLS has good authentication mechanisms (X.509 certificate
features)
FTP and SSL/TLS support is built into many Internet communication
frameworks

Cons:

Doesn't have a uniform directory listing format
Requires a secondary DATA channel, which makes it hard to use behind
the firewalls
Doesn't define a standard for file name character sets (encodings)
Not all FTP servers support SSL/TLS
Doesn't have a standard way to get and change file and directory
attributes

SFTP

Pros:

Has good standards background that strictly defines most (if not all)
aspects of operations
Has only one connection (no need for DATA connection)
The connection is always secured
The directory listing is uniform and machine-readable
The protocol includes operations for permission and attribute
manipulation, file locking, and more functionality

Cons:

The communication is binary and can't be logged "as is" for human
reading
SSH keys are harder to manage and validate
The standards define certain things as optional or recommended, which
leads to certain compatibility problems between different software
titles from different vendors
No server-to-server copy and recursive directory removal operations
No built-in SSH/SFTP support in VCL and .NET frameworks


What are some cards that are vulnerable to RFID theft?

which cards are vulnerable to such abuse?

First of all you need to recognize whether the card has RFID capabilities or not. These may be advertised with logos, icons (usually the three curved lines also used to indicate "WiFi" in some contexts), or in writing. You can also check on the supplying bank/company/entity, or look for telltales such as "My card does not work..." in the FAQs or forums. Also the issuer's support hotline, if available, should be tried first.

Another possibility is to inspect the card itself (some RFID antennas are visible by placing the card in front of a very strong point light, such as some hi-power LED torches; you can try and see if a RFID reader beeps, even if it does not recognize the card, or better yet, if a recognized RFID card has suddenly problems if waved in front of its reader while being pressed against the unknown card. Normal plastic and chip cards do not interfere with RFID cards; RFID cards, of course, do). If you have an expired card of the same issuer, you can try cutting the old card apart, and if it has a RFID coil inside, chances are that the new issue is RFID too.

Now that you know it's RFID, what information/operation is needed to complete a transaction or get the information on the card? A few RFID credit cards require a PIN to be entered manually (which somewhat negates the ease of use of a RFID...), for example.

If the only thing needed to get something you wouldn't want gotten from the RFID is to skim it with a reader - your knowledge or confirmation aren't required - then by definition that card is vulnerable.

  How do I prevent RFID scanning? Would a wallet with aluminium plates on both sides do the job?

There is a common misconception about "shielding" RFID. Passive RFIDs don't have a power source, so they get it from the incoming scanner field through inductive coupling. The shielding works both by limiting the energy transfer (so the RFID doesn't "wake up") and by decreasing the signal-to-noise communications ratio (so the RFID and the scanner don't "understand" each other).

The absorption of the shielding depends, for any given material, on the frequency being used; for smart cards we want good absorption in the 13-14 MHz range.

Different materials - even metals - have different shielding properties at different frequencies; for example, aluminum won't stop low frequencies (or stationary magnetic fields: a magnet will still work even if wrapped in aluminum foil). Steel sheet or soft iron sheet will screen low frequencies and absorb much of the magnetic component, but will leak at very high frequencies.

So, while an aluminum foil will create a Faraday cage stopping dead most high-frequency RF, microwaves, etc., it may not be enough to screen an inductively coupled RFID smart card from a juiced-up, savvy scanner. A single layer of aluminum foil will not stop any except the cheapest, more shoddily constructed readers. Of course, more layers will increase protection.

You would perhaps be better off with jamming -- using a shield made of a valueless (e.g. expired), but still working, smart card of the same make and model. Or "sandwiching" the real card between two valueless ones. Not only will the middle card receive less power, but the outgoing signal will be mixed with two others on the same frequency (activation delay makes this method not completely safe,  though).

Otherwise, you can use 30-mil magnetic iron foil (looks very much like aluminum), or have the wallet lined with Near-Field Cobaltex which is almost as good and weighs less.

For the truly paranoid, apart from several layers of Cobaltex, there are metamaterial shieldings (e.g. silvered-nickel-iron or nickel-cobalt-copper mesh from several suppliers, from Achron to Laird Technologies) which are significantly more expensive but have even more stopping power. And you don't need a lot of material to line a wallet after all.

You can then test the effectiveness of the shielding by using a shielded credit card to try and pay at the next gas station. If it doesn't work, you smile happily, take the card out of the wallet and tell the gas guy "Sorry, it usually works even from inside the wallet". If a reader at one inch can't interface, it's unlikely that a pirate reader will be able to do it from much farther.

It would also be interesting to build a coil tuned to 14 MHz and connect it to a rectifier, buffer capacitor and buzzer stage. It would suck most of the energy from the scanner field, converting it into an audible sound and giving the alert. Basically the same thing as a near field probe, except it could be completely passive: it takes quite a lot of energy to run a blind skim a RFID at a distance, so the scanners are probably heavily up-juiced and give off radiation enough to be detectable. (It would also possible to build an active scanner detector by tweaking this design).


Chinese or "pinyin" wordlists for dictionary attacks

Chinese (Mandarin) is a very phonologically restrictive language with a limited amount of possible syllables. Hence, you can make a table consisting of every possible syllable in the Chinese language as exemplified here:

        a       ai      au      an      aŋ      e       ə       əi      əu      ən      əŋ      i       ia      iai     iau     ian     iaŋ     ie      iə      iəu     iən     iəŋ     io      iu      iuan    iuə     iun     iuəŋ    aɻ      o       u       ua      uai     uan     uaŋ     uə      uəi     uən     uəŋ     m       n       ŋ
        a       ai      ao      an      ang     ê       e       ei      ou      en      eng     yi      ya      yai     yao     yan     yang    yê      ye      you     yin     ying    yo      yu      yuan    yue     yun     yong    er      o       wu      wa      wai     wan     wang    wo      wei     wun     weng    m       n       ng
p       ba      bai     bao     ban     bang            bo      bei             ben     beng    bi                      biao    bian    biang           bie     biu     bin     bing                                                                    bu
pʰ      pa      pai     pao     pan     pang            po      pei     pou     pen     peng    pi                      piao    pian                    pie     piu     pin     ping                                                                    pu
m       ma      mai     mao     man     mang            mo      mei     mou     men     meng    mi                      miao    mian                    mie     miu     min     ming                                                                    mu
f       fa                      fan     fang            fo      fei     fou     fen     feng                                                                                fu
t       da      dai     dao     dan     dang            de      dei     dou     den     deng    di                      diao    dian                    die     diu             ding                                                                    du                      duan            duo     dui     dun     dong
tʰ      ta      tai     tao     tan     tang            te              tou             teng    ti                      tiao    tian                    tie     tiu             ting                                                                    tu                      tuan            tuo     tui     tun     tong
n       na      nai     nao     nan     nang            ne      nei     nou     nen     neng    ni                      niao    nian    niang           nie     niu     nin     ning            nü              nüe                                     nu                      nuan            nuo                     nong
l       la      lai     lao     lan     lang            le      lei     lou             leng    li      lia             liao    lian    liang           lie     liu     lin     ling            lü              lüe                             lo      lu                      luan            luo             lun     long
ts      za      zai     zao     zan     zang            ze      zei     zou     zen     zeng    zi                                                                                zu                      zuan            zuo     zui     zun     zong
tsʰ     ca      cai     cao     can     cang            ce              cou     cen     ceng    ci                                                                                cu                      cuan            cuo     cui     cun     cong
s       sa      sai     sao     san     sang            se              sou     sen     seng    si                                                                                su                      suan            suo     sui     sun     song
tʂ      zha     zhai    zhao    zhan    zhang           zhe     zhei    zhou    zhen    zheng   zhi                                                                                zhu     zhua    zhuai   zhuan   zhuang  zhuo    zhui    zhun    zhong
tʂʰ     cha     chai    chao    chan    chang           che             chou    chen    cheng   chi                                                                                chu     chua    chuai   chuan   chuang  chuo    chui    chun    chong
ʂ       sha     shai    shao    shan    shang           she     shei    shou    shen    sheng   shi                                                                                shu     shua    shuai   shuan   shuang  shuo    shui    shun
ɻ                       rao     ran     rang            re              rou     ren     reng    ri                                                                                ru      rua             ruan            ruo     rui     run     rong
tɕ                                                                                ji      jia             jiao    jian    jiang           jie     jiu     jin     jing            ju      juan    jue     jun     jiong
tɕʰ                                                                                qi      qia             qiao    qian    qiang           qie     qiu     qin     qing            qu      quan    que     qun     qiong
ɕ                                                                                xi      xia             xiao    xian    xiang           xie     xiu     xin     xing            xu      xuan    xue     xun     xiong
k       ga      gai     gao     gan     gang            ge      gei     gou     gen     geng                                                                                gu      gua     guai    guan    guang   guo     gui     gun     gong
kʰ      ka      kai     kao     kan     kang            ke      kei     kou     ken     keng                                                                                ku      kua     kuai    kuan    kuang   kuo     kui     kun     kong
x       ha      hai     hao     han     hang            he      hei     hou     hen     heng                                                                                hu      hua     huai    huan    huang   huo     hui     hun     hong

The first row are the column headings and the first column are the row headings. Thus, you can ignore the first row and column as they were for my aid in learning Mandarin pronounciation.

Many syllables are not used and their positions are, thus, empty in the table giving a total of 410 possible syllables. Furthermore, there are 5 tones (beginning with 0) in the Mandarin Chinese language denoted by numbers, so a password could be something like gao1mi4. Counting the tones, there are 2050 possible syllables. With Chinese words being typically 1 to 3 syllables long, it's a real possibility that you could break a Pinyin-based password in  less than 8,615,125,000 attempts using random combinations of syllables and tones without the aid of a word list.


I am worried because my college asks students to confirm their credit card number, location, SSN and full name on signup. What do I do?

When you say sent over what do you mean? Is this information presented to you, and you then  have to verify it or does it also ask for this information as well as your regular login credentials (Username, password) of which it then verifies whether the credentials (SSN,  etc.) that you have entered are correct?

Because there is to sides to the security coin as it were, with this situation. As using multiple factors of authentication before a student can add a new class is a particularly good idea, as the underlying fact is it's hard for an attacker to gather all that information on a single person unless of course you're really clumsy with your credentials or your attacker is a really good profiler. However, keeping that amount of data on a person is possibly not the best thing to do if your colleges back end is not all its beefed up to be.

-Dumming down the HTTPS stuff before I go on too much!-
On the matter of the use of HTTPS. It's only really as good as it's implementation.
There are allot of holes and work around's if it hasn't been implemented correctly. Although I shouldn't worry about it as much as the integrity of the AP you're using to send that information.

But If you have any concerns you should talk to a lecturer or someone higher in Management and always use a VPN or if possible an SSH Tunnel.


Does PCI-DSS password guidance apply to service accounts?

Your use of the word 'guidance' is a but off.

Under the standard there are 4 parts per requirement:

The requirement itself
Testing procedures
Reporting instructions
Guidance

These can be found under the ROC and Standard documents in the PCI SSC Document Library.

Requirement 8.2.4 states:

  Change user passwords/passphrases at least once every 90 days.

It has its matching Testing Procedure:

  For each item in the sample, describe how system configuration settings verified that user password/passphrase parameters are set to require users to change passwords/passphrases at least once every 90 days.

Its guidance however provides the intent behind the requirement:

  Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.

So IF you can show you can pass the intent (guidance) without changing your password every 90 days without using another requirement (by compensating control worksheet) by say, having a password with such complexity that its hash can not be cracked within its used time, with additional logging (above the requirements) etc.  Then the QSA might say the requirement has met the intent.

Some definitions of what counts as an 'Admin' account for your service accounts (however 'the standard' overwrites all FAQs and 'Guidance' documentation at will of PCI and the QSA).


Why do I have to do manual XSS testing in addition to using tools such as Burp Suite/XXSer/Xenotix?

That link is reasonable.

Why do you need to manually test for vulnerabilities? Because a tool it's just a tool someone else created and he might have forgot to add a possible payload. Don't know about any specific case though, although I'm not much on the "offensive" side nowadays.

So, if you are the developer, a good approach is to:

Know where are you accepting input data.
Integrate automatic testing of input filtering.
Run any reliable tool to check for possible XSS.

On the other hand, if you are just black-box testing:

Identify the possible input points.
Run whatever tool you want.
If you consider that the tool might have skipped something, manually check for it.


Vulnerabilities by adding an untrustworthy package repository

As a general rule most package managers will ask you if you want to install dependencies, as well as asking if you want install different (versions of) packages.

Whenever I download a package from somewhere that's not debian's repos (I use Crunchbang linux) then I'll install the needed dependencies myself and only use the third party repository for the one specific package I want.

Afterwards, I'll comment out the line in my sources file that has the third party repository so when I do run 'apt-get update' I won't get anything from that repository. (The only downside is it requires an additional step to update the package from that repository.)

Usually when you update or upgrade you'll be shown all the packages that need updating. If you pay attention, you'll notice anything funky going on.

Edit: Just found an example when trying to upgrade Mono

Need to get 55.8 MB of archives.
After this operation, 33.8 MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
**WARNING: The following packages cannot be authenticated!**
  mono-complete mono-runtime-sgen mono-devel mono-dmcs...

It's from a non-Debian source, thus the warning and forcing me to select Y again.


Efficient way for finding XSS vulnerabilities?

DOMinator Pro is a great semi-automated tool for identifying DOM XSS.

  What is DOMinator?
  DOMinator is a Firefox based software for analysis and identification of DOM Based Cross Site Scripting issues (DomXss). It is the first runtime tool which can help security testers to identify DomXss.

  How it works?
  It uses dynamic runtime tainting model on strings and can trace back taint propagation operations in order to understand if a DomXss vulnerability is actually exploitable.


What are the security dangers of using Security Groups instead of NAT Gateways for isolating AWS RDS databases from public access?

One through public/private subnet separation using NAT Gateways to
route communications between resources (e.g. public web servers) in
the public subnets and resources in the private subnets (e.g. Aurora
RDS instances)

^^^This approach is recommended by AWS, as it minimizes the attack surface by keeping the DB instances in a dedicated subnet and additionally host level access is controlled using Security Groups.

one could just have public subnets and all resources that should not
be reachable from internet should not have public IPs and be inside
Security Groups, which should only allow other resources in the public
subnets to stablish connections with them

^^^This approach does not enable the same behavior as the public/Private subnet design.
For instances present in a public subnet, you may use security groups to control host level access. However, a public subnet is "public" due to the presence of an Internet Gateway and an appropriate route entry in the subnet's route table. For instances in a public subnet to connect to Internet, a public IP must be assigned to them.
In your case, not assigning a public IP to a Database Instance in a public subnet would make it inaccessible over the Internet but it would also mean that the instance would not be able to access the Internet. A NAT Gateway/Instance solves this problem by allowing instances in the private subnet to access the Internet, without needing a public IP address.


Why does OpenSSL not include AES-256-GCM?

As the author of the Ruby AEAD library, I can assure you that OpenSSL does support GCM on 1.0.1c.

~ $ /usr/local/bin/openssl version
OpenSSL 1.0.1c 10 May 2012
~ $ /usr/local/bin/openssl enc -help 2>&1 | grep gcm
-aes-128-gcm
-aes-192-gcm
-aes-256-gcm

If it is unavailable on your platform (OpenSSL added GCM support in 1.0.1, I believe), I have also implemented an CBC-HMAC and CTR-HMAC.

If you've installed a later version of OpenSSL, you need to ensure the Ruby binary you're using is linked against that version. It is probably not. Details for doing this are rbenv- and rvm-specific.

Partly for these reasons, I'm writing a replacement library that will bundle and link against DJB's NaCl instead of OpenSSL.


Backup is corrective control or a preventive control?

Corrective Control

It isn't a control until it can be used and the only benefit is corrective, it does not prevent the media loss, it just helps fix the media loss.

Who cares that it needs to be implemented beforehand, and operational costs are incurred beforehand.

All other tools need to be implemented before they can be used, except maybe forensics.

That said, you need to "Channel" whoever wrote the exam and I am not CISA myself, RTFM.


Is it safe to install ...

It is nearly impossible to be sure that some software is safe to install. It can always contain a back door, have bugs in it which might be exploitable from a remote system or similar.

All one can say that the specific problem with CCleaner was fixed according to Avast and that currently no other problems are publicly known with this software. If you consider this safe enough is up to you.


Does Google capture microphone data to better target advertising?

Possible, but unlikely.

As others have stated Google (and others) could record your conversations and analyze them, but it would probably be very expensive and the return of investment not high enough. Presumably this is a manifestation of (self)-selection bias.

What does that mean? In a nutshell: If you would have mentioned a wide selection of products in front of your computer would you have seen advertisement for them? Probably not.

The far more likely scenario:

you already use some Google services so they have a pretty good idea of who you are and
you (like 99% of all people) live in relatively easy to approximate personal circumstances.

Thus follows that showing you ads for the mentioned books or a coffee machine is pretty reasonable. If the Internet as a whole taught humanity one thing it's that we are all very much alike.


Why some antiviruses detect viruses and some not?

You described one type of anti-virus software: signature based AVs. These anti-viruses look for suspicious sections of binaries that match known viruses. However, each AV has it's own list of "known viruses", so they may catch different viruses. There is no universal list of viruses that each AV can check against.

The other type of anti-virus looks for suspicious behavior in any running programs. Each AV program will look for it's own definition of "suspicious behavior" and so the results of each AV may differ.


Getting an Interactive Powershell Reverse Shell Using socat

Seems work fine in my case between virtual machine macOS (VMware Workstation Pro 16) and Windows 10 host.


Gather system metrics securely from infected VM

I opted for Cuckoo to automatize running the software on the guest machine and wrote a custom auxiliary analysis script to collect those metrics every second. The way to collect data is thus as secure as Cuckoo is so I guess better solutions could be found but at least there is a possibility to stream them as they are collected so that, in case of loss of communication between the host and the guest, metrics prior the loss are not lost.


What is probability of a user picking a published password?

The answer will vary wildly depending upon the habits and security-awareness of the person in question.  However, we can come to some conclusions depending on the "type" of person.  At least, we can if we simplify people into one of two categories:

People who use computers to generate truly random passwords

aka people with "good" security awareness.  This is easy.  None of these people will have passwords in your list.  Even with just a random 8 digit alphanumeric string (which is not really a strong password anymore) there are ~2e14 possible password combinations, which means that the odds of finding one of those passwords on a list with 10 million passwords is just 1 in 5 million.  Better than winning the lottery, but still pretty bad.  Personally I use 16 character-long random passwords (which is probably quite common), so then we're looking at ~5e28 possible passwords and therefore tiny odds of selecting one on your list (presuming your list even has 16 character-long passwords on it).

People who pick their own easy-to-remember passwords

As is generally well known, people tend to reuse a lot of passwords, and a lot of common passwords are used by many people.  However, it can be very difficult to actually calculate the frequency with which particular passwords are used.  For instance, most studies of password dumps find that 123456 is the most common password.  This article pegs the frequency of that password at 0.6%, but as discussed in that article there are many caveats.  My own cursory reading of this plot suggests that the top 25 most common passwords might account for something like 10% of all passwords.  It's hard to extrapolate that to the top 10 million passwords though.

As my first link suggests though, there are likely many caveats.  For instance, if you ask someone to pick a password for their bank account they may try harder than 123456.  Indeed, there is some evidence that people are getting better at passwords in recent times, and many of these data sets are based off of leaks that are a few years old.  Those are just two of many potential gotchas that make it hard to estimate for sure what the odds are that some random user's password might be in your list.

Again though, it very much depends on the person.  If you are talking about the kind of person who picks 123456 for their password, then there is a 100% chance that their password will be in your list of 10 million passwords.  If you are talking about someone who generates long random passwords, then there is probably a 0% chance that their password is in your list.  If you're talking about someone in the middle, then who knows.


What security risks are posed by software vendors deploying SSL Intercepting proxies on user desktops (e.g. Superfish)

Having a proxy SSL certificate creates some privacy and security implications:

Superfish can impersonate any site

This does not mean that Superfish will do it (or is doing), but they have the power. As they have a Certification Authority Certificate, any certificate they generate will be valid and accepted.

Certificate pinning does not protect you, either:

  "There are a number of cases where HTTPS connections are intercepted
  by using local, ephemeral certificates. These certificates are signed
  by a root certificate that has to be manually installed on the client.
  Corporate MITM proxies may do this, several anti-virus/parental
  control products do this and debugging tools like Fiddler can also do
  this. Since we cannot break in these situations, user installed root
  CAs are given the authority to override pins. We don't believe that
  there will be any incompatibility issues."

If you use Windows and EMET, Certificate Trust can protect you IF you configure it beforehand. But the process is manual and somewhat complicated.
Superfish can intercept traffic

As a trusted CA, Superfish can perform a MiTM attack on any site, and the average user will not detect the attack. Savvy users can see that the certificate was signed by a strange CA, if they know where to look.
Superfish can inject code anywhere

Even if the site is protected by SSL/TLS, Superfish can inject Javascript or HTML on every page. They just proxy the requests, make the request to the intended server, read the response, inject data, and send data to the user. And unless you are looking for it, you will never notice.
Superfish can be used to install malware

Like above, Superfish can add code to Windows updates, alter executables being downloaded, infect Java applets, Flash files and so on. Any download could be silently compromised. They could even change the origin site and put changed checksums on it, so even if you calculate the hash after downloading the files, they would look legit.
Superfish can know every site you access

The software monitors your browser and send data to Superfish. Even without the software, they can inject code on every site and track you everywhere.
Anyone on the web can use its certificate

The private key of the certificate has been compromised, so anyone knowing the key can use Superfish certificate to create valid SSL certificates for anything they want.

Saying that they can does not mean or imply that they will, only that they have the power to do if they want (or are forced to).


Field-level encryption vs disk encryption for PCI compliance

Field level encryption is important in case of SQL injections or your database server getting hacked. Assuming application and database are on different servers, the data will still be encrypted by application server.

Full-disk encryption would help in case of hardware theft as otherwise encrypted server will not be protected in case it is broken into as your encrypted partitions will be mounted so you database (MongoDB) can access it.

From this I would say that Field-level data encryption should be your focus.


How do I securely store a API key in a PC program?

Put simply, there is no bulletproof way of concealing a string if it is being made available on the client-side.

Maybe instead of giving the user access to the API key, make the client contact your own server and perform API requests from there, if you do this then you will be able to limit unauthorised use of your API key.


This depends. If you are using the keychain to store a key which you can retrieve then the security level is not the same. You still have to move that key into memory to use it - all the secure enclave does is make storage of that key data when not in use more secure.

Alternatively you can create and store an actual key in the enclave directly. See -

https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave

  When you store a private key in the Secure Enclave, you never actually handle the key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create the key, securely store it, and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome.

...

  Can’t import preexisting keys. You must create keys directly inside the Secure Enclave. Not having a mechanism to transfer key data into or out of the Secure Enclave is fundamental to its security.


How can I be protected from pictures vulnerabilities?

I have some suggestions:

Use a separate domain. Host the images on a separate domain that is used only to host user-provided images.
This will ensure that many browser-level attacks can have only limited effects.  For instance, suppose the user's browser is vulnerable to content-type sniffing attacks, so it is possible to upload an image that some browsers will treat as HTML containing malicious Javascript; this defense ensures that the malicious Javascript can only tamper with other user's images, and cannot access your site's cookies or content or other security-sensitive stuff.  However, this does not defend against code-injection attacks that exploit a vulnerability (e.g., a buffer overrun, a double-free) and execute native code.

Defend against content-type sniffing.  Follow practices I've outlined elsewhere to defend against content-type sniffing attacks.  The most important one is to set a correct Content-Type: header on the HTTP responses where you serve the image.  It can also be helpful to include a X-Content-Type-Options: nosniff header, to prevent some versions of IE from trying to do content-type sniffing.

Convert to a fixed format. Convert the input image to a bitmap (keeping only the bitmap data, and throwing away all the extra annotations), then convert the bitmap to your desired output format.  One reasonable way to do this is to convert to PBM format, then convert to PNG.
This is not a reliable way to stop attacks, but it reduces some of the attack surface available to the attacker.  For instance, it prevents the attacker from attaching malicious metadata that are crafted to exploit some vulnerability in the image parser.  It also does not give the attacker a choice of image formats.  To defeat this defense, the attacker must find a vulnerability in the PNG decoder, in the code that reads image pixel data.  It prevents the attacker from exploiting a vulnerability in the decoder for some other image format or in the part of the PNG parser that reads metadata.  So, while potentially helpful at reducing the risk, I would not expect this defense alone to be sufficient.

Consider randomization.  Consider inserting some random noise into the image.  For instance, you might loop over all the pixels, and for each of the three intensities (corresponding to RGB) for that pixel, randomly choose among adding 1, subtracting 1, or leaving that intensity value alone.  This introduces a tiny bit of noise into the image, but hopefully not enough to be noticeable to viewers.  And, if you are lucky, it may make some attacks less likely to succeed, because the attacker cannot fully predict the result of the transformation.  This defense is highly heuristic and is certainly not guaranteed to be effective, but it is possible it might help, if used in addition with the other defenses I've outlined, as a sort of belt-and-suspenders defense-in-depth strategy.  But please understand that this defense alone is probably not adequate.

Depending upon how concerned you are about these risks and the sensitivity of your site, you don't need to do all four.  If you are not concerned about code-injection vulnerabilities in the browser, you could do just #1 and #2.  If you want partial protection against code-injection vulnerabilities in the browser, you could do just #1, #2, and #3.


Can USB ethernet passthrough to a KVM virtual machine isolate network-related kernel vulnerabilities?

Yes, this can reduce host kernel attack surface area. It can also be useful for isolating devices in the case that you have broken DMAR table and cannot protect from DMA attacks otherwise. This is something I have done in the past for most PCI devices. Some things to consider:

Use VFIO, not PCI passthrough

VFIO is newer, and will properly isolate devices in their IOMMU groups, whereas PCI passthrough can potentially be bypassed if there are any devices that are not passed through which are in the same IOMMU group. From the above link:

  IOMMU groups try to describe the smallest sets of devices which can be considered isolated from the perspective of the IOMMU.  [...]  Legacy KVM device assignment will allow a user to assign these devices separately, but the configuration is guaranteed to fail.  VFIO is governed by IOMMU groups and therefore prevents configurations which violate this most basic requirement of IOMMU granularity.

Beware option ROMs

There is one thing you should keep in mind, though. When you pass the PCI device directly though to a guest, the guest gets raw access to the PCI configuration space, including read/write access to the option ROM. An option ROM is a bit of firmware stored on certain devices which is executed by the BIOS during early boot. If the guest kernel is hijacked, then even if it cannot escape into the host, it will be able to write to the option ROM on the physical device, and wait until you next reboot, at which time the option ROM is called by the BIOS, subjecting you to a BIOS rootkit.

There is a way to mitigate this risk, however. Intel TXT allows you to verify option ROMs before they are called. This requires you set up tboot, which enables various TXT features at boot, properly. The official documentation is available here. This is very important, so don't ignore it!

Harden userspace components

By far, the most vulnerabilities will be present in the userspace component (QEMU, or maybe kvmtool), so securing this should be a high priority. Assuming you will be using QEMU, you should ensure it restricts its filesystem access to an empty directory with the -chroot directive. It must drop to a dedicated, unprivileged user with the -runas directive, and it must enable a seccomp sandbox with the -sandbox directive. Attack surface can further be reduced in other ways, by disabling unnecessary features (ACPI, RTC, etc.), and setting resource limits. Using a MAC such as AppArmor or SELinux is also recommended. If you will be compiling QEMU from source, you can further harden it at compile-time with the right gcc flags.

Harden both kernels

It's very important, if you want reduced attack surface, to use grsecurity for both the host and the guest. Additionally, grsecurity will provide PaX, which has components that harden userspace components like QEMU. If QEMU is used with -enable-kvm, then it is safe to use the strictest PaX settings with it. The commercial version of grsecurity is not necessary. All it is is a stable kernel which does not update as often. It is not necessary unless you are running a high-availability servers.


Can I get malware just by navigating to a webpage?

Since browsers and plugins like flash are not bug-free there is a non-zero risk that you can be attacked with malware just by visiting a web site or that your credentials gets stolen. These can be silent attacks (drive-by-downloads, cross-site-scripting, CSRF...) or social attacks (downloads of fake software updates, scareware, fake login,...). You will find these attacks everywhere, i.e. in your mail, in advertisements (malvertisement) and in compromised systems. These attacks are no longer restricted to the shady sites of the internet.

There is no way to eliminate the risk fully but you can reduce it in several ways:

Use a  browser with a good security record (i.e. fast fixes, good sandbox...). This is Chrome/Chromium in my personal opinion.
If possible use a secure OS which gets not targeted much, i.e. Linux. If you only do Web and Mail it will provide everything which Windows can do, only in a more secure environment.
Install a proper antivirus product if this is needed on your OS. This often does not help against the latest attacks but vendors try to quickly catch up. Don't take the one with the best marketing but look at independent tests.
Installing ad-blocking software which helps to reduce the risk of malvertising
Throw away plugins with a known bad security record, i.e. Flash, Silverlight and Java. Actually you don't need to use any Plugins today.
Keep your system lean and up-to-date. Throw away any software you don't need and don't install unknown software. Keep all installed software up-to-date. If it is out of support (i.e. old office versions) throw it away.
Get a router with a good security record. Lots have really bad security and can be easily used for man in the middle attacks.
Think twice before entering your login credentials anywhere.
Do sensitive things like online-banking on a dedicated system or at least another browser profile.
and there is probably more


How UPnP is vulnerable if the attacker is not connected in the same network?

Not exactly, UPnP requests to open ports can be sent without router's password. So UPnP is dangerous. Usually UPnP is enabled only on LAN side (wireless and ethernet), but in some cases (rarely but sometimes, on some old routers), routers have UPnP enabled even on WAN side which is very dangerous. In these cases, an attacker can open a port to access to an internal ip and port. He can try and try or bruteforce it to find internal ip addresses accessing to shared folders and that kind of services.

So, disable UPnP if you are not using it. If you have devices using it, be pretty sure that your router has enabled it only on LAN side.

Anyway, this is not related to wireless networks. Same effect on LAN side on wireless or ethernet.

A tool to exploit this is for example Miranda


How securely should one treat their primary public key?

... is my understanding correct that primary keys and subkeys are all
key pairs consisting of a private and a public key?

Absolutely. Sometimes to keep it simple we say "key", where as actually we mean "key pair".

... handling the public primary key? Is this the one that should be
shared with others or uploaded to a key server?

Correct. The public key of the master key pair is what proves that the signatures associated with this public key was made by you. That's why you make the public key of your master key pair available publicly.
How can one trust your subkeys? When you are using subkey, you provide also certification signature that shows that particular subkey (namely, the public key of subkey pair) is signed by your master key.
The idea behind this is following: When one trusts your master key, then one trusts subkey signed by this masker key.


Secure file encryption with OpenSSL and a little trick?

I know, the md5 of password + salt is stored in the first 32 bytes of the enrypted file now.

This is not true. It will only write the 8 byte salt and nothing derived from the password (not MD5, not something else) as you claim. Instead the salt and the password will be used together to derive the encryption key using MD5, but the user needs to provide the password for decryption so that the encryption key can be again derived from the (given) password and the stored salt.

The problem with enc is instead that MD5 is a weak key derivation function because it is too fast and thus  simpler passwords can be brute forced. See also openssl enc uses md5 to hash the password and the salt.

If you really need to use enc use a hard password so that brute forcing will not  be successful.

  Let´s say, I use a password with 256 or more bytes of random data,...

Yes, this is probably hard enough: 2048 bits of random data can be well considered impossible to be brute-forced, commonly even 128 or 256 bits (16 or 32 random binary bytes or about 22..44 random alpha-numeric characters) are considered sufficient.


Windows 10 seems to load session before user log in, is it safe?

One of the many small changes in Windows 10 Fall Creators Update is that the operating system can now automatically reopen programs that were running before shutdown or restart. If you shut down Windows 10 with some apps open, some of them are relaunched at next startup just like what is happening to you.

It usually opens the app or the window you didn't close when you hit the shutdown button by bookmarking that specific window or the application so that it automatically open when you restart or power on again.

If you want to start with no apps open (other than those set to auto-start via Task Manager/Start), you’ll need to ensure all apps are closed before shutting down or restarting the PC.

Though there is no way to turn the feature off in the user interface, there is a way to prevent Windows 10 from restoring previously opened programs after a restart.Microsoft suggests exiting programs manually before shutdown, so that they won’t be be relaunched after reboot. That’s the best practice.

You need not worry about the security of windows as it is the update officially from Microsoft itself.


If there is no authentication of at least party then then no connection can be trusted, and MitM is possible. MitM does of course require an active attack; just eavesdropping is not enough, and unauthenticated DH does protect against eavesdropping attacks.

Note that the authentication may require a relatively low amount of data (e.g. there are protocols that simply use vicinity) but some kind of authentication does need to take place.


I think it is doable for a small business provided someone can spend a chunk of time setting up a free tool with the rules you need for your environment (I'm thinking of Snort).  I see that you are a developer from your reputation on SO, so I assume there is someone who can do that.  It is just a matter of spending the time getting the tool in place and writing the rules (and keeping them updated and responding to alerts).

That said, Snort will do exactly what you want.   It has real-time alerting that can send emails and block unwanted traffic.  Snort rulesets are often the basis for other Intrusion Detection / Prevent systems.

A good example of the work you might be doing is revealed in these questions:
https://serverfault.com/questions/255843/custom-rules-for-snort

https://serverfault.com/questions/703559/how-can-i-put-snort-in-front-of-nginx-server

https://superuser.com/questions/930742/are-these-snort-rules-redundant


Vulnerability of a computer behind a serial port?

Interesting theoretical question, so I'll provide a theoretical answer :).

Lets assume that East1 and West1 are compromised (they're connected to the Internet and running COTS software so not a massively unreasonable assumption).

The interface to the code running on East/West2 is the software making the serial connection and transmitting the encrypted messages.  Like any software it will have bugs and these bugs may be security relevant.

If the software running the communication over the serial port has a buffer overflow issue for example it may be possible for an attacker to transmit a message which allowed for code execution on the serial-only computer.

At that point the Operating System in use on the serial connected systems could be relevant as OS level mitigations (e.g. ASLR) could be relevant in whether it's possible to exploit the hypothetical vulnerability in the software running over the serial connection.

Assuming that the software running the serial connection has an exploitable buffer overflow or similar it could be possible got get remote command execution on the serial connected machine and thereby get access to the one-time pad.

Of course in the real-world that's a pretty unlikely chain of events and it would likely be easier for the attacker to take some alternate avenue to get access to the information :)


Would an official  HTML (6?) element/wrapper combat XSS effectively?

Problems with your approach

No, this wouldn't work. The problems are:

An attacker can still inject tags. They can inject </disablescripts> to inject scripts and thus gain XSS.
It affects usability. What if I want to leave a comment that is: You can use </disablescripts> to exit the new HTML6 feature. After that, anything in <script>alert(1)</script> will be executed. That comment would not display correctly.
XSS is dangerous, but you shouldn't underestimate HTML injection, which would still be possible with your approach and allows to change the look and functionality of a website, which may be used for phishing attacks, defacement, and possibly even privilege escalation.

And that's not even considering the practicality of it. The problem with XSS is that developers often don't know where user input is expected. If they knew, they would HTML encode it already. But for some reason, they lost sight of what is user input and what isn't.

The same problem exists with your proposed idea: How does a developer know what areas likely contain JavaScript? Even if it was working, your approach would at best be a second line of defense, in addition to the proper solutions to XSS.

Better approaches to XSS

Better approaches are:

HTML encoding in HTML contexts, escaping in JavaScript contexts
Using something like HTMLPurifier if a limited subset of HTML is required
Use some templating engine or other mechanism that allows the automatic encoding of all variables (to ensure that none are forgot).
If you do not have inline JavaScript, use a content security policy such as script-src self https://cdn1.com. Only modern browsers will follow it, but they will not execute any injected inline scripts, and will only load external scripts from allowed sites.


What can you tell about this form input when it gives internal error with ';--' and not ';--?

From the samples given it appears to be a normal SQL injection with a string.

For argument sake, say the query was

select * from users where username='<user data>' ;

It is correct that the first two do cause an error as they produce invalid SQL:

select * from users where username='';--'' ;
select * from users where username='';---'' ;

Because with regards to MySQL comments:

  the “-- ” (double-dash) comment style requires the second dash to be
  followed by at least one whitespace or control character (such as a
  space, tab, newline, and so on)

Try ';-- '

Trailing single quote probably not needed.

The remaining produce either incomplete (i.e. no closing single quote) or valid SQL so don't produce any error:

select * from users where username='';--' ;
select * from users where username='";--"' ;
select * from users where username=';--'' ;

Note that

select * from users where username='';-f-'' ;

should error. I would confirm whether the result of this test case is correct.


Triggering Javascript by user-agent string. CSRF or XSS?

Your example is XSS.
The full definition of CSRF from Wikipedia:

  Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

Example of a CSRF attack:
let's say you own a website example.com, and you have a shop where users can buy items using GET requests. An example link would be: example.com/shop/purchase?itemId=123456, and it doesn't perform any authentication but making sure the user is online. You land on the page - Boom, $30 are withdrawn from your bank account.

Now, an attacker could take that link and mask it inside an email, or by embedding it into a clickable image on an active forum - thus making it appear safe (click here to read more, etc). When a user clicks that link (who does not want to buy that item) - he's automatically charged the $30 which he didn't even want to spend!

The protection against this is fairly simple - You generate a unique CSRF token for every user when his session is created, and force him to pass the token as a parameter. So now your link is example.com/shop/purchase?itemId=123456&token=abcdefg. Now, an attacker can't send me "malicious" links - because he doesn't know my token!

As you can see, this attack really has nothing to do with Javascript. Your example was persistent XSS (an interesting topic by itself, albeit unrelated to your question so I won't dive into it here)


How negative are virtual machines (vms) to /dev/urandom?

Statistical tests like the one you use cannot detect whether /dev/urandom is good or bad on a specific machine.

Specifically, /dev/urandom runs a cryptographically secure PRNG. From a given initial internal state (the "seed"), it produces an arbitrarily long stream of seemingly random bytes. The PRNG being cryptographically secure means that for an attacker to actually predict the next bit with probability better than 1/2, he MUST have guessed the exact internal state (down to the last bit); otherwise, he has nothing.

The risk of /dev/urandom in a VM relates to the theoretical possibility of the attacker being able to guess that state, since the state is fed from hardware sources and a VM has no true hardware, only emulated hardware. However, this requires an intelligent attacker that perfectly knows that the PRNG is the one usd by /dev/urandom on this specific machine, and the attacker purposely tries potential internal states based on what he knows about the emulated hardware and what the OS extracts as "random seed" from that hardware. Your rngtest does nothing of the sort; it runs basic statistical tests to see whether there are biases in a 100 Mbits stream.

To summarize: rngtest does not test the important thing, which is how much the seed is hard to guess by an intelligent attacker. Instead, rngtest measures how well the cryptographically secure PRNG algorithm is indeed cryptographically secure; and it does so only basically (it cannot see anything except the most obvious biases). By nature, rngtest cannot detect any VM-related issue with /dev/urandom (and, correspondingly, it is quite useless to run it).


What is the best practice to save encrypted data to a database?

Based on the information provided in the update, I would suggest to use the same key for each field. Different keys would be an overkill as you might want to encrypt other fields as well and also it would be cumbersome to map the fields with different keys.

Following points can be considered with this approach :

The encryption key is not stored at the same db where encrypted data is being stored. (consider to store in configuration file)
The encryption key should be sufficiently long to prevent any brute-force attack on the key itself.
Based on the frequency of usage and sensitivity, decide whether to use Symmetric or Asymmetric. (refs : comments)

Edit 1 :

If using the config file to store encryption key, make sure to not commit the key accidentally. Instead, commit a dummy key and replace it during deployment.


Fake "FROM" email to allocate to account

There is no direct way to know if the from address is forged or not.  It is trivially easy to change when sending an email.

You can't even always tell if it came from the right server - many domains dont have SPF setup properly.  And sometimes people send emails through other servers because they have to - for example some ISPs require you to send through their mail server and block others.

There are several ways to handle this:

Send an email back requiring confirmation by clicking a link.  They can forge the from address, but they wont be able to recieve replies.
Require the emails to be signed with a PGP key or similar encryption.
Attach the file to their account as a "draft" or "pending item" or something and have them approve them later.
Give everyone a unique secret email address to send to.  This is how services like Evernote handle sending in email attachments.  Its not perfect but it does help.  You can still validate the from address or simply allow it from any address. Make sure people can change their secret address in case it gets out.


Yes, full-disk encryption using AES-256 would be considered HIPAA compliant encryption.  It is so because it is a FIPS 140-2 compliant cipher, and data encrypted with FIPS 140-2 cipers is considered "encrypted" under the HIPAA Security Rule.

As to whether this qualifies as good enough for "data at rest," that is up to your organization's interpretation of this seemingly ambiguous section of the HIPAA act.

Full disk encryption is a measure to help physical security.   "Data at rest" can be interpreted to  mean both the physical layer (in this case, if someone steals the Mac, the data would not be available as it's encrypted) as well as the availability of the actual data files sitting on a disk.

For example some organizations might consider databases backups sitting idle on a disk "data at rest" and would choose to encrypt these files with a password, e.g. using 7zip with AES-256.  Some organizations might consider full-disk encryption enough for the "data at rest" standard.

This is an area of much debate when it comes to the HIPAA security rule.  If you're concerned having files on a computer not encrypted with a password or PGP key etc might be a risk, it is best to err on the side of encryption.  Under HIPAA, if encrypted data is compromised this need not trigger reporting/breach disclosure requirements, since the data could be assumed inaccessible to third parties.  If non-encrypted data is compromised, and this includes hackers with malware taking files off an online computer that does have full disk encryption enabled; then this will trigger reporting requirements.  It's up to you to weigh the risk.


Is there any way capture HTTPS Request with Python?

HTTPS runs on top of TLS.  That is the entire HTTP request and response is encrypted, and an application eavesdropping on the network traffic will not be able to decrypt the traffic.

That said, you could log the IP addresses (especially those connected to servers on port 443 - HTTPS) as the IP layer is not encrypted.

This is what your netstat command does.  It looks for TCP connections on your network card, and notes which ones are connecting to port 443 (well known protocol for https) and observes the IP address of the HTTPS servers you are connecting to.

I should note that if you capture encrypted network traffic, it is possible to decrypt such captured traffic if you save the SSL key from your browser.  See here for instructions how to decrypt SSL eavesdropped network traffic with wireshark when you log your SSL keys; you should be able to do something similar with scapy.


Why are encryption methods chosen by what is not broken instead of what is possible?

The simple answer is, it isn't that simple.

There a number of reasons for this.

First, let's address the notion of:

  "What is not broken, instead of what is possible?"

Outside of information theoretically secure algorithms, all algorithms fall under the category of "isn't broken yet" for some notion of semantic security.  This includes entire classes of systems that we don't have (in use today) good quantum resistant replacements for, like asymmetric algorithms for digital signatures and key exchange in TLS.  Not that quantum resistant algorithms for problems like key exchange and signatures don't exist...We just haven't figure out how if we can use them practically yet, and in cases even done enough research to be sure they're actually reasonably secure.  So "what is possible" is more academic than practical, even in the world of hyper-scale systems.

On that note, performance.  Even in the world of hyper-scale systems, performance is critical, even to the largest players.  Google, for one, is constantly looking for ways to shave milliseconds and increase the number of concurrent sessions they can serve, and they (and everyone else) has to be concerned not only with their own servers but with the hardware the client has on the other end, which may be a modern laptop, or a 15-year old low-end desktop, or a smart-phone, or an eight-year old feature phone with a basic web browser, or for non-web systems, a low-power embedded device, or a smartcard with almost no computing resources at all.

On that note, compatibility.   Even in the most up-to-date modern x64 processors and software can easily handle any algorithm thrown at them, as  Matija noted in another answer you can implement algorithms in a cryptosystem that can't be understood by consumers of those systems.

Additional considerations pointed out by SEJPM in a comment is certification, and politics.  Some systems implementers don't even have a choice in algorithms.  A FIPS-certified system, for instance, can only implement FIPS alogithms.  And not just any implementation of those algorithms will do..The implementation itself needs to be FIPS-certified.  Many US government systems have this requirement.  Russian systems, on the other hand, may be required to implement their own standard algorithm, GOST.   So even in senarios where better algorithms exists (and for FIPS, this is a reality, not a theoretical) they aren't an option for regulatory reasons.

To deal with all of these issues, we have a variety of options, and all of those options come with various benefits and drawbacks, and for a specific use we have to consider carefully the trade-offs which make choosing the "most secure" option subjective, and often impossible to measure without resorting to individual opinion on the impact of those trade-offs.  And, as we've seen, due to performance and compatibility requirements, security itself is a valid trade-off to make in order to produce an entire system that works nominally optimally well.


A malicious folder is created automatically?

The file it is trying to download is not exactly malware; it is a potentially unwanted program (PUP) (probably spyware). See here for details.

Apparently the game you downloaded was either downloaded by a downloader, or packaged into an installer, that relied on OpenCandy.

From their site:

What is OpenCandy?

OpenCandy is a service that helps app developers earn money and keep their apps free-of-charge for you, the user. Developers earn money by recommending other select, free apps during the download and install process of their free app. We guarantee that all app recommendations are optional and you may choose to accept, decline, or uninstall any app at any time. As it takes an enormous amount of time, effort and investment to create apps, we are focused on helping these developers keep their apps free (and their lights on) while maintaining the highest quality user experience.

Usually you should get:

a checkbox in the install process allowing you to opt-out and not install OpenCandy on your computer;
an entry in the Control Panel > Installed Applications > Uninstall list allowing you to remove OpenCandy after you have installed it;
OpenCandy entrypoints and hooks that are not hard to hunt down and kill.

Since it's too late for option #1, see whether condition #2 holds. Unless your game's developer was feeling particularly unscrupulous, you should be able to find an entry for either OpenCandy or Advertising which you'll be able to remove.

IMPORTANT: be aware that some tools claiming to remove OpenCandy or listing it among the spyware they remove are malware in their own right.

This tool (others exist) claims to be able to remove OpenCandy, and at this moment, VirusTotal gives it a clean bill of health. (Their site is listed by ESET Smart Security, updated not five minutes ago, as "unsafe" - I have notified ESET).


How to trace a DDOS attack on a dedicated server and block it?

Are you sure this is a real DDoS? Over an 8 month period you would think that the "attackers" would find something better to do. Did you implement an update in the game around that time that causes it to fail an authentication procedure or something similar?

you can disable UDP as per this answer, however note the answerer's warning

  "I've NEVER encountered a situation where turning off UDP was a good idea. It seems like you're trying to secure your system by randomly turning things off, without understanding what you're doing, or how security works. Please don't."


using multiple Firefox profiles to increase security

Yes it would increase security, as (malicious) cross-domain information leaks aren't possible between browser instances. You can also minimise the use of plug-ins and add-ons in high security browser environments, as they expose additional attackable surface.

Another way to mitigate the risk of malicious code running in your browser are ad blockers and NoScript-like add-ons. Chrome/Chromium allows you to disable script and plugin execution through its built-in domain-specific policy settings.

Separate browser instances will not protect against malware running on your computer. If an attacker successfully exploits a remote code execution vulnerability in one instance or gets you to run his code through social engineering, the resulting malware has access to all browser profiles/instances under the same user account (unless the malware manages to escalate its privileges).