You have to update something in the user database, otherwise the whole operation makes no sense.
So, it makes sense to use a token that encodes that information. This way, the token automatically expires itself.
For example let us say that I want those users that have no valid birth date archived to update their birth date (or credit card expiration or whatever). I can set the birth date field to NULL or to a special date such as 0000-00-00 00:00:00, or to the existing, invalid, date (I have some way of determining it's invalid; it's the same way I determined which uses to send the token to).
Then I can generate a token from the user, the birth date, and a secret:
token := user.userId+':'+Crypto.SHA512(user.UserId + user.BirthDate.toLocaleDate() + 'S33kr1t')

So my token would be 31337:10952b847b3c5be46bdbb9c67b2f050f92f59f87cd1af5baf459012593d4ff1639c38a60c2010ee9adeb727d4025897ad9fb25a4d4f46ab8f22f0a64e13f8c94 (okay, maybe SHA-512 is a bit of an overkill).
Users send me the token and I authenticate them for the purpose of updating the information (I might require also to enter their password just to be sure). I can first verify that the token is still valid by retrieving the user info and re-calculating the token. If the supplied token and the regenerated one are the same, the token is valid.
When they update the information, the token is automatically invalidated because it will now be generated from different data.
You can also introduce a time factor by adding the timestamp in the token and in the hash:
31337:202103041715:f3dafa6e87a23baf56ed7e6bc...

Now you can first determine if the token is "too old" (reject immediately with a very low cost, no database check required).


Can a malicious SSH server successfully *pretend* to know a client's public key?

So if the client has no knowledge of the servers public key, and no authority to verify anything, then there is no way to distinguish between the authentic server and a malicious server. Because the malicious server would just generate a new private  public key pair and provide the matching public key to the client and all the match would check out.

However the premise of the attack " equally as capable as S is of presenting itself to C at the IP address where C expects to find S" is unreasonable because every hope would need to be working together to incorrectly route to the wrong ipaddress so the malicious server could manipulate the packets without breaking the tunnel. Not impossible but definitely an edge case.


Is it possible to use Kerberos for SSO in a SaaS application?

The way Kerberos works is by the client (browser, app, PC, etc.) requesting a ticket from the KDC (domain controller) whenever it needs to log in to the SaaS application. The KDC creates the ticket and encrypts it to a key only the service knows. Therefore this means the client must have line of sight to that KDC whenever it needs to log in. Within a corporate network this is completely reasonable and is how many apps have functioned for the last 20 years.

However, what happens if the client doesn't have line of sight, say working from home because of a pandemic? In that case the client needs VPN or a KDC proxy to fulfill the requirement. Not unreasonable, but more infrastructure to deploy. Comparatively things like cloud identity providers don't really have this issue (though introduce their own).

Regarding the security of the symmetric key... Only the KDC and the service should have knowledge of that key, so therefore only the KDC or the service can generate a ticket representing the user. The KDC is authoritative so it's going to issue a ticket one way or another and the service is the thing requiring the identity so who cares if it impersonates something only it cares about? Repudiation might be important on that one for the sake of auditing, though you could argue that if the KDC didn't log a ticket creation did it really happen? Also, in Windows-land domain controllers sign an internal bit of the ticket with a key only the KDC knows so with enough auditing it's possible to prove one way or another if the KDC issued the ticket.

Since only the service knows that secret, the best it could do is potentially authenticate itself to the KDC and from there request a ticket to another service, but it's going to be the identity of the service so it can't impersonate other users. Unless you enable full unconstrained delegation. Just don't do that. A SaaS should never need that.


How should I defend against zero-day attack on SSH?

Setup a port knock daemon which opens the firewall for some time when specific ports are "touched" in some specific order. See for more information Port knocking


whether or not sandboxing and lowering privileges is a good idea

ALWAYS!!! Every time, everywhere (English is weird), isolate your processes. In an ideal world, we'd SELinux the hell out of every application, user, file, etc.

A properly established mandatory access control provides both protection against exploits and detection of compromise when you see patterns in your audit logs that just shouldn't be there, which of course you're always reviewing to correct bad rules or notice something unwanted has happened.

WAF, MAC, firewalls, etc. are body armor for your web server. They make you heavier and slower, and chest armor doesn't stop you from being shot in the arm, but it does improve your survival odds.

AppArmor is a simpler interface to the Linux security modules, and a decent substitute for corralling specific applications that you consider high-risk if SELinux is melting your brain.

  whether or not protecting the additions to a site before protecting the site overall is a good idea

Yes again! The more compartmentalized you can make things, the better off you are. If the a module only needs access to the posts table, provide it a context where it can't access the credential table, etc. It's a lot harder to leak the access you don't have than the access you do have.


How to encrypt user name and password between my website and an Android app?

You don't.

You hash and salt them. However, you should not roll your own implementation. Find a library that supports encryption and use a well known impmenetation of a strong algorithm, such as BCrpyt, or PBKDF2.

There's plenty of information out there if you just google for how to securely store passwords in a database. There are plenty duplicate versions of this question on this website.

Here's a link to get you started:
https://crackstation.net/hashing-security.htm

Again, I recommend not rolling your own implementation if you are unsure, and finding a trusted library that uses a strong algorithm to do the work for you.
Implementation mistakes make many applications vulnerable.


How to keep someone from analyzing our site?

If there is no discriminating feature of the traffic that you can analyse for and block, and a WAF is not possible then blocking the IP is your only real option. Your coordinator is correct in that blocking the IP could result in you locking out authentic traffic, so the question is whether the potential for loss from the hacking attempts is greater than the potential for loss from blocking the IP.

Put together some statistics of authentic and malicious connections from that IP. If you have lots of authentic compared to malicious then it's not worth blocking it as you're going to alienate your customer base, however if it's mostly or all malicious you have nothing to lose from blocking the IP and the case is strong.


What are methods to protecting an android phone from law enforcement

You should encrypt the SD card as well. This is optional in Android, so be careful and don't forget this.
With good enough equipment they can freeze your phone (or laptop), and specifically the RAM chips inside. Then they can take them out, connect them to another computer, and read them out.

With good enough equipment... "Law enforcement" (what is that? NSA?) can probably read out the encrypted data from disk (without freezing anything), then run it in a VM and try all PIN codes. It won't take long to find the right PIN, even with 8 digits. A password will be a lot more difficult when long enough, but have you ever tried a long password in daily use? For me it's too much trouble and I'm not a good enough typer wth those crappy onscreen keyboards.


The default installation of debian for the Beaglebone has a user named 'debian' and password is initially set to 'temppwd'.

The first thing you should do is log in as this user, change the password and set a root password. From a terminal or shell use the passwd command and follow the prompts to change the password.

Next, use the command sudo su to run with root privileges - you'll be prompted to enter the user password - and again use the command passwd to set a password for the root account.

With your passwords changed you should thereafter not log in via the root account unless you're performing actions that require administrative privileges. All services, for example a web or file server, should run from a non-privileged user. You can even create users to run services, to isolate services from one another.

You may also wish to remove the default user account from the sudoers file, which can be done by running the visudo command, deleting the entry for that account and saving the results.


Does a hash have more than one possible original message?

Is it theoretically possible that I could come up with two (or more) completely different inputs that generate the same output, since there are infinite possibilities for an input and only a finite number of characters to work with for the output?

Yes, its theoretically possible. But hash functions are so designed to make it practically difficult. When I say practically difficult, I mean it will take immense compute cycles (which translates to money and time) to compute a collision.

  If yes, what is the likelihood of finding another input that would generate the same output?

This depends on the hash functions. The property is called Collision Resistance

To depict via an example, lets construct a hash function which hashes numbers into a resulting smaller address-space [0, 9].
Our simple hash function is hash(X) = X mod 10. Hence

hash(10)   = 0
hash(1864) = 4

This is a valid hash function but has very poor collision resistance.
For example, hash of 24 and 1284 is the same. If you are relying on the hash(4 in this case) for the integrity of the message, a attacker can safely replace the message 24 to 1284 which hashes to the same value.
This particular attack is called a Preimage attack Preimage collision resistance is a prime property of any hash function.


What are mitigation techniques against Cache-timing attacks on AES?

It's not that creating a constant time implementation is inherently problematic, it's mostly a matter of efficiency and awareness.

The table based implementations are fast. Constant time implementations are possible, but tend to come at the cost of reduced performance compared to the table based version.

Additionally, and the more likely culprit, is the awareness level of the implementer of the existence of cache timing attacks. This is not something that is immediately obvious to the uninitiated. Implementations that are constant time are generally not so by accident - they were written that way with explicit intention by the implementer. A good example is bearssl.

Lastly, many modern CPUs have the AES-NI instruction set, which basically offloads the AES computation to a dedicated hardware circuit, and should run in constant time.


If a MITM has your public key and you are SSH-ing through the MITM, what is the maximum attack it can perpetrate?

With SSH, the server key pair is actually used for signatures: the server sends to the client a piece of data and signs it. By verifying the signature, the client makes sure that the piece of data is really from the intended server. That "piece of data" contains a Diffie-Hellman public key that the server just generated, and the client uses it to do the cryptographic key exchange.

To succeed at doing a Man-in-the-Middle attack, the attacker must either obtain the DH private key (but tough luck on that; the server keeps it, and rebuilding it from the public counterpart is way too expensive to be actually done with actual technology), or feed the client with a fake DH public key for which the attacker knows the private part. But the client won't accept a fake DH public key from the attacker, because that fake will not be signed with a signature corresponding to the server public key (the "permanent" public key, not the DH one).

To be brief, everybody knows the public key; it is public. It is not a problem if the attacker knows the public key. What would be a problem is if the client did not know the server's public key, because in that case the client would not be able to verify the signature from the server. Without this verification, the client can be embezzled by the attacker with a fake DH packet, and the MitM attack succeeds.

The client "knows" the server public key by remembering it. This is the reason why the first connection to a server is critical: at that point, the client does not know the true server public key yet. The client is supposed to verify the key fingerprint by (for instance) phoning the server sysadmin.

All of this relies on the magic of asymmetric cryptography:

You can verify a signature with the public key, but producing new signatures requires knowledge of the private key, and the private key cannot be (practically) deduced from the public key.
The DH key exchange consists in publicly exchanged messages, sender and receiver finally agree on a "shared secret" obtained by processing these messages, and yet someone observing only these messages cannot recompute the same secret.

Mathematics are involved.


Absolutely. Given that you can modify the firmware on a router, you could infect it with a virus if you were so minded. DD WRT is Linux-based; some routing equipment uses OpenBSD or one of the other BSDs.

However, generally speaking, routers are fairly stripped down pieces of kit - i.e. they run very cut down versions of Linux, or OpenBSD - and as such, the attack surface is much, much smaller than your desktop - in English, there's fewer places you're likely to find a security hole. Short of persuading a user to upload a malicious update, your average router probably doesn't have that many vulnerabilities in it, especially when the default configuration is to drop all incoming connections (connections that originate from the internet side of the router).

That's not to say people won't try though; for example, there have been a number of published exploits against Cisco kit, for example this one.

There is also a value-of-target factor to consider. With home routers, there are many different possible configurations and no standard operating system; they're not even guaranteed to be running x86 processors - I'd suggest an ARM variant would be more likely. Cisco kit is likely to be a much more attractive proposition since there is a lot of it in big businesses and the software on it is likely to be similar, meaning attacks might work across multiple models. This is the same idea that attacking Windows is a much more attractive proposition than attacking Linux, because there are many more Windows installs to target.

If you're asking "is my router likely to be compromised?" I'd say the chances are pretty slim. If you want to check if exploits exist, have a search for vulnerabilities against that model and see what you find.


How can I generate a list of all passwords that apply to a specific rule?

Use Crunch.

It's a Linux tool, you can find it pre-installed on Kali Linux, check this
 link for more info.

For example, you can use the following syntax to generate your requested rule:

crunch 6 6 -t @@@%%% -o output.txt

the result will be saved in output.txt as the following:

aaa000
aaa001
aaa002
aaa003
aaa004
aaa005
aaa006
.
.
.
zzz992
zzz993
zzz994
zzz995
zzz996
zzz997
zzz998
zzz999

Be aware that using larger syntax will generate a huge sized files.


The vast majority of web applications do not allow query stacking. With PHP/MySQL application can allow for query stacking if you use the mysqli::multi_query()or mysqli_multi_query() functions.

You can exploit these systems using sub-select,  union-selects, blind sql injection,  into outfile, or  loadfile().  SQLMap and Havij are both tools that automate the exploitation of SQL Injection. SQLMap is a great tool with a wide range of features, and supports a wide verity of injections and DBMS'es.


How much information can be sniffed at tor exit nodes

Every unencrypted thing that passes through that exit node can be seen, for as long as you use the node.  That means plain http, but it also means POP3, SMTP, and IMAP email, telnet sessions, etc.

Things that cannot be seen: your IP address, the contents of anything going over https or other encrypted protocols (but various side-channel attacks, such as monitoring packet sizes, are possible), or hidden service connections (those don't use an exit node).


will all instrusion dectection will become host-based?

If I understand your question correctly, then yes.

If you use network-layer encryption on all traffic, for example ipsec or SSL/TLS, then any network-based IDS/IPS will have limited ability to detect application-level (or any upper layer) attacks on your hosts, because it's encapsulated/encrypted. If this is the case, then having some form of a host-based protection is your best bet.


Is there any way to detect Phishing and Deceptive page ( social engineering )

As long as you

allow javascript
or allow forms
or allow storage

then you are providing an exploitable asset for phishers.

As for detecting such sites...there are various approaches you can apply to catch the low hanging fruit such as word checking and bayesian filtering. You should also be monitoring your hids to see when new content appears.

But if it were me, I would also inject a (smallish) floating banner with something like "hosted by badr" into the html pages.


Is storing a private key in a device as it was done in AirPort Express the right solution?

I think, like all security design choices this one came down to risk versus cost to do something different.  The first question they need to ask is, what are they trying to protect?

Apple aren't interested in encrypting my music as it streams to the speakers, they're merely trying to protect a revenue stream which relies on only authorised manufacturers knowing the private key details.

The main threat to this is obviously exposure of the private key. So, where should they store the private key? They really only have a couple of (practical) choices imho.

1) On the device

2) On the Internet (yay - I didn't say cloud!)

If they store it on the Internet, effectively we're dealing with something akin to a Certificate Authority. An example process could be when you set up the devices they dial home with some form of key signing request which results in a key they can store on the device which is effectively unique to it but which can be validated by the AirPlay compatible software which has the public key for Apple's "CA". Google "web of trust" if you need more info, though it sounds like you understand this stuff.

That's quite a lot of overhead for something they are trying to sell in bulk and for about £60 each. So I guess they chose to store the key on the device and leave it static.

Next then, they evaluate ways in which they think the key could be exposed if it's on the device. Two main ones spring to mind:

1) Network software based attack

2) Physical attack

So now, what mitigation do they have in place for these?

In both scenarios the key, as I understand it, can be replaced by software updates, albeit this is reliant on end users to actually install the updates (not too big a problem - just bundle the update with some cool new feature they were developing anyway and most people would upgrade in a flash - no pun intended).

A physical attack would require specific equipment and knowledge, not necessarily complicated but let's face it, beyond the desire of most people to bother.

They also add the paperwork control by expressly forbidding people to "reverse engineer" the key.

If they really wanted to go to town, they could have made the AirPlay devices tamper-proof with something like the FIPS 140-2 standard but again, this seems massively excessive for a cheap consumer unit.

So, to answer your questions specifically:

Was this use of asymmetric key cryptography right? - I believe so, based on a risk analysis, similar perhaps to above.

How should it have been implemented to make such attack impossible? - maybe as I outlined with an online key signing or similar but really the point is, nothing is impossible when it comes to encryption. You need a key and it has to exist "somewhere", there's always a risk. What we are actually trying to do, like with all security design decisions, is mitigate the risk to the lowest acceptable business level.

HTH!


User authentication in JavaScript application

What you describe here is pretty much the equivalent of classic cookie management (besides the parameter issue, see under)

When done on SPA applications like yours, usually the session ID (the token you describe) is part of an HTTP header.

I strongly advise you to avoid sending the session ID as a parameter as you are currently describing. Notably, because :

browsing history (client-side) would disclose the session ID and facilitate session hijacking
server logs would contain session ID's and facilitate session hijacking

Using HTTP headers instead mitigates those issues.

  We always use .NET MVC for now, and store user information in server session, but this is new situation, where client didn't run on server directly,

About this : make sure that all your validation always happens at least server-side (and optionally client-side), and that sensitive session information stays server-side as well.


Is it possible to track by Bluetooth headphones

Not unless you are in range of the device.

And even then, there are caveats, such as

You can only track signal strength, so you need at least three measurement devices to track a location approximately.
You can't know if a one MAC address corresponds to one or multiple devices.
You can only track if Bluetooth is activated and actively sending out beacons or responding to requests


What is the advantage of using jump servers for security reasons?

Jump servers, or more accurately, bastion hosts, provide a segregation layer between the target network and the user. Consider a network with database servers, application servers, an HSM or NAE for PCI, and monitoring systems. Without a bastion host, this needs to be exposed for maintenance and monitoring of these systems. The bastion host provides an auditable layer for users to access these systems. It also provides a separation of duties. Devops will need to access the servers, but Marketing typically won't need access.

Look at this basic network diagram without a bastion host:

Any user on the network can access, and potentially attack, any server in that network. But by employing a bastion host, controls can be put in to place:

  How can I use two-factor authentication with jump servers?

Check out libpam and configuration with TOTP.

  Why do jump server need virtual machines?

They don't.


Receiving S/MIME signed emails with Gmail

Gmail mangles S/MIME signed only messages. Before 2017 it was done for multipart/signed from summer 2017 it has started for signed-data as well.

Looks like it's done in a favor of G Suite subscribers and there is no hope that Gmail team will fix it.
https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/gmail/RUBO_qtA5nM/FclopwMZBAAJ


Can JS templates for admin-only pages be public

Usually static resources are served from within the web root and are findable by unauthenticated users.

If there's no sensitive information stored in these files (and from a security point of view I'd say that there shouldn't be) then this shouldn't really be a problem. An attacker could view the contents of the file if they can guess the URL for a valid resource, but if the files have no security significance it shouldn't really matter...


There appears to be a proof of concept on github:
https://github.com/sasqwatch/cve-2019-11477-poc


Effectiveness of Interactive Application Security Testing

Each method (DAST vs SAST) has its strengths and weaknesses.

For example, DAST method is much better positioned at evaluating XSS type vulnerabilities because it is actually able to execute "on the client side" to validate if execution is indeed possible (rather than benign reflection).  SAST in this case for the most part is limited to proving that input made it (or has a possible path) from source to sink and can be reflected back in the output, but typically wouldn't be able to confirm that reflection can be executed to deliver XSS payload.  In this case DAST has some advantages over SAST.

OTOH, detecting vulnerabilities such as a password input being written clear-text into backend log file would prove just about impossible for DAST scanner, but a manageable job for SAST analysis.

So IAST (or sometimes referred to as hybrid) can take advantage of strengths of both methods and help manage/reduce inherent weaknesses of the other.  It can also help reduce false-positive detection rates by having one method confirm the other (e.g. in dynamic testing of SQLI having confirmation that attack indeed made it to DB); help speed up testing by narrowing attack surface (e.g. no need to test a page for SQLI if page doesn't do any SQL), actually discover attack surface that may be hidden (i.e. sub-application or pages that are not linked to and are not easily discoverable in the blind), etc.

Disclaimer: I used to work for and develop one of such scanners.


Is this what a brute force SSH attack looks like?

Is this a bruteforce attack

This looks like the background scanning that any server on the internet will experience.

Should I be worried

Not really, background scanning is completely normal, as long as your passwords are secure background scanning should pose no risk.

What are the best mitigation steps

You can use the following to make the server more secure:

Only allow login using key auth
Disable root ssh access
Use a system like Fail2Ban to block brute force attempts

Should I change IPs

Changing IPs will probably not affect automated background scanning much


Is there a threshold of bits of entropy below which hashing becomes meaningless?

For a login function, you should aim to get the hashing process to take around a second.

If you take this post as a guide, 1170ms requires around 8,192 iterations of bcrypt (cost of 13).

This means that your iterations add around 13 bits of effective entropy.

If you have only 31 bits of entropy in a secret, hashed value, then this bcrypt configuration would give you 44 bits of entropy.

As a guide, 47 bits of entropy would take 0.223 Hours maximum to crack per phone number (assuming at 350 billion guesses/Sec). Even if the attacker didn't have these type of resources and they guessed at 2 billion guesses/Sec using a single home PC, this would take 39 hours per phone number to crack.

So, to answer your question, it doesn't make sense when you either need to increase the hashing time to an unacceptable level (a cost of 16 to add 16 bits would be over 9 seconds, what you would describe as harmful to your application), or that the cracking time per secret is below your goal for the sensitivity of the information it is protecting and the resources of your perceived attacker.

If it is acceptable for each phone number to take 39 hours to crack by a casual attacker, then there's no problem with bcrypt at a cost of 13 . This is assuming they are using bcrypt with said cost and not simply storing SHA1(salt + number).


How to test DoS attack by sending unsolicited ARP packets over ethernet?

I uploaded an old python script of mine right here.
This piece of code is very basic and clearly not a masterpiece, it just answered my needs few years ago.

I recommend you to look and understand how its done, then build your own tool.

I'm not sure this old lazy script still work, but you can get the idea of how you can use the scapy lib.


Should a hostname ever be considered a secret?

Two reasons I can think of:

Attackers will know which servers are more valuable to attack. e.g. TEST_BOX_04 vs DB_BACKUP_02
Attackers will have better idea of the topology of your network: How many servers you have; which other servers probably exist because semantic implication (host03 implies host01 and host02); what style of application stack you have (eg. web_app_server implies 3-tier; cloud_proxy may imply 4-tier); and which company assets are being allocated dynamic vs static IPs (valuable assets tend to have static IPs)


How do private feeds get transferred between two different portals?

I think you should use some kind of tokenning system, if a blogger want to share his RSS feed with another blogger he just has to give the token to the other user, or even better generate a unique token for each reader.

Something like :

http://www.website.com/flux.rss?key=549424e1778e55c0dbfb8bd4a2f6877330b9a46b


Possible to send password in plain text with SHA-256?

First, if you're worried, contact your bank and request a new card number, right now.  Then change every password you use that's the same as, or similar to, what you sent them, on every site everywhere.  Then terminate your account with them.

Second, the SHA family is a set of hash algorithms.

Third, they're lying, by omission if nothing else.  If they truly did use any form of SHA-256 on your password, then they cannot send it to you in (probably unencrypted) email

Unless they ran an offline cracker themselves, AND your password was P@$$w0rd, Jennifer2007, 12345, or something similar.  Without a weak password, SHA-256 will take a bit.

Fourth, unless they're using PBKDF2-HMAC-SHA-256 with a high iteration count (i.e. slow down offline attackers), then they're STILL doing it wrong if they're using SHA-256.

Fifth, either they're storing passwords in plain text, or they really are using encryption (instead of hashing), which is What got Adobe in trouble in 2013, and is wrong.

You are correct, they SHOULD NOT be able to retrieve your plaintext password from their storage.

Also, they shouldn't send it out over potentially unsecure email even if they are storing it.  Double stupidity for the loss!


Can computers built in minecraft be used to hijack hosts?

That just sounds like a Minecraft exploit with extra steps...
If that ever becomes possible, then the issue is not the "computer" that was built inside, but the vulnerability in Minecraft to allow it. And at that point, you just trigger the vulnerability. No need to go through the work to build a computer...


How to handle personally identifiable information (PII) as a startup?

This is a very broad question, so I'm suggesting a broad answer.  Check out the NIST Cybersecurity Framework, which is a comprehensive plan you can follow to help ensure you're covering all the bases.


The quick answer is "no".

Each anti-virus vendor examines the malware samples they find, determines a detectable "signature" for each, and creates a name for the malware.  Malware names are often derived by the examiner who is looking at the unique text strings contained within the malware.  Every few days they send an update to their paying clients with the new signatures and labels.

The anti-virus vendors don't often cooperate with each other because they're in competition.  If my WowAV!! product detects 1,000,000 viruses, that's a reason I can market to people why they should buy my product over the competition, YawnAV, which only detects 900,000 viruses.  So they don't share names, they don't share signatures, they don't share analysis.


Is it good practice to delete old accounts?

Every account you have most likely contains personal (and potentially financial) information about you in one way or another.

The more accounts you have with different websites, forums, games etc, the increased chance that one of these accounts could be involved in a data breach.

I don't see a downside in deleting old accounts.  This minimises risk, minimises your digital footprint and if you aren't using them then it shouldn't effect you if you get rid of them.


Can't execute shell i uploaded with cURL

You get the file contents in curl because you are accessing the file directly without the server executing the contents.
You are not getting the shell in the browser because the PHP server is trying to show you a jpeg file that isn't a jpeg file.
It's not working because the server is not vulnerable to this problem...
Just because you can upload a file does not mean that the server will do what you want with it. It will handle the file based on its own rules.


Why does Canonical not enable https here?

Ubuntu images are available from lots of mirrors which are out of control of Canonical. That means you cannot trust the image itself because it might be that one mirror is compromised and is distributing modified files. That's why Canonical offers signed checksum files like SHA256SUMS.gpg which are cryptographically signed so you can verify that the image is actually the one released by Canonical.

Nevertheless would it be of course much nicer if they provide their own mirrors with https and if they also provide detailed instructions how the download should be verified, instead of just downloading the image without any kind of obvious validation.


Wired VS Wireless Mouse & Keyboard Security

USB mice and keyboards are generally "safe" from known vendors and distributors, but then again you cannot really trust anything. nation state etc etc.

The Bastille research is based on wireless keyboards and mice that do not use encryption, or at least, does not force encryption (downgrade attack) or uses weak keys. This is the key point on the wireless keyboard.

So your options, use a built in keyboard or a wired keyboard or a keyboard that forces encryption only with strong non-reused keys. (good luck)

unless you build your own keyboard you will have to trust things, not sure on PS/2 security, but you could always go back to that!


Protecting Python source code on physical product?

Anything you do to obfuscate your code is a waste of time. It can be reverse engineered and I promise you anyone that wants your intellectual property will take the time to deobfuscate it.

One solution you might look at is http://cython.org. Cython converts your python into C so that it can then be cross compiled for each platform natively. If you want to hide your code this is your best bet. I know of at least two companies doing this for production python code.


Apache logs, suspicious logging apach0day

Proxypipe.com is hosted by Voxility S.R.L (AS39743)(AS3223). Voxility is known to be a bad hosting company by allowing the hosting of malware, sending spam, executing DDoS et cetera, from their IP's.

It is best to block all their IP ranges otherwise you will possibly be dealing with DDoS attacks. I experienced this all day long before.

You can find a list of their IP ranges here Voxility (AS39743) and Voxility (AS3223)


If there is no WLAN hardware present, then by definition your laptop cannot possibly have WLAN capability.

But you then ask a slightly different question: "How can I be sure I have disconnected my computer from the internet?". You would guarantee this by ensuring there is no hardware that is capable of network communications. Here's my suggested guide for the paranoid:

Remove any USB WiFi "dongles".
Remove any network cabling.
Visually inspected the motherboard to rule out any PCIe (desktop) or Mini-PCI/Mini-PCIe (laptop) wireless cards.
Continue inspecting the motherboard to rule out any WWAN cards (that allow internet connectivity just like cellphones).
Continue inspecting the motherboard to ensure it does not include built-in WiFi (many modern motherboards still don't).
For good measure, enclose the computer in a faraday cage with the mesh sized to block WiFi frequencies. Incidentally, microwaves emit the same frequencies, so you can just buy microwave oven shielding in bulk :)
Bonus points: Modify the operating system and remove the network stack.

Congrats, you have now air-gapped your machine! If you've done all this, and can still get internet connectivity, I'll give you a million dollars.


Depends on the web server and the operating system, for example:

The Apache web server on Linux would store these in flat files in a dedicated directory, which is distribution-dependent, e.g. /etc/apache2/ssl. You can choose a custom path in your virtual host definition, so the path/location is more of a convention rather than a standard or a requirement.
Apache Tomcat, for example, uses a key store, which is encrypted using a symmetric key, and typically the specific SSL/TLS configuration file will contain the key store password.
IIS on Windows may use a variety of certificate stores, most of which are physically located in the Windows registry.

As you can tell, the implementation varies from one platform to another - from flat files, through an encrypted database-like file, down to an OS-provided/managed specialized certificate store.

I hope this helps.


Why is CAcert not trusted by my browser?

In case of cacert.org, they are presenting a self-signed certificate and that's why your browser complains. There is no trust chain that leads from the certificate to a root CA that you trust.

If you were using a Linux distribution that comes with their certificate pre-installed, you wouldn't see a warning. It would be inferred that by using such a system you trust the community.

In case of other OSs you put trust in public PKI that is supported (and provided in the form of a root certificate store embedded in their products) by Microsoft, Apple, Google, or Mozilla.

Cacert.org is outside of this infrastructure and that's why you see a warning.

Why?

Their "business" decision. They are free to do whatever they want when they provide web services. They could ask users to install their root CA, they could invest money and get a signed certificate for their website, or not invest and get a free letsencrypt certificate*.

They chose the first model, seemingly because that fits their purpose and "eat your own dogfood" idea.

What you can do?

It depends on what you want to do. You can access the site with http://cacert.org/ and read.

If you want to access it with HTTPS, you can display the provided certificate, examine it yourself. Then take your own decision to trust it.

The tricky part is that it indeed could be a MitM attack, so you should compare the fingerprint signature of the certificate you got with a signature you obtained through another trusted connection. They publish the fingerprints here but until you trust real them, you can't really trust the site belongs to real then. Catch 21.

You could either confirm the signature with another source you trust (friend, or just search google for the fingerprint you got and evaluate, if it's all over reliable places, it has chances to be valid) or use Debian that comes with their root certificate pre-installed to access the site over HTTPS.

You can then follow the link to instructions how to install their root CA, install and trust the certificates they signed from now on (including their own one).

* Technically they could use a certificate recognized by public infrastructure for their site and avoid the problem of initial trust, but maybe they decided that making you ask such a question is better for the spread of knowledge...


Why does McAfee think Stack Exchange is malicious?

Can someone one please enlighten me as to how mobile McAfee determines
  a site is dangerous?

This can be found in the SiteAdvisor Site Ratings Policies:

  What Is Rated? How Is It Rated?

  We test the following attributes of a
  site. Red, yellow, and green scores are computed from the outcome of
  these tests.

  Downloads We test downloadable software that is hosted by and directly
  linked to from a site. We use our award-winning McAfee anti-virus
  engine to determine if the file includes malware, such as viruses,
  Trojans or adware. We also test for program behaviors that we deem to
  be risky or merit a cautionary note. Behaviors can include resetting
  the browser's home page, adding toolbars or desktop shortcuts or
  contacting 3rd party Web servers. Based on these results, we score the
  site's downloads accordingly.

  E-mail practices We test sites for e-mail practices by entering a
  valid, unique personal e-mail address into a site's e-mail form. Then
  we measure any mail that is received at this unique address. We score
  the site according to the quantity of mail received as well as the
  "spamminess" of those e-mails. Spamminess is a measure of the mail's
  commercial content, as well as the presence of tricks used by spammers
  to try to escape detection by spam filters.

  Browser exploits We perform tests to detect the presence of exploits
  on a site. An exploit is any content that forces a web browser to
  perform operations that the user does not explicitly intend.

  Web reputation McAfee tests websites for web reputation using the
  TrustedSource™ system. This system collects security data from tens of
  millions of sensors located in more than 120 countries. McAfee's
  proprietary technology analyzes traffic and linking patterns, website
  behavior, content analysis, site registration and hosting, to develop
  an overall reputation rating for the website.

  Annoyances When we visit a site, we record how many pop-ups occur and
  how many cookies we receive. In addition, we monitor prompts to change
  a browser's home and search page settings.The presence or cookies is
  only noted. Cookies do not affect a site's score.

  E-Commerce McAfee tests sites for the following e-commerce issues:

  Phishing: We use proprietary, award-winning real-time phishing
  software to evaluate whether the site in question is attempting to
  mimic a legitimate business or financial institution.

  Scams: We use a variety of criteria to determine whether a site in
  question is engaged in questionable business practices, such as
  selling rogue anti-spyware.

  Links (online affiliations) We collect information about the URL links
  posted on a site to determine whether the site is affiliated or
  effectively directing traffic to another site. We rate a site based on
  our estimation of the risk users could experience if they used these
  links to be led to other risky sites.

As for what triggered the rating for the site you are trying to access, we can't really tell as the SiteAdvisor rating itself does not seem to provide any further information on what specifically was wrong with the site (no mention of the attributes that they supposedly use to determine the safety of the website).

A simple search for 'siteadvisor false positive' on Google should reveal that SiteAdvisor has a notable history of providing misleading ratings and taking embarrassingly long times to resolve complaints. Given the reputation of StackExchange sites, the rating for the site in question is also probably just a false positive.


The attack you mention isn't really all that scary or surprising.  It doesn't actually attack the encryption used by the devices, but rather the pairing process.  When you pair a bluetooth device, an encryption key has to be exchanged.  This is done by deriving an AES key from a PIN number.  They effectively try all pin numbers against a recorded pairing session in order to recover the AES key that is used long term.

If you establish the pairing for your device securely (in an environment free from attackers), then this attack will be useless, as once the encryption key is exchanged during pairing, it is used for future updates and the key exchange doesn't have to be repeated.

I would rate this vulnerability as very low chance of issue.  It could have been avoided pretty trivially by having client and server each choose half of the key for the exchange, but it isn't a huge deal.


Azure supports different kinds of VPN connectivity.  You can set up not only a site-to-site VPN, which is what I suspect is what you're currently thinking that will create a network-level link between your corporate network and Azure, allowing you to securely route traffic to Azure without having to worry about your ISPs policies, but you can also set up a point-to-point VPN connection, which sounds like it may be all you need given your stated requirements.   In this configuration, the machine or machines(s) that are going to be pushing new files to Azure would have the VPN client and could set up and tear down tunnels directly, and only as they need them to push updates or manage the Azure environment.  This way you don't need to have a persistent network level route to the Azure infrastructure that could be used for traffic outside of what you intend and believe you need.

There are other ways that you could set up your network to limit the capability to access the Azure resources, but a point-to-point VPN is likely the simplest and easiest to manage.


This looks like a Data Loss Prevention (DLP) system in which DRM is applied to documents. While I haven't assessed Fasoo itself, I have assessed five or six different enterprise DLP solutions over the years so I can make some inferences about how it works and how secure it is.

In my experience the answer to your question is "pretty much nothing stops you from leaking documents". All DLP suffers from the analog hole (e.g. someone taking a photo of the document on their screen using their phone), and most DLP solutions offer little security against a determined attacker. They're better at detecting accidental leakage, such as a sensitive document being dropped onto an open file share, or emailed without proper encryption. DLP and DRM are inherently broken objectives on a general-purpose computing platform.

Document tracking tends to utilise similar tricks to canary tokens. The document has some element embedded in it that causes network traffic to be sent whenever the document is opened. This can be something as simple as a hidden 1x1 pixel image inside the document, loaded from a web server. These don't stop you from exfiltrating a document, but the idea is that it catches an unwitting attacker opening the document from an unauthorised location.

The DLP part generally works by storing fuzzy hashes of document contents in the DLP server's database, then giving it access to all shared directories and outbound network traffic so that it can try to find documents that have been put in the wrong place or that are being exfiltrated from the network. This usually involves TLS inspection at the gateway. In addition, for an enterprise DLP solution like this, there are sometimes hidden byte sequences injected into the document file that can be caught by detection agents on the network during file transfers.

In most cases DLP is a bit of a misnomer, since it's much more adept at data loss detection than data loss prevention. Even then, it isn't great. I've exfiltrated gigabytes of faux customer data to file sharing websites and even pastebin on DLP-enabled networks without a single alert going out. It usually suffers from the same problem as IPS solutions - either you turn the reporting levels down and never catch anyone, or you turn them up and get flooded with false positives until your security team just ignores everything. Configuring and training DLP solutions is a very long and arduous job that rarely gets done properly.

The remainder of the software implementation is likely little more than a document storage webapp with audit functions and some enterprise integration features like tying user accounts to AD accounts or an SSO platform.


DVWA separates each vulnerability into its own page.  Each page is accessible on the menu to the left.  Each vulnerability is a textbook example of the flaw,  there should be nothing strange going on so any documentation on that vulnerability is useful.   If you don't understand the very basics of a flaw,  then I'm sure OWASP has a page on it.  You could also try and find an exploit for the specific flaw "in the wild" (like exploit-db.com).


First of all, the antivirus should have performed the cleanup itself if it's worth its salt. Just to be sure, you can safely wipe your USB key with the following command:

sudo dd if=/dev/zero of=/dev/[device]

...[device] being your pendrive of course. You'll have to format it again afterwards. All your data will be overwritten, though.
Whether the virus can be harmful to your Linux machine, I'd say "most likely not", but I don't have anything to back that up.


Is it bad practice to use the same password for multiple accounts on the same website?

If you consider a breach of the service and passwords are properly handled on the authenticating side, the attacker who gained access to the password database is left only with the brute-force attack.

Brute-force attack means checking exhaustively all possibilities, but does not limit the method to the dumbest "from 0000 to ZZZZ" one. That said, an attacker who expects users might create multiple accounts with the same password can easily modify the algorithm to check all accounts against each discovered password.

Whether this is an issue depends on you.

If you consider an attack on the client side, an attacker needs to learn one password from among multiple account-password pairs to learn all of them.

If you login to all accounts from the same machine, the attack surface remains constant, but if you use one account on a mobile device, the other on a secure PC, then one compromised device reveals the information about all accounts.

Again, given that you expressed the idea means other people think of it or do it too, and an attacker would probably take advantage of that (the cost is nil).

Whether this is an issue depends on you.


Does installing undercover (macbook theft software) increase risk of attack, privacy breach

The vendor getting a bunch of certification means they are trying very hard to improve perception. But if you don't trust the vendor, all other discussion is moot.

Even if you do trust the vendor, consider the following:

This sort of software will get privileged access to various parts of your system. Even if the vendor has the best intentions, their own software can be compromised, indirectly letting an attacker access your system. Even if the vendor is honest, a third party can abuse an exploit in the vendors software to get to you. Since it adds a new attack vector, it can be considered to be increase the risk.
It could very well increase the likelihood of a privacy breach. Consider, as an example, that many antivirus companies trade user data. Some, like Avast are open about it. But as recent news indicates, companies cannot be trusted to disclose everything that they do with user data. So assume that you just won't know if there is a privacy breach.
Your trust in them is (should be) based on their current policy. They can change policy/strategy if it suits their business interests. There's also no guarantee (independent audit with complete access to the vendor's systems, etc.) that they actually follow their own policy. You don't even know if the whole company actually believes/practices the policy.

The bottomline is that yes, it increases both the security risk and privacy risk. But the important thing to understand is it is a tradeoff. When you access most webservices you trade personal data for it, when you hire a security guard, you give the guard privileged access which can be abused.

Lastly, consider what you really need this software for - to protect your hardware in case of theft. There's no guarantee that this will actually help you recover a stolen laptop. Thus, you can choose to do only one of the following - increase the odds of recovering your device in the event of theft, or increase the odds of your privacy being violated and your system compromised. So you need to compare the relative value of 1) the hardware and 2) the user data on it.


How is the DEK in a SED drive encrypted?

It seems like there is no publicly available information about this specific model of Samsung. However disk encryption of Samsung 840 EVO and Samsung 850 EVO have been studied (among other SSD drives) in this paper. Based on the research Key derivation scheme is built upon:

1 - Key Storage

This key storage is aimed to validate the password and to derive the key :

  A password candidate p' is validated by computing PBKDF2(HMAC_SHA256,
  p', Sverif). Then, the result is compared against the stored
  PBKDF2(HMAC_SHA256, p, Sverif). If they match, then p = p' is assumed.
  The derived encryption key is then obtained by computing
  PBKDF2(HMAC_SHA256, p', Sderiv).

2 - Crypto blob

This bloc is 64KB and it holds all information related to disk encryption including DEK:

  From password to DEK Samsung’s Opal implementation allows a total
  number of 9 ranges and 14 passwords to be specified. The password is
  fed to the validation/derivation function, using slot 478+u, where u
  is the user id associated with the password. Once the password has
  been validated, the derived key is then used to decrypt an entry in
  the password ↔ range mapping table. The entry is located at slot 0 +
  27u + 3r, where u is the user id and r is the range number. Finally,
  the decrypted result is used to decrypt slot 456+r, yielding the DEK
  for range r


Isn't this the same as using a certification authority?

What you're describing is called certificate pinning; essentially, you ignore the whole CA process and just give the user application a certificate to trust. It's actually widely recommended for non-browser applications (e.g., mobile apps) for the exact reason you stated - if you rely on a CA and it goes down, you're in pretty deep trouble, whereas it's relatively easy to fix it quickly with certificate pinning by pushing a new certificate. Or better yet, you can have two certificates in your app, and rotate them if one goes down, then push a new certificate in the next update.

Of course, web browser makers can't amass and verify a collection of everyone's certificates ever, so they choose to trust a few centralized servers that then verify everyone else, and this is mostly successful at keeping users out of trouble. That's why the CA system exists.

I should clarify that you're still trusting a third party - it's just a different third party that doesn't charge you for the privilege. For instance, if we're talking about an iOS app, the app is signed by the App Store. That's what's preventing an attacker from swapping out your hard-coded certificate with another certificate.


Heroku is a platform as a service offering, your code will live in virtual containers, this means that it is better isolated from other containers running in the same server (speaking strictly about direct file access).

The way to store secrets, as you pointed out, is to use config vars. The heroku documentation specifies this as the secure way:

  A better solution is to use environment variables, and keep the keys
  out of the code. On a traditional host or working locally you can set
  environment vars in your bashrc file. On Heroku, you use config vars.

You can in fact keep files outside of the public folder by specifying the Document Root of your application. This will set the folder where the web server will look for your php files. The web server will reject direct internet access to files outside of the Document Root, your code may still introduce vulnerabilities that allow this but from a configuration point of view this is the way to go.


Good way of storing lots of third-party passwords

There are off the shelf secure solutions for this.

You could store the passwords in a password manager like Hashicorp Vault or Thycotic Secret Server and use their APIs to retrieve and use them as needed for scraping.

Rolling your own is also an option. Adapting the example from this blog about using Amazon KMS with DynamoDB is one straight-forward option for doing that if you are using AWS and have Java programmers on staff.


Remote Administration Tools and firewalls

There are two types of Remote Administration Toolkits: those that are used for legitimate purposes by the system administrators and those that are used by the malware for controlling the PC from a C&C server. You have used the malware tag in your question so I assume you want to know the working of the second type of RATs I mentioned.
When malware infects the machine, usually a small stager code contacts its parent server and download the rest of the code. Note that the connection is initiated from the victim's PC to the attacker's controlled PC. This is called reverse connection which most of the firewalls allow. The connection is initiated on those ports which have a very high chance to be allowed outbound such as port 80 (HTTP) and port 443 (HTTPS). Also, even an application layer proxy examining and blocking non standard traffic on standard ports cannot block these connections because nowadays the RATs uses standard SSL connection stream.
The only chance of detection these outbound reverse TCP/HTTP/HTTPS connections are through blocking the IP or DNS addresses of the C&C servers. This method has only a reasonable chance of blocking the connection and will work against only the most basic attacks since malware can use a variety of techniques to hide their C&C servers. Fast flux and TOR hidden services can be used to hide the C&C effectively and can't be blocked easily.


Does it make sense to put a firewall within a LAN to protect sensitive information from the rest of the LAN & Internet?

It is a perfectly normal approach to split a network into zones (network segments) of different security requirements and have firewalls between these zones which limit the communication possible between these zones.

It is also perfectly fine to cascade firewalls, like have a firewall from your main network A to the less secure network B and from there another firewall to the even less secure internet. It actually adds security since an outside attacker would need to compromise two firewalls instead of only one (and there are still too many bugs even in commercial systems where a firewall compromise was possible from the internet).

A cascade of firewalls might give you trouble with some applications like VoIP if these firewalls are all doing NAT but from the security perspective it is fine.


Web Service Authentication Using PBKDF2 and a Public Salt - Does the salt need to change on every request?

The point of using salt is to prevent brute force attacks against multiple passwords at once. If they all have different salts your dictionary or rainbow table is only valid for one specific salt.

So, indeed using different salts for the same password is not helpful.

N.B.: If somebody can break TLS connections they will probably attack something more interesting than your webapp. ;)


This is largely an opinion-based question, as no one knows for sure, other than the well-informed in underground markets for selling such exploits.
This does make a massive amount of sense, and I wouldn't shrug it off.
Doubtless, there will be zero-day exploits right when support is dropped.
It's probably not as large-scale as some would think, but definitely probable.


Generally you would need to find something that will get stored to a appropriate variable in the same service to store your egg. The smaller egghunter then finds the egg you previously saved.


How application-level stateful firewall impacts network performance

First, an application-level firewall is usually always stateful, unless you deal with application protocols where each packet can be analyzed separate from the rest. Therefore one only distinguishes between stateful and stateless analysis with packet filter firewalls but not with application-level firewalls.

The number of packets the firewall can process, the impact it has on the network performance (i.e. throughput and latency) and the limitations in processing depend on a lot of factors, like the complexity of the application protocol to be analyzed, the quality and depth of the analysis and the performance of the underlying hardware and operating system. This means no hard numbers are possible. But in general: the more effort is put into a proper analysis of the protocol the slower it gets but the more secure it gets too. And one can try to make it faster by throwing more expensive hardware on it, i.e. the classical trade-off between performance, price and security.

Unfortunately most vendors and literature only talk about performance and maybe price and not about how deep and solid the application analysis really is and what level of security it really provides. Thus you might have a look at the white papers and sales brochures of the various vendors for some performance numbers but keep in mind that performance and price are only one aspect and that a major aspect of a firewall should be the security it really provides and not the one which is claimed (which is usually "full protection", but the cheaper the firewall the higher is the chance of dubious claims).


Why does localbattle.net point to localhost?

This domain is used by Blizzard (battle.net) for some communication between their web pages and a server running in localhost.

Thus, when the web page wanted to communicate with the local install, it would direct a request to https://localbattle.net:22886/ were the game would be running a webserver. As they owned the domain, they would have issued a publicly valid certificate for that domain, which could then be embedded in the game, while they couldn't have obtained a certificate for 127.0.0.1 or localhost.

Do note however that this was still the wrong thing to do. Since the private key needed to be shared within the game, the private key isn't really private, and such certificate MUST be revoked by the CA within 24 hours of knowing about it (section 4.9.1.1 of the Baseline Requirements).

The public certificate running locally was originally reported by Tavis Ormandy and -after Hanno Böck reported it to mozilla and the CA- the certificate got revoked, after which Blizzard issued an update that installed a local (non-CA) certificate into the root trust store. Then they briefly used a new certificate, issued by digicert which also got revoked, and added to the OneCRL.

The whole story is explained quite well on this mozilla.dev.security.policy thread. If you want to dig up more, you can also read this Reddit thread, and the Blizzard post explaining their change to use a self-signed certificate.


Tracking an anonymous comment back to my work computer

The public IP will lead them to your company's network.  Your company's network administrator may then be able to look at their logs to determine which computer inside the network initiated that outbound traffic.  In general, you should always assume your employer knows everything you are doing on their network.

There are also additional ways to identify you other than by IP.  Depending on how ill-advised of an action you took, these may or may not come into play (posting an abusive comment, probably not; accessing child porn, certainly).


Access Controls on employees handling credit card data

Once an employee has access to this data, you cannot actually control what they do with it. There are useful restrictions, such as:

disallow phones or camera devices
disallow taking papers home
strongly restrict what their computer can access

As well as wider controls such as:

employee vetting
contracts that include major disciplinary repercussions

But you need to accept the risk can not be 100% remediated.


SSL's (security) benefit to the website owner

It prevents the ISP from injecting their own ads in place of your own. If you rely on advertising for revenue, https helps protect your revenue stream.


Is there data on the most common password strength requirements?

... but I'm wondering whether anyone has collected some amount of data gathering the modal password strength requirements?

A Second Look at Password Composition Policies
in the Wild: Comparing Samples
from 2010 and 2016 from Usenix 2017 has collected password policies and strength requirements from many web sites. In this paper you'll find also links to related papers.


This is either just a simple spidering, penetration testing, browser randomization, or a mix of some of those.

Web Spiders

Many web-spiders allow you to randomize your user-agent while siphoning the contents of a website. This is rather trivial to implement, and some of my web spiders do the same thing. However, it is bad design to randomize user-agents while spidering.

Browser Randomization

There are browser plugins such as Secret Agent which allow you to randomize your browser fingerprint values to avoid detection.

Since you are only seeing upwards of 19 attempts, it's also possible they've viewed around 15-19 pages each, but it seems odd that they'd do this consistently. It could even be one person switching their VPN and browser settings for each page load, which would indicate next-level tinfoil hattery.

Penetration Testing

Automated penetration testing tools also randomize their user agents when visiting a page.

Conclusion

Without seeing more of what's going on, we can't really tell you what's happening beyond making a few guesses. Do you have any packet capture data? That would help tremendously.


Best practices for storing 2FA recovery codes

First of all, let's clarify that 2FA recovery codes are used to bypass 2FA itself.

2FA's main purpose is to make sure that you provide a secret from two different "channels", for example, something you know or something you have.
The password is something you know and the recovery codes, if kept in memory (your brain or your computer's hard disk) is also something you know.
Without going into too much discussion about the security of these recovery codes, it seems obvious to me that the "something you have" factor works better when completely outside the virtual world. That is, keeping the codes in a piece of paper, or small pieces of paper for each code, may be the best option IMHO.
Clearly encrypting it and storing it in the cloud or in a separate computer/device/usb may work, but eventually you need to decrypt and access these codes in plain text. In an emergency it may not be ideal or if your systems/network have been compromised, the unencrypted codes might be accessible to an attacker.
Therefore, I believe that if you print the code and keep in your wallet for example you maintain the secure properties of 2FA.
One may need to reconsider it if travelling by plane as the officials might be able to force you to provide your password and confiscate your wallet. So just a note to be aware of :)


How is the initial request made to the Access Server in Kerberos?

Note that it's the Authentication Service, not access service.
Why wouldn't a password be capable of being a symmetric key? It just needs to be the right length. Since Kerberos doesn't require users passwords to be a certain length what actually happens is the password is passed through a key derivation function (KDF). This output is considered the user long term credential. Both the client and AS need to know this long term credential.
What happens is the client sends the AS-REQ and the AS responds saying the user needs to do pre-auth. The client will resend the original request, but then the client will encrypt the current time to the long term credential and stick it in the pa-data list. This is the partial encryption bit. Only the timestamp is encrypted where the rest of the message is cleartext.


Should a webpage where visitors submit e-mail address and phone number be served only over HTTPS?

Personal information (PII) Must be protected.

Name and emails are. IP address can be too.

If it's in your policy, you have to.

In Europe, it's an obligation, like in most countries.

So you must use https.

If you don't use https on all your pages including ones without PII, then you are vulnerable to MitM/sslstrip attacks, so you don't protect them correctly.

You should use https on all your pages and HSTS.


Security implications of client TLS termination

Put simply, the risk is that you won't have TLS between your TLS proxy and the end webserver.

This sort of design is fairly common: plenty of services terminate TLS connections at a load balancer and run plain HTTP from there to the webserver. If you segment your network appropriately you can mitigate the risk posed by having the remainder of this link unencrypted.

Also see this answer.


How secure is WiFi roaming if clients connect automatically to access points with the same SSID and security?

Rogue access points can certainly be dangerous, but there is a caveat:

If the "real" network is encrypted, you cannot set up a rogue access point without knowing the key. Rogue access points must have exactly the same security settings as the original access points, including the same key.  If they do not have the same key, clients will try to connect but fail.  Fortunately, it is not possible to see what key the clients attempted to use, as the key is never actually transmitted during the authentication process.

Thus, the only people who can cause any real damage with rogue access points are people who already know the key to the original network.  People who don't know the key can still set up a rogue access point, but all they'll be able to do is make people unable to connect when their devices fail to authenticate with the rogue ap.

For networks with large numbers of users and public networks though, they become a more serious concern.  There's no way for a users to tell that they may be connected to a rogue ap, and pretty much anything could happen (data theft, malware injection, eavesdropping...) if they are.  That's part of the reason why VPNs are always recommended when using public wifi.


RADIUS Authentication and Shared Secret, is secure?

The way most 2FA services for RADIUS work is by acting as a server hosted locally or in the cloud that authenticates RADIUS requests from agents, and then sends the request to their own servers using their own protocols (disclosure: I work for such a company and have studied and built such services).

That means the data flows like so:

[You] => [VPN|router|service|etc] => [agent] => [2FA RADIUS server] => [2FA service]

There are a number of places to attack:

between you and the VPN-thing: one would hope this is protected through other means. This would likely require a man-in-the-middle attack.
between the VPN-thing and the agent: they're usually the same thing, so it's either an in-memory attack, or an IPC attack. This means you'd need to be on the same box with elevated privileges.
between the agent the 2FA RADIUS server: I suspect this is your biggest concern. It's the RADIUS protocol, which means it's dependent on what auth mechanism it's using for the user. Most use PAP, which uses a shared key to "encrypt" and "decrypt" just the password (quotes meaning it's a bit iffy). This would likely require a man-in-the-middle attack.
Between the 2FA RADIUS server and the 2FA web services: one would also hope this is protected through other means. This would likely require a man-in-the-middle attack.

So what does this mean? Yes, someone can read everything but the password in your RADIUS requests if they get between the agent and the server. This is somewhat trivial if the server is in the cloud. It's a little more difficult if the RADIUS server is on the same closed network as the agent. It's debatable whether an attacker can decrypt the password, as it's dependent on the strength of the shared secret, and how many packets they can steal.

Additionally, you have the shared secret if you're communicating directly with the RADIUS server. If everyone has the same shared secret then anyone can decrypt anyone's password.


Why is leaving a passworded SSH over the internet so bad?

Why is this so bad?

Because there are tons of bots just scanning the web for open ports and trying to log in, once a scanner bot finds an open SSH port it may be queued for another bot (or botnet) to try to brute force the password. One of the risks here is that eventually, they may succeed in figuring out the password and take control of the server.

  I understand the password can be bruteforced, but what if it is a very
  strong password that would takes eons to crack?

Having a long password is a mitigation technique, however the resources (bandwidth, disk space used for logs and CPU for example) consumption of a brute-force attack can also be damaging.

Mitigation

Some techniques to mitigate a brute-force attack on SSH:

Use a different port, don't get a false sense of security with this, but many bots do search for 22 exclusively. (Related question)
Disable SSH passwords
Require a private key for logging in
Throttle connections
Implement an IPS (Fail2ban and Snort come to mind)
Restrict login per IP address
Restrict which users can log in (different than checking the IP address)


Does AES 256 encryption support a master key and generated (time-bombed) keys?

First, about AES-256 in particular: AES-256 is a symmetric cryptosystem. Decryption and encryption use the same key; if you encrypt stuff with a master key, you have to give that master key to whatever's decrypting stuff or else it can't decrypt stuff. You may have read about master and session keys, but that is about stuff happening before AES encryption -- to decrypt the output of AES-Encrypt(k,m), the client must know k.

Second, for time-based decryption: Encryption and decryption algorithms are mathematical functions. They have no notion of an hour; they cannot be made to work one way today and a different way in six weeks. A function takes an input and gives an output; it always gives the same output if given the same input, no matter where or when it's being run. Since neither key nor ciphertext degrades over time unless you actively destroy it, there is no way to have "time-bombed" decryption that happens entirely on the client side. This is not AES-specific; in every encryption system, if you have the information needed to decrypt the data now, you can use that information any time you want.

The only way to get some sort of time-bomb encryption is to make it so that the client simply does not have all the information it needs to decrypt. You need a system where it can't decrypt without contacting a server you control and getting some information that couldn't otherwise be figured out. Even then, if that information is stored locally, an attacker doesn't need to contact you to use it a second time unless you re-encrypted the data.


If I obtained a username and the salted password pairs from a server, can I login?

Disclaimer: I'm no expert in cryptography so this answer come from my limited understanding of the protocol.

Let's look at the protocol

SaltedPassword  := Hi(Normalize(password), salt, i)
ClientKey       := HMAC(SaltedPassword, "Client Key")
StoredKey       := H(ClientKey)
AuthMessage     := client-first-message-bare + "," +
                    server-first-message + "," +
                    client-final-message-without-proof
ClientSignature := HMAC(StoredKey, AuthMessage)
ClientProof     := ClientKey XOR ClientSignature
ServerKey       := HMAC(SaltedPassword, "Server Key")
ServerSignature := HMAC(ServerKey, AuthMessage)

Who know what at the start?

The server knows : salt, i, StoredKey, ServerKey
The client knows : password
Both parties know the AuthMessage as part of the exchange

The answer

You are right that only the SaltedPassword is required to compute everything but the problem is that no one stores that SaltedPassword. Also, if you want to simply impersonnate the client, you only need the ClientKey to fool the server.

The idea behind SCRAM --> A failure?

  The secure authentication mechanism most widely deployed and used by
  Internet application protocols is the transmission of clear-text
  passwords over a channel protected by Transport Layer Security (TLS).
  There are some significant security concerns with that mechanism,
  which could be addressed by the use of a challenge response
  authentication mechanism protected by TLS.

Still, it doesn't seem to explain how it will protect the password from the server. You have to understand that even if you use some kind of fancy challenge response mechanism to "never" send the password over the wire, that when you enter the password on the browser page, that is served by the server, the script in the page could decide to record your password even if it tells you that it doesn't.

The main advantage, that I see, of a challenge-response mechanism for the users is that they would be able to reuse the same password everywhere. But, since the user really cannot trust the page where it enters his password, he cannot reuse his password.

Then, the next big advantage that I could think of is that in a challenge-response mechanism the password usually isn't stored on the server. So, even if an attacker stole a copy of the server, he cannot try to de-hash the password. Again, it's a big fail since the server has a copy of the StoredPassword, the salt and the iteration count. He has all he needs to try to crack your password via dictionary or bruteforce attack.

At some point, I have to wonder, why not just give the password to the server? The only protection that it adds is that if TLS is broken (but the attacker can only listen), the attacker still has to brute-force your password in order to gain access.


Are web vulnerability scanners active or passive?

Web app vulnerability scanners typically use a combination of active and passive vulnerability detection, with the majority of the testing done actively.  For example, if the scanner requests a page and it returns a cookie without the 'secure' flag that is essentially a passive test.  But if the scanner is trying to find an XSS vulnerability in a parameter it is probably going to actively send several hundred different requests to test attack variations.  That's why active testing is more prominent.

Some scanners can be put into passive-only mode where they crawl through the app normally or monitor you using the app to detect vulnerabilties.  As you might expect, this has less impact on the app (and is less detectable) but produces fewer results.

The payloads of attacks are generally non-malicious, but some of that depends on how the app reacts to it.  I've seen poorly designed web apps crash when they receive unexpected data.  To test something like an XSS attack the scanner may just try to inject basic script tags with an alert to see if it works.  They normally aren't going to inject a keystroke logger, fake login form, etc.

With regards to your SQL injection question they shouldn't typically use SQL commands that delete data or change configurations, but that may depend on the scanning policy you use.  Some scanners have malicious or DoS policies that might be more disruptive.  It's also possible that your database will have a lot of records added by the scanner even if none of the previous data was manipulated.


The short answer:

Whatever your heart desires.
Just tested up to priority:1000000; and works just fine.

What it says in the manual:

The following was put under §3.4.6 - classtype, the section immediately preceding priority:

  Attack classifications defined by Snort reside in the classification.config file. The file uses the following syntax:

  config classification: <class name>,<class description>,<default priority>

  These attack classifications are listed in Table 3.2. They are currently ordered with 4 default priorities. A priority of 1
  (high) is the most severe and 4 (very low) is the least severe.

Hope this answers your question!


Why ret2libc is not working in the below code on x86_64?

There are a few points to note:

1. The strcpy function stops copying stuff into the destination buffer as soon as it encounters a NULL byte. A NULL byte is 0x00 or \x00. In 64-bit machines, the length of an address is 8 bytes. Let us consider pop_rdi_ret = 0x00000000004005cb. This has NULL bytes. So, as soon as strcpy encounters the first NULL byte(the NULL byte next to 0x40), it stops copying. So, the exploit payload is not being injected properly because of NULL bytes.

2. I hope you have compiled your vulnerable program without StackGaurd or the Stack Cookie protection. If that is there, it will kill the program when it detects a stack smash. You can use the -fno-stack-protector compiler flag to compile without StackGaurd.

3. I don't know why you are injecting NOPs into the buffer. There is no harm in doing it, but there is no use either because W XOR X is enabled.

  And, please can anyone help me little to understand the concept of ROP stack frame in 64 bit, I mean 32 bit ROP stack frame is simple to understand as compared to 64 bit and available content on the internet about the 64 bit ROP didn't help me.

When it comes to ROP, there is no difference between 32-bit ROP and 64-bit ROP. That is because in both cases, the ROP Gadgets are chained.

If you are talking about ReturnToLibc, there are differences. ReturnToLibc is the fancy name given what you are doing in the above exploit. You are returning to a libc function to get god access.

The root cause of this difference is the way functions are called. The function calling mechanism in 32-bit and 64-bit processes are different. In 32-bit, arguments are passed to the callee function using the stack. But in 64-bit, the first 6 arguments are passed using registers and if there are any more arguments, stack is used.

Because we are calling functions here, the exploits for 32-bit and 64-bit will be different. As you righty mentioned, ReturnToLibc exploit for 64-bit is more or less ROP because you will have to find gadgets which will load stuff into rdi, rsi, rdx etc., . If you don't find the right gadgets, you will have to chain them.

  Because of that, I am also confused about creating stack frame via ROP for mprotect call for my another exploit code.

Let me help you out with this.

Take a look at the manpage of mprotect.

MPROTECT(2)                         Linux Programmer's Manual                              MPROTECT(2)

NAME
        mprotect - set protection on a region of memory

SYNOPSIS
       #include <sys/mman.h>

       int mprotect(void *addr, size_t len, int prot);

For 32-bit:

Let us first create the fake stackframe for 32-bit.

Suppose you want to make the stack address space executable.

Let addr = 0xf1f2f3f4, size = 1000, prot = PROT_EXEC | PROT_WRITE | PROT_READ .

The values of PROT_READ = 1, PROT_WRITE = 2, PROT_EXEC = 4. Referring to this sourcefile.

So, PROT_READ | PROT_WRITE | PROT_EXEC = 7.

The strategy is this:

a. Overwrite the vulnerable function's returnaddress with mprotect's address. When the ret instruction is executed, control is transfered to mprotect function and stack is popped. For mprotect, the stack before ret instruction is executed should look like this:

<mprotect's Address>          // This is vulnerable function's return address
<mprotect's Return Address>   // This can be exit libc function
<prot = 0x00000007>
<len = 1000>
<addr = 0xf1f2f3f4>

So, there you go. you have the stackframe you wanted.

For 64-bit:

To exploit a 64-bit vulnerable function, we have to pass arguments through registers. This is not as easy as it was for the 32-bit exploit. This is what we need.

rdi = Stack's address = 0x00007ffff7123456  // just an example
rsi = 1000
rdx = 0x7

Now, we have to find gadgets which directly does this or have to find gadgets and chain them. This is where it gets a bit hard. Writing ROP chains by hand is time taking. You can try out ROPGadget or any other ROP tool out there.

Assuming you get the proper mov gadgets, I will continue my answer.

0x400123: mov rdi, 0x00007ffff7123456; ret
0x401234: mov rsi, 1000; ret
0x412345: mov rdx, 0x7; ret

The plan is, these 3 should get executed in a  row and then mprotect should get executed. So, the stack should look something like this before the vulnerable function's ret is executed.

<0x400123>                  // This is originally vulnerable function's return address
<0x401234>
<0x412345>
<mprotect's address>
<mprotect's return address>

In reality, the stack might be way more complex than this. This is just an example.

I hope you see the difference between the stack of a 32-bit exploit and a 64-bit exploit.

If anything is not clear, leave a comment below.


DKNUCKLES' answer covers the reason why your injection doesn't work, so this answer is more about how the program's stack gets laid out and why you need to input 312 bytes before you see a crash.

If you look at the assembly generated from your program, you can figure out that the stack looks like this at the point strcpy is called:

               +--------------+
      rbp + 15 |return address| 8B
       rbp + 8 |              |
               +--------------+
       rbp + 7 |    old rbp   | 8B
           rbp |              |
               +--------------+
       rbp - 1 |  alignment   | 3B
       rbp - 3 |  padding     |
               +--------------+
       rbp - 4 |              |
               |              |
               |    buffer    | 300B
               |              |
               |              |
               +-- -- -- -- --+
     rbp - 304 |  buffer[0]   |
               +--------------+
     rbp - 305 |   argc       | 4B
     rbp - 308 |              |
               +--------------+
     rbp - 309 |  alignment   | 4B
     rbp - 312 |  padding     |
               +--------------+
     rbp - 313 |   argv       | 8B
rsp, rbp - 320 |              |
               +--------------+

From that, you can see that there are 11 bytes between the end of buffer and the return address: some padding and the old stack base pointer.  That explains why nothing happens until your input reaches 312 bytes.  The padding is never read from, and nothing above main uses the stack, so it doesn't matter that you've corrupted it.  If you write 312 bytes you end up corrupting the return address though, and that causes the program to crash.

You're also not actually injecting your exec code; you're just passing it and a literal '+' character as separate arguments.  That explains why you need to input 312 or more 'A's to cause an error.


Are documents truly "signed" by DocuSign?

A signature is, ultimately, a legal concept. When you sign a document, you are really producing a legal gun aimed at your own head (so you usually want other people to sign things, not sign them yourself). The value of a signature comes from its legal power, i.e. how much it will allow to apply responsibility and blame on the signer. The cryptographic elements (RSA and so on) are only tools that can help build the technical side of things, but that cannot suffice. Ultimately, there must be some kind of legal framework that defines signatures.

Of course, this will depend on jurisdiction. Nevertheless, countries/states that are currently defining laws for electronic signatures tend to go along the same lines:

A signature is binding as long as it was really signed by the alleged signer. This looks tautological, but it is an important definition: it really says that the signature legal value is not intrinsic to any specific technology. Writing your name at the end of an email is a signature.
What matters is the burden of proof. Legal frameworks will normally segregate systems into two categories: those for which signatures are reputed good, and it is the party who denies having signed who must make all the proofing work; and those for which signatures are reputed worthless unless a positive proof of attribution to the alleged signer is shown. "Name at the end of an email" belongs to the latter category; a positive proof may be simply a witness who saw the signer type the email.
The reference for signatures is handwritten signatures, which are, technically speaking, absolutely terrible. They are hard to validate, and can be faked. Handwritten signatures are still used thanks to a legal framework that severely punishes anybody who denies his own signature. Since handwritten signatures occur in the physical world, the very act of signing (with a pen) leaves a lot of traces (witnesses and so on) so many people ultimately find that repudiating their own signatures is too risky.
A further complication is that legal systems of the "Common Law" tradition tend to rely on jurisprudence to iron out the fine details, so countries like USA and UK will likely have legal frameworks for signatures that boil down to "wait and see" ("see you in court", I mean).

In France (which has a very "Latin" law system that really likes pre-established rigorous definitions, Descartes-style), the legal framework defines systems which are qualifiés, by which they mean that they went through independent audits and an administrative process that has all the simplicity that can be expected from French bureaucracy, to the effect that for this systems, the burden of proof lies on whoever claims that the signature is not binding. The list of the systèmes qualifiés is published and I see no DocuSign there [edit - as of July 21, 2017, DocuSign France is now listed].

DocuSign has a page dedicated to the legality side of things -- which is in fact a lot more important than the technology. In particular, they say this:

  While DocuSign has a successful history of providing customers with all the evidence they need to defend their documents against repudiation, DocuSign is available to assist our customers with legal challenges by testifying in court to support the validity of DocuSigned documents.

which implicitly admits that their system tends to be of the "must prove validity" kind, i.e. not the one you would like -- but they claim to have had good results in some courts, and that they will help you. At that point, I'd say that if you want to use DocuSign for making your customers / business partners sign things, you'd better make sure that there are appropriate clauses in your contract that ensure a strong level of help from DocuSign, with insurance and so on. Your lawyer team should be involved.


How does Google crawl pages which require login?

These pages simply don't require a login when Google is crawling them but only if a user with a common browser accesses the pages.

In order to have pay-walled or otherwise protected content included into results of search engines, several sites white-list specific crawlers, for example based on source IP address or user agent. Another way (which might be also employed at the specific site you want to access) is not to white-list specific crawlers but to detect if a real browser is used and then require a login.


Yes it can be. Since i do not use MAC or i-Phone or anything i'm not sure about how it is exploited  but i'm sure you don't have to be a coding genius to understand this code
So here's the Apple bug:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
    OSStatus        err;
    ...

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;
    ...

fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;
}

Source:
So it is a mistake by not commenting the second goto fail; so this can be a really dangerous loophole if you are on an open network (It lets you make a secure connection to an IP without considering the signature) . Not much danger in private LAN  if you trust the others in the network.


Should I restrict access to the username and passwords in a web app?

From a security standpoint, the threat is what happens when the underlying storage is exposed in any way, not just a sql injected select * from users; statement. Do you trust your administrators? Even the one you just had to let go? Who else has access to the box? Is it a virtual machine at a third party company? In the cloud? That is why getting hashing right is often emphasized first and foremost, so that user passwords have some defence even against an authorised user.

That said, I think controlling access via views would be beneficial, such that you can only execute pseudo-instructions "insert user", "delete user", "does user exist" and "are these credentials valid" from the perspective of your web app. This prevents enumeration except by repeated calls to the database with a known user identifier, which is better than allowing the attacker to grab the entire database. You're reducing the ease with which an attacker can grab that table in the case of any potential compromise/unforeseen vulnerability in your code or framework. The only question is compatibility with existing frameworks, although many provide the ability to extend or implement custom authentication backends.

On the subject of hashing, use PBKDF2 or bcrypt or an equivalent slow hash key derivation function with salt, not just a hash with salt. A decent article on the subject will explain this stage (sometimes they recommend repeating a hash for several thousand iterations; it's essentially the same idea).


Separate SSL certs on CloudFront and Heroku?

A server certificate is used to authenticate the target of the current request. This means that when accessing www.example.com the client expects to get a certificate valid for www.example.com. When accessing example.cloudfront.net the client expects to get a certificate valid for example.cloudfront.net.
The context of the request does not matter, i.e.  if the request for example.cloudfront.net was caused by an XHR from the site served by www.example.com. All what matters is the target of the current request (example.cloudfront.net).
One could have a certificate which is valid for several targets at the same time (i.e. includes both www.example.com and example.cloudfront.net). But this requires that one actually owns and manages all these domains. In case of example.cloudfront.net or example.heroku.com this is not the case since these are owned and managed by third parties.


Is it a major security risk if your client_secret gets displayed for about 30 min - 1 hour before you notice it showing and you can remove it?

The only thing on Stack Overflow that might not be public forever is a comment. If you edit an answer or question all past versions are still available. Deleted questions and answers are still visible to mods as well as any user with enough rep. Even the chat sites retain permanent public transcripts. It's possible that you could have an admin actually remove something from the revision history, but I'm not 100% sure. In short, you should assume that anything you ever post to stackoverflow has permanently become public knowledge. So in this case, yes, change your client secret.

In general, if you were to post a secret to a public place for a brief period of time, only you can decide whether or not the "cost" of changing it outweighs the risk of someone using it. If the client secret protects something low-risk (imagine a Google maps API key that is only authorized for use from your server IP), then you may reasonably decide not to change it.

Personally though, unless the key is nearly impossible to change, I would change it no matter how short the exposure.


How can one know if the password database on the server is stolen or not?

Start collecting data

There is no "was_compromised" database setting that gets changed when a breach happens. You'll have to monitor your evidence now, and look for suspicious activity. You should look into the concepts around Intrusion Detection more broadly, but I'll give some database specific ideas to get you started. Essentially, start logging information to an central system as soon as possible.

You don't just need the data to determine what happened should a breach occur, but you also need the data to establish what is normal so you can detect what is abnormal.

Enable Database Query Logging

In MySQL, enable the General Query log. If your server is breached, you will often see a large increase in query activity.

Intrusion Detection systems can be to watch for canary values.

One technique that has a very small false-negative rate is to insert fake data into the database, and configure your Snort to detect if that data exits the network. This technique can get tricky, because data can be encoded or encrypted, but setting up multiple tap points will help. You would ideally listen to traffic between the webserver and the internet, as well as between the database and the webserver.

Monitor your web logs

If SQL Injection attacks are being used to grab data, the attacks will show up all over your weblogs. You will often see huge spikes in traffic for a small group of IPs. Knowing how much data your website normally transfers a day is very helpful here.

Start full packet captures

This is the final word. If you can record every packet ever sent to and from the database server you will be able to answer the "Did we get breached" question much more effectively.  You'll ideally want to capture between all the your servers.


My cellphone is infected, and it keeps coming back

An increasingly common attack is to use your Google Play Store credentials to force apps onto the device via the web page for the app.  If you are seeing apps install automatically this is the likely source.

In any event if you got malware on your phone, you really need to change your Google credentials and reset any 2fa tokens or app-specific passwords that are outstanding.

Edit: just a bit more musing about android vulnerabilities

When you "format your phone" really you are removing everything in the user directory (all your downloaded apps and settings) and calling everything back from the "factory" directory.  If you have rooted your phone (intentionally or unintentionally) this area can get unlocked and a particularly persistent malware could copy itself there, where it would survive a "factory data reset".  If you have refreshed all your Google credentials and the phone still exhibits strange behavior, you will need to restore the factory section with a "rom" which is a file containing the entire storage image in the factory default state.  These are available online from various places (http://www.xda-developers.com is the most thorough) and the process is fairly simple for most models.