When taking ownership of a TPM in Windows 7, how is the SRK derived from the password?

Disclaimer: I'm not a TPM expert - most of this has come from a half hour's worth of research. I've managed to cobble together a reasonable understanding of the process and details from the TCG TPM spec, the TPM API documentation on MSDN, and various papers on the subject.

The SRK is an RSA key pair (of at least 2048-bit size) that is used as the root for a chain of trust within the TPM. It acts as the ultimate authority of trust. If a secondary RSA key is loaded into the TPM and signed with the SRK, that key is classed as trusted, and other materials signed with that key may be loaded in via that chain of trust. The SRK is not derived from a password - it is an RSA key generated in hardware.

When ownership is taken of the TPM, the process involves two things: one is generating the SRK, the other is storing the owner authentication secret. Once set, this secret is used to authenticate owner users in future sessions, usually via a HMAC-based exchange.

The Trusted Computing Group (TCG) spec for TPMs does not specify how this secret is to be created, but Windows uses a SHA1 hash of the UTF-16LE encoded password, with the null terminator of the string excluded (source). If you were able to retrieve the owner authentication secret from the TPM, you would be able to crack it just as quickly as you could any other SHA1 hashed password, e.g. via oclHashcat. Simply capturing an authentication exchange (HMAC of a challenge value using the secret as a key) is not enough to crack the authentication secret, since the challenge value is generated by the TPM.

The SRK is stored in the TPM in an encrypted format, using one of two different encryption methods. If the Authorisation Data Insertion Protocol (ADIP) is used, the SRK may be encrypted with AES-128-CTR or simple XOR. If ADIP is not used, XOR is the only method defined by the spec. Therefore, the system is expected to compute its own key, and store secondary information such as the IV inside non-protected areas of the TPM. The creation of the key for the encryption is, again, entirely reliant on the OS.

It stands to reason that different keys can be used for ownership and internal encryption, i.e. an SRK key and an owner key. However, it appears that Windows simplifies the situation by using the same key for both.


Which are the most common vulnerabilities for poor crafted IoT devices?

The most common vulnerability is no security at all. Many brands just:

put a completely insecure web server onto their devices.
put plain-text hard-coded passwords into their code for "maintenance access".
standard issues such as buffer overflow.
the firmware update functionality is often vulnurable
signature of an update was in past verified to be a valid signature, but the certificate itself was not checked for validity. So any self signed certificate provided access.

For best practices, try to keep your code simple and authenticate everything. There will probably be no need to include something like a web server in a camera and it brings many vulnerabilities. Also remember, that users may not ever update your firmware, so keeping bugs to a minimum by making the device simplistic is a good idea.

PS: Also authenticate using something like HMAC, as your connection will most likely not be secure. You should avoid sending passwords.

PPS: If you want some sort of developer access, use public key cryptography and always include an option to turn it off.


How safe are signed git tags? Only as safe as SHA-1 or somehow safer?

There is no contradiction. Linus himself said in that same talk:

  If I have those 20 bytes, I can download a git repository from a
  completely untrusted source and I can guarantee that they did not do
  anything bad to it.

I'd interpret the "Git uses SHA-1 not for security" as "SHA-1 hasn't been added to git for security reasons, but for reliability reasons, but security still is a nice side effect", and "The security parts are elsewhere" as "the final verification is done by gpg, and git verify-tag".

Git commit ids aren't "more secure" than "bare" SHA-1. However, the use cases git is used for are more resistant against collision attacks, than most other SHA-1 use cases.

For example, SHA-1 in certificates is dangerous. Somebody could create two certificates with the same hash and for different domain names. One (the "legitimate" one) is sent in a CSR to a CA, and the other one kept private until used on some victim with the signature from the CA. For collision attacks, if the attacker changes the preimage at one part (like the domain name field of the cert), they must also change it at another position. While the attacker had free choice for the two domain names, the other changes are mostly fixed. Particularly, they are binary, and can't be part of any human-readable part of the cert. Some attacks hide them in the public/private keys of the cert (discussion for MD5).

Git however, is mostly used for source code. Hiding your {chosen-prefix,} collision in an ASCII diff reviewed by humans is much harder. Maintainers usually ask questions when you make an if-condition about the hex address 2ff5e of the file logo.png you added in the commit. Taken together, it is easier to hide a backdoor inside a commit, than to attack SHA-1.


What makes Malware so difficult to remove?

Malware is not made to be easy to remove. That's the point. You should not even be able to tell that your computer was infected.

The malware authors employs several techniques to make their software almost impossible to remove: encrypted code, multi-part software, self-healing components, and rootkit behavior.

If you could just go to programs' list and remove them, they would not profit. Hiding it as much as they can, they can keep profiting on your computer.


Session Cookie HttpOnly Set After Initial Server Response Showing as Vulnerable

This is easy to test.  After the browser finishes rendering,  open the JavaScript console and try this:

alert(document.cookie)

If you can't access the session id using the terminal,  then an attacker cannot access it using XSS.


Bank details by them self are not such an issue.
If you however supply more personal info such as a picture of your ID/pin number/secret code/bank login information, this will be an issue since an attacker can use this against you.

For example: (Only main issues are pointed out)

If I have a picture of your ID and your account information, I can edit the ID to have a picture of me and go to the bank with the fake ID and identify myself as you.
If I have your login details I can try to brute force online account and then manage your account as I wish.

In conclusion:
Never give out more information then is needed for the transfer and even then, only if you trust the person.


Don't one-time recovery codes for 2FA introduce a backdoor?

tl/dr: One time recovery codes give account owners an option for regaining lost access.  People who consider this an additional risk
can always ignore it or destroy it, but people who are worried about
losing access to critical services can certainly come up with a secure
way to store it.  As a result, it's a good option to have for services
that may be critical to businesses and/or people.

There is no secure
In most of the systems I've seen that have one time recovery codes, they are an optional feature.  As a result, they give the account owner a way to mitigate competing risks.
When it comes to security, it's always important to remember that there is no such thing as "secure", only "secure enough for me".  Different companies and people have different risk tolerances, different threat models, and different concerns.
Mitigating denial of service vulnerabilities
From that perspective a one time recovery code is a mitigation against a very particular kind of denial of service vulnerability: faulty (human) memory.  In some services, if you lose your password, you are effectively locked out of your account permanently.  In some cases you may fix this by getting a new account and suffering the inconvenience of having to set it up again.  In some cases this may destroy your business.  If a particular account falls in the latter category then you probably don't want to risk forgetting the password and losing access.
One time recovery codes are obviously designed to address that (and other kinds of events that may cause you to lose access).  You may decide that printing a one time recovery code on a piece of paper and putting it in (for instance) a bank safety deposit box is a good way to mitigate the risk of lost account access without increasing the risk of account theft.
Then again, you may decide that you aren't worried about losing account access and so you may "print" the one time recovery code from the site and then immediately throw it away/burn it/never actually write it down/never actually request it in the first place.  After all, if you don't have it, then you don't have to worry about accidentally leaking it.  In this case, you are deciding that the increased risk of account theft via the recovery code is not worth having an alternate means of access.
From the service provider perspective
The whole point is that you get to decide whether or not you wish to make use of this feature.  Many sites I have seen it make it optional, but even if it isn't, you can destroy it easily enough.  However, as a service provider, if I provide the kind of service that may be critical to running a business, then I probably have some customers who want to have an alternate means of access in the event of account lock-out.  As a result, it makes perfect sense for me to provide this as an option.
Certainly, this will save me a lot of trouble when I start getting frantic emails from people who claim to have lost access to their account.  Telling the difference between "I lost access to my account" and "I'm trying to use social engineering to convince support staff to give me access to someone else's account" can be surprisingly tricky.  If I build options that give my customers the self-service options to recover their own account, then that gives me less support requests to handle and also decreases my legal liability (since if I accidentally give away an account to an attacker I will definitely be held liable for it).
Moreover, since these are features that will be used rarely, the provider can make extra protections around it.  You would certainly put in protections against people trying to brute force recovery codes, although I don't think that is a real concern anyway.  Every recovery code I have seen are long and random enough that they would be immune from brute force anyway.  In general though, the concept itself is perfectly valid.  Whether or not a particular provider may have implemented an insecure implementation of one time recovery codes is another matter.
Finally, adding recovery codes doesn't make it easier for a provider to access your data.  The provider can already do that anyway, and will do that if requested by law enforcement regardless of whether or not you have a recovery code.  In the case of services that are designed so that the provider cannot access your data (for example a password manager), then they would have designed the recovery codes so that they are also inaccessible to the provider.  As a result, recovery codes do not generally create an additional risk vector for internal attackers.


Are there any security risks with allowing shared accounts to website

Concerns regarding shared accounts:

The audit trail becomes an issue, since there is no valid audit trail possible. When the audit trail is not properly in place, accountability becomes an issue.
Loss of credentials to unauthorized users is significantly increased.
Once an account is compromised, the impact is high since many users share the same account.
Password policies no longer apply. Regularly changing passwords is not a viable option anymore. If the password would regularly be changed, how is the new password communicated to all your users?

Probably one could come up with a few more concerns here. The fact that you do not understand why they are asking you this question is interesting to me.

Apparently they have an issue and think they have the best solution for this problem already and ask you to implement it this way.

I personally would go back to them and try to determine the problem. Once the problem is determined, a proper and secure solution could be considered.


No. If you can read the MySQL schema tables, you can extract the names anyway, and the schema tables have fixed names.

Work on preventing SQL injection through the use of parameterised queries and other well documented techniques, and it doesn't matter if your table and column names are predictable.


How can Bank of America tell that I'm logging in on a computer I haven't used with them before?

I'm willing to bet that they don't actually identify the computer, they just send you a persistent cookie once you've successfully logged in, and as long as your browser returns that cookie, they know it's a previously used machine.

You should be able to test this quite easily using something like Firefox's Web Developer toolbar which will let you both examine all of the cookies that you're sending to a specific domain, and will let you delete the cookies for a specific domain.   If you delete the cookies for the Bank of America website and then try to login again, you should get the "You're using a new computer" workflow again if indeed they are using a cookie to determine which workflow should be presented to you.

Besides cookies, there are a number of methods they could be using to recognize your machine.

Locally shared objects (Flash cookies)
Web Storage (Also known as local storage)
Other storage mechanisms
Browser fingerprinting (much less likely)

Additionally, the storage mechanisms can be combined (as it appears Bank of America does, or at least did at one point.)  The ultimate example of this, so far, is a project known as evercookie which aims to make persistent browser tracking as difficult to defeat as possible.


Have both my email address and IP been spoofed, or has someone gotten my password, or...?

Originating email address is quite easy to spoof when SPF is not in the picture. However, given the nature of TCP it's much harder to spoof a source IP address. It is possible your account is compromised if you are seeing this source IP. I would highly recommend changing your password. There is a possibility there is something configured incorrectly with Sendmail, however, that might allow messages to be forged or relayed through you. I am not a Sendmail expert but I know it's notoriously hard to secure properly.


Why can I ping a server, but nmap normal scan cannot see the host?

From nmap.org:

If no host discovery options are given, Nmap sends an ICMP echo
request, a TCP SYN packet to port 443, a TCP ACK packet to port 80,
and an ICMP timestamp request. ... For unprivileged
Unix shell users, the default probes are a SYN packet to ports 80 and
443 using the connect system call.

I am guessing you ran nmap as an unprivileged user, so ICMP was not used for host discovery. Using -Pn "works" because it skips host discovery and treats the host as up no matter what.


Securing API access. oAuth Client Credentials vs client ID and secret

Using client credentials flow would make sense if

there is need for separation of authorization server (which grants access) from resource server (which server API)
there is a need for separation of more trusted client part (which knows credentials) from less trusted (which uses token to call API)

if it is not a case then there is no need to complicate the API with OAuth.

I would also suggest considering client certificates for securing API access instead of id/secret combination. They have the benefit that the private key never needs to leave client machine, while secrets need to be transferred over the wire and received by the server every time they are used.


The best practice by far is to chose any of the questions but enter random text as the answers.

As others have said in the comments, it is far too easy to discover the answers to most of the well-used questions now.

Of course, this requires you to carefully keep track of the answers and be able to get hold of them when required.

Generally I use Keepass as a password store and this supports additional QA security as well as the enter n characters from a password type entries. It is well tried and trusted and has 3rd party versions for pretty well all platforms including mobile ones.


Forcing a black box to register a ssl cerificate

For the HTTPS proxying to work, the client must know (and trust!) the mitmproxy CA, i.e. the CA key file must be added to the trust store of the client. What type of device is it? How can you access it?


Why does Google say my password is weak when I only added a division sign after a bunch of random stuff?

There's no cryptographic reason why adding a character would make it weak. Most likely, this is a programming oversight. In particular, if the symbol is not allowed, it may not be sending the (invalid) password to the strength-analyzing routine which then reads out the default strength, which is weak.


Is there any real security benefit to forced password change intervals?

Supposing that the hashing function was correctly selected, it should take more than 60 days to crack a password that follows correctly selected password policies.

Therefore, if a malicious actor has permanent read access to your credentials database, since they would only have access to hashes, and since the hashes would change before a password would be cracked, the passwords would still be safe.


Can a file .exe.part already have caused damage?

I'll agree with @Adnan but I will make a bit longer answer just to explain you what can happen and what is not possible.

Short answer is no.

Long answer, no, but maybe. As you may know, the *.exe.part is un-executable until renamed to executable PE (exe, cpl etc.). Try it out. Create a new file on desktop called "test" and change files extension to .exe.part. Now try to run it. Is it executed? I don't think so. It will ask you for software you want to run or open the file with.

Considering above, you are safe but there still might be chances to cause a damage to a system in next case. If connection is established, an attacker maybe already compromised the system with another malware which will hook the process of downloading and rename the file to *.exe. If file is successfully renamed, it will execute the same. Note that this may not be possible because .exe.part did not finish full structure of PE file (it's still in downloading process) plus you were saying something about anti-virus that will detect the infection while downloading. The chances of happening this to someone are pretty low. The only generic trojan that could do something like this is probably Carberp and attacker would not execute this type of action as most of trojans and malwares already offer hidden UrlDownloadToFile function which downloads file with out your knowledge of specific action.

As written above, you safe but there is always a way of security disclosure.


What are the pitfalls of repeating a password multiple times for increased length and entropy?

The problem with picking a password based on any pattern is that, if the attacker knows the pattern, they can then eliminate relatively large numbers of possible passwords they'd otherwise have to test.

This is why we advocate for passwords to be randomly-generated as much as possible. The only restrictions you might want to put on the random generation are:

Minimum character length
Inclusion of multiple character types

Those help to ensure (though, strictly, not guarantee) that the random generator will not unintentionally spit out a password that's likely to be found in dictionaries or rainbow tables. However, where it can be avoided, we do not want to add in restrictions like these:

Maximum character length
Exclusion of certain characters or character types
Matching specific patterns (e.g.: a dictionary word repeated n times - even if n is random)

These will greatly reduce the search space for an attacker who knows your password generation scheme. You might still be able to dodge the ones who are just looking through a database for passwords they can easily break. But you'll be much more vulnerable to a dedicated and resourceful attacker who is targeting you specifically (some call this an "Advanced Persistent Threat" or "APT"), or if your particular method becomes common among other users and the large-scale attackers adjust their methods to compensate.

True random generation of passwords, with very few restrictions to avoid accidental output of weak passwords, is the only way to be sure your password is strong enough to resist virtually any attacker. Of course, this all does assume that the password storage and transmission mechanisms are reasonably secure as well - but that's beyond the scope of this question.

In short: A password based on a single string repeated a number of times, is always more vulnerable to a dedicated attack than one which is of equal length and randomly generated throughout.


How does Cloudflare track their client? Tor is not a workaround

Cloudflare is notoriously unfriendly towards Tor users. Most Cloudflare hosted sites becomes quite patchy when accessed through Tor as Cloudflare rates Tor users as high risk users.

It's possible your scraping or the site admin triggered "I'm under attack" mode, which increases Cloudflare's vigilance while it's active.


My old job has massive security exploits in their product, but they dont care

A quick word of caution
You sound very invested in trying to do something.  If I can be frank, it sounds like you are at least partially motivated by your frustrations with the way the company treated you as an employee.  This can be understandable, but doesn't necessarily lead to good decisions.  In particular one option you mention (contacting customers and informing them of the issues) is the sort of thing that, rightly or not, and regardless of how it might end, can result in lawsuits filed against you by your former employer.  So tread lightly.  All things considered that is probably a very bad idea.
Understanding the (flawed) business perspective
Unfortunately the situation you describe is not uncommon in the software industry.  From the perspective of many companies, bring up security issues is asking them to spend real money (in terms of developer salaries) to fix a problem that they cannot see for a benefit that may not be needed for a long time (it may in fact be a while before someone tries to hack them).  It's a hidden benefit with an upfront cost, and that is something that short-sighted thinking can easily ignore for a long time.  After all, from their perspective, the things you are making a big deal about have never actually caused problems but will definitely take a lot of time and effort to fix, so why should they fix it? (I'm not saying they are right, I'm just explaining the thought process).
It's important to understand that this is obviously the approach that your ex-employer is taking.  You have informed them of the issue and they have decided to ignore it.  There is no reason to think that any (legal) action you can take as an outsider is going to change that, especially since you failed to make any changes as an insider.  Of course we know that with bad security practices, someone finding and exploiting a weakness is inevitable, especially if they start to see any real kinds of success (i.e. having a large customer base).  As long as none of their customers take the time to delve into potential security concerns proactively (and most don't, because they don't know enough to look properly even if they do care), situations like this can go on for a surprisingly long time before it causes real problems.  In the worst-case scenario this leads to situations like the equifax security breach.  For smaller companies this can result in complete bankruptcy.
Reality
So what do you do about it?  If management knows about the problem but refuses to change, there probably isn't anything you can do to force them to change.  You can try things you mentioned like reporting this to their customers, but their customers may not take you seriously.  For all they know you are simply a disgruntled ex-employee trying to cause trouble for your previous employer.  If they didn't know enough to look into these things before starting to use the platform, then there is no reason to think they know enough to take your claims seriously now.  More likely than not you'll just end up being ignored or sued.
(per @forest's answer) You certainly should submit a CVE.  You could also try submitting bugs through a third-party bug bounty program.  There are some that have popped up in recent years and exist to try to act as a neutral arbiter between "independent security researchers" (aka you) and sites that otherwise don't have bug reporting programs (aka your former employer).  Of course such programs work only if the company you are reporting bugs to actually listen.  You already know that your former employer won't.  However, having published and ignored vulnerabilities through standard channels will help their customers in the long run when they do get hacked. This will change the situation from simple incompetence to outright negligence, which comes with much stiffer financial penalties in civil court (FYI: IANAL).
Any further (legal) options will vary depending on your jurisdiction, aka in Europe you may find some venues for legal action through the GDPR.  In many places though you probably don't have any options that can immediately bring legal trouble to them.  Most likely that won't happen until they get hacked and their customers sue.  Having a published CVE will help their customers when that happens.  In the meantime, it sounds like you are thinking about posting something publicly "on the internet". What would be your goal there?  Realistically, your attempts to do that will probably just be ignored by the internet.  It's possible however that they may end up hacked much sooner as a result though.  Without going through more standard channels though, you probably dramatically increase your own risk of legal repercussions.  Therefore, I would personally keep to official channels.
Again, I may be misreading you, but I think your question is largely coming from the place of someone who is angry at a past-employer and is, to some extent, looking to cause trouble.  That's a good way to get yourself in legal trouble or at least give yourself a bad name when trying to find jobs in the future.  I think you should try to stop looking at this from the perspective of an ex-employee and focus more on the perspective of a neutral-security-researcher.


GPG why is my trusted key not certified with a trusted signature?

The key needs to be verified. If you trust that someone's public key does in fact belong to that individual and they are in your keyring you can use your private key to sign your correspondent's public key and validate it.

So you are Bob and you trust that Alice's public key does in fact belong to Alice, so you sign it with your private key. So Alice's key is trusted to you. Also any keys that Alice trusts, say someone called Chris will be in your web of trust also. So you can also trust Chris, because Alice does. So Chris’s key will be certified with a trusted signature.

Now if Alice trusts that your key does belong to you then she can validate your public key with by signing it with her private key, therefore your key will now be included in that same web of trust.

  a procedure was given to validate your correspondents' public keys: a correspondent's key is validated by personally checking his key's
  fingerprint and then signing his public key with your private key. By
  personally checking the fingerprint you can be sure that the key
  really does belong to him, and since you have signed they key, you can
  be sure to detect any tampering with it in the future. Unfortunately,
  this procedure is awkward when either you must validate a large number
  of keys or communicate with people whom you do not know personally.

  GnuPG addresses this problem with a mechanism popularly known as the
  web of trust. In the web of trust model, responsibility for validating
  public keys is delegated to people you trust. For example, suppose

  Alice has signed Blake's key, and

  Blake has signed Chloe's key and Dharma's key.

  If Alice trusts Blake to properly validate keys that he signs, then
  Alice can infer that Chloe's and Dharma's keys are valid without
  having to personally check them. She simply uses her validated copy of
  Blake's public key to check that Blake's signatures on Chloe's and
  Dharma's are good. In general, assuming that Alice fully trusts
  everybody to properly validate keys they sign, then any key signed by
  a valid key is also considered valid. The root is Alice's key, which
  is axiomatically assumed to be valid.
  Trust in a key's owner

  In practice trust is subjective. For example, Blake's key is valid to
  Alice since she signed it, but she may not trust Blake to properly
  validate keys that he signs. In that case, she would not take Chloe's
  and Dharma's key as valid based on Blake's signatures alone. The web
  of trust model accounts for this by associating with each public key
  on your keyring an indication of how much you trust the key's owner.

  There are four trust levels.

  unknown

  Nothing is known about the owner's judgement in key signing.
  Keys on your public keyring that you do not own initially have this
  trust level.

  none

  The owner is known to improperly sign other keys.

  marginal

  The owner understands the implications of key signing and
  properly validates keys before signing them.

  full

  The owner has an excellent understanding of key signing, and his
  signature on a key would be as good as your own.

  A key's trust level is something that you alone assign to the key, and
  it is considered private information. It is not packaged with the key
  when it is exported; it is even stored separately from your keyrings
  in a separate database. The GnuPG key editor may be used to adjust
  your trust in a key's owner.

Read more here

Also have a look at this awnser from Server Fault


Intrusion attempt? Host 'somedomain.org' is not allowed to connect to this MySQL server

My first guess would not be a hacking attempt, but rather a transient glitch in your shared hosting's DNS or something similar.  On shared hosting, something like this could easily happen for a brief period.

Update (8/7): If you are concerned that you might be under a hacking attack, my suggestion would be: rather than expending a lot of energy trying to confirm whether you are in fact under attack or not; rather than expending a lot of energy trying to identify the perpetrator; instead, I suggest that you focus on making sure your system is secure against attack and can resist attacks.

Take this as a good opportunity to review your security practices and the configuration of your systems to ensure that you are in good shape.  If you are under attack, this will help protect yourself -- and even if you are not under attack, you get good protection against other kinds of attacks.  In either case, you will have the peace of mind of knowing you've done all you can to lock down your systems.


Prevent Handler From Starting On Exploit

Run the listener as a job and set exit on session to false

set EXITONSESSION false

then

exploit -j

then view all active sessions with

sessions

and interact with specific session with

session -i n         # n being the number of the session


If the server checks certificates (of connected clients, or of other servers that it connects to), changing the time will disrupt these checks. Changing to a time when the accepted certificates are not valid will cause denials of service. Changing to an earlier time allows expired certificates to be accepted, and these certificate may have been compromised or may use weak cryptography that is now breakable.

Incorrect times on file timestamps, logs and anywhere else a time is recorded can make intrusion detection and later forensics harder. This is a concern when the attacker would otherwise only have limited access. For example an attacker who can gain user-level access but not root access to a unix system can fake files' modification time, but not their inode change time.


How exactly does 4-way handshake cracking work?

Short answer is, 4-way handshake password "cracking" works by checking MIC in the 4th frame. That is, it only checks that KCK part of the PTK is correct. 4-way handshake doesn't contain data that would allow checking of other parts of the PTK, but that's actually not needed, for two reasons:

MIC verification is how AP checks the validity of PTK (and, consequently, the password);
Chances of a password producing PTK that has valid KCK but invalid other parts are really low: KCK is 128 bits, so probability of incorrect password producing correct KCK is 2-128.

Overall, 4-way password "cracking" works like this:

4-way handshake is parsed to get SP and STA addresses, AP and STA nonces, and EAPOL payload and MIC from 4th frame;
Candidate password is used to compute PMK;
PTK is computed from PMK, AP and STA addresses and nonces;
KCK from computed PTK is used to compute MIC of the EAPOL payload obtained at step 1;
Computed MIC is compared to the MIC obtained at step 1. If they match then candidate password is reported as correct.

If you'd like to see actual implementation of the attack, one place to start is coWPAtty sources: they're relatively small, self-contained, and easy to read.


How do I continue pentesting with access to local station?

General strategies - Red Teaming Analysis

Abuse identity and authentication -> Target: People and credentials -> RDP, SSH, more consoles, portals
Exploit privilege and trust -> Target: Infrastructure -> Utility Manager, Sticky Keys, NT Domain administrator, Unix root accounts
Attack data structures and data handling -> Target: Services, Apps -> Client executables, Client-to-server traffic, Server-side controls
Subvert the supply chain -> Target: OEM software and hardware -> "Get there first"

You may want to check out the recent attack vectors and strategies on the Irongeek Derbycon 4 video page.

Specific strategies - Scenario Analysis

Trustwave has a few blog posts that link to some of their homegrown tools, as well as links to other known attack tools/techniques.

http://blog.spiderlabs.com/2012/12/my-5-top-ways-to-escalate-privileges.html
http://blog.spiderlabs.com/2013/09/top-five-ways-spiderlabs-got-domain-admin-on-your-internal-network.html
http://blog.spiderlabs.com/2014/02/responder-20-owning-windows-networks-part-3.html

For general strategy 1, most professionals tend to employ "social engineering" techniques, perhaps using the Social Engineering Toolkit (SET) or related tools such as recon-ng, esearchy-ng, FOCA, et al.

General strategy 2 is the most common attack vector from your position, and these Trustwave blog posts mostly suggest ways of focusing in on this strategy (or perhaps also general strategy 4, which may require patience or social engineering to get people to act on your well-placed traps). However, a great resource are the first few chapters of the book, "Defense against the Black Arts: How Hackers Do What They Do and How to Protect against It". There are also many Metasploit and nmap mechanisms that can aid in the general strategies. Attacking infrastructure may sometimes begin with a classic vulnerability scan. Custom vulnerability scan development will teach you the basics that network vuln scanners will not, so I do recommend using vulscan over OpenVAS, Tenable Nessus, Rapid7 NeXpose, or Qualys QG if you are a completist.

If you do plan on attacking either networks or apps, I suggest learning a lot about those domains. For example, knowing networks could involve learning Wireshark-related tools and methods, along with strong network engineering skills. You'll typically want to learn all of the internals of traceroute/0trace/lft, sslyze/ike-scan, and bnat/nmap/amap. When you start using firewalk, qscan, osscan-guess, traceroute, and packet-trace with nmap, then you'll understand how to combine methods well -- although basic issues like banner grabbing must also be mastered.

Apps are the hardest domain of penetration testing. My suggestion is to learn as much as you can about your target applications: their primary interfaces (e.g., for webapps, try webshot) and their various configurations. Then, move on to their internals by learning how to build and code apps in a variety of environments. If you understand the entry points to the applications, you can begin to learn to look for low-hanging vulnerabilities and spend an extra amount of time bringing them to full exploitation once you verify a vulnerability. Typically, for web apps, you'll need a good crawler to back up your existing domain knowledge (e.g., the Discovery-section of seclists found in Kali Linux) and a proxychain to analyze and attack using fault injections. My favorite open-source crawler and my favorite open-source fault-injection tool is Arachni (the autothrottle and other plugins are good introductions to web app pen testing). Eventually, you'll want to move to commercial tools such as Burp Suite Professional or Acunetix WVS, but there is no need to rush it when you don't understand the basics (as I alluded to with net vuln scanners above).


With eight characters you're extremely limited.

My advice - forget the memorisation part.

Generate an eight character string using a cryptographically secure pseudo random number generator, using letters (both cases), numbers and symbols. This will give your password 52 bits of entropy, which is the maximum you can achieve using this scheme. The alternative would be to start using unicode characters if these are supported, as a much greater key-space can be achieved. However, entry of these passwords may be difficult depending on the devices used. This would enable you to achieve the 80 bits necessary for a secure password.

Use a password manager to remember the password for you - this can be a memorable password, however make sure that this has enough entropy to make it secure. This is the best way to achieve memorability and security of your passwords, because you only have to remember one password.

For example, the LastPass generator is here. However, make sure your browser supports the Web Cryptography API, otherwise unfortunately this one falls back on current time as seed and uses a standard PRNG. You should be OK with any modern, popular browser.


The SANS course that includes incident handling, introduced at https://www.sans.org/course/hacker-techniques-exploits-incident-handling recommends the following steps:

Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned

Obviously, it's too late for step 1...

A network IDS (eg. snort) watching all internet traffic will help you identify infected hosts (#2).  It will also help you identify where you're being attacked from so you can filter those IPs and networks at your firewall (#3).  Don't forget that most control channels will originate from your machines out to the attackers' servers, rendering basic firewall rulesets ineffective.  The ability to watch intra-host traffic as well as external traffic at the NIDS will help spot lateral transfers where an infected host directly compromises another.

As infected hosts are identified, rebuild them (#4 & 5).  Use a unique local administrator password for each one, saving them offline (eg. a notebook in a safe or locked room) for use next time that host is compromised.  That way, you're not exposing domain admin credentials when logging into a compromised host, and local admin on one host does not equal local admin on all of them.

Full packet capture will allow you to review malicious activities, extract malware, droppers, exfiltrations, and such.  With limited network bandwidth, hardware requirements for capturing all traffic drop to levels where commodity hardware can handle it.

If your infrastructure is Windows, radically limit your domain admin accounts and rotate their passwords often, especially when used to access a compromised host.  Log all network accesses, collect your logs centrally, and review them regularly.  For SSH access, use PKI, generate new private keys and remove old keys from authorized_hosts.  Change any local account passwords on all hosts and don't reuse passwords on multiple hosts.

It sounds like you may be over your head on this.  It may be wise to hire an outside firm to help you identify which hosts to clean, IPs to blackhole, etc.  Search for incident handling services and shop around.


Should I report a security vulnerability?

Quick note: this answer assumes that you have permission to run scanners against the website.  Running scanners against a website is illegal in basically all jurisdictions, so if you are doing that then my only suggestion is: "STOP!".
What you shouldn't do
You should never send a vulnerability report from a scanner to a company.  90% of the time those are useless by themselves, and are likely to be ignored by any competent security team.  The reason is because scanners can have any number of false positives, so a positive from a vulnerability scanner does not actually mean there is a vulnerability.  However, it is common for new bug bounty testers to simply send vulnerability reports from scanners off to companies without any understanding of what the report says, if it is correct, or if it is even applicable.  As a result security teams will often just ignore a report that came straight out of a scanner.  Most bug bounty programs specifically state this.
What you should do
Instead you should take the time to generate a vulnerability report yourself, which means that you describe the nature of the vulnerability, steps they can take to confirm your findings, the risk the vulnerability creates for the company, and potentially even steps they can take to mitigate the danger.  That is what you should send to the company, and sending something like that is almost always a good idea.
If this is a company that doesn't have a public bug bounty program then they are even less likely to be able to make sense of a report out of a scanner, so it will be that much more important for you to take the time and provide an actually vulnerability report detailing the vulnerability, the impact to the business, an estimate of its severity, and suggested mitigation steps.  Obviously though that's not the situation you are in, since running automated security scans on a website without explicit approval is illegal in most jurisdictions and a bad idea in general...
tl/dr:
Should you send the results from your scanner to a company?  No, because that's often useless.  What you should do is verify that the scanner isn't reporting a false positive and then send a report detailing the vulnerability, what they can do to reproduce it, an explanation of its impact, and suggested mitigation steps.  You obviously shouldn't "hack" into the system under any circumstances.


ojdkbuild maintainer here, to get the list of CVEs from downloads page you need to follow announcement link that contains some details on release and usually links to Oracle Java SE Risk Matrix.

Yes, you can assume, that ojdkbuild OpenJDK builds includes the same CVE list as RHEL OpenJDK builds.

Generally Oracle CPU list linked above is exactly the same as the one in RHSA link you posted. There may be nuances, for example if RHEL (and as a consequence - ojdkbuild) do not use the version of third-party library (like libjpeg) that is vulnerable.

Please note, that this covers only OpenJDK itself, WebStart and OpenJFX (that are not parts of OpenJDK) are handled separately.

You can also use issues lists from aarch64-port maillist (aarch64-jdk8u is a base for RHEL builds for all arches) and from corresponding IcedTea 8 release notes for cross-checking.


RC4 is an algorythm, not some piece of software. It's the same difference between an idea and a book: you can attempt to suppress a book that carries a specific idea but you cannot suppress the idea itself.

Likewise, you cannot globally disable RC4 with a registry edit. At best, you will instruct software that reads that registry key not to use RC4.

Specifically, what you're doing with this registry entry (the GPO is just a way to propagate a registry edit to a domain) is instruct software that uses the Windows secure channel API for establishing a TLS/SSL connection from using it by default. Software that do not use SChannel or software that do not let the SChannel subsystem auto-negociate an SSL connection will not be affected.

For instance, setting these registry entries will prevent an IIS web server from using the RC4 cipher but will do nothing about a Tomcat server.

Conclusion: it is impossible to globally prevent the use of RC4. You should refocus your question by specifying exactly what software you want to restrict. Such a question would be more suited, however, to serverfault.com or superuser.com


How to secure MySQL based web session data table?

One of the biggest security threats of storing session data in the database is that an attacker can use SQL Injection to obtain the Session id and use that to authenticate instead of cracking a password hash.  The solution is to encrypt the session id. MySQL's aes_encrypt() is not a bad choice for this data type even though its ECB mode.  Because the session id is random you don't have to worry about a repeated plain text with your encryption key (CBC+Random IV usually solves this problem).  A hashes session id might be easier depending on your deployment.

Keep in mind that you have to keep the encryption key somewhere and an attacker maybe able to read it using the load_file() MySQL function with SQL Injection.  Make sure file_privs are disabled for the MySQL user account that your web application uses.

However the data its self maybe sensitive.  If that is the case,  then this may also need to be encrypted, and aes_encrypt() would be a poor choice for this type of data. CBC+Random IV is a good choice.   MySQL doesn't allow query stacking,  so an attacker will never be allowed to insert a session record. If this was MS-SQL, then you would have to worry about this attack.


Setting up LetsEncrypt SSL for domains/subdomains on two servers

Assuming you have ssh aacess to server where foo.example.com and bar.example.com are hosted, just run the certbot command with above two domains only, and it should work without any errors and browser warnings. For certbot to be able to generate certs, it needs to be run on the same server where the domains are hosted.


Unless you have some program that is able to run compressed programs from archive, no it can't.

You inability to suppress the file is more likely due to the fact that the file itself is being used or access restricted by some program (e.g. antivirus quarantine).


Is an unknown directory structure considered security by obscurity?

To answer the question in the title, yes, that's security through obscurity.

While the security community generally frowns upon that, in some situations that can be appropriate - for instance, semi-private files on a CDN, with a long random-ish string in the URI, that need to be accessed by a variety of clients for whom handling authentication is difficult.

Your situation, though, is a bit different, in that you explicitly are not using a hard-to-guess filename.  This means that someone who has never been given access to the file still has a reasonable chance of finding it.

A broader problem with this sort of security is that you cannot easily revoke access for specific users.  If one person has been granted access, they continue to have access, which can be a problem if, say, they were an employee and they've now left the company.  It also allows them to send the link to others, either publicly or privately, and those others will now have access, even if you did not intend to grant it to them.  Again, in some situations this is acceptable (if it's a file that isn't frequently updated, they could simply save it onto their computer and achieve the same thing), but this will depend on your situation.


Help with scope clarification of PCI requirement 8.5.15

Yes, your understanding is pretty close.

That accompanying note is intended to clarify exactly that point: those requirements apply only to accounts that have access to multiple cards.
I.e. a cashier application, that accepts a single card at a time (and cannot access historical data!), is out of scope.
I.e. your account that can only send emails (assuming there is no access to the customers CHD) is out of scope.


Are there any know browsers that support file URL redirection?

Generally speaking, no, a website cannot redirect the browser to a file: URL.  This is due to special restrictions imposed by browsers on use of file: URLs.

(Redirecting to a local file: URL would be mostly harmless, but this is a better-safe-than-sorry situation.  It is mostly harmless, because the user is shown the contents of the file in their browser window, but the contents of the file never leave the user's computer and are not sent to the web server, so no harm is done.  However, there are some cases where it could pose some risk, so browsers block redirection to file: URLs, just in case.  See references below for details.)

To learn more, see the Browser Security Handbook.  The Browser Security Handbook should be your standard go-to reference for information about security-related browser behavior.

And sure enough, it covers your question.  See, for instance, its sections on URL scheme access rules and Redirection restrictions for information about what kinds of uses of file: URLs are and aren't allowed by browsers.


Whats the best custom compression method to use when I have SSL?

Encryption hides data but leaks data size. That's a common property of all encryption systems: encrypted data has (more or less) the same size as the clear data.

Compression alters the data size but it does so by finding "redundancies" (in a loose sense) in the data. So compression success rate depends on the data contents. Thus, compression makes data size dependent on data content.

Take the two together, and this leads you to the unavoidable but grim conclusion: compression leaks information about the data contents, even through encryption. The only general conclusion is then that thou shallt not compress at all.

The CRIME attack simply works with that notion, in a Web-specific setup where the attacker gets to choose part of the data which is compressed, and tries to obtain some other confidential data which is also part of the compressed stream. This is a chosen plaintext attack and it makes the attack really efficient. However, in all generality, a leak is a leak: even in purely passive attack scenarios, compression will make your connection "less secure".

The principle is not specific to Deflate; changing it to a custom algorithm would not save you. Deflate is not "especially weak" or "especially strong" in that respect.

All of the above applies for all lossless compression algorithms. It doesn't for lossy compression algorithms which achieve a fix data bandwidth. For instance, if you compress music into a MP3 at exactly 128 kbits/s (no variable rate) then the resulting data size will not depend on the music contents, only on the original music duration. But, of course, lossy compression algorithms are applicable only to data where loss can be tolerated; e.g. sound, not XML.

(The thing about "lossy" is that you cannot guarantee a fixed compression rate without having some potential data loss, because of the pigeonhole principle, unless your "compression" is actually a lack of compression, with the input data being totally unchanged.)


Security Consequences of compromised passport data

The specifics will likely depend on your passport's originating country. Let's assume you're not actually British and instead have a US passport. Mine has the following information:

Pretty clear picture of my face
First, Middle, and Last name
State of Birth
Birthday
Passport number

The adjacent page also contains a signature line, so depending on what exactly was exposed your signature may be included.

While this isn't strictly sufficient to perform identity theft, it's certainly pretty close. This is also much of the same information that is available on social media sites for many people. Assuming this is the information that's been released...personally I'm less than impressed. As already mentioned for many people it's already public.

A much more interesting aspect is that many US federal positions, particularly related to the Department of Defense, require a CISSP or CEH. Since the CEH is easier we can assume it's the more common. So with some clever filtering it may be possible to construct some fantastic social engineering data for a population that likely has some pretty fun access.


Why middleman cannot capture the encryption key of https/tor traffic?

This is the basics of Asymmetric Key Encryption (or public key encryption).  Each party has a key pair, a public key and private key.

You can encrypt data with the public key, but it can only be decrypted with the private key.  Now, there is a performance hit when using public keys, so usually a symmetric key is set up.  The problem is that we need to have a secure way to distribute our key.    Public key cryptography is used to securely exchange that key.

In it's most simplified form, a client creates a secret key K, and encrypt this using the server's public key. Now, only the server can decrypt this, and K is used to encrypt all further traffic.

K is never transferred in clear text, so even though an ISP collects all traffic between client and server, they'll never know what K is.  (That is, unless there are vulnerabilities).

As said, there's a lot more to see (SSL negotiation, etc...) when setting up an SSL tunnel, but that's the general idea.


Are there any known breaches of the .NET AppDomain isolation?

Yes, there are plenty of examples.

MS14-072 is one of the most direct ones. An attacker could hijack a remoting call to elevate privileges to other AppDomains running within the same execution context. Pretty much all the direct code execution bugs work as examples too, because once you escape the type-safe environment, you can make direct API calls on the system which violates all safety guarantees.

There are also application-level bugs which can violate the AppDomain restrictions. For example, an arbitrary file write bug could cause a secondary AppDomain to load a DLL or other executable object, leading to a compromise of both parts of the application.

As far as hosting untrusted code goes, keep in mind that the latter article you linked is very old. It is now generally considered insecure to host any kind of untrusted code. Code Access Security (CAS) has become deprecated in .NET due to its ineffectiveness and difficulty of implementation. Microsoft provides advice should you absolutely need to host untrusted code, but generally this is more focused upon using closed-source 3rd party libraries for which you have no security metrics, rather than "please upload a .NET executable and I will run it".


With symmetric encryption, the level of confidentiality depends on the protection of the keys.  Storing the keys on a file is easier than storing the key in a db but you'd have to have protections for the file.  Database can provide a more secure storage facility but then you have to manage much more than the contents of the file.  When you take into consideration key rotation, storing keys in a database will likely reduce headaches of key management in the future.
It depends - if you have the facility to maintain multiple keys and a way to tie back ciphertext to key, then you wouldn't have to decrypt and re-encrypt data with the new key.  This method also requires some sort of key store (see above).  However, if you want to maintain just one key, each key rotation will require you decrypt data with the old key and
reencrypt with a new key.
Again, it depends.  I'd recommend you figure out how important the data is to an adversary now and over the course of its useful life and how much effort you want to exert in this process.  I wouldn't recommend rotating keys more frequently than necessary for the sake of security.  That'll lead to a management nightmare and you could lock yourself out.

NIST has a great write-up on this topic.  The NIST docs lays out what, how, and why.  Since the NIST docs and frameworks are published for government use, it's very comprehensive and well structured.

Check out NIST's Special Publications for additional details:

SP 800-57 (Recommendations for Key Management) 800-57
SP 800-130 (A framework for designing cryptographic key management systems)
800-130


How can an internet server can find my local ip address?

As it turns out, the recent WebRTC extension of HTML5 allows javascript to query the local client IP address. A proof of concept is available here: http://net.ipcalf.com

This feature is apparently by design, and is not a bug. However, given its controversial nature, I would be cautious about relying on this behaviour. Nevertheless, I think it perfectly and appropriately addresses your intended purpose (revealing to the user what their browser is leaking).

https://webrtc.org/


Reality check: what actions should be taken if an hack attempt seems to be a false positive

As proof of a successful compromise has been cited, my suggestion would be to isolate the computer from the network and watch its behaviour (i.e. the network traffic). Information gleaned from this might shed some light upon how the compromise was performed, and thus how to avoid it in the future.

After this step, the computer should be erased, updates performed and all passwords and credentials for user accounts should be changed.

To emphasize on earlier postulations: Whether Microsoft is directly or indirectly involved in a compromise is irrelevant here; a Microsoft system could be hacked, and a proxy or VPN software installed upon it to cover tracks... After all, nobody in Microsoft would want to admit to such an embarrassing attack; they'd cover it up.

  I am now wondering on what the best actions would be in such case

At the very least, to quote what I wrote earlier, "the computer should be erased, updates performed and all passwords and credentials for user accounts should be changed." This won't shed insight upon how the compromise was performed, but that insight might not be necessary. I tend to be curious about these kinds of things, so I'd be likely to perform some investigations prior to that system restoration phase, and from my experience there's usually a botnet to observe, and a leader repeating the same attack upon multiple people well into the future.

EDIT: The following was the result of misinterpretation of the question, and doesn't answer the question, but does present some good advice so I'll leave it, with invalid sections struck out like this.

It's a good practice to change the password every few months. The account was only freshly created, and there are no reasonable grounds to suspect the password is known.

  Some time ago a friend of mine created a Microsoft based mail account (Live Id/Microsoft Account. He just needed the mail) to use for receiving some messages. ... All seems to point to a keylogger or similar infection on the client used to create the account.

It seems crazy to assume the only person who knew about the email address was the client, does it not? After all, the client was "receiving some messages".

Additionally, if the client is keylogged, it seems crazy to assume the hackers need to brute-force; if they have your keystrokes, they can... replay your password.

Perhaps the sender wanted to crack the account open but doesn't want there to be any evidence and so to cover tracks, used an irrelevant Microsoft system (the IP you mentioned).

There are also emotions to consider. Suppose sender thinks receiver will get paranoid, and to trigger the paranoia merely inserts the email to a phishing page with a fake password. Yes, people are often extremely vulnerable to emotional hacking.

Whether the sender/hacker/whatever is internal to Microsoft or not, this detail matters not to the question. Nonetheless, it's possible that Microsoft system was infiltrated by a Microsoft employee posing as a Russian hacker via Tor, which was then used to host a phishing site later used by sender to trigger anxiety meaning the blame is shared amongst two (edit: multiple) attackers, and the service staff you spoke to not wanting to get in trouble for such a stupid (edit: an embarrassing) attack implicitly being a third; how deep could the rabbit-hole go? It's not important.

No, the computer shouldn't be erased unless there's conclusive evidence that it was compromised. In this case, there seems to be no such conclusive evidence (or even mildly suggestive evidence), so even changing the password for the inbox seems unnecessary.

  I am now wondering on what the best actions would be in such case

(edit: see suggestion at top of post)

Nonetheless, changing your password every few months is a good security practise. Perhaps making a memo to change the password in a few months is the most appropriate course of action here :)


Are TLS session keys cached in a browser?

Yes, sometimes, but not as you're describing.

The simplest bottom line answer for you is "Yes, sessions are cached until the browser is closed."  That's not absolutely true, or true in all cases, but it's a reasonably secure belief for you to base your actions upon.

  when authenticating to a TLS protected service, and then closing the
  tab, you can sometimes reconnect to the service afterwards without
  re-authenticating.

What you're describing here is that you authenticated to a web application which you browsed to using a TLS connection.  Unless you were prompted to provide a client certificate the first time through, the authentication is not for TLS, it's for the app.

That app is probably using cookies, and those cookies mean that when you go back in another tab, it recognizes you and you don't need to authenticate again.  Depending on the setup, this authenticated state may also persist past a browser close and restart, system sleep, and IP address change!  I've had authenticated web sessions work on either side of a day of air travel.

(Even if you were prompted for a client certificate... browsers will remember your selected certificate and re-present it as necessary until you close the browser.  Closing the tab would not impact that.)

  In preservation of perfect forward secrecy, the key should be deleted
  after the session terminates. Does the session only "terminate" when
  the browser closes, or is there a "Time To Live"-like expiration on
  session keys not in use?

Realistically, the speedup provided by session resumption outweighs the potential negative of re-using keys - keep in mind that most HTTP transactions are astonishingly small, whereas PFS becomes a larger practical concern with protocols like IPSec that will be up for days/weeks/months and swap large chunks of data.

So, in practical terms, browsers will remember recent TLS session IDs and use them to try and shortcut the TLS negotiation process.  Closing a tab will not cause them to be forgotten (although closing the browser probably will).  They are used invisibly; the use of one cuts down on 4-8 packets of back-and-forth when setting up TLS and thus speeds the connection up.

But - again - this has nothing to do with authentication you might see, and takes place quietly, behind the scenes.

The "time-to-live" is determined by both the client (who has to remember the session ID) and the server (who also has to remember the session ID).  There's a good article here which talks about how to tweak the cache for various servers to limit the amount of past sessions that would be compromised if the server is compromised.

And this interesting answer suggests that Chrome and Opera stores session keys infinitely until browser restart (or other limited situations).


I have a virus in my USB drive. I haven't inserted it on my PC yet. How should I proceed?

If the malware are just .exe files waiting to be clicked on, then not opening them should be enough (also beware of Autorun). You can further protect yourself by using an OS which won't be able to execute the files anyway (like Mac or Linux). Deleting the malicious files or formatting the drive is enough to clean it.

If the malware also modified the files or some filesystem data to be malicious and exploit a vulnerability, you should decide whether you're likely to be affected - if your system is up to date and it's unlikely someone would use a zero-day on you, then it's safe. Otherwise, it's not and you shouldn't be mounting the filesystem (Windows and Mac mount them by default so be careful). Reformatting the drive is again enough to clean it.

If the malware modified the firmware of the USB drive itself, then it's no longer an USB "drive" and will often pretend to be a keyboard and type in malicious commands. At this point, I suggest you just throw away the drive as it is now comparable to a compromised machine and you can no longer trust it.


Make all form inputs safe but allow any type of input including code

The two main risks of a system such as this are:

SQL Injection
XSS

The risk of SQL Injection is mitigated by the use of parameterised queries. This ensures that data values inserted into the database can only be interpreted as data and not by part of the query by an attacker escaping out of the context.

XSS is prevented by correct output escaping. This prevents the browser from interpreting any markup or code as script and it will render the visual representation of the markup instead. This should be done by your application on output of data to the browser, and usually shouldn't be stored in this format. This is because if you later have to output the data in any other format (e.g. JSON or plain text) things can get complicated because you'll first have to convert back to plain text before re-encoding and this is where mistakes can easily happen to leave your application vulnerable.


Do dictionary attacks only use specific entries from a dictionary, or combinations of an entry?

The most powerful feature of oclHashcat is the rule based attack. The rule engine can accept characters to rotate the passwords in the list, so using the '{' character in the rule file will rotate the word left by one char. 'abc' will become 'bca', then 'cab'. You can also reverse the word using 'r', 'abc' will become 'cba', then rotate left or right if you wish. This barely scratches the surface. Check:

https://hashcat.net/wiki/doku.php?id=rule_based_attack


Clarification on "data hiding" and how it applies to hardware?

The question was "NOT... an example of data hiding" and in option A, you have an authorized reader of the data.  Options B, C and D deal with users, or applications, that do not have permissions to view the data.

In all of these options, consider permissions in relation to the data.  Permissions being the ability to read, write or modify and the only one with any of the three, (read, write, modify) is the authorized reader in option A who has read access.

You may need to shift your thinking for this test.  Coming from a systems background, I failed the test the first time because I took the test with a desktop support/sysadmin mentality.  Try to think from an administrative/managerial approach.  I know that's easy to say because I read it a few times when I was studying for the exam.

Good luck man!


Identifying malicious scripts on a website

We had the same issue some time ago. This probably comes from ads from Google AdSense. Unfortunately Google AdSense if full of malicious ads targeted only for mobile devices and debugging this is nearly impossible.

After months of searching and disabling some 3rd-party networks in AdSense panel, we added device detection on server side based on user agent. Now we're serving ads from AdSense for desktops and custom ads for mobiles - problem disappeared (or at least no one bothers to report it to us).


Type of SSL connection used when visiting google services

It might a because of different processors in your computers, i.e. one supporting AES-NI and the other not. From https://codereview.chromium.org/75663004/:

net: boost AES-GCM ciphers if the machine has AES-NI.
We want to use ChaCha20 based cipher suites on machines that don't have AES-NI
and AES-GCM on those that do.


How are Intel/Amd Microcode Issues Delivered? Is it possible to block them?

Answers to your questions, one by one:

How are the microcode update files published?

They are simple, rather small, files, published by the processor makers.

How are they loaded into the CPU?

Your processor comes with an initial version, that it boots up with.
Your processor has a sequence of instructions to initiate a microcode upload.
The BIOS/UEFI of your system may have a newer version, that it will load into the processor before your boot-loader gets control.
The operating system may have an even newer version. If so, it will load it into the processor during system start.

How are new versions normally transferred into your computer:

If the BIOS gets updated by you, it could contain a newer version.
Your operating system may be setup for receiving microcode update through system update. (All current ones can)
If somebody nice from Intel gives you the encryption key for their microcode, you could encrypt/sign a modified version, place it on your hard-drive, and load it with some instructions.
If somebody else can run processes on your system with System/root rights (e.g. Virus, Trojan), they can even do it for/to you.

How could somebody apply such an update without me knowing?

These days, BIOS/UEFI implementations are entire operating systems in themselves, with all modern features, networking, usb, graphics, ... support.
Most network cards runs an entire, independent Operating System too.
Aside from bugs, which you can bet there are, these firmwares all have (partly) documented remote communication protocols.
Somebody exploiting a bug in your NIC, or using the magic_key/protocol, could send a correctly signed microcode update to your CPU.

How feasible is this type of attack?

For somebody with authority over the key-holders: Very easy.
For the savvy neighbor kid: impossible


Things we do on shared hosting platforms is limit/block outbound connections (especially UDP) and check for scripts trying to bind to ports (listeners). We force all SMTP traffic through our mailserver where we ratelimit SMTP traffic and store logs containing the customer's username. We assign unique user ID's per customer so we can track incidents to specific useres. We use FTP servers are checked on suspicious IP-addresses (from other continents mostly) and filenames being uploaded (known bad files for Joomla, Magento, etc). We have scripts detecting files being downloaded and uploaded with only a very limited time (seconds) between those actions, which turned out to be another good way of detecting compromised FTP accounts.

I haven't used it myself, but you might want to try HoneySpider (http://www.honeyspider.net/), which scans websites for malicious files, scripts, etc.


Is Telegram now secure enough to consider?

This has already been answered and recently updated (as of yesterday).

Is Telegram E2E Still Insecure?


This has something to do with MTU and Path MTU Discovery (PMTUD).

Let's assume your MTU is 1400 and MTU of your server is 1500. When you try to download the file, without MSS or PMTUD, server would try to send you file in around 1500 byte packets which would be dropped since your MTU is only 1400.

With Path MTU Discovery, server can discover what is the MTU size, the thing is, it relies on ICMP. So when packet is dropped, the ICMP message is sent back. However, if ICMP is blocked, server must rely on MSS value included in SYN packet. So if your lower your MTU, your MSS value in SYN packets will be lowered as well so the servers will now know how to size the packets.

Your router can also be altering MSS field in SYN packets to adjust to MTU of your broadband line like ADSL. It's iptables feature "SYN TCPMSS clamp to PMTU". This is because if your broadband line MTU is lower than your WIFI MTU (which is normally 1500), router may need to clap it for you so the packets coming back from the internet servers are sized for your Broadband and not WIFI.


Protecting yourself against DNS spoofing?

Technically that could have been an ARP cache poisoning attack which is much more likely to occur. I'd suggest using SSL (Secure Socket Layers) and TLS (Transport Layer Security) as well as only connecting to the sites with "HTTPS://" addresses to encrypt your connection. Using a proxy or VPN protects your IP address from users on the other side of the modem, but not people within the network you're using.


What's the idea behind requiring users to change password periodically?

While I see your point, having a compulsion to change your password at regular intervals of timing is a good and mandatory method for security within most banking applications. Allow me to explain why.

The main reason people get hacked online is because of vulnerabilities where their password is either phished from them, key logged or too easy to brute force. This also includes conditions wherein due to the manner in which the user accessing the system, other individual(s) are aware of his log on credentials.

In all such cases, changing your password helps a lot. Logs generated by key loggers are enormous. If a mass key logger has affected someone, hackers generally take time to process those logs. Changing your password regularly has a fair chance of ensuring that by the time the hacker attempts to log in with your credentials, the password has changed.

Also, most applications set out alerts when a password is changed. As a result, if a hacker does get control of your account, he could only access it without your knowledge so long as as the password remains constant.

Of course, this is not the best method of delivering security. I personally believe that 2 Factor Authentication is a more safer and user convenient method then prompting the user to change his password which can lead to him forgetting it or storing it insecurely.


SQL queries using SQL Injections do not work as I think they should

Example 1 & 2

This is because your query is applying this clause:

'1'='1/*'

If you have a comment character inside of your quotes the comment is not respected by the query parser, you would have to exit the quoted context first.

1 is returned as count because that's how many users have that email address.

Try this instead for example 1 (the same technique will apply to the others):

Username: abc@gmail.com' OR '1'='1'; --
Password: Whatever

This should make the query

SELECT * FROM User WHERE EMAIL='abc@gmail.com' OR '1'='1'; -- ' AND PASSWORD='Whatever'

Example 3

I'm guessing that you do not have a user with the email address abc@gmail.com/* set? Again, because of the quotes, it will be querying abc@gmail.com/* and not abc@gmail.com.


Is password strength exclusively a function of character set size multiplied by password length-in-characters?

Is password strength exclusively a function of character set size multiplied by password length? Well, to be precise... not exactly.
Technically, entropy alone is not enough to guarantee you have a strong password. Strong passwords are supposed to be generated with enough entropy, and also look random enough to defeat dictionary-based attacks, or other related attacks. Also, technically, if a password with enough entropy and that looks random enough has been leaked and can be found in leaked databases, then it's not strong enough anymore.
What I mean in practice is that a 8-char randomly generated password might look like 49thS1bp, or might look like 123abccc. The second password though, unfortunately, by chance, contains patterns that make it easier to attack. As another example, by chance, you might end up generating a passphrase like correct horse battery staple, or orange banana banana orange, and those will not be considered safe enough (by the way, correct-horse-battery-staple has also been found in leaked databases). Also, consider what would happen if you used a custom word-list for generating your passphrases, so instead of the typical English-based word-list for diceware you would be using a list of words in your own native language, some other foreign languages you know, and maybe some local slang. The entropy will be the same (same size of the list, same length of the passphrase, etc.) but strength will be increased, because dictionary attacks will be less likely to succeed on average.
In your case, if the method of generating and checking the passwords is always the same, then you can just use the formula C^N for estimating your password strength, where C is the alphabet size and N the length of the password, exactly like you said. Also, if C and N are large enough, you can even forget about checking for patterns or checking in leaked databases, because those weak points will become less likely.
To sum up, even with perfect randomness, C^N technically defines the password entropy, not necessarily the strength. However, if C and N are large enough, this distinction becomes less important.


This is a rather broad question, so I cannot give more that hints. First at its lowest level, the SSL/TLS library (OpenSSL) only require that both parts involved in a communication have private and public keys and that each knows the public key of the other one. That is the way it is used for example in OpenSSH. The PKI infrastructures and CA and only a way to validate public keys for entities that do not know each other.

In your use case, you could use a (private) Certificate Authority to validate certificates for the devices and eventually certificates for the client PCs. But in case a key was compromised, the renewal of a certificate would be hard while it does not add much security to a mere public key exchange the way OpenSSH do.

So my advice would be:

find/build an acceptable way to generate random key pairs on the devices and client software. The good point with it is that is the device is sold, the new owner can install a brand new key on it.
imagine and develop a way to exchange public keys between a device and a PC. Something like broadcasting them in a time window followed by an agreement protocol if one and only one key has been received. After that point, the peer key should be pinned on each part

From now on, the device should just reject any connection request that cannot prove the knowledge of its peer key. That allows you to:

rely on the high quality OpenSSL (or probably LibreSSL) library.
allow the owner to change the keys on his device at will if it can suspect his PC or device could have been compromised, or if for any reason the device or the PC hast lost its previous key (for example is the device memory had to be replaced, or if the PC disk crashed)
require no more that 2 buttons (generate a new key and start an association) on the device or even one single button if a new association can consistently use a new key

Alternatively, you could setup a special mode (activated by a button on device) in which any certificate will be accepted during a time window and that certificate will be pinned for further exchanges provided one and only one was received. In that mode only the connection should be possible and no command would be processed. This variant avoids to setup a key exchange protocol and simply rely on the ability of SSL to pass certificates. So you end on both side with:

generation of a new self signed certificate
on special mode allowing the pinning of a peer certificate
all other exchanges rely on the certificate send being the same as the pinned certificate

I know that this is far from a definitive answer, but it could allow to ask more precise questions here or on StackOverflow...


Is it safe to call an untrusted service with jquery.ajax and dataType 'jsonp'

No it is not safe. You are correct that the JSONP service could deliver arbitrary JavaScript, which is then executed as part of your site.

Because JSONP is essentially a hack to get around the same origin policy, it is not possible for a JavaScript framework to perform sanitisation.

These days, CORS is the preferred way to call external sites. An alternative approach is to have a server-side script on your site that proxies calls to external sites.


Google Timeline: is it encrypted and if so who has the key?

It means they will not post it in public places, not show it on other people devices, things like that. It's like those sites who ask your email and say it will be kept private, unlike your picture and nickname that are public. It's not private on the crypto sense, more on layman's sense...

It does not mean it's encrypted in any way or form, or only you can see it (and they cannot). It's a way more relaxed definition of private.


Data retention is limited by country law (and GDPR in EU).

In my country, the law says 6 months so it's 6 months., but it may differ depending on your location and implicit legislation.


Do a DoS where you permit only your own connection?

This depends a lot on the setup of this site.

If there is no DOS protection at all than it is probably not possible for an attacker to block others from accessing the site while still having access. The attacker might of course try to hack the site and configure a firewall or require authorization so that everyone else gets blocked.

If there is some dumb DOS protection or IDS the attacker might try to create an attack with spoofed source IP in the hope that the IDS or DOS protection will consider these source IP malicious and automatically block them. This way it can be done that only selected IP addresses have access, including the attackers real IP address.


Strategy for encryption before cloud storage

First, it's no problem to use a different symmetric key for each document, generation is easy as you just have to generate a 16-64 byte random string, a matter of a millisecond (mostly).

As threats I guess you consider your cloud hoster and anyone who can get their hands on the documents.

The approach you propose should work.
The document needs to be encrypted and authenticated using an AEAD mode like AES-GCM.
You add a header (which may be stored on the metadata storage, no matter where), which is authenticated and encrypted (using an AEAD mode like AES-GCM) using your master-key.

Scenario 1: You do this for personal access.
You can store the metadata locally or on the cloud, it won't make a difference.
You should use password-based key derivation to derive the master key from your password. The master-key will be symmetric and be used to encrypt+authenticate/decrypt+verify the file-header.

Scenario 2: You do this for a company, or a larger group of people.
You should go with cloud-hosting the meta-data so everyone has access if needed.
You store the header encrypted as described above.
You give everyone a copy of the master-key, so they can encrypt it using their very own password (again using authenticaed encryption + PBKDF)


Suspicious .exe set to run at startup: Determine if file exists still

I would just run Sysinternal's autoruns, and find the exe file in the list it provides you with. Make sure you run it as an administrator. If the file is marked red it does no longer exist.

You should however note the name of the file and do some research about it. If you have a bad feeling about the file I would also run a virus and malware scanner.


Invoke an antimalware scanner from code on azure Roles

You are going to be fighting somewhat of an uphill battle to implement this the way you want to. For whatever reason, local anti-virus systems typically do not give an API for such interactions. I will give a few options:

1) Scan your files on a storage server after they have been uploaded. Then, check back later to see if the AV has zapped them.

pros: Easy to implement.
cons: Malware may make it deeper into your back end.

2)Use an open source AV solution such as clamAV, and look for a language binding that will do what you need it to do.
pros: Allows you to check on the results of the scans when you want to in the process.
cons: Open source. Potentially buggy.

3)Pay a large AV vendor to modify their solution to your needs.
pros: Will do whatever you pay the AV guys to make it do.
cons: Very expensive.

4)hash the file, and query a public AV provider like virus total.
pros: Cheap and easy.
cons: May fail to find custom malware, or malware that is new. Slight loss on the privacy front.

5)Upload the file to a public AV prover like virus total
pros: Cheap, easy, and effective. More likely to find custom malware via heuristics.
cons: Much bigger privacy loss for your customers.

6)Pay for an external service to hash/scan your files that you communicate with via API, and promises secrecy.
pros: works pretty well.
cons: Expensive. Promises of secrecy doesn't obviate privacy issues.


Are there privacy implications with ESET Web Protection?

They are both passive features. In either case when it detects a file it will scan it, before the file is created on the disk, in theory preventing the malicious file from ever existing on your drive. This is at least how it works on the Windows side.  In the case of the Outlook plugin it will scan the file atachements, and in the case of the "Web Protection" it scans files as you download the file, all detection is passive without user ction.


Could HTTPS-Attacks like CRIME be mitigated by changing the session cookie regularly?

In the case of CRIME, the attack is on the client. Hostile Javascript in the client triggers requests to the server, that the attacker observes from the outside; and (that's the important point here) the attacker can block the outgoing request. The attacker needs to see the encrypted records, but not necessarily to let them go all the way to the server.

Thus, during all the attack, the server never sees any request with the cookie in it. Even if the server changed the cookie for every request (a "one-time-cookie"), the attack would still work.


Are cross site scripting attacks and sql injection a good topic for my thesis?

I wouldn't do it. Injection attacks have been in the wild for long time, and everyone (in this field) know about them.

As I see you are focusing on web applications, my suggestion is to take one of the vulnerabilities in the end positions of the OWASP's ranking, and then research about it.


Are there any examples of huge damages done by password leaks, or bad password management policies?

There was a study conducted by the Ponemon Institute and IBM in 2015 which estimated that the average information breach costs a business $3.79M, with an additional $1.57M in reputational damage.

Source: http://www.csoonline.com/article/2926727/data-protection/ponemon-data-breach-costs-now-average-154-per-record.html

However, it's really hard to determine whether these are caused purely by password security, or whether the incident was caused by some other vector of badness. There's one identifiable case of a bad password being used to cause reputational damage to NATO countries here:

https://www.schneier.com/blog/archives/2009/03/choosing_a_bad.html


This is not a secure approach.

In order to use the connection string, the client must decrypt it. In order to decrypt it, it must have possession of the secret key, at least temporarily. During that time, a hacker can debug the program and extract the key from memory. For this reason, a global secret key should never leave your data center.

A more typical approach would be to issue a license code that is hard to guess and simply store it on the server. The caller would need to send the code along with the request to use the service, and the service would check that it is valid. If the code is found to have been compromised (e.g. shared), you can simply remove it from the server.

A less centralized approach would be to issue a license document (e.g. an XML file) and digitally sign it before providing it to the customer. That way the client or other clients could validate the license independently of the server (and of course the server can still validate it).


Safe place for private-public ssh key pairs

Since you are talking about public keys only, it is fine to place these file in any repository you like.

Now I am unsure if you are really only talking about the public keys. In case you are wondering what to do with a private key, here is what I do from a backup perspective:

Encrypt external media
Use a long (20 characters) random password which I memorize to decrypt the external media.
Copy the private key(s) to this media
Store the external media in a (physical) vault


Should WPA2-AES be presumed insecure? (What is the "Hole196" vulnerability?)

WPA2-AES should be considered secure against "outsiders": people to whom you have not given the cryptographic key / passphrase.

WPA2-AES is not secure against "insiders".  People who you have given the cryptographic key can access the network and may be able to eavesdrop on communications of other users.  However, usually this is acceptable and beyond the scope of what we are expecting the network to do for us.

See also How do I protect myself against 'hole 196'? and this summary of hole196.

Also, make sure you read about the vulnerability in Wifi Protected Setup (WPS).  Probably you'll want to disable WPS.  See, e.g., this question for some citations where you can read more about the WPS vulnerability.


Sending passwords securly over the net: javascript?

Properly implemented TLS provides end-to-end encryption between the client (your computer) and the server so that any passwords being sent should not be visible to any passive attacker along the wire.  TLS also resists active attacks by require that certificates be verified by Certificate Authorities.  If you are the server operator, you can make future man in the middle attacks harder by implementing Strict Transport Security.  STS ensures that future connections by the same user agent will also connect over an encrypted channel, and enhances certificate errors on future connections (generally, users will not see a "proceed anyway" option if the SSL connection is being tampered with).


Initial certs used during role configuration have a short lifetime. But regular certs generated by each WAP henceforth will last 20 days by default. They are renewed automatically.

If the trust between the WAP and the AD FS breaks after a long duration of been offline (and thus cert expiring), simply re-run the WAP configuration via PowerShell or re-enable the GUI and launch the wizard by toggling the registry value as shown in https://blogs.technet.microsoft.com/rmilne/2015/04/20/adfs-2012-r2-web-application-proxy-re-establish-proxy-trust/


Salting by itself does not prevent a dictionary attack against the password itself. But it makes rainbow-table or common password attacks against the hash much harder. If you use a PBKDF instead of a simple hash o HMac, a dictionary attack against the password may become infeasible, too.

P.S.: The salt is nothing to be kept secret. Its only purpose is to randomize the hash and make it unique to another factor other than the user-chosen password.


Best practices with respect to hard drive reconstruction

Question: once I have decrypted an encrypted file, how do I make sure that the information is not written in plain text to hard drive somewhere?

You use full disk encryption, so that no matter where it is written, it will be written encrypted. This includes swap and all user writeable spaces - excluding only a small boot partition that is not encrypted.

If you do not encrypt the whole disk, you have the risk of remapping sectors leaving unencrypted data around, or that it's written to the wrong location. Encryption does not provide enough overhead to negate the benefits of it.

  Related question: can one safely assume that information stored in RAM
  cannot be recovered once overwritten?

Yes, that's an safe assumption. Also it's fairly irretrievable once the computer has been powered off for >minutes.

  Related question: what other similar traps might one fall into when
  trying to use encryption software?

Leaking key material, leaking cleartext, leaking passphrases, backdoors and similar. It depends a lot on what crypto system. If you use encrypted e-mail it's fairly easy to secure against an attacker having access to only the ciphertext. It's a lot harder to secure against an attacker on your own computer.


Is it safe to use flex and bison as a protocol parser?

Bison and flex are reasonable tools to write parsers for protocols which fit in an LALR(1) grammar; but they are just tools like, e.g., a C compiler. It is still up to you not to do anything wrong with them. For that matter, bison and flex mean that you are about to implement your code with C or C++, languages which are known to be difficult to handle properly and prone to trigger security holes, especially because of pointer aliasing issues, manual memory management, lack of decent character string handling facilities, and unchecked array bounds. These are C issues, not bison issues, but you'll get them nonetheless.

LALR(1) parsing can be a bit confusing because you tend to get the "reduce" rules on a right-to-left basis. When you write the code attached to the grammar clauses, this can make things awkward (you have to handle the leaves of the syntax tree is a mostly context-free way).

The good thing about flex and bison is that they are systematic: they will implement all the corner cases of the grammar. That's a great property for security (most of secure coding is about covering all possible cases without forgetting any).


That's a very general question.

Your concern should not just in relation to Snort, it all depends on the platform that you install it on (o/s - yes it does run on Windows, CPU, memory etc) and what elements (pre-processors for fragmentation or stream reassembly) of Snort that you enable (look in the configuration file, typically /etc/snort.conf, for more information) and what rules you enable or add.

If you want to test it, I'd suggest downloading Security Onion (http://securityonion.blogspot.com), a Xubuntu-based Network Security Monitoring distro, as it comes with both Snort and Suricata. It is a fantastic project and so easy to learn with as everything is essentially pre-configured. (Disclaimer: I try to help out with the Security Onion project).

Snort is very scalable and I know is actively used in networks with over 20gb/s but remember the platform aspect above.

Additionally, both Snort and Suricata have active mailing lists for their users where such performance issues are actively discussed.

I'm sure vendors like Tipping Point, Sourcefire (commercial aspect of Snort), Enterasys (if they're still around), Cisco etc have comparison whitepapers on their sites but beware their bias.

Regarding the 'rule size' and 'accuracy' aspects, these are becoming like the AV industry a little now with the "I'm bigger than you argument".

Here's some links for you -

http://www.aldeid.com/wiki/Suricata-vs-snort

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,7913.msg42307/topicseen,1/

and an old one

http://www.infosyssec.com/forum/viewtopic.php?t=14


Is it ok to send plain-text password over HTTPS?

It is standard practice to send "plaintext" passwords over HTTPS. The passwords are ultimately not plaintext, since the client-server communication is encrypted as per TLS.

Encrypting the password before sending it in HTTPS doesn't accomplish much: if the attacker got their hands on the encrypted password they could simply use it as if it were the actual password, the server wouldn't know the difference. The only advantage it would provide is protecting users that use the same password for multiple sites, but it wouldn't make your site any safer.


how to download software without fear of viruses?

Well... It depends...

You didn't specify your operating system, but the way the question is worded I'm guessing you want software for Windows.
You didn't say what software you are looking to download, so I give a few examples for both proprietary software and free/open source software.
If you're looking for free downloads of commercial software, that is illegal unless you get a free license from official sources.

Most important
On Windows, you NEVER go online or run/install new software without active and updated antivirus.
Also important
Preferably stick to:

Official sources
Trusted sources

If those aren't available/applicable you could use:

Well known, reputable sites with curated content.

But NEVER without using a search engine to check if:

That site is recommended/criticized by other sites.
Users have left good/bad reviews somewhere.

Forum threads (if you can find one) usually have back and forth discussion, so they can give a good indicator too.
P2P / Torrenting
Unless the p2p or torrent link is:

Posted on an official site.
AND
File hashes/signatures for verification are available.

Then stay away, because there is no way to know/verify what you're downloading.
Official Sources

For Windows, MS Office, Visual Studio or other Microsoft products.

microsoft.com
office.com

If you need Adobe's Photoshop, Premiere or Creative Suite.

adobe.com

And so on...

Trusted Sources.

OS repository/app store.

Windows 10 App store etc.

Online or in-app stores for games.

gog.com
Steam
Origin

Even TRUSTED sources aren't 100% safe
Steam offer games/software from many sources, and for them to test every update and release of every title would be impossible.
A few titles that came bundled with very invasive "anti-cheat" functionality, that could potentially take control of a computer did slip through to end users.
Other curated sources
These could be less secure, so do some checking.
Until 2/3 years ago I used the following two sources a lot. With no problems.  (Before I switched to Linux)

ninite.com
chocolatey

Great for automatically and easily downloading and installing/updating software.
There are loads of alternatives now, but I have no experience with those.
Other OSes

Mac OS X
GNU/Linux
BSD
etc...

All these come with their own built in software management tools in different flavors. Like App stores and/or package managers.
They are usually very safe. Stick to them when ever possible.