Are Linux System Capabilities Considered Mandatory Access Controls?

Generally capabilities are a good way of implementing a Mandatory Access Control system (see Eros OS, for example).

The Linux system capabilities affect objects which can be under both DAC and MAC.  They also don't seem to break the possibility to do MAC since you can limit altering capabilities using the bounding set.  Once you remove the ability to alter MAC settings from the bounding set on all processes, then you have full MAC on the system.  Of course implementation bugs may make this wrong.  If you don't remove the alter MAC capabilities then processes that have them are able to treat mandatory access controls as discretionary.  If any of those processes (or files they start from) are not part of the "trusted computing base" for your system then what you have is a system configured with discretionary access control.

I think the best answer to your question is:
system capabilities are designed to support and could be part of a mandatory access control implementation, incorrectly configured they could also break mandatory access control.


For a password of that length, your only real options are to subvert it entirely, or try a different approach.

Rainbow tables aren't yet big enough to cope with that length, but because the majority of passwords in use are badly chosen
A dictionary attack may give you better odds of breaking it. You'd need to make some assumptions on words, alternate characters etc and will have no guarantee that your assumptions are correct.
Have a look at this question over on the Security Stack Exchange for some in depth discussion on passwords sparked by the famous xkcd cartoon.
Social engineering might be your best bet - however that probably doesn't come under the remit of an Ethical Hacking course at University.

You should definitely come on over to Security SE anyway, as it is likely to give you useful input which could help you on your course.


Exposed my browser cookie of my request header

Can someone still use that browser cookie to impersonate me?

As @Hackndo noted, this is totally up to the web-developer.

am I safe now

Guessing, I would suggest you change your password, not just log out.
Here is a deterministic way to check:

Now take your cookie, then log in (or change your password) and compare the 2 keys to see if they are the same.

if they are not the same, make an http request with your old key, and see if it is valid. You say that it is stored in cookies, if so you can use curl to send cookies. If the key is stored in it's on header (cookies are seperate), something like this

GET / HTTP1.1
Authentication-Key: "some_key"
Cookies: cookie1=something;cookie2=comething;

you can still use curl to define custom headers.
If the Authenticaiton Key is not send with either of these formats, you'll have to replicate your browser's behavior by looking in the network tab.


In practical terms there are three threats I'd be worried about:

Passive monitoring by network owner/other users on the network
Direct exploitation by network owner/other users on the network
Active man-in-the-middle attacks such as Karma and sslstrip

If you haven't already, I'd recommend simply adding Wireshark to your demonstration, and showing a capture of someone logging into a website over HTTP (if you can find one, or create one). This will show how trivial it is to sniff sensitive information from a shared network if the connection isn't encrypted.

For threats #1 and #3 above, a good trusted VPN service (e.g.Encrypt.me or NordVPN) will mitigate these risks. For #2, keep your devices and applications up-to-date.

However... I'd argue that there is a bit too much hysteria about the risk of using public WiFi.

Most of the legitimate concern about public WiFi began because of #3, particularly before HSTS became a thing. Back then it was possible to use sslstrip against major banking sites and other valuable services (Google, Facebook), and the only real mitigation was "don't join non-password-protected WiFi networks", or to use a trusted VPN at all times. Now that HSTS is available this is much less of a problem (for those sites which support it), although it's still a good idea to use a trusted VPN if you're worried about local MITM attacks of this sort.

For most users, #1 is a non-issue as the services they're worried about would be using HTTPS. The major exception is that DNS requests are still in-the-clear in most cases (users might not want someone on their network knowing that they're making DNS requests for pornhub.com). A trusted VPN will solve this problem.

Direct explotiation (#2) is also a non-issue for most users unless they're using very outdated software (i.e. running unpatched Windows 7 or an obsolete Android device), or unless their threat model includes attackers with 0-day remote code exec exploits (if this is the case, they likely have bigger problems than connecting to public WiFi).


What does this sh script do if executed?

I downloaded the first URL (http://something.example.com/xx) and ran

$ file xx
xx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, not stripped

So, it's an executable program meant to run on a Linux machine.  I assume you are running a Linux server.  Next, we want to see what the program does, but of course, you don't want to run it.  A quick way is to ignore all the computer instruction code embedded in the executable, and just look at what human-readable strings it might contain.  So, I ran

$ strings xx | less

[... excerpt ...]
NOTICE %s :Receiving file.
NOTICE %s :Saved as %s
NOTICE %s :Spoofs: %d.%d.%d.%d
NOTICE %s :Spoofs: %d.%d.%d.%d - %d.%d.%d.%d
NOTICE %s :Kaiten wa goraku
NOTICE %s :NICK <nick>
NOTICE %s :Nick cannot be larger than 9 characters.
NICK %s
NOTICE %s :DISABLE <pass>
Disabled
Enabled and awaiting orders
NOTICE %s :Current status is: %s.
NOTICE %s :Already disabled.
NOTICE %s :Password too long! > 254
NOTICE %s :Disable sucessful.
NOTICE %s :ENABLE <pass>
NOTICE %s :Already enabled.
NOTICE %s :Wrong password
NOTICE %s :Password correct.
NOTICE %s :Removed all spoofs
NOTICE %s :What kind of subnet address is that? Do something like: 169.40
NOTICE %s :Unable to resolve %s
NOTICE %s :UDP <target> <port> <secs>
NOTICE %s :Packeting %s.
NOTICE %s :PAN <target> <port> <secs>
NOTICE %s :Panning %s.
NOTICE %s :TSUNAMI <target> <secs>
NOTICE %s :Tsunami heading for %s.
NOTICE %s :UNKNOWN <target> <secs>
NOTICE %s :Unknowning %s.
NOTICE %s :MOVE <server>
NOTICE %s :TSUNAMI <target> <secs>                          = Special packeter that wont be blocked by most firewalls
NOTICE %s :PAN <target> <port> <secs>                       = An advanced syn flooder that will kill most network drivers
NOTICE %s :UDP <target> <port> <secs>                       = A udp flooder
NOTICE %s :UNKNOWN <target> <secs>                          = Another non-spoof udp flooder
NOTICE %s :NICK <nick>                                      = Changes the nick of the client
NOTICE %s :SERVER <server>                                  = Changes servers
NOTICE %s :GETSPOOFS                                        = Gets the current spoofing
NOTICE %s :SPOOFS <subnet>                                  = Changes spoofing to a subnet
NOTICE %s :DISABLE                                          = Disables all packeting from this client
NOTICE %s :ENABLE                                           = Enables all packeting from this client
NOTICE %s :KILL                                             = Kills the client
NOTICE %s :GET <http address> <save as>                     = Downloads a file off the web and saves it onto the hd
NOTICE %s :VERSION                                          = Requests version of client
NOTICE %s :KILLALL                                          = Kills all current packeting
NOTICE %s :HELP                                             = Displays this
NOTICE %s :IRC <command>                                    = Sends this command to the server
NOTICE %s :SH <command>                                     = Executes a command
NOTICE %s :Killing pid %d.
TSUNAMI
UNKNOWN
NICK
SERVER
GETSPOOFS

"Enabled and awaiting orders" suggests that this is a program that makes your server act as a botnet node.

The next file it downloads, http://something.example.com/ru, is a shell script, which in turn downloads a .tar.gz file from http://example.hu/ar/64.tgz (or 32.tgz, depending on your CPU architecture), then installs and runs it.  That archive contains three files:

A php interpreter compiled for Linux
Another Linux executable named pnscan
A shell script named run which launches pnscan

The other thing it does is create a weekly cron job what downloads and runs http://something.example.com/sh, which contains exactly the shell script you posted above.  Basically, it will automatically reinfect your machine every week unless you uninstall that cron job.

Recommended action

The code looks like it was put together by script kiddies.  It uses existing tools such as pnscan, tied together with some shell scripts.  It's not Stuxnet-quality code.

From the information you added later (your Apache server has no PHP support, your Apache server is still running normally, and no cron job got installed), it seems likely that the code never actually ran on your server.  In that case, you are probably OK!  Run ps ax to check whether anything suspicious is running, and you should be fine.


Will all the key pairs that ssh-keygengenerates be unique (not taking collision into account at this point)?

Yes, every key pair will be unique, with well above 99.99999% probability. This is largely due to the size of the key space and the quality of the CSPRNG that is used (see below).

  If yes, how does ssh-keygen assure that all key pairs that different people generate at different times are unique and do not end up being the same?

It makes no such assurances, but it is effectively guaranteed to be unique anyways. This is because the OS uses a high quality CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) algorithm that is much more reliable (meaning, more unpredictable) than the out-of-the-box PRNG you get with most languages.

  If no, on what factors does the uniqueness of a key pair depend? Other than key length space, and PRNG.

The uniqueness comes from the CSPRNG, not a "regular" PRNG. The difference is the choice of entropy.

A PRNG simply takes some seed (usually either "0" if a programmer is lazy, or some arbitrary measure, such as from time()), shuffles the bits around every time something asks for bits, then does more shuffling. It only "appears" to be random until you observe the output for some period of time, at which point you can determine (a) which seed was used, and (b) the next infinite number of outputs that will be observed from that particular PRNG.

A CSPRNG, by contrast, builds entropy the longer it runs. It does this by taking periodic readings from multiple devices and applying some pretty complicated abstractions to the incoming data to generate a pool of "random" bits. This means that if you're running a flavor of Linux when you loaded this answer, odds are some bits of this answer are now floating in your entropy pool (until they are used, at any rate).

Logically, of course, these bits are random in the sense that computers do not actually have the capability to do "random" things (they always precisely follow the instructions given to them), but they are nevertheless random in the sense that no generic algorithm devised by either man or machine can possibly hope to determine the original entropy numbers, which is being constantly replenished as random numbers are generated.

Since computers often receive different types of input from the network, disks, and so on in fairly unpredictable order (because of latency, retries, other physical characteristics of hardware), it would be impossible for two systems to be perfectly synchronized to the point where the CSPRNG would also be in sync. Similarly, it'd be impossible to predict the output of a CSPRNG unless you were literally debugging the kernel, and the very act of doing so, or trying to report the current state, would alter the state of the CSPRNG.

Of course, the official documentation is quite clear on this: it's all theoretical, as we have no way of proving that no key will ever be generated twice. However, the odds are so incredibly stacked against ever finding a random key that was a duplicate that one may as well say it is indeed impossible.


Stringify the sent information in a standard way, take the SHA256 hash, sign it with the private half of the key-pair that is genned for the handset when the application is installed (the public half is sent to the server at enrollment time).

Most importantly, HMAC is easy to do wrong because it is crypto and crypto is really hard to do right (even Ron Rivest -- the R in RSA, and possibly one of the top expert in crypto -- can come up with something like RC4 which has some protocol-level weaknesses_. DO NOT ROLL YOUR OWN CRYPTO. I would bet money you will not do it correctly. Instead, use existing algorithms, existing methodologies, existing libraries. HMAC using SHA256+ECDSA is well understood and has been tested. If you go with EC crypto for your public-private key-pair-generation and signing, use a curve that is well known, such as the NIST curves, since they have the most scrutiny and have highly funded cryptanalytic research by the federal government.


Should WS-Fed, Mozilla's Persona or OpenID ever be used with a Banking application?

I think that banks should keep their systems closed and have stricter security policies than most OpenID providers.
Imagine logging into your bank account using Facebook, Gmail or other providers. This would highly increase the attack surface.

Most banks have hardware tokens for their web banking sites and several others security features in place to protect your transactions. Common setups involve:

Primary authentication using an username and a password
On every sensitive operation while logged in, a token generated by the hardware device is requested
A message is sent to your email/phone with details about transaction that have been made an exceed a certain amount.

Banks have a very sensitive environment they have to protect and relying on third parties for the authentication is not the best solution.

They should have strong systems in place that they can be audited at any moment and they should also be able to deal with any security incident (have logging mechanisms, alerts for abnormal behavior ,etc).

If your bank does not already have multi-factor authentication then they are one step behind in respect to their web application security.


As long as you have a proper SSL in place 95% of your risk factors are eliminated.  Because your data-stream is encrypted, a MiM cannot read what you are sending or modify any data in it without completely corrupting what is received on the other side.  In order for the file to be intercepted for modification, the attacker would need some manner of malware on your local machine at which point, most origen validation processes become a moot point if your attacker knows what he is doing.

That said, your best bet to prevent externally modified files from being opened by your program is to add tracking codes for each file.  The tracking code could be some product of the file's Hash and a verification key generated by your program.  That way, even if an end user tries to figure out how to sidestep your upload procedure and push his own file, it won't have a valid key and your program will know not to allow it to be opened. But, as Anders pointed out, this is not a full proof method.


In a lock you have a key (in a normal lock it is an actual key) having some features (grooves, indentations, crenellations) that

are difficult (ideally impossible) to duplicate
are difficult (" ") to tamper with, and do not degrade/change with time
are easy to verify
generate a very large keyspace (reducing the feasibility of a brute force approach)
are cheap to make ;-)

In a biometric lock the key is a living organism (e.g. you), hence the bio- part, and the features are some measurements (hence the -metric) on said organism.

Several measurements can be taken from a human being, but when you check them out with the above checklist some difficulties pop out:

fingerprints are easy to duplicate
retinal image is complex to acquire
the voiceprint is prone to changes
muscle memory is again prone to changes
DNA scan is either slow, or not sufficiently accurate

Whenever a measurement is prone to changes, it needs either to be measured with great accuracy and multiple attempts (which becomes awkward), or the acceptance criteria need to be relaxed; and in that case the "keyspace" shrinks and the duplicability of the measurement may become easy (e.g. computer generated voice samples from recordings).

Mixing several measurements, also adding in the mix some that per se would not be reliable, can increase accuracy and reduce the vulnerability. For example a fingerprint reader could be equipped with unreliable sensors to verify:
 - the IR emission (passive) is that of a live human finger
 - the IR emission (passive) shows fluctuations at approximately the heartbeat frequency
 - the IR and visible reflectivity (active) are those of human flesh with nothing (such as a thin fingerprint-printed silicone layer) between sensor and flesh
 - dielectric characteristics are those of a human finger
 ...

The problem becomes then one of cost.

Once the "defense" sensors have given their okay, you run a feature extractor on the raw signal, and from the basic features and an average feature survey you can establish the information associated to each feature.

For a fingerprint, the "features" could be the presence and (relative) position of specific markings - ridges, whorls, loops and so on. For human voice, the spectral content of same. For muscle memory, the timings and precision of some well-known and repetitive task such as typing one's name on a keyboard. For DNA it could simply be a given DNA sequence (...ACTGATTTCAAC...). And so on.

Ultimately this yields a string of bits, which is the representation of the signal also "cleaned" of unwanted variations (in the fingerprint case, these would be caused by finger pressure, speed, alignment; in the DNA case we would look for a sequence between two easily recognized and unique 'marker' sequences, possibly amplified and reconstructed from several samples) and noise (in the finger's case, possibly dirt or sweat).

It is then a matter of searching a user database for the desired string. Finally this yields a basic information ("found" or "not found") and possibly a user identification ("Found: user ID 123456").


How can a customer authenticate EPOS device and make sure it's not fake?

Switch from magstripe to chip cards

The only way for preventing a fraudulent merchant or POS from impersonating a customer/card is by ensuring that the card data cannot be copied and cloned by the merchant simply by having the card available during a normal payment process. The switch to EMV chip cards was intended as a solution for this and other problems.

The scenario that you describe is very similar to other popular attacks like a third party attaching a skimming device (e.g. on ATMs) or a dishonest waiter swiping a card in a real terminal and also another card reader. The customer can spot such risks in some cases, but in general they cannot eliminate the risks, cannot do a full validation and will have to trust the merchant and accept some risk or not use magstripe payment cards.

The main practical way for fighting this type of fraud is by identifying common point of purchase after fraud has happened, and verifying identities of potential merchants - so that it becomes impractical to do this because you're very likely to get caught soon, and it's not that easy for such criminals to recreate new legit merchant connections many times.


Storage of account password on keychain iOS to enable TouchID login

Suppose you have an iOS app that accepts a username and passcode. This login information would be entered by the user, then you could store that state by saving the credentials in the Keychain, which is the only place secure enough to store that information on device.

If the above is already in place, than adding Touch ID only increases security because the iOS Touch ID API works by simply unlocking keychain items. So you would use the LocalAuthentication framework to ask for Touch ID authentication. This API would then present the UI on the screen, send the encrypted fingerprint data to the Secure Enclave, and send you back a result that simply specifies whether the match was successful or not, optionally unlocking the associated keychain item for the user's login item. At no time is your app given access to the fingerprint data, and if you need further authentication you can associate a keychain item that would be unlocked on success.


Unwanted DoS by portscans is kind of a myth. A simple CONNECT or SYN scan (ab)uses TCP functionality to find out if a port is open or closed. This won't be a problem for the running daemons because thy almost surely leave it to the operation system to handle the resulting events. The only way a daemon has to handle these itself is when the developer used RAW Sockets.

When it comes to more extended scans that for example are used to guess which operation system is running on a host it can theoretically cause problems to very old or poorly configured hosts. This is because OS guessing is (beside other techniques) done by causing unusual situations to the host which then has to react. These reactions in many cases are specific to a TCP/IP Stack implementation which can be attributed to an OS or a Kernel Version,...

What really can get dangerous is using a vulnerablity scanner linke nessus without the needed knowlege and/or care. There are thousands of modules and some of them can cause a DoS (and they are labeled as those) to the scanned system.


If most ATMs are Windows XP, and Windows XP is no longer updated...?

ATMs normally lie on a isolated network directly to the bank that owns the ATM. This is normally enforced by a VPN-router if theres no leased point-to-point line at the location, where the local end does not allow any traffic outside the VPN, even if malicious software on the ATM deliberately tried, and the remote end's firewall is configured to not allow any traffic other than is required for ATM operation.

This means normally that the ATM does not have access to the internet, nor does the internet have access to the ATM.

As the customer also never gets to have any physical input to the ATM, like usb, keyboard or mouse, rather the customer input via cardreader, pinpad and screen selection buttons, are managed via RS232, and similiar interfaces, so the ATM software has full control and customer cannot send any data to the underlying operating system, the ATM can be considered being isolated and safe.

Thus:
Since theres no possibility to inject malicious software, neither via the local console (if you don't have the keycard to open the restocking/maintenace room, but then the security of the ATM computer is less of a issue since if unautorized access has happened to that room, ATM is usually replaced as a precautionary measure), and neither via the internet, unless you do have access to the bank's server hall where the VPN terminates.
There cannot be malware or hacks on the ATM in the first place, regardless of the security of the OS.

And in addition, even if someone managed, despite all security measures, to plant some sort of malware on the machine, the malware cannot send its data anywhere.

Communication with the card reader, pinpad and cash unit is usually encrypted end2end.

In other words, by planting malware on a ATM, you would just get a fancy receipt printer, or you can prank the user by changing the amount the user want to withdraw - eg user select "10$" but a "50$" bill comes out and "50$" is pulled from account (and most users would regard the ATM as broken and depoist the sum they got "too much")

So the security of the operating system on a ATM does not really matter. The security around is normally so tight so it compensates.

In addition, some newer ATM provisions their operating system and relevant ATM software via PXE, and reboots regularly, to clear out all and any unauthorized changes to the system installed on the ATM.


how to find out if a program sends data to internet (without permission)?

You can use TCP View which is usually used by investigators and security experts to determine the behavior of certain malware, where it's establishing connections/getting commands from, or more common use is to solve cases where an individual is spying on another by use of Webcam/Microphone etc, by tracing the IP address; an example use of TCPView in such cases is that of Jared James Abrahams who hacked into several of his peer's computers to sextort them with pictures of he would take via their hacked webcam. (Sometimes the "hacker" is just someone without much knowledge in security/IT, so they don't take precautions to mask their IP)

This is an example of TCP View showing an executable connecting to external addresses

Then to know what data the executables are sending, you can do packet sniffing, using software such as Wireshark that allows you to a network protocol analyzer.


Can my ISP/MSP read my Whatsapp messages?

Short answer: NO, if you are sure you are using end to end encryption, and MOST LIKELY NO, if you aren't using end to end encryption.

Whatsapp uses encryption two ways: first it has an "outer layer" built by TLS, which has ben analyzed thoroughly by the security company Praetorian in February 2014, with almost all issues pointed out being fixed within a day. The page only says that Whatsapp promised to include certificate pinning, but I assume they did in the meantime. If there is no certificate pinning, then ISPs/Governments with control over certificate authorities can indeed mount a successful MITM attack (and we know that china did this).

The second, inner layer, is more secure, when active. It uses the encryption used by Textsecure, and, if you have verified the keys of the the parties you communicate (e.g. by meeting them in person and comparing hashes), is quite secure (using modern standards, etc, but without a professional review), once you know its activated. The activation part is the problem: you never actually know.

Also, according to this answer, textsecure wasn't encrypted over 3G in the past.


Even though modern Web technologies use the complete domain name as a the one security boundaries, HTTP cookies is an old technology that isn't rooting in RFC but in history and evolved from a world with poor isolation.

Cookies can be segregated by exact domain name match, or by super-domain: on that very Web page, my browser informs me that it has a bunch of cookies for the  domain stackexchange.com which is a super domain of that of the page (https://security.stackexchange.com/questions/227598/ideas-for-subdomains-isolation).

The sharing of these cookies is the problematic issue with hosting user provided, arbitrary and totally non-secure HTTP content

content provided with an HTTP content-type header that either means HTML content (or generic XML/SGML that is seen as HTML),
or content with a content-type that is plain text but which may be "sniffed" as HTML by the browser (as historically HTML HTTP browsers are known to have such "quirks")

in your super-domain.

It isn't the only issue: not only existing cookies could be read (which could be prevented by the HttpOnly flag), but even if you have none of these cookies, the active HTML content could set new cookies that are shared on the super-domain. These cookies will be associated with the super-domain.

The extreme weakness of the HTTP protocol means that only the HTTP server tells a browser the scope of the cookie when it is set, the browser never repeats back that information. It means that the HTTP server has no way to determine the origin of a cookie: which complete domain name set a cookie, and what is its scope. The browser has that information, the end user can access it (f.ex. with the page inspector, you can see a list of all cookies set or sent during that page load), but the server won't have it.

[Note:

Google set up the googleusercontent.com for a reason: any complete (whole Web pages, not HTML fragments) user content is provided from a completely different domain (webcache.googleusercontent.com) from the one domain trusted by the browser (google.com): there is zero chance the Web client can confuse these domains. Only the end user can navigate to (non existing) https://webcache.googleusercontent.com/zfzefzef

and see that the domain certificate is attributed to

CN = *.googleusercontent.com
O = Google LLC
L = Mountain View
S = California
C = US

(Another hint is the list of altNames in the certificate, many of which are very recognizable as Google's.)

That's the kind of effort it takes for an end user to identify that a domain is owned by the same entity as another.

end note]

Because the client doesn't inform the browser which entity was the source of any particular cookie, the server can be confused by a cookie with the same name set by a subdomain; if more than one domain has a cookie with the same name, the behavior of browsers is unpredictable, with either multiple Cookie header, in some browser dependent order, or the concatenation of all cookies in one header. Making some part of cookie names unpredictable by any adversary (like cookie_name_RANDOM_SEQUENCE) at least avoids the concatenation of multiple cookies issue, but it doesn't authentify the origin of a cookie.

Conclusion: to be safe, do not allow any potentially active HTML content (one with working Javascript) anywhere inside (in a subdomain of) your trusted domain.


Someone called someone else with my phone number

Someone placed a call to 'the guy', and spoofed the caller id to make it look like the call came from your phone number.  Caller-id spoofing is not uncommon, and there are even VOIP services that actually offer this as a 'feature'.  'Junk callers' often spoof the caller id to make the call look like a 'local call', so as to make the recipient more likely to answer the call.  See https://en.wikipedia.org/wiki/Caller_ID_spoofing for more info.


Can I use Let's Encrypt to verify my signing key?

GPG and Browsers trust certificates in fundamentally different ways.

How do Browsers do it?

Browsers need a set of trusted root certificates. These either come bundled with the browser, or the browser relies on the root certificates that the OS provides.

When trying to validate a certificate, the browser checks first if the certificate matches what the browser is trying to access (e.g. if a browser tries to access security.stackexchange.com, does the certificate claim to be from security.stackexchange.com?) and then checks who signed that certificate. Then the browser checks that certificate, all the way up to the root. If the root is found in the browser's trust store, the certificate is considered valid.

How does GPG do it?

The above mentioned approach requires trusting certain third parties not to issue bogus certificates. Instead, GPG tries to distribute trust among peers. The way this works is that you generate a key that originally nobody trusts. You then share your key with your peers, and your peers then sign your key. They can choose the following options:

Marginal trust: This option means that you trust that key a little bit, but not necessarily completely. This should be used if you got that key through some means, but can't actually 100% verify that the key is legitimate.
Full trust: You trust that the key belongs to whoever you believe it to belong, and you also trust that the person will make sane signing decisions.
Ultimate trust: This is for your own keys. You will trust everything these keys do, and everything signed by these keys.

How do I fix this weird GPG error?

First of all, your friend needs to verify through some means that the public key they received is actually yours. This can be done through any channel which you think is unlikely to be compromised - most favorably in person.

Then, your friend should sign your key. It doesn't matter what trust they give it, just that they signed it. As a result, your friend's GPG installation will consider the key trustworthy.

Why would you even do such a complicated thing?

GPG is notoriously user-unfriendly, which is likely a reason why it is not widely used outside of enthusiast circles. The core idea behind it, however, is that solid trust established by meeting in person and exchanging keys is very very difficult to subvert. No compromised CA could get you to trust a key which you did not manually set to trust.

If this is something you are worried about is a different story. If you want to learn more about GPG's trust model, this article gives some good insights.


Finding mechanism of unauthorized data access on OneDrive/Windows 10

How can I find or trace the mechanism by which she is doing this?

There's hardly a benefit in that. If you find out, what would you do next? If you think she should be penaltized for illegal activities, you should report crime and your computer should undergo a forensics analysis.

  Months ago, ...

The later you do that, the less successful it will be.

  Windows Defender would detect those because they are well known. Is this a bad assumption?

IHMO that's a bad assumption. I think I can write malicious code in C# which simply runs. I have already implemented a keylogger without any problems. Given enough permissions once, it could run as a service and upload your keystrokes, files etc.

  What else should I use to scan for known backdoors?

From the before: maybe it's not a known backdoor, just some legit looking software.

  I would prefer to sniff out the intrusion mechanism, or at least some evidence of when and whence intrusions have occurred, before blindly locking down the system.

Your computer is compromised. You should return to a secure state as soon as possible. Create an image of the system (use "dd" on some Linux Live system), remove all personal data and run it in a virtual machine if you want to play with it.

Change all your passwords to different passwords. Use KeePass to create different passwords for each service. Have the paswords generated.

Be aware that she may have access to any data and keystrokes you enter on the VM. You should not log into services for which you have changed passwords.

So, what can you look for:

check all running processes including services. Microsoft software should be digitally signed.  Process Explorer provides a convenient way for checking Authenticode signatures.
check outgoing connections. TCPView may help. Wireshark is even more powerful.
check for additional user accounts. Maybe she has created an additional admin account.
check the disk for files with a creation date around the time she had physical access. Agent Ransack and Search Everything may help.


hmm is this confidential information? if is already public domain.. why even worry about how secure it is?
like if this was confidential and authorized level of access then I will do the copy over ssh.. scp just to mention a simple solution.


Is Tor secure if exit node is compromised?

In an ideal world, no. If the exit node is compromised it can only see the source tor node, the traffic destination (and potentially the traffic itself, if unencrypted).

However it's not simply a matter of you not sending "stupid" traffic such as logging in your personal e-mail.

For example, consider this scenario: the exit node is compromised, and it modifies the (unencrypted) traffic so that your client receives a payload that causes it to send traffic over the clear internet. For example, a Flash app, or malicious Javascript, or whatnot. See for example here

Of course a nation-state sponsored attacker is likely also to watch (some of) Tor's entry nodes, and in that case there's little you can do.

Nevertheless, if you assume some of the exit nodes of your Tor connections to be compromised you'll probably default to better security practices in your day-to-day Tor browsing, which overall is not a bad thing.


logging available client side cipher suites from Apache tomcat?

Yes, you can crank up Tomcat logging to include that information using the javax.net.debug system property.  That will allow you to get this sort of output, which includes the cipher suite proposed by the client:

*** ClientHello, TLSv1
RandomCookie:  GMT: 1073239164 bytes = { 10, 80, 71, 86, 124, 135, 104,
151, 72, 153, 70, 28, 97, 232, 160, 217, 146, 178, 87, 255, 122, 147, 83,
197, 60, 187, 227, 76 }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods:  { 0 }
***

Parsing Tomcat logs is one of those joys that ranks up there with dentistry, but of course it can be done, and will provide you a census of the cipher suites your clients are connecting to you with.

Alternately, running tcpdump (or equivalent) captures with a filter that will capture ClientHello messages will give you a store of raw data to mine. The following filter will capture just the ClientHello messages:

tcpdump -s 0 -w client_hellos.pcap 'port 443 and tcp[((tcp[12:1] & 0xf0)>>2):1] = 0x16 and tcp[((tcp[12:1] & 0xf0)>>2)+1:2] = 0x0301 and tcp[((tcp[12:1] & 0xf0)>>2)+5:1] = 0x01'


Is it possible to perform a MITM attack with a smartphone?

Technically yes, but only in the sense that it's technically possible to shoot down Air Force One with a hand-built trebuchet.

While it's in flight.

Over the Pacific Ocean.

THE DETAILS: The operative word in the phrase "Man in the Middle attack" is middle.

The way the internet - and most modern communications networks - operates is that a message sent from Alice to Bob goes from Alice to Alice's computer to Alice's modem to Alice's ISP to the interconnection between Alice's ISP and Bob's ISP to Bob's ISP to Bob's modem to Bob's computer to Bob.

I'm oversimplifying here; the point I'm trying to make is that said message gets passed through a lot of different systems along the way.

A "Man in the middle" attack happens when at least one of the systems in that path is compromised by an attacker, who can then attempt to read the message, or even redirect or modify it at will.

In theory, it doesn't matter what kind of device you're controlling, as long as it's at some point in the communications chain between Alice and Bob -- hence, "Middle". The trick with MitM attacks has always been to get into said middle in order to do your evil stuff.

So in order for this hypothetical situation to work, your smartphone would have to be legitimately accepted as a link in the communications chain. There are probably ways to do this, but the most obvious way would involve putting out a stronger signal than the nearest three cellular towers so that nearby phones will try to call through yours first... Oh, and you'd have to emulate a cellular tower's communications protocols as well while you're at it...

(Update: A friend of mine points out that windows has pretty horrible default settings in regards as to how it handles USB connections, so if you preload your smartphone with the right malware and then plug it into Alice's computer, you might get somewhere.)


Best way to allow sudo access when using ssh keys

The NOPASSWD option allows the sudo program to be executed by the sudo user without having to enter a password. It does not imply that your account is password-less.

Other users that run su youruser still need to enter the password for youruser. But if you are logged in as youruser (via physical access or over SSH), then you do not have to enter a password when you run sudo somecommand.


When can I start security test in an agile environment?

The short version is: as soon as there is something to test.
There are two common challenges that normally impact this on teams newer to agile development:

Teams still batch work. They do all of the design up front, then all of the development, then hand it over for testing. This often runs late and leaves little or no time for testing. This can be addressed a few different ways but they all boil down to building in very small pieces that take at most a few days to complete and those can go through testing steps (including security testing) early and on a continuous basis.

Testing is done in a manual or ad hoc way that assumes you will only test once. Again, regardless of if you are doing security testing or other testing, you're in an environment where you expect things to change frequently. This means that what was secure yesterday may not be secure tomorrow. Your security testings toolset needs to support this. A vast majority of things will need to be automated. Also, if all of your security testing is black-box, this will get away from your quickly. You want to target root causes of problems more than symptoms. Scan config files, use static code analysis, etc.


My site has Certificate Transparency enabled but Chrome is still showing NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Botched CT redaction
According to the CT lookup site (archived here) the certificate is logged as ?.goflyla.com. This looks very much like an attempt to redact the exact domain name.
And unfortunately that feature is not fully standardized yet. So it just doesn't work at the moment. (And any attempt to submit a redacted entry to the log will just result in Chrome 53 completely ignoring that log entry and saying: No log entry found. -- For details see SSLMate blog post linked below.)
So what can you do? -- I'm not sure. I'd guess one of two things:

Ask RapidSSL to fix the CT Log submission and re-submit with the unredacted hostname.
Buy a different certificate. And not from Symantec or a subsidiary. -- The reason is that Symantec was, for lack of a better word, sentenced by Google to CT log every new certificate (Archived here). -- (And it appears that that requirement also applies to their subsidiaries, like RapidSSL.) And other certificate authorities simply are not under that requirement.

Further reading:

SSLMate Blog, 2016-09-07, Why Chrome 53 is Rejecting Chase Bank's Symantec Certificate (Archived here.)

Despite the fact that redaction, practically speaking, does not exist, Symantec forged ahead and grafted redaction onto the original version of Certificate Transparency. The result is a Franken-certificate that works fine in browsers that don't support Certificate Transparency, but fails to validate in Chrome.

Log entry without redaction: https://crt.sh/?id=31180341&opt=cablint,x509lint
Log entry from later on that same day. Interestingly with the SAME serial number. I don't know what to make of that.   Also now with the weird redaction attempt of "?" Instead of "www": https://crt.sh/?id=30754735&opt=x509lint,cablint


"It is safe if only Port 443/HTTPS is accessible from Internet!" Is it?

Port 443 is the default port for HTTPS communication using SSL/TLS. As such, if you can reject and/or redirect traffic on port 80 (the default unsecured HTTP port) and reject all other ports, and if you can trust your web server OS's TCP/IP and TLS implementations, this scheme is as safe as any publicly-accessible computer communications endpoint can be made, from a hardware/firmware perspective.

However, this only proves that the means of communication is secure, and that this comm channel is the only way to get in. That can still mean the application communicating over this channel has vulnerabilities. Someone could hijack the remote system and use the secure channel to request information the person normally wouldn't be able to get. The remote system itself could store information it retrieves from you in an insecure manner. The component of this solution residing on your webservice could be vulnerable to any number of attack vectors that don't require breaking TLS itself; a third party could, for instance, perform a replay attack to corrupt data by making your server do things twice. Or, they could properly negotiate a TLS connection with your server and then pound on the relatively weak authentication system provided by the application.

In short, just because you can expose only port 443 to the world and accept only properly-negotiated TLS connections through it does not necessarily mean your system is secure. You must also trust that the application using the TLS channel is properly implemented to prevent various attacks carried out by systems using the channel. If you cannot trust this application, you should not use it.


Disk encryption with OTP to protect source code

Send one of your engineers with the laptop. Rationale:

If it's important enough to send a laptop, it's important enough to send a person
There will be no problems caused by ad-hoc encryption and lock-in
If there are (other) problems he'll be able to solve them
No problems with the client copying the software or hardware
Your guy will learn a lot from the client about what the client expects and needs
If your hardware and software are not GA quality I expect your documentation isn't either
Above all you avoid the situation where your prospective client finds himself with a laptop he cannot use for some reason, and decides your product is not good

But do write up an NDA agreement too, of course.


Average user reaction to SSL certificate error pages

I would add this as a comment if I had the rep but the typical user reaction would be to click through. Your average user has no clue about SSL. As a side note, at my place of employment, our ERP throws an error message due to an unverfiable certificate. The solution to this problem (according to the help desk) is to click through it.  I assume most users would take the same course of action on their home computer.


The answer provided in the linked comment isn't very thorough, so here's a better explanation.

IPsec is used by itself (sometimes referred to as bare IPsec) all the time; it is commonly used to create a secure transport link between two machines, or to create a tunnel between to different networks / POPs; the former is used (as mentioned) between two machines, while the latter is used to connect disparate networks together, especially when the networks are in RFC1918 space. However IPsec is a very flexible standard (especially v1 over v2), and doesn't establish much in the way of rigid requirements for getting the two endpoints talking to each other. In the situations above, this isn't much of a problem; you simply define all the parameters between the endpoints manually (encryption algorithms, hashing methods, network declarations, as well as upper level routing protocols).

That's all fine and good, but what happens when you want to use IPsec in a road warrior scenario? Let's say you have an employee who wants to connect to the internal network but is traveling, and you want to use IPsec. Do you have him manually configure those things all the time? Is he/she even capable of identifying what network he's on if he's using something like a public wifi gateway? Do you expect him to set up addressing and routing protocols every time he connects?

Of course not. That's what the IPsec + L2TP standard is for. This builds on bare L2TP (also a pretty barebones defined protocol) and automates all of that: it establishes hashing and encryption standards as well as defines a way to leverage PPP over L2TP to do the actual network and routing bootstrapping so that all a person has to do is enter their credentials and hit "connect" (you did know PPP was involved, right?).  Think of IPsec + L2TP as something comparable to PPTP, except it's not considered insecure.

A little more in depth to visualize better: think of the end user being a person dialing into an old ISP. L2TP is the phone line / layer 1 / physical connection, as it allows layer 2 protocols to operate on it. When you dial the modem (connect to the endpoint), PPP is the protocol that runs on that link to authenticate you, get you an IP address, as well as routing and DNS resolving information. You're now online. IPsec + L2TP is exactly the same, except instead of a phone line, you're creating a virtual circuit across the internet (L2TP), and to keep it secure, you're encrypting that circuit with IPsec. This encrypting part happens first, before the L2TP connection is made, but everything from that point on is exactly the dialup analogy.

To go even more in depth: why use L2TP just to get PPP? Why not just run ethernet frames instead of PPP on top of IPsec to use traditional things like DHCP / OSPF? Actually you can: bare IPsec is designed to offer full layer 3 connectivity except for multicast / broadcast; so in the case of DHCP and OSPF, you'd probably swap out L2TP for GRE. Why isn't GRE used for mobile users? Because it doesn't offer authentication, while the IPsec + L2TP standard does (don't ask why we picked L2TP over GRE for the standard). PPP fits better for that scenario, although GRE over IPsec is used in other situations. And if you don't need ethernet framing at all – just doing things like standard applications (web browsing, etc) or utilizing BGP – you don't need any layer on top of bare IPsec.

So in short, you usually use bare IPsec when you have static configurations between two endpoints. You use IPsec + L2TP for dynamic (mobile) end users who have little control over their environment.


Are eavesdropping attacks possible on Ledger Nano S hardware wallets?

Properly implemented hardware wallets perform all operations with the private key on the wallet itself, and not in the PC connected to the wallet.  Only the inputs and outputs to the signing operations are sent over the USB connection, never the private key itself.

The user uses their application to specify that they want to make a transaction.
The (hardware-aware) application generates a transaction that is not yet signed with the private key, then sends it to the hardware wallet to be signed over USB.
The hardware wallet signs the transaction, using the private key kept in a secure element, and returns the signature over USB.
The application uploads the signed transaction to the pool to be included in the blockchain, finalizing the transaction.

In most hardware wallets (e.g., TREZOR and Ledger), there is a step between 2 and 3.  These wallets require the user to confirm the transaction using an interface on the wallet itself.  This is to protect against malware forging requests to the wallet to spend money (which could occur without the user noticing).

These concepts are not new to hardware wallets for cryptocurrency: many smartcard based systems have used these for years, such as the OpenPGP card for performing GnuPG-based operations.


BlackBerry client authenticating to Java Web Service

There is a good explanation of this on the OWASP website, see the page Hashing Java.
It explains some of the details about the use of hashes and why to add a salt, it also contain code examples. This may be a good point for you to start from.

As for securing sending the passwords from the app using HTTPS instead of HTTP if your not already would be a good start.


How can I determine (as a layman) if an E-mail was set to self destruct?

Emails, sent through SMTP, have no way of "self-destructing" internally built in to them. They're basically just text files that hang around for eternity until all copies are manually deleted. The fact that you still have the email's headers is proof enough; if messages could self-destruct, their entry would be entirely removed from your mail client, as if they never existed.

However, there is a way to destroy the body of an email: simply have the email point to an external inline image, then later delete the image. In short, the body of your email might look like this (HTML sourced):

<img src="http://www.example.com/message-images/012345.jpg" />

Thus, when you first open the email, your client displays the image, which appears to be just plain text to a layman. The only obvious hint that it is not text would be that you can't "copy and paste" it, but it'd still be printable, etc. Some clients will warn you about inline images, because that itself is a security risk (at minimum, you can presume that the author now knows you've opened or scanned the email).

Finally, the author simply needs to delete the original image file. Once deleted, clients would probably display nothing or perhaps a "broken image" icon. Alternatively, they could switch the image out for a 1x1 transparent pixel, which would render as... nothing.

You could, however, view the source of the email (see your client's help documentation on how to do this), then find the image link, as described above. From there, you might do a Google search; if it's cached by Google, you might be able to recover the source from there. Of course, if the image was hosted without a domain name (e.g. stored by IP address), you might be entirely out of luck.


I believe this is mostly due to the fact that SSL was never a considered an internet standard.

This quote is from the SSL 3.0 RFC.

  Although the SSL 3.0 protocol is a widely implemented protocol, a
     pioneer in secure communications protocols, and the basis for
     Transport Layer Security (TLS), it was never formally published by
     the IETF, except in several expired Internet-Drafts.  This allowed no
     easy referencing to the protocol.

When TLS was accepted as an internet standard, the people in charge probably wanted a new term to distinguish it from the older, "non-standard" SSL protocol.


I thought blind SQLi was needed when you don't see (error) output from your target, and you can only use fase/right/slow/fast to see if your query is true or works.

Correct, in a blind SQL injection you can only evaluate if the result of a query is true or false.

So, how would you fetch a value from the database if you can only ask yes/no questions?

You would surely ask for each letter separately. But that would still be at least 62 possibilities (assuming a-zA-Z0-9) per character. Therefore, the idea presented in the tutorial is to ask for each bit individually. This way you need exactly 8 queries per byte to determine its value. So all you do is transform the value you want to read into binary and successively ask for every bit if it's 1.

Say, you want to retrieve the value "secret". So you start by extracting the first character:

substring('secret',1,1) -> 's'

Then you get its ASCII value:

ascii('s') -> 115

Now you apply a bitwise "and" (&) to isolate the value of the first bit:

115 & 1 -> 1

  1110011
& 0000001
---------
  0000001

The result is 1 which makes the statement true.

If you apply this method for every bit of every character of the value you want to read, you'll eventually get the entire string by just evaluating if your queries are true or false.


Are there any IoT Systematic Creation Security Checklists?

A note about the wording of the question. You've asked about IoT but this is more of a concept than a "thing". IoT might cover many subjects from industrial controls to smart cities with home automation in between.

However, the following may be of help.

The Cloud Security Alliance's "Future Proofing The Connected World" report
NIST's "Network of Things" report
The EU's emerging IoT policy
Robert Silvers, the Assistant Secretary for Cyber Policy at the U.S. Department of Homeland Security has some useful things to say.
A presentation from an ENISA workshop at least highlights some of the EU thinking that is happening
The UK Government have a competition running for research
There is an IoT Security Foundation which has some white papers at least
You might also check out the Common Criteria "Evaluated Assurance Levels". There is an overview with respect to embedded devices here.
Some recommendations on Securing Industrial Embedded Devices may be useful.

The approaches should, of course, mirror any other security driven approach. Though we have some added twists for IoT:

Embedded devices may not have sufficient power to maintain standard security protocols as they can't always cope with the encryption overheads.
Embedded devices may be difficult to upgrade making it hard or sometimes impossible to fix security issues discovered after deployment.

One area where I'm trying to make a difference is to try and get standard contracts changed to require vendors to ensure that devices can be upgraded after deployment to keep them current and to fix security issues. So we shouldn't assume that issues and fixes always have to be technical.

Just a note about this answer. Because of the question, the answer is inevitably a set of links to other information - normally frowned upon in Stack. It is likely that these links will drift over time which is why I've tried to give the titles where possible so they can be searched for.


Will SIM‐like PIN on website as second password increase security

This would help prevent credential stuffing, but would only catch a couple edge cases and is not as effective as adding a 2nd authentication factor. The specific attack vector this would protect against:

A user uses the same password on your site and another site
The other site, like most, doesn't use a PIN to supplement authentication
The other site gets breached and leaks the user's password
An attacker uses the breach to attempt to log in to your site as that user
The attacker doesn't know your user's PIN, and ultimately can't log in

The biggest issue here is that 2fa covers this exact case, as well as significantly improving the security of your auth flow. There are a couple mobile applications that use a PIN in lieu of a password, as it's easier to type on a phone, but this doesn't seem to be applicable to your question.

There's no reason to use a PIN in addition to your auth flow - either just use a password field, or enable/require 2fa for your users.


Can a badly configured AppArmor profile reduce security?

You are asking, whether maliciously or very badly written AppArmor profile can reduce security. Considering this question already states, that you can indeed reduce security using restrictive MAC, using restrictive AppArmor can obviously also decrease security in all the same ways, possible in some additional new ways as well. So YES, it indeed can decrease security.

As for giving processes additional permissions, I am reasonably certain it can't. Unix permissions (DAC) are checked separately before MAC, so it should be impossible to override them.


VyprVPN (from GlodenFrog.com) weirdly keeps sending unauthorized suspecious data even after uninstall

Hi I'm the developer who wrote VyprVPN for Mac. It looks like you've still got one of our software components installed. Macintosh applications that needs to alter your system, including VyprVPN, uses something called a "privileged helper tool” aka a system daemon.  We install a helper tool with the user's permission, using the appropriate Apple API for this purpose, that runs in the background and does things like setup the VPN, manage kill switch rules, etc. This is the component that is performing the operations you are seeing.

In recent versions of our software, we include an Uninstaller on the .dmg. Mount the .dmg and scroll down and you'll find an app called "Uninstall VyprVPN.app". Run that. It will remove the privileged helper tool.


Where does a Hyper-V guest get its entropy when generating a certificate authority key pair?

A Hyper-V guest gets its entropy just like it would if it wasn't a guest. For Windows, an application that uses Microsoft's cryptographic service providers get its entropy from three/four main sources:

External events like network activity.
Details about the callers to the CSP functions (process ID, thread ID, various timers associated with those threads and processes, etc.).
Any entropy the application developer would like to provide (key press timings, mouse movement, etc.).
Any supported hardware entropy devices, such as RdRand in Intel processors.

All four of the above are just as available to a guest as they would be if it were a physical server.

As described in msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx:

  With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. This allows numerous processes to contribute to a system-wide seed. CryptoAPI stores an intermediate random seed with every user. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). In Windows Vista with Service Pack 1 (SP1) and later, an implementation of the AES counter-mode based PRNG specified in NIST Special Publication 800-90 is used. In Windows Vista, Windows Storage Server 2003, and Windows XP, the PRNG specified in Federal Information Processing Standard (FIPS) 186-2 is used. If an application has access to a good random source, it can fill the pbBuffer buffer with some random data before calling CryptGenRandom. The CSP then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the pbBuffer buffer before calling CryptGenRandom.


Is hardware approved for classified government use more secure?

Government (at least the USG) uses different approaches to hardware and software. For example FIPS: "FIPS is a U.S. government computer security standard used to accredit cryptographic modules" EAL: "Evaluation Assurance Level (EAL1 through EAL7) of an IT product or system is a numerical grade assigned following the completion of a Common Criteria security evaluation, ... The EAL level does not measure the security of the system itself, it simply states at what level the system was tested." and other standards. Since you're looking for hardware, I would research FIPS Accredited, and or EAL (vendor search here)


Should I use a Firefox master password or NTFS encrypt my profile?

You're protecting two different things. NTFS only provides storage protection. The Firefox master password provides protection in terms of storage, and up to the point of use.

Once in use, your filesystem will be decrypted for any application you're running. In contrast, the FF-based encryption will give access to your private key only to FF when it's running. Provided that the memory used by distinct applications is properly isolated by the OS, other applications won't have access to it.

If your machine is compromised with a keylogger or something similar, neither approaches help much, but the FF master password should at least protect your from "semi-trustable" applications: those that don't take control of your system, but can at least read what they like on your filesystem, while you're logged on. Of course, this depends on which applications your run.

In addition, assuming that you leave your seat without locking your machine, while another user could make use of that certificate and private key here and there if you've also left FF running, they wouldn't be able to export a copy of it without having to enter your master password when exporting (even if you've already typed in your master password for FF to use, it's a different thing), whereas they could easily copy/export these files when there's no master password.


VirtualBox setup - running potential virus

In general VM environment is a sandbox (isolated environment). However, it comes with caveats. If your VM is connected to the local network, the Virus or Malware can use it as an attack vector to infect other hosts on the network. So you should consider disconnecting your VM from any type of network and or virtual interfaces. Another factor worth considering is that escaping sandbox is difficult but not impossible so depending on the type of Virus/Malware it may affect the host machine and other connected devices utilizing vulnerabilities of the sandbox environment.
I would advise using a separate dedicated offline machine for running the sandboxed environment, a machine that you can reformat after finished testing, preferably something with capabilites for flashing the BIOS to avoid any surprises.


Android devices with locked bootloaders and production mode ROMs have none such capabilities. Your first proposal of cloning the checksum would not work as the code signing identity is verified by the device before flashing or booting when the bootloader is locked. This is done in an effort to harden the devices against attackers and is an important part of any consumer product.

Depending on your device's firmware, there may be publicly known exploits which can gain you root however you'd have to craft the payloads yourself.


Are passwords comprised of key sequences on a keyboard any less secure than the same characters but jumbled up?

Yes! Especially when faced with draconian password complexity requirements, users frequently choose passwords like the first one: keyboard progressions, keyboard walks, keyboard patterns, or whatever you like to call them. And attackers are well aware of this.

Whether conducting an online (brute forcing) or offline (hash cracking) attack, an attacker knows that the most profitable method is usually some variant of a dictionary attack: using a collection of common passwords and trying them. Pretty much every dictionary built using passwords collected from real data breaches contains at least a few variants on the keyboard-pattern method, most commonly "1qaz2wsx" and friends.

Beyond the static dictionary method, the mental algorithms people use to create these passwords are quite simple, and there are lots of programs that generate these passwords rapidly in order to try them all.

From an information-theoretic standpoint, the second password has more entropy, since each character is a random choice from a set of 16 characters. Knowing that they come from a small grouping reduces the entropy somewhat, but it still remains fairly good. The first password, on the other hand, is much simpler. You can think of entropy as "how hard would it be to explain how to type my password?" Here's how I might try to explain your first one:

  On a US-standard keyboard, start at "5":

  Type 4 keys to the right, then return to your starting position.
  Hold "shift" and repeat step 1. Release "shift."
  Move down a row and repeat steps 1 and 2.

Compare that to your second password, which would have to have a procedural step for each character of input. There's no good way to compress it, so it has lots of entropy. Even if I know which 8 keys you've chosen, and that each of them is pressed once with shift and once without, that still leaves (assuming totally random choosing) 16! ~= 2^44 choices, meaning about 44 bits of entropy, which strangely enough is the same amount claimed by the "correct horse battery staple" method.


How can I (preferably metaphorically) explain DNSSEC without technical jargon?

Regular DNS responses are like business cards - while you can generally trust them when someone hands theirs to you, they're actually just ink and card stock, and anyone who is even a little motivated can get their own made by a print shop.  And there's no way to enforce their validity; I can go to (for example) VistaPrint and they'll ship my "He-Man, Master of the Universe" cards right to me.

DNSSEC DNS responses are like drivers licenses.  They've got a picture.  They've got a mag strip with a copy of the information.  They've got holographs that are difficult to forge.  They've got layers printed in special ink that only show up under ultraviolet light.  In short, a number of technical measures have been taken to make them hard to forge.

When authentic data is important, DNSSEC/licenses are preferred.  Just as the Post Office requires a license and not a business card for identification, so your business might require DNSSEC data for use in connecting to your bank.


Your question is really broad. I can tell you about how I did in one instance, for fun, in a small arcade game several years ago. This should make you gain some educational insight, but won't help you much otherwise, I'm afraid.

I simply had another program running in background, scoping the memory of the arcade game.

I started playing, and then I lost one life. Hit both shift keys -- and a snapshot of the memory was saved to disk unbeknownst to the running arcade. Then another. BAM another snapshot. A third, and a fourth. And then game over and I exited the arcade game.

Then I just compared the snapshots, looking for a memory location that changed from one snapshot to the next, either increasing or decreasing by exactly one. I remember finding some twenty of them. I could have checked all of them, but I spotted immediately that one among them, and only one, had value "five" at the start of the game, and became "four" on my first death. And I had started with five ships. Now that's interesting...

So I wrote a small program that would look for that memory address, recognizing it by its distance from other pieces of code and strings that didn't change, checking its value every few seconds, and just poking back "5" into it as soon as it became anything less:

: install
    look for string 'COPYRIGHT ACME GAMES'
    add 1138
    is it a five?
    no, abort, something went wrong
    yes. lie in wait.
: wait
    is it still a five?
    no. Set it to five.
    sleep for a couple of seconds
    goto wait

Sure enough, the next game, I died - and an instant later, my four remaining starships became five again. For the heck of it, I discovered that I could get up to seven 'lives' with this method (eight crashed the game).

By using a "debugger" it would also have been possible to stop the program as soon as the location was modified, thereby seeing which instruction had done the deed. Then you would just blot out that one instruction from the assembler code. Or you could follow the program flow in reverse, and discover where, for example, the collision check was made between your player's sprite and the enemy missiles'. Thwart that check, and the enemy missiles no longer affect you (possibly, also yours no longers affect them; it's a tricky business).

I expect the techniques to have matured and progressed a great deal in these years, but I'm confident that basically the idea is still the same - spot the change you don't like, then either defang the code causing it, or patch the code so that the damage is undone as soon as it happens.

To make things more difficult one could devise strategies to make the changes stand out less, or make them seemingly random. Add "chaff" or "dummy" variables that change just as if they were useful. Use them as telltales - if all variables don't tally, it means that someone is trying to hack.

In the end, however, you can't beat a determined and experienced hacker. All you can do is try making the deed not worth his while. There are code obfuscators, code protectors, code encryptors, debugger detectors, anti-virtualization techniques...


Securely store password for Java Keystore

This is a recurring problem in app security: even if you store your secrets in a protected datastore, you have to authenticate to that, which means you've got another secret to manage, which puts you back at the original problem. Unfortunately, there's no cut-and-dry canonical solution.

The best you can do is to try to minimize risk by introducing different types of systems that are a bit harder to falsify. Are you using physical servers (presumably with some sort of virtualization layer on top)? You might store the encryption key on a smartcard or similar physical device that's plugged in to the machines, and lock down the software access to it to only the user responsible for scaling the app. Are you using AWS? You can take advantage of Amazon's machine-based roles, and lock down which IAM users are allowed to launch machines with those roles. Maybe you have a manual step when deploying new code that adds a private key and then bakes a virtual machine image, and you heavily restrict which users can access those baked images. None of these solutions are perfect, but they help limit the entry points into the secure data.


how to write a snort rule to alert traffic that does not find any matched rules

I'm sorry, but Snort is not really designed for that.  It sounds like you're wanting something more like a firewall.

Snort is an Intrusion Detection System, whose job is to highlight on suspicious or malicious traffic that it observes in order to inform those who monitor the network to, "Look over here!"  Alerting on every single piece of traffic that passes by is pretty much the opposite of what Snort is supposed to do.

There are other solutions that would be better suited for what you're asking.

If you're looking for metadata only, a firewall with the ability to log would be perfect.  You can simply put an "allow any -> any log" rule at the bottom and then you'll have a log file with all of the metadata for each connection.
If you're wanting to capture the actual traffic that is observed regardless of whether it fires a rule or not, you'd probably want to set up a packet capture utility with the ability to rotate log files.  Many homegrown security devices are built this way so that security researchers can examine traffic that their IDS may have missed.  For high bandwidth connections, people use something like netsniff-ng.  If you're looking for something that not only captures the traffic but also gives you an interface to use to examine and download pcap, check out http://molo.ch/ which is free.


Do VB Macro viruses (ie macros in Microsoft office documents) affect modern Linux systems?

Microsoft Office macros and OpenOffice macros are not compatible, you would need to rewrite a Microsoft Office macro for it to run in OpenOffice.

Also, macros in OpenOffice 3 are disabled by default.


I assume this question is about a short leave. In this case it might not be suitable to wipe the complete machine.

Dependent on the trust into you IT department, the following points may be good ideas:

Browser caches, stored passwords, forms, ...
Media Player caches
Password Manager
private files, including recycle bin. Of cause this does not wipe the data from HD,but makes it inconvenient to find.
all other programs you use probably store information ... you will never get them all if you do it manually.
unplug the SD card which is in the SD card reader and you always forget about :)

Actually, in most cases the IT department does not care. But you never know what a bored person might do with your computer. Moreover, probably the IT department is able to access the data on your computer at any time remotely.

For Windows 7 this question was already asked:
https://superuser.com/questions/165710/clear-all-personal-data-in-windows-7

In Windows 10 there is also an out of the box soltuion.  Goto
Start > Settings > Update & security > Recovery
 taken from here:
https://home.bt.com/tech-gadgets/computing/windows-10/how-to-wipe-your-pc-with-windows-10-11364002707321

Please feel free to edit the list.


Does compromise of one cPanel / WHM account on a server mean the other accounts are at risk?

Allow me to start off by saying that setting up a secure WHM & cPanel environment is a very difficult task. There are many source of information on that topic, such as:

10 Tips for making your cPanel and WHM servers
WHM Recommended Security Settings Checklists
How To: WHM Server Hardening And Security Basics

As for your question itself. WHM creates separate cPanel accounts with the aid of the Operating System's access control and permissions; each user has their own directory and they're given access to only what's theirs, so a compromised account shouldn't normally be a problem. But if all of your accounts exist on the same dedicated server, it means that an attacker could exploit a privilege escalation vulnerability to gain access to your root account. From there, it's Game Over. All of the other accounts and even your WHM control panel will be compromised.
Another possibility is a vulnerability in the WHM software itself.

The reality of the situation is somewhat different. Yes, there is a possibility, but the likelihood is very low. WHM is widely used by hosting retailers and we don't hear a lot about major attacks on it.

Conclusion: If you follow the recommended security practices, you've shaved the vast majority of the danger.


Why is it recommended to use GCP service accounts vs user accounts?

There are two primary authentication methods in Google Cloud: User Credentials and Service Account Credentials. I am ignoring API keys, etc.

The reason that Google recommends using service accounts (where applicable) instead of user accounts is the processing for user accounts is much more intense for Google. The process takes longer, there are more security checks, etc. There is an API limit on how many times you can authenticate with user credentials in a certain period of time. The exact numbers are not published.

Service Accounts contain all the components necessary to authenticate with Google Cloud and require fewer interactions to generate OAuth tokens.

Service Account JSON key files are assumed to start in a secure environment. User Credentials are assumed to start in an insecure environment.

Service account credentials are typically used for service-to-service, installed software, etc authentication/authorization that may happen over and over again.

If you are using the same service account for each user, then yes, you lose a piece of the audit trail. However, you should not be distributing one service account JSON key with the application. You should issue a different service account to each user. Your example then becomes john-smith@myproject.iam.gserviceaccount.com. The user should protect the service account credentials in the same manner that he would protect his email credentials.


Can you get someone's IP if you have their Skype number?

Skype is a modified P2P network.
 You have no guarantee that your traffic is going to them, so a sniffer wouldn't work the way you'd expect. However, you can resolve the person's username to their ip address with a tool like this while they are online. So if you can get their username from the Skype number, or the email address associated with the number (to then get the skype username), you'd be able to resolve it to an ip address.


How do I prevent my Rails application from attack?

I have not looked into your code, but the things I would do are:

checking the eligibility of the user to do anything on your website before making that user makes an action. (If somebody posting something without even registering in the site - it is no good).
to prevent from the new signup the common practice is to confirm yourself using a mail account or an account from high profile resources google acount, fb account.


Getting an alert box in JS without using alert()

Try with a fresh copy of window:

document
.body
.appendChild(document.createElement("iframe"))
.contentWindow
.alert("XSS");

you can cleanup/hide the iframe as needed, it doesn't have to navigate, it just has to exist to expose its global window methods. Think of it as a web worker with more built-ins. Note that even though chrome46+ block alerts from iframes, you're not calling it from the iframe technically, so it's allowed. This is also a decent way to avoid re-writes/fork to run a process that conflicts with pre-existing code which doesn't need the document's content to function, but needs DOM tools that Worker doesn't provide, like alert.


Benefits of home router behind Linux firewall?

After reading a bit into the documentation this seems like a nice bit of additional security for a home network. You have a basic firewall package with basic networking features. In your case it is free, and can be a nice side project. Some things you will want to configure:

Firewall rules

Make sure you actually configure firewall rules to fit your situation. There are plenty of guides, take your pick.

NetFlow

I notice that iftop and bandwithd are both available packages to install. I would recommend these. If you notice you're home network is sending out tons of data at 3 am, there may be a problem. These tools can help you identify those issues.

IPS/IDS

Snort and Suricata are also both available packages. I'd recommend picking one and installing a simple interface to view alerts (snorby is simple, and nice).

If you have the time, and inclination these steps will be good first steps towards securing your home network. Have fun.


If you enter your credit card data on a website then yes, the website can see your credit card data.

If the website redirects you to PayPal, and then you enter your credit card data on PayPal, only PayPal sees your credit card data and not the original website.


How do I securely store passwords in my database?

If you don't need to know the password but just check, whether or not the user has entered it correctly, store the password as a SHA1-Checksum of the password string (The checksum is obfuscated and cannot be deencrypted by anyone - but if you enter the same string, you'll always get the same checksum). Then, when the user enters the password, just generate the checksum of the entered string and compare it to the one in the database. This is also a common implementation for most online accounts


With CSRF the attacker is able to control a request sent to another site. But the attacker is unable to read the response. Since your API is purely informative and does not cause any changes to the server the cross site request is still possible but will not cause any permanent problems.

But depending on the abilities of your API it might still be possible that the attacker is able to trigger a high resource usage at the server  by using unexpected parameters for the request. This might result in a denial of service for the proper users of the API. Thus it might still be worth to detect and block CSRF requests.

Also, even though CSRF itself is not possible other attacks like DNS rebinding or Cross Site Scripting might still be possible. Contrary to CSRF these attacks then have also access to the response data.


how to make software reverse engineering difficult

Here's an example in x86 assembly:

MOV AX, 4Ch
MOV [someaddr], AX
MOV AH, 30h
INT 21
CMP AL, 5

This will take advantage of the instruction pipelining of the processor and the failure of debuggers (as they single step through the code) and can as well be an example of an anti-debug measure.
This is so because int 21(DOS interrupt) along with an 30h in AH will return the dos version of the platform. However the first two lines have been so crafted that [someaddr] will become 4Ch (someaddr has been so chosen such that it contains the address where 30h  has been stored). Thus, 4Ch in AH followed by int 21 will terminate the program (interrupt thingy!).
Without the influence of a debugger this won't  be a problem as the third line will be prefetched and the first two lines will have no effect. But debuggers will be broken as they single step the code and AH will now contain 4Ch which will of course terminate the program.
You asked for the higher level version of it. For that you will want to know how gcc (or any other compiler toolchain) converts C to asm code and then decompile the above code.
http://www.programmingforums.org/thread4484.html

But some really cool guys came up with a solution and actually wrote a countermeasure (debugging a loop which has been software-pipelined): read Non-transparent debugging for software-pipelined loops by Hugo Venturini, Frederic Riss, Jean-Claude Fernandez and Miguel Santana.

Another solution to it would be to make the debugger aware of the pipelining.(drop a mail to Oleh!)


How do I store other people's ssh keys securely?

The only key here that seems reasonably sensitive is the priv/pub key pair that you generate for each server that needs Github access.

The rest of the keys you mentioned are public keys. I'm not saying you should publish them and make them public, but they are public keys and don't need to be stored particularly safely.

Also, since the private key that's generated is being stored on the server only, it's going to be as secure as that lone system. Here you have a few things to consider:

Keep each system as secure as possible.
Make sure that if a single key is compromised, its access is already restricted and easy to revoke.


How should I defend against TightVNC brute-force attacks?

Since you're only accessing VNC over a SSH tunnel, just close the VNC port at the firewall and drop every connection attempt coming from outside.


Can I use 3 same subkeys to 2 different GPG Smartcards?

Yes, this should work as you described.

To test, try using the cards to decrypt files encrypted to your public key, use them to sign files and see if you can verify them using your pub etc.

In my limited experience the biggest issue with using the same keys on backup cards is that the system looks for the keys on a specific card, regardless of whether there's a copy of them on the currently-inserted smartcard. When I had that issue deleting my gpg directory (already backed up elsewhere) and running gpg --card-status cleared it up.


What is the relationship between cookies and anonymity?

First, you don't get complete anonymity just by using a VPN in the first place. A VPN will only reduce the tracking surface but not remove it. Similar removing cookies will only reduce the tracking surface further but not remove it too. There are still enough cached information in the browser outside of cookies and these can be used to track you. Removing the browser profile completely will remove these traces but it will for example not help against fingerprinting your based on some system properties from within the browser.

In short, removing cookies will help a bit - but only a bit.


Where do I securely store application-specific symmetric key?

This is the magical issue of DRM and the short answer is that there is no good answer and if you come up with one, you will be very wealthy.  In order for the application to access the key, it has to be able to get to it from an unencrypted state and whatever it can do, a sufficiently advanced user can do too.

You could use a TPM (trusted platform module) or HSM (hardware security module) to store the key as long as the user does not have administrative access on the system, but if they are an admin, then they will likely be able to get the TPM or HSM to give up the key.  It would also be difficult to make sure that only the program is able to get the TPM or HSM to perform operations as the application has no way to authenticate itself to the key store that the user can't fake, but it at least would keep the key itself safe.

So short answer, you are completely out of luck if the users have admin on the box the app will run on.  If you can give them only limited accounts, then there are some options, but they are still not particularly strong unless you lock down the system quite a bit.


Can I prevent XSS attacks with MySQL REPLACE function?

This is a really cack-handed way to attempt protect your application. Never try to transform input like this; it is a very long way from being effective in its objective, it is not maintainable/extensible, it will end up trashing your data.

The golden rule is to validate input and escape output

Check content against a set of rules, reject it and flag a problem for non-compliant data. Whenever data moves from one domain to another (e.g. from PHP or python or PERL to mysql, or from your program to an html stream) then make sure that the representation of the data isolates it from the construct it is being injected into.

There are good libraries for escaping output for a variety of languages and a variety of targets (including SQL and HTML). Start by learning how to use them effectively.


In the Netherlands, is there danger in my name and bank account number being public?

In Europe the common way to send money is by giving the International Bank Account Number and the Bank Identifier Code, so no problems there.

If your name is available, they might find your address if it's publicly available, e.g. on  social networks, blogs... The only risk here, is if they find the email related to your account you can get spear-phishing emails, most of them will end up as spam. And as long as you don't click on anything weird nothing will happen.

As long as they don't have your credentials, the login and password and PIN code, and the two-factor authentication Code (single-use code for online transactions if you're using online services) you are safe.


Why does Google Safe Browsing keep detecting malware on my website?

There are several scenarii you may think about. I am not going to be exhaustive, but I will mention briefly the milestones that can come to my mind:

Your website is effectively clean

Let us suppose your website is clean as you say. So why Google still blacklists it?

There may be several reasons for this situation:

Reason #1

Google effectively did not find anything wrong with your website by now, but it still does not trust you because it can not understand your intentions as you may be someone who wants to attack your website's visitors, so Google needs time to be sure that you are not playing a game over its head by just pretending you are not attacking any body for the moment but as soon as Google whitelists you then you come back to your nefarious habit(s) (This is said, I am not accusing you to attack people through your website, I just say why Google still does not trust you even if your website is innocuous for the moment)

1.1. Solution for Reason #1:

You need to scan more times, and in separate days using Google Webmaster Tools until Google trusts that your change (clean-up) is permanent.
Reason #2

Google believes that you have cleaned-up your website from malicious content but you did not really finish that task as you did not request from it (Google) a malware review.

2.1. Solution for Reason #2:

After you cleaned your website, request a review from Google.
Reason #3

You cleaned infected webpages from their malicious content and you submitted a review request from Google that still does not trust you.

3.1.Solution for Reason #3:

You need to delete those pages, not only their malicious content. Yes, it is a radical solution but the only one that will make Google trust you in this particular case because Google will think you have intention to use those pages to attack your clients and that is why you are keeping them there.

Your website is not as innocuous as you might think

Your domain has served as a bridge to deliver malware

Google says that Over the past 90 days, zeta-uploader.com did not appear to function as an intermediary for the infection of any sites.  But given what discussed above, you are forced not to trust this statement.

1.1. Why Google did not detect my domain as being a malicious intermediary one?

Several reasons are there to explain why Google failed to detect that:

attackers obfuscate links in your webpages to domains that attack using drive-by download attacks (which is reported by Google concerning your website).
an other reason is that Google detected the obfuscated link but can not follow and determine the malicious chain of intermediary domains
Google found the obfuscated link to the malicious domain but the attacker replaces such links frequently to new ones that may be are difficult for Google to detect so it can not be sure what decision to take

1.2. What to do then?

I do not have much ideas for this situation apart from searching for such links manually yourself or, if it is possible, to hash your webpages and develop files/directories modification notifications.
What is the situation about my real case now?

It is not that good. Under the section What happened when Google visited this site?, Google says you have:
 Malicious software includes 96 trojan(s), 14 exploit(s), 5 backdoor(s). and that 3 page(s) resulted in malicious software being downloaded and installed without user consent (drive-by download attacks).

Only backdoors can explain what really happened to your website.

What's the solution then?

This is too broad to answer because you are the owner of the website, you know its security architecture, so you are the only one who can assess that and take decisions depending on different scenarii/discoveries you may encounter. You may start by checking this: Google Webmasters help for hacked sites and see which method to use to discover, remove and mitigate backdoors on your domain... do not forget to review your scripts related to file upload ...

Good luck.

P.S.

The question you linked to, I asked it a year ago when I was developing a software for the sake of a web vulnerability scanner to detect drive-by download attacks and malicious contents on websites.


Has Linux Mint updated the OpenSSL library for LMDE (Heartbleed bug)?

I am running LMDE as a workstation and I am afraid as of now (Wed Apr  9 11:28:14 UTC 2014) no patch has been released yet. All available patches have been applied by me and right now # openssl version -a shows OpenSSL 1.0.1e 11 Feb 2013.

You might want to consider changing your sources to point to Debian repos directly in order to get the update. I'll be doing this soon.

Just as a side note, LMDE is a desktop- rather than server-targeted distro. If you wish to be secure you should rather stick to Debian stable.

EDIT
If you wish to update the package please follow the steps:

Edit your /etc/apt/sources.list file, comment out whatever you have there and add the following line: deb http://ftp.us.debian.org/debian testing main contrib non-free (Note: you might just as well do this with apt-pinning but this way it's easier to go back to LMDE repos right after the update)
aptitude update
aptitude install openssl libssl1.0.0 to update the packages
aptitude show openssl to verify you have 1.0.1g-1 version (see here for explanation of version number)
Edit your /etc/apt/sources.list again, uncomment what you previously had there and comment out the deb http://ftp.us.debian.org/debian testing main contrib non-free line.
aptitude update and you're good to go :)


Why is DKIM configuration testing not working the same for every test site?

It looks like that you did not specify any DKIM selector on the second test site. And if the one you use for your site is not one of the several the test site tried then it will fail to check for a DKIM DNS record.

Apart from that the second test site seems to have more strict and non-standard requirements than the first site. While it successfully validated a domain I own with a non-standard DKIM selector it failed to verify DKIM setup on gmail.com with the current selector 20161025. The reason might be that my DKIM DNS record included the recommended (but not required) v=DKIM1 at the beginning while the record for gmail.com did not.