uploading photos to cloud from an infected device

It's always possible that any files on an infected machine are infected themselves, but I'd say that image files are a less common target for malware.

One approach would be to upload them to a cloud service and then make sure that you scan them with an A-V solution when you re-download them.

Whether it's worth the risk to you will depend on how much you want the pictures :)


Next Microsoft Patch Tuesday include BEAST SSL fix

Since the patch has been released some time ago, we can now have more information. The security bulletin is quite devoid of technical information, but some clues can be gathered from reading the KB article about known issues. The patch does, basically, two things:

The patch activates TLS 1.1 support. This support was already included in Internet Explorer, but not enabled by default, because there were some buggy servers which did not tolerate it (in a SSL/TLS handshake, the client announces his maximum supported version, but some server implementations refuse to talk to clients who announce anything else than SSL 3.0 or TLS 1.0). Microsoft seems to have decided that fixing BEAST was more important than supporting faulty SSL servers.
The patch implements record splitting. In SSL/TLS, data is encoded as records, each record being encrypted by itself. The BEAST-related flaw is about records in SSL 3.0 and TLS 1.0 with CBC encryption, where the IV is extracted from the end of the previous record, thus predictable by an attacker eavesdropping on the line. Record splitting is about automatically splitting an n-byte records into two records, the first one being very small; this has mostly the same net effect as choosing a random IV for each record (which is what TLS 1.1+ does), and this fixes BEAST, with a small size overhead (not much). A 0/n split would be ideal (i.e. prefixing each data record with an empty record) but tends to break too many existing implementations, in particular the one in Internet Explorer 6.0; hence, a 1/n-1 split is often employed, and almost as good. This is probably what the Microsoft patch applies.

Record splitting is used when the server chooses SSL 3.0 or TLS 1.0, and a CBC-based cipher suite.

Note that practical application of BEAST also requires a rather flexible way to do cross-site requests, something which the BEAST designers (Duong and Rizzo) could achieve only by exploiting one of two weaknesses, which were in Javascript WebSockets (draft version) and in Java (Sun/Oracle implementation), respectively; both weaknesses were also fixed. The Microsoft patch we are discussing here addresses the underlying vulnerability of CBC encryption with predictable IV.


How to check if a software is legitimate

You could be asking one of many questions here.

If you are asking "How do I know that the software I have here is
what the vendor made - could it have been altered before I got it?"
then you will want to compare the hash of what you have to what the
vendor has published, assuming they have. (Almost everyone does
nowadays.)
If you are asking "How can I tell if the vendor has put malware or
back doors into this software?" then the key thing to consider is how
much you trust the vendor. (Although that's not a guarantee. Big
companies have accidentally gotten a virus on their gold masters
before now, and the bigger you are, the more likely a government is
to lean on you to put a back door in.) Of course you've scanned it
with a couple of AV scanners, like you do with anything you put on
your network. Talk to other users and see if they have any issues. If
it's open source, you can read the source before compiling, although
that is a huge amount of work. Lastly, you can run it in a sandbox
for a while, monitoring what it does, especially it's network
activity to see if it phones home.
If you are asking "How can I tell if it has programming mistakes
that make it vulnerable to attack?" then again there are various
approaches. As before, consider the reputation of the vendor; talk to other users; and if it's open
source and you have the resources, review the source. Check it's
bug tracking system if this is public, and it's historical release
notes, to see how well security issues are addressed. Think about
what it does and what threats you face, and identify other security
controls you can put around it.


Does mutual authentication have any impact on MiTM possibilities?

A Man-in-the-Middle really is simultaneous double impersonation: the attackers poses as a fake server when talking to the client, and as a fake client when talking to the server. The beauty of the MitM is that since the impersonation is simultaneous, the attacker can hope to reuse answers from the genuine client or server, when responding to the genuine server or client.

Details matter. TLS uses X.509 certificates, and uses them properly, which makes it robust against some possible attacks.

Suppose that the attacker somehow managed to pose as a fake server, e.g. by bribing or compromising a CA into issuing to him a fake certificate, or,  more probably, by convincing the human user to disregard the browser's warning about the server certificate not being valid. The attacker now relays the information back and forth between client and server. The server now wants to authenticate the client with some password-based protocol (e.g. the simple and very common "show the password" protocol), inside the TLS tunnel. The attacker can simply let that protocol flow, and, once it is done and the server is content, really hijack the data stream and inject his own commands.

Now, try that again, but with a client certificate. When a client certificate is used in SSL/TLS, the client demonstrates his mastery of his private key by computing a signature over a "challenge" from the server. Crucially, this "challenge" really is the concatenation of all preceding handshake messages (see the standard). In particular, the server's certificate is part of what is signed by the client. Our attacker could reach that point in the MitM by feeding a fake server certificate to the client -- that is, a certificate distinct from what the genuine server sent. Thus, what the client signs and what the server uses to verify that signature will be distinct sequences of bytes, and the signature will not match.

Summary: if by "mutual authentication" you mean "authentication with a client certificate, handled at the SSL/TLS level", then that authentication will prevent the MitM. Or, more precisely, the attacker will succeed only if he manages to obtain a fake server certificate that will convince the client and a fake client certificate that will convince the server.

However, if the two authentications are not coupled (as what happens in the password-within-TLS protocol), an attacker that succeeds at impersonating the server can easily turn that into a full MitM by reusing the client answers.


Does reinstalling ubuntu eliminates all existing rootkits/ malware/spyware/ virus etc?

You are required to format the disk completely. There are rumours and even proof of concepts of rootkits hiding in the BIOS, but I haven't seen them in the wild yet.


What can a user do in order to protect against CSRF attacks?

Maybe use two browsers, one for those account, and another one for browsing?

This is a probably the best idea since it offers the most separation. This way classical session cookies will not be shared between sites, although a sharing of Silverlight and maybe Java or Flash based session ids might still happen. In most cases it will probably already be enough to start an instance of Firefox/Chrome in private/incognito mode.

But using another browser or browser profile for each sensitive site is not practical in all instances and one will probably do it only for some more sensitive sites like online banking or administration of the router. Apart from that valid cross site requests are in use for instance in single sign on setups (i.e. sign in with Facebook etc) or for using 3rd party payment providers like Paypal. For these cases there are several browser extensions which help dealing with CSRF and you will some examples at Wikipedia - CSRF - Client side safeguards.


Like Neil Smithline already said: if the attackers can outsmart a usually reliable DOS protection then there is nothing much you can do to protect yourself. That means that you should not focus on fighting or blocking the attack itself (leave that to the experts), but on reducing the impact of the attack. This might include:

Reduce your attack surface by making only services public that need to be publicly available. That is don't expose your database if it is only needed as a backend for some web services.
Have sites all over the world or have the ability to easily setup an alternative site (somewhere in the cloud) so that at least part of the sites still work even if the others are attacked. Using DNS you then can make sure that mainly the good sites are accessed by the customers.
Make sure that attacks on public sites don't affect internal sites, i.e. it would be bad if you hosted some internal application on affected public systems and could not proceed with your internal business if public sites are attacked.

These are just some general concepts. Of course details depend on the kind of DOS attacks (bandwidth, application level DOS, flood  of spam mail affecting specific recipients....), how critical all of this is for your business, which services are exposed to the public at all etc.

  Patch my systems with latest updates

This will not specifically help against DOS, but of course you should keep your systems always current.


This sounds like a typical scam, the tip-offs are:

A message from a complete stranger claiming that they will give you money.
Creating a sense of urgency to push you to do things quickly and not think them through. ("...and did not have a lot of time as the doctors where ordered to take away all electronic equipment.")

I'm not sure what you can do to protect yourself from identity theft, except for watch you accounts extra-carefully for suspicious activity, and report anything that you notice.

For any North Americans that read this thread: the Better Business Bureau has launched an online Scam Tracker tool where you can search keywords to see if other people have reported the same scam.


Can Malware/Hacker Connect a Device to Internet that's NOT Already Connected?

In general, yes. Once a malware is properly inside a system, it has an access to that system higher or equal than yours. So it can do whatever you can, and possibly even more.

  What if I JUST bought a new laptop and never connected to a router.
  BUT, my router has malware or a computer connected to my router in the
  same household has malware. Could the malware in my router or
  household computer somehow "turn" on my computer to the internet

This is a completely different problem. It too is possible, but requires hypotheses that are quite unlikely.

To start with, the infected computer must know about the newcomer. How can it?

You turn on the new laptop and navigate. The infected computer has what's called promiscuous access to the network and "sees" packets from a physical address (MAC) that it did not know about.
You do not navigate, but the malware performs routine scans of its network to find possible targets of opportunity.

Now it needs to turn it on. There's a facility to do that, Wake-on-LAN, but is it running on the newcomer? What if the laptop is WiFi and doesn't support the much more complicated and expensive Wake-on-WiFi?

But it could simply wait for someone else to turn the laptop on.

Finally it needs to seize control of the laptop. This is actually the easy part. A sophisticated enough malware would not act alone, but rather connect back to a command-and-control network, and the conversation could go like this...

malware: NEW POSSIBLE TARGET, MAC 00:11:22:33:44:55
control: MANUFACTURER IS KNOWN, EXPLOITS MIGHT EXIST. PERFORM PORTSCAN.
malware: PORTSCAN COMPLETED, RESULTS ATTACHED.
control: TARGET IS NIFTYWARE LAPTOP MODEL THX1138 RUNNING BUNNYOS 3.11. EXPLOIT ATTACHED.
malware: EXPLOIT UNZIPPED AND RUNNING.
(and some seconds later...)
laptop : CONTROL, THIS IS NEW INSTANCE 019298 REPORTING FOR DUTY.

...and from that moment on, your laptop isn't really "your" laptop anymore.

And that's why you don't want an obsolete or vulnerable machine in your network, ever.

Update

  But then I thought, maybe the WiFi is on, but if I never connected
  SPECIFICALLY to a network, then I couldn't pick up anything, right?
  Out of curiosity, shouldn't the WiFI be off?

Yes, and not necessarily. Yes, if you never connected to a network, the new laptop was never online and nobody could have reached it. (There have been reports of airgap bypassing but, to my knowledge, they either have never been substantiated, or refer to a different scenario - two already infected computers bypassing an airgap).

And no, on most new computers WiFi is actually on, but the "light" only refers to the capability, not to the actual connection or even presence of an access point. It just means that the laptop might connect if there is an active access point and you supplied the password.

On some high end laptops the light is blue when WiFi is on and e.g. green if there's a connection, and it maybe even blinks when data is exchanged. But it still means that the "default" blue light signifies nothing.

In your specific case a router "malware" almost invariably entails modifying the DNS mapping so that e.g. www.google.com is actually a site faking Google that prompts you to download malware. And a Mac malware is not at all likely to propagate on non-OSX computers. So you should be doubly protected (you were not connected to a network where nothing was likely to infect you actively).

There is one case in which this is not completely true: a malware's code cannot spread across OS boundaries, but its damage can. Case in point: a CryptoLocker/TeslaCrypt ransomware running on Windows will find your open shares on a Mac OSX, if they are open and writeable, and will encrypt the documents they contain. The Mac OSX will not be infected, but its documents will nevertheless be lost.

And that (that, and user errors, and hardware failures) is why you also want to have full and adequate backups.


How to escape user input in a value of javascript object?

http://code.google.com/p/json-sanitizer/ takes JSON-like content and converts it to JSON that is safe to evaluate as JavaScript source code and which can be embedded in HTML <script> elements and in XML <![CDATA[...]]> sections.

For example, given

{
  key1: "user_input",
  key2: ["user_input1", "user_input2"]
}

It preserves several properties:

Keys must be properly quoted.
Brackets match.
All JavaScript newline characters (CR, LF, U+2028, U+2029) in strings are \u.... escaped.
Quotes ("), backslashes (\) are \u.... escaped to ensure that strings do not end prematurely.
Angle brackets (< and >) are \u.... escaped as necessary to prevent strings from containing the literal text </script or ]]> which would prevent embedding.
All control characters (actually characters not allowed in XML) are \u.... escaped including U+0-U+1F excluding tab, U+7F, U+FFFE, U+FFFF.
Orphaned UTF-16 surrogates are \u.... escaped.
All escape sequences are converted to valid JSON escape sequences including octal escapes (\012), two-digit hex escaped (\x0A), and single character escapes (\!).

It can be a good idea to \u.... escape things like + to defang UTF-7.


Active directory based permissions SID, username or email?

Your question is a bit unclear, but it sounds like you want to grant permissions in your app using AD properties associated with an account the user authenticates with.  If that's correct, you should use the SID as that is the intended purpose of that property, and it is the least likely of the properties to be changed.  A username, an email address, or other account properties can be changed or reassigned, but the SID will remain the same for that object throughout its life in a domain.


Online Marketing company want me to share my Google Account login details?

With Google My Business (and related services) you can add/remove managers to the business account without having to share credentials. The marketing company would need to have or create a Google account that you can then add to your My Business account in the Managers tab of your settings. Note that only the Owner on the account can add new managers.


Ruby on Rails basically makes use of a Security Token, which if also a recommended way of preventing CSFR attacks, to prevent CSRF attacks.

You must include a security token using: protect_from_forgery in your requests and MUST verify it on the server. This will automatically include a security token in all forms and Ajax requests generated by Rails. If the security token doesn't match what was expected, the session will be reset.

Source: Ruby on Rails Security Guide.


Have you tried to load the openvas plugin in MSF, connect to your running openvas server, and import your report directly from openvas by issuing "openvas_report_import report_id nbe"?

I was having the same problem as you until I imported using the plugin.


Given that your cyphertext is all As, I am going to assume that the key is of the same length as the plaintext (there are edge cases where this is technically untrue, but for decryption purposes it's probably true).
When your Vigenère key is as long as your plaintext, you are effectively using a One-time pad, which is impossible to decrypt.


xml library vulnerabilities, regarding post-exploitation

The computer is not yours anymore, it is probably his.

You cannot trust that he did not actually compromise your box further than you currently know about.

He could have compromised the kernel, binaries or virus scanner on your box and you would never know.

I would recommend wiping and re-installing from known good media.

Then scan your current hard drive and all network drives for compromises (but you can never know that your virus/malware scanner will recognise the specific compromise left behind). Then take off the content you must from your old media.

If you wish to contact the police about it, you will need to supply them with your computer (or at the least your hard drive) so think carefully before you do the irrevocable step of wiping the old media or trashing anything else on it.

But I am Not a Lawyer, I only read Groklaw.


Is VPN the best solution against man-in-the-middle attack?

Setup proper 802.1X authentication / WPA-Enterprise to connect to the network. So each client will have their own credentials and they'll be logged accordingly.

VPN could also be set up in the same manner if you need remote access. All of these protocols are designed with security in mind and thus inherently prevents any form of MITM attacks if implemented correctly. Basically, it creates a secure tunnel to communicate between client and server which coupled with secure authentication protocols would prevent anyone from monitoring, modifying or impersonating your communication.


How does EAP/PEAP integrate with modern security protocols?

Your understanding is already pretty good. As you say, there are a variety of EAP protocols: LEAP, PEAP, EAP-FAST, EAP-TLS, etc. Each one works differently, but they all do the same thing: authenticate a user before allowing them access to a wireless network. You could call EAP a protocol, or you could call it a framework of protocols, where each variant like EAP-FAST is a protocol. It doesn't make much difference, and I find that different documents are not always consistent with each other (or even internally!)

To answer your bolded question, basically it's yes. A client and access point will have certain EAPs enabled, and if they support the same one, the client can try to authenticate. Each EAP is a protocol, and will have different implementations. e.g. if your iPhone is logging in to your Cisco access point using EAP-TLS, then Apple EAP-TLS is talking to Cisco EAP-TLS - and because the protocol is standardised, they (should) communicate successfully.

Why is there an EAP-TLS? Remember, that the EAP occurs before the client is allowed access to the network. At that point they don't have an IP address, so it's not possible to use normal TLS. I think re-using TLS as a part of EAP is a very good idea - the security requirements are very similar for EAP as for HTTPS, so it makes sense to use a protocol that's mature (despite recent revelations!).

One challenge for EAP-TLS (and PEAP) is that the process of certificate issue and verification is less clear. Normally the network administrator needs to install the access point's certificate on all clients. If certificate verification is not done, then the clients are vulnerable to an Evil Twin attack.


The Mozilla Server Side TLS guide you linked to is an excellent resource to follow for ciphersuite choices. Ciphersuite choices will change as new vulnerabilities in TLS emerge and Mozilla seems to do a good job in keeping up-to-date with recommendations.

AES-128 is generally preferred because people think bigger is better. Both AES-128 and AES-256 are secure against known attacks and there is a non-negligible performance cost to using AES-256 over AES-128.

ECDHE uses ephemeral keys while ECDH does not. Thus, ECDHE provides perfect forward secrecy while ECDH does not.


using the CO2-Extension within Burp for sql injection

I don't know the extension you are using, but if you check, none of the default burp modules are recorded in the proxy history. If you send requests from the Repeater or the Intruder you won't see them either in the Proxy history.

I would guess this is a design decision. It also makes sense, because the history is the Proxy history, so it shows everything that has gone through the proxy. Requests sent by Burp don't go through the proxy.


Is there any security difference between login via iFrame, Pop-up, or redirect?

Iframes are dangerous as the user has no easy way of verifying that the embedded page is indeed, say, facebook.com and not some phishing page. Depending on how it is set up, allowing embedding might also enable clickjacking.

Using a popup versus redirecting the current page is just a matter of user experience and has no impact on security.


Elaborate Hacking attempt detected - now what?

Welcome to the wild wild interwebs.
Both the attacks you described seem pretty much automated scans done via some tool. Some tools can even throttle the requests to avoid detection by IDS so that could be a reason for a slow request rate of the scan you mentioned.
This specific scan you mentioned appears to sniff for presence of a forum software on your website. ( e.g. ucp.php is a phpBB forum file).

  I wonder what the hacker's goal was to try all these URLs

The attacker's goal here is to identify the framework/scripting language/software running on this domain.

  What should I do with the information I got today?

Well, if you are curious to know more about the intentions behind these attacks, you could search the IP address on google and check if there are any known instances of attacks from this IP.
For example, I just checked my server logs for such automated scanning in past 1 hour and I saw extensive scans from this IP 88.190.60.68. Searching this on google immediately led me to this report and this page which detail more about this rouge IP and its activities. So at least I can rest assured that this wasn't an targeted attack (most are not).

If you want to go a step further, you could install software like fail2ban and configure it to automatically detect such scans and blacklist the IP address for a specified duration of time.

  Is anyone familiar with this specific attack?

I am afraid you might see more of such scans as your site (domain) gets popular/old. There are tonnes of scripts with various intentions. Some try to find comments/feedback pages where they can just post link spams. Others might be looking for some very specific vulnerability.


Hide data from user, but process it in application

No. People with vested interests and deep wallets have put countless man-hours into solving this problem, even when using specialized hardware, and it gets broken over and over. Some game systems used security chips (10NES, anyone?) which validated cartridges and refused to run the system if the signatures did not match. It did not work out too well. If you find a way to solve this yourself, you have single-handedly obsoleted the entire DRM industry.
https://superuser.com/q/14224/893950
https://skeptics.stackexchange.com/q/4630/47018
Are there DRM techniques to effectively prevent pirating?


User Enumeration Vulnerability while creating Google account

Email accounts are not private, so there is little risk to discover a certain address. The same thing could be accomplished by sending an email to random accounts and see what bounces back.

Email account enumeration is not the risk as much as true user enumeration is.


Sharing credentials based on the network profile

In general, you never want to give multiple people access to the same account.

Here's an example of why: if someone does something they're not supposed to such as delete data, overwrite information, etc., no one knows who it is and that is a problem within a company. Each person should be liable for their actions, so having individual accounts is the way to go for this. Just create 1 account per person and put them into the same "group". Then assign permissions for that group, allowing all members of the group access to whatever webpages you would like.

Edit:

More regarding why shared accounts aren't a good idea:

Password changes for security reasons do happen, and someone would have to administer those and then communicate the new password to each user. I don't recommend this as there is never a secure way to tell someone a password. Also who will perform the above actions? A system admin should not be spending time administering this, and one of the users shouldn't do this because it could be similar to one of their personal passwords, thereby putting their emails/facebook/other sites accounts potentially at risk.
Also with people sharing a common password, there's greater risk of someone leaking the password (intentionally or non-intentially).


In Linux, when I consider trusting a new software source, what do I need to evaluate?

This is why the dialog sucks: it's confusing.

The decision to trust a particular repository or not is one you already took when you added it to your package manager. The whole point is to get software from the repo: if you didn't trust it you wouldn't be downloading and running code from it.

I suspect that this dialog is attempting to protect you from a situation where the repository is not the same one you trusted when you added it. For example, someone might have performed a Man-In-The-Middle attack, so you think PackageKit is connecting to the trusted repo but in fact is connecting to another, evil one. If it's connecting to the evil one, then the signature will not match.

If that's right, then they certainly shouldn't show it to you very often. They should trust the repo's signature at the point of adding it, and then pop up this dialog only when there's subsequent trouble.


One obvious way to breach this: attacks using things that aren't strings (for example, numbers) where the user is supposed to enter something like 45 (which is manipulated in code as a string because it comes out of some HTML that way, but is not apostrophe-delimited in the SQL because it's a numeric-type field) but can instead enter an entire SQL subquery (or a procedure call, or at least some additional clauses...).

You also aren't anywhere close to comprehensive about meta-characters to catch. For example, using -- to start a comment isn't the only way (I'm not sure if it's even in the general SQL standard); another way to start a single-line comment (which MySQL also supports) is #, and you aren't doing anything about those. See https://dev.mysql.com/doc/refman/5.7/en/comments.html

Other problems: Let us hypothesize that you managed to actually do this "completely" somehow. Then, some time in the future, you switch database engines (or just upgrade to a new version) and the new database server supports some new meta-character (as a start to a comment, as an end-of-line, as an end-of-string, as a subquery delimiter, as something else altogether...), and suddenly your "solution" is vulnerable again.

Stop trying to re-invent the wheel. Prepared statements / parameterized queries exist for all database drivers. Some database engines support user-defined stored procedures, which are not only parameterized but also execute faster than normal SQL strings.

If you absolutely must combine user input with raw SQL for some reason (this is rare, and can usually be avoided by being more clever with your code, but that are some places where you can't simply use parameterized queries), use a well-tested library function for it. You're basically trying to re-implement mysql_escape_string, and the first attempt at that went wrong too.


Local file inclusion when URL is appended with .php?

Unfortunately (for the attacker) this specific technique only applies to PHP 5.3 and below. It is likely that you are encountering a newer version considering the last release of PHP 5.3 was in August 2014.

Here's a bug listing for PHP and there are multiple articles and resources specifically mentioning the null byte bypass in LFI being restricted to before PHP 5.4:

Offensive Security's File Inclusion Vuln -- In versions of PHP below 5.3, ending the URL with a null byte (%00) would cause the interpreter to stop reading, which would allow the attacker to include their intended page.
PayloadAllTheThings File Inclusion reference
Rawsec LFI

Note: some references say 5.3.4 and below specifically, and I was looking deeper into this but I stopped pursuing the rabbit down the hole as "5.3 and below" likely answers why the bypass is not working :).


Pros

A password generating token does mean a 'decently' strong password, compared to other manual/memory methods. It does not rely on a common repository of passwords like a password manager. The process is as portable as the token is, which means it could be used in areas where personal devices or internet connections are unavailable, which makes it superior to password managers.

Cons

It would not produce a sufficiently random password compared to automated password generators, but I would not go so far as to say 'not sound security'. A photo of the card is enough to start a dictionary attack, not just theft of the card. Loss of or damage to the card means a loss of all passwords associated with that token.

The other issue is that once someone has your token, they can perform that dictionary attack on all your accounts (and, perhaps with optimizations in pattern/pathing matching once the first successful match was found).

Mitigation

Placing the token in a polarized sleeve so that photos cannot be taken, and physically attaching the token so that it is not easily stolen might help. I was wondering about getting the token printed on a metal card with a hole punched in the corner. Limiting the number of accounts that use the card would also help. Consider printing both sides of a card with different random character sets and distribute accounts across both character sets.

Password Managers

I have used password managers frequently and I do not find them difficult to use or implement.

Conclusion

Both a physical token and a password manager represent a single point of failure and single point of attack, and as such, the impacts need to be carefully considered. Considering the password complexity that could be generated by a token like tabula recta, it might be very useful and more secure than relying on a user's memory in situations where other password reminders are not available.


How to properly deal with different user-facing login mechanisms?

I'd listen to your developers.  The whole point of identity federation is that you delegate authentication to the underlying identity management system.  Perhaps one is a simple username/password sign in while another uses two factor auth.

Besides, what info do you really need to protect?  The fact that bob@gmail.com is a gmail account?

If you're determine not to give anything away, there's nothing to stop you forcing the user to be explicit about their domain before they provide their username.  That's a common enough approach.

E.g.

Sign in with Google
Sign in with Facebook
Etc.


Generating token for email validation and registration security

It looks secure enough considering the details you commented about, but I think the best course of action would be to cut the user ID out of the callback and have the user login normally to proceed with authentication if they are not logged in already. The exposure is not too bad as is, so if it is a pain to redirect back to auth page after login then I would say it's fine.


Bizarre email sent from spam email address with contact details of someone I know and a friend of their's in it

This is a common phishing scam. It is meant to work like this:

Mallory is a baddie and figures out that Alice knows Bob. (Lots of ways this can be done, classic examples are looking on LinkedIn or reading employee lists published on the web.) Often Bob is Alice's grandboss or similar.
Mallory sends a mail to Alice, using a free email account with something close to Bob's name, asking if they are available.
Alice doesn't look too close at the mail, thinks it is genuinely from big boss Bob, and replies.
Mallory does some social engineering, telling Alice a story such as "I am stuck in a meeting, can only email, need to get someone important a last minute present, buy some amazon vouchers and send them to me, I will pay you back from work funds."
Alice buys and sends the vouchers and Mallory's scam has been successful.

There is an extra factor to what you've seen with Darren. Mallory in this case is not terribly bright and has mixed up Darren and Darren's friend.

The correct response is not to respond to the email.


Advantage of group signing over single signing

A digital signature binds a message to a private key in a way that ensures that no one without the private key can create a signature for any message that they didn't just get a signature for from the real signer, even if they have the public key needed to verify it. The key is that it binds things to keys, not individuals.

When should you use a group signature? When the signature should associate it with the group, and don't care about linking a message to a person in the group. Why do this? That's not actually a question information security can answer; the discipline is about helping you better express your security goals and finding a way to achieve them, but infosec isn't about "what are your security goals in the first place?"

Companies have a security goal -- only authorized company personnel should be able to get something signed. So they establish a corporate key and give access to only people who should be able to do it. Or a group of friends (say, Alexander, John, and James) without some formal association want to write a series of things in the same persona. They want things to be associated with the group of them, and are not interested in showing who wrote an individual message, so they create a key and share it to sign things for the persona.


Yes its used, in a number of mail delivery/filtering sytems.  The most recognized and widely used of which is spamassassin, used by some major ISPs and mail services.  See http://hashcash.org/mail/

You might also want to read the hashcash FAQ: http://hashcash.org/faq/

It is also used in various other protocols and applications including for combating blog spam.  And you may have heard of bitcoin - hashcash is the underlying mechanism used as the work function in bitcoin.


It is possible to exploit a SIM card's SMS, OTA (over the air) update system that is built with Java Card, that is, a subset of Java that allows applets to run on small memory devices.

OTA commands, such as software updates, are cryptographically secured SMS messages, which are delivered directly to the SIM.
While the option exists to use state-of-the-art AES or the somewhat outdated 3DES algorithm for OTA, many (if not most) SIM cards still rely on the '70s-era DES cipher.

Send an improperly signed binary SMS to a target device using a SIM encoded with DES, which was not executed by the SIM because of a signature verification failure. However, while rejecting the code, the SIM responded with an error code that contained the device's cryptographic signature, a 56-bit private key. It was then possible to decrypt the key using common cracking techniques.

With this key in hand hackers are able to sign malicious software updates with the key and send those updates to the device. The attacker is also able to download Java Card applets, send SMS messages, change voicemail numbers, and query location data.

If you want more technical details on how to reproduce that yourself I recommend google since I never exploited a SIM myself just google for "sim javacard vulnerability", "sim exploit" and you probably will find it yourself.


Where to store hashes, salts, keys in Desktop Applications

TLDR: you cannot keep anything secret in a client application, you can only make it harder to find. You need to obfuscate the secret key to make it hard enough for an attacker to want to reverse engineer it.

client applications, which have to be deployed to the end user device are subject to reverse engineering and hence NOTHING can be kept secret. But it is true that you can make the process of reverse engineering certain parts of your application hard, sometimes hard enough to make it not worth the effort, by using obfuscation.

using a hash and a salt will not help you since a hash function is a one way function - it can be used to validate a given input's hash is identical to what is expected. It cannot be used to encrypt data, since there is no method to decrypt.

You can use symmetric encryption such as AES, but still the encryption key will be needed to decrypt the data and hence will be also available to the attacker.

Keeping the secret on a server and calling a web service, as you noted, is useless since the attacker can call the web service just like your client application can.

So the real only means of protecting your secret is using obfuscation which will make it not worthwhile to an attacker to do the effort of reverse engineering it.

IMHO in your case, a secret key for an API is sensitive data, but not critically sensitive. Anyone can obtain an API key of his own, and as you noted on itself does not grant you permissions to any users data. It is just for the service provider to track who is doing the API calls, and sometimes in certain API's to monitor usage, limits and even fee's. So you risk is someone stealing your API bandwidth of calls and maybe even causing you to pay for their usage of the API. On the bright side - such keys (facebook, twitter...) are very common, today almost in every application, and hence its enough for your to make it just a bit harder than usual in order for the attacker to just leave your application alone and go grab a sercret API key from another application where it is just laying in plain text.

Here is a blog post with some nice simple ideas.


How safe are password managers like LastPass?

We should distinguish between offline password managers (like Password Safe) and online password managers (like LastPass).

Offline password managers carry relatively little risk. It is true that the saved passwords are a single point of failure. But then, your computer is a single point of failure too. The most likely cause of a breach is getting malware on your computer. Without a password manager, malware can quietly sit and capture all the passwords you use. With a password manager, it's slightly worse, because once the malware has captured the master password, it gets all your passwords. But then, who cares about the ones you never use? It is theoretically possible that the password manager could be trojaned, or have a back door - but this is true with any software. I feel comfortable trusting widely used password managers, like Password Safe.

Online password managers have the significant benefit that your passwords are available on anyone's computer, but they also carry somewhat more risk. Partly that the online database could be breached (whether by hacking, court order, malicious insider, etc.) Also because LastPass integrates with browsers, it has a larger attack surface, so there could be technical vulnerabilities (which are unlikely with a standalone app like Password Safe).

Now, for most people these risks are acceptable, and I would suggest that the approach of using a password manager like LastPass for most of your passwords is better than using the same password everywhere - which seems to be the main alternative. But I wouldn't store every password in there; make an effort to memorize your most important ones, like online banking.

I know someone who won't use Password Safe and instead has a physical notebook with his passwords in obfuscated form. This notebook is obviously much safer against malware... whether it's at greater risk of loss/theft is an interesting question.


How does changing your password every 90 days increase security?

The reason password expiration policies exist, is to mitigate the problems that would occur if an attacker acquired the password hashes of your system and were to break them. These policies  also help minimize some of the risk associated with losing older backups to an attacker.

For example, if an attacker were to break in and acquire your shadow password file, they could then start brute forcing the passwords without further accessing the system.  Once they know your password, they can access the system and install whatever back doors they want unless you happen to have changed your password in the time between the attacker acquiring the shadow password file and when they are able to brute force the password hash.  If the password hash algorithm is secure enough to hold off the attacker for 90 days, password expiration ensures that the attacker won't gain anything of further value from the shadow password file, with the exception of the already obtained list of user accounts.

While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups.  Ideally, of course, everyone would be just as careful with the tape that has the backup from 6 months ago as they are with the production data.  In reality, though, some older tapes inevitably get misplaced, misfiled, and otherwise lost in large organizations.  Password expiration policies limit the damage that is done if an older backup is lost for the same reason that it mitigates the compromise of the password hashes from the live system.  If you lose a 6 month old backup, you are encrypting the sensitive information and all the passwords have expired since the backup was taken, you probably haven't lost anything but the list of user accounts.


Could a large amount of wget requests be viewed as an attack?

The answer is subjective but wget simply makes HTTP GET requests, just as is done with a browser.

At worst one might claim a denial of service (DOS) attack but if only a single thread, most would classify as either normal use or perhaps aggressive crawling.


Can this Javascript redirect be exploited in some way?

I'm not sure what you're imagining you might do, but the answer is no. String concatenation isn't inherently unsafe, nor is the code doing anything unsafe with the concatenated string. Redirecting to an HTTPS URL is the opposite of unsafe, and assuming you control the initial URL you could direct the "victim" to any URL you wanted anyhow.
If it was possible to change the URI scheme to something potentially unsafe (like javascript: or data:) you might have an attack vector for XSS. Even then, though, it'd be tricky to get something close enough to correct to load the page at all but also containing a meaningful payload, even if swapping out the expected scheme was somehow trivial. In any case, the scheme is hardcoded here, and you're not going to be able to change it.


Is it possible to log web sites that require Adobe Flash?

In most cases flash content is served with a distinct content-type like application/x-shockwave-flash. Proxies like squid can log this content-type additionally to the URL and I'm sure lots of the better firewalls can log this too. Note that simple packet filtering firewalls (iptables etc) will not be able to do this.

Since I doubt that you will replace your existing firewall with another solution or that you will add a proxy to the network and reconfigure all clients just for this feature I would recommend you contact the support of the solution you currently have and ask them. Also, since lots of content today is delivered by HTTPS you must either ignore this traffic or intercept it if your currently used product supports it.

Apart from that you might also used tools like tcpdump/tshark or IDS like bro to passively sniff the traffic and extract the HTTP traffic matching the specific content-type. This will not for for HTTPS though.


How are Google searches intercepted when they are supposed to be encrypted with https?

For the average webmaster, having Google switch to TLS has made tracking somewhat more difficult. The problem of course lies in that the referral connection was encrypted and so you can no longer just 'see' it as was the case years ago. That being said, tracking in not impossible. For instance the average webmaster can use services that essentially embed tracking cookies on many subscribed sites (Google themselves do this). Google only gives you analytic data to your site but it still collects all of this data (we will touch on that later).

Hypothetically, you could also create your own tracker that simply embeds a bit of code on every website that stores the user's info -however, this is obviously infeasible and also not needed (although Google and others do try)!

If you are a law enforcement agency, intelligence agency (GCHQ), or hacker, you potentially have access to the conduit that all of this traffic flows through (via court orders or exploits) and what's more is that you likely have access to the TLS certificates themselves (via court orders or exploits as well).

Obviously, there are legal and moral issues surrounding all of this but the technical rationale for how traffic can be monitored is sound. In regards to your GCHQ example (I didnt follow the link because I am at work and it contains the word 'porn' -can't have them tracking me now), the agency most likely had a subpena to access the information (if they 'hacked' the info, it would be poor OPSEC to disclose such a feat). Considering that the top 5 CAs are based in either the UK or US, this is not much of a stretch to assume. For example From a ToS at section 8.3:

  Comodo will disclose information where required by a subpoena, interception order or other lawful process.

If anyone can add some examples and references, that would be great. I tried to make this more than just conjecture but we will see how it is received.


What is the best way to encrypt my Windows user folder?

Try to use DiskCryptor. I don't think it can encrypt folders but it's very good at encrypting entire partitions. You can simply create a partition and use it as a folder and encrypt it using this free tool.

https://diskcryptor.net/wiki/Main_Page


Are there any risks associated with using a single U2F/FIDO key with multiple sets of credentials?

No, you are safe

Even if you entered it inside a malicious computer, your key could not be compromised. It uses the same security as a credit card; meaning a smart card. This smart card contains a private key that is not disclosed unless you physically open the smart card. This is the reason why credit cards with a smart card are so much better than credit cards with a magnetic stripe. The stripe can be copied just by scanning it while it's impossible to copy the smart card just by using it.

How it works?

It's basically a challenge-response mechanism. The smart card has a private key and it's the only entity that know this private key. When you authenticate, you receive a challenge; usually a random number or something like that. Then, when you press the gold symbol on your usb, the challenge is sent to the smart card that encrypt it using it's private key and then return the encrypted challenge. This encrypted challenge is then send back to the server which contain all the public keys matching the private keys that are stored on the usb. The server then decrypt the encrypted challenge with the right public key and verify that it matches the challenge.

About phishing

Phishing protection in U2F is top-notch it seems. See this excellent answer :

How secure are the FIDO U2F tokens

Still, beware of compromised computers

Even if your usb key cannot be compromised, you, as a user, are still vulnerable if you use a compromised computer. On a compromised computer, you cannot trust anything that you see. Even if everything looks good, url in browser, certificate, etc. You just cannot trust anything. I could present you a login page but I would in fact be using that login information to change your password for that site.

Conclusion

Your usb key is safe. You it's another story. At some point, you are the only one that can save you from using it on a machine infected with virus.


How to generate pfx file from private public key?

Okay, so DKIM uses only 'raw' publickey crypto and not certificates, but some 'application' for it uses PKCS12 format which requires a certificate. That's pretty silly.

If you have OpenSSL, and on Linux you should, it has several ways to create a self-signed certificate from a private key. A self-signed certificate doesn't accomplish the main purpose certificates were designed for, of distributing trust from a (relatively) centralized source, but it does package a public key with some other data in the form of a certificate, which is often convenient, including here.

The simplest way is req -new -x509 something like:

 openssl req -new -x509 -key privatekey.pem -days N -out dummy.crt
 # N is the number of days (from now) until the cert expires
 # reliers may or may not care about expiration of selfsigned,
 # but to avoid possible issues it is common to use a longish period
 # like 5, 10 or 20 years (roughly 1825, 3650 or 7300 days)

To avoid being prompted for the subject name fields, which are probably meaningless here, you can specify a dummy name something like -subj /CN=mydkim .

It is possible an application silly enough to use PKCS12 for this might want some particular extensions in the certificate; this opens a much broader field because there are about a dozen commonly-used X.509 extensions and hundreds or thousands of more obscure ones. If the 'application' document says anything about cert extensions, or you get an error related to them, post details.

Once you have the cert just use

 openssl pkcs12 -export -in certfile -inkey privatekeyfile -out pkcs12file


rkhunter is pretty old and you should pay people to perform security analysis on your systems.  Try running it against a fresh install,  and diff the results with your run.    That being said,  this is still no guarantee that you are safe.  If you suspect you have been rootkit'ed then you should reinstall OSX.


The company could use the laptop to scan everything on your network. What they can exploit depends entirely on what is exploitable.
To do this using best practice, you want to set up a separate network for the device. A lot of routers allow for a Guest network to be set up, and you could put your roommate on that.
You could put them on the ethernet and make sure that the ethernet LAN cannot access the WiFi network, if your router allows that sort of control.


As @logicalscope says, you can also look at the MAC lookup chart to find out the manufacturer. This could be spoofed.

You could try to find out the IP address of the device, then you could run nmap against it to see if you can identify the OS.

This could be hidden from you, so an alternative would be to try and connect to it - does it give banners back? Ports 22, 23, 80, 443 etc could be useful starting points here.

Failing that, try forcing it off the network and see if anything breaks :-)


Wifi penetration testing: Why aireplay-ng de-authentication does not work?

I had the same problem and after some research I found that everything worked fine when I disabled the wlan0 interface before running the attack.

To disable the wlan0 interface, I used the following command:

ifconfig wlan0 down

Then I tried the following command again:

aireplay-ng --deauth 1111 -a macadress-of-ap -c macadress-of-client mon0


Redirect a user to a trap page using evil twin

Because the victim is running through the attacker's network, the attacker can dictate the network settings, like what DNS is used or redirecting traffic.

So, yes, it is possible for the attacker to redirect DNS queries to Facebook to their own laptop's web server, and while the URL looks legitimate, the victim is actually using the attacker's web page.

Alternatively, the attack could simply record and replay all the traffic going through using a proxy, and the victim actually visits Facebook, but the attacker sees everything the victim sends, like usernames, passwords, files, pictures, etc.


Does it make any difference of the order Hashing and Encrypting in terms of security?

You don't want a hash; you want a MAC.

The scientific answer: you apply the MAC after encryption, not before. It is known as "encrypt-then-MAC" and it has a lot of benefits over doing things in reverse (aka "MAC-then-encrypt") or in parallel ("MAC-and-encrypt"). See this question for details.

The moral answer: don't do it. It is hard to make these things securely. You don't know enough to do it. Even people with a PhD in cryptography consider that they don't know enough to do it. When such a thing must be done, a cryptographer produces a tentative design and submits it to his peers, who scramble and try to break it for several years. Only survivors are deemed "apparently secure".

The practical answer: there are nice encryption modes which combine encryption and MAC for you; these schemes have survived the onslaught of enraged cryptographers. See GCM and EAX.


Does the server certificate control the cipher suites available to secure the communications?

No, there is no restriction coming from the TLS protocol version with regards to the hash function used by a CA in its signature algorithm.

In TLS 1.2 the client can advertise both the signature algorithms and the hash functions that it supports; this is done in the signature_algorithms extension, which is optional. A given client may perfectly well send such an extension stating that SHA-1 is supported as part of RSA / DSA / ECDSA signatures. Actually, if the client does not send the extension, then the server is supposed to assume that the client supports SHA-1.

In SSL/TLS versions prior to TLS 1.2 (thus up to, and including, TLS 1.1), there is no such extension: the client does not indicate what hash functions it supports.

In practice, a server usually has only one certificate at its disposal, and will send it, regardless of how that certificate was signed by its issuing CA: the client will accept the certificate, or not, but the server does not have anything better to send anyway.

Google and Microsoft currently appear to want to wage a war on SHA-1 (in fact Google started it, and Microsoft must follow so as not to seem lagging and irresponsible), but this is not related to the TLS protocol version.


Is using sensitive information to generate a UUID v5 considered secure?

Whether this is secure depends on the entropy in the secret.  If your input is a regular password, where entropy is low, any simple hash using your password and other determinstic data is insecure because an attacker can simply brute-force all the possible passwords to determine yours.  This is true of literally all such types of simple hashing of passwords, with or without additional data, whether in a UUID or not, and whether or not truncated.  There are many, many password lists of breached passwords and it's extremely easy to generate many possible passwords programmatically.
If this is a pseudorandomly generated token with enough (e.g., 128 bits or more) of entropy, then this is secure.  Using a cryptographic hash function on a high-entropy secret is secure because it is impossible to efficiently guess the input based only on knowing the algorithm and the hash, since the domain of the function is sufficiently large.


Changing Structure of SAM database to disable LM usage

It is not recommended to change SAM file and it is not reasonable to make modifications on it. If you have physical access to machine, nothing will help you to stop adversary. LM and NTLM hash types must be inside SAM, by disabling LM hash exchange during communications is enough to stop "some kind of" hijack and cracking techniques but It will not disable or change SAM structure.


HMAC provides message integrity and authentication. If you receive a message with a correct HMAC on it, you know that:

the message is intact;
the sender has the key.

Since the sender has the key, you know the message originates from somebody you gave the key to. If you distribute the key only to known users, you can be sure that the message originated from a known user.

Sometimes the key is used by the same system and no key exchange is necessary. For example, a password reset functionality on a web site may create a HMAC and send that by email. If you click the link in the email, the same site verifies the HMAC. Since the HMAC is created and verified by the same software, not verification is necessary.

In other applications, for example in OpenID, each client has its secret shared with the server. When adding a client to OpenID you also need to specify the key for the HMAC operation. This configuring step is done once.

In your example with the C# client and server, the key is hardcoded. The server can then verify that the request really originates from the client. However, it
would be pretty easy to extract the key from the client and forge a request.

A key exchange method for HMAC does not really make sense. It may be usable in another cryptographic mechanism, but normally HMAC keys are fairly static.

Finally you ask how this works in conjuction with HTTPS. HTTPS provides server authentication. You could use client certificates to achieve client authentication, but this is not enabled by default. With HTTPS, messages can't be modified in transit. So the only thing that the HMAC solution could add is client authentication.


Two-way SSL/TLS, client host verification

Yes, TLS has provision for mutual authentication during the handshake process.

In this case, the server will add a certificate request message to his handshake along with his certificate server and server key exchange (so it will happen very soon in the handshake).

Note that mutual authentication is compatible with TLS/SNI because the SNI header is added to the client hello message which happen before the server sends his client certificate request message back.


Was the Stuxnet S7-417 payload a firmware update?

According to Lagner:

  Immediately after infection the payload of this early Stuxnet variant
  takes over control completely. Legitimate control logic is executed
  only as long as malicious code permits it to do so; it gets completely
  de-coupled from electrical input and output signals. The attack code
  makes sure that when the attack is not activated,
  legitimate code has access to the signals; in fact it is
  replicating a function of the controller’s operating
  system that would normally do this automatically but
  was disabled during infection. In what is known as a
  man-in-the-middle scenario in cyber security, the input
  and output signals are passed from the electrical
  peripherals to the legitimate program logic and vice
  versa by attack code that has positioned itself “in the
  middle”.
  [Page 8]

That seems to suggest that logic flow was changed at the software level.

[Side note] It appears the original Lagner article has been moved. The PacketStorm link works.


If you're asking in theory, can such a system be built securely?
My answer would be yes, absolutely, but it's not trivial work - and most likely would be done wrong (depending on who designed and built it).

If you're asking about existing services, while I'm not familiar with the one you mentioned, in general I don't know of any good, reliable, secure systems for this.

If you're asking, how can I tell if a specific system is secure and reliable?, well, ya can't.
Unless you (or an expert you trust, and is proficient enough in the given technology) performed an in-depth code review, penetration test, and other security reviews. And periodic deployment and server examinations. And so forth...

And no, getting a 3rd party certification such as HackerSafe (not even PCI:DSS) is not good enough, not for you to entrust the keys to your most sensitive data. (Unless its a service you know well enough to trust).


Import Public Private key pair to a Keystore

When creating a keystore with the Java keytool a keypair is generated and the certificate is signed with the private key itself. Therefore you have a self signed certificate in this case.

You can check this with the command

keytool -list -v -keystore <keystore>

The first certificate shown should have the same Owner and Issuer.


Teamviewer logging remote keystroke events

Simply running basic image recognition on a low-resolution, low-framerate video to detect the keys being pressed via an on-screen keyboard would not degrade performance, so it is a practical attack against virtual keyboards. There are free and easy to use spyware utilities that come with this functionality built in, so even script kiddies can do this.

You fundamentally cannot input information securely when your method of inputting is compromised. The most a virtual keyboard can do is protect against hardware keyloggers connected to the keyboard. If something is monitoring input to a remote or virtualized machine, you've lost.

Perhaps you want to use a KVM (Keyboard Video Mouse) switch. They are devices which allow remote access to, as the name states, the keyboard, display, and mouse (and often other HIDs). These devices are simple and do not run a complex operating system, nor do they allow executing files, making them more or less immune from malicious activity. They are nothing more than an extension for your monitor and input devices.


Using / finding covert channels in inter-process communication

Just some random musings here: this is quite an interesting problem, and I assume that both good guys and bad guys use the same client, and that bad guys are secretly chosen by the moderator and unknown to each other.

In this scenario, simply detecting communications with the server isn't going to be enough, because a good guy must do so in order to acquire information. Also, any protocol to elect a supervisor good guy might choose a bad guy instead.

It is also unclear whether the guys, good or bad, have a private or public channel to communicate among them.

One approach could be to periodically broadcast on the public channel one's network status parameters. This means that the client is inherently "good" or "neutral" (it has no support for werewolf activity), so that any werewolf has to instantiate and deploy a workaround and trick his own client not to report "bad guy" activity. All the other clients would listen for anomalous reports (e.g. extra connections to the server); submitting an anomalous report, failure to submit anything, or submitting a corrupted report could be taken as evidence of werewolfishness.

For example each user could be requested to send publicly the results of a "good guy" utility that queries and timestamps the output of netstat -snap tcp and netstat -na to detect communications with the server in a non-deniable way. This could be boiled down to a simple utility that outputs a timestamp, a username, a random seed and a secret hash:

12345678:lserni:56789:SHA1("secret:12345678:lserni:56789:WEREWOLF!")

(Each user, even werewolves, would be expected to install the utility on the grounds of him being a good guy).

If the inter-guy channel is private, we can just let every client check the others at intervals. The werewolf will be immediately spotted as soon as he issues a death warrant, and all the good guys will shoot him down. This leaves all the other werewolves free to use their bullet at that turn to shoot down some good guy, but if they're under the same limitations the good guys are - they don't know themselves - then their action will be uncoordinated and ineffectual, and every turn will see a werewolf go down.

The scheme above still holds, if the werewolves are given a client of their own that allows them to coordinate, as long as it does not enable them to fake network status.


Possibility of SQLI in the following request?

Probably not.

As you can see, the query uses prepared statements:

WHERE `promotions`.`id` = ?

Of course, this is only a small part of the query, user input may be inserted directly into the query in other parts of it, so you should check if the id parameter is vulnerable anyways. This may actually be the case, 2170 and 2313 for example do seem to be injected into the query directly.

But just seeing parts of a query is no indication that an SQL injection is possible. It just tells you that something went wrong when performing the query.

Of course, sending this error message to the user is a bad idea in and of itself. The average user will just be confused by the message, and an attacker gains some information about query structure - eg that it seems to use prepared statements, at least in parts -, table and column names, and possibly used software, such as the type of DBMS, etc.


What is the best way to protect a captive portal againt MAC spoofing

I am not sure of any commercial implementation, but I saw an interesting idea that you can track physical proximity using signal strength, which AP, etc and determine that if the location suddenly is very different, that is likely a spoofer. I also found an interesting paper on spoofing detection using a fingerprinting technique.

The captive portal will be a web page. You may or may not be blocking all other ports before authentication, let's assume you can only get to 443 (80 redirects to 443) and only allow HTTPS. At this point they can only get to your captive portal page. Once they agree to the terms, log in, etc. you then can open up the other ports and allow web browsing anywhere they need to go.

If you are in a corporate environment, you will probably want to be implemented 802.1x, certificates, VPN, etc. to let them go anywhere and only keep the minimum ports open for authenticated users. VPN either at the IPSec or a higher layer would make the spoofing issue less likely. This allows you to restrict access where it won't matter if they spoof the mac, because they still can only get out to the VPN, and would need to attack the VPN.

If you are a hotel where you are tracking people by room number, spoofing the MAC would give someone a free ride, but it ends after the time period for which the legit user paid. You could implement something at the web proxy level to check certain cookies, headers, etc that will be more client specific.

The main security challenge of wifi is that your on an open network unless you are doing per-host type encryption (e.g., VPN). A MAC address should never be considered sufficient to identify someone.

Here are some resources related to security and captive portals:

How To: Using m0n0wall to create a Wireless Captive Portal - Captive Portal Management (2004)
Discussion on MAC spoofing mitigation for PacketFence Captive Portal Systems
This sec.SE post is also relevant


Is xhr.withCredentials making POST endpoints vulnerable to CSRF?

You don't need an AJAX request, the standard approach to exploit this issue would be:

<form id="myform" method="post" action="http://mysite.vulnerablesite.com/mysite/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

You can also send JSON formatted values (use enctype="text/plain"). You cannot however change the Content-type header to JSON or add a custom header like x-requested-with: XMLHttpRequest. The thing is, you can't do that with your AJAX example either.

In your example, the browser sees that you are sending a request that is perfectly allowed, so it doesn't ask the receiving server for its CORS policy (thus saving a request). It just sends the request and - depending on the response - allows or disallows reading of the response.

Now, if you were to add a custom header like xhr.setRequestHeader("x-requested-with", "XMLHttpRequest"), then you are asking the browser to do something which may violate the cross origin policy. Now, the browser will first issue a preflight OPTIONS request. If it is allowed to perform a request it will do so, otherwise it will not.

To prevent CSRF, you should use some token based defense. Because of the way CORS works, you could also check the presence of special HTTP header like XMLHttpRequest for a less secure CSRF protection.


Heartbleed and Facebook logins on (once) vulnerable sites

Sites that use Facebook logins should never have access to your username/password.  The Facebook API connects the user directly to Facebook, authenticates the user, and then passes that authentication back to the website that you're on.

If something different is going on, that website is probably behaving maliciously (think, emulating the facebook login process like a phishing site, in which case your facebook login would already be compromised).  In this case, there's a fairly narrow attack surface opened up by HeartBleed... if that site's private key is compromised, and the session where you sent your user/pass to them was previously captured by the attacker, then they would be able to decrypt your communication.  I'm gonna put odds on this one as pretty low.  Otherwise, if they are unpatched and you send your facebook user/pass to them again, then an attacker could grab it if they are attacking reasonably close to that moment.

I'm not gonna suggest that such a scenario doesn't exist anywhere on the web, but any site that you typically would want to access that uses a Facebook login never had access to your user/pass to begin with, because the API specifically protects against that scenario.


I've set up restricted shell environments that put the user into a chroot jail. Only the bare minimum executable files are copied into the jail. The shell user has hardly any permissions in the jail -- everything is defaulted to deny, and I only provide permissions where necessary. You could combine the jail with rbash for an extra layer of protection. The advantage of a chroot jail is that, if the user breaks out of rbash, he's still stuck in a chroot jail and can't access the rest of your system. (There have been instances where it's been possible to break out of a chroot jail, but properly constructed on a patched OS it is hard to attack.)

Another point to consider is whether you really need to provide a shell. Could the service you need to provide be set up as a simple, secure web service?

Finally, if the shell is provided via ssh, you can restrict the command set available to the user by requiring login via keys and setting the command= in your authorized_keys file. You do have to be careful here, though, because if the command(s) you permit allow the user to "break out", you're no better off than with the same attack against a restricted shell.


My bank's android app is logging session ids, account numbers, money transfers and current balance of my account.

If true, what bank? Shame them. It's also possible you have a piece of malware that's doing this.

  Is this normal?

No way.

  Do all banks do that?

I doubt it.

  Can a malicious app read my logs and get my account number?

Yes, they can. They can get session ids, account numbers, money transfers, and the current balance of your account. This can help malicious attackers do things with your account.

If I were a malware author, I'd be very interested in using the session ids and account numbers in particular. To a lesser extent, current balance. If I have your bank account number... the things I can do with that are quite nearly endless, especially if I know who you are.

  And finally if this is a security problem what do i do?

Uninstall it. Nobody's data should be hanging around like that. In fact, maybe if you point this out to the bank, they might reward you? You should point out that this is a terrible security practice.

If the bank doesn't do anything, as in they don't acknowledge that this is a security concern, or they don't even have the courtesy to call you, then by all means, go cause a big stink somewhere. Go to the media, and let it spread like wildfire.


Hashing two passwords can produce the same hash. How to prevent this?

It is a mathematical certainty that any hash function with a fixed output size will have collisions. However, the chance of a collision can be reduced by using a hash function with a large output size. Using SHA-2 with the default output size of 256 bits, for example, means that you will need 2^128 users before there is a 50% chance that some pair of them will have the same password hash[*].

Ideally, you should apply a hash function to SALT+PASSWORD, where SALT is a unique value specific to the user account. If the salt values are chosen uniquely over accounts, this virtually ensures that both username and password must match with a specific account to allow logging in.

Please note that the above is only intended to explain the concept. In practice, you should almost always delegate this task to a quality implementation of a standard password hashing function, such as PBKDF2 or bcrypt, rather than rolling your own.

[*] - assuming no pair of them actually have the same password, which can happen with surprisingly few different users.

In the case of Alice and Bob having the exact same password and Alice logging in as Bob accidentally, there is nothing you can reasonably be expected to do about this.

In terms of unreasonable efforts, you could store the hash of PEPPER+PASSWORD for each user (where PEPPER is a site-wide constant), run a script to detect same-password cases, put the hash on a "bad list", and automatically send e-mail asking users to change their password if their password hash is in the "bad list". Note however that this opens your site up to a new kind of attack whereby an attacker repeatedly changes their password to a common password and waits to see if an e-mail is generated. If it is, they know another user has that password and they can try common usernames with it (or, the result of scraping any available public data for usernames, such a site forum). So you should rate-limit the script that sends e-mails (for example, to once per day) to reduce the efficacy of such an attack.


Rationale for security lockout after changing a password

I am with @Cowthulhu about the cooldown time.

Lastpass uses something similar for their recovery access: you can designate someone as trusted, that person can request an access to your password vault, but will have to wait a predefined time (predefined by you, from nothing to a few days) to give you time to revoke the access. In the meantime you recieve an email stating that a request was done.

Have you received a message from the site owner right after the change with some similar information ("your password was changed but the user is locked for 30 minutes, if it was not you contact us during that timeframe so that we revert the change")? Since you asked the question - I guess not, but maybe this is buried somewhere in the informational email.


Reasonable security measures for unvalidated "login"

You've hit the main threats, but there's a few that you've missed.

You're leaking information about how many patients you have. It sounds like you're using sequential values for your Patients table's primary key, so exposing that key will tell a patient how many patients you've had before them, and two patients who first visited at different times will be able to determine about how often you add patients. While perhaps not something you care deeply about, there's no need to leak this info.
You mention that the links expire, which is good, but it sounds like you're not automatically expiring them upon use. I recommend that, as soon as the patient submits their information, the link can no longer be used. This is especially important if it would otherwise be possible to view a patient's past answers using the same link.
You don't mention how the random numbers - which are essentially authentication tokens - are generated. If it's using the standard random number generators common to all major programming languages, then a malicious user can probably guess them correctly. The normal RNG functions are typically seeded from the current time (which narrows the space of values to search quite dramatically, even if the attacker doesn't know to the second when the value was created), and also can usually be predicted based on other numbers from the sequence (so one or more patients, whose own numbers are known, could predict the numbers of other patients forward and backward of themself/ves).
32 bits - even if they are generated using a secure random number generator and thus unpredictable - is shorter than ideal. Realistically, nobody is going to try the ~2 billion requests it would take to guess one by brute-force, given the low sensitivity of the site, but it's not actually impossible to send requests at a rate fast enough to make that feasible (your server is the only bottleneck; an attacker with even the short use a botnet can generate billions of requests, though usually this just knocks the server offline).

Now, none of these are high-severity risks, especially since there really isn't that much at stake. Still, you asked for advice, so... Given all of that, here are some recommendations:

Remove the plaintext primary key from the URLs. Either just use the "random number" (token) to identify patients, or pass the primary key through a HMAC (with a key that is not exposed to the patients) so they cannot tell what their number is (or make a meaningful guess at anybody else's valid number). You can create a database index on the token to ensure you're still able to quickly look up patients using it.
Lengthen the token to at least 64 bits - 128 is the usual - and use a cryptographically-secure [pseudo-]random number generator to create it. A type 4 GUID/UUID works, if you have a handy tool to emit them (note that not all types of UUIDs are suitable here; it's not actually what the data type is for).
After the patient submits their survey answers, invalidate their token (you could remove it entirely, or just use the expiry field to mark it as no longer valid). Don't invalidate URLs that are visited but the survey isn't submitted (until they expire); some email programs proactively send requests to URLs found in the email, to check them for malicious responses. Do continue to expire the tokens the way you currently do, for surveys that are never taken.

Additionally, just to be clear, you need to generate a new token for each email, rather than just reusing them for repeat patients. It sounds like you're already doing this but I wanted to be explicit about it.

Overall, good stab at a threat model and some mitigations.


How is the iOS KeyChain master key derived?

See these slides for an introduction on data protection on iPhones (presumably, iPads are similar). At the core of the system, there is a device-specific key called the UID-key; it is stored in the CPU itself and each CPU has its own. From that key are derived other keys, including the one used for KeyChain; the user's passcode is also used in the key derivation. The CPU is assumed to be tamper-resistant, which means that you should not be able to extract the UID-key from it. If you access the hardware directly, you can make the CPU use the UID-key, but any brute force attack on the passcode will need to go through the actual CPU.

To sum up, breaking through an iPhone's KeyChain is feasible, but at the cost of an exhaustive search on the PIN code which must use the actual iPhone CPU (so it is not offline). Of course, we are most interested in KeyChain's resistance precisely if the iPhone was stolen, in which case the attacker has access to the hardware.


Signing up on a paid site with a credit card

Imo, this question doesn't exactly belong here as well but hey we're helpful people, right?

How do I verify a card's validity without making a charge on it?
There's no way, but the charge can always be refunded. For example, what many companies like AreaNet do is that a 0.01$ charge is made on the credit card, and then the charge is refunded. This can be done automatically generally using the banking payment gateway's APIs. Since we're only programming it to refund all 0.01$ payments, it is not a security threat that someone can exploit and also helps us confirm the card.

Looking up to see if it's presently used?
While many companies have been known to do this, they do it by storing the credit card information of their customer in plain text. Don't do that. Use a good undisclosed encryption algorithm with the key unique per user. However, before that remember to store a SHA hash of the true/original password in a mirror column next to the encrypted passwords.
If the encryption algorithm is a custom variant then even better!

Every time you want to verify if a card is registered before, hash the input and run a simple  "WHERE" queries in the hash equivalent column of the CC table.
Whenever you want to use the CC, use the encryption algorithm along with the key to decrypt it and obtain the true information.


How to estimate the number of entropy bits & search space of a signature system like passtouch?

Your very rough calculations seem to be a gross overestimate, as the line has to be continuous.  For simplicity let's first neglect curved lines.

Then since it is one continuous line, let's imagine it as a 10x10 continuous grid (my finger widths on an ipad; I doubt it will be more sensitive in rejecting passwords until its more than a half-fingers width of error) over the section covered by the passtouch logo.  A possible password is then a series of points (starting point and each point where it changes direction).  So that all matters is starting location and then travelling to a few points.  For example, dropping the circle at the end of the demo video the demo password there were 5 points.  If the points were randomly chosen (probably a bad assumption as humans are poor random number generators), you'd have ~2^33 possibilities.

Now there's the question of how much entropy does making a curve add?  You could approximate as each new direction of a curve (change in concavity) is equal to an additional new point (the point the curve must go through to go from the start point to the end point) as if you only had a straightline.  So the demo password with the curve at the end counts as 7 points with ~2^46.  This is roughly equal to a password with 8 upper/lower case letters chosen at random.  I personally wouldn't trust encrypting other passwords (I hope it encrypts) by protecting with a key that's this weak.  There's further weakness in that people will probably not randomly choose circle widths; but instead choose width to circle/weave around circles already in the figure.


Does verifying an additional fraction of a file decrease the chances of collision?

You might be interested to read about ssdeep, a "context-triggered piecewise hash" (CTPH) used as a content-agnostic form of fuzzy hashing.  Ssdeep builds hashes of pieces of a file so that similarity can be determined; say one character changes between two otherwise identical files.  The checksum of the changed file parts will differ, but the checksums of all other parts will not, so the files are deemed to be highly similar.

You're essentially trying to do this but without intending to use it to measure file similarity.

I am under the impression that as long as you keep entire hashes (do not truncate them) and the segments you hash are large enough to make collisions rare (maybe 512 bytes?) then you will have a sufficient level of data integrity.  It is theoretically possible that you'll have more integrity since you have a longer hash length, but there are so many areas that you have to be especially careful about in your implementation that I would not at all recommend this.

That said, you specified three sha256 hashes, including one for the whole file.  As long as you're matching all three, this should be, at its weakest, as good as sha256 alone.  It's likely stronger still, but you'll (probably) be just as susceptible as a single sha256 when it comes to theoretical SHA-2 vulnerabilities, so you might as well go for another algorithm such as SHA-3 or even (since you still have the full file's sha256) something faster like MD5.  You can also consider storing the byte size.

256 bit SHA-2 should be sufficient for anything unless you're worried about the distant future. If that's the case, you can't take anything for granted, but I'd go with SHA2-512 and SHA3-512 and the exact file size.

If you just want more speed and aren't concerned with being attacked (i.e. you're just worried about data integrity from faulty hardware and/or crappy networks), you can start with just the file size, then calculate MD5 and SHA1 concurrently (two separate processes, one read of the file).  I still wouldn't mess with cutting up a file unless you wanted to use ssdeep (which appears to use MD5 for its pieces by default).

Perhaps an attractive balance of speed and integrity could be to check the file size, then the MD5 of the first 5MB (or the whole file if under 5MB), then the real integrity check, e.g. sha256 or sha3-512.  It should* be harder to create a collision and faster to detect failures (stop on the first failure) while being only negligibly slower than just the last check (it took me 0.003s to calculate the MD5 hash of a random 5MB test file).  (* I'm expert in neither cryptoanalysis nor cryptographic checksums: this is not authoritative.)

I'm tempted to say that if an attack isn't suspected, you'd be fine with both file size and MD5 (you'd probably be fine with just MD5, though file size would allow you to fail faster and provide slightly better data integrity).


Using AesCryptoServiceProvider in C#, should using an incorrect IV mangle just the first block?

I want to clear a couple of things first:

What you're seeing is the intended and correct behaviour.
ECB doesn't use chaining and it applies the block cipher to the plaintext block by block separately, so there's no point to discuss IV and ECB because the two don't really work with each others.

Let's start with CBC encryption. It's quite simple; take the  first plaintext block and XOR it with the IV, apply the block cipher on it, take the resulting ciphertext and XOR it with the second plaintext, apply the block cipher, XOR the result with the third plaintext block, and so on.

Now let's look at the decryption. Take the first ciphertext block, apply the block cipher on it, and then XOR it with the IV, (pay attention here) then move to the next ciphertext block and apply the block cipher on it and then XOR it with the previous ciphertext block, and so on.

Now, can you see it? The IV is only used when working on the first block, and that's why using the wrong IV for decryption will only give the wrong first block with all of the next blocks decrypting just fine.

The same logic can be used for CFB decryption

For the sake of simplicity, you can think of it this way: The IV of the first block is the actual IV, while the "IV" for the next block is the  first block's ciphertext, and the "IV" for third block is the second block's ciphertext and so on. Guess what? When trying to decrypt without the correct IV, you already have the ciphertext, so you already have the "IVs" for all the blocks except for the first one.


Security test within a staging environment. Is SOAPUI sufficient as a test tool?

SOAPUI is a good tool to execute a DAST (Dynamic Application Security Testing).
Another good open source tool is OWASP ZAP. There are also a bunch of commercial ones.

It's not the tool you are testing with, but the web attack payloads it runs against your application. If two of the tools have the same web attack payloads, there is no need to use another one.

You could also potentially do tests like SAST (Static Application Security Testing) which analyzes your source code for vulnerabilities before deployment or SCA (Software Composition Analysis) which would check for vulnerabilities in your third party dependencies you are using.


Isn't Youtube supposed to forget what I did during an incognito session?

First note that just because something can be explained by YT tracking you in incognito mode, this does not mean that this actually happening. Just because there is an apparent explanation does not mean that this is the only explanation or that it is the correct one. Note also that you have a biased perspective, i.e. you argue based on a single video which you've watched in incognito mode and which got recommended to you, but ignore all the videos you watched in incognito mode and which did not get recommended to you.
I doubt that YT actually knows what you've already watched in incognito mode and therefore recommends you the same thing again. But YT (or Google in general) tracks your general interests, not only on YT itself but over many sites using Google Analytics embedded in a significant part of the web pages.
It is probably correct to assume, that watching this video somehow aligns with your interests. And that you've implicitly shown these interests by watching other videos on YT or by visiting other sites while not being in incognito mode. Or the video was included in a site you've visited recently. So the recommendation does not completely come out of the blue and there is no need to actually track you in incognito mode to recommend you this video.


Access and Refresh Tokens (which aren't always JWTs) provide an additional layer of security and usually related to access.
As for your concerns, the expiry is not a sole defense against an attacker. You still need to enforce encrypted communication and secure storage of the tokens.
That is, if you have an attacker who gained access to your system in away that they can read your credentials, it's game over. No matter what kind of tokens you use. Even 5 seconds are plenty of time for a scripted attack.
The expiry serves two purposes:

It forces the system to re-interact with the identity and access management. This allows you to invalidate not-yet-expired Tokens from the Server Side (for example, if the User changes their password or clickt an Sign-me-out-everywhere button).

And it ensure that if you forget to explicitly invalidate them, they expire automatically.

A setup with Access and Refresh Tokens, as for example defined by the OAuth 2.0 Framework, provides additional security if implemented correctly.
You only need your Username and Password on an explicit login. Your client software (App or Browser) should never store these, as they are the keys to the kingdom. For example, your Google Username and Password allows you to access Mail, Calendar, Dokuments, App Store and all other Services provided by Google.
Access and Refresh tokens, on the other hand, can be scoped: they give you only access to a subset of the services you can normally access. An Access Token could be limited to use with email. If an attacker gained access to that token, they still can't access your Calendar, for example.
JWTs on the other hand are usually used as an Id Token, where you want to get more information on the user accessing the resource.  Have a look at the documentation on the Auth0 Website on Tokens. The differences of the tokens are subtle.


Should smartphones with AI assistants be restricted for use in office?

Short answer is yes. Any recording device that you do not control should not be used where the information it records is sensitive.


Is privacy part of the CIA triad or an independent concept?

In the CIA triad, privacy is often seen as equal to (or part of) the confidentiality concept.

  Roughly synonymous with privacy as a security concern is the Confidentiality part of the CIA Triad.

(Source)

However, you can also relate privacy to the entire CIA triad, as an overall goal:

  Privacy relates to all elements of the CIA triad. It considers which
  information can be shared with others (confidentiality), how that
  information can be accessed safely (integrity), and how it can be
  accessed (availability).

(Source)

Privacy often refers to individuals and what of their personal data is collected/shared, while confidentiality is about protecting the access to the data. If an attacker manages to download the customer database of a webshop, the system failed to provide confidentiality -- and in consequence, the leak of addresses and phone numbers compromises the privacy of their customers.

Also see: What is the difference between privacy, confidentiality and security?


I think you are doing good the commands... but the sslstrip technique doesn't depend only on your side. It depends of a lot of factors... if the "victim" is using bookmarks using always https://whateverpage there is nothing to do. He/she is going to ask directly always for an encrypted page.

If the "victim" is asking for pages using whateverpage.com without putting before https, he is going to ask for the http page. Even if the site has HSTS activated (which is going to receive the http request and will redirect it to https page version), you can do sslstrip because there is a request for an http page... only one, but enough for sslstrip. It is going to show the page in plain to the "victim" and it will do the ssl connection to the real site.

So many people say "HSTS is the solution to sslstrip". And this is NOT TRUE. I did sslstrip a lot of times testing access to pages with HSTS and it works... they key as I said is the victim must do the http (without "s") initial request.

Another decisive factor is that not everypage can be sslstripped if you use common browsers... I mean, if you use Chrome, Firefox or Internet Explorer for example... these browsers have an internal list of known ssl sites. That sites (like twitter or facebook for example) will never be sslstripped because the browser knows that ALWAYS must look for them using https even if the user did the "bad way request" putting facebook.com without specifying the https:// before. I guess these sites pay to the browser's companies to be in that list.

I suggest to you try against not very known ssl pages because in that way there are less possibilities to crash in your tests against a site which is in that browser internal lists.

There are more advanced techniques to do sslstrip even to pages in that lists... like Delorean attack, etc... but are more complicated.


Can revealing Intranet address become a security threat?

If you are talking about the Internet address such as example.com, then you are safe. That is what others will use to find your company website.

If you are talking about the intranet address such as example.net, not really unless it also reveals the network topology, then it is possible to have an issue as knowing the network topology can make a dhcp and dns poisoning attack possible.


Can uncompressing a ZIP/tar.gz/rar/etc file execute some custom code?

There are several slightly overlapping questions here:

can ... execute some custom code

This might be possible due to security bugs, even if it is not intended functionality.

is this hidden functionality of .tar.gz

No. This is generated by the OS

a ZIP/tar.gz/rar/etc file ...

As for ZIP, tar.gz and rar - these don't have this functionality. As for "etc" - maybe, when choosing the right value for "etc".


Tor browser prevents somebody watching your Internet connection from
  learning what sites you visit.  It prevents the sites you visit from
  learning your physical location, and it lets you access sites which
  are blocked.

This statement is valid for Microsoft Windows OS. So to answer bluntly: No.

EDIT:

Following your comment: As by your machine being compromised you are asking if your Tor browser activities are no longer that protected.

From the official documentation you can read:

  The User Agent MUST (at user option) prevent all disk records of
  browser activity. The user should be able to optionally enable URL
  history and other history features if they so desire.

So as long as you did not change the default settings of your Tor browser, it won't save your browsing history in any file. This way, even if your machine is compromised, your Tor browsing activities are still protected.


Is a console application with NT Authority/System rights dangerous?

What kind of application is this, and how does it get executed before logging in?
Actually, scratch that, a better question would be: WHY is this application allowed to run.

Yes, it is very dangerous.
This allows arbitrary users to run any system command. The process account is known as LocalSystem, which is the only local account with more privileges than the Administrator.
This application can do a.n.y.t.h.i.n.g. Anything at all on this system: change the admin's password, install services, attach to memory of any process, anything anything. On this system.

Additionally, depending on configuration, the LocalSystem application could probably authentication to other machines in the domain as the machine's computer account. E.g. for registering changes in ActiveDirectory, etc.

However, one thing specifically you asked about - acquiring domain admin rights. This is not so simple (assuming the application is not running on the DC), since we are talking about local privileges.
So, while that machine is completely violated (as in, nuke it from orbit), the rest of your domain is (relatively) safe. (well, at least from this application).