Blackberry QNX / Playbook encryption details Now that Blackberry received FIPS 140-2 certification for one of it's QNX devices, does anyone have technical specifics on how data is encrypted on both mobile phones or the Playbook tablet?

I'm interested in seeing the differences in how information is treated (technically) in the "Playbook" partition vs the "Enterprise" partition.  Is the same encryption used?  What keys are used?

Source Blackberry Knowledge Base

  "Security of work and personal data on the BlackBerry PlayBook tablet"

Does the tablet store any work data persistently in the work file system?

No.

When a tablet is connected to a BlackBerry® smartphone using BlackBerry® Bridge™, the tablet temporarily stores work data in the work file system on the tablet. The work file system is encrypted using XTS-AES-256. The keys that the BlackBerry® PlayBook™ tablet uses to encrypt the work file system are encrypted using the BlackBerry Bridge work key. The tablet stores the BlackBerry Bridge work key in RAM only.

When the Bluetooth® connection between a tablet and a smartphone closes, the tablet and the smartphone each delete their copy of the BlackBerry Bridge work key. All of the work data that is stored on the tablet is encrypted with keys that are encrypted using the BlackBerry Bridge work key, and both copies of the work key are deleted. This data and key encryption means that it is not possible to decrypt the work data after the Bluetooth connection closes and the smartphone and tablet delete their copies of the BlackBerry Bridge work key.

What is XTS-AES?

XTS-AES is an IEEE-approved Advanced Encryption Standard mode for disk encryption that provides protection against manipulation of encrypted data. XTS-AES-256 uses 512-bit cryptographic keys.

Does the tablet encrypt personal data?

No.

Can I disable the feature that allows work applications to attach personal files to work email messages or calendar entries?

No.

Is the cryptographic module on the BlackBerry PlayBook tablet FIPS validated?

Yes. The cryptographic module on the tablet has received FIPS 140-2 certification.

Can I set a password on a tablet?

Yes. A user can configure the tablet password and timeout options using the Options menu on the tablet. If you set a password for the tablet, you must provide that password to log in to the tablet.

Is work data protected by the smartphone password?

Yes. After a BlackBerry PlayBook tablet user connects the tablet to a BlackBerry smartphone that requires a password, the tablet automatically requires the user to provide the smartphone password when the tablet accesses any smartphone data. Smartphone data can include email messages, calendar entries, tasks, memos, BlackBerry® Messenger messages, intranet content, files, or attachments that the user views on the tablet.

The requirement to provide the smartphone password to access work data is independent of the tablet password that a user may set.

Do the IT policy rules that control the password security level of a smartphone extend to a tablet?

Yes. If a user connects a tablet to a smartphone that is associated with a BlackBerry Enterprise Server, any IT policy rules that control the password security level of the smartphone apply to the smartphone password that the user must enter to access work data on the tablet.

What password security level is enforced if I connect a tablet to a smartphone with one set of IT policy rules, then disconnect and connect the tablet to a smartphone with a different set of IT policy rules?

While the tablet is connected to the first smartphone, the password security level that is set for that smartphone is enforced. This security level applies to the smartphone password that a user must enter to access work data on the tablet. It does not apply to the tablet access password that a user may set on the tablet.

When you connect the tablet to another smartphone, the tablet deletes the work file system that temporarily stored work data associated with the first smartphone. While the tablet is connected to the second smartphone, the password security level that is set for that smartphone is enforced. This security level applies to the smartphone password that a user must enter to access work data on the tablet. It does not apply to the password that a user may set on the tablet.

Additional information can be found here (also see the links in the comments)

http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/BlackBerry-PlayBook-File-System-Layout/ta-p/773327?CPID=E10C020&Date=040312

Alias   Path
File.applicationDirectory   /accounts/1000/appdata/(appdir)/app/air
File.applicationStorageDirectory    /accounts/1000/appdata/(appdir)/data
File.desktopDirectory   /accounts/1000/appdata/(appdir)/shared/documents
File.documentsDirectory /accounts/1000/appdata/(appdir)/shared/documents
File.userDirectory  /accounts/1000/appdata/(appdir)

  Now, in that list, the (appdir) folder (which refers to a folder named
  for your app's Package Name and Package Id joined with a dot, as in
  "Foo.QXBwRXZlbnRzICAgICAgICA") is not writable by your app.  The app
  has read/execute permission only, and only root can write to it.


Need DNS changer app (or method) which actively locks DNS servers I have tried all methods in the following link except DNS+DNSCrypt (having issues in flashing files):
https://forum.xda-developers.com/general/xda-university/guide-how-to-change-dns-android-device-t3273769/page1

I need something which actively locks DNS after I set it.

I have tried Override DNS & scripts in the link but that only set my specified DNS after reboot and connectivity change and do not prevent DNS servers from changing.

Instead of locking DNS records, you can try to block all DNS requests.

If the problem is that you then cannot add new DNS records to domains that are not in the hosts file, just check all incoming DNS requests and see if the domain is in the hosts file. If it already is, block the DNS packet, so it doesn't change, if it is not in the hosts file, add the domain to the hosts file.


Security concerns around sharing secret on a website I need to share credentials with users. These credentials are created when the user wants them, but cannot be chosen by the user specifically (AAD credentials). I want to share the same with the user on my website(just once, at the time of creation). What are the security concerns around the same?

The website is using TLS, and proper authentication & authorization procedures are followed.

Shoulder surfing may be a problem. Malware on the client's device could screen scrape. Remote desktop session administrators may be looking at the desktop. SSL breaking proxies may store the data in transit (on the client's side where you might not know what their local proxying setup is). What is a user leaves the web page tab open and walks away from their device/computer?

Not that any of these are any riskier than other methods of communication, you just need to asses the risk vs cost of any credentials sharing system and make an informed decision on what level of risk to accept.


How to support search of data under PCI-DSS? Suppose that the data in question is a card PAN. According to PCI-DSS, you have to store it with extra security (encrypt it before storing in database and store the secret key elsewhere with more restricted access).

But what if you had to support searching based on PAN?

A. The straight forward solution would be receive a plain PAN, send it to the backend which goes through all the PANs in database, decrypts them, sees if they match the input, and then return the record with the needed data based on what is attached to that PAN (which sounds bad performance-wise).

B. Would hashing be a solution?
When a new PAN is created, encrypted and stored encrypted, a hash for the PAN can also be calculated (not reversible but still hiding the real sensitive PAN).
 - should it have a salt?
 - can the salt be stored same place as the hash? or does it have to be store in a more secure place, like a secret key?
 - is the salt shared with the searcher? should the searcher do the hash and pass the hash around ? or should it just pass the plain PAN around and let the hashing be re-done close to where the original hashed PAN (PAN digest) is?

C. Is the entire concept of supporting search by encrypted data bad from start (and it should not even be supported because there is no good solution for it without compromising on the extra security)?

D. Is there any other secure way to do indexing of sensitive data?

PCI requires the data be unreadable. This is generally done through encryption or hashing. As you state above, decrypting for the purpose of searching is a terrible idea for performance. Hence, hashing is a great option for fast searching and a strong hash is recommended/required. The PCI DSS doesn't require a salt be used. If you want to use a salt, it should be static to support the search speed requirement. If storing both truncated PAN and hashed PAN, you should be using a salt.


Can CSS file contain malware? I know that javascript files can contain malware. However, I am not so sure about CSS files. They only affect how the page is displayed, right? I know that css files can be used for clickjacking but I cannot imagine how they can be used to infect someone. How can a css file be used to compromise a machine? Are there any examples of malware/exploits using CSS files? Any pointers would be helpful. Thanks!

Yes: CSS can contain malware, though in my experience, its usually been tied to a vulnerability, e.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3971

As far as it containing JavaScript, that's certainly a vector, though successful exploitation should generally be limited by vulnerabilities within the Browser, the OS and the JavaScript engine.  Vulnerable ActiveX controls are a factor as well in such scenarios.


Is this a reasonable approach of continous network monitoring? I'm currently implementing some mechanisms to continuously monitor our network. Most of this is done through OSSIM but I also extended it by some self written monitoring scripts. Im currently doing the following:

Hourly host discovery scans of all subnets including the detection of common services (using nmap)
Permanent passive host discovery through broadcast monitoring (using tshark and packetfu)
Hourly scan of all hosts for nic's in promiscuous mode (using nmap)
Hourly scan of all hosts for activated ip forwarding (using nmap)
Daily "non destructive" vulnerability scans of all hosts (using OpenVAS)

Is this a reasonable concept or am I missing some major points?

// We did an initial validation of the found vulnerablities and did patch them if possible. Some of them weren't patchable in that cases we limited access heavily.
We are now verifiying new vulnerablities on a daily basis.
We also have HIDS on all Servers but I did leave that out here because it is not really related to the network.

The approaches you mention are a bit confusing, and I will explain why. In a properly designed infrastructure many of the bulletpoints you listed would be addressed:

Hourly host discovery scans - If you implement strong port security on your switches, and used NAC - PacketFence (since you mentioned open source, I did also) you wouldn't need to worry about what was plugged in. The counter would be someone commenting: "Well yea but MACs could be spoofed" I say: "If someone is on your PHYSICAL network spoofing MAC addresses you have bigger things to worry about. Network Address Control done properly minimizes someone just throwing something on the network.

Permanent passive host discovery through broadcast - This was addressed with the NAC comment, but even if it hadn't been, not all hosts respond to broadcast.

Hourly scan of all hosts for nic's in promiscuous mode - This is a permissions issue/system issue. A normal user cannot put an interface in promiscuous mode. Properly patched systems include updating software. Without a vulnerability, or permissions, a user would not be able to turn on promiscuous mode, with NAC, they wouldn't be able to put up their own machine.

Hourly scan of all hosts for activated ip forwarding - More overkill. Without permissions to both the system and the network, I don't see how forwarding would occur.

Daily "non destructive" vulnerability scans of all hosts (using OpenVAS) - This is a lot of noise.

Much of what you have written about aligns with the "castle" approach to security. This is where you keep building to block from coming in. In this case, instead of looking at what you have, and how to use it, you are adding more issues down the road. Account auditing (logging sudo commands, controlling who can do what as an admin) is a better approach than wondering whether or not someone is putting something into promiscuous mode. Implementing NAC keeps untrusted, untested systems off your network. It is a one two punch: "no random machines, and no machines in existence can be tampered with. There are not vulnerabilities." Is a quicker, more effective, and more scalable approach then what you mentioned.


Windows Phone and Hardcoding Values Let us say that I have a Windows Phone application.  If I hardcode a private key in the Windows Phone application, can people extract it once the application is released to the public on the Windows Store?

I am asking this because I have found no way of accessing installed certificates from the phone.

With software, reverse engineering works (there is even a dedicated StackExchange site for reverse engineering questions). Extracting secrets from compiled binaries has been done and redone and done again since the days of the first "copy-protected" games for personal computers, back in the 1980s. The bottom-line is that you cannot really hide a secret value in an application.

What you can do is to hide a customer-specific secret in the application. This is similar to giving to each customer his own login+password, except that the human customer does not see it (it is hidden in the application). This won't prevent reverse-engineering, but it may help with mitigating consequences: if a given "application secret" appears to be leaking too much (e.g. hundreds of different clients use it), then you can invalidate that secret on the server, without impacting the rest of your user base. (I assume here that your private key, to be hidden in the application, is used to talk to a server that you control.)

This is somehow equivalent to the Blu-Ray security model: each (physical) player has a player-specific key, and content distributors can blacklist keys which are known to have been leaked through reverse-engineering (the actual blacklisting uses a nifty system called broadcast encryption because it needs to work even without a network; but a Windows phone is a phone, thus presumed network-able).


Protecting users with browser extension. Is it possible, if the machine is already infected? Assume a trojan acquired admin privilege on a Windows 7 machine.
How easy is it for the trojan to replace/hijack/modify a browser extension without user knowing it? Is it possible?

I am thinking of implementing a chrome extension to provide additional security layer. So I would like to know whether the trojan can modify the behaviour of my "security extension" that easily. I can understand that the trojan might be able to easily uninstall the chrome extension without user knowing it (uninstalling is not a problem, but hijacking/modifying is).

Also, are there any special security mechanism to prevent the tampering of a chrome extension?

If a process (or a user, for that matter) acquires administrative privilege on a machine, it is able to do anything. Included replacing a browser extension with a malware browser extension without the user knowing it.

Any security mechanism implemented inside the machine can be nullified by the malware. For instance, your homemade extension could verify its checksum to ensure it has not been tampered with; however, it would be trivial to include in the tampering code a check to falsely pass the checksum test.


Plausible deniability with VeraCrypt standard volumes: what information do they give away? I know VeraCrypt hidden volumes can be used for plausible deniability, but what about standard volumes?

Indeed, properly encrypted data should be indistinguishable from random data. This way, if a whole disk is encrypted with a VeraCrypt standard volume, what proofs/clues are there that the disk is encrypted and not just contains random data?

For example, does VeraCrypt store unencrypted information in the disk that could be used as evidence, such as the hash/cipher algorithms used?

It's complicated. VeraCrypt volumes themselves appear to be random data - they're the output from an encryption routine which should be indistinguishable from random data, barring some flaw in the algorithm or implementation of the algorithm - and that applies for both volumes within files and for system encryption.

VeraCrypt accepts a password, then tries all supported key derivation functions, all supported encryption algorithms and all supported key lengths against the first 512 bytes of the volume. If one of these results in the first 4 bytes of decrypted data being the string "VERA", it is assumed that the methods used are correct, and the rest of the header is used to decrypt the rest of the volume. This means that it doesn't need to store information about the cipher used, or the size of key expected (See https://www.veracrypt.fr/en/Encryption%20Scheme.html for the full details).

However, if you have set up system encryption, the routine to perform this decryption is stored on the first track of the boot drive - this is unencrypted, else it couldn't be run prior to decryption. You don't actually need to have this installed - you could use a rescue disk to boot the system far enough to decrypt the volume, for instance - in which case only encrypted data is left on the drive.

In this case, the only evidence of VeraCrypt (or similar software) being used is the large blob of random data. The lack of a decryption method could be considered suspicious, especially in cases such as border checks, where it would be unusual to carry a laptop with a drive which had been overwritten with random data. On the other hand, having an encrypted drive, with the appropriate methods to decrypt for use is standard procedure for many business users (although this may normally be BitLocker rather than VeraCrypt).

For file based volumes, the presence of a file apparently containing only random data could be considered suspicious - most legitimate files have some sort of detectable header - even if VeraCrypt itself is not installed on the device. However, they don't have anything to indicate that they're VeraCrypt volumes - for example, I have a bunch of files which are simply dumps of random values from /dev/random on my work system, which I use for testing upload systems which claim to allow specific file types (by renaming them to the expected type, it tests whether the system is checking headers, or relying on file extensions, without risking accidentally using an accepted header type). There is nothing which could distinguish these from VeraCrypt volumes, other than that there is no (known) password which decrypts them to produce "VERA" at the start.

So:

For system encryption, there is a pre-boot decryption routine to allow booting without a rescue disk
For other types of volume, there isn't anything directly added by VeraCrypt, but the presence of VeraCrypt itself and a lack of obvious volumes could suggest something is hidden
For plausible deniability, the presence of VeraCrypt itself is not intended to be secret, but rather whether a specific bunch of random data within a VeraCrypt volume is another VeraCrypt volume or not
While direct evidence is hard to find, it may be possible to look at a lack of data and draw conclusions that something is hidden - see https://www.veracrypt.fr/en/Security%20Requirements%20for%20Hidden%20Volumes.html


Need assistance diagnosing hacked website Despite all my work to harden my website, someone has managed to hack it.

When loading the homepage in IE8, the page appears to load normally. Then, the status bar briefly displays a request to a domain that is just a jumble of letters followed by .com. It opens a Windows Media Player window, and as that opens the IE screen goes red with a "this site has been reported as unsafe" warning on it.

In Chrome, the site loads normally, and I get a warning that the Java plugin needs my permission to run. I did not grant permission.

In Firefox, everything looks normal, but in my NoScript menu there is an item labeled "http://undefined", which I of course blocked.

The good news is that I was able to capture a screen movie of the problem in IE and was able to note the malware domain for research.

When I first noted the problem I started Wireshark and have logged everything in and out of my PC since. This provided me with multiple DNS requests with domain names linked to the attack. I have also downloaded the server logs. Our entire site has been moved into a holding directory and an 'unavailable' message has been put at the root of our domain. I have changed our server login password.

I downloaded a copy of our homepage from the server and analyzed it. The malicious domain is nowhere to be found in it.  I utilize a few external JavaScript libraries, such as jQuery, that are loaded from remote servers. I am wondering if something could have happened on one of those servers?

Now I'm not quite sure what to do next.  I am a creator, not a security expert. My current position does not have an IT or Information Security department to get assistance from, so I am seeking help from anyone who may recognize the symptoms of this attack.

UPDATE: I found malicious files in my server identical to what was described at https://stackoverflow.com/questions/6686354/virus-problem-google-verify-php-and-ftp-passwords

Update Oct. 26: After reviewing log files, I found that the hack was done via FTP. Evidently my login was stolen somehow.

Steps to take in an attack like this:

In this particular case, it is important to cease serving the site, so firewalling it off would be appropriate -- either at a gateway device or by pulling the plug.
Next you would need to image everything you can. Some data can only be obtained live from the machine. I found a decent Windows-focused guide for you from CERT.
From there you need to take steps to identify how you were compromised and prevent it from happening again.
When you've discovered the necessary steps to secure the machine, use a new image.

The symptoms of this attack are that something has managed to alter the data being served by your website. They may be limited to just the files being served up by the site or they may have compromised the entire system.

You'll have to spend your time comparing good data to the damaged data. Hashing all the files between the directories is a handy way to start.

Beyond that, I think you've got a lot of time and learning ahead of you, or an outsourced forensics / malware / general security expert who is looking forward to you as a client.


Sending Commands using Hping3 I want to send my command to destination server.

I am using hping3. And;

hping3 -p 9999(running daemon and commands executing on this server) -S 127.0.0.1

I want to send my command. How to?

Hping3

Hping3 doesn't work on layers above layer 4. If your daemon digs through packets, then you need to use -E to fill the TCP data. (You then use -u to end the communication.) But, I'm not sure you can use hping3 to make a connection to a service on a port in the way you describe.

hping3 man page

Connecting Alternatives

It almost looks like you want to use netcat, or sbd, which can send commands.

nc 127.0.0.1 9999


Virus: Images get replaced on website I have installed Windows 7 again on my laptop with Chrome as browser. The problem is that on different websites I visit, the actual images of the website get replaced with out of context images. It happens quite often. Is it some virus? How can I remove it?

Check on another device to see if the same behaviour occurs.

I don't believe removal of malware is the scope of this forum. However, I'd recommend you do an virus scan, check your BHOs and Addins on your browser.


Hosted checkout page - who holds liability if there is fraud case? We are planning to use the hosted checkout page - does it minimize our liability and security measures? In the event of hacking of our website or poor security of the website, does it affect the customer's credit card information?

If there is a fraud case, is it our liability or hosted payment gateways liability? I read that you need lot of security to use the non-hosted payment gateway.

Not a lawyer, this is not legal advice.

This is a contractual issue, more than anything else.  However, a principal reason for using hosted payment providers is that they handle all the sensitive payment information, not you.  If it is well built, you should never even see that payment information (most redirect completely to the other site and then redirect back to you so that they can be assured as possible they are under their own control - they prevent frame embedding and so forth).  If the payment processor allows you to build the form, including the CC data, and call their backend, you will likely have more liability (because you have that access - you could do something dumb like logging the data before sending it to the processor. Never do this.)

If there is a compromise, you will likely be informed by your payment provider and be the one who contacts your customers, because you are the one they have a relationship with. Even this may not be true, however.

If you want to minimize liability, do everything payment related on their site - you should be only informed that the payment was made, not any payment details.  Get your contract read by a lawyer and make sure it spells out liability issues and your responsibilities and make sure that is acceptable to you.


Is there a way to securely check if a password is one of the most used ones? So lets's say that a user wants to register to some website. For whatever reason, I want to not allow that password if it is one of the top 100 passwords used on my site (So I'm not checking against just a top 100 dictionary, but one specifically for my site). However, all of the passwords on my site are hashed and salted. How can I check which passwords are in the top 100 most used in the most efficient and secure way? The only thing I can think of right now is storing just the hashes of every password and how many users registered with that password in a separate table. That way the attacker wouldn't be able to attach the password hash to the username and all they have is the unsalted hashes of the top 100 most used passwords. Is there a way to do this in a more secure or efficient manner?

Unsalted hashed passwords, especially hashes of common passwords, are trivial to reverse. For example, diamond is a top 100 password. A quick Google of its SHA1 hash of f872caad177d67bbe18c119d0505f2d3caa02af3 quickly reveals the unhashed password.

If a list you created a list that indicated that a set of users all shared the same password and that list was acquired by a hacker, then a password breach of one account would quickly lead to a breach of other the accounts.

This also opens up a new type of attack where an attacker can guess the top 100 passwords for your site by setting their account's password to likely choices. When it fails, they'll know they've found one. Then they can try logging into other user's accounts with that password.

Basically, storing passwords securely is difficult. The current technologies have been developed over decades. Any change you make to the current model will likely risk your user's accounts and passwords.

If you want, grab the list of the top 100, or top 1000, passwords and prevent them from being used. Just keep in mind that there is much controversy over the use of password requirements. Some feel they make things more secure, others that they just irritate users.


ISAAC pseudorandom stream - why is this considered strong crypto? I was looking for a good pseudorandom stream generator to supplement or replace RC4-drop-lots, in a noncrypto application. Since I'm mixing it with output from /dev/random, I decided not to use ChaCha for my purposes - /dev/random might already use it and I didn't want accidental correlation.

I decided something cryptographically capable would give me some guarantees against unpredictability, and I stumbled into ISAAC.

Wherever I see it mentioned, I see it referred to as strong enough for crypto work. But I haven't seen who decided that, and looking at the implementation in C, it looks for all the world like someone picked arbitrary constants for shift operations and fiddled with add operations until they got something that had good statistical properties. (I realize they often look like that, but this code seems especially arbitrary).

The one paper I found that does any analysis promptly diagnoses a bunch of weak keys and proposes ISAAC+ - which no one seems to have discussed at all. A website for ISAAC says it's never been cracked, but given the lack of online discussion about it, maybe only two persons ever tried.

Are there valid reasons for the warm fuzzy descriptions of ISAAC? If it's great and unbroken after all this time, why isn't it a mainstay?

I decided not to use ChaCha for my purposes - /dev/random might already use it and I didn't want accidental correlation.

You might want to rethink that. Firstly, /dev/random is not the one using ChaCha20, /dev/urandom is. Secondly, there is no "accidental correlation" to worry about. You can safely use ChaCha20 multiple times and it will remain secure as long as the key:nonce tuples are all unique.

  Wherever I see it mentioned, I see it referred to as strong enough for crypto work. But I haven't seen who decided that, and looking at the implementation in C, it looks for all the world like someone picked arbitrary constants for shift operations and fiddled with add operations until they got something that had good statistical properties

ISAAC is considered secure simply because no one has broken it yet, and because analysis appears to indicate a solid and secure design. As for the rotation constants seeming arbitrary, you're right, they often are! That is often how people choose such constants. They try different values and see which ones have ideal diffusion characteristics. I'm not aware of any heuristics for choosing specific rotation constants for an arbitrary cipher. Even ChaCha20 and Salsa20 use constants that were chosen (in part) this way.

  The one paper I found that does any analysis promptly diagnoses a bunch of weak keys and proposes ISAAC+ - which no one seems to have discussed at all. A website for ISAAC says it's never been cracked, but given the lack of online discussion about it, maybe only two persons ever tried.

It's not weak keys that were found, but weak states, which are far more hypothetical and harder to generate. ISAAC+ is likely less researched because it is not an entirely new design, but a small tweak on the original design. Such tweaks do not always warrant a significant amount of new analysis.

  If it's great and unbroken after all this time, why isn't it a mainstay?

Simple: There are better, faster alternatives like ChaCha20. While it is true that there are no known practical attacks against ISAAC, it's really not that brilliant a design to warrant significant attention. It got some rudimentary cryptanalysis and cryptographers in general feel it is secure, but there is no compelling reason for it to be used, resulting in less attention from the cryptographic community.


How do compilers detect buffer overflow? I just started researching about security at the systems level and challenges, especially with respect to low level languages such as C/C++ and Objective-C. I have understood buffer overflow and how it works. I was playing around with it on OS X and Ubuntu. Of course these systems have ASLR and stack guards implemented, which we can disable at compile time. So I have couple of questions with respect to this:

How does a compiler detect an overflow at compile time? I understand that while compiling it will add a canary and if any instruction tries to overwrite this, it will throw an error. But what is the exact algorithm? If someone can point the gcc code functions for this, that would be great.
Is disabling the stack guard and making stack/heap executable on Ubuntu sufficient? Or can ASLR still make it difficult to exploit?
If I have a binary (no source code) and I know it crashes due to buffer overflow, how do I detect it?

Buffer overflows aren't detected at compile time.  There are code analysis tools such as Sparse or Lint (cpplint, pc-lint) that will perform further analysis on both source code files or compiled binaries.  Each analysis tool has their own algorithms for determining a buffer overflow, but it comes down to common known instructions that lead to buffer overflows.

You can also add Bounds Checking at compile which inserts bounds information for each allocated block of memory.  This bounds information is then checked at run-time to ensure buffers are within their limits.  A common implementation is to use "fat" pointers.  Which contain both the address of the real pointer to the data, and additional data describing the region it is located.  I believe Firefox does this for their memory allocations, but I could be mistaken.

Canaries are inserted at compile time to help detect buffer overflows by inserting a word of data between a buffer and the control data on the stack.  At a certain point before the return of the function the canary is verified to be intact.

ASLR has nothing to do with stack protection.  It randomizes the address that your program runs in memory.  This means that you can't rely on functions to be at the same address each time the program is run.  This prevents the hardcoding of library and function addresses.  Making the stack or heap (or any piece of memory that you're trying to execute) executable is necessary regardless, but ASLR will still cause you problems.  If you're just experimenting and trying to understand exploit code I would do the following:

Disable ASLR
Disable stack protections
Attack each problem individually, and re-enable them one at time until your exploit can handle both.

If you have a binary that crashes due to... well anything (not just a buffer overflow) run the program in a debugger.  The debugger will catch the crash at the exact point that the program fails.  You should probably realize that this might not be the exact location of the overflow, but a stack trace should help determine the root cause.  I would suggest reading these posts if you're not familiar with reverse engineering tools, or x86 computer architecture.

Why are buffer overflows executed in the direction they are?
Reverse Engineering Tools


Will using unicode chars in my password increase security? Possible Duplicate:
  Do non-keyboard characters make my password less susceptible to brute forcing?

Bruteforce tries cracking the hash with every possible combination of letters.

Then, If I'll use an special Unicode char, as ♥ or ¿, will it increase my security?

I'm talking about NTLM passwords.

Yes,

In the sense you are increasing the entropy of your password, making it harder to perform bruteforce attacks against.

I am from a country where we use non-english letters. This allowed me to use characters not common used in a charset by a brute-force applications, but I effectivly locked myself out of my webmail when I used a computer without my regional keyboard settings.

Edit:

Googling NTLM + unicode shows that there is support for unicode as NTLM password.


Requiring regular password change but storing previous passwords? My bank requires me to change my password regularly but then they can detect if my password was used before. They probably store the old password (possibly hashed) in order to detect it. I think this defeats the purpose of password change since old passwords are still stored.

Is storing old passwords even if hashed for the purpose of forcing new passwords generally okay? Or it defeats the purpose?

The bank keeps your previous passwords (or hashes thereof) to force you to change your password, but it does not mean that they would accept an old password as valid authentication. The important point is: the bank wants to protect access, but it has no interest in protecting your older passwords per se. For the bank, the old password is no longer sensitive data, since it does not grant access to the bank.

Well, actually, old passwords are somewhat sensitive because users are users, and thus they:

reuse passwords for other sites;
"generate" successive passwords with "witty" procedures, as opposed to what they should do, i.e. random procedures. If an attacker learns that your two previous passwords are "sleepy" and "sneezy", he may try "grumpy" and "happy" as potential passwords).

So a bank which keeps traces of old passwords around should protect them adequately, i.e. as if they were still active passwords (hence store only hashes, with a slow hash and a lot of salt). But that's indirect. By itself, learning an old password does not give any special power to the attacker, at least from the point of view of the bank.

Forcing password changes on users is, at best, a procedure of dubious value. It may enhance security only if we assume that the previous password was indeed stolen at some point. In other words, it has security benefits only if a constant, non-null amount of fraudulent accesses is occurring and the server has learned to tolerate it, and just wants to keep it low. This is not very reassuring, for a bank. In all other cases, forcing a password update just antagonizes users, and that's never a good thing. See this previous question for more opinions on the subject.

Most places where passwords must be changed regularly do so mostly because it is technically possible, and out of respect for a fuzzy tradition which is never uttered with clarity. At my work place, passwords must be changed every 42 days, must be distinct from the last 24 passwords, and, last but not least, when I change my password I am not allowed to change it again for the next three days (I have never understood what reasoning may have gone through the mind of the people who established such a rule; I find no benefit for it in any situation, even far-fetched; it is just irksome, and I must assume it was meant to keep me angry).

But, if the bank nevertheless wishes to force password updates, then keeping around old password hashes makes sense: it does not weaken the security of the bank's site and it is the only way to enforce a policy of distinct passwords.


Burpsuite 1.5 initiating TLS Connection on their IP to Port 443. What is it? I recently started using a security tool (Burpsuite 1.5) which has a free licence and a professional one. Upon downloading the free one from its vendor web-site (I am using BackTrack), I noticed within my Wireshark that every time I launch the tool, a TLS connection is made to the vendor’s IP on their port 443. This connection stays open and exchanging information for as long as the tool is kept open. Because I do not know what is being transmitted I blocked the outgoing traffic on my firewall to this IP: this did not impact on its usability. It might be paranoia, ignorance or both, but I don’t think I want this to be happening.

I have spent a couple of hours’ worth of research to see if the vendors would say anything about, which led me nowhere: perhaps I have not searched correctly, but I am intrigued by this from a learning point of view (and from a security perspective too, but to a lesser degree in this case).
I have not directly contacted the vendor yet, mainly because I want to learn about it first, so my apologies if this is out of scope in here. However, a question if I may:

Is there a way of finding out what this is being sent?

Is there a more elegant way of stopping this from happening other than blocking the connection on  my Firewall?

One thing you could look at is setting an upstream proxy in burp (either another instance of burp or a similar tool) and see if the traffic is then sent via that proxy.  It may hit a problem with SSL certificate validity on the other hand might work.  Assuming that it works, it would let you see within the SSL stream (although there could be further encryption of course).

To block the communication you could add an entry to your hosts file for the DNS name that it's contacting and redirect it to 127.0.0.1 as one option.  You could also block it on your hosts firewall or if you're running it via a chained proxy as I mentioned above, you could likely block the traffic there too (depending on which tool you use.)

Another thing I'd recommend is asking in the the PortSwigger Forums, they're usually reasonably responsive, so you could well get an answer there.


What types of background checks of employees are state-of-the-art? A high security environment requires trust in the integrity of the employees. I am talking about administrators, developers and everyone else who could compromise the security easily. One way to reduce the risk is the application of the four-eyes principle, centralized logging and other ways of surveillance.

In addition to that I noticed the trend that new employees have to undergo background checks before they are allowed to work on high security projects. I wonder what can be considered state-of-the-art concerning the screening of employees. Where are the legal boundaries and what is usually excepted by new employees?

I don't know about state of the art, but for high sensitivity positions in financial services in the UK you would expect the following to be checked:

criminal record
credit
terrorist connections
residency/right to work

In some countries this list is reduced, eg in Switzerland you won't get a credit check


Using a standard account is safer? I just read this article about making a computer safer: Komando.

They recommend using a standard user account for daily use, and using a separate admin account for making changes. I do this at work so that if someone sees my password, they won't be able to make serious changes to my system.

On my Windows 10 laptop at home, I use the admin account for daily use. I never install anything, except the Chrome browser. I literally never install anything because I am paranoid. I don't even have flash and I disabled the browser extensions/plugins. In this situation, how would using a separate standard account make it safer?

To put it another way, if you were attacking a system like my home laptop, would it slow you down at all if they were using a standard account?

Yes, it's safer

If you mean safe in the general case ("can they introduce a boot time backdoor or format my hard drive"), then yes, using a standard account is much safer.

With an administrator account, you might not install software, but as soon as some attacker manages to use a Chrome weakness to run some arbitrary software on your PC, you're done for.

It does not matter how safe Chrome is. There have been attack vectors like images libraries - they could get in (and did so, in the past) simply by placing a prepared GIF/PNG on some harmless website. They could exploit some fancy Chrome bug and install some plugin which you notice only when it's too late.

No, it's not safer

If you mean "safe" as in specifically "can they get my data, impersonate me or empty my bank account, make me take part in DDOS attacks" and so on, then no. If you are the only user of the machine anyways, and do everything from your one unprivileged account, then they can pretty much do to you whatever they could if you had admin access. They just can't harm the system itself or other users on that machine (in this scenario, there are none).

It will still make it a little harder (they will have a hard time overriding security prompts by whatever software you are using, and so on), but generally possible.

So...

The benefit of using a standard account is that you do other stuff in other accounts. I.e., if you do general web browsing, you do that on another account than your online banking (depending on your level of paranoia). If you have wife and kids, they use different standard accounts. If you have an antivirus or a local firewall, you configure them from the admin account and not your personal one. And so on.


Server encryption, client decryption, without the client having the ability to encrypt? Is it possible to encrypt data server side and then decrypt it client side; without the client having the ability to encrypt the data themselves after decrypting?

I'm working on a license manager which needs to be able to read the contents of the encrypted file, but ideally we don't want the client to have the ability to create their own encrypted license file.

You are probably mistaking encrypting for signing!
Being able to decrypt something does not imply that the encrypted data comes from a trusted source, which is what you likely want from a licensing software.
Rather, what you should do is to sign the license key, and allow the client to verify the license. This can be done using public-key cryptography. Your server would contain the private key, with the ability to sign data, and your clients would contain the public key, with the ability to verify a signature.
However...
... it should be noted that what you are trying to do is a DRM scheme, and theses schemes are impossible to do with any reasonable guarantee of security, at least if all the "interesting" bits happening on the client.
Your program, in essence, looks like this:
if(license.IsValid())
{
    startTheCoolStuff();
}
else
{
    showLicenseError();
}

You can make this more complicated and throw some obfuscation at it, but it won't change the fundamental nature of the approach. And an attacker, eager to circumvent your licensing, will find a way to execute startTheCoolStuff() without a valid license.


Should I use my trusted VPN for all my traffic? I use my trusted VPN primarily for the sake of anonymity (to avoid data being collected about my Internet browsing), although I am aware of its security benefit -- traffic encryption. My question, however, stems from an unsubstantiated fear I have of using the VPN when accessing sensitive sites (banking, primary email, billing, PayPal, etc.). When accessing sensitive sites I am not seeking anonymity, in fact, quite the opposite; unavoidably such access requires the exposure of personal information (hopefully under the sound encryption that these sites themselves provide).

Several questions related to my title or umbrella question:

Is it advisable to still use a trusted VPN when accessing sensitive sites?
Does using a VPN in such circumstances jeopardize the sensitive information I'm accessing?
Regardless of whether using a trusted VPN inconsequentially effects such access and surveying, do you yourself switch off your own trusted VPN when accessing sensitive sites?

(I am aware of my persistent use of the phrase "trusted VPN". It does seem quite silly and was likely unnecessary. Also, feel free to critique my understanding of "trusted VPNs", the benefits they provide, and so on. I can only begin to conceptualize how a VPN works, although I do know conflicting views exist on the security and general benefit they provide. I use several other mechanisms to enhance my anonymity and my security, none of which include TOR, as I am under the impression it requires legitimate knowledge of CompSci, a "domain" which is widely foreign to me.)

What is your threat model ? Why do you want to use the VPN ?

You seem to think that a VPN is the silver bullet for privacy (thanks to all these ads to fool naive users, even though these VPN providers will probably be the first ones to hand over your data in case of a government/attorney request).

Sorry to disappoint you, it is not. All the VPN does is create an encrypted tunnel between your computer and the VPN server, and all your traffic appears to come from that server to the eyes of websites. That's it.

Why do you think Google or evil advertising companies will have trouble tracking you ? They couldn't care less as to where your IP is your real IP or the VPN server's one. They use cookies to track you. If you want privacy, install a good ad blocker, block all the advertising/analytics crap and you'll regain some privacy.

The only benefit of a VPN is either when you need to connect to your workplace's network remotely (and appear as if you were on their network), or use unencrypted protocols (HTTP, IMAP, SMTP, FTP, etc) over untrusted networks (public unencrypted and often overpriced Wi-Fi garbage, rogue ISP that spies on your unencrypted traffic or alters it, etc).

To actually answer your question, any serious bank uses HTTPS, which is safe to use even on untrusted networks. The VPN won't add any security (but may trigger some alarms on the bank's side because your IP suddenly changed) because it's already secure.


PCI-DSS Is the infrastructure really in-scope? Say I have an application that takes credit cards, but this is actually a payment gateway on the internet that I don't control.

The web site used HTTPS and only returns if the card was authorized or not and stores the last 4 digits of the PAN.

With this setup, how much, if any, of the infrastructure is really in-scope?

PCI-DSS only applies to computers and systems that handle PCI (Payment Card Industry) information.  If it is handled by a third party and you are only given a receipt token, then no PCI data is being handled by your system and it doesn't fall under PCI-DSS.


How applications are installed in TEE and REE I am trying to understand the difference between the TEE (Trusted Execution Environment) and REE (Rich Execution Environment) in an electronic component. I understand that for security reasons, there is a TEE environment. I want to understand how one can manage to install an application (a Trusted Application) in TEE and a normal application in REE. That is, how do we instruct the application to install in a specific environment.

I am newbie to security in electronic components. I will be really happy if I can get an answer.

The installation of TEE application purely depends on the TEE that you choose. There are so many TEE vendors in the market. General methods of TEE application installation are

Build the TEE application statically in the TEE itself.
Install the TEE application from the REE file system. There are commands available to install these applications to secure memory from TEE


Is it possible to enroll on behalf if only public key of client is known? I have the following scenario: I have a lot of embedded devices that should talk to another. To enable trust between these devices I would like to use certificates. The devices generate a keypair and send the public key to a central instance that should act as enrollment agent, request the corresponding certificate for the public key from the CA and send it back to the client.

To my limited understanding it should be possible to request a certificate for another user/machine if

a) I'm in possession of an enrollment agent certificate, with which I sign the request

b) I have the public key that should be certified by the CA.

Unfortunately everything I found during my research the last days this does not seem to be possible. Can somebody with a deeper understanding than me please shed some light on this?

EDIT

To make it clearer what I want to achieve and still not know if it's possible, here are the steps:

The device creates a keypair
The device sends the public key of this pair to a machine that acts as an enrollment agent (protected by OTP)
The machine, that acts as enrollment agent, creates a csr for the
device containing the public key and signs it with the enrollment
agent certificate.
The machine sends the csr to the RA and delivers the resulting certificate to the device.

I hope this clears things up a bit.

The first thing I researched was the automation of the process by using certreq, especially certreq -new. I can see no option to provide the public key of the device to the request.

Then I looked at the example at Creating an Enrollment Agent Signed CMC Request (Single Signer), but I can't see where the public key of the device makes its way into the request.

As I am more familiar with the Java language I also looked in some examples utilizing the bouncycastle API. All of them used the private key corresponding to the public key of the device to sign the request, not the enrollment agent certificate.

I know that the above is a common usecase for smartcards, but I can't find how it is done.

Ok, after some struggling I found that this is possible using CMP. Unfortunately the Microsoft CA I used in the beginning seems to ignore some standards so I didn't get it to work.

Using EJBCA did the trick. I was able to do exactly what I want following the code snippets in the documentation. Just setting the ProofOfPossession-flag to RAVerified helped to achieve the desired behaviour.
Here's a codesnippet using the bouncycastle-library:

    CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(certReqId);
    X500Name issuerDN = new X500Name(issuerDNString);
    X500Name subjectDN = new X500Name(subjectDNString);
    msgbuilder.setIssuer(issuerDN);
    msgbuilder.setSubject(subjectDN);
    final byte[] bytes = keyPair.getPublic().getEncoded();
    System.out.println(Base64.getEncoder().encodeToString(bytes));
    final ByteArrayInputStream bIn = new ByteArrayInputStream(bytes);
    final ASN1InputStream dIn = new ASN1InputStream(bIn);
    final SubjectPublicKeyInfo keyInfo = SubjectPublicKeyInfo.getInstance((ASN1Sequence) dIn.readObject());
    dIn.close();
    msgbuilder.setPublicKey(keyInfo);
    GeneralName sender = new GeneralName(subjectDN);
    msgbuilder.setAuthInfoSender(sender);
    // RAVerified POP
    msgbuilder.setProofOfPossessionRaVerified();


Why are ransom attacks successful? I just read that "ransom" attacks are on the rise - where the attacker uses a vulnerability to enable them to encrypt files and demand money for the key.

Why is this any different to a disk failure, where the solution is "get the backup"?

Most people don't have backups.  Most people who do have backups, haven't tested them to make sure they work.

The real difference between disk failure and ransomware is that paying the ransom is cheaper than paying a data-recovery company, and is more likely to get your data back.


SSD (Flash Memory) security when data is encrypted in place I'm surveying current techniques on flash memory security. I've learned that the non-in-place update of flash memories prevent us from adapting the same encryption techniques that we used on hard disks — see Do Flash memory (SSD) architecture impacts encryption techniques? —
 and I was wondering what kind of mechanism is being used to address that.

To put my question in a clear form, let say data "a" is stored in address "x", but after encryption the data "a" can't be stored in the same address "x" (because there is no in-place update in flash memories). So what we do is encrypt the data, say " a' ", and store it in another address " x' ". Since the unencrypted data "a" is still available, we have to delete it (note that in SSDs we can only erase a whole block at a time), which results in erasing and displacing all the data found in the same block as "a". The problem is, this will cause a lots of erase operations, and if it continues this way the memory will wear off after a limited number of erasures.

I would like to know if there are any solutions for this problem.

I think this question is asking a bit more about what happens when you encrypt data on a device where that data was previously unencrypted. SSD units and HDD units suffer from different possible compromises related this. This is basically referred to (at least on the venerable Wikipedia) as data remanence. That article offers lots of information about the various ways that data can remain or be leaked on hard drives.

Where the SSD presents a special problem, it also presents a new resolution: the "Secure Erase" command to compensate, just as TRIM helped compensate with deletions.

If your security concerns are sufficiently high that you're worried about the block level activity of unencrypted data, though, I suggest the following: consider any drive that has ever held sensitive data in an unencrypted state to be tainted. Use partition or device-level whole disk encryption.

This applies to HDD systems as well as SSD systems. The particular case would be an over-written file. Advanced recovery techniques have been theorized to read overwritten data (hence secure wipe pattern algorithms: DoD 5220.22-M), though that may be an artifact of lower density drives (http://computer-forensics.sans.org/blog/2009/01/28/spin-stand-microscopy-of-hard-disk-data/ and http://www.securityfocus.com/brief/888). Never the less, advanced filesystems might process an overwrite to another location, or capture snapshots of data when unencrypted.


Security threats of wireless charging? It is well known that plugging your mobile device for charging in public/uncontrolled places through Micro-USB can be a security hazard. USB protocol supports much more than just transferring power, leaving the device exposed to all sorts of malicious data transfer.

So although I wouldn't plug my phone to any untrusted wired charger, I wonder whether wireless charging technologies - like Qi - pose a security threat, for example by permitting any sort of backdoor/exploited access to the device itself?

I encounter public wireless charging pads with increased frequency (e.g. in cafes), and they seem to be extremely convenient way of keeping your phone up (Nexus 4 in my case) almost seamlessly. Thus I'm quite interested whether it is possible to take advantage of this nice new technology without worrying about security threats.

Older chargers used to just be a simple power supply - little more than a diode bridge, a capacitor and a voltage regulator IC. They supplied a steady voltage to the phone, often +5V. When USB connectivity arrived with modern phones, +5V became a standard and the supply pins on the USB header were used for charging just the same. The two data pins would be left floating or tied to ground, and would not be used.

These days things have changed. Modern phones are power-hungry smart devices, with large batteries. The old USB standards heavily limit the amount of current that can be supplied to a device. On a USB 1.1 port, you could draw up to 100mA of current on the +5V line. This equates to 0.5W, which certainly isn't much when charging. USB 2.0 increased this to 500mA, and USB 3.0 increased it further to 900mA. However, the actual allowed power consumption is not as simple: when just plugged in the maximum a device is allowed to withdraw is only 100mA / 150mA for USB 2.0 / 3.0 respectively. The device must designate itself to a particular type, as must the dock to which it is plugged into. This is called a negotiation.

There are three main types of power state for USB:

No Dead Battery (NDB) mode - allows 100mA (150mA on USB3) to be drawn when plugged into a device without any negotiation. No data may be transferred.
Host charger mode - allows 100mA on USB 1.1, 500mA on USB 2.0 and 900mA on USB 3.0 after the device has been registered with the host, and full duplex communications can occur. This is the "normal" mode most devices will be in when plugged into a computer.
Dedicated charger mode - only defined for USB 2.0 and 3.0, and allows 1.5A on a dedicated charger device. Whilst in this mode, no data may be transferred. However, the device must negotiate this mode with the charger.

Notice that only 150mA may be drawn by the device when no negotiation has occurred. This is a safety feature, as over-current protection on a device may involve surface-mount fuses that require de-soldering to replace. As such, if a device tried to pull 1.5A on a USB 1.1 host that only supports 100mA, you'd likely melt the host. As such, we have to do proper negotiation, which involves some data transfer.

Here's where things get fuzzy:

The negotiation phase may be implemented in hardware, firmware or software. Usually the first step is hardware, then the next step is firmware, and the final step (OS recognition via PnP) is software.
The data involved in the initial negotiation handshake doesn't (as far as I'm aware) involve any arbitrary length buffers. It's this stage that involves the power negotiation.
The data involved in the full Plug-n-Play negotiation is complicated and most certainly does involve arbitrary length buffers.

As such, modern dedicated chargers usually have a small microcontroller or dedicated USB host chip to deal with the negotiation phase. This means there is usually a firmware-based attack surface on the charger, and most definitely on the device. However, some specialised chargers (e.g. iPhone) cheat the specification by using detection tricks (e.g. capacitative sensing on the data lines) to make the charger production cheaper, and therefore don't need to do any data transfer. This may or may not be a violation of the USB specification, but big companies tend to be able to get stuff like that past regulatory bodies.

The wireless charging side works almost the same way, except the actual transfer of current is done via an oscillating electromagnetic field. The negotiation works in the same way, just over an NFC-style communications channel. If you could inject data into that communications channel, you might alter the way the negotiation works, but I doubt you could do anything interesting without violating the protocol. An interesting avenue of research would be to see if any devices have buffer overflows or similar issues in the protocol.

So, in conclusion, you may be able to find an exploit for a device, but it's likely to do nothing more than temporarily brick the USB controller IC on the device. Alternatively, you could replace the charger with an active host, and use it to fully negotiate with the device and send commands to it. This is especially dangerous on iPhone and Android devices that have USB debugging enabled, as it allows the device's memory to be accessed.


Can any information leak by sending auto-generated 'Unsubscribe me' email? I have been receiving spams from one source for a few months. I believe it has a lot of channels - I see the from address like CREDIT CARDS<abc@somespam.com>, HOLIDAYS<abc@somespam.com>, etc.
I decided to unsubscribe and on clicking the unsubscribe button in the mail, a new Compose Mail window was opened and it had the following details populated.

Recipient e-mail id
Subject
Text

The recipient email id was a different one. It was xyz@someotherspam.com rather than abc@somespam.com (from which I received the email). And the subject had some auto-generated token comprising of chars, numbers and symbols.

And on looking at this question all I could see is, the spammer can mark our account as active.
However, I would like to know a few questions regarding information security here.

Is it possible to retrieve any information from my inbox / sent items using some scripts if I send the unsubscribe mail? If yes, how do we find if any information has been stolen?
Since my connection with the server is open, is it possible to contact the mail server by impersonating as me?
If all it does is mark my email as active, what are the consequences of that?

Is it possible to retrieve any information from my inbox / sent items using some scripts if I send the unsubscribe mail? If yes, how do we find if any information has been stolen?

People on this forum are generally going to acknowledge that "everything is possible." Instead, we concentrate on what's likely, probable, and worth defending against.

Applications like Outlook and Thunderbird read the link as a URL, and those URLs are linked to applications. mailto: will be opened by the default mail client, http / https will be opened by the browser. These URLs are then parsed, and action is taken on them.

It's the parsing that gets us in trouble. When input is parsed by the application (or the OS), it could be parsed in a manner that exploits some flaw and precipitates a bad result. One example: earlier this year, a flaw was discovered where a link click can crash your system.

So, links can be dangerous. Fortunately, there is a relatively safe way to deal with them: mouse over. When you mouse-over a link, it should display the destination. If it's an http or https or mailto link, then you should be relatively safe (until you're not). If you see a UNC link "\something" in an email, then that's definately not something you'd want to click on. Even an http(s) or mailto link might be suspect depending on the destination.

So the ultimate conclusion is: if you are running an unpatched, not up-to-date operating system and software, then the odds you'll be hit with something nasty from a link (or other sources) is much higher. (Using AV for protection is out of scope for this question, and generally triggers a Holy War. If you have additional questions on that, I'd post it on SuperUser.com).

  Since my connection with the server is open, is it possible to contact the mail server by impersonating as me?

Assuming that you have a vulnerability as discussed above, anything is possible. So, yes.

  If all it does is mark my email as active, what are the consequences of that?

I've dealt with spam extensively. Both in MS Exchange filtering, to Postfix, SpamAssassin and writing milters to filter spam. There are three things that a spammer cares about that will make your address a "value add:"

That the email can be delivered. Deliverability is what these low-life's are selling when they sell your email.
Open rates - that you opened the email marks it active. They do this with email tracking pixels.
Some sort of activity (a click, a purchase, a phish, etc...).

So, your email gets marked as one or more of these - if you're dealing with a sophisticated spammer. However, most spammers are not even sophisticated enough to send RFC compliant email, their database handling skills are basically non-existent.

Chances are: you're already marked as one of the three classifications above. If your email has been breached, bad guys cross reference different breach lists. If the email appears on more than one, (and chances are, that's true too... thanks Yahoo, DropBox, Google, etc...) then you're on a separate, more valuable list.

So what to do?

You have to assume that if you receive an email, you're "active." If you open it to see what it is, you have already been marked as "active+open." So, there's no point in worrying what metadata some bad actor is is collecting on you. Your primary concern is (should be) protecting yourself.

Simple steps to do this:

Just delete obvious spam emails. The unsub links won't work 90% of the time, and when they do work, you've raised your hand as active. (That seems to be worthless to them these days since data breach data is so much more reliable... but why not avoid it?).
In the last year, at one of my sites, I monitored and did frequency analysis on just over 500,000,000 inbound emails over a period of six months. The only factor that increased the frequency of email to a given address was its age. The owner of the company had a 20+ year old email address, and he got the most. The next most senior employee had the next greatest spam level. And so on...
If the mouse-over reveals an https link, manually navigate to the site (in a sandbox) using copy paste, and go to the root of the site to see if it's legit. If so, then unsubs are probably honored.
If it's from a big company, unsubs must behonored (at least in the US). It's probably fine to unsubscribe.

Important

Read the URL carefully and always check the SSL certificate issuer for https links in the emails. Ransomware emails are crafted amazingly well in comparison to the rest of them. I have seen a few come through that were beautiful reproductions of UPS, FedEx, USPS, the IRS, and a few other major orgnization emails. I've seen some that came through that had working websites behind them claiming to be a city municipality complete with contact address, correct phone numbers, Google Maps addins, and what must have been a $3,000 website complete with SSL (signed by a Chinese CA. Pretty sure US municipailties won't be using a Chinese CA). These are sent as RFC compliant, DKIM signed, SPF compliant emails from non-day-old-bread domains in low volumes to keep from getting blacklisted. Spamassassin routinely classifies them as < 2. They either use a compliment domain ("irscompliance.us" instead of the legit irs.gov) or a duplicate letter (like Gooogle vs Google). These are pretty rare, but they are exquisitely crafted. It's almost as if all the spammers who were good at their job have switched to the ransomware industry.


How can an un-trusted device connected to the LAN network infect others operating systems? I have a various devices on my LAN network (Linux, Windows, Android device..), sometimes i allow others to connect to my LAN through , it is not possible to verify the safety of their machines, Let's say i have allowed an in-trusted machine to connect trough my router. How can the infected device harm others machines?

there are lots of attack vectors, such as :

Sniffing admin/user passwords and exploiting systems using them
Accessing an anonymous shares and planting malware there(if they're not read-only)
Performing MitM attacks to steal data
Exploiting IPv6 in LAN : it's often an IPv4 LAN's but people forget to disable IPv6, so it's a prioritized by OS, especially Windows, and sending a router announcement makes you a LAN owner(I performed it myself, it works)
Stealing Kerberos tickes

... and too many other ways to mention them all


What is the risk of allowing users to change Windows 10 wallpaper? In the past I know there where ActiveX that could be installed as wallpaper and I see that this may be a risk.

Is there any risk allowing this on Windows 10?
Is there any kind of wallpaper that may damage user data or the system?
Is there a security reason to block changing Windows 10 wallpaper using a GPO?

Purely from a risk perspective:

The risk posed by an image file containing a payload of malicious code is not changed by the fact that you allow users to change their desktop wallpaper.

I mean, if it's got a nasty bit of code in it, then opening the file in paint or even generating the thumbnail view in explorer would execute the code too.

At worst you may be increasing the likelihood, because your users might be allowed to grab wallpapers from the web and use them.


Can we use CORS policy to restrict API calls from native mobile app? We can use CORS to restrict API calls to a specific host in a web app. How to do the same for native mobile app?
I want to restrict API calls from my app alone.
Is it possible to do so?

CORS doesn't prevent anything, and it doesn't protect the server. It simply tells a conforming client (a browser) what is permitted for the protection of the browser's user; CORS is a way to carefully make holes in the browser's Same-Origin Policy. Additionally, CORS headers are advisory, in that they don't actually prevent anything from happening. They make it so that a malicious attacker can't fool an innocent victim's browser into making making certain requests (or, more often, using the responses to such requests) that the user wouldn't want the browser to make. A browser's user could, if it was wanted, open up the browser's dev console and make the request anyhow. Similarly, the user could export the request (cookies and all) to curl and - potentially after making more changes - send it from there.
Any non-conforming client (such as in a mobile app, or just a shell script invoking curl), can and usually will completely ignore CORS. Such clients don't have a Same-Origin Policy to begin with, so there's nothing for CORS to make holes in and therefore it does nothing.


Keyboard vs clipboard password manager threat models A password manager (like KeePass) offers you the option to copy and paste your password (the clipboard is cleared after pasting/timeout) or to emulate a keyboard and "type" the password for the user.

What are the cases where one method is better than the other? Are there any example threat models where using one of those methods should be preferred?

Without a defining a threat model, it's hard to compare effectiveness.  Clearly, both fail in the face of malware running on the local computer.  (Either keyboard events or the clipboard can be read from malware.)

With Flash, it's possible to read the contents of the clipboard, so there's a small opportunity there where passwords might be leaked.  (Though JavaScript has access to the clipboard, it can't read the contents without the user selecting paste.)

At the end of the day, neither approach is likely to be the make-or-break factors in the security of a password manager.


School Wifi Certificate My school is requiring that I download a wifi certificate to use the school wifi on my phone but i was wondering what downloading the certificate entails since it doesn't really tell you if I download this can they see what I do on my phone at home or just on the wifi

There are two likely types of certificates they may be asking you to install:

One that authenticates your phone to their WiFi
One that is a trusted root CA which can issue a certificate for any site

The former is more security in that individual users of WiFi can be identified, and linked to the network traffic they create. The latter is the one that permits them to observe the content of your traffic.

Your first task would be to discern whether you are being given an authentication certificate for network layer connectivity or a "trusted root" key owned by the organization for issuing SSL certificates for any site.


How do vulnerability reports work? I'm really interested in IT security and I would like to know how vulnerability reports work.

Is there a central database for those things? I often see CVE-XXX-XXX on disclosures, but I don't understand very well how the numbering works and which database keeps the information about that report.

What should one do to publish a new vulnerability report on the internet?

There are several organisations that maintain vulnerability databases.  NIST's NVD is probably the most notable IMO

http://nvd.nist.gov/

CVEs are software flaws - Common Vulnerability Enumeration, but there are also other prefixes used, like CCE for Common Configuration Enumerations - which are misconfiguration based issues like easily guessed default passwords, and ports exposed by default etc.


Why shouldn't I sign my email newsletter using an s/mime email certificate? I currently offer email subscriptions on my blog, something I coded myself in PHP.

People sign up on the blog using their email address. I send them an email with a link to verify their email address and once verified, they get an email whenever a new post is published. I only publish about 4 or 5 posts in a month and every email sent has an unsubscribe link which unsubscribes them right away if they wish. I hate spam so I definitely don't want to send anyone email that they don't want. I'm constantly checking to see if any of the emails bounce (nothing does) and would remove them from the list right away if there was ever a problem. I'm presently not having any problem with the emails being delivered and as far as I know, they're not ending up in people's spam/junk folders. I've set up my VPS box with SPF and DKIM, SSL only, etc… I currently have just under 200 email subscribers.

I'm wondering, is there any reason not to sign these subscription emails with an s/mime certificate? Would it improve deliverability? Or just give people the peace of mind of knowing that the email did in fact come from me?

Also, what about for email receipts? I'm presently working on updating another site, which will have an e-commerce component to it (via Stripe), so I'll be sending a lot of email receipts (I hope!), and also an email newsletter through that site also.

I know that s/mime is not that popular/wide-spread, so would sending these emails signed be a bad idea? (Not encrypted, just signed.) I don't see anyone else doing this, so I'm wondering if it's a bad idea? (Or why isn't anyone else doing it?)

Signing emails is useful only insofar as recipients verify the signature. Theoretically, signing the emails might improve deliverability, but only if a recipient configures his filters for incoming emails to verify email signatures and accept emails which have been verified to come from you. However, this is only theoretical; in practice, email filtering is not under control of the end user, but done in the email server, and no server verifies S/MIME signatures. In fact, there are some (poorly configured) antispam system who will react negatively to signature (because they don't understand them), so signing emails is probably a bad idea in your case.

Said otherwise: if signing emails improved deliverability, then spammers would do it.

Another general comment is that you should not want to sign. When you sign something, you are actually building a legal weapon aimed against you: a signature can only serve one purpose, which is to rub your data in your own face. If you think clearly about signatures, then you should actively avoid signing anything; what you want is that other people sign what they send to you.


How can I read snort logs in NIDS mode? I am reading some snort logs from a firewall, I could read some with "snort -r file"
But when I had tried the newest logs I get this error:

snort -r snort.log
Running in packet dump mode
   --== Initializing Snort ==--

Initializing Output Plugins!
pcap DAQ configured to read-file.
ERROR: Can't initialize DAQ pcap (-1) - unknown file format
Fatal Error, Quitting..

Probably the snort is running in NIDS mode, I don't know, I have barnyard into this system if help.
Is there any material to help me understand and troubleshoot this problem?
Thank you!

I figured out that problem is about the format of snort output, the logs that I could read is alert logging, the logs that I can't read area unified2.

  Unified2 can work in one of three modes, packet logging, alert logging, or true unified logging. Packet logging includes a capture of the entire packet and is specified with log_unified2. Likewise, alert logging will only log events and is specified with alert unified2. To include both logging styles in a single, unified file, simply specify unified2.

https://www.snort.org/faq/readme-unified2

Thx


How does this HTML5-based "Mass Router Infection" scheme work? I read this article stating that purely through a website, "without any user interaction" mass router infection is (/was?) possible. I'm not sure that this problem still exists as it was posted 3 years ago, but I'm still curious.

The article states:

  How could an attacker "own" a router? First, the victim would have to be lured into visiting a malicious website, which would then push JavaScript with instructions to the browser to tell it about all locally connected devices. Second, after learning about the network and finding a device to target, the malicious website would need to launch a brute-force attack and divine login credentials for the device. Then, after gaining access to the device, the website could then send malicious firmware, instructing the browser to install it on the targeted device.

I get the part about HTML5 releasing IP addresses that allow a hacker to see devices on the network, but from there I dont understand how the hacker goes about breaking into and controlling the devices remotely.

I didn't realize that I could control even my own computer purely via my home network, without leveraging an application like TeamViewer or LogMeIn. How would the hacker make attempts at entering my password purely by knowing my IP address?

Can someone please explain the way this would work more clearly than the article?

These types of attack could be achieved via multiple CSRF attacks against the IP addresses discovered via the JavaScript reconnaissance tool.

Say your local IP address is 192.168.1.100. You visit the malicious website, the JavaScript runs and finds the device 192.168.1.254 on your network. Now, depending on how complex the JavaScript is, it will either identify the router make and model, or will just try a brute force attack in order to exploit the router.
That is, it will send every exploit in its database at the device in order to try and compromise it.

Say that the BOB 2000 router has a vulnerability in that its URL /config/remoteConfigSettings does not implement any sort of authentication checks. As this page is only accessible from your local network, it is not normally vulnerable to internet based attacks.

However, after someone on your network has visited the malicious site, this could try every attack in its database to try and exploit the router at 192.168.1.254, including sending a POST request from the browser with the message body:

AllowInternetAccess=true&RequirePassword=false

to http://192.168.1.254/config/remoteConfigSettings.

As this page is vulnerable, the request causes the WAN side of the router to be available for remote administration and disables the password authentication. The malicious website can report that a device was found to the attacker along with the internet IP for the attacker to log into later either manually, or more likely to add to an IP list for automated exploitation now that remote access is granted. The remote exploitation could include anything from altering DNS settings to an attacker controlled server for a future MITM attack, to malicious firmware updates to the router itself.

As well as checking for known vulnerabilities, the malicious script could also try regular router requests but authenticating with default or commonly used credentials.

Update

Regarding @Ajedi32's comment about the Same Origin Policy - the scanner does not need the router to be in the same origin in order to fingerprint it. It uses a combination of IFrames and image tags to determine whether something and what was loaded and then matches these against known default IPs. From the author's site:

  The scanner accesses a IFrame to perform a generic scan of the network
  for known default router IP’s, once a connection has been made it then
  passes the IP address and performs a lookup of routers/devices based
  on that address. The reason I have decided to do this is because I
  wanted the scanner to grab as many devices as possible because it will
  be impossible to finger print everything.

  Once a IP address has been found it passes this to the finger printing
  function which uses a image object to make a connection to the device
  to see if the finger printing graphic is there.

Via DNS Rebinding

Another possibility not discussed in the linked article is a DNS Rebinding attack. Say the IFrame trick detects something is running on 192.168.1.254 once the victim has visited evil.example.com. The attacker's detection script then runs a server-side script to rebind the DNS of evil.example.com to 192.168.1.254. As the DNS entry has a very short TTL, the browser requeries the name lookup and gets the router address. As the router has default credentials setup, the malicious page can send AJAX requests to read and alter any content on the router's configuration page. This "bypasses" the same origin policy as the router now has the same origin as the malicious site (http://evil.example.com:80).

This attack would count on the browser timely rechecking DNS. Most browsers have their own DNS cache outside of the Operating System's, and may cache for longer than TTL dictates, hindering this type of attack.


Google mail - Paypal emails going directly to trash Emails coming from paypal go directly to my trash,

I noticed this today because i got a mail notification through OSx.

However when i went to find the email it wasn't there. After some digging i found it in my trash.

I logged into google and checked sessions, only mine was there.

I checked filters and forwarders and saw nothing.

Where else can i go from here to investigate, besides changing password and 2fa token?

The issue was with a mailing list unsubscription service unroll.me that i subscribed to a while back.

from their documentation:

Unroll.me unsubscribes you by following a sender's unsubscribe instructions 24 hours after you've unsubscribed.
As a backup, we automatically trash all future emails you'll receive from that sender. This is to ensure that if the unsubscribe request fails for some reason, you'll still never receive an email from that sender.

It seems the service accesses your email via IMAP using Oauth. then uses this access to scan emails and pick out the unsubscribe URLs. However it also retains access and trashes any of the emails that get through.

Seems a lot of access for what the service provides, but it was what i signed up for.


TLS: could the resumed session and the original session in the same connection? In tls 1.2, we know that every connection is associated with one session, and session resumption can be used to establish a new connection quickly by using the session ID of the original session of an old connection, what's more, the resumed session is not a new session.
   However, if it is true that there is only one session in one connection, why TLS can renegotiate within an existing connection to create new session, and can we use session resumption to refresh keys in an existing connection since the resumed session is not a new session?

There is no problem in having several sessions on a single connection -- of course not simultaneously, but if, within a connection, a new handshake is performed (a "renegotiation"), then that new handshake may resume an existing session, including the one which was active before that new handshake. As for any session resumption, this works only if both the client and server agree, and remember the session parameters in some way (if session tickets are used, the server's memory may actually be offloaded on the client).

However, this raises the question of why you would renegotiate, if that is only to keep the current session running. A common case of renegotiation is when IIS (Microsoft's Web server) is configured to use certificate-based client authentication. IIS, by default, uses client certificates on a per-directory basis, not for the whole server; thus, things go normally the following way:

The client connects to the server. A "normal" handshake is performed, with no request for a client certificate.
Once the handshake is done, the client sends the HTTP request. At that point, the server learns the exact target path for the request (up to that point, the server knew, at best, the intended server name, through the SNI extension, but not the full path).
If the target path is configured to use client certificates, then the server buffers the request, and initiates a new handshake (HelloRequest and so on).
The client responds with a ClientHello and normally tries to resume the ongoing session. However, the server refuses, and instead initiates a new session. This is so because the whole point (in that situation) of starting a new handshake is to ask for a client certificate, and this can happen only with a full handshake, i.e. with a new session.
Once the new handshake is completed and the client authenticated, the buffered request is processed (this is safe as long as client and server implement the secure renegotiation option, which was designed exactly for that usage).

The point I am making here is that the client really tries to resume the same session, as is allowed by standards, and the server rejects the resumption because it triggered a new handshake precisely so that a new session may be opened. In practice, performing a new handshake but resuming the same session can be done by people who feel that they must "renew keys" for some ill-justified reason; we are more in the domain of Tradition than Science here. Conceptually, doing a new handshake with the same session could be used as a way to exchange some new TLS extensions, but there currently are hardly any defined extension for which such a thing makes sense (but extensions are, by definition, open-ended, so this may be useful some day).


How can I protect my eCommerce site from stolen credit cards? The case would be that someone with stolen credit card registers on my site, and uses the stolen credit card details to purchase services through my site.

How can I protect my eCommerce site from stolen credit cards? What actions can I take to validate the card before it is used?

Normally when using the card with an official payment gateway, a reported, stolen credit card should be marked as unusable. The card will be refused by the gateway.

If you really need advanced authentication before allowing a card to be used by the client, you should verify his identity by making the client send you a copy of his ID card or passport and a recent bill (water, electricity,...) which states his name and address. This address should be the same as on the credit card. Do note that this will make transaction a lot more difficult and cumbersome and make some clients go away.

Also make sure that when performing credit card transactions you are completely PCI-DSS compliant if you have to be. If your business is not PCI compliant there are various measures that the card brands can take, ranging from warnings and monetary fines to revoking your ability to process transactions entirely. More importantly, the PCI DSS allows you to assure your customers that you're protecting their credit card data appropriately. In case of a breach you can also be held legally liable by your customers.


If the bitcoin network was cracking bcrypt, what cost factor would you use? Since the best example of pooled resource to crack hashes is the bitcoin network, currently churning through 2.14 ExaHashes/s.

I want to ask, if the resources of this network were pointed towards cracking blowfish, and (by extension) bcrypt, what would be the minimum cost factor to keep when protecting passwords using bcrypt?

Short answer: if you compare the speeds on x86, the maximum cost in PHP of 31 (2^31 iterations) would be secure enough for a strong (random 8 char) password. Not that it would be usable, one hash would take ~ 200 hours to generate on a desktop.
Long answer:
(large margin of error due to lack of accurate hash performance data, no specifics on password strength and lazy approximation.)
The cost of raw brute-force can vary with a factor of billions between a 6 letter password and a length 10 password with numbers and special chars. (26^6 = 3.0E+8 for lowercase, 94^10 = 5.3e+19 for mixalpha-num-all) Hashing speeds can vary with implementation.
So if the user picks one of the 1000 most commonly used passwords, it's as good as a 3 digit pin number, making the question practically irrelevant.
To this end, the answer is "as much as you can, we can't save everyone from themselves"
But let's make a back-of-the-napkin calculation to get an idea. Let's assume the database sets a strong minimum requirement of "as good as 8 random chars"
With a character set of all lower- and uppercase ASCII chars, all digits and special characters that would come to 6161234432565770 combinations
Now let's get an idea of the hashes' performance. The only side-by side comparison i could find that came close was this:
https://pthree.org/2014/12/26/sha512crypt-versus-bcrypt/
It states that the default work factor of 10 is about equal to 80.000 rounds of SHA512crypt
.
Now SHA 512 only costs about 120% of the time 256 takes
So that makes bcrypt with cost(10) approximately equal to 100.000 rounds of SHA256.
BCrypt's cost is defined like this:

The two digit cost parameter is the base-2 logarithm of the iteration
count for the underlying Blowfish-based hashing algorithm  and must be
in range 04-31, values outside this range will cause crypt() to fail

cost(10) = 2^10 = 1024 iterations. so bitcoin's algorithm SHA256 is about 100x faster per iteration.
Assuming BitCoins network can do 2.14E+18 SHA256/second, that would come down to 2.14E+16 iterations of BCrypt/second.
The keyspace of the length-8 random password in charset mixalpha-numeric-all is about 6.16E+16

So at 1 iteration, it could bruteforce such a password in < 3s. the minimum for PHP is a cost of 4, so 16 iterations.
At the default cost of 10, it would take nearly an hour.
At the maximum cost of 31 it would increase another 2^21 = 2097152 hours, which is a little under 240 years.

This is quite an infeasible brute-force, and could for the moment be considered secure.
The maximum amount of 'cost' in BCrypt would suffice against the entire current BitCoin network if the password is moderately strong.
However, the comparison of BCrypt vs SHA512 mentions cost(20) already takes > 3 minutes on a workstation, making such large costs impractical for now.
extrapolating 2^12*3.12/60 =~ 213 hours


How should this system be protected from ARP spoofing? Background
My university uses an authenticated (squid) HTTP proxy server for accessing the internet.
There are a few reasons for this:

They want to track misuse of the connection
Our university has subscriptions to most paywalled journals, and logging in via the proxy server unlocks this. Outsiders and folks which tunnel1 into the system should not be able to access these either.
They want to make sure that we don't script-download a lot of stuff from the journal websites -- accountability is the best way to do that.
They want to be able to block certain ports and sites. Aside from 80, 443 and 22, IIRC all the ports are blocked.

All logins on our institute are on ldap, as is the squid proxy. Which means that the same credentials are used for many other (more crucial) systems, and with them one could wreak havoc. For example, one can mess around with what courses people are going to take, drop people from courses, and cause many other problems.
The problem
The other day, while messing with ettercap, I discovered that it was quite easy to pipe it with grep and get proxy authorization data2 (which is just a base64 encoded header) from all people using the internet in a subnet of my choosing.
I would like to bring this to the attention of the authorities, as it's a rather severe bug. I'd also like to devise a fix for it.
Now, it is easy to protect the online portals from ARP spoofing by making them HTTPS (still spoofable, but IIRC Chrome starts complaining). However, there doesn't seem to be a consistent (across browsers) way to make HTTP Proxy authorization secure (or a SOCKS proxy, for that matter).
A  (not so good) solution
One solution is to use two sets of credentials -- one for the proxy and one for the rest of the intranet web portal logins (which can be made HTTPS). Keeping the proxy safe from impersonation isn't that big a deal. Someone tunneling in can't ARP spoof unless they already have access, and  there are a few other checks in place that will make it hard to falsely implicate someone by misusing the proxy in their name (IP logging, etc). On the other hand, keeping the intranet web portal pages secure is priority, due to the amount of havoc that can be caused with the credentials.
However, this isn't optimum, as the proxy is still open to abuse (just harder to abuse it), and people reuse passwords.
TL;DR
How does one (with control over the network infrastructure) prevent ARP spoofing on proxy authentication? I'm open to replacing the proxy with a similar entity (it must have auth though).
1. While shell access requires a login on your respective department, tunneling in requires a publicly available password. I guess that's something that should be changed as well.
2. This is easier than just logging generic POST requests and extracting passwords since there is a specific, grep-able format to this and the proxy credentials are sent with every GET and POST request one makes (which means that I can get a sizeable amount of data after running ettercap for just a minute.

There is a possibility to encrypt the connection to the proxy, there was a question on this site.Please find the link mentioned below.However the methods mentioned may not work at all times.

Is it possible to connect to a proxy with an ssl (or otherwise encrypted) connection?

To answer your query regarding implementing this on the network infrastructure:

There is a feature called Dynamic Arp Inspection.This can be enabled on supported switches.Each ARP packet is looked into by the switch and the IP mac binding is verified with a Trusted binding table.(I believe that the binding table is populated by snooping into DHCP at the time of IP allocation and i guess static binding between IP and mac can also be configured on the table).So any ARP packet with an incorrect mapping between IP and ARP is dropped hence preventing poisoning.