Program getting exploited inside gdb, new shell is spawned but terminated immediately

This may be a little late but GDB stays attached to the parent process when a program forks by default. To make GDB follow the forking process add set follow-fork-mode child to your .gdbinit. GDB will then follow the shell process that is spawned when your exploit lands. More information about gdb and forking processes is available at https://sourceware.org/gdb/onlinedocs/gdb/Forks.html.


Does a chain of proxies (e.g. one connecting to another and another and so on) make tracing the original IP harder/impossible?

The way an investigator would trace a multi-hop connection to the original source is to follow each hop, and examine either the logs (if the connection is closed) or the network state (if the connection is ongoing) to see where the next hop goes. This can get very difficult if the hops cross political or jurisdictional borders, since the cooperation of multiple authorities may be necessary (and they may not want to cooperate), and more difficult still if the hops involve organizations which do poor security and logkeeping. Depending on the resources of the investigator, tracing such a connection can range from annoying to difficult to simply impossible.

As an alternative, the investigator may look for information leakage through other channels; perhaps the same username or cookie shows up under a different IP, for example.

If the cryptography is done correctly, then it is impossible to tell a file's contents just by the encrypted container, which is the point to cryptography. But to convict a suspect, the authorities need only to convince a panel of jurors that a law has been broken, or in certain cases simply that it was the defendant's intent, which means that decrypting the file may not be necessary. If the corresponding forum post says that the file contains an encrypted copy of X, that may be enough.


It is not troublesome, removing these "links" have been done for a very long time, even when disk space was expensive.  Since CPU cycles were also expensive, there was no point in securely "overwriting" (like shred) data.  If you remove the logical file table entries, the space it addressed as empty and was just overwritten.

Alas, it is not "troublesome", to remove data - it is just wasted time / CPU cycles, and then we're not talking about the ability to recover this data.

Companies such as facebook store their data over several media, not just a hard drive.  First off, it is located in multiple servers from an availability / performance point of view, and is backed up several times.   Plus, their Terms of Service stipulates that it is still somehow accessible and could be "used" (though within limits) even after your account is removed.


Skill testing question in registration page

Bots are usually made generic.
There is no bot to register specifically at Celeritas.domain and post spam.
There is a bot to register at any generic Wordpress/xForum/yCMS site and post spam.

It is very hard to generically write a bot that can answer "What is one plus -2", "What color is a Firetruck?", "What is the name of this Blog?" and whatever else such registration questions can be.
Posting spam on a single website is (currently) not valuable enough for this Spammers to pay humans to solve this things.

If there is a new Captcha system used at many domains, it is worth the effort to implement that. For a single site, the effort just isn't worth it, it seems, even if the effort is very low.


How can I identify that my page is requested by robot, but not user's browser?

Javascript detection seems to be the common way to detect a bot, by having a random token generated using Javascript and being sent along with requests.

I like the idea of having a 'honeypot' page on your web application. This page would be linked to using a hidden link, which no end user would ever see. This way if this honeypot page is ever reached (by a bot scanning the HTML source for links), you can be pretty confident that this is a bot or other malicious scanner and temporarily block that IP address.

There are also tools out there (such as weblabyrinth) which aim to trap bots in a loop by dynamically generating bogus links for the bot to follow.


How do I audit the effect of security policy on a computer?

Windows Group Policies control many different aspects of a running machine. I'm not sure there could be a single way to test the breadth of what a policy could cover.

My approach is to define a test for each policy component (that can be tested) and use whatever tool is appropriate to execute that test. Sometimes that tool can be a script (Powershell, Python, etc.), a packaged tool (Nexpose, metasploit, etc.) or a manual test (click here then there, etc.).

The idea is to treat the security policy like a software development project and to use the concept of "unit testing". Each new "function" needs to be tested for expected behaviour (does it do what I'm asking it to do?) and for unexpected behaviour (what happens when I modify the inputs it controls?). These tests are documented and the results saved. When I make a change to the policy, I re-run the tests and add whatever new tests are appropriate. In this way, I can prove that the policy is effective, and I have evidence for Change Management and Auditors (when applicable). I rest easy knowing that I am not "hoping for the best" when I set a policy.

Having this documented test process also means that when a security incident happens, I can rule out the demonstrated behaviour of the policies and look for ways that the incident occurred despite the successful running of the policy (in other words, I can ask, "if everything worked, how could this have happened?"). Or I know where a policy can fail and I can design mitigating processes to make up for the weaknesses in the policy.

By the way, I use the same process for firewall rules.


What is the difference between a Self-signed root certificate and a root certificate authority

The Root certificate authority contains information about the Country, Location, Email-address, etc. of the origin, while the second contains a Serial number and a version in the Subject and Issuer information. Are these the same things?

No, the properties you listed are not the same. A certificate must have a Subject and Issuer and it may additionally contain a Country, Location and Email-address, etc. What is included in a certificate depends on its type and what the owner wants in it.

  Can there be root certificates that are not self-signed? I thought "Self-signed root certificate" would be a tautology.

Let's take a look.

A self-signed certificate is just that. A certificate signed by the private key, which is the pair of the public key embedded in the certificate. When building a trust chain, this type of certificate can only appear at the root of the chain as it cannot have anything after it (since it is signed by itself). Here comes the twist. The trust chain building will stop when a trusted-root certificate is encountered. This is trusted-root is always self-signed.

However, there exists a special case when a CA who newly enters the field publishes its "root" certificate which is not self-signed, but cross certified by a well established CA, making it an intermediate certificate. This allows the new CA to start operations before its real root certificate is distributed to the browsers and OS trust stores. A great example of this is Let's Encrypt's root certificates. They are cross certified by IdenTrust.

To sum it up, yes self-signed certificates are by definition root certificates, making it a tautology.


Linux whitelist-based Mandatory Access Control instead of a blacklist-based model

I seem to have found what I was looking for - using AppArmor global profiles and profile stacking which can be used to implement a whitelist-like model:
https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorSystemWideRestrictions


What would you define as an "advanced" hacker attempt?

what defines a advanced kind of attack? Advanced for who and how?

Ultimately, an attack is an attack. It doesn't matter if they used social engineering techniques to get an unsuspecting user to divulge their credentials, brute-force methods, obtained a copy of the software and performed reverse engineering or used the system in methods other than intended, or tools to simply bring the system down and render it inoperational for a period of time.

Most attacks take some kind of sophistication and knowledge of the users of the system, how the system works, or where components reside and how to access them. You could say that any successful attack is advanced - it overcame your security measures to prevent attacks. You might also say that any attack that degrades service, even if it doesn't disable the system, is also successful as your current system couldn't withstand it.

  What do you do for "more secure"?

More secure depends on the system being built.

I would recommend reading the work of Gary McGraw. He wrote three books that are especially interesting to people building software. Building Secure Software: How to Avoid Security Problems the Right Way, Exploiting Software: How to Break Code, and Software Security: Building Security In discuss how to build secure software, how to break existing software as well as perform security testing on systems that you are building, and complete software development lifecycle approaches to security. As far as I can tell, these are the canonical books on the subject.

  What do you define as obvous or well-known security flaws?

Things that have been seen before and have been studied are, or at least should be, obvious. That's why there's a great deal of work done to study security, from building secure software to analyzing security incidents to determine how and why they happened, and then producing documentation so that other people don't fall victim to the same problems.

The US Department of Homeland Security's National Cyber Security Division has a Build Security In program about finding and organizing information relevant to people building systems that must be secure. The Open Web Application Security Project also produces documentation and resources about many aspects of software security so that they are easily accessible to people building systems where security is a concern. The MITRE Corporation also does work in finding, identifying, and producing vocabularies to discuss security concerns.


Can anyone provide references for implementing web application self password reset mechanisms properly?

Some suggestions:

Don't reset the user's password until confirmed. Don't immediately reset the user's password.  Only reset it once the user clicks on a confirmation link sent to their pre-registered email address.

Require a CAPTCHA. When a user requests that their password be reset, force them to solve a CAPTCHA before proceeding any further.  This is to prevent automated tools from trying to give many users grief, and force the user to prove they are a human (not a robot).

Randomness. The time-limited password reset URL should include a random, unguessable component.  Make sure you use crypto-quality randomness.  The output from /dev/urandom or System.Security.Cryptography.RNGCryptoServiceProvider would be a good choice.  The output from rand() or random() or System.Random are not random enough and would be a bad choice.  A GUID or timestamp is not random enough and would not be a good choice.

Include a time limit. The reset confirmation link should expire after some reasonable time: say, 24 hours.  The link should be usable only once, and should immediately expire as soon as it is used.

Include explanatory text in the email. You may want to add some explanatory text to the email, to explain why the email was sent, in case someone requests a reset for an account that is not your own.  You could include some text like "Someone has requested that the password be reset for your account username on site.  If you made this request, click here to change your password.  If you did not make this request, click here to cancel the request."

Send email after the password is reset. Once the password is successfully reset, send email to the user to let them know that the password has been changed.  Don't include the new password in that email.

Monitor cancellations. You might consider including some logic to monitor the frequency with which users click the cancellation link indicating that they didn't request a reset.  If this goes above a certain threshold, it might be useful to send an alert to the system operators.  Also, if a cancellation link for some request is visited after the confirmation link is visited, that's a potential indication of an attack against that user -- you may want to take action at that point, e.g., invalidate the user's password and require them to reset their password again.  (This is a defense against the following attack: the attacker gains access to the user's mailbox, then requests that their password on your site be reset, then visits the confirmation link.  If the attacker doesn't delete these emails from the user's inbox, then when the real user reads their email, they may click the cancellation link, giving you an indication of possible trouble.)

Use HTTPS. The link should use https (not http:), to protect against various attacks (e.g., Firesheep attacks on users surfing the web from an Internet cafe).

Log these operations. I suggest logging all such requests.  In addition to logging the user's username, you may want to log the IP address of the client that requested a reset link be emailed to the user, as well as the IP address of the client that visited the reset link.

Additional reading. You may also want to read Troy Hunt's excellent blog post, Everything you ever wanted to know about building a secure password reset feature.  Thanks to @coryT for a link to this resource.

Lastly, consider non-password authentication.  Passwords have many problems as an authentication mechanism, and you might consider other methods of authenticating users, such as storing a secure persistent cookie on their machine with an unguessable secret to authenticate them.  This way, there is no password to forget and no way for the user to be phished, though you do need to provide a way for a user to authorize access from a new machine or a new browser (possibly via email to the user's pre-registered email address).  This survey paper has an excellent survey of many fallback authentication methods and their strengths and weaknesses.


Very broad question, but here is a baseline of security additions I would add

Firewall rules to block ALL except authorized sources
Remote syslog/event logs
Web Application security test

This is beyond broad, and scattered. The reasoning? I have no idea what your risk is. Only you and your organization can determine that. So a quick risk analysis on a 50k view:

Question: "I need to put this server online, what is the risk someone will get my data?"

Answer/Question: Who has access to data (what network and why). Can I minimize this via a certificate, SSL, VPN, ACL?

Answer/Question: Once someone DOES access this site, what permissions do they have? Can they access all data, some data, how does it get processed, can someone attempt to access something they have permission for, if so will I know via logs, alerts?

Answer/Question: Can this be done safely over the Internet? Should I be introducing this risk not only to myself, but to my clients? Can I enable a VPN transaction, with this procedure documented so my clients understand I value their security?

Then there is the more granular problem outside of that server. "What if someone compromises this server, what can they do once on the server. Can they pivot back into the corporate network. Can they pivot unto any network in the routing tables? Can they sniff other client connections and compromise other clients?" This question is rather broad, and I hope I gave you some things to think about. There is no "what framework/standard/guideline" I can think of because 1) I don't know your industry 2) I don't know the purpose of your application 3) I don't know your organization's risk tolerance.


How can changing your DNS protect your online privacy?

Essentially, it doesn't.

DNS servers let your computer look up where websites and other services are based on friendly names, by converting those to IP addresses. Your ISP provides this as a service, but knows precisely who you are, and what IP your computer has, so can easily look up to see that @user1 has made a request to look at google.com.

A third party provider knows what IP address your computer is on (else it couldn't reply to queries), and what sites you are looking for. If they are a free, registration free provider, such as OpenDNS, that's all they know. They can take a pretty good guess at your ISP, and probably your geographical location (since most ISPs assign IPs based on location), but they don't have direct access to your name, or to any other data you send to websites.

However, even when using a third party DNS provider, the actual traffic between you and websites goes over your ISPs network. In this case, they can see that @user1 visited 173.194.113.80 and made some requests. If the site is running over HTTP, they can even see that you requested pages from a specific host, thanks to header data such as Host: google.com in each request, and the specific pages thanks to the HTTP verb used (e.g. GET /search?q=dodgy+things). If the site is running over HTTPS, they just get the IP address, but that's probably enough for them to work out what site you were on, just not the specific pages you looked at.


Possible to use "Blackberry Protect" in conjunction with a BES IT Policy?

It looks like it creates a partition on the device for the end user that doesn't allow you to mix the personal data with business data. A lot of 3rd party companies are doing this.


Secure way to store sensitive API details of users (localStorage or database?)

How about storing the API tokens in a way that not even you can use them?

Encrypt the API tokens with a key derived from the users password. To avoid having to send the password to the server in plain text you could use a hash of it as the key - making sure to use a different salt on the client side to the normal server password storage process. On login the tokens can be pulled from the database and decrypted. If the user forgets their password then the API details can't be recovered from your copies - but that is OK because they can get them and reenter from the exchanges again.

If taking this approach you want to take steps to make sure the tokens are not paged out on your server. There is little point going to this much effort to then have them written to disk anyway. You also need to ensure they are flushed from memory on log out.

Another alternative would be to derive and use the keys / API tokens on the clients machine - this way you never have access to them in plaintext. This assumes the Exchange APIs have CORS policies which allow your application to call them from the clients machine. An example of key derivation / use using the WebCrypto API (More complete code here - https://pastebin.com/XzrarRha)-

var _algorithm = "AES-CBC";
var _key_size = 256;
var _pbkdf_iterations = 100;

// Do not change this once used in production
// If copying from StackExchange replace with a new random value for your app
// or pass in a user specific value from the DB
var _defaultSalt = "af95a2b25229d227269a54fdec562d93";

// Derives a key from the given password.
// Salt is not required. If supplied should be a hex string.
function deriveKey(passphrase, salt)
{
    if (typeof(salt) === 'undefined')
    {
        salt = _defaultSalt;
    }

    return passphrase == null || passphrase.length < 10 ?
        Promise.reject("Password must be at least 10 characters") :
        crypto.subtle.importKey(
            'raw',
            stringToUtf8ByteArray(passphrase),
            { name: 'PBKDF2'},
            false,
            ['deriveBits', 'deriveKey' ]
        ).then(function(passwordKey) {
            return crypto.subtle.deriveKey(
                {
                    "name": 'PBKDF2',
                    "salt": hexStringToByteArray(salt),
                    "iterations": _pbkdf_iterations,
                    "hash": 'SHA-256'
                },
                passwordKey,
                { "name": _algorithm, "length": _key_size },
                false, // Extractable is set to false so that underlying key details cannot be accessed.
                [ "encrypt", "decrypt" ]
            );
        });
}

function encryptData(keyObject, data)
{
    let iv = crypto.getRandomValues(new Uint8Array(16));

    return crypto.subtle.encrypt(
        {name: _algorithm, iv: iv},
        keyObject,
        data
    ).then(function(encryptedData) {
        return {
            iv:iv,
            data:encryptedData
        }
    });
}

function decryptData(keyObject, iv, encryptedData)
{
    return crypto.subtle.decrypt(
        {name: _algorithm, iv: iv},
        keyObject,
        encryptedData
    );
}


Using valid SSL/TLS connection by making sure you're always connecting to the https:// version of the website and that the browser isn't giving you any warnings or errors, is your first line of defence. An addon called HTTPS Everywhere can be very helpful here.

The approach you're proposing (SSH to your trusted network) is a very standard approach. I use it everyday to connect from any network in the street/restaurant/cafe using a small app called SSH Tunnel from my mobile or using any SSH client on my computer.

Important note: Always make sure you're connecting to your server by watching for fingerprint acceptance prompts and making sure you're accepting your server's fingerprint.


Why is it not standard practice to run password-based KDF's client-side?

I think the main issue are the client side languages (normally JavaScript), they are relatively slow. This would often lead to fewer hashing rounds and therefore weakens security.

If your client side language is fast enough, you could calculate the expensive PBKDF client side, then calculate a cheap hash on server side (SHA512 for example). To get the plaintext passwords an attacker still had to calculate the slow PBKDF. It is also not possible to use the PBKDF directly as password, because only the hash of the PBKDF is stored (the output of a PBKDF2 can be seen as a very strong "password", so it is safe to use a cheap hash function).

One downside is, that the handling will become more complex, you need to send salt and cost factor to the client for verification of the entered password. Another problem is to ensure integrity of the client side code, if somebody could alter the delivered JavaScript code, he could return a known string and you would store the now unsafe PBKDF.


Is there a way for most in the field clients to lock their channel to the one they know their secured AP is handling?

Irrelevant, but I will get to that in a moment.

  If i look at my channel can i tell immediately if there is an attack AP on me?

Maybe, but again that doesn't matter. The attack demonstrated by the discoverer of the KRACK vulnerability was just a proof of concept attack. It was not meant to provide a model for any sort of real world exploit. Just because that demonstration used a change in channel doesn't mean that any real world exploit would do so, it was simply a mechanism that allowed an easier demonstration of the exploit at work. Expect real world attacks to be a bit more "clever" than a proof of concept.

Put another way, the KRACK vulnerability doesn't depend on any sort of change in channel, it is purely an attack on the WPA/WPA2 handshake. While the change in channel may make some aspects of the attack easier, it isn't entirely necessary.

So depending on detecting a change in channel does not really provide you any protection, especially since many sites (including an increasing number of homes) also use multiple channels as part of normal operation. If you want to provide protection against KRACK, upgrade devices as soon as patches are available for your device.

Further, many consumer devices will auto select a channel, often at the time they boot or at scheduled intervals. If your device reboots for any reason, it may change channel itself. The change in channel is no sign of an actual attack.


Number of certificates in a PKCS#12 archive

Quick & Dirty:

$ openssl pkcs12 -in <CERTFILE> -nokeys -password pass: 2> /dev/null | grep -c "BEGIN CERTIFICATE"

Please be aware, that this assumes that there are no password(s) set. Otherwise you'll have to fiddle around with the password argument.


Secure endpoint for root domain only, no subdomains

Unfortunately what you are trying to do is effectively impossible because HTTP simply was not intended for this use case.  I think there are a few misunderstandings that are confusing the issue for you.  Running through things:

There is nothing special about browsers.  Browsers are just a fancy HTTP client that can send HTTP requests to an HTTP server.  However, they are not the only HTTP clients that can send requests to a server.  If you have ever made HTTP requests from your own server, you are already aware of this.  Similarly tools like postman, curl, etc, are also HTTP clients and can make HTTP requests to your server, except they are not "running" on a domain anywhere.
In fact the whole question of "what domain is making this request?" is a concept that doesn't exist in HTTP.  It's easy to misunderstand this fact because of how CORS works, but CORS is something that is baked into browsers - not HTTP.  CORS is only meant to protect HTTP requests made by javascript on a webpage inside a browser (again, it's not strictly part of HTTP).  As a result if you put up a completely restrictive CORS policy banning access from everywhere except your main domain, that CORS policy would do absolutely nothing if someone visited your API endpoint from literally any other HTTP client - which is what you just discovered.  Anyone using postman, curl, etc would still be able to access your API endpoints without issue, regardless of what CORS says, because CORS only matters for browsers.
Blocking by domain is impossible because HTTP doesn't know anything about domains.  When a client makes an HTTP request it first uses a DNS service (if needed) to convert the domain name of the destination into an IP address.  The client then sends its HTTP request to that IP address.  The only thing the server knows is the IP address of the client.  All other information is provided by the client and can therefore be easily spoofed by an attacker.  I say this because while some browsers may attach information to the HTTP request stating what domain the javascript that made the request is running on, a non-browser client can easily do the same and lie, claiming to be javascript running on your domain.

In short the only thing the server knows is the IP address of the client (technically that can be spoofed to, but it is substantially more difficult).  All other information about the request is provided by the client and therefore cannot be trusted for security purposes.

It may help to brush up on the basics of HTTP.  The details in that link break things down well.  The link also happens to focus on browsers as the HTTP client, which we know is not exclusively true.  Ironically articles like that one are why misconceptions like yours are common :)  Still, with a proper understanding that HTTP clients can be anything, that link should be helpful.

This doesn't answer how to secure your endpoints.  I can't give you an answer there without more details, which would basically make this a new question (aka you'd be better off asking a new question than editing this one, I think).  In general there are lots of strategies, but the short of it is that you can't have an anonymous endpoint and also selectively block users, except by IP address (which isn't possible for endpoints that are supposed to be accessed from a browser).  As a result there is only one general answer: you need to put some kind of authentication on the endpoint, even if it doesn't specifically require a login.


Is it safe to use session to check if the user is logged in?

What would be your plan otherwise? Sessions are merely a way to denote that a user has recently authenticated successfully, so you don't have to keep asking them for their password on every request.

You ask if you should also check the database. If you aren't checking the database, how are you verifying the provided session token is valid?

The most common attack against sessions is session stealing. The most common preventive measures are https on every connection that includes a session, and automatically expiring sessions (ideally not often enough that users complain) so a stolen session is only useful for a limited time.


The challenge is that if the machine is compromised, and it sounds like it is, your ability to diagnose and revert the compromise can be extremely hard if not impossible. This is because the compromise might replace system tools so you can't see its processes, etc.

If the compromise occurred by visiting that page and your web browser was not running with admin privileges and you did not allow it to elevate via UAC prompt, then the compromise would be contained to the login profile in use. But if the session was running with admin, the compromise could extend system wide and if so the ability to revert the damage is a lot hard -- if not impossible.

Assuming the compromise happened within a non-admin context, you can login in with another admin account and see files & processes. Look for processes you don't recognize. Look for files created/modified around the time frame of the compromise. What you find will determine the path to revert the damage. Could be as simple as a malicious chrome plugin was installed. If you cannot determine the compromise and revert, you can create another user and profile and start fresh and copy only the things you know were not compromised -- like documents, etc.

If the compromise happened with elevated rights, while it may be possible to revert the compromise, the best recommendation that can be made without knowing the specific compromise is to restore the OS from factory or fresh from the OS media.


Are the sticks of RAM in my desktop computer volatile? Is it safe to sell them?

Yes, they're safe. Consumer memory DIMMs use volatile SDRAM memory. Volatile means that it does not hold its state after you turn it off.
SDRAM memory chips are constructed from an array of memory cells, with one cell per bit of data stored. Modern memory ICs have billions of cells each. Each memory cell is constructed from a transistor and a capacitor. A transistor is like an electronic switch, and a capacitor is like a tiny battery. The value stored in the cell is a single bit - a value of 0 or 1, represented by a low or high voltage.
Here's a circuit diagram of a simple memory cell:

You can simulate this circuit in your browser here, and I'll talk you through how it works. You can control the simulation with the "Run/STOP" and "Reset" buttons on the top right. If the run/stop button is red, you've stopped the simulation. If it's grey, it's running.
I've labelled the transistor and the capacitor, so you can see where they are. The parts marked 10k, 100k, and 1M are resistors - don't worry about those for now.
At the top left of the circuit we've got our input data. This is a switch that selects either 5V or 0V (ground), to represent a value of 1 or 0. We use this switch to select which value we want to write into the cell. On the right, we've got our output data. This will show as 1 or 0 when we read from the cell.
Underneath that, we have a write/read switch. This selects which operation we want to perform. When switched to the left it writes a value to the cell, using whichever value was set by the input data switch. When switched to the right it reads a value from the cell and displays it on the output data.
The enable switch allows us to decide whether or not we want to talk to this specific cell at any point in time. When there are many of these cells all connected to the same input and output signals, this allows us to select just one cell to be read from or written to.
There's another switch marked "leakage". I'll get to that later - leave that switch open for now.
First, let's write a 1 to the cell. Set the input data switch to 1 and the write/read switch to write. Then close the enable switch. You'll see the bottom of the circuit light up green, and little yellow dots will move for a moment to indicate that a current is flowing as the capacitor charges up.

The top part of the capacitor goes green, indicating that the capacitor is now charged up and the cell's value is set to 1.
Next, flip the write/read switch to the right, in order to read from the cell. The output data now shows 1.

Repeat this again, but for an input value of 0.
Also have a play with the enable switch - you'll see that when it is open, the output data will always be 0 regardless of what you do with the input value and the write/read switch. Additionally, whatever value is stored in the capacitor stays there until you turn the enable switch back on.
What we've looked at so far is an ideal memory cell. It can store a 0 or 1 almost perpetually. However, in reality there is always some leakage in the capacitor that causes it to slowly lose its charge. You can simulate this with the leakage switch I included in the circuit.
Close the leakage switch, then set the input data to 1, the write/read switch to write, and close the enable switch. This will cause a 1 to be written to the cell. Now change the write/read switch to read, and look at the output data. It will show 1, just as before. Now wait a few seconds. The output data will flip back to 0.

If you watch the path through the leakage switch and the 10k resistor, you'll see the current dots flowing slowly along as the capacitor charge leaks out. Eventually, the capacitor voltage drops below the threshold voltage, causing it to be read as a 0 instead of a 1.
Try this a few times to get a feel for what's happening. Once you're happy with that, it's time for another experiment.
With the leakage switch closed, repeat the write process again and store a 1 in the cell. This time, instead of immediately performing a read operation, open the enable switch beforehand. Wait a few seconds, then close the enable switch. Here's the full steps in case it's not clear:

Close the leakage switch.
Set the input data to 1.
Set the write/read switch to write.
Close the enable switch. Observe the capacitor charging up.
Open the enable switch.
Set the write/read switch to read.
Wait 5 seconds.
Close the enable switch.

Notice that the output data is zero! What happened is that the charge in the capacitor leaked away while you were waiting, causing it to drop from 1 to 0.
This happens in real DRAM chips, too. The controller on the memory chip has to constantly refresh the data in the cells by reading them and writing their values back, to keep up with leakage. When you turn off your computer the data in the DRAM memory chips quickly degrades and leaks back to all zeroes. This process normally takes only a few seconds.
(interesting little aside here: the time it takes to set up the switches and get the data in and out of a specific cell is what defines the latency of memory, often listed as four numbers or just something like "CL16" - the memory timings wiki has some further info on this)
The leakage process can be artificially slowed down by cooling the chips down to very low temperatures, in what's known as a cold boot attack. This causes the cells to retain their values for much longer. It only works if you freeze the RAM right at the same time as powering the system off - if you wait even a few seconds before freezing it all the data will have begun to degrade. As such it's not a problem for you.

There are some additional interesting things that can be talked about here, such as SPD flash, NVDIMM, and Intel Optane, but I'm due to play a D&D game in ten minutes so I don't have time to expand this answer right now. I'll come back later and edit them in. Don't worry, though - they don't affect the safety of your sale!

Ok, zombie beholder's dead. Let's talk non-volatile RAM.
There's a special type of memory technology called NVDIMM. An NVDIMM is like a regular DDR SDRAM module, except it has a battery backup on it and a non-volatile flash memory chip. This allows the system to be powered off without losing memory state. The battery backup on the DIMM allows it to continue to refresh the memory cells. It then copies the contents of the memory cells into the non-volatile flash chip. It can then safely power off, because the contents of memory are saved and the volatile memory chips do not need to be refreshed. The operating system has to be built with support for this feature. This is a specialist memory technology usually reserved for server applications where you need to be able to recover the contents of memory during a power outage, or bring the system up to the same state quickly after maintenance (e.g. replacing a PSU or UPS).
Another type of non-volatile DIMM is Intel Optane. This is actually not RAM at all - it's better to think of it like a very low latency NVMe SSD that just happens to plug into a DIMM slot.
Finally, let's talk about SPD flash. When you plug a DIMM into your system, your motherboard needs to be able to identify it and learn about its specs and features - its name, size, type, speed, latencies, voltage requirements, inbuilt overclocking profiles, and all sorts of other details. This information is provided by a standard interface called Serial Presence Detect (SPD). In practice, the information is stored in a table (the exact format and contents of which is defined by JEDEC) in a small non-volatile flash EEPROM chip on the DIMM, which the motherboard can talk to via SMBus. The operating system can also talk to this chip to find out information about the memory - you can view it with a tool like CPU-Z.
Normally this SPD data is written to the EEPROM at the factory and never changed. However, it is entirely possible to write to the flash chip from the operating system. Some chips do technically have the ability to lock the first half of the data (usually the first 256 bytes) but often this is not done, and the second half of the data is always writable. The size of the SPD table for DDR4 is 383 bytes. However, nobody makes 383 byte EEPROM chips - that'd be weird. Instead, you'll usually find that the chip is 512 bytes in size. This means that there are 129 bytes left in the EEPROM that aren't used for anything. If you wanted to, you could store 129 bytes of non-volatile data in every stick of RAM in your computer, by writing to the SPD flash. I wouldn't recommend trying this yourself, since there's every chance you could brick your RAM if you do it wrong, but I did this as an on-stage demo at a security conference a while back.
The SPD interface isn't usually exposed to anything but the kernel, but there are many signed Windows drivers out there that either provide write access to SPD by design, as well as drivers that provide write access to SPD by accident, which you can abuse to write a small amount of data to the SPD flash chips.
There is, therefore, a scenario in which an attacker could use one of these drivers to write to the SPD flash. This data would remain on the DIMMs even after the system rebooted, or even if you re-installed your OS. The data doesn't do anything by itself - you need malicious code to already be running on the system to actually read and write it - but it is a nice little hidden storage location for a few bytes of data. There's almost no reason to abuse this storage location in practice - it's complicated, error-prone, requires admin and a loaded driver, for almost no benefit in return - but it is a fun little trick to store non-volatile data on regular volatile memory DIMMs!
One scenario where this is actually really important is bare-metal cloud hosting environments. In these environments, customers rent physical systems that they have complete administrative access to, rather than virtualised instances. Providers of these services need to ensure that there is no data remanence between one customer and the next. The SPD writing trick is one way for an attacker to achieve data remanence. There are plenty of other EEPROMs on the motherboard, hard disks, network card, RAID card, etc. that can also potentially be written to by an attacker with that kind of access. Bare-metal cloud providers have to implement special checks to ensure that these non-volatile flash memory devices were not modified. It's quite a challenge and hardware attestation is far from a solved problem. Again, this doesn't affect your consumer memory DIMMs, but it's a situation where a device that you expect to be volatile or stateless may actually have some non-volatile state.


Why are wireless adapters needed for wireless attacks?

Many of the native wireless cards used in commercial laptops are not capable of packet injection. While you won't need this to monitor network traffic passively, you will need that capability to perform any of the wireless attacks. Furthermore, some of the native cards have compatibility issues with Linux (i.e. driver support isn't great).

For this reason, many of the tutorials out there tend to stick with two well-known and reliable wireless network adapters:

Alpha AWUS036NH
TP Link N150

Note: these are not product recommendations, rather frequently used devices in many entry-level wireless pentesting tutorials. I point them out for reference not recommendation. (Though I own -and use- both regularly).


Is it secure to set the encryption password the same as the root password?

I don't have enough reputation to comment, so I'll post as an answer.

In general terms, you should never use the same password twice.
Manjaro is only enforcing and trying to make it mandatory.

Maybe this answer here can give you a better overview.


Make the public key unrecoverable given the private key

For the commonly used cryptographic algorithms, the public key can be recomputed from the private key. An edge case can be a RSA key with a big public exponent (i.e. not the traditional 65537) and without knowledge of the modulus factors. This contradicts the standard storage format described in PKCS#1; not knowing the factors means that private key operations won't be optimized with the CRT, so signatures and decryption will take four times as much CPU; and, last but not least, public exponents which do not fit on 32 bits will not be supported by some widespread RSA implementations (the CryptoAPI in Windows, namely).

Therefore, it does not seem practical to try to "hide" the public key from the private key holder.

In your case, you cannot prevent a MitM attack from the server side, and even if you could "hide" the public key, then this would buy you nothing: the attacker could mount a modified server which accepts every user as "valid" regardless of the public key they use to authenticate. If you want to protect your users against a MitM, have their software verify that it talks to the right server, i.e. yours. This is what plain SSH does with the known_hosts file. If you cannot use this facility but cannot distribute a modified SSH client either, then you will have to rely on user education: teach them that when they connect to your server and their client (e.g. PuTTY) grumbles about the server key not being known, make them verify the "key fingerprint" which the client will display: it should match the fingerprint of your server key.


What are the reasons this SQL injection code wouldn't work?

Is this MySQL specific? As others have noted in the comments, the standard MySQL extension in PHP does not support stacked queries. Stacked queries allow you to use semi-colons(';') to separate SQL statements in a single query. This type of functionality is only supported in the mysqli and PDO extensions of PHP.

From the PHP Documentation:

  mysql_query() sends a unique query (multiple queries are not supported) to the currently active database on the server that's associated with the specified link_identifier.)

The documentation explicitly states that multiple queries are not supported, so fortunately (unfortunately?) only one statement can be executed at a time.

Also take a look at this question, as it seems to be similar to yours.


Is it possible to be a hacker without being a criminal?

There are many ways you can be an "ethical hacker." Here are a few that come to mind:

You can write malware that helps catch the bad guys. Who the "bad guys" are may depend on who you're working for, and what your beliefs are. This may be a gray/black area to some.
You can write malware so you can understand how it works, and then defend against it. The best anti-virus authors are those who understand how to actually create malware.
You can get paid to find bugs in programs developed by large corporations, but this isn't generally "creating" malware; it's just finding security holes, of which people could use to inject malware.

Just because someone creates malware doesn't mean they're going to use it against others. For some, just understanding how it works is enough. Not everyone involved in information security is out to hurt someone.


Aside from SeDebugPrivilege, the other major privilege that is abused during escalation attempts is SeImpersonatePrivilege (leveraged in tools like Incognito). This privilege can allow the user to steal impersonation and/or delegation tokens that are present on the machine.

That being said, there are a number of administrative privileges that theoretically have the potential to assist during privilege escalation attempts, including:

SeAssignPrimaryTokenPrivilege
SeTakeOwnershipPrivilege (owning and modifying objects to elevate privileges)
SeCreateTokenPrivilege
SeTcbPrivilege
SeRestorePrivilege (write access to any file)
SeLoadDriverPrivilege
SeSecurityPrivilege

An exhaustive list would be difficult to compose, and I couldn't say with any degree of certainty that any administrative privilege could not be somehow leveraged in this way.

Furthermore, similar to how SeTakeOwnershipPrivilege and SeRestorePrivilege might be abused, a common method of escalation from Domain User that I see regularly involves overwriting binaries or other code that will be executed by a higher-privileged account. As such, write access to service binaries, System32, the All Users 'Startup' directory, application executables etc can lead to other accounts (Local System, Administrators) executing an attacker's code. I have personally found that poorly configured file permissions are a more common attack vector when escalating from basic users.

A good overview of different methods, including some of those above: https://www.netspi.com/blog/entryid/112/windows-privilege-escalation-part-1-local-administrator-privileges


How does a government shutdown Internet (and how to bypass it)?

Usually, the government will physically disable (usually just by unplugging or powering down) critical routers within their jurisdiction. It is not possible to bypass these, as there is a physical barrier that you cannot reasonably control.

Unfortunately your only options are to either find an ISP that the government does not control (if that exists, they won't be publicizing themselves, otherwise the government will shut them down, so you will probably have to look pretty hard to find one) or to find a 3/4G carrier who has reception in your area.


Passwords stored as obfuscated text, not encrypted

First thing I'd do is consider whether the system needs "reversibly encrypted" passwords at all (usually yes if it's sending them on to some other service rather than just verifying them when a user logs in, sometimes yes if this is required by some important customer but they should have an option to properly hash them as well). Second, since you say "a simple mapping" I assume this isn't actually using any modern cryptographic cipher primitives (AES, *fish, SALSA20, etc.), so that's definitely a security bug you can file.
Look up a security contact (email address, etc.). There should be one somewhere on the site. If you can't find one, try emailing security@company.domain, or just contact their support line and ask for a security contact.
Note that any form of reversible encryption, no matter how up-to-date its ciphers or strong its keys, suffers from a key storage problem: the program needs access to the key, which means anybody who can access the program itself can almost certainly decrypt the data. However, there are still improvements to be made from using real encryption:

Real encryption, even with a hardcoded key, will prevent anybody who doesn't know the key from reversing the encryption if they get access to the DB. It sounds like they currently don't even meet this - very low - bar.
Done correctly, the key should be unique per instance of the app. Getting access to somebody else's DB shouldn't reveal anything, even if you know the encryption key used by your own copy/instance of the software.
The key should be stored in a location as hard to access as possible. Ideally, it would be stored somewhere not actually extractable (like an HSM), with the app having the ability to request encryption and decryption of arbitrary strings but no other software allowed to access the HSM. At the very least the key needs to be separate from the DB, such that even an attacker with total, unfettered DB access can't get the key without finding a new vulnerability in some other part of the system.

It sounds like you're already well aware of why they should be using a slow password hashing function, rather than reversible encryption of any sort. Even if they need encryption for some passwords/API keys (stuff used to access external services, not to authenticate local users), they should use encryption for those secrets only, and use secure password hashing algorithms for user passwords.
If the vendor won't budge - says that it's not a security bug, or that they don't care, or just refuses to respond - give them some time and then (IMO) it's time to escalate. If possible for you, try to convince your company to threaten to cancel the contract; that's often the simplest leverage. If you can't, I would tend to move up to name and shame. Companies are usually way more likely to respond to things when it's likely to impact their bottom line, and bad publicity can do that. Sites like https://plaintextoffenders.com/, or just reaching out publicly on social media (especially to, or at least mentioning, well-known security figures), can help get the word out.
Obviously that last part isn't risk-free. There's probably something in the terms of use about not "reverse engineering" the software, and although I think this level of "cryptanalysis" doesn't count at all, I am not a lawyer. If you had to bypass any attempted safeguards to keep you out of the DB - entering a username/password of admin/admin might count, though copying a DB connection string out of a plain-text config file on a system you control does not - then that increases the risk they'd think it worthwhile to involve lawyers. A smart company wouldn't do this - siccing the law on somebody who is trying to responsibly report a security issue is a good way to get the entire security community mad at you, and some of us hold grudges and make product recommendations at big companies (and others are hacktivists) - but a smart company wouldn't let things get nearly that far to begin with. Before you take any steps beyond just reporting the issue to the vendor, especially if you have any notion of involving your company's name, you might want to talk to the legal department. However, I am not a lawyer, and this is NOT legal advice.


Using VPN in the UAE - safe or trackable?

Technically, if ZenMate is considered safe to use, then cannot see the communication.

Etisalat, like any other ISP, will see that you made a VPN connection to a particular service.  If ZenMate has no privacy issues (leaking of meta data, DNS queries, you installed backdoored version,  ...), then an ISP will not know what data you're sending and receiving over the channel.  Which is the same as any other end-to-end encrypted tunnel.

UAE ISP's however block several websites and services that clash with their (perhaps vague) policy, and this is backed by the UAE's cybercrime law; bypassing controls to access blocked content is against the law, but then it becomes a legal issue and this wasn't the question.


A secure OS is an OS that is maintained by a sysadmin who knows his job. This trumps everything else. So, basically, when the sysadmin knows all the internal details of BSD, and not of Linux, then BSD will be more secure than Linux. However, if the converse holds (sysadmin knows Linux better than BSD), then Linux wins.

In the quasi-mythical case where a given sysadmin would be equally good at BSD and Linux administration, then it might be construed that some specific characteristics of the two OS might tilt the overall security balance one way or another. For instance, one may say that the more confidential nature of the BSD systems implies a relative scarcity of published exploit, giving the sysadmin a small advantage over the hordes of not-very-competent attackers that know how to download exploits but do not know enough to adapt them to other systems. Since the situation of equal sysadmin competence in both systems cannot be achieved in practice, one may say that this kind of comparison is purely theoretical with no actual relevance.

Now of course I encourage you to try out both systems -- on your own test machines, of course. Trying out systems is a great way to build up sysadmin competence. But don't believe propaganda that claims that one system is more secure than others. What really matters is that some sysadmins are more competent than others.


What is Non-Repudiation of content? How can we combat it?

There are 4 basic principles used in cryptography:

confidentiality
integrity
authenticity
non-repudiation.

I will not go through the mathematical aspects involved, instead I will try to offer a more general description.
Confidentiality is assured by the encrypting of data, integrity and authenticity are assured by a signed digest and non-repudiation is assured by the linking of the above operations to a digital certificate.

The owner of the certificate is responsible for every action performed using that certificate.

The best example I can think of right now for non-repudiation is that of the law of digital signature. This law  states that a digital signature is in every way equivalent to the signature made by hand by a person. Usually, a trusted time source is also involved, so that the time of the signing is also trusted.

All these ensure the fact that if you digitally sign the document, you cannot deny the signing, because of the fact you are the owner of the certificate and because there is a trusted time reference.
It is the same as signing a contract for a loan at the bank. You cannot say you were not the one that agreed to the contract, because they have the proof (the handwritten signature).


Did somebody try to spoof my wifi network?

While this is probably not enough information to determine with
  certainty what happened, I am wondering: is this how a (failed?) wifi
  spoofing attack would look like from the victim's point of view?

Yes (which is not the same as saying that it happened).

Specifically, someone nearby could have used airdump-ng or equivalent to get your AP's SSID and MAC address.

Then it would have issued a forged deauth packet to log everybody off the AP. This closely matches your symptoms.

Finally it would have set up a fake access point with the same MAC and SSID, but transmitting at a markedly higher power (not really difficult this, as he's trying to overpower a smartphone). Your Mac then connects to the rogue AP.

Next thing you know, you're supplying your credentials (as Torin42 noticed, this requires some social engineering and works best with a little help from the OS) to the attacker. Who is apparently not interested in intercepting your traffic (otherwise he would have let you log, lying in wait for you to enter some other credentials such as email, home banking and such). But now that he has your credentials, he's free to hijack your access point and surf for free without any need to crack the WPA2 encryption.

The attempt failed because you changed your WiFi password, and because he did not allow you to connect to the rogue AP. The latter could have disclosed other credentials on the Mac, not doing the former would have left your AP exposed to a connection with stolen credentials.

There are diagnostic tools for PC and Android (don't know about the Mac) that would help recognize this situation - if you scan the neighbourhood with e.g. WiFi Analyzer (Play Store: com.farproc.wifi.analyzer), you would see your access point - which must be running on a different phone - with an expandable 'shadow' with the same MAC as the main one (WiFi range extenders would have the same, with two different MACs).

Or - even easier - if you turn off the AP on the phone and scan the neighbourhood, you would see your AP's name, which ordinarily could never be seen (as WiFi client and AP server functions are mutually exclusive).


Computing RSA 1024-bit Decryption Performance

Performance really depends on the implementation, the type of processor, the processor clock, and many other factors. The OpenSSL command-line utility includes a benchmark tool. For instance:

$ openssl speed rsa1024
Doing 1024 bit private rsa's for 10s: 2430 1024 bit private RSA's in 9.28s
Doing 1024 bit public rsa's for 10s: 48984 1024 bit public RSA's in 9.92s
OpenSSL 1.0.1 14 Mar 2012
built on: Tue Jul  3 20:15:19 UTC 2012
options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT
-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
                  sign    verify    sign/s verify/s
rsa 1024 bits 0.003819s 0.000203s    261.9   4937.9

The machine I ran this on is known to be quite slow (it is a low-power VIA C7 x86 clone). A Pentium 4 (which is also a 32-bit system) should run at least as fast as that, but probably not supremely faster (I would be surprised if OpenSSL reached 1000 signatures per second with RSA 1024 on a Pentium 4).

Translating such a figure into application performance is a difficult exercise.


Local File Inclusion [ Post-Exploitation ]

This may depend on what files the webserver's user may have access to. But, this user should at least have access to the files related to the webserver. This could include viewing application source code (to help find additional, more severe issues like RCE), configuration files (possibly containing sensitive information such as database credentials which could be used by an attacker if the database server is exposed), or other files (think user uploads).

As far as general Windows files, I found a cheat sheet for Windows LFI online: https://www.gracefulsecurity.com/path-traversal-cheat-sheet-windows/

C:/Users/Administrator/NTUser.dat
C:/Documents and Settings/Administrator/NTUser.dat
C:/apache/logs/access.log
C:/apache/logs/error.log
C:/apache/php/php.ini
C:/boot.ini
C:/inetpub/wwwroot/global.asa
C:/MySQL/data/hostname.err
C:/MySQL/data/mysql.err
C:/MySQL/data/mysql.log
C:/MySQL/my.cnf
C:/MySQL/my.ini
C:/php4/php.ini
C:/php5/php.ini
C:/php/php.ini
C:/Program Files/Apache Group/Apache2/conf/httpd.conf
C:/Program Files/Apache Group/Apache/conf/httpd.conf
C:/Program Files/Apache Group/Apache/logs/access.log
C:/Program Files/Apache Group/Apache/logs/error.log
C:/Program Files/FileZilla Server/FileZilla Server.xml
C:/Program Files/MySQL/data/hostname.err
C:/Program Files/MySQL/data/mysql-bin.log
C:/Program Files/MySQL/data/mysql.err
C:/Program Files/MySQL/data/mysql.log
C:/Program Files/MySQL/my.ini
C:/Program Files/MySQL/my.cnf
C:/Program Files/MySQL/MySQL Server 5.0/data/hostname.err
C:/Program Files/MySQL/MySQL Server 5.0/data/mysql-bin.log
C:/Program Files/MySQL/MySQL Server 5.0/data/mysql.err
C:/Program Files/MySQL/MySQL Server 5.0/data/mysql.log
C:/Program Files/MySQL/MySQL Server 5.0/my.cnf
C:/Program Files/MySQL/MySQL Server 5.0/my.ini
C:/Program Files (x86)/Apache Group/Apache2/conf/httpd.conf
C:/Program Files (x86)/Apache Group/Apache/conf/httpd.conf
C:/Program Files (x86)/Apache Group/Apache/conf/access.log
C:/Program Files (x86)/Apache Group/Apache/conf/error.log
C:/Program Files (x86)/FileZilla Server/FileZilla Server.xml
C:/Program Files (x86)/xampp/apache/conf/httpd.conf
C:/WINDOWS/php.ini
C:/WINDOWS/Repair/SAM
C:/Windows/repair/system
C:/Windows/repair/software
C:/Windows/repair/security
C:/WINDOWS/System32/drivers/etc/hosts
C:/Windows/win.ini
C:/WINNT/php.ini
C:/WINNT/win.ini
C:/xampp/apache/bin/php.ini
C:/xampp/apache/logs/access.log
C:/xampp/apache/logs/error.log
C:/Windows/Panther/Unattend/Unattended.xml
C:/Windows/Panther/Unattended.xml
C:/Windows/debug/NetSetup.log
C:/Windows/system32/config/AppEvent.Evt
C:/Windows/system32/config/SecEvent.Evt
C:/Windows/system32/config/default.sav
C:/Windows/system32/config/security.sav
C:/Windows/system32/config/software.sav
C:/Windows/system32/config/system.sav
C:/Windows/system32/config/regback/default
C:/Windows/system32/config/regback/sam
C:/Windows/system32/config/regback/security
C:/Windows/system32/config/regback/system
C:/Windows/system32/config/regback/software
C:/Program Files/MySQL/MySQL Server 5.1/my.ini
C:/Windows/System32/inetsrv/config/schema/ASPNET_schema.xml
C:/Windows/System32/inetsrv/config/applicationHost.config
C:/inetpub/logs/LogFiles/W3SVC1/u_ex[YYMMDD].log

Some of these should be world readable; others may be locked down or non-existent.  These should provide a good starting point, but there may be additional files you should add depending on what you are looking for.


Root kits / keyloggers do exist on Android.
There are plenty of commercial viruses/rootkits that do.  An example of this HackingTeam who has exploited several zero days and has written maleware that has the ability to rootkit your whole phone and track every app you use and your location and read your texts along with rootkits.

more info on this:

http://www.hackingteam.it
https://en.wikipedia.org/wiki/Hacking_Team

As for the Permissions.there is external read / write permissions. And probably other ones. Read these two articles by android.

https://developer.android.com/guide/topics/permissions/normal-permissions.html
https://developer.android.com/training/basics/intents/index.html

Yara(a tool which many anti virus programs like ESET and CLAMAV US)which is used by pattern analysis on android that will search for Keylogger like signatures and priv exec. Any other tool besides yara for maleware anaylsis is pretty much garbage.

Note Some of the process are legitimate may have functionality to your keyboard.
below are links to yara, and some rules that were written for detecting android male-ware:

https://virustotal.github.io/yara/
https://github.com/Yara-Rules/rules/tree/master/Mobile_Malware


SSL with client certificate authentication

...if for example I use Server certificate, with 2048bit keys and client certificate with only 512bit strength, does this use in any way affect the security of the established SSL?

It does not affect the strength of encryption since this depends at most on the servers certificate (for RSA key exchange). But it will affect how easy the client certificate can be spoofed, so it does affect the credibility of the client authentication. 512 bit keys are considered broken since 1999 and might have been spoofed in 2011.


How can you hide the usage of an external VPN?

Based on the example of Netflix I think you falsely assume that it is all about explicit detection of VPN. Netflix for example seems to check that the geographic location matches the information in the account. It also seems to check if the traffic comes from some web hosting sites, since the expectation for a customer would be some DSL line or maybe public hotspot instead.

Thus how to bypass such detection depends a lot of how the detection is done. A common way to bypass these checks is to come from a "residential" IP address, i.e. an IP address associated with customer DSL, cable, fiber or mobile connections. There is a whole industry to offer "residential proxy networks" to whoever want to hide its activity behind innocent citizens and these service are often used by companies doing web scraping or similar. The residential proxy networks work by (ab)using "free" (with a catch) VPN like Hola VPN or which even employ network of hacked machines (botnet) of private citizens - see Resident Evil: Understanding Residential IP Proxy as a Dark Service.

Of course, you might actually find the VPN offered by Hola and others actually useful for your purpose since it also allows you to let your own traffic hide behind some residential IP address in another country. Just be aware that others will do the same with your own IP address and any problems coming from this (i.e. accessing illegal content) are then your own.


About security of web application - user attached files

The possible vector is a content-range attacks, when you will be asked for a document not from the very beginning of it, it can force you to read all the content into the memory for sending just a byte. So you can hit OOM on server while network and bandwidth payload for the attack is measured in hundreds of bytes


Cache side-channels: Prime & Probe attack

Just to reiterate, this is how cache timing attacks work:

Attacker fills up the cache with arbitrary data. The actual values don't matter, so long as the cache is full of data that isn't what's accessed by the algorithm.
Some portion (or all) of the algorithm runs.
Based on how long it took and their knowledge of the relevant algorithm, the attacker can estimate what cache lines were loaded. Note that this does not have to happen locally -- depending on how the encryption is used, it can be done remotely as well, even over a busy network!

See, e.g., this paper for a description of using cache timing attacks against (at the time) common AES implementations. In short, because you know how the algorithm works (Kerckhoff's Principle) and nonces come from the client, you can pick your nonces and messages carefully so that certain nonces will trigger a significantly different timing. The only uncontrolled variable is the secret key, so it must be influencing the timing. Repeat with enough nonces, and you'll be able to determine that a certain timing pattern can only occur with a certain set of nonces if a specific byte of the key is one of 23 options, instead of one in 28.

While it won't give you the exact address used, you don't need that, and in fact it probably wouldn't be very useful without context. What's important is that, because certain data is loaded into the cache and therefore quicker to access, you now have more constraints on the possibilities than you did before, and you can brute-force within those constraints much faster than you could the full, 128-bit key.


How can I protect the confidentiality, integrity and authenticity of my communication if I am victim of a Man-in-the-Middle attack?

How to protect confidentiality and integrity?

Limit who you trust; encrypt everything.

Obviously, don't install any CA certificate imposed by the ISP. Consider removing certificates that are controlled by parties you do not trust.

At a minimum, make sure HTTPS is used for everything; you could even block traffic to port 80 and other HTTP ports to ensure nothing is leaked. Even with HTTPS, the ISP can still see the hostnames of the site you are visiting, thanks to SNI, if using TLS < 1.3 without ESNI. To mitigate this, only use TLS 1.3, and/or use a browser that supports ESNI. Problem is, not all websites may support these technologies.

The other major threat is DNS. DNS reveals just as much as SNI, but it also has no guarantee of integrity. Even if you change your DNS provider to something outside of your ISP, your ISP could theoretically redirect your DNS queries to their own servers and modify the traffic without any way to detect it. There are several replacements for DNS which attempt to mitigate the confidentiality and integrity problems, notable of which are DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), dnscrypt, and dnscurve (note DNSSEC is not listed; it does not solve the problem of confidentiality). These protocols are all incompatible with each other and have varying degrees of standardization; it appears that DoH and DoT have gained the most traction. Various big-names have started promoting these protocols and have started offering them within browsers and mobile operating systems. These protocols can either be enabled individually on each device in the network, or configured on the router so that all devices speak normal DNS to the router, which then proxies the request using DoH or DoT.

But the above may not cover everything you do. To ensure more complete safety, use something that can tunnel all of your traffic, such as a VPN*, IPsec, or Tor (as written in the other answer, the ISP may have blacklisted known Tor nodes, so you may need to choose an entry node manually). Ensure that wherever the tunnel ends, it is beyond the reach of your ISP (e.g. don't set up a VPN tunnel to a friend's house that uses the same ISP), and it with a party that you trust (relatively). This depends on your exact threat model, so "free-VPN-that-collects-and-logs-all-your-traffic" may be acceptable compared to an ISP that is actively hostile.

If you own and control your own router (preferred anyway), you may be able to configure it as a VPN client such that all devices on your network will automatically use the VPN. If you do not control your router (i.e. ISP owned), connecting to a VPN from each device on the network will mostly mitigate the threat of the router.

*Most modern VPN providers and software will have pretty safe defaults, but VPNs can be configured without encryption as well, so don't automatically assume they are equivalent in all possible scenarios.

How to evade detection of these methods by the ISP?

This is definitely a hard problem, as it is fairly trivial to analyze network traffic. That is, changing the port you use for a protocol may not fool anyone (unless the traffic is encrypted and unrecognizable, and on a port that normally has such traffic). So, tunneling all of your traffic over a VPN on UDP port 53 may defeat some basic firewall rules, but deep packet inspection (DPI) will immediately raise red flags; port 53 is usually for DNS, which is a well defined protocol. Your traffic won't look like this at all.

Likely, the best option is to choose a port such as TCP 443. Still, it may be possible to profile the traffic and determine that it is not purely web traffic, with a decent degree of certainty, but it may not raise too many red flags since most internet traffic is probably over 443 anyway.

There are also ways to tunnel IP traffic over standardized, plaintext protocols such as HTTP, DNS (iodine), carrier pigeon, and ICMP (icmptx). While I do not think these may solve the problem (in fact, they could bring more attention to your traffic), they are interesting and perhaps relevant. I suppose there could be a scenario where your ISP forces you to use plaintext protocols that they can enforce and inspect with DPI. A VPN could be used to tunnel all traffic over another protocol while still conforming to the outer protocol's standards, thus evading the restrictions.

Summary

Require HTTPS and secure DNS
If this prevents your availability, e.g. the ISP forces HTTPS traffic to a proxy, use a VPN or Tor with manual entry nodes. The VPN may take some research or experimentation to get working; perhaps there are ports or protocols that are overlooked. E.g. perhaps TCP traffic is bent toward the proxy, but UDP is overlooked or mistakenly routed anyway (possibly only certain ports), but this is only a hypothetical misconfiguration
If all else fails, use application-layer encapsulation as a last resort. HTTP/DNS tunnels often still work behind proxies and forwarders, and may allow your traffic to pass through since it matches an allowed, cleartext protocol (but obviously your data would be encrypted). There may be some severe performance penalties to this method, but it can get you out of many a tricky scenario. This is not foolproof, it will still stand out and could be signatured.
Adapt to whatever they throw at you


can one stop spam with my name but not my address

You can try to filter spam messages. First of all, check if your email provider has enabled spam filter for your account. There is a lot of anti-spam techniques which can be employ to help your problem:

RBL,
URIBL,
SPF,
greylisting,

and a lot of others.

On the other hand, if you are using local email client you can install some anti-spam plugin:

http://www.specificfeeds.com/blog/the-best-free-spam-filters-for-outlook-thunderbird-and-outlook-express/
http://email.about.com/od/outlookspamfilters/tp/anti-spam_ol.htm
https:__addons.mozilla.org/en-us/thunderbird/addon/emailsecurityplus/


You might want to develop a UDP proxy. UDP is very easy to be proxied, each packet is a complete data structure, so it's easy to filter it.
UDP proxy would be an Linux C application which is receiving packets on port X and resending it to port Y. This could be simple as single loop. In this loop, you can run any kind of check and drop packets by simply not forwarding them.
It's that easy because it seems it's not encrypted traffic.


The book you are after is:

Cryptography and Network Security: Principles and Practice

This book contains all the information you need to understand the use of cryptography in practical protocol applications.


A common social engineering ploy which uses such reflective xss attacks is to trick users into entering obfuscated javascript code into the input box themselves. Usually under the pretense that it would be some secret trick to do something interesting on that website. But what it actually does is steal the user's login cookie and write a message to everyone on their friends list telling them to also try out the "secret code".

Another use of such a reflective XSS vulnerability is to combine it with a cross-site request forgery attack. An attacker would build a form on a website they control and have it submit to the same URL on the target website which the vulnerable form submits to. They would then lure their victim to their website. The victim doesn't need to perform an action on the attacker's website, because it's possible to submit the form automatically on pageload using javascript. This only works under the conditions that 1. the vulnerable form is processed server-sided and 2. the vulnerable website doesn't use the standard methods to prevent CSRF attacks (validate the user's Referer header for POST requests, use a sane CORS configuration for XmlHttpRequest's).

Should you report it as a bug even if you don't manage to find an exploit? Definitely. It's certainly not intended behavior and a sign of bad code.


Is it a good practice to use certificates as a mean of client identification in a cloud environment

It may not be best practice because you're using a specific-purpose CA (in which case, authenticating your OpenVPN clients) for something else, but security-wise, as long as that CA is secure, your solution is fine.

I would recommend however putting the private key of that CA certificate somewhere safe, like a smartcard, a completely offline computer or an HSM.


Is there any way to estimate the safety of arbitrary binaries, which are usually released with unofficial patches?

I suppose that it is hardly possible to include malware by arbitrarily changing a few bytes in the executable; so this should be safe;

Viruses can easily be as small as about 50 bytes of code, so changing a few bytes isn't an indicator. Granted, most AV can detect viruses this small, so the risk is minimal, but be aware that it doesn't take much to turn a normal executable into a bomb.

  Github binaries with source code provided should hopefully be safe, though I may be naive here, especially since out of box builds may differ from the source code.

True, your best bet is to build your own binary, but Open Source Software tends to be safer only because there are so many people looking at it. If something was amiss, it'd probably be reported before it had a chance to do much harm (but, note that things like Heartbleed still get out in the wild despite such assurances, so it's not foolproof).

  Arbitrary executables provided on fansites dedicated to the game are only as safe as the site is reputable... but that's an odd way to say that if the admin isn't known to have included malware within past 10 yrs they're unlikely to include malware now?

On the internet, reputation tends to be important. That's why sites like Stack Overflow actually work. I would say that over 99% of "fan sites" are probably likely to be legitimate, because almost nobody wants to be the one that tarnishes the image of their beloved franchise. However, it's no guarantee. People that are out to do harm will most likely fake their 10 year reputation in order to seem legit, because ten years just to plant a virus isn't practical.

Overall, the only way to stay 100% safe is to never run any code from anyone ever. There's always a risk. You can reduce the risk by using legitimate sites, but even those can be hacked. Always use an up-to-date antivirus, always check signatures, and always have backups. And always backup your data. There, said it twice. As long as you have everything backed up, you should be good to go. Real fans won't harm your computer, but be aware of posers that will. Almost all "pirates" prefer their reputation over doing damage, it's the scammers and crackers you should be worried about.


Does versioning an encrypted file make it less secure?

If the encryption algorithm in question is weak against a Ciphertext-only attack, having multiple variants of an encrypted files might allow an attacker to decipher the ciphertext.

All strong encryption algorithms including AES isn't susceptible to such attacks. You should be fine.


How to restrict access to API in Azure API Management to known applications?

Short answer: you cannot.
As soon as you ship a secret to the client, the secret is not secret anymore. No matter how many layers of obfuscation you employ, if the application somehow have access to the secret, the attacker have access too.
The only way to protect the API is to only run it server-side, and offer the service for your clients from the server.


Security implications of storing the password hash along an encrypted AES key

Just to make sure I've got it - you're storing:

the hashed password - theoretically the password can't be recovered, since the hash is one way.
the salt - only half the equation for the encryption key, since you need the password in the clear as well, right?
the encrypted AES key

So... the AES key is the real payoff, presumably, because that's being used for encrypted communication or storage.

When you want the server to use the key, I'm guessing the process is this:

user gives the system his password
system checks the password, hashing it - and it's good.
system takes the password (not the hash!) and the salt and computes the encryption key
system takes encryption key and decrypts AES Key

Then the system handles the AES key appropriately, does whatever it needs to do and erases any copy of the AES key from memory so that it's not lying around in the clear anywhere.

As is, I don't see a weakness in that, but you've boiled everything down to the strength of the password.  If an attacker should get your data store, the one thing he needs but doesn't have is the password.  If a user has an easy to guess password, then the attacker will get the user's AES key.

I think it if was analyzing this system, I'd not worry too much about that - instead, I'd start poking around at how user passwords are communicated and how the AES key is handled after it's decrypted - those are weak points, too and may be easier to hack than a back end data store of hashes, salts and encrypted keys.


Does a valid code signing certificate mean that an installer has not been tampered with in transit?

The signature is of a hash of the portion of the executable before the code signing block. Best practice is to have both the installer and the application signed.

You can study some details by looking at this:
https://msdn.microsoft.com/en-us/library/windows/hardware/gg463180.aspx

EDIT:  OK, now that I'm off the mobile device and on a real keyboard, I can elaborate.

As noted in the document to which I referred you, the hash that gets signed is generated as to the entire executable file except for two excluded portions (a) the total file checksum; and (b) the certificate tables.   These cannot be incorporated into the hashing because of the chicken or egg problem (e.g., these fields are dependent on the content of the attribute certificate table, and thus their values are not fixed until the certificates/signatures are prepared and appended).

As for the attack surface/scenarios, we see once again why it is so important to have good crypto primitives, and ALSO to use best practices.  I suppose that in theory an attacker could create a malicious version of a software application, and then roll it into an installer and include some carefully calculated data to generate a hash collision with an existing real MD5 certificate from the application vendor, attaching that existing certificate/signature to the compromised executable.   If you only checked the installer you might get fooled.   This is why MD5 cannot be trusted for this sort of application anymore. It is also why, in addition to checking the installer, you should check the application program itself.

Windows 7 accepted MD5 hashes for code signing, whereas Windows 8 and up requires SHA1 or better.  (For what it's worth, I dug around my program files and old installers just now and only found one from 2008 or so that used MD5 for the signature hash. 2nd edit:  I take that back, I also found a relatively recent version of Winzip using MD5).


What are the security risks of basic authorization in SOAP requests?

I can think of three points:

You must use HTTPS, or password will be sent in plaintext. But you need HTTPS for all authentication so this is not specific to basic auth. (I wouldn't really care about the fact that the password hits the network multiple times instead of once. Either you use HTTPS, and then it is fine, or you don't, and then just sending it once is already a catastrophy.)
Browsers will have to cache the password instead of just a temporary token of some sort. Maybe not a huge issue, but still.
You must make sure that the passwords are properly hashed on the server side. This is not always the case for common implementations, so be wary! Since the password has to be checked every request, proper password hashing comes with a higher performance penalty, especially if it is a busy system.


How to get net anonymity while browsing?

I'm not saying either answer is WRONG, but here's the answer to your question: Yes, Tor ought to protect you from an admin looking at your traffic. If that's all you wanted to know, stop reading now.
HOW TOR DOES THIS:
Tor employs a principle called onion routing to ensure privacy (hence its name, The Onion Router). Here's how it works: You hook up to the Tor network. Then Tor works out a path THROUGH ITS OWN NETWORK OF COMPUTERS WITH TOR for your data to take. Here's a graphic showing a prospective path:

Now you perform something called a Diffie-Helfman key exchange (SE community, please correct me if I'm wrong about this part) with all computers along the path individually. In a 3 computer path you now have worked out f(x) (with the first computer), g(x) (with the second computer), and h(x) (with the third computer). Let's call your request for information m. You work out f(g(h(m))) and send it to computer 1. Computer one, who only knows f^-1(x) (meaning f-inverse of x), performs that operation, and sends the result along to computer 2. Computer 2 only knows g^-1(x), so it performs that and... well you get it. After computer 3 has undone the third encryption, it takes a look at your request and passes it on to the pornography server you were trying to contact, named Bob. Bob sends computer 3 your erotic Animorphs fanfiction (sorry, couldn't resist). Computer 3 now sends your fanfic along the same chain of communication that we already looked at.
This system is effective for several reasons, but I'll just say this: Due to the properties of the Diffie-Helfman exchange (there's another answer on here that explains it just beautifully) your sysadmin will never see the keys for f(), g(), or h(). All he will see is that you're sending an encrypted packet to an IP that doesn't belong to any website at all. Will he be able to determine that you're using Tor? Almost definitely. Can he do anything about it? Well, he can stop you from accessing the internet (in fact, he might decide to), but he can't see your internet traffic, which means that you can keep your erotica to yourself. I would warn you that Tor includes an add-on called NoScript that stops you from watching video, so I hope your fanfic is in text form.


Can a detached hard disk reveal the system information of machine from which the hard disk is detached?

For Linux-based operating systems, very much so.  The kernel prints out a detailed hardware summary during the startup process, which typically gets written to the system log.  For example, some excerpts from my computer's log:

Memory: 32877348k/34603008k available (3933k kernel code, 1126392k absent, 599268k reserved, 1997k data, 576k init)
...
CPU0: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz stepping 07
...
pci 0000:00:00.0: [8086:3c00] type 0 class 0x000600
pci 0000:00:01.0: [8086:3c02] type 1 class 0x000604
pci 0000:00:01.1: [8086:3c03] type 1 class 0x000604
pci 0000:00:02.0: [8086:3c04] type 1 class 0x000604

CPU, memory, expansion cards, peripherals, virtually any autodetectable hardware connected to your computer will be listed there.


In theory, someone might be able to find a buffer overflow in notepad that could cause issues when opening a file, but the chances are pretty minimal and the file would have to be specifically made to exploit notepad.  A sandbox is still technically the safest, but I generally view files in Total Commander's viewer (which is equivalent to opening it in notepad) because the risk is so low that it isn't really a problem unless you have really high security needs.


AES in CTR mode with same random IV to create same ciphertext

If I understood your question correctly, you're trying to generate an AES key using AES and the user password as a key, then use that key to encrypt an RSA key.

Granted, AES will give you a very indistinguishable ciphertext that you can use as an encryption key if you wanted. But AES isn't really a password-based key derivation function, mainly because it's pretty damn fast.

What you're looking for is PBKDF2. You can feed it the user's password, and as long as you feed it the same parameters, it will give you the same fixed-length key. You can use that key for your encryption and later decryption. So you'd end up with something like this:

Enrypted_RSA_Key = AES-CTR(RSA_KEY, PBKDF2(USER_PASSWORD))


Exploiting vulnerabilities in the C code

1)

          m                          s
 +-----------------+-------------------------------------+
 |AAAAAAAAAAAAAAAAA|                                     |
 +-------------------------------------------------------+
 ^                 ^
 |                 |
 +                 +
src               dest

If m contains exactly 100 bytes and is not null-terminated, then what will happen after strcpy(s, m)?

After 100 bytes are copied:

         m                          s
+-----------------+-------------------------------------+
|AAAAAAAAAAAAAAAAA|AAAAAAAAAAAAAAAA|                    |
+----------------------------------+--------------------+
                  ^                ^
                  |                |
                  +                +
                 src              dest

As there is no null-byte at src, it will keep copying:

         m                          s
+-----------------+-------------------------------------+
|AAAAAAAAAAAAAAAAA|AAAAAAAAAAAAAAAA|AAAAAAAAAAAAAAAAAAAA|
+-----------------+----------------+--------------------+
                                   ^                    ^
                                   |                    |
                                   +                    +
                                  src                  dest

and it will keep copying like this until it finds a null-byte (which it obviously never will) and will destroy the stack and will continue copying until it runs into an unmapped address and causes a segmentation fault.

2) Free'\0'$1.50. x will be 1, y will be 50, but strcpy(s, m) will copy Free to s.

3) Free'\0'$0.50000. x will be 0, which will pass the check at L10, but y will be 50000, and L13 will yield 100*0 + 50000, or $500.

Updated answer for 1:
You are probably having trouble replicating it because the size of m and s are not actually 100 and 200 but something like 112 and 208 (depending on the preferred stack boundary of your compiler). So s does not start exactly where m ends. And if there happens to be no leftover data from previous stack operations in that extra space, then this will not work. The question mentions 'potentially' crashing the process, as this will not work in all platforms and in all contexts.

The key thing to note here is that running strcpy on a src buffer that may not be null-terminated is an unsafe operation. For example, as m and s are uninitialized, there might be leftover data from previous stack operations which will then cause strcpy to go berserk. Example snippet:

#include <stdio.h>
#include <unistd.h>
#include <string.h>

void randomstuff()
{
    unsigned char buf[400];

    for (int i = 0; i < 400; i++)
        buf[i] = 'A';

    buf[399] = '\0';
}

void vuln()
{
    unsigned char m[100];
    unsigned char s[200];

    read(0, m, 10);
    strcpy(s, m);

    printf("%s\n", m);
}

int main(void)
{
    randomstuff();
    vuln();
    return 0;
}

Here, we are making sure there is some stuff on the stack where m and s resides (a string of 399 As). Note that we are reading only 10 bytes into the 100 byte m buffer. Yet literally provide any input to read to watch this program burn.


Cipher Key Length versus Encryption Bits

Rijndael is a versatile block cipher which can work with blocks of size 128, 192 or 256 bits, and with keys of 128, 192 or 256 bits. All nine combinations are possible.

In 2001, as part of an open competition which went on for three years, Rijndael was chosen to become the US federal "Advanced Encryption Standard", aka the AES; but only with a block size of 128 bits. So there are exactly three versions of the AES, all with a 128-bit block size, and with keys of 128, 192 or 256 bits.

Therefore, while Rijndael formally supports blocks of 192 or 256 bits, it is very rarely used that way; it is thus highly plausible that MCRYPT_RIJNDAEL_256 actually means "Rijndael with a 128-bit block size, and 256-bit key (aka 'AES-256')".

The Initialization Vector (IV) is a piece of data which must be used as parameter to the encryption mode; in your code, you appear to use CBC, so the IV must have the same length then the block size (128 bits, aka 16 bytes).

I see that you are trying to use PBKDF1. This is an old key derivation function which is limited in several ways, including its inability to output more than 20 bytes. You will have a hard time getting 32 bytes of key and 16 bytes of IV ouf of PBKDF1... I suggest you switch to PBKDF2, also defined in RFC 2898, implemented in C# by Rfc2898DeriveBytes, and which can output as many bytes as you need.

Note that PBKDF2 (and PBKDF1, for that matter) use some configurable parameters, such as an "iteration count", or the name of the underlying hash function. You have to take care to use the exact same parameters in the PHP code and in the C# code, otherwise you will not obtain the same keys and IV, and decryption will fail.


Does public key auth in SSH prevent most MITM attacks?

1.Yes it is correct. There are 2 possible ways:

  A) Alice blindly accepts the new fingerprint from the attacker mallory.
  Alice and Mallory could connect and authenticate each other. Problem
  here for Mallory is, that he couldn't sign the session id, exchanged
  with Bob. Because Mallory doesn't own Alice's private key. And
  also Mallory couldn't redirect the signed session id from Alice to
  Bob, because the session id would be, with high probability,
  different.

  B) When Alice doesn't blindy accept the new fingerprint, Mallory could
  send the public key and thereof the fingerprint from Bob. Problem here
  would be that Mallory couldn't authenticate to Alice, because Mallory
  didn't own the private key from Bob.

NOTICE: In Case A), when Alice also accept a password authentication, mallory would configure his server to authenticate the client with password authentication and so mallory would get the username and password.

2.Yes, theoretically it would be possible.
See in A), why should Alice not accept the right signed ID from Bob? She would accept :) And also Alice would accept the right signed id from Bob. Mallory needs only to show Alice the Public Key from Bob on connection build up.


Lattice vs Level with regard to access control

Biba and Bell-LaPadula are generic models. One parameter of those generic models is a multi-level security policy.

A multi-level security policy is a pair (DOMS,≤) where (DOMS,≤) is a partially ordered set and DOMS is a set of security domains (this is what you refer to as level).

A lattice is a quadruple (L,≤,⊓,⊔) where (L,≤) is a partially ordered set, ⊓ is a least-upper-bound operator on (L,≤), and ⊔ is a greatest-lower-bound operator on (L,≤).

Not every multi-level security policy is a lattice, but there exist multi-level security policies that are lattices.

One could instantiate the Biba and Bell-LaPadula models with a multi-level security policy that is a lattice, but one does not need to.


How do I know if a Certificate Authority is not fake?

This CA is installed when installing the Packet Capture app from the play-store.

It's very likely that you've imported this Certificate yourself by installing the app somewhere in the past.

Further, there is no reason at all for Android to block any CA Certs based on the "weirdness" of a name. And it doesn't really make any sense to me why it should, as names can be chosen freely...


Actually you cannot really "remove the password from memory". Not nowadays.

In older times, memory allocation strategies in Java virtual machines were relatively simple; when a block was allocated, it was allocated once, and remained in memory, until the GC decided that it was no longer reachable and thus could be released. In that mode, allocation is similar to what C programmers call malloc(). For these JVM, the GC was conservative: it did not always reliably detect whether a given piece of data in memory was a pointer or something else (e.g. an integer or some characters), and thus assumed that everything which looked like a pointer had to be treated as such, for garbage collection purposes.

Since Java is a strictly typed language, it allowed the implementations of stricter GC who have strong knowledge of what is a pointer and what is not. This allows these GC to move objects in memory. From your side, in the Java source code, this is completely transparent. But internally, the GC may decide to move an object from one emplacement in RAM to another, automatically fixing all pointers to now point at the new copy of the object. Doing so enables a lot of optimizations which make that kind of GC quite desirable (better cache coherency, very fast allocation...). All JVM from the last decade use such better GC algorithms.

However, a consequence of these newer, enhanced GC is that old copies of objects may linger in RAM. When you "wipe" a char[], you are only writing to the latest in-memory copy of the array; remnants of older copies may still be there and contain your password, completely out of your reach since all of this is done transparently, invisible from the developer.

Therefore, the tradition of storing passwords in char[] and wiping them is just that: a Tradition. It used to be justified, in days from the previous century, when the JVM was using a conservative GC. At that time, wiping worked and was really removing secret data from memory. These days have finished. Programmer-driven wiping no longer works. So it makes no sense to make a difference between char[] and String; just use the String and be done with it.

If you believe in the importance of wiping, then the correct way to do it is to integrate the automatic wiping within the GC, systematically applied to all objects. I don't know if the current JVM from Oracle (or OpenJDK) offers an option for that.