I see no huge issue triggering an self-XSS since injecting content into an existing TCP connection is already difficult enough (thanks to initial sequence numbers).  And, even if an attacker would be able to inject valid TCP packets, he would be probably more interested into getting your session information directly to his IP, without going through XSS.

Things change a little, when the self-XSS is persistent.  i.e. it ends stored in the DB and can be re-run at a later stage.  In that case it is pretty much a full XSS, since you can, for example, give access to your account to other users who will run the XSS.  But not sanitizing data provided by a user that goes into the DB should be a crime.

Still, on the questions:

  While the true solution would be to automatically sanitize ip address before displaying it, i would like to know when should we really do it?

Not only the IP, but every piece of information provided by a user request.  And not only in specific cases but always.  If you do not sanitize every piece of information and send it back, or leave it in the DB and send it back later, you will have XSS problems.

  Is there any configurations where webservers automatically change the REMOTE_ADDR to the value of one of this headers?

Webservers don't do that (although some nginx hacking allowed me to perform it, but that would be a horrible practice).  Webservers pass variables to the CGI program/script.  Apache's mod_cgi pass things through environment variables and STDIN (for POST content).  Nginx controls the variables that are present in its configuration to go to the CGI through the scgi_params file (normally at /etc/nginx/scgi_params).

  How are those headers useful anyway?

See my rant-comment about akamai and True-Client-IP, i.e. X-Forwarded-For is the correct HTTP header.  X-Forwarded-For is meant for connections that go through some form of proxy (as opposed to going through a NAT).

  The only thing I'm seeing is when client pass by some proxy for un-obvious reason but still want the website to know his ip address. Is there any other?

And yes, that is the main and (not considering possible dirty hacks) only use for X-Forwarded-For.  That may seem not very useful but is much more common than you imagine.

Offices/datacentres often have huge proxy/firewalls to which their internal network pass through to the internet.  Some of the internal machines have private IPs and depend on a NAT but other do have their own public IPs and depend on the firewall as a proxy (the firewall must be stateful to be in any way effective).  This situation requires the use of 'X-Forwarded-For' to know from which part of the network a request comes.

Internet proxies (free and non-free) often use that header to ensure that you can visit websites that are tailored to your location.  e.g. connecting directly to google.com I get redirected to google.co.uk (since I live in the UK).  But if i use a proxy in Poland and do not set X-Forwarded-For I get redirected to google.com.pl.  If I use the proxy and set X-Forwarded-For to my home IP (in the UK) I get correctly redirected to google.co.uk.


Bank accepts different password to the one that I set

Sure there is, but this doesn't mean it is a good practice.

Probably your bank is chopping your password to eight chars (this limit was highly used in old systems). Your bank simply takes the first eight chars of the string, hash it and compare against their own hash. This is secure, at least, as secure as the length limit of its password.

There are more possibilities like they try every hash in the string with the first 4,5,6,7...N (where N is the length of the string the user entered) chars until they find a match, but I believe that my first guess is the good one =)

So you will have a log-in as secure as your first eight chars (or the amount they are using). If they simply use the second method (which I extremely doubt) the log-in will be as secure as your password length.

I won't enjoy my bank doing so but... Consider that they hold the responsibility if they got hack since your money is guaranteed by them (but you will have headaches).


That depends entirely on the file in question.

For example, if you want to enable users to just upload plain text files, then it may be enough to check if there are any unprintable characters in the file.

If you allow users to upload images, you have to make sure that the files are actually images. This is best done with tools like ImageMagick.

This list goes on and on, and depends exactly on what files you want to allow. If you want to allow arbitrary files, then you can't make any file type checks.

What not to do

Never go for file extensions, MIME type or naive magic numbers. File extensions can be changed trivially, even by less experienced users. MIME types can be evaded by any even moderately experienced attacker, just like magic numbers.


Is Chinese great firewall white or black list based?

The details are technically a secret, but there are a few things we know:

There are IP-based blacklist restrictions for popular sites like Facebook, and probably many other sites we don't hear about.
There are content filter-based restrictions placed globally. That is, if you mention a blacklisted word or phrase, you connection will be dropped, and reconnect attempts will fail for a short time (a second or two).

One thing worth noting about your site in particular is that approximately 400 other websites are using that same IP address.

http://whois.domaintools.com/94.23.151.19

If you're worried about being on a blacklist, I suggest getting a unique IP for the domain, so that you only have to worry about yourself being on the blacklist, rather than all of your neighbors as well.


Is it appropriate to use haveged as a source of entropy on virtual machines?

(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.)

To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse movements, incoming ethernet packets, time for a hard disk to complete a write request...). HAVEGE also claims to feed on all the types of cache misses which occur in a CPU (L1 cache, L2 cache, TLB, branch prediction...); the behaviour of these elements depends on what the CPU has been doing in the previous few thousands clock cycles, so there is potential for some "randomness". This hinges on the possibility to measure current time with great precision (not necessarily accuracy), which is where the rdtsc instruction comes into play. It returns the current contents of an internal counter which is incremented at each clock cycle, so it offers sub-nanosecond precision.

For a virtual machine system, there are three choices with regards to this instruction:

Let the instruction go to the hardware directly.
Trap the instruction and emulate it.
Disable the instruction altogether.

If the VM manager chooses the first solution, then rdtsc has all the needed precision, and should work as well as if it was on a physical machine, for the purpose of gathering entropy from hardware events. However, since this is a virtual machine, it is an application on the host system; it does not get the CPU all the time. From the point of view of the guest operating system using rdtsc, this looks as if its CPU was "stolen" occasionally: two successive rdtsc instructions, nominally separated by a single clock cycles, may report an increase of the counter by several millions. In short words, when rdtsc is simply applied on the hardware, then the guest OS can use it to detect the presence of an hypervisor.

The second solution is meant to make the emulation more "perfect" by maintaining a virtual per-VM cycle counter, which keeps track of the cycles really allocated to that VM. The upside is that rdtsc, from the point of view of the guest, will no longer exhibit the "stolen cycles" effect. The downside is that this emulation is performed through triggering and trapping a CPU exception, raising the cost of the rdtsc opcode from a few dozen clock cycles (it depends on the CPU brand; some execute rdtsc in less than 10 cycles, other use 60 or 70 cycles) to more than one thousand of cycles. If the guest tries to do a lot of rdtsc (as HAVEGE will be prone to do), then it will slow down to a crawl. Moreover, the exception handling code will disrupt the measure; instead of measuring the hardware event timing, the code will measure the execution time of the exception handler, which can conceivably lower the quality of the extracted randomness.

The third solution (disabling rdtsc) will simply prevent HAVEGE from returning good randomness. Since it internally uses a PRNG, the output may still fool statistical analysis tools, because there is a huge difference between "looking random" and "being unpredictable" (statistical analysis tools follow the "look random" path, but cryptographic security relies on unpredictability).

The VirtualBox manual claims that VirtualBox, by default, follows the first method (rdtsc is unconditionally allowed and applied on the hardware directly), but may be configured to apply the second solution (which you don't want, in this case).

To test what your VM does, you can try this small program (compile with gcc -W -Wall -O on Linux; the -O is important):

#include <stdio.h>

#if defined(__i386__)

static __inline__ unsigned long long rdtsc(void)
{
        unsigned long long int x;

        __asm__ __volatile__ (".byte 0x0f, 0x31" : "=A" (x));
        return x;
}

#elif defined(__x86_64__)

static __inline__ unsigned long long rdtsc(void)
{
        unsigned hi, lo;

        __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
        return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}

#endif

int
main(void)
{
        long i;
        unsigned long long d;

        d = 0;
        for (i = 0; i < 1000000; i ++) {
                unsigned long long b, e;

                b = rdtsc();
                e = rdtsc();
                d += e - b;
        }
        printf("average : %.3f\n", (double)d / 1000000.0);
        return 0;
}

On a non-virtual machine, with the "true" rdtsc, this shall report a value between 10 and 100, depending on the CPU brand. If the reported value is 0, or if the program crashes, then rdtsc is disabled. If the value is in the thousands, then rdtsc is emulated, which means that the entropy gathering may not work as well as expected.

Note that even getting a value between 10 and 100 is not a guarantee that rdtsc is not emulated, because the VM manager, while maintaining its virtual counter, may subtract from it the expected time needed for execution of the exception handler. Ultimately, you really need to have a good look at the manual and configuration of your VM manager.

Of course, the whole premise of HAVEGE is questionable. For any practical security, you need a few "real random" bits, no more than 200, which you use as seed in a cryptographically secure PRNG. The PRNG will produce gigabytes of pseudo-alea indistinguishable from true randomness, and that's good enough for all practical purposes.

Insisting on going back to the hardware for every bit looks like yet another outbreak of that flawed idea which sees entropy as a kind of gasoline, which you burn up when you look at it.


VPN - Tor: can VPN provider see the data?

Between your Tor client and the guard node, the communications are encrypted with three layers of AES128. The first layer is a key shared between you and the guard node. The second layer is a key shared between you and the middle node. The third layer is a key shared between you and the exit node. Each layer provides 2128 possible combinations of keys. Simple math dictates that 2128×3 equals 2131, so the three layers total up to the equivalent of 2131 possible keys.*
Assuming you are using Tor browser correctly so you are not leaking DNS, the VPN will only be able to see your IP, the IP of the guard node you are connecting to, and the encrypted communications between you and the guard. In order to break them, it would have to either brute force at most 2131 keys (on average half, or 2131/2 keys), or break the algorithm used to exchanged keys safely, called curve25519. This would require either a major breakthrough in mathematics, or a breakthrough in cryptoanalytic quantum computers. Neither seem likely to appear in the near future, and if they are, they are the kind of things which will be used by FVEY (NSA, GCHQ, etc), not by petty commercial VPN providers who want to snoop on your data.
To answer your literal question: no, the VPN cannot see your data. It only sees encrypted data between you and your guard node.
However, you should be aware that, while Tor is very secure, there are theoretical attacks against it which an actor between you and the guard node, or the guard node itself could pull off. Most of these are termed traffic analysis attacks, because, while they don't involve decrypting the data directly, they involve finding loopholes that end up discovering what the data is without actually finding the encryption key. Tor does have many defenses which makes this more difficult, far too many to name exhaustively, such as padding data into chunks of exactly 514 bytes (previously 512 bytes). However they are not perfect. It is very unlikely that your VPN will be able to pull any of these off, as they often require additional attacks against the entire Tor network.
* There's also a separate TLS connection between each node, which a VPN provider would also have to break.


Is it possible to find out the salt of a MD5 hash?

Given the hash output, one can always try to get lucky, and injecting random values until a match is found. In your example, any decent password cracker should try "helloworld" and "goodbyeworld" very quickly (like, within the first second of trying) because they are extremely classic password strings.

In a more general case: given a cryptographic hash function h, and the values h(m||x) and h(m'||x) for unknown values of m, m' and x, it is not feasible to recover m, m' or x except by being lucky in the sense of the previous paragraph (attacker tries exactly m||x as input). This holds for cryptographically secure hash function, and MD5, despite its weaknesses with regards to collisions (which are irrelevant here), is still "secure enough" for that.

(Of course, one must be aware that MD5 has no "salt", so any mention of MD5-with-a-salt really means "some custom, homemade, non-standard construction that involves MD5 and a value that the designer chooses to call 'a salt'". Generally speaking, homemade constructions shall be avoided.)


How do you find out if your PC is reverse shelled?

1.) Netstat -a: look for connections that are not familiar to you. If you are suspicious about one, do a dig and a whois lookup to see who they are.

2.) Check open ports on your machine and your router. Verify your port forwards if enabled. Hackers tend to use the same port especially if the tool was employed by a script kiddie.

3.) Run your AV of choice and do a deep scan.

4.) TronScript: This is a hell of a script that it open source and regarded to be very effective. It's updated frequently. This is the last thing you can do to get rid of any malware/issues before doing a full clean wipe and clean install of your OS of choice. TronScript has good logging and it will tell you directly what it is doing and when. Read more at the link I provided.


Is it necessary to encrypt an ASP.NET view state hidden field when using SSL certificate?

You have to distinguish two kinds of attackers:

SSL is used during transport to prevent a third person from reading and modifying the transmitted data.

The user who sends data to the server and  gets answers from the server, can obviously see and modify the data any way he or she wants. So the user can modify the hidden form field containing the view state. Base64 escaping does not offer any protection here, it is just a way to ensure that binary data is not messed up by character set conversations.

So in the likely case that your view state contains trustworthy information, that a malicious user must not modify, you need to enable encryption and signing for it.


What's stopping people from modifying cookies to change who they're logged in as?

So, suppose I'm storing a cookie of the user ID which is logged in.

That's not how session cookies work. The cookie shoudn't just contain the ID of the current user since that would obviously allow an attacker to tamper with the value.

Instead, a common approach is that the web application issues a sufficiently long, random session ID to the user and internally associates this session ID with the actual user account. Since a user is then assigned a new session ID after each login, it won't be feasible to predict the session IDs of other users or manipulate user-specific values by modifying the cookie.

Generally, you shouldn't have to invent your own session management scheme. If you think about how to store a user ID in a cookie, you're probably doing it wrong. Many frameworks already provide abstractions for cookie-based sessions. E.g., PHP has built-in support for session handling. Also have a look at the OWASP Session Management Cheat Sheet to learn about security considerations.


No, you do not have solid irrefutable evidence.  I could have stolen their password and sent the email from their account.

That being said, the key question you should ask yourself is how much proof do you need in the current environment.  If this is office politics, you may not need very much proof at all.  If you're trying to indite someone for selling state secrets, you're going to need a lot more proof.


What are proper security precautions when enabling multiple connected social accounts or login/authorization methods?

Bear in mind that when you enable third-party account authentication in your application it is because you're delegating Identification AND Authentication to that third-party, that you choose to trust.
For instance, if the user chooses to login to your application using a third party account, your application doesn't have to be aware when the user changes his password. Rather it's up to your application to keep the user loged in permanently or ask him for login again (using the third party account) each time he get access.


Are Meltdown and Spectre exploitable on 32-bit Linux platforms?

Any CPU that performs speculative execution is vulnerable to Spectre, so yes, 32-bit OSs are vulnerable.

Meltdown is an issue with how Intel CPUs enforce memory protection while performing speculative execution (in short, memory protection isn't enforced until the point at which speculative execution is turned into real execution).  32-bit OSs on Intel CPUs are vulnerable, but the heavier use of swap reduces the impact somewhat (Meltdown can only read physical memory; data that's been swapped out to disk is inaccessible).


In addition to using strong hash algorithms, what is a good "password requirement"?

Stanford University a month or so ago came out with a sort of sliding scale. It allowed complexity to decrease as length increases. This is basically just a probability function. An 8-character password needs high complexity, while a 20 character password needs little.

Mathematically (character set) ^ (Length)
95^8 < 52^12 < 20^26

This works great until you consider things like antidisestablishmentarianism which passes that above strength challenge swimmingly, but is in most good pentesters' password dictionaries. If you want protection from brute-forcing, come up with a target number (7 x 10^16) and an algorithm for calculating the number of possibilities and use that. Dictionary and rule-based attacks will still grab the low-hanging fruit.


What are modern protections against mobile application cloning

After some digging, I’ve found the answer to the question.
Essentially, the application needs to authenticate to the server. This means that there has to be a shared secret between the application and the server. However, the secret cannot be hard coded into the application, because it would be copied by cloning.
In Android and iOS, each application instance is given a unique ID. Verify this ID on the server side proves app authenticity. Source: https://developers.google.com/instance-id


Does every security patch get back ported to every .NET framework?  Are there exceptions to the rule?

If you visit http://support.microsoft.com/lifecycle/search/default.aspx?sort=pn&alpha=.net+framework you'll see Microsoft's support lifecycle for the .NET framework.

As you can see, many of the older versions are no longer supported, so Microsoft do not promise they will issue security patches for them, and you should no longer use them.


How does firefox sync password recovery work?

The specification says:

  Note that, since the forgotten-password client never learns kB, any class-B data will be lost.

NB: kB is the private key.

Here's how it works:

You generate a new password
A new private key "wrapped" with your new password
Your old data is lost

The developers of the protocol assumed that if you lost your password, you would still have a device with the data synced. Therefore your device would re-sync the data from scratch.

If you loose your devices AND your password, you're doomed.


Newer Self Encrypting Drives (SEDs) generally follow either the TCG OPAL or TCG Enterprise standards.  I've done a lot of digging on this issue and as best I can tell there is no specific method specified in the TCG standards for generating the DEK.

If you review the security policy documents that each manufacture submits to NIST to obtain FIPS 140-2 approval for their product it seems like they all use a DRBG that follows the SP 800-90A standard.  How they seed that DRBG though varies between manufactures.  Some use a NDRNG as you noted with the HGST.  Others like Seagate seem to have a seed that is set at the time of manufacture.  I've also seen some older Seagates that seem to indicate the user can set the DRBG seed with vendor proprietary commands.  The bottom line seems to be that the mechanism used for seeding the DRBG is vendor specific.


The generic tests for randomness are the "Diehard suite", but they don't ensure security. These are tests which detect biases in PRNG output. Security is about defeating intelligent attackers who know the internal details of the software you use and can think a lot; statistical tests are mindless automaton which just find the most blatant deviations from pure randomness. So if a statistical suite like the Diehard tests finds something weird with your RNG, then the PRNG is definitely bad; but if the tests find nothing, then you just don't know whether the PRNG is good or not.

A "black box" is the conceptual representation of a completely unknown algorithm. This does not occur often in practice; arguably, it never occurs. The algorithm implemented by a "black box" is always known or potentially known, if only by identifying the developer and raiding his drawers one night. That's more or less the idea behind Kerckhoffs's principle. Since the "ideal black box situation" does not occur in practice, there is no "commonly applied methodology". Or, if you prefer, the commonly applied methodology against black boxes is to open the box so that it ceases to be black.

A well-documented historical example is the cryptanalysis of the Enigma. The Polish cryptographers who broke the first military versions made a lot of guessing, but also knew the "commercial" versions from which the military Enigma was derived, and this helped them a lot. During the course of the War, considerable effort was devoted to the capture of actual machines and keys -- that's the "open the box" analogy, and it worked.


PGP uses hybrid encryption. That means that the public/private key system is not used to encrypt the whole message. It is only used to encrypt a symmetric key which is used to encrypt the actual message.

When you address a PGP message to multiple recipients, you only encrypt the message once with a newly created symmetric key, and then encrypt that symmetric key multiple times, once for each intended recipient. That way each recipient can decrypt their personal copy of the symmetric key and then use it to decrypt the message.

Your message would grossly oversimplified look like this:

Symmetric key encrypted with public key of user A
Symmetric key encrypted with public key of user B
Symmetric key encrypted with public key of user C
Symmetric key encrypted with public key of user D
Symmetric key encrypted with public key of user E
Message encrypted with symmetric key

By the way: Hybrid encryption is also used when you send a message to only one recipient. The reasons is that using a different symmetric key for each transmission prevents an eavesdropper from noticing when you write the same message to the same recipient twice. It is also better for performance, because most symmetric encryption algorithms are much faster than most asymmetric ones.


Difference between non-repudiation and plausible deniability

As in any other aspect of life, one might have different information security goals in different situations. There are situations in which you want non-repudiation and there are situations in which you would want plausible deniability. Likewise, there are situations in which you would want non-repudiation on some aspects but plausible deniability on others.

For example, let's say you've made a deal with someone and want to sign a contract with them. Such a contract would not be of much value if one of the sides of the contract could later deny signing it. Each of the sides to a contract wants non-repudiation on the other side's signature.

On the other hand, consider the case where you are a whistle-blower informing the authorities of some grave crime being committed by your employer and you're worried your employer may discover your leak. In this scenario you would want plausible deniability.


Quick, factor 1081.

Or if you prefer, answer this: what's 23 times 47?

Which one is easier? It's easier to perform a multiplication (just follow the rules mechanically) than to recover the operands given only the product. Multiplication. (This, by the way, is the foundation of some cryptographic algorithms such as RSA.)

Cryptographic hash functions have different mathematical foundations, but they have the same property: they're easy to compute going forward (calculate H(x) given x), but practically impossible to compute going backward (given y, calculate x such that H(x) = y). In fact, one of the signs of a good cryptographic hash function is that there is no better way to find x than trying them all and computing H(x) until you find a match.

Another important property of hash functions is that two different inputs have different hashes. So if H(x1) = H(x2), we can conclude that x1 = x2. Mathematically speaking, this is impossible — if the inputs are longer than the length of the hash, there have to be collisions. But with a good cryptographic hash function, there is no known way of finding a collision with all the computing resources in the world.

If you want to understand more about cryptographic hash functions, read this answer by Thomas Pornin. Go on, I'll wait.

Note that a hash function is not an encryption function. Encryption implies that you can decrypt (if you know the key). With a hash, there's no magical number that lets you go back.

The main recommended cryptographic hash functions are SHA-1 and the SHA-2 family (which comes in several output sizes, mainly SHA-256 and SHA-512). MD5 is an older one, now deprecated because it has known collisions. Ultimately, there is no mathematical proof that they are indeed good cryptographic hash functions, only a widespread belief because many professional cryptographers have spent years of their life trying, and failing, to break them.

Ok, that's one part of the story. Now a password hash is not directly a cryptographic hash function. A password hash function (PHF) takes two inputs: the password, and a salt. The salt is randomly generated when the user picks his password, and it is stored together with the hashed password PHF(password, salt).  (What matters is that two different accounts always have different salts, and randomly generating a sufficiently large salt is a good way to have this property with overwhelming probability.) When the user logs in again, the verification system reads the salt from the password database, computes PHF(password, salt), and verifies that the result is what is stored in the database.

The point of the salt is that if someone wants to crack a password, they'll have to know the hash before they can start, and they have to attack each account separately. The salt makes it impossible to perform a lot of cracking work in advance, e.g. by generating a rainbow table.

This answers (2) and (3) — the legitimate verifier and the attacker find out in the same way whether the password (entered by the user, or guessed by the attacker) is correct. A final point in the story: a good password hash function has an additional property, it must be slow. The legitimate server only needs to compute it once per login attempt, whereas an attacker has to compute it once per guess, so the slowness hurts the attacker more (which is necessary, because the attacker typically has more, specialized hardware).

If you ever need to hash passwords, don't invent your own method. Use one of the standard methods: scrypt, bcrypt or PBKDF2.


Advantages of using a Digital Signature Scheme (DSS) with Appendix instead of DSS giving Message Recovery

Ok, let's avoid confusing terminology, because "DSS" also means "digital signature standard" as in FIPS 186-3, which is not at all RSA.

RSA is a signature scheme "with recovery", meaning that there is a bit of room to embed some arbitrary data within the signature itself. The document you quote uses ISO 9796-2, which implements this kind of embedding. For instance, if you have a 2048-bit RSA key and used it with SHA-256 as hash function, then the signature has length 256 bytes, but you can reuse 222 bytes for your message, so the actual size overhead for the signature will be only 34 bytes. On the other hand, ECDSA (the elliptic curve signature scheme which your document alludes to) does not have the "recovery" feature, so while a robust ECDSA signature is shorter than a RSA signature of similar strength (e.g. about 64 bytes for something as good as RSA-2048), the actual size overhead is higher (i.e. 64 bytes). All of this depends on the key sizes and used hash functions; your mileage may vary.

Security of ISO 9796-2 is questionable (basically, you don't get your money worth from your hash function output size; you must use a hash function with a larger output to regain your security, increasing the size overhead). Also, ECDSA is computationally less expensive for signature generation, and that can be important for some low-power embedded devices. On the other hand, RSA is mathematically simpler, more widely used and supported (because it is quite older), and, depending on the parameters, may offer a slight size advantage.

Anything with elliptic curves is, of course, highly fashionable.


Brute forcing encryption password (self destruct after 4 attempts)

Have you tried any of the options that Lumension offers?

  Secure recovery of passwords, data and forensics

  Challenge/response over the phone with the help desk for recovery of
  forgotten passwords
  Local self-help to recover forgotten passwords during pre-boot without
  calling the help desk or the need for an Internet connection

From their brochure on the Disk Encryption feature for Endpoint Security

As there are no currently listed exploits to be found, your only options are:

Try the Above
Image and restore on the threshold over and over again

  Worst case scenario if I make a forensic image using EnCase will I at least be covered in the event that I make any terrible mistakes?

Best way to find out is to try:

Make the image, load it into the application, try a login attempt, try a login attempt on the other disk and see if the application has a way to identify the disk and link the counters and if you can use them safely apart from each other.

Find a 0-Day

You could also reverse engineer (debug) the application and see if there is a counter somewhere you can control/reset. Of course this would take some time, knowledge and would have to be tested extensively before trying on your actual target.

Honestly, if I were in the situation you say you are, I would just contact their Helpdesk and find out a way to get around this. It's version 4.6, they released 8 now. I say odds are in your favor.


Can I use tor browser to make myself anonomous?

Tor users can be traced through traffic analysis by people who can inspect traffic for both exit nodes and entry nodes: namely, they can correlate entry of a data packet at some entry node with subsequent exit of a packet of the same size (actually a bit smaller, because of encryption overhead) soon afterwards from an exit node. The spies, here, need to control either node; they just need to make passive observation of the traffic which enters and exits the node.

It is interesting to note that adding intermediate nodes does not help much against traffic analysis. The real source of the problem is that the user (that's you) is not patient: when he clicks on a link, he does not want to wait for five seconds before the page begins to show up, then another five seconds before the pictures and CSS are obtained and the page begins to visually make sense. If the user was patient, then the Tor nodes could add random delays on the packet propagation, to make traffic analysis substantially harder. But that's Web browsing, not emailing; latency is not tolerated.

Arguably, by simply asking a question on security.SE about how you could use Tor to become really anonymous, you have already awaken your arch-enemy (the NSA), who has added you on the list of "people to monitor". It might be a bit too late to "go anonymous".

(If I were a spy agency manager, I would instruct my troops to survey Web sites which discuss anonymizing tools like Tor, because my targets of interest would be interested in such tools. Assuming that a government agency like the NSA can collectively be as smart as me -- which might be a preposterous claim, because collective intelligence is known to drop quite fast when too many people are aggregated in the endeavour -- then I may surmise that the NSA already monitors this very site that we are presently using. Hi!)


How to classify DNS packets coming to clients as spoofed or not?

It's probably impossible to look at a single DNS packet and know if it is spoofed or not. But, if this is a DNS reply packet to a system without a matching DNS request a short time before than this is probably spoofing. And if there is a DNS request originating from the machine but the incoming DNS reply does answer the DNS query but does not match in the DNS request in port and id than this is probably a spoofing attempt too, especially if there are lots of these mismatching packets.


Confidentiality and integrity are aspects of information security.
User permissions and privileges are security mechanisms that can be used to achieve them. So the answer to your first question, "should user permissions and privileges be considered as a part of confidentiality or integrity," is
No.

You can categorize accountability, authenticity and non-repudiation as sub-characteristics of integrity if you like to but that is largely a linguistic question. It does not have any practical consequences.


There are online attacks and offline attacks.

Online attacks are when the attacker tries each password by sending it to the attacked system. The attacked system might be using, for instance, an HTML login page; in that case, the attacker would first manually obtain a copy of the login page (like any other user, with a Web browser), then look at the HTML, and infer the format of data that is sent to the server. Most login pages are simply HTML Forms; when a user enters the login and password and clicks on the "log me in" button, the browser sends an HTTP request which encodes the data entered by the user. The attacker then just has to build, with some custom code, synthetic HTTP requests which use the same format.

As for how often the attacker will try... well, it depends. On one hand, the attacker has a lot of passwords to try, so he will send many requests, include a lot in parallel because the server itself can handle several incoming requests simultaneously, and will process more requests per second when used in parallel than if the client (the attacker) waited for an answer before sending his next request. Parallelism absorbs latency, in a way.

On the other hand, some sysadmins include detection systems for "suspicious activity" and receiving 100 login attempts for a given user login per second surely looks unnatural. Therefore, some attackers will try the low-profile thing, trying only one password at a time, and waiting several minutes between any two attempts. The attacker tries to stay under the radar. This can still be an efficient strategy for the attacker, if he has lots of user logins to try on lots of distinct servers.

Offline attacks are very different. In an offline attack, the attacker was lucky enough to obtain enough information to "test passwords at home". For instance, through some SQL injection attack, the attacker grabbed a copy of the hashed passwords for a thousand users of a given site. The attacker can then proceed to "try" passwords by hashing each potential password and seeing if the hashed version matches the database table that he previously purloined. All of this occurs on the attacker's PC, with no network at all, and nobody else is made aware of the cracking effort.

Offline attacks are a bigger worry than online attacks because in an offline attack, attackers are limited only by their available computing power; there is no honest server who can arbitrarily limit the rate at which passwords can be tried. With simple hashing functions, attackers can try billions of passwords per second, with off-the-shelf consumer hardware (a PC with a big, gaming-class GPU). There are mitigation measures but they are not perfect (they are relatively expensive trade-offs). It is much better to avoid offline attacks in the first place (i.e. check your SQL statements, dammit !).


API Security - Mutual TLS vs TLS with shared secret .

Both can be secure, so potential attacks are not the main thing here.

The differences are in identity- and key management.

With PSK (pre-shared key) you just get a key ID for the client, not a certificate with X.500 attributes such as common name. So to identify the identity you need to link already known information to the key ID.

With PSK you share a secret key between client and server. But if there are multiple clients or multiple servers then you need to share keys between a lot of entities. With certificates - or rather, the public key infrastructure (PKI or PKIX) created using certificates - you just need to have one secret (or rather private) key per entity. The public key can be trusted if it is part of a certificate in a certificate chain, so the public keys don't need to be distributed either.

As you've already indicated there are a lot of other key management options for certificates.

One disadvantage of using certs is that the server cert is usually required to include the server name, and the connection may not be established on differently named hosts.

For business to business I'd certainly go for the client / server authentication using certificates. This is the most common and most flexible option. Be sure to trust only those certificates that you require (and not all certificates that are trusted by a default trust store).


Yubikey with KeePass using challenge-response vs OATH-HOTP

depending how how the plugin does it internally this can be quite an intresting way of adding security.

essentially this thing misuses HOTP big time, by calculating the next however-many OTPs needed and forms them together with the master pass to encrypt the database.

but of course when you have lookahead active (and you really should, especially on a nano) it generates a few more sequences of keys in case you incresed the counter accidentially.

The idea behind it isnt bad, although obviously keepass needs to store the seed (shared secret) in the database to allow for re-encrypting it.

the keechallenge plugin works on the same premise: hashing a shared secret with some kind of challenge (the counter in HOTP), but this plugin is actually safer from a few standpoints.

1) it provides a 160 bit output of HMAC-SHA1 instead of "just" of log2(10^(6*x)) bits (x is the number of consecutive OTPs you select, 8 consecutive OTPs would you get just to 159 and a half bits of length)

Simply saying, you need to tap MUCH less for the same security Level, and while the OTP plugin could probably be configured to use a ton of OTPs for even higher security, with modifications the Challenge-Response plugin could also run multiple challenges throwing the number of bits through the roof, with again just an eighth of the needed taps (and no concern of mis-tapping and not getting the proper sequence).

2) as the challenge is provided from the database, we dont need to worry about accidentially touching the key or lookaheads, which means we dont need to lower the security by allowing multiple second factor solutions to get in.

Simply said number 2 means the Yubi only has the Secret and the DB has what could be called the "state" of the challenge, while in TOTP, the Yubi has both the state and the secret needed to decrypt the DB and the state changes everytime you touch the key, meaning you would need to account for multiple states.

although obviously the shared secret still needs to be stored in one way or another inside the database (unless you don't change the challenge at all, but that's reckless).


Content Security Policy applied to Single Page Applications: Is it worth it with unsafe-inline?

does applying 'unsafe-inline' render CSP more or less pointless?

Preventing XSS is one of the main benefits of a CSP. If you need to allow inline scripts, that benefit is mostly gone.

But there are still some situations where a CSP can prevent exploitation of issues. Examples:

Clickjacking: a CSP can prevent it
HTML injection: Even if no XSS can be gained, HTML injections can be used to exfiltrate data. A CSP may be able to mitigate some of the impact (by restricting form actions, images sources, etc)
CSS injection: If you don't have inline CSS, you can prevent CSS injection via CSP
even with unsafe-inline, a CSP may make XSS more difficult to exploit. The easiest way to exploit XSS is to include a remote script, as an attacker doesn't have to worry about length or special character restrictions in the payload
enforce content to be loaded via HTTPS

  Does anyone have any good ideas of how to handle CSP on an SPA?

The same way as with any application: Don't have inline scripts. Instead, you should have all your scripts in .js files, which you then include from a trusted origin (this actually seems easier to achieve in a SPA compared to a classic application which may have inline JavaScript all over the place).

You can also allow a specific script block using a nonce or hash source (which implemented correctly prevents XSS).

Even if you need to allow unsafe-inline for now, I'd still recommend implementing a CSP which is as restrictive as possible given the situation.

It will help you implement future features in a way compatible with a restrictive CSP. And when you get around to removing inline js, you just need to remove unsafe-inline from the CSP that you have in place already (instead of having multiple issues to worry about implementing a new CSP).


Creating a domain admin account from NT\System access

# WINDOWS: Add domain user and put them in Domain Admins group
net user username password /ADD /DOMAIN
net group "Domain Admins" username /ADD /DOMAIN

# WINDOWS: Add local user and put them local Administrators group
net user username password /ADD
net localgroup Administrators username /ADD


If you do a DDoS by sending large amounts of traffic to that site, you're very likely creating a lot of collateral damage since other services in (parts of) the network will suffer as well if the network is saturated.

Also, very often phishers use hacked websites (for example poorly managed and outdaged Wordpress installs) to host their phishing sites, so you're not just attacking the phisher, but also a (mostly) innocent victim of that phisher.

And as others pointed out, just as in 'the real world' (which this is just as much a part of), you shouldn't take matters into your own hands.

The right thing to do, is either complain to the owner of the site or the network hosting it, or report it to the website being phished. Especially banks often have dedicated teams (or hire companies) which are specialised in taking down phishing sites.

In addition: you must consider that, when you are DDoS'ing a website, you're not attacking the web "per se" but the whole server, so you're causing the damage to the webhosting server (that may propagate among other websites hosted in the same server).

Finally: Most laws in most countries consider illegal to send any cyber-attack, it does not matter if it is against a legal or illegal target.


How can I ensure that Dropbox is using only its folder?

Create a new user.
Give that user access rights to only the folders you want to share. You can use the File and Folder Permission options on Windows, and simple chmod on Linux.
Run your application (Dropbox, for example) under that user. You can use runas on Windows, and sudo -u on Linux.

Please note that you might have to allow access to other folders where Dropbox keeps its cache files and configurations.


Attack on old OpenSSL/Debian vulnerability doesn't work on a vulnerable box

The "weak key" means that you can have a copy of the server's private key. This allows you to run a fake server and possibly do a Man-in-the-Middle attack on an authorized client, when he connects to the server. However, this does not allow you to log in "by yourself".

When using a public/private key pair with a client, you are sending that public key to the server and the server will authorize entry, or not, depending on whether that public key is in the $HOME/.ssh/authorized_keys of the target account. Here, you are sending as "client's key" a copy of the server's own public key, which is not authorized for client authentication, hence the result.

Not accepting his own key as correct authentication for a client is nothing special in SSH; client keys and server keys live in separate worlds. The server is not aware that you are trying to feed it with its own key; for the server, this is just "a public key which is not in the target authorized_keys file".

The box is still vulnerable; but there are other kinds of vulnerability than allowing connections out of the blue. MitM attacks are harder to put in action (you have to intercept an honest client's connection, usually with some variant on DNS poisoning) but are nonetheless very serious.


The guy was trying to get access to your WiFi.
He deauthenticated your device and sent you a phishing page asking you to login again. That's common thing... Keep your Wi-Fi mac filtered or hide your ssid


How to really treat security between peers in WebRTC

Technically, encryption always have a performance impact, in todays machines it's negligible.  For best outcome, you could perform the following:

Get the RSA public key of the server side.
Create a symmetric AES key, encrypt it with the RSA public key and send it to the server; the server decrypts it and you have a 'pre shared secret' then.
Encrypt your data with the symmetric key, and decrypt it on the server.

Not to re-invent the wheel, but if you have browsers such as Opera, Chrome or FF, you could use Datagram Transport Layer Security or ZRTP.

In essence, WebRTC creates a new communication channel, and encryption is up to you.  What you encrypt (offer, answer, ...) is basically based on how sensitive the information is, but once a channel is setup (i.e: the AES key is shared), you may as well encrypt everything; again - you'll have a minimal performance impact on modern systems.


As of the latest information, the main problem with Truecrypt right now is that it is no longer supported and maintained. This is of significant importance as we expect the phase 2 audit report from iSec because it means that if serious flaws are found in the encryption used or the implementation of it, then those flaws will not be fixed by the developers. Further issues are created because TC is developed by two semi-anonymous (source in Russian) developers and its unique license prevents it from being open-source. However, until that report shows that flaws exist in the program, it can be argued that it is "safe enough" to use depending on the threats you are faced with in your situation. Essentially, it is no less safe today than it was two or three days ago to most users, although you should not take my word for that as I am by no means a security professional.

Yesterday, when the news was broken, there was initially a lot of speculation regarding the possibilities of what has happened. Theories ranged from the developers simply giving up, to TC being served with an NSL. The anonymity combined with the lack of clarification from the developers and amateurish method of informing their users created a lot of unnecessary speculation.

The Swiss website seems to be a genuine effort to eventually create a fork of the Truecrypt code and to create a new project with a new name.

So to give a rundown of your questions:

  So, what is really happening?

The developers seem to have lost interest in the project and they seem to believe that only they have the required knowledge and familiarity with the code, any fork deriving from the TC codebase will be potentially harmful.

  What are these security issues in TrueCrypt?

As of right now, the Phase 1 report of the iSec audit found 11 issues in the assessed areas of the code and documentation. The most serious of those being a weak volume header key derivation algorithm. To quote the official report:

  Exploit Scenario: An attacker captures an encrypted TrueCrypt volume and performs an offline brute force and/or dictionary attack to
  identify the key used to encrypt the Volume Header. They use the
  recovered key to decrypt the volume.

  What kind of security risks can be expected if we are keep using it?

If you do keep using it, you should keep in mind that the software is no longer supported. This is significant considering iSec's report on phase 2 of the TC audit was scheduled to be completed. Of course, it is uncertain whether that report will be released or even finished now that TC has essentially shut down. As with any piece of software that is no longer supported, if new issues arise, they will not be fixed. My suggestion for a home-user (such as myself) who faces very weak threats would be to continue using TC version 7.1 until someone picks up the project or a clear successor comes forward. Making rash decisions due to the sense of urgency created with the recent situation is unlikely to produce good results.

I hope this gives a decent overview of what happened. I might update this as new information surfaces.


Are positional parameters vulnerable to command injection?

I see three layers of interpretation where there might be some sort of injection vulnerability.
(EDIT: immediately after posting this, I realized that since you're working with domain names, you could just validate the inputs in C before any of this, and make the whole thing moot. The allowed characters in domain names -- plain-ASCII letters and digits, dash (but not as the first character), and period -- are restrictive enough that you'd completely block all of these injection opportunities.)
Layer 1: There might be a command injection vulnerability in how you pass the arguments to posix_spawn. Fortunately, it sounds like you don't use it the vulnerable way, but I'll discuss it for completeness.
If you construct a command string (that includes untrusted data) like sh script.sh "<untrusted data here>" "<more untrusted data>", and pass that via posix_spawn to a shell for interpretation, something like this:
char *argv[] = {"sh", "-c", cmdStringWithUntrustedData, NULL};
status = posix_spawn(&pid, "/bin/sh", NULL, NULL, argv, environ);

...then you're almost certainly vulnerable to command injection. There are ways to safely quote/escape untrusted data for inclusion in a command string, but it's tricky to get right and you're better off avoiding it.
(BTW, my C is pretty rusty; please ignore any errors.)
The safe way to do this is to avoid the extra level of shell interpretation, and pass the arguments (as separate strings) directly to the shell that'll be running the script:
char *argv[] = {"sh", "script.sh", untrustedData1, untrustedData2, NULL};
                 /* ^^^ note the lack of "-c" */
status = posix_spawn(&pid, "/bin/sh", NULL, NULL, argv, environ);

Since the script has a shebang, if it's also executable you could also safely execute it directly, without specifying a shell:
char *argv[] = {"script.sh", untrustedData1, untrustedData2, NULL};
status = posix_spawn(&pid, "/path/to/script.sh", NULL, NULL, argv, environ);

With these methods, the untrusted strings are passed to the script without any interpretation, so they're safe from injection problems (at least until the script starts using them).
Layer 2: There's an injection vulnerability when the script uses the arguments. If parameter/variable/etc references are not enclosed in double-quotes, then values are subject to word splitting (basically, being broken up into separate strings on whitespace) and filename wildcard expansion. This isn't strictly a command injection, but it does open up a variety of opportunities for an attacker to trigger unexpected argument interpretation, do filesystem enumeration, etc. So replace this:
dig +noall +answer TXT $2._domainkey.$1

with this:
dig +noall +answer TXT "$2._domainkey.$1"

Note that the ._domainkey. part could be double-quoted (as above) or not (as in "$2"._domainkey."$1") -- since it doesn't contain any special characters, it doesn't matter. Also, you might think that an attacker could escape from the double-quotes by e.g. including a double-quote in the argument, but that's not the case; when a parameter or variable reference occurs inside double-quotes, it's expanded and then no further processing is done on the expanded value. So no quote/escape/etc trickery is possible here.
BTW, there are some contexts where it's safe to leave off the double-quotes, but IMO it's easiest and safest to just always double-quote them.
Layer 3: There's an option injection vulnerability with the dig command's interpretation of its arguments. Most commands treat arguments that start with "-" as options (/flags) rather than normal arguments; dig also treats arguments that start with "+" as query options, and those that start with "@" as a servername to query. Double-quotes have no effect on this, so when an argument starts with untrusted data, you need to be careful that this doesn't create a vulnerability.
In the case of dig, I don't see any obvious way to do anything really nasty here, but it's best to sanitize your inputs anyway. You can do this for each parameter with a case statement. Here's an example that restricts them to valid domain name characters:
case "$1" in
    [-+@]* )    # Forbidden as first character
        # Maybe log/report that someone's trying option injection?
        exit 1 ;;
    *[!-.A-Za-z0-9]* )    # Only allowed chars at *any* position
        # maybe report/log an error here?
        exit 1 ;;
esac

case "$2" in
    [-+@]* )    # Forbidden as first character
        # Maybe log/report that someone's trying option injection?
        exit 1 ;;
    *[!-.A-Za-z0-9]* )    # Only allowed chars at *any* position
        # maybe report/log an error here?
        exit 1 ;;
esac

If you wanted to be really picky, you could disallow ".-" in the middle of a domain string, since "-" is forbidden at the beginning of a domain label (but I don't think that's relevant for security). Also, if you can count on bash, and not some other shell, you could use its regex-matching feature instead of glob patterns in a case statement. But you're using a /bin/sh shebang, so that's not safe.


It's trying to see if that page is vulnerable to sql injection. It uses id=-1 to make the original query return no results so the union is executed (since usually only the first record is fetched). If the union is executed, the attacker will find 'loginpwnz' in the returned page (the hex is to avoid using quotes, which might be escaped).

Since the union select must return the same exact number of columns, the attacker is probably trying from 1 to n columns.


Certification in secure software development?

If you are looking for training/certification of individuals for secure coding, SANS.org is a good resource. Their training is very good and the certifications are well respected.
https://www.sans.org/curricula/secure-software-development

If you are looking for a security benchmark certification for software products produced by a company, the CIS Security Software Vendor Membership is a good program:
https://benchmarks.cisecurity.org/membership/certified/overview/


Why does the JWT Wordpress plugin recommend storing the token in a cookie/localstorage?

Your session/auth tokens will always be exposed to some level of risk when stored on the client machine... for example, if you have physical access to the person's browser and they are logged into a service, you could use browser developer tools to view all their cookies and local storage key/value content.

HTTP-Only Cookies and Local Storage are not inherently insecure, but can be vulnerable if there is some other exploitable functionality on your website.

So there's some things you can do to mitigate the risk...

Short-Lived Tokens

Short-lived session tokens will help to mitigate risk inherent from stolen tokens by reducing the time an attacker has to take advantage of the stolen token. The less time they can exploit a stolen token, the better.

XSS

To protect your token from Cross-Site Scripting (XSS) as a cookie, set the cookie to HTTP-Only, so that the browser won't allow JavaScript to read the cookie. This is a property set on the cookie header itself.

XSS attacks are a little trickier with local storage. Both local storage and cookies are protected by allowing only access to code loaded from the same domain. So if the script injection originates from code loaded on the same domain the local storage value originates on, then it may be vulnerable.

You can help protect cookies and local storage by carefully managing where functional code and user-generated content load from, but this is a rather advanced technique. It takes some careful consideration.

CSRF

Cross-Site Request Forgery (CSRF) attacks should not expose local storage values, but can expose content that is protected by cookie values.

CSRF works by loading content from your domain, on an attacker's page. With your website properly configured, Cross-Origin Resource Sharing (CORS) will help protect content/actions that are typically at-risk of exploit by CSRF. CORS is not fool-proof, though. So it's usually better to use a stronger mitigation like a CSRF token.


Which smartfone OS/vendor is the safes when it comes to exploits?

The answers given in this earlier question might perhaps be of some help to you?

Mobile Phone security - help finding security/privacy review/discussion

In addition to Ubuntu Phone, as stated in an answer to that question, there is also Sailfish OS, but, unfortunately, both have a very small market share, and hence few apps, and hence a small market share..


Some experimenting shows that double quotes signify 2 conditions comparing both against the value of the field named insertname and against the value insertname. So unlike the use of single quotes, manipulating the condition into WHERE name="name" will yield all rows, potentially allowing to bypass checks such as authentication.


Is it normal to receive working SMS verification code from strange number?

Yes. The use of SMS for 2FA is very price sensitive (it's a commodity market racing to the bottom). The use and registration of alphanumeric sender ids (like "UBER") costs money and time (you have to get the contracts). But if one just wants the content delivered to the handsets, one uses the lowest bidder for delivery who will in the end use some numbers (can be even throw-away burner phones) as the last hop to deliver the SMS to the handset.

The scrambling of the content can also be intentional: Of course the telcos want the customers to use their pricey services, so the try to detect and block traffic from cheap numbers. One way to get around theses blocks is subtly altering the content.

I work at an SMS aggregator who develops 2FA, delivers SMS for 2FA, uses SMS routes, and has heard of content scrambling.


I believe my Domain has been hijacked I am not receiving in sales in shopping cart

We had something similar two years ago. Someone hijacked our DNS account at our domain hosting provider. They changed the email DNS for one domain, the one linked to our main Amazon account. We had two-factor authorization, but they convinced Amazon to disable this - probably they had the last digits of our credit card but we are not sure how this happened and Amazon didn't tell us about this. Then they had control over our Amazon account, and they could start and stop instances.

We had two parties involved: the DNS host and Amazon. The DNS host denied that they were hacked, but they helped us actively in blocking all DNS changes to our domains. For some reason Amazon could not throw out the logged in users, so it was a constant battle between us and them to undo their actions. After one day they were automatically logged out and could not login anymore.

For you it's about getting control back over DNS, and with that your DNS hosting provider should help you actively, and they should block any changes to your account for a while without phone contact or something.


Active Directory Pentesting Methodologies

In most scenarios, Windows Server Forest targets, are hardened quite well, but usually because of the existence of an EDR and/or NIPS that prevents initial entry access.

The whole concept of Active Directory testing, as you say it, is to expand access * after * that initial entry point, or foothold, is proven.

The book, Mastering Kali Linux for Advanced Penetration Testing, 3rd Edition, is one great resource on what you ask for -- hone into its chapter called Action on the Objective and Lateral Movement.

The Hacker Playbook 3: Practical Guide to Penetration Testing, Red Team Edition -- is also a great resource for some baseline techniques along with demonstrations on how or where to evolve them.

You'll find that any-given cybersecurity conference has a few training courses that specifically teach Active Directory testing or some variation (or even a subset, e.g., there was even a class just on mimikatz and nothing else). A lot of these courses have their own methodology, but the methods are always the same: gain access, keep access, and expand access.

In order to gain access, you'll require a carefully-planned Pre-ATT&CK scenario with a series (or chain) of tactics, each backed up by one or more underlying techniques. Since I'm sure this is not what you're asking about, I'll move on.

In order to maintain access, you will need that Pre-ATT&CK scenario to stand the test of time, and if it uses reverse-https/etc payloads that connect to your remote handlers, then all of that will need not to stand out. Of course some scenarios could position C2 inside the network, over say, ARP daemons, or MS-RPC Named Pipes, or any sort of covert channel. However, others just hide in plain sight, such as Domain Fronting or BC-SECURITY's Empire fork, where evasions such as ones for JA3/S (a popular detector in 2019), are available.

A lot of times this involves finding computers (i.e., AD Computer Objects) that are not in Sites (an AD concept) because they also may lack a full EDR stack or have other exceptions. The IT and Cybersecurity staff don't seem to know the computer is there and that AV or basics aren't installed or properly-working. Look for overlaps in Windows Server Domains and Forests as well. You have to explore or know the target environment(s).

The book, Advanced Infrastructure Penetration Testing, has an entire chapter dedicated to Active Directory Exploitation. The section on SPN Scanning is unique in that it simplifies much internal AD recon with one PowerShell command: setspn -Q */*. You might not get this data in this exact way (because it might set off a detection right away -- or even much later it could be discovered during a hunting op), but you are going to need to know how to parse and understand it. SPN data is an Active Directory targeting goldmine.

Low-hanging fruit in an Active Directory are usually the SharePoint accounts even when you're not targeting the SharePoint sites (sometimes SharePoint has been replaced but the legacy accounts remain!). This is where techniques surrounding the BloodHound tool can come into focus.

Even better are lone or anomalous installs of IIS found via SPN or some other means. Any means of landing a payload to an IIS server could reveal apppools leading to hidden pivots via creds that are usually otherwise-undiscovered. A command to do this (as well as working with apppools in general) can be found in the book, Internet Information Services (IIS) 7.0 Administrator’s Pocket Consultant in the section on Working with Application Pools: [drive:]\windows\system32\inetsrv\appcmd list apppool <AppPoolName> /text:*

MS-SQL Server services are also found in SPN, and the services that are tied to them (e.g., SAP ECC) may also be visible. I recall PowerUpSQL and PowerSAP pentest tools, but there are hundreds of these projects when 2 years ago there were only ten or so. I think you're starting to understand that the reason there isn't a one-size fits all Active Directory pen test (or an easy-to follow flowchart) is because it's all dependent on the target environment(s).

Play around with the PowerShell modules specific to administration of each of these Microsoft Server Forest Services, like those apppools above, but often closer to the implementation. For example, Get-Webconfig and Get-ApplicationHost, but there are countless others. MS Exchange Server has a lot of these, be careful, though! It's also possible to look for the tools that come with these services, for example Exchange Admin Center has GUI tools but it also has a web portal (try IP addresses and the /ecp URI to find them).

There are also some point tools I could be missing and that are worth mention, such as Vibe. There are really lots of ways to skin this cat. An army of cybersecurity pros would never run out of ideas. Azure AD will change things but will probably open new doors. Just keep testing it and get the value that you want out of it.


How can the ISP block Sarawak Report even if I am entering Sarawak Report from google search?

If you click on the link of a search result you simply get a redirect from google to this site, i.e. your browser is still accessing the site by its own directly and not through the servers of the search engine.

If you don't want to get this you would need to try the cached version of the site, which is sometimes offered within the search results. This cached result is then served from the search engine itself, although it might include the images on this site in a direct way again.


The site does only provide a rainbow table (a lookup of the possible text from the hash).

So it is simple a database with all hashes saved (so far because a user has entered the text for the searched hash before).

If you enter a hash value (e.g. 3d24c2171cac6da8435ff671c8408189688101be2581d20870a2cb508870048afec15eecd7ed8c406d4d86da746c8caf66db75d9060543dd5d29faca95819707) that was not hashed by them then the following error message appears:

Results not found in DB or your request exceed execution time. Anyways - please try again later.

Also they clearly state that they only provide a rainbow table:

"Decryption of hash (unsolted) is impossible, but we offer reverse decryption via our database (~245M records, and counting)."


Automatically finding and fetching signature paths from own key to target

Missing Semantics

There are different problems with finding such signature paths. One is the semantics of such a path, signatures of other keys should never be taken into account without the trust into that user considered. Of course, there might be use of such a path anyway, I use the PGP patfinder you mentioned from time to time to derive trust paths, fetching the appropriate keys and issuing trust as I see fit.

Technical Reasons

There's also a technical reason this is not implemented in GnuPG: finding those paths requires knowledge on all keys. GnuPG is not really able to handle those millions of keys. and both fetching and keeping them current will require quite some effort. The PGP pathfinder uses a daily key server dump and performs some preparation work (mostly extracts the underlying network, to speed up queries) to tackle this. This dump is multiple gigabytes in size!

Running Your Own Signature Path Finder

wotsap is a project providing similar analysis, and made the sources available, given you find a current source for the .wot files (providing the network data). Alternatively, you can calculate them from a key server dump on your own using the tools provided by wotsap.


It's not possible to stop Windows local admins from accessing SQL server - see https://dba.stackexchange.com/questions/34684/restrict-access-for-windows-administrator.

By default, users who are not local admins will not be able access SQL Server with Windows Authentication. So the solution for you is to ensure your users are not local admins.


2-Factor Authentication vs Security Questions

Are there others I am missing?

The one-time password has more entropy than dog's name and is less vulnerable to enumeration/dictionary attacks.

On a phishing site, it is fairly easy to display some trivial personal question (e.g. what is your dog's name).  The phishing site doesn't need to know the answer.  On the other hand it is pretty difficult to spoof a one-time password sent to your phone, since the phisher won't know your number.

  putting an iron gate out front and leaving the back door unlocked?

Maybe a little bit.  Probably not a concern if the cookie has sufficient entropy, i.e. is hard enough to guess.  If the hacker has some means of actually getting the cookie-- e.g. has physical access to the computer-- you're screwed anyway.

  when I clear my cookies, they still "recognize" my device

There are a couple possible explanations for this.

One explanation, as you have noticed, is IP address, although this wouldn't work very well for mobile devices or certain ISPs (IPv4 addresses do change from time to time).

Another explanation is that the cookie is backed up by a different token, e.g. a Flash token, which is not cleared when you clear cookies.

A third explanation is that they are not really checking whether they "know" your computer.  Instead they are performing a risk-bases analysis of your browser's fingerprint, cookies, IP address, etc. and deriving a score.  You get prompted for the MFA if your score isn't good enough.  A lack of cookie doesn't necessarily trigger it.


You shouldn't be worried. 4.2 Bluetooth devices use Long Term Key to encrypt the data trasmission between them. The generation of Long Term Key are based on Diffie-Hellman. The generation of that key occurs after devices exchange public key and pair.


Sign PKCS#7 and verify PKCS#7 signature with OpenSSL

TLDR: It's not actually signed. You do understand wrongly. To explain I'll start from the beginning.

PKCS#7, and its slightly modified and enhanced IETFized[1] form CMS Cryptographic Message Syntax http://tools.ietf.org/html/rfc3852 et pred et amici, is a standard that defines a whole series of different but similar messages for various cryptographic functions. One type of PKCS#7/CMS message is called SignedData and its original purpose, as you might reasonably guess, is to convey data with a digital signature, or for generality one or more signatures, for example a contract signed by both parties. PKCS#7 (mostly) uses public-key cryptography and needs/expects a way to properly match public-key values to entities like people and organizations and systems, called a PKI Public Key Intrastructure; in practice the PKI we use is X.509 Certificates issued by CAs Certificate Authorities which can revoke bad certificates using CRLs Certificate Revocation Lists (and nowadays also using OCSP, but that came after PKCS#7).

A SignedData actually consists of three main parts: the actual data in a structure named ContentInfo; a variable number of SignerInfo structures each containing one signature and some metadata including an identification of the certificate containing the public-key needed to verify the signature; and a variable number (maybe none) of certificates and/or CRLs that the recipient may need to determine and verify the (signing) public-keys or for any purpose. For generality the number of SignerInfo's, and thus signatures, may be zero, in which case the data is useless and is omitted.

Thus a SignedData with no data and no "signers" (zero SignerInfo structures), only certificates and/or CRLs, provided a standardized format to contain several related certificates and/or CRLs, at an early date when there was no other good standardized method for this. As a result it was widely adopted and became ubiquitous. This format is commonly identified by the extensions "p7b" and "p7c". See What's the difference between X.509 and PKCS#7 Certificate?  .

So as to your questions: this format is a PKCS#7 or CMS structure of the type named SignedData, but it does not actually contain data or signature(s) on that data, it contains only certificates and/or CRLs. Because it isn't signed, it can't itself be verified.

Each certificate or CRL in itself is signed, using a signature specific to the cert/CRL format not a general data signature. This is independent of whether it is in a p7b or separate. Each (nonroot) cert or CRL after you extract it can be verified, if you have a valid chain of certs "above" it, and should be if you use it for anything. However all PKI signatures only propagate trust from a (usually small) set of trusted "roots" or "anchors" (such as Verisign, GoDaddy, etc but hopefully not DigiNotar) to an unboundedly large set of other entities (HTTPS or other SSL/TLS servers on the net, email senders in the world, program developers in the world, etc). Ultimately you decide what anchors to trust, or delegate that decision to someone (like Microsoft for Windows, Oracle for Java, Mozilla for Firefox, etc).

In OpenSSL all (AFAICS) operations that use certificates, and (optionally) CRLs, verify them, against a truststore of CA (root) certs that you can choose or default. You can also manually (re)verify a cert with the commandline verify utility; see https://www.openssl.org/docs/apps/verify.html . Other tools and programs will do something equivalent, but details vary some.

[1] for comparison, the Netscape protocol SSL Secure Sockets Layer was turned over to IETF where it was slightly modified and enhanced and renamed TLS Transport Layer Security. Although there are technical differences that do matter sometimes (like the recent POODLE vulnerability that affects SSL but is fixed in TLS, at least in correct implementations), for the most part SSL and TLS are functionally the same and people often just say SSL to mean both. Similarly PKCS#7 and CMS are so similar many people use either name for both.

Update 2/06 per comment: If you send a valid chain to a recipient who correctly validates the lowest (leaf) cert using that chain, that will prove whether the chain is valid as received.

If an attacker or fault modifies or deletes any (needed) cert or replaces one with an invalid or wrong cert, the received chain won't validate.
If an uneeded cert (either valid or not) is added it won't be detected, but won't harm security at the recipient either.
If you sent an unneeded cert (or several) and that uneeded cert(s) is modified, deleted or replaced it won't be detected, and won't harm.
If you omitted a needed cert and it is added (particularly an intermediate CA cert is likely to be widely known and available), the recipient won't detect the change, but security will be helped.
If there are multiple valid chains -- as is often the case with public CAs, especially now when many have recently upgraded to one or more of RSA-2k ECC SHA2 -- if you send one chain and it is modified to another chain that is also valid, the recipient won't detect the change. This is the only case I can see where the recipient can be harmed: if there are multiple valid chains but not equally "good" on some metric, like long-term sustainability, the recipient can be tricked into using a worse one.

PKCS#7/CMS can be nested. This is commonly used to both sign and encrypt (aka envelope) but other combinations are possible. If you really care the recipient get the exact chain (or other set) you send, not just a valid chain, you can put the p7b as the content of a second, outer SignedData message. In this case you have another choice: mostly for historical reasons PKCS#7/CMS can generate a "detached" signature, where the SignedData object does not actually contain the data, only the SignerInfo(s) and some metadata like the hash algorithm(s); in this case you must send both chunks of data in a way that the recipient can reliably connect them, e.g. Message12345.dat and Message12345.sig . Alternatively it can "embed" the data in the content slot of the SignedData message; this is probably simpler for your case. OpenSSL commandline can do this just by doing two steps, and much email software can handle the SignedData part or at least its S/MIME variants (which OpenSSL can also do), and the remaining p7b part can be handled by most if not all cert/security software.

RFC 4510 (and 2510) has lots of capabilities and options that I haven't dug through, and I'll readily believe there's something in there that does what you want, but I've never seen any implementation of it. You may well have to write -- and support -- the software at both (or all?) ends yourself.


Can I get the forwarder IP from the WAF? (when a website redirects a user, and I want the website's IP)

The HTTP Referer header is generally used to identify which website forwarded a client browser to the current site.  It only reflects the last link in the chain.

However, as with anything submitted by the client, you cannot rely upon it for security purposes.  It may not be included as a matter of browser policy, such as with Firefox Private Mode (but not Chrome Incognito).  Non-private-mode browsers may still allow the user to turn it off via settings or via extensions.

It might be possible to have the other web server set something for you via CORS, but that presumes you'd be working pretty closely with them, which I don't get the sense of from your question.

Other than that, there's not much you can do.  Your WAF will only see the connection from the client to you, and cannot know anything about previous connections the browser made.


Probably useless, but since this got necroed ...
I don't believe the Q is accurate, because
/usr/local/bin/openssl genpkey \
    ecparam \
    [anything]

is an error and cannot have worked. But if you actually did
/any/openssl ecparam -name prime256v1 -genkey -param_enc explicit -out keyfile

and used that key for a CSR and cert as described, you may have created an unusable cert.
When RFC 4492 (first) defined ECC options for TLS in 2006, it followed then-current X9.62 practice to allow both predefined (standardized) curves, also called 'named' and identified in TLS by registered numbers, and 'arbitrary explicit' curves (over prime or characteristic-two fields) that might be defined by users.
In practice people implemented only 'named' curves -- and often only a subset of them, such as the ones adopted/approved by NIST in FIPS 186-2 and especially the two selected by NSA's then-fashionable 'Suite B', which are called secp256r1 secp384r1 in SEC1 or P-256 P-384 in FIPS 186, and the first prime256v1 in X9.62. Almost nobody generated their own Weierstrass curves, and the few that did got them registered e.g. Brainpool RFC7027. (Note that the schemes for Bernstein et al's 25519 and 448 are not just different curves but different algorithms; they don't fit in the original 4492/X9.62 definition at all.)
Consistent with this OpenSSL didn't implement 'arbitrary' curves in TLS -- although it does implement ECC primitive operations using X9.62 formats. I don't know any other TLS implementation that does implement arbitrary curves for TLS, and the standards have moved away from it. For PKIX certificates (related to but distinct from TLS) RFC3279 in 2002 supported EC pubkeys using explicit parameters (in painful detail) or 'namedCurve', but RFC5480 in 2009 prohibits explicit (now 'specified') parameters and requires namedCurve only. Post-Q, RFC8422 in 2018 modifies RFC4492 (for TLS1.0-1.2) to reduce the list of named curves and remove (deprecate) the 'arbitrary' option; concurrently RFC8446 for TLS1.3 adopted the same reduced list of named curves, plus predefined/registered non-EC groups (called Finite Field groups) from RFC7919 in 2016, and no arbitrary groups ever.
Using -param_enc explicit discards the information that this key is on a standardized curve and makes it appear arbitrary. (edit) As a result OpenSSL for a long time did not treat it as matching a ClientHello offer to use P-256; it would match a client offer to use 'explicit_prime', but OpenSSL doesn't implement that, and I've not seen any (other) implementation that offers it anyway. Thus an OpenSSL-based server couldn't agree any ECC-based ciphersuite because the cert isn't suitable, nor any other authenticated ciphersuite because you haven't provided any other cert, and it can't agree a non-authenticated ciphersuite because those are disabled because they're insecure, so you get 'no common cipher' (or whatever other wording is used for alert 40). However, I didn't notice (or re-check) when I wrote this but OpenSSL 1.1.0l and 1.1.1d up (since 2 months earlier) recognize explicit parameters which are actually for a supported named curve, and convert them back to the named version, so this works. However, explicit still wastes space and violates 5480, and might or might not interoperate successfully, so I recommend against it.
TLDR: don't use -param_enc explicit


Should HSTS be declared on all assets, or just on HTML files?

Since the policy of HSTS gets applied to the whole site it is enough that you sent it together with a resource which is definitely read by the client. This can be a HTML page, it can be an image, ...  as long as the client will definitely request this resource so that it knows the policy.


Is this password hashing + salt method the most secure way possible?

No, no, no, no, no. Encryption is not hashing.

You need to use  a strong hashing algorithm like bcrypt or pbkdf2 instead. You can use a library like Bcrypt.Net.

With the library, hashing a password is simply a matter of calling,

BCrypt.Net.BCrypt.HashPassword(password, workFactor);

Verification is just as easy,

BCrypt.Net.BCrypt.Verify(password, hashed_password);

If you do not want an additional dependency in your project, look into using the built in Rfc2898DeriveBytes class instead.


Is it possible to fake an AES-encrypted data?

So the question is: is it possible to fake an AES-encrypted data, that
  can be decrypted by a given secret key?

If there is no authentication added to the data, then yes, easily. Block ciphers are really just permutations of all possible plaintext blocks to all possible ciphertext blocks. Or, in other words, any 128-bit block of data is a valid ciphertext for some plaintext, for any encryption key.

However, if we require that valid plaintext blocks have some structure, like trivially requiring the last 64 bits to be zeroes, with the data in the other 64 bits, then only 1/2^64 ciphertext blocks will produce a "valid" plaintext. But that only works for one-block messages, and is harder to do with multi-block messages, so one might as well use something designed for authentication.

  The requirement is we want to generate a bunch of keys, and we need a way > to validate if this key is generated by us.

This doesn't sound like something that would require encryption (making sure third parties can't read it), but authentication (making sure third parties can't fake it). Some message authentication code would seem to be in order (be it HMAC with some hash function, CMAC if you prefer AES). Note that there's no need to use the full authentication tag produced by the MAC. You can instead truncate it to trade off some security for a shorter length.


Tracking stolen laptop which has a login password

It all depends who steals your laptop. If its running Linux and the thief can't use it,  then it's not going to be switched on, and prey will be useless. The attacker is just going to install Windows and sell it on eBay.

What happens when you steal a hacker's computer is interesting.  Due to the fact that he had an insecure setup and that the thief could use his machine, Zoz was able to track it down using a dynamic DNS update and ultimately recover it.

To be honest I would use full disk encryption, set a BIOS password, disable the Ubuntu guest account and when the machine is stolen consider it lost forever (and hopefully useless to the thief). It's very unlikely that any software will be helpful in recovering it.


It appears to be COW.
COW programing language

The COW programming language is an esoteric programming language
created by Sean Heber in 2003. It is a Brainfuck variant designed
humorously with Bovinae in mind. COW has twelve instructions (four
more than Brainfuck) and is Turing-complete. Most instructions are
moos, only the capitalization varies: mOo, moO, mOO, Moo, and so on.
MMM, OOO, oom and OOM are the exceptions. All other character
combinations are ignored and treated as comments.

Here is Javascript Interpreter for COW, COW Interpreter
Your sample translates to "t", just the letter t.


In short, guarantee that cookies from site A won't be read by site B is provided by so called Same Origin Policy (SOP). This is browser security implementation. Sure, if there is a place for code injection (like XSS), attacker can steal your cookies, but that's another scope - in that case client "allows" (but user is unaware) to retrieve cookies by third-party.

Additionally, I highly recommend to read Michal Zalewski's browser security book, or, at least chapter of it: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies.
Also, nice post about cookies is again from himself: http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html.

Some good, related to this question links from here: How can I check that my cookies are only sent over encrypted https and not http?  and Are browser still vulnerable to Cross-Site Cooking?.


Best way to prevent phishing by turning off HTML links

Of course you could strip all the html links off your e-mails centrally. If you try this, you're likely to get hit by a mass of users complaining about non-working links. You could also just revert html e-mail to text-only in that way images would not get loaded, and all links are visible directly to the user. Bear in mind one of the classic phishing education points is to copy a link to the browser's address bar and see if it appears to be correct. This could be done directly in the mail without having the risk that a user accidentally sends the HTTP request when a malicious URL is copied in the address bar.

Nevertheless, in both "solutions" you will reduce the usability of your e-mail system to increase security. This is the classic trade off. While I agree that sometimes this must be done, I think you will not win with your personnel if you do this. You likely end up annoying more users and result in a less secure environment because people will start to overhear you. In my presented solution (no html mail) the user could still browse to the URL, and based on my experience they will. It's the same as Windows UAC where everyone clicks yes anyway.

Your solution, if I don't mistake it will strip all URLs hence no user could deliberately copy the link and browse to the site. However - and this is where people will start to hate you - not all links are harmful and there is quite often a reason to send a link. Your solution prevents this and people will have to find a way around it. At the end you made the mistake and instead of being a business enabler (god I hate this term), you are blocking business's from working.

So with phishing I would suggest regular education and awareness programms. I know they are not bullet-proof. We all have done it and later run a test case where still people clicked on the links. That's how some of the people are wired and for some it helps to get back to them personally, for others it doesn't (my example the CEO of the client...).


Businesses Handling Credit Cards via Email

PCI-DSS is not enforced by any government; compliance is a requirement for handling credit card transactions in any way.  Fines and exclusion from processing are two enforcement actions that can be taken.  I'm not sure exactly who can definitively do what but the card brands, the acquiring banks, and the processors are the entities usually involved in either determining to do so or leveraging the enforcement.  (For example, I believe card brands levy fines, but acquiring banks are responsible for collecting them - or making up the shortfall.  Likewise, processors are tasked with collection by acquirers - or making up the shortfall.  It's a system that encourages each tier to police those lower down, and the card brands don't get left holding any bills.)
No, this shouldn't vary much internationally.  All the details you mention, which are essentially unencrypted public transmission and storage of Primary Account Numbers and Sensitive Authentication Data, are violations of the core principles of the DSS and aren't subject to localization.

As far as improving it, you can work with the merchant or you can blow the whistle (publicly, or privately to their processor/acquirer).  Unless they're unusually receptive, none of these options works well for you, a contractor in a business relationship with them who has almost certainly signed legal contracts with them.

It sucks, but as you linked to earlier... "the PCI DSS structure is designed to encourage security and punish responsible parties, not to enforce security."


The answer will depend on the manufacturer, OS, hardware, and applications
It is hard to give a complete answer and you can't control any of the previous 3 in a normal phone.

GSM protocol does not require a SIM card to be able to execute an emergency call.
Any malicious application in the mobile can disclose your relative positioning using this strategy.

Another possibility, for example, is with Android OS, it uses the Google play store to provide accurate info to apps on positioning and other data.

Google play store or any app can be constantly collecting info on your phone about your wireless profile and surrounding networks.

Even if you are offline it can still track you by the GPS or the wireless SSID networks that are near you, and when online again synchronize the information.
I would not trust much airplane mode as it is based on software and not hardware.

My way of being off the grid,
I would buy a Raspberry Pi and a 7" touchscreen and install Linux with one of those power sources to recharge the phones you will have power for around 5 hours.
If you need a network to connect USB WiFi, if you need GPS to connect USB GPS... if you require 3G then connect a USB 3G stick, etc...
You own the OS so you can decide what you keep or allow to be collected.

Your tablet will not be small but it will work and keep you safer as you control almost everything...


Session Authentication vs Token Authentication

In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is however nothing fancy about this session_id string. It is just an identifier and the server does everything else. It is stateful. It associates the identifier with a user account (e.g. in memory or in a database). It can restrict or limit this session to certain operations or a certain time period and can invalidate it if there are security concerns. More importantly it can do and change all of this on the fly. Furthermore it can log the user's every move on the website(s). Possible disadvantages are bad scale-ability (especially over more than one server farm) and extensive memory usage.
In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request (it can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility (tokens can be exchanged with another client) a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server. There are a number of ways to use/create tokens:

Using a hash mechanism e.g. HMAC-SHA1

token = user_id|expiry_date|HMAC(user_id|expiry_date, k)

where user_id and expiry_date are sent in plaintext with the resulting hash attached (k is only know to the server).
Encrypting the token symmetrically e.g. with AES

token = AES(user_id|expiry_date, x)

where x represents the en-/decryption key.
Encrypting it asymmetrically e.g. with RSA

token = RSA(user_id|expiry_date, private key)

Production systems are usually more complex than those two archetypes. Amazon for example uses both mechanisms on its website. Also hybrids can be used to issue tokens as described in 2 and also associate a user session with it for user tracking or possible revocation and still retain the client flexibility of classic tokens. Also OAuth 2.0 uses short-lived and specific bearer-tokens and longer-lived refresh tokens e.g. to get bearer-tokens.

Sources:

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
https://stackoverflow.com/questions/1283594/securing-cookie-based-authentication
https://web.archive.org/web/20170913233103/https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/
Demystifying Web Authentication (Stateless Session Cookies)
https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication


Why is it possible for the root user to delete the logs?

Because you need to be able to manage the server.

  Whats stopping a hacker with root access from deleting the logs in order to cover their tracks?

Regarding local logging, only their own stupidity. Regarding external logging, their skill set and yours.

There are many, many different ways to "log." In fact, you could have the rooted machine log to a separate, hidden device that can't easily be overwritten, such as a raspberry pi / arduino logger, of which I have a few.

In Linux, root is supposed to be able to do pretty much everything. In Windows, the same concept applies; if you have root access to a machine, you will be able to do almost anything you want to that machine, which includes deleting logs.

You can also log all connections to a certain machine, especially if it isn't supposed to be "accessed" in the first place.

How would you find out what's going on, and how would you circumvent it?

Here's a way to find all changes in the last 120 minutes:

find / -mmin -120 -printf '%p\t%a\n'

Nice, huh? Gotcha, hacker! Mwahahaha... but you can change these attributes if you know what you're doing, like so:

touch -d "24 hours ago" <file>

Even worse, automating it:

find / -print | while read file; do
    touch -d "$(date -r "$file") - 24 hours" "$file"
done

But wait, Mark Hulkalo! If all the files were last edited 24 hours ago, then that clearly shows we've got a haxor! True, but you can also apply $RANDOM where 24 exists. Here's an example of a number from 1-24: $((RANDOM % 10) + 1). Now it doesn't look so easy to discover, does it?

But what if all files look like that, especially files which aren't supposed to be changed? Limit the scope to a certain directory, such as /root. There are lots of ways to mask your presence locally.

Unless the attacker forgot to cleanse ~/.bash_history, you'll be flying blind. Really, if the only "logging" you have is ~/.bash_history, then you're in trouble if your attacker is at least moderately intelligent. That can be erased on each user account with astounding ease, so as long as you have the appropriate permissions.

It's much easier to log entries somewhere it won't be easily detected or modified, such as an external device. While it's possible to use forensics to recover your attacker's footprints, it's very, very easy to circumvent if you know what you're doing. This is why external logging is a much better solution.

And that's the story of why external logging is generally the answer... keep in mind there are also ways to circumvent external logging. Nothing is ever 100% safe; you can only make it harder for your attacker, not impossible.


Are Chrome extensions like Advanced REST Client safe to use?

I worked this summer around 3 browsers: Firefox, Google Chrome and Internet Explorer: by principle any extension is a source of vulnerability if not an exploit in itself. Trust me it is not the number of people who use REST that will make you comfortable to use it because there had been several and more popular extensions that were discovered finally later to be too dangerous. You can find examples of such malicious extensions (even if most of them were used as spywares and adwares) on here and there, for example.