Port scans: 'traffic denied' VS 'close - age out' I have been investigating logs from the firewall (Juniper) and I've found out that when someone is portscanning my website, the majority of the traffic through different tcp/udp ports is denied (except for ports 80 and 443, which is allowed). However, traffic is allowed through some of the ports that it shouldn't be, for example, ports 4800, 502, 21025, 88. But after inspecting the log it also says 'CLOSE - age out'. Does that mean that the attacker managed to initiate a session but no traffic was sent for a certain amount of time ? Does the attacker get any information from these different responses ?
To clarify: I do not have access to check what is the exact firewall configuration.

Some Juniper devices log TCP RST packets as age out. This is to do with how the ASICs handle the timeout - see here.

A RST packet would be expected behaviour when a SYN based port scanner is allowed through the firewall on a given port. SYN scanners send the initial SYN packet to establish the TCP connection.

For a closed port most systems would reject this by sending a RST packet (thus letting the client know and not leaving them to time out).
For an open port the client would respond with an ACK. The scanner then (usually) sends a RST so the server knows it can close the connection.
Worth noting this could also legitimately be a time out. I.e. a connection is established but no packets are received within the firewalls timeout limit.

If you are seeing age out on those ports it would suggest the packets do make it through the firewall. Without seeing more information from the log, firewall configuration or server configuration it is difficult to speculate on both why these are allowed through and how far through the connection the process gets.


Infected employee using office VPN was part of a DDoS attack Recently, our office VPN was taken down by our ISP after discovering a DDoS attack. Apparently an employee connected to our VPN is infected. There were no logs at the time of the event.

Besides advising everyone to use an AV, what are the solutions to mitigate or solve this from both server/client side?  One idea is to ask them not to use our VPN as their default gateway so malicious traffic will not pass via our VPN server.

As you mention, you should definitely setup "split tunnel" VPN, wherein traffic only traverses the VPN when it needs to -- other traffic goes over the internet.  That is likely the simplest solution to your issue.  However, the caveat is that these infected computers can still be used as a hop-off point to access resources on your VPN; so you can have a security issue and not be aware with that solution.

There are many other, more complex ways of addressing the problem.  Of course, not just advising but requiring VPN users have active, up to date AntiVirus is important.  Many VPN concentrators (Cisco, Juniper, etc) have features in their VPN clients that allow for testing for compliance to a host profile -- e.g. see if updates are installed, antivirus is current, etc.

Moving up an order of magnitude, an IPS (Intrusion Prevention System) system is the ideal solution to this problem; if budget allows as these systems are prohibitively expensive and often require significant resources to setup.  A properly configured IPS will immediately revoke VPN access if seriously anomalous activity is detected -- a DDOS attack will almost certainly trigger this.

In this case, you can still use a "full tunnel" VPN with all internet traffic using the VPN as the default gateway if you prefer.  While speed may suffer on a full tunnel VPN connection, it will be more secure as all traffic will have to traverse the IPS system.


Sudo password when authenticating via passwordless SSH I've got a few boxes all networked together on Amazon EC2, each of which are in automated communication with each other via SSH (rsync, etc). As such, I've created SSH keys on each of these machines to allow them to SSH into each other without requiring a password. Likewise, my personal account is key-based and passwordless as well.

To the best of my knowledge, I've secured SSH appropriately using the well-documented methods.

Under this configuration, I notice that I don't have to provide a password to use sudo. If I try to su root, I get nowhere, because root doesn't have a password. However, if I run a sudo -i, I am asked for no password, and am immediately granted root. That worries me a bit.

So, two questions:

Should this worry me, or am I being too paranoid?
Is it possible to set a sudo password when using key-based SSH authentication?

Several of these boxes are web servers, and are hosting web applications of what I fear to be dubious quality. (I didn't write them, so they're dubious!) I've got Apache and the permissions on the servers configured such that a very unprivileged user (www-data) is serving the files, but my fear is that - somehow - an attacker could compromise a web application, escalate privileges to a more privileged user, and then simply sudo -i to root.

I'm not aware of a vulnerability in my software that would allow www-data to escalate its privileges, but I would prefer having a password in place to use sudo were that somehow to happen.

Also, for the record: I did try to set a password by logging in via SSH and then running passwd, but it threw an error. I don't remember the exact phrasing, but it was something about a "token". Either way, the password didn't stick, which makes me think I'm misunderstanding something at a fundamental level here.

Any illumination on the subject would be very much appreciated. Thanks.

-- Update: 7 December 2011 --

Thanks for the thoughtful explanations, all. It does in fact seem like the issue lies in /etc/sudoers. Thanks for pointing me in that direction.

I figured I'd document this for the sake of completing the discussion. When I looked into /etc/sudoers, I encountered the following lines:

# ubuntu user is default user in ec2-images.
# It needs passwordless sudo functionality.
ubuntu  ALL=(ALL) NOPASSWD:ALL

I am, in fact, using the ubuntu user for my privileged operations (though, again, the webserver is only running as www-data), so I guess that explains the issue I was having.

If anyone wants to follow up with a guess why the ubuntu user needs passwordless sudo functionality, I'd love to hear it. Otherwise, at least for the time being, I think I'll let good enough alone and leave the configuration as-is. I don't want to break a working system while trying to preemptively solve a non-existent problem.

Thanks again for lending your time and expertise.

The reason you're not being prompted for a sudo password is because your user (or usergroup) has NOPASSWD enabled in /etc/sudoers. You can edit this file with visudo as root.

Regarding passwordless authentication, you are correct that public key authentication is a preferred method for authenticating to servers. If there is no password to guess, then no brute force attempt can succeed.

The fact that you have no root password at all violates some best practices, but as you correctly stated, if a key is required to get into the box, it is probably alright. Having a root password might encourage you to use SSH to login as root, which should be disabled in your sshd_config.

The only question I have relates to one of your last paragraphs:

  Also, for the record: I did try to set a password by logging in via SSH and then running passwd, but it threw an error. I don't remember the exact phrasing, but it was something about a "token". Either way, the password didn't stick, which makes me think I'm misunderstanding something at a fundamental level here.

You were unable to set a password while sudo'd to root? Or just as a regular user? Having public key authentication in place shouldn't stop you from setting a userspace password, nor a root password. It looks like you might be encountering this problem, discussed on SuperUser, so hopefully that will help a bit.

I hope I answered the security side of your question; feel free to add a comment or followup if you need more information!


Multi Domain SSL for different ip? i have 5 domains(example.com,example2.net...) hosted on separate servers. is possible to use one Multi domain SSL certificate for these domain ?

Yes, you can.   You can have all of the domains listed in the SAN (Subject Alternate Name) field in the one certificate, and use it for them all.

This comes with a couple of things to consider, namely:

If any of your servers are compromised, or the certificate is leaked, you'll have to replace it everywhere.  You now have approximately five times the risk of the cert being compromised, and if it is, it can be used in attacks against any of the domains.  This is a real risk if one of the domains is particularly sensitive and its servers are hardened, and another is significantly less sensitive and not as much care is taken to protect its servers.   It's less of a risk if all of the domains are roughly equal in size and value, and of your, your mileage may vary.
The benefit, on the other hand is that you have slightly less management overhead.  Now you only have one cert to worry about renewing, and one renewal date.  This reduction in overhead may well be worth the bit of additional risk.


Is there a threat in router backdoors if I only use SSL? If there is a backdoor in a modem or router, it can execute a MITM attack. But what if I use SSL (actually TLS)? We use TLS in order to prevent MITM attacks anywhere on the way (such as the ISP, the website's host, or anyone else). Is the router any worse than any other step between the client and a website?

Regarding TLS, your home router should be the same as any other node, eg. from your ISP.

In company settings, it is somewhat common that each company computer also has a CA certificate from the router, and the router checks all traffic - in this case of course HTTPS is broken by design, and someone able to access the router can access all traffic data too.

And not directly related to TLS, but: Always remember that attacking HTTPS is not the only thing. A home router has a direct connection to your computer and can send/receive everything there. Network stack exploits, Intel AMT, DHCP weaknesses, something to take over your network printer and send all print jobs to the attacker, etc.etc.


How to migrate users? (Changing the login system) Let's say that you are about to change your log in system and you have a few millions of users that you want to switch to the new system.

Specification Old System

Username : email address
Password Policy : None
Email Verification : None
Password Hashing : None

Specification New System

Username : email address
Password Policy : Yes
Email Verification : Yes
Password Hashing : Yes

I am of the opinion that the users should have to recreate their password and verify their email address but asking the users that have been client for many years to suddenly recreate an account, verify their email or change their password might be a bad user experience.

So, I'm asking both in term of security and user experience :

How would you migrate those old accounts?

Note : Since it's a system that involves money transaction I really don't think we should keep the old passwords that often look like "123", "abc", "password", etc.

What you could do is hash the old passwords and make the users choose a new one when they login. You really need to force them to use new passwords though since if there's not a 100% chance that the old database was leaked their financial info could be exposed. If you think that the old system was compromised you'd be better off sending out emails, or requiring verification when they login.


Hash Security of Windows 7 Password I need to find some materials about how Security Accounts Manager(SAM) works in windows 7+. I am confused with the storage format of hashed value.

Many materials (such as, 1) tells me that it uses NTLM(or NTLM v2). However, as far as I understand, the security level of NTLM is very low. Most OS(such as unix) will provide random salt to enhance basic security level. For NTML, we can break it easily with brute force in several days(even several hours with great device). Also, if we use rainbow table, we can achieve perfect result.

Some other materials (such as, 2) tells me that Windows Vista or above has replaced NTLM with Kerberos. Does it affect SAM? If so, in default, which hash algorithm does it use in Windows 7 or above?

To make my question clearly, I want to list them below.

Does NTLM or NTLMv2 use salt?
Which algorithm does windows 7 or windows 8 use for SAM?
Whether kerberos affects the hashed format of SAM?

Kerberos is only available when you have a central server available, for instance, an Active Directory Domain Controller.

No, it does not use salt.
It uses NTLM if it isn't a part of a domain.  Details.
Kerberos does not affect the hashed format of SAM.


Storing random initial (one-time) passwords in plain text I manage a vendor app that issues accounts (with passwords, of course) to end users. From what I can see, final user passwords are stored properly. My concern is the initial account generation and communication step. The first point of contact with end users often isn't over the web — it's just as likely to be by phone, mail, or other means — and so the app has many options for communicating the initial account credentials to end users. To facilitate this feature, the app stores the initial password in a database column in plain-text that can be used for generating letters, welcome packets, email, shown on screen for communicating over the phone, integrated with other software systems, etc.

There is a mitigating factor here. The end user must change this password before they can complete their first login. The changed password is not written back to the database in plain text, and is not stored in a recoverable format. The original password is only good for at most a few weeks before it is changed. Additionally, the end user can't do anything with a new account that couldn't be rolled back if needed. It may be possible to leak some personal information, but I believe a new account won't display any data yet that isn't considered directory information.

However, it still nags at me that this plain-text password exists at all, and hangs around even after it's replaced. Given the mitigating factors, is this still a big deal?

I would say, it depends.

If the Creation of this account is triggered by some external means, for example payment, or signing up for some other service, such as so if any unauthorized person access the new unused account on your site would cause a security breach, then it can be a security risk if the database leaks.

If however, the account Creation is directly triggered by the end user, and the account is plainly unuseable without setting a password, then a attacker could gain the same access by signing up himself, thus it would not create any security risk if a initial password leaked.

If you really dont want to store unencrypted passwords in database, I would suggest hooking up a network printer to your service. If the service reside on a web hotel, you could put up some sort of tunnel or Connection between your printer and web service, so the web service can print anything on your printer.

Depending on the security settings and security policies of your server host or web hotel, you can either have it that your web service Contacts your printer via ipp and prints password, or you could have that your print server "polls" the web site for any new accounts and prints them.

As soon as a user signs up so password should be distributed via snail mail, then the web service immediately send this to printer, and then stores the password encrypted in database. This means you can still batch process the snail mails, by putting them in envelopes.
The papers with initial passwords and adresses and such just is there sitting in the printer output bin waiting for being processed, and can sit there for months.

A good thing with IPP is that its based on HTTP, so your can for example tunnel IPP in a SSL tunnel by using stunnel on the gateway or print server, and then on the client site, you simply encapsulate Everything in a HTTPS request instead of HTTP request.

This means the password will never be stored in cleartext anywhere on the server harddrive, it will only be available in cleartext on the paper, a paper that once sent away with snail mail, will no longer be available to you or any adversiary physically breaking into your location.


Can governments intercept end-to-end encrypted Whatsapp communication through lawful interception? Since Whatapp started end-to-end encryption with an option for users to verify keys, many government security agencies, like the Indian one, red-flagged such use of encryption.

Now, Yesterday the Parliament was informed by Communications and IT Minister Ravi Shankar Prasad that Security/law enforcement agencies face difficulty while dealing with encrypted communications by various application service providers including end-to-end encrypted communication messages provided by Whatsapp. However, security agencies are able to intercept these encrypted communication services through the lawful interception facilities provided by the telecom service providers.

Is this technologically possible considering its a 256bit? Can government agencies intercept end-to-end encrypted Whatsapp communication services through the lawful interception facilities provided by the telecom service providers?

It's very unlikely that any government agency would crack the encryption. They would need the key. And the only way they could get that is if Whatsapp had a backdoor or weakness in their software which allowed for such a key to be extracted.

There is, as of today, no direct evidence that such a backdoor exists in Whatsapp. But, since Whatsapp is closed source, it also becomes difficult to make sure such a backdoor does not exist.

However, in terms of information security, what we are interested in is a risk assessment. Considering OP, government agencies are the parties we are being asked about. We should therefore asses that risk. Here is some relevant information regarding that:

Whatsapp's parent company, Facebook, has been shown to give the NSA direct, unilatateral access to their servers through something called the PRISM Program. While Facebook denies this, it has been proven by leaked documents. This does not, however, mean that the NSA can decrypt Whatsapp messages. I include this information in the risk assessment as an example of Whatsapp's owner's relationship to the NSA and privacy transparency in general.

In 2013, information was released regarding: (Source)

  • NSA and GCHQ unlock encryption used to protect emails, banking and
  medical records

  • $250m-a-year US program works covertly with tech companies to insert weaknesses into products

We can absolutely not prove that this large, covert program has in fact worked with Facebook to put such a "weakness" into Whatsapp. However, this information is nevertheless relevant to our risk assessment. If such a weakness was actually implemented, it could compromise the encryption key.

Though not absolutely identical, considerably similar things have indeed happened before. Here is one example regarding Skype, Microsoft and the NSA.

Conclusion: It is, at present, difficult to conclude one way or the other. Whatsapp's parent company (as well as other companies) have demonstrated in the past that they are willing to give the NSA unilateral access to user data. They have also shown a willingness to lie about it. Given this, it seems difficult to take companies under the control of Facebook at their word regarding this particular subject.

When we evaluate the degree of risk in regards to malware, a virus, being hacked, data loss, data theft, surveillance, etc, it is not only relevant if something is proven. It is also relevant if something is possible or even likely. While, in this particular case, there may not be sufficient grounds to say that the NSA gaining access to Whatsapp encryption keys is likely, it is definitely possible, given the history of these entities.

This is something people can take into consideration when evaluating such a situation.

Related reading:

New Snowden Documents Detail How NSA Can Bypass Common Internet Encryption (International Business Times)

Microsoft handed the NSA access to encrypted messages (The Guardian)

Revealed: how US and UK spy agencies defeat internet privacy and security (The Guardian)

PRISM (surveillance program) (Wikipedia)


Claims based authentication to log on to a device Are there operating systems that allow logging on to the device (laptop, tablet etc.) using claims based authentication?

I don't think you're going to find anything substantial. Windows 10 supports auth via Azure AD which supports a federated IdP via WS-Trust.

Chrome OS supports google accounts, which can be backed by a SAML IdP.

In either case they have special implementations that rely on username/password combinations.


Can you generate Diffie-Hellman parameters quickly I am working on an android project for school and I am supposed to do a DHKE(Diffie Hellman Key Exchange). Everything works well, the problem is that it takes a lot of time (really a lot) to generate DHParameters. Basically, in my code, this is the part that is the most time (and battery) consuming:

KeyPairGenerator kpgDH = KeyPairGenerator.getInstance("DH");
kpgDH.initialize(512);
KeyPair kpDH = kpgDH.generateKeyPair();

As you can see, the key length is only 512 bits, so it's not long, and it still takes at least 30-40 seconds (best case scenario), but it can go up to 400 seconds. And I've tested it on several phones: Samsung galaxy s2 (quad core), samsung galaxy s4 (quad core), samsung galaxy note 10.1 (quad core).
Does anybody know an alternative to generate more quickly the p and g for the Diffie Hellman in order to speed-up the process?

First, 512 bits is way too small. Parameters that size can be broken in a month by a small computer cluster. Use 2048.

Second, the Diffie-Hellman parameters are public information. Any sensible cryptographic library would include default parameters -- probably from RFC 3526. (Even if your library doesn't include them, you can still use RFC 3526 parameters if you convert them to its input format.) If you insist on generating your own, do it once and hardcode them. You can even do it on your PC if you'd prefer not to wait.

This Stack Overflow question (mostly) demonstrates how to do it (though it uses 1024 bits; as I said, you should use 2048):

https://stackoverflow.com/questions/2469235/dh-keypair-generation-time-on-android

Generating the DH key pair itself is basically instantaneous.

Third, writing your own cryptographic protocol to learn is great, but do not use it in real code, with real user data, money and lives at stake. Designing secure cryptography is extremely difficult. Crypto is especially dangerous because something can look good, seem to work, and still be badly insecure. It takes teams of experts years and several tries to get it right. Use TLS.


Password reset for AD RODC-specific krbtgt_xxxxx accounts While there's a lot of information [1], [2], [3] about resetting the password for the regular krbtgt account, but I haven't yet found a clear suggestion about RODC-specific krbtgt_xxxxx accounts.

Should those be rotated similarily to regular krbtgt account?

On the very bottom of this article
https://adsecurity.org/?p=3592

  If the RODC is configured to cache passwords, change the RODC’s krbtgt_###### account’s password on a regular basis (2x every year). Microsoft’s krbtgt change script is not geared for the RODC krbtgt account (the risk of changing the RODC krbtgt password is very low). In Active Directory Users and Computers, right-click on the krbtgt_###### and change the password (set it to pretty much anything, Windows should automatically set the password to a random value).

If you read the article, the krbtgt account on a RODC is similar to the one from the "real" domain (writable DC), just limited to several groups of users/computers, if it was set up correctly. So resetting RODC krbtgt-accounts also makes sense.

(I wonder why something like this is not built into AD. A checkbox somewhere, to enable auto-rotation of all those krbtgt accounts.... would be nice :) )


SSL: MAC address tampering detecting? Suppose that in some scenario using SSL, a hacker has succeeded in obtaining the MAC address, but not the encryption.
Can this be detected?
Also, suppose he changes the MAC address: what should he also change in the IP and TCP layers?

TLS protects the application data only. It neither protects nor detects changes in the lower layers, i.e. neither TCP ports, nor IP addresses, nor MAC addresses. This would also not make much sense since otherwise TLS would not work over LAN borders (MAC address is specific to LAN, i.e. changes when passing LAN borders) and it would not be possible to use TCP level (non-intercepting) proxies and load balancers (i.e. IP and port changes).


Poor man's 2FA. Should I use composite passwords and how much does entropy matter? I use a password manager, I vary the length of my passwords occasionally and they're all unique and random but I think - what if the PW database leaks (e.g., malicious software exfiltrates the contents)? Not all sites support 2FA so how can I increase security?

I came up with an idea. I decided to type a word at the start before I autotype the long random password. The word is always the same for every account in this "important" category and the word only exists in my head. The idea is if the database leaks then no one can get in to my most important accounts because they don't know the word.

This is a sort of 2FA without the need for website support. If multiple important credentials were to leak it would be obvious what I was doing and you could assume there were other passwords that I use with this word at the beginning. I assume this decreases entropy. In what scenarios would my system be less secure, if any? Could knowledge of my secret word from one leaked credential (e.g. from a website breach) help you crack another of my accounts beyond the obvious benefit of knowing e.g., 5 of my 25 chars? Am I better off not doing this for some cryptographic reason or is it a sensible extra precaution against a database leak?

After seeing some answers, more concisely, could knowledge of [staticWord]'s existence / content / position, help you crack "[longRandomString][staticWord]" or is it always at least as strong as [longRandomString]?

Just thinking through this, is there a possibility an attacker may not know they've cracked a password if it's a random string, until it's tested to see if it works. Whereas you could assume it's cracked if you decrypted a random looking string and noticed a real word at the end of it. I don't know whether this could/would happen. I think my staticWord should be short and random.

What this doesn't protect against

You don't really specify which database may leak. If the database of the web application leaks, or if your complete password leaks - eg via phishing - your scheme will obviously not help against that at all, because it's not real 2FA.

What this does protect against

On the other hand, if your password manager database - and the corresponding password - leaks, this will help in certain situations.

If we assume that an attacker knows that you are using this scheme, you are now essentially using the same password on all websites. Your security now depends on the security of the weakest website you registered, and on the strength of your additional password.

Things to take into account

Your second password should be reasonably strong, otherwise the scheme is useless.

Obviously it should also not be the same password you use for your password manager.

I would also recommend that you append this password after the password stored in your password manager. Some websites may cut off your password after X characters, and if X is small, you may end up with just this extra password, which will make leakage more probable and reduce your overall security. On the other hand, if your additional password is cut off, your back where you started (no additional security, but also no additional weakness).

Conclusion

Your scheme may add a small amount of additional security in case your password manager data leaks, although the added usability disadvantage - having to type the additional password - wouldn't be worth the trouble for me. At the most, I would use the scheme for extremely important accounts.

A more reasonable approach would be to have two different password manager databases: one for the less important passwords which you can also use on systems which may be more likely to be compromised, and one for important passwords, which you will only use on systems you deem to be secure. This should achieve the same goal you want to achieve in a cleaner way.


Initial handshakes of attacks via client-initiated renegotiation As far as I understand after reading this beautifully explained answer, MiTM data injection attacks via client-initiated renegotiation can only happens if the attacker is already in a connection with the server which did not check his credential. He then issues a command, and escalates his privilege by triggering a renegotiation and splicing in an authentic client's handshake, and the server will then mistake the command for one coming from an authentic client.

Similarly, according to this post, the DoS attack works by an attacker first establishing a connection to a server (during which his credential is not checked), and then repeatedly trigger renegotiation on the same connection.

My question is: if I'm operating in an environment where the client's certificate is checked upon first connection, I should not be affected by this, is it correct?

A related question: if the connection is started after StartTLS, since StartTLS checks for client's certificate, are client-initiated renegotiation attacks also not applicable?

I don't think client certificates will solve the problem of computational DoS. Consider the sequence of messages in SSL / TLS:

The client certificate is sent to the server after the ServerKeyExchange message. In the case of [EC]DHE_RSA the ServerKeyExchange message involves the server signing the DH parameters with it's long term public key. So the server has already performed a computationally intensive operation (RSA signature) before the client even sent it it's certificate.

A better approach would be to require a client puzzle to be solved in between the ClientHello and ServerHello messages.


It is common for an account to be locked after X amount of failed logins, what are the best practice of selecting x? To my understanding, it is common security practice to lock the account after X failed login attempts in N minute. Usually, the account will be locked for M minutes.
I noticed that most of the time X is 3 and usually the account needs a reset by the system admin. Now my question is why X most of the time 3? and are there any methods we should follow to figure out accepted values for N and M.
I am mainly asking this in case of access controls systems that are not using password-based protection but other factors like behavioural biometrics or context-based authentication

It depends upon environment and intent.
High security environments often use 3 failures to lock and require contacting an admin and verifying your identity to unlock.
More automated systems may use 5 failures with a timed unlock after some time, typically in the region of 15 minutes to 1 hour.
I usually set Fail2ban to block remote access after 5 failures within 5 minutes with a timeout unblock of 30 minutes, under the theory that if a person screws up 5 times then waiting 30 minutes to try again is acceptable but 30 minutes is long enough to send brute force bots along their way as not viable.


How to deal with Office documents in file upload? When creating or testing a file upload functionality how do you deal with Office documents assuming that the client wants to be able to upload .doc/.docx/.xls/.xlsx?

I have found quite some reading material about the possibilities of writing your malware in Office documents in macro's and other functionalities. But I have also found that no one really has a good way to filter out all harmfull possibilities with Office documents.

Users upload these files and other users download these files and open them as they see fit (as in we have absolutely no control over the users). How do I protect the users from other users that try to upload malware?

Well you have 2 possible defense lines here and my advice would be to combine both.

try to filter malware out of the documents

you could try to use an antivirus to automatically scan any uploaded file and reject it when positive
you could try to filter any macro out of office documents, but it could be harder than it seems at first sight, because there are numerous formats, and it will be easy to let one unfiltered

use a reasonably strong authentication system - one that you can trust to be able to unambiguously identify the real user in your use case - and consistently log all actions including versioning of files if they are modified

if a malware is later found on your system, you will be able to identify the culprit - with all legal consequences involved
it can be seen as a dissuassive weapon: if users know that they could be later charged for their bad actions, they are likely to try another way


Symlink file name - possible exploit? I found a vulnerability in one of my managed website where I can give any name to the symlink file name source link. I cannot control the target directory link though. Also I can create as many symlinks in that directory with different source names but pointing to same target directory. My questions are:

Can it be exploited in any way? What worse could happen it left it like as it is?
How many symlinks creation are allowed in linux in any particular directory?

Thanks

TL;DR Fix it. Don't leave it like that.
It depends heavily on your file system permissions.
Assuming the (Linux-)user that creates the symlink has write permissions to other directories in the filesystem, they can create symlinks anywhere that is writable on the file system e.g. "../unexpected_sym_link".
Any operation that follows symlinks (e.g. bash: find -L ...) would now include the TARGET file in its results.
Although there is no real value that an attacker can get from using this exploit
as is, they might assist this to obtain something in combination with other exploits or routines in your website.

There is no specific limit on the number of symlinks created in a directory, but rather on the number of files in a directory, which you can find here.


How does SEH based exploit bypass DEP and ASLR? I am new to  structured exception handling based exploits.

Why don't we put our return address directly in SE handler to jump to our shellcode? (with no safe SEH)

Can anybody explain the reason of using pop pop ret?

I read something that said SEH bypasses ASLR and DEP, but how?

Our shellcode will be located on the stack and since the stack will be still non-executable, how is DEP bypassed?

http://www.exploit-db.com/wp-content/themes/exploit/docs/17505.pdf

Using SEH to achieve exploitation defeats neither DEP nor ASLR.

In particular, DEP will mitigate execution of shellcode off the stack memory page which, ultimately, it was what an SEH based exploit is trying to achieve.

Without a non-ASLR module in the process spacing being used to locate the SEH exploits key POP POP RET, ASLR remains to further impede exploitation.

As Van Jone suggested in his comment, ROP (and an info leak for module base address discovery) are necessary for DEP and ASLR defeat.


HSTS doesn't work on browser when dealing with a self-signed certificate We have a web portal and I need to add HSTS header in the response. Ours is an on-premise solution, so we use a self-signed certificate. I have added the hsts header in the response & I need to check whether it really works.

I understand that for HSTS to work, there shouldn't be any certificate issues & first we need to access https://somesite.com then in the next pass http request will be automatically redirected to https at client side itself.

So, I installed our self-signed certificate in the Chrome browser & restarted the browser. Now my connection to our web application was secure. But HSTS doesn't seem to work. In the successive calls to http://somesite.com, still we redirect (302) to https (automatic client-side redirection to https doesn't happen). One thing to note here is, there is no domain name associated with our web application, we access it with our server's ip within our company's internal network.

Any idea how to get HSTS working?
or is it like HSTS works only if there is a domain name for the site?

Actually, this is already answered in stackoverflow :  RFC 6797 Appendix A : HSTS doesn't work for IP address.

You need to setup local DNS server to deal with it.


Is RC2-CBC at all secure? (And more generally, is there a site listing which various algorithms are still considered secure, so I wouldn't have to ask that here? Wikipedia's "known best attack" is not particularly clear.)

I noticed our email system, IceWarp, supports S/MIME in its webmail app. (Which itself is probably not a very good idea considering it requires uploading the private key, even if it's a corp-issued one. But that's beside the point.)

Anyway, when sending S/MIME messages, IceWarp uses RC2-CBC [this does not seem to be configurable anywhere]. How secure is that in 2015?

(Is it better, or worse, than 3DES-EDE-CBC which apps like Thunderbird use?)

RC2 is a currently "unbroken" block cipher; the best known attack is a "related-key attack", i.e. something which does not really apply in practice (related-key attacks are about specific properties when the victim uses two distinct keys, that the attacker does not know, but with a difference between them that the attacker knows).

RC2 still has some suboptimal properties:

It uses 64-bit blocks. This makes it unsuitable to processing large data sets, the cut-off being around 2n/2 blocks when blocks consist in n bits. For a 64-bit block cipher, this amounts to about 30 gigabytes with a single key, which is large but not unattainable in some contexts. Encrypting more data than that implies a risk of revealing part of the plaintext. Note that 3DES suffers from exactly the same limitation. For encrypted emails, you should be OK with that.
Its performance sucks. About as much as that of 3DES; on my (underpowered) laptop, OpenSSL's implementation achieves about 10 MB/s with 3DES, 12 MB/s with RC2. There again, for emails, this should not be an issue.
RC2, in its description, uses a lot of data-dependent lookup tables. In that sense, it would be very difficult to make an implementation that is "constant-time" (i.e. does not leak information to attackers that can run their own code on the same hardware, through cache-induced timing differences); at least, it would be very difficult to make one without a massive slowdown (like a 100x slowdown factor). Note that classic 3DES implementations are not constant-time either, but that can be done with only a "moderate" (relatively) slowdown (about 3.5x with my own code).

Since email sending is asynchronous, and moreover since email encryption and decryption tends to happen on the user's desktop computer, not on a shared server, this kind of side-channel leakage should not be a big concern anyway. Unless you decide to upload private keys on a server, in which case the concerns may come back -- make sure, at least, that the server is not hosted in a cloud that shares the very same hardware with outsiders.
RC2 has a configurable key length, between 1 and 128 bytes (i.e. 8 to 1024 bits, and multiple of 8). Thus, while RC2 itself can be a tolerably fine algorithm, it can still be used with a key which is way too short for ensuring a decent level of security. RC2 also includes an additional parameter (called "effective key length") that can be used to limit the brute-force resistance. Historically, RC2 has been much used in setups meant to comply with the pre-2000 US crypto export rules, with a typical strength equivalent to 40 bits (i.e. not strong at all).

The fourth point is, in my opinion, your biggest risk when using RC2. You do not really know how large the actual encryption key is; if the software you use does not document that information, then you do not really know how strong the encryption will be. Moreover, software that uses RC2 might be a bit lacking in maintenance...

To sum up, there is nothing really wrong in RC2 itself for encrypting emails, but the implementation still has ample room for doing stupid things that annihilate security.


How effective are anti-virus products against real-world threats? In a recent interview† with Dave Kennedy, he in passing pegged the average effectiveness of anti-virus products as detecting approximately 3% to 5% of current active threats.

While AV comparisons will typically publish detection rates, those are always based on historical virus samples which are only mildly relevant in today's security landscape. Current virus and malware activity is inherently difficult to properly gauge.

Do we have any scientific measure of the real-world effectiveness of off-the-shelf anti-virus products in detecting and stopping today's active threats?

Put differently, what is the actual real value of running an anti-virus product when facing today's common security threats?

† PaulDotCom Security Weekly Episode 335 -- Excerpt

Do we have any scientific measure of the real-world effectiveness of off-the-shelf anti-virus products in detecting and stopping today's active threats?

No. New viruses are created everyday, some may spread far enough to get caught by Anti-virus vendors, others might not, slight variations in viruses can cause them to be missed and many people in underground markets offer 'FUD' Crypters/Packers in order to evade AV solutions. With so many people writing malicious code and the code being re-used/modified to suit its more than possible what we see and defend against is only the tip of the iceberg.

  Put differently, what is the actual real value of running an anti-virus product when facing today's common security threats?

The vale? It provides another Layer of security. Like all security technologies, no one single defense creates a 'bulletproof' defense against all malicious attacks. I've heard wildly varying estimates as to the size of AV signature database but the point is, that it'll catch low hanging fruits (it'd be embarassing to be pwnt by ILOVEYOU now wouldn't it?)
In addition, the herustics engines might work for you from time to time and find new malware that doesn't have signatures.

Its all about defense in depth!


Question about "FUDing" with hex editor I see a lot of materials in Internet about this technique. I'm not really interested in malwares, but I'm curious when you change bytes to an exe with other bytes, wouldn't this corrupt the exe? I can give example videos if somebody didn't understand my question.

You'll want to load into tool such as OllyDbg and you'll have instructions and you can modify them to do the same sort of job as alternative instructions then save them to executable so byte signature against your file would be bypassed.

You can rewrite code to do same job. Let's make a really basic scenario.
Imagine you seen in executable. I'm going to pretend this is x86 executable:

004CFF64 - B8 05000000           - mov eax,00000005
004CFF69 - B8 07000000           - mov eax,00000007

So, 10 byte in total.

You could rewrite that as:

004CFF64 - B8 05000000           - mov eax,00000007
004CFF69 - 90                    - nop
004CFF6A - 90                    - nop
004CFF6B - 90                    - nop
004CFF6C - 90                    - nop
004CFF6D - 90                    - nop

Which is still 10 bytes in total but the signature has now changed.
Reason why we used a NOP (No Instruction Preformed) is because it does nothing but use space.

Now, in real world situation you won't come across it as easy as that you'll have to use code-caves and so on. For example let's say you needed to write more than 10 bytes of code then you really can't do it since you would overwrite next instruction which would corrupt the executable. Well, what you do is use JMP instruction to free space in memory which then you'll do all code there and you'll use JMP to get back to normal execution of code.

Byte signatures are generally do on whole file and static parts of the executable.
For example .text (Sometimes known as .code etc) which is the executable part of the code and the memory regions are not writeable so they won't change although you can override the permissions with VirtualProtect API.

I could go into much more detail about obfuscation, how byte signatures works and so on but I hope that answers your question if not leave a comment and I'll expand my answer.


Contactless credit cards security In the UK there has been a large increase recently in the use of contactless card payments (you pay by waving your card over a reader). Prior to this the primary way to pay with a card was to use "chip and PIN" where you insert your card into a machine and enter your PIN.
The banks and card issuers claim the contactless method is more secure than chip and PIN but I am struggling to see how this can be true.
Visa appear to just gloss over the security measures in place:

How secure is a Visa contactless payment?
Very secure indeed, and certainly much more secure than carrying cash. Visa contactless cards use the same secure technology as Chip and PIN so you can feel totally confident when you’re using it to pay. Source

There is no second factor authentication (PIN entry) when paying. If I have someone else's card I can pay, up to a transaction limit of £20, ten times a day.
I have also had the ultra paranoid thought that someone could modify the the Kimble tag sensors around the door and read your card automatically as you leave the store. That is probably pure science fiction though.
My question is: How can contactless payment be more secure than Chip and PIN?

No, contactless transactions are not more secure than contact transactions. The whole contactless business has a lot more to do with making payments easier on the point of sale (and possibly enable future developments of the smartcard business) than in increasing security.

Ridiculous early US implementations aside, we have a couple things going on here:

transactions less than a certain amount are authorized in nocvm mode, meaning, no card verification method - it's what you have observed
transactions over a certain amount (depending on the country etc) will be asked for an online pin verification (meaning the PIN is encrypted in the PIN pad and sent over the network to the issuer for authentication), whereas contact-EMV cards will typically do an offline PIN verification where the POS asks the card's EMV chip if the PIN is OK.

this is more of a different kinds of usability tradeoff than a security one - offline pin allows offline authorizations on the POS where transactions need to be super fast. Both online PIN have their unique (and difficult to execute) attack vectors.

with contactless the card doesn't get a chance to verify the issuing host's authenticity (ARPC verification is not done). It's one security measure of the EMV scheme that I never fully understood and with contactless it's gone so I guess I was not the only one :) but still, it's 1 security measure less

Some extra EMV tags aside, as far as I know this is the only impact of EMV+CLESS vs old-school EMV. Magstripe+CLESS, or allowing EMV fallback with CLESS results in that youtube video from the beginning of the post and is completely ridiculous.

EDIT 1: holy cow https://play.google.com/store/apps/details?id=nfc.credit.card.reader.pro2 it seems the ridiculousness is still on. Not only it reveals the card data, but the transaction history too. I mean it's on Google Play, it and a bunch of others. Don't test it with production cards.

I don't understand, Visa/MC went through so much issues on the US market with the early NFC, they went through a mountain of trouble due to early magstripe cards. Finally, EMV is here and it's secure, and then they upgrade it with NFC capability by basically reverting the security almost all the way back to magstripe levels.


Are our email credentials safe with email clients? I've been trying out a few desktop email clients (Windows) to better manage my e-mail.

As I tried Thunderbird, Inky, and Outlook, it occurred to me, what guarantee is there that my e-mail/pass won't be compromised by using email clients?

Wouldn't it be really simple for the author(s) of e-mail clients to incorporate a function that sends the users' login info to a predefined server?

I just wanted to know whether I'm being paranoid or is this a valid concern?

It's a valid concern. Any software which runs on your desktop can execute any code it wants. You need to trust your software to be authentic. You can transfer some risk mitigation to your firewall, antivirus, host based intrusion detection, or other anti-malware to some degree. But, if you have already installed the application and enabled firewall rules, etc. they likely won't be much help to prevent such exfiltration.

Most desktop clients are not encrypting your account passwords, and there are plenty of tools which can recover passwords from instant messaging clients, email clients, and browser. You would need to find a product at least claiming encryption that uses a master password to protect your other passwords. Also note though, you will have to trade off convenience and security in most cases - the decrypted credentials need to at least be stored in memory to be used continually; if they are discarded after downloading/sending your email, you would have to put in the master password again each time, since most mail client connections are not persistent.


How does the weakness of SHA-1 introduce attack vectors in SSH? The security branch of my company worries that the use of older versions of OpenSSH (pre-7.4), where the only Key Exchange Algorithm available is SHA-1 is a major security issue. They suggest generating new public/private keypairs for all users in the infrastructure.
As a Linux admin I'm supposed to be making a plan for fixing this issue, but when I try to research it, it seems that there is some mixup between the algorithm used to generate private/public keypairs, and the algorithms used in the connection handshake between two hosts.
As far as I can tell, the SHA-1 hashing algorithm is only used in the key exchange between two hosts, to validate each other, and has nothing to do with generating the public/private keypairs.
It also seems that the demonstrated vulnerability applies to things such as pdf documents, where there are tons of metadata that can be tweaked to try to generate an identical hash without actually generating visible text. I'm not even sure this is possible to implement in the SSH handshake.
My big question is: If our servers are vulnerable because they use SHA-1 in the handshake, what are the worst case scenarios?

Can the attacker spoof a known host and capture sensitive information by having an unknowing user log into it?
Can the attacker get a hold of login info directly or indirectly?
Something else?

Please also correct me if I have misunderstood something, I have found a lot of conflicting information about this!

SSH uses a hash algorithm in couple of places:

As a pseudo-random function in the key exchange (e.g., with diffie-hellman-group14-sha1).
As a message authentication code (e.g., hmac-sha1)
To sign a signature over the negotiated session hash to authenticate both parties (e.g., with ssh-rsa)
To sign certificates if you're using OpenSSH certificates (e.g., with ssh-rsa-cert-v01@openssh.com)

Uses 1 and 2 are still secure, since they rely on properties of the hash function that don't involve collision resistance, which is what's weak about SHA-1 (although there are uses of HMAC-SHA-1, such as commitment schemes, where collision resistance is required).  Therefore, there's no reason that SHA-1 itself is weak here.
Use 3 is more questionable, since you're performing a signature, where collision resistance is required, although this is probably not practically attackable.  The attacker would have to have some way of guessing the shared Diffie-Hellman secret or a derived value, and we generally expect that to be computationally infeasible.  That's because SHA-1 is weak to collision attacks, so an attacker has to be able to produce two messages (which, with current attacks, are of a certain form) that hash to the same value, and it would be hard to do that in an online manner without the assistance of the server.
Use 4 is a serious problem.  Because we assume users can generate their own key pairs, using SHA-1 to sign a certificate is very weak.  OpenSSH certificates contain somewhat less data than X.509 certificates and exploiting this is therefore likely to be more difficult, but this is the threat I would worry about most, and it's the one that the OpenSSH developers are most worried about as well.  If an attacker carried out an attack here, the attacker could get access to systems they should not due to an invalid certificate being accepted when it should not be.
So if you're not using OpenSSH certificates, you're probably not at a direct risk from attack.  However, there are more reasons to avoid using SHA-1 if you can:

It's weak in many practical cases and we prefer to use cryptographic primitives which are unambiguously strong.
We don't want to encourage others to use SHA-1 at all, since even if we're using it in a secure way, others might decide to use it as well and then use it in an insecure way.
It sets off security scanners and causes compliance problems, as you've noticed.

It goes without saying that all of these also apply to MD5, which you should definitely not use.  And there are some additional reasons why SHA-1-based algorithms are bad in SSH particularly:

Most of the SHA-1-based key exchange algorithms use groups that provide less than 128 bits of security.  Because the security of the key exchange is required for forward secrecy of the connection, you'd want to avoid using a weak group here.  The generic group exchange diffie-hellman-group-exchange-sha1 could be secure, but that depends on both the server and the client being configured correctly.
Using SHA-1 in the key exchange loses entropy (as outlined in RFC 4253) if you negotiate an encryption or MAC key longer than 160 bits.  Therefore, the most security you can possibly get out of using SHA-1 in the key exchange is 160 bits.
DSA (ssh-dss), which uses SHA-1 for signatures, is limited to 1024 bits in SSH, which is far too small for practical security.  RSA keys less than 3072 bits also offer less than 128-bit security.

128-bit security is the minimum level of security for practical matters these days.  Some organizations have requirements for 192-bit security.
If you can use any of the Ed25519, Curve25519, ECDSA, or ECDH algorithms that OpenSSH supports, these will use stronger hash functions and will avoid your entire problem.  They may also be available on older systems.  When in doubt, follow the Mozilla recommendations.


Effectively Pentest a Wordpress Site When it comes to blackbox pentesting of a Wordpress site, the first thing to come to mind is WPScan [http://wpscan.org/].

While pentesting some sites, I faced a common issue i.e it shows that Wordpress SEO 1.14.15 is vulnerable to Cross Site Scripting Attack. Output is given below:

 | * Title: WordPress SEO 1.14.15 - index.php s Parameter Reflected XSS

 | * Reference: [http://packetstormsecurity.com/files/123028/][2]

 | * Reference: http://osvdb.org/97885

But when following the link http://packetstormsecurity.com/files/123028/ , it shows that attack can be executed with

But the main problem is when I tried to inject several XSS vectors, the results were not positive. I was not able to find any XSS in above url. There is proper output encoding, a snapshot is shown below:

So my question is:

Do you have any method to bypass this and execute an XSS?
Do you have any other tool or resources through which I can do better blackbox testing of Wordpress?

Wordpress is attacked 3.5 times more often than non-CMSes. WPScan is a great tool that's been around since the BackTrack Linux days.

However, there are more tools and techniques available. Here is a list of some newer tools:

https://github.com/RamadhanAmizudin/Wordpress-scanner
https://github.com/enddo/wp-plugin-scanner
https://github.com/0xBADCA7/wp-xmlrpc-bruteforcer
https://github.com/droope/droopescan
https://github.com/iniqua/plecost

Techniques for Wordpress security testing and remediation:

https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline
https://www.acunetix.com/blog/articles/wordpress-security-wpadmin-directory/ (a 10-part series on Wordpress Security from Acunetix)
https://www.acunetix.com/vulnerabilities/web/wordpress-xml-rpc-authentication-brute-force
https://www.acunetix.com/vulnerabilities/web/wordpress-username-enumeration


Which Protection Profiles required for EAL 1 test? I have some question about PPs for EAL1 test.

1- Which PPs required for a Router Devices in EAL 1 test?We only need compliance with 'collaborative Protection Profile for Network Devices' (aka NDcPP) or other PPs is required,such as 'Router PP for Medium Robustness Environments' ?

2- If I need to compliance with Router PP, so the question is : EAL 1 test is a functionally test, but Router PP has requirements for Structurally and Methodically test, for example FCS_IKE_(EXP).1 in the page 61 of Router PP. well, Do I need certain requirements  instead of all requirements in Router PP? Which requirements is needed?

Thanks a lot for you answer.

For a simple network device such as router, in 2016 you only need to claim NDcPP (collaborative Network Device Protection Profile) and nothing else.  PP (protection profile) you linked is no longer in use. NDcPP will include all functional (SFR) and assurance (SAR) components that you have to include in your ST (Security Target). NDcPP is evaluated at EAL1, but you don't include explicit claim of EAL assurance with it.
NDcPP requires exact compliance, that is you can't add or remove requirements and conforming is all or nothing deal. The only exception is EP (extended packages) such as firewall and SIP server that are technology-specific. You can find full list of EPs here: https://www.niap-ccevs.org/Profile/PP.cfm by searching for "Extended Package for...".


Does the secure attention key really increase security? Are there any statistics on whether requiring the secure attention key to be pressed on login actually increases security ?

I personally don't see the point of that :

if you're after credentials, you're better off phishing email or other app's credentials that allow access from the Internet. Phishing OS credentials won't do any good as you still need to be physically on the network to use them
if you're physically in the building and have access to the network you can do more damage, and the secure attention key won't do much either as you can completely replace the machine with your own one which doesn't care about the secure attention key (or rather does, but presents your fake login screen when pressed)

Also, there seems to be no SAK support in Mac and Linux support is weak (the code is in the kernel but no desktop manager appears to take advantage of it) and it seems no one is screaming about it, which makes me think it's more a security theatre popular in the Windows networks more than anything else.

The system-attention-key is mostly an historical remnant from the youth days of the engineers who designed the SAK. These engineers, when they think about security, actually think about the times when they were dabbling in security, and that was when they were students. More precisely, when they were students in the 1990s. That last item is important: in the 1990s, students did not usually have networked computers, in particular laptops; more commonly, the students were sharing a dozen workstations in a dedicated room. The students, being students, engaged into the kind of things that students do, in particular setting traps and jokes on each other. "Stealing" the password of a co-student was a common game.

And game here is an important word. The point was not really to have the password to enact mischief, but to demonstrate technical skill for boasting purposes (most human activities, at least from male people, are at their core about gaining or keeping Alpha male status, even to the point of absurdity because computer rooms of the 1990s were singularly devoid of any female that could have been wooed by such a display of technical skill). Thus, the "password stealing" needed not be efficient but elegant. This included amusing systems by which a user would keep a picture of the login screen running as a basic application under his own name, mimicking the true one and grabbing the password of other people -- the elegance coming from the fact that the attacker does not even need local administrative rights ("root privileges"). You will notice that the SAK prevents exactly that attack.

Real-life attackers don't play that nicely. When they have physical access to a machine, they first get kernel-level access, possibly by physically damaging the machine (an unthinkable heresy for a computer student), and if they want to log keys they just do, regardless of the SAK. But engineers who design operating systems now still think in terms of the golden days of their early twenties; they try to thwart not the practical real-life attacks, but the elegant shenanigans from a more civilized age.

So the SAK is there, mostly to give a feeling of safety to people who envision attacks and key logging like a game they played two decades ago and still fondly remember. Like most things in computers, it is there out of a matter of Tradition.

(Note that some of these engineers did not get jobs designing operating systems, but writing specifications of "security rules" to which organizations shall conform -- for an hilariously extended effect of lingering tradition. OS designers still have to include a SAK because they need it to comply to some regulations, even if they know it does not make a lot of sense.)

Now, in practice, what good does the SAK make ? Not a lot. One can still say that the login password of a user is sensitive data -- not because it grants access to the local network (an access that the attacker already has, by virtue of hijacking a machine that runs on that network), but because users have the habit of reusing passwords, either directly or through some transparent "rule" (if user's password on server QZ982 is "PasswordQZ982", guess what will be the user's password on server YH455 ?). But the SAK is not enough to resist key logging anyway.

Security is really increased, not by SAK-like attempts, but by (as usual) educating users, in particular to the necessity of not reusing passwords.


Detect Different Machine using Browser Some web apps like Facebook and Gmail detect the first time we try to login from a device.

Assuming that a browser can't read machine name, and MAC ADDRESS. What kind of variables are they collecting for doing this validation?

as the website service panopticlick puts it "How unique and trackable is your browser?"

there are many things that especially via scripting can be found out about your machine. This uniqueness estimation can include

browser type
browser version
geometrics (screen size)
average cpu usage / calculation power via script trial
fonts (are a especially neat way to test for uniquess)
the operation system as reported by the useragent stuff from the browser


How to fuzz shared objects? I know there have been similar questions about that topic, but I think mine differs from the others. I have this application which I am able to crash, but the error seems to happen inside of a shared object library, which gets loaded by the application. So my question is, how do I proceed further?  I attached the application to GDB and let the application crash. But how could I find out if the error relies in the library?

You can't. For example, if you call a printf() with a NULL as format string, you will get a segfault in the libc, although it won't be a libc error.

But you can be nearly sure, that the shared library doesn't checks some of the data structures it gets from the main program (or from another dlls). C libraries doesn't need to do that (normally).

And if something isn't checked against NULL-pointer dereference, probably it wasn't checked also against buffer overrun. And such errors are mostly caused be NULL-dereference. You should always check on the asm-level (even with the gdb), what caused the crash, and to make an assumption, what were it on the C level.


Somehow unexpectedly my computer got infected with malware So I consider myself a pretty conscious computer user.
I run Windows 7 SP1 Pro 64bit and I update it.
For surfing on the web I use Firefox 20.0.1 - I keep it updated. I also have NoScript and AdBlock - both up-to-date and running all the time. If I trust a site, I allow scripts from it (sites like stackoverflow etc.).
For virus protection I use MSE - I know it's apparently not the best free software out there, but I though it'd be sufficient.
Ill also point out that I dont forward any ports to this PC.

On the 6.05 at around 10:00 I started to browse the internet. I visited sites like stackoverflow.com, teamliquid.net and others - generally sites which I trust. I also visited sites which contained information about MPI protocol, but as far as I recall, I didn't allow scripts to run on these sites.

At about 11:00 I went to bathroom. When I returned, say at 11:30, I noticed that software was installed on my PC ('freshly installed', highlighted in menu start). I didn't notice this software before leaving to bathroom, it might have been there already, but I think it was NOT there yet.

So this software is called QType (quicktype apparently). It's somehow connected with other software - DealPly. They actually both got installed on my PC at that time, however only QType appeared as 'freshly installed' in my start menu. This software could also be somehow connected to 337 Technology Limited company. When I booted my browsers, they were both hijacked. Start pages looked like google, but it was in fact www.qvo6.com/... So in fact my browsers got hijacked.

So after seeing it, I went to view Windows' Event Viewer-> Windows Logs -> System to do some research. I noticed this message: Information; 2013-05-06 11:15:58; A service was installed in the system. Service name: Qtype Service ... Just after this one, this server entered the running state. There is no information about the other software - DealPly.
Next thing I did was check what happened just before this suspicious service got installed while I was away. So in the event viewer system logs I can see, that something was happening with my browser: 'The computer brwoser service entered the running state.' and after a couple of seconds (six seconds in each log im looking at atm) 'The computer browser service entered the stopped state'. This rebooting of the service happened quite a few times.

So I wanted to ask those of You, who have some understanding in this matter. How is it possible that this software got installed without my knowledge. Was it some site I visited? Is it possible if I have disabled running scripts on sites? I may have accidentaly enabled scripts on some malicious site, but I don't think so. Is it possible that I didn't enable those scripts and it still got through somehow?
Or is it something entirely different? Could it be some PDF I opened weeks earlier? (I sometimes read PDFs about stuff, like just recently about CUDA - but I imagine they come from trusted sites, of course this is naive reasoning).
Or is it something else?
Does the fact that this software got installed without my knowledge imply that someone has taken control over my PC?

I run a full scan of MSE - detected no viruses. Right now ill be running some anti malware software to get rid of unwanted things. Im considering re-formatting the PC - this would be the safest way, but I really don't like the idea of having to install all the IDEs and software again.

This infection really came as a surprise to me.
Please feel free to answer if you think you can provide some insight on this matter and perhaps explain what took place on my machine, I will greatly appreciate your time.

I will also appreciate any tips to prevent such situation from happening in the future.

The easy answer is: browser exploits. Not visiting "dodgy" sites does not, in any way, mean that you're 100% safe. There have been many cases of exploits loaded through flash or pure HTML/JS through ad networks, for instance (if you are a gamer, Curse had this two years ago).

Even if everything you have is up to date, there are still ways around it. There are hacking competitions every year with the sole aim to prove that 0day exploits (exploits used before the manufacturer is aware of the exploit) are still alive and kicking. Pwn2own proved this pretty clearly every year it ran. Take, for example, the 2011 results:

stock IE (no plugins) fell on day 1
Safari (latest + fully patched mac) also fell on day 1
All phones were hacked on day 2
At the end of the contest, Chrome and Firefox remained unhacked.

"Hacked" means in this case that the hacker had access to program execution (by running calculator.exe as a proof) and disk I/O (by writing a file to disk).

In 2012, Chrome fell, by the way. Along with Firefox.

All this is to say that, no matter what, a fully patched system does not equal to "secure". By the looks of it, you've been victim of a drive-by attack. DealPly has been reported to do this, by the way. A full security advisory for it is available from Symantec.

P.S: if you're running IE7 or 8...Neither of those has a sandbox.


Is it possible to store an android apk in SIM card and install it from there? I suspect somebody has installed a spyware in my android smartphone. I have done factory reset, which is supposed to uninstall all apps in SD card and internal memory. I am curious about following.

Is it possible to store an android apk in SIM card (not SD card) and install it from there ? If yes, does a factory reset uninstalls such an app (or spyware)  ?

No. SIM card is generally very small (32kb ~ 64kb) and stores only TLV records, which is not really suited for apk (though technically it can still be possible to store it as a binary record, but is technically very challenging).

Factory reset restores an image which is stored in a system partition on the phone, so if the spyware has somehow been able to successfully corrupt the factory image, then it would again be restored on factory reset. However, such modification can be done only when your phone is rooted (has su binary) or when your bootloader is replaced by an infected bootloader (Most android phones have specific key sequence to be pressed in order to access bootloader, check xda forum for your phone model). Probably that is how malware is able to reinstate back on factory reset.


File encryption with external key I want to encrypt a few files on my computer (not FDE). To do this, I'd like to use something that requires having some external usb thing with the key on it plugged into the computer. Price is not really an issue for the usb device (ideally in the hundreds of dollars). Any recommendations for solving this problem?

It depends on what security features you are looking for; specifically, how much you mistrust your own computer.

If you just need the decryption key to reside on a USB device, then you can put a key file on a basic USB flash drive, and use GnuPG. The key will of course make it to the main computer, because the computer will do the actual decryption work. But at least the key will not be written to a file on the computer; it will be in RAM only. This is the cheap method. It works in the case where you do not trust your computer when it is powered down; e.g. this is a laptop and you fear that it could be stolen while you are not using it.

To go one step further, you may want to consider encrypted drives like these ones. The encryption and decryption keys are known to the device only, and all encryption and decryption occur in the device, not the host computer. Some models can even be unlocked with fingerprints (a reader is embedded in the device). If the host computer is hostile (e.g. compromised with a nasty virus), it can still plunder your data when the device is inserted and unlocked, but at least you have some control on when such things may happen.

If you have really sensitive data that must never be shown to a potentially compromised computer, then the most natural solution is to buy a dedicated computer, kept offline, for this data.


Is accepting the current and the previous one-time password a bad practice? I often see two-factor authentication (2FA) methods using one-time passwords (OTP) implementations wherein the current (previous) and sometimes even 2 or 3 previous tokens are still valid. This is probably done for several reasons, I can think of:

to overcome possible time sync issues between the client and server (user experience),
for convenience of the sysadmins not to constantly have support calls about not being able to login.

Is accepting the previous OTP a bad practice? And if so, what is the general recommendation regarding the implementation of such "features"?

Correct me if I'm wrong but when the token is 6 digits, the number of possible combinations are 1.000.000 (000000 - 999999). So only 1 in a million tokens in accepted during a 30 second time-span. But when accepting the previous (or even more previous) tokens the chances are basically 2, 3, 4, or 5 in one million.

If by previous you mean an OTP that predates one the user already authenticated with then yes, this is considered bad practice. The OTP is meant to be used once, hence the name. The whole point of 2FA is that it represents the "something you have" in the security trinity. Allowing a token to be used twice defeats the purpose of what OTPs are meant to prevent. Turning it into "something you know" which makes it just a second password.

This problem usually doesn't present itself as a brute force issue. For example in the case of TOTP where the time windows are relatively short, brute forcing isn't really used to circumvent it. The use case as an attacker for a site that allows OTPs to be reused, either current or past is interception.

If the client uses the OTP and it is somehow intercepted, the attacker now reduces the problem to username password. Which, if they're intercepting information is likely also listening for these.

In the case of HOTP the problem is even worse, because theoretically the counter or moving factor does not increment very often. Meaning the last or even previous OTP the user authenticated with will likely be valid for a long time. In some cases months depending on the implementation of the server.

If by previous you mean the OTP on or before the current one being generated but not yet used, then no, within limits. Standard implementations of OTPs apply a "window" to overcome sync issues usually. In the case of TOTP, a 5 second window is employed (both forwards and backward) but this, in any implementations that I have seen, always disallows any OTP that is on or before the last one the user authenticated with. If we take the case of a 15s moving step with a 15s window there would be three OTPs that can be used to authenticate over a 45s timeframe, one in the past, one now and one in the future (this assumes the interval is the same as the moving step). The reasoning behind this is elegantly explained in @cornelinux's answer.

For HOTP the window is a "look ahead" window. The last OTP the user authenticated with was allowed if it was within the next 10 OTPs of the previous one accepted, and then the implementation calculates the next 10 from that one for the check against the next OTP entered. It has the considerable good sense to disregard any of the OTPs not used in the window before the one used successfully.

Note:

In HOTP 10 is arbitrary. Usually the factor is about 2.5 times the number of OTPs required to authenticate successfully. So if the user needs 3 HOTPs to authenticate the window will be about 8 OTPs after the current one.

In TOTP 5 seconds is also variable. In some cases I've seen windows as large as 100% of the moving step. So with a 30s step and a window of 30s effectively makes a code valid for 1:30. Again, expanding both before and after the current iteration.


Why does one need a high level of privacy/anonymity for legal activities? This question is sort-of spun off of a previous one.
Why do law-abiding citizens need strong security?
There are a lot of great security-focused answers there.  However, I think the true question that is brought up is more about privacy and anonymity than it is just security.

I'm looking for concrete examples that can be presented that show the need for strong security when conducting perfectly legitimate activities. Examples in the areas of trust worthy encryption on end-to-end communications for cellular networks, network identity obfuscation services like Tor or VPNs, complete and total data destruction, and so on are what I'm after.
I'm always inclined to point to social uprisings in states like Libya and Egypt but these events tend to be presented to too many of the people I encounter that use this argument as "things that happen on TV" and not real things that have any effect on them or their personal liberties. So counter-arguments that keep it squarely in the first world, it-could-hurt-you-or-your-grandma kind of are really valuable here.

The examples brought up in the post copied above are really more specific to privacy and anonymity than they are about general security.  I'm sure you'll find that most "Joe Users" will agree there is a need for Antivirus, Wi-Fi encryption, and other common defensive measures.  But, why would the same people have a need for things like Tor, or end-to-end encryption over cellular networks?
To be a bit more clear:  What are some arguments for personal online privacy/anonymity that your regular Joe User - who plays Angry Birds on Facebook while sitting in his boxers on the living room couch - will relate to?

One real world example - when you are naked in your shower, not doing anything wrong, would you like it if everyone came by and took pictures? Or televised your shower for the world? Probably not.

Another example - if I send a love letter, or write a will dividing up my savings, should that be published on the front page of the national papers? Again - no.

If I am carrying out my own business, the expectation should be that I have privacy, except where I have consciously and deliberately waived it. This was the case before technology became pervasive - it should still be the case. In the old days law enforcement needed a warrant before they could access your property or communications, because the assumption has to be innocent until proven guilty. This has been eroded as technology has developed.

If I encrypt all my emails to my friends, the expectation should not be that I am a criminal for doing it, just that I want privacy, like leaving a room to take a private phone call. I could be planning a surprise birthday party, or applying for a new job, or possibly just enjoy using PGP - it doesn't really matter - it's my business.

From the EFF's privacy page:

  Privacy rights are enshrined in our Constitution for a reason — a
  thriving democracy requires respect for individuals' autonomy as well
  as anonymous speech and association. These rights must be balanced
  against legitimate concerns like law enforcement, but checks must be
  put in place to prevent abuse of government powers.

Admittedly, I don't live in the US, but those constitutional rights sound good to me.


How likely is it to find valuable information in the slack space of a workstation? I just read about slack space which is the unused space at the end of a sector. This space is unused in some sectors when either the file itself is smaller then the sector or the sector contains the end of a file, which is likely to not fill the sector completely.

It seems to be a good practice to inspect the slack space of a filesystem too. It might contain data left from overwritten files or even data hidden there on purpose.

I understand the theoretical value of this but I am very sceptical if this practice will come up with any really useful results. Am I missing something or is the probability of success really just a matter of luck?

This doesn't have a definitive answer.

It depends on what the workstation is used for, what information is stored in the slack space, how much data overwrites valuable information before you get to it, and even what you consider valuable information.

During forensic analysis, you always read and analyse the entire filesystem, because sometimes you will have useful data, but you really only stand a chance of finding recent data on an HDD.

On an SSD, as @NeilSmithline commented, things are a little different, as writes aren't to the same location - overwriting doesn't happen in the same way: wear-balancing moves write areas across the addressable space on the SSD, so forensic analysis can turn up a lot more consistent data. Given time though, you'll still lose data of interest, so time is always considered of the essence.


Can a webcam be turned on when disabled in Windows' device manager? In addition to whether a webcam can be turned on without the indicator light, I was wondering if disabling the device in Windows' device manager is a good option.

Of course when your system is compromised already, it's possible (and probably trivial) for an attacker to turn the device on, and back off when he is done. But just about the theory, is there any way to use the cam without having to enable it first?

Additionally, can hardware management be protected, so that an attacker cannot turn a device on without knowing a password? Or if Windows can't, can Linux or OS X?

Most of this question is hypothetical, but I just wonder. Thanks!

Most malware is likely to just iterate through all webcam devices and attempt to turn them on. Disabling the device in device manager is very likely to protect you against 99% of cases.

On a more anecdotal level, I've come across around maybe ten or so different bits of malware over the years that have various remote webcam capture functionality, but not a single piece of malware that has attempted to enable hardware devices that were previously disabled by the user.


Does anybody not store salts? We talked about password hashing and salting in class today. Our professor had a very different understanding of the use case of salts from mine and said that you might not store the salt at all and just check every login attempt with all possible salts and authorize if one matches.

I don't really see any point whatsoever in this since now my service is much more vulnerable to brute force attacks (send one password, server checks many), but I guess it is a little more secure to pure dictionary attacks against the hashed password.

So is there any use case where people would actually do this?

Not storing the salt is bad advice.

The main purpose of a salt is that each user password has to be attacked individually.

If you do not store the salt then, as you said, you need to try every single salt combination in order to validate the password. If you need to check every single salt combination, this means that the salt cannot be too long (you mentioned 12 bits in a comment). If the salt is not long, it means that the salt will be repeated for many users. If it's repeated for many users, it means the attacker will be able to attack many users at the same time, which will save the attacker time.

By doing that, you nearly completely defeat the purpose of using a salt.


How can I protect content distributed on a linux virtual machine? What assets am I trying to protect?

An unofficial pre-alpha software prototype provided as a reproducible example for evaluation during the scientific peer-review process. The software will be officially released under an MIT/BSD style license after it has been peer reviewed. The VM has been distributed through a ftp site and as a DVD.

The stakes are low: My gut feeling is that I don't want the unofficial version circulating in the future. I want the official version, with the capacity to update and cleaned of misc. artefacts to be used and not be confused with existing copies of the old version.

Even if I extend trust to peer-reviewers and colleagues, I would like to be able to share the software more informally without having to request that the file be deleted after the official version is released.

who uses the asset you're trying to protect, and who you think might want to abuse it (and why)?

Other scientists / potential employers / unwitting recipients who have not read the disclaimer could either scoop or falsely trust the draft version of our incredible and revolutionary software. The VM itself depends on code that is still under development and not intended for the first release of the software.

what steps you've already taken to protect that asset?

I have a cron job set for July 1st, 2012 to run a script cleanvm.sh to remove files. I have used the virus tag because this seems to provide functionality I normally associate with viruses.
Using the VM requires a password.

what risks do you think you still need to mitigate?

I would like to a) prohibit transfer of files outside of the VM and b) ensure that there is no simple workaround to disable the cron-job (changing system time comes to mind). Ideally I could set up a remote kill command that I could send prior to the official release , but that might be 'overkill' for the present context.

Have a good read of this question on how effective DRM controls are.

The summary is that no - if you give the code to the user, you can't control it effectively. So one option is to never give them your code:

Can you use a terminal/Citrix type solution to just allow them the experience of using your code? If so, that is the route I would recommend in your circumstances.

Of course, a possible drawback is poor user experience if they do not have sufficient bandwidth.


Is it dangerous for a scammer to know just your name and birthday? Basically, this afternoon, I got a call that I had picked up. The caller asked for (my name) stating that they were from this company associated with my healthcare. The call seemed pretty legit, and they asked for my birthday and my address for confirmation. I was a bit fishy at first and wanted to tell them I was busy and that I would call them later. I don't know where they got my name, but I had given them my birthday, but not my address. Am I in danger of ID theft?

Update : Thank you for all the responses so far, the thing is, I did ask them for a number that I can contact them by, got a number and googled it. The results are 50/50. It's not a chance that I would like to take. Knowing that they already had my name and phone number, I can just assume that they now have a zip code of where I live. Now they also have my birthdate, which causes me to be extremely worried. The thing is, I'm not at the point in life where I file for tax or have credit, but I am worried that this will come to haunt me in the future. Are there any steps that I can take to limit any possible id theft?

It depends on what other information they have.  If it was in fact a scammer, they may have had other information but needed your birthday to make use of it.  In that case, you'd have an imminent risk of identity theft if they were able to capture the additional information needed to make use of what they already had.

That said, name and birthdate by itself isn't really a big risk.  I have my name, birthday, education, general area I live, e-mail address and home phone number all publicly listed on my website in easily scrapable fashion and have never had issues with identity theft.

Most of that information can be obtained online already anyway from a variety of open source sources, such as social media and public records as well as from database dumps of compromised corporate databases which most people are likely to have been in.

Certainly any expected fraudulent call is worth following up with the legitimate company to validate if it was real.  If it was a real call, you have nothing to worry about.  If it was not, then they will want to know so they can warn other customers if this kind of fraud is being targeted at many of their members.


Should I be concerned at the lack for transparency by Microsoft which quietly added 17 root certs? This week it was noticed that Microsoft apparently very quietly pushed out 17 new trusted root certificates (Infoworld Article).  The lack of public announcement seems a bit strange.

Is anyone aware of a press release by Microsoft or some other publication that might make this event seem less sinister? Furthermore, should I be concerned that my trust stores are being updated without notifying or querying me?

No, new root certificates are added on a regular basis. Microsoft have a Trusted Root Certificate programme enabling CAs to enroll.

This happens with most products that handle certificate verification. For example, this is Mozilla's list where you can see that there are several added per year.

For Microsoft's list you can simply check your Windows OS's certificate store for root certs.


SERVER-IIS multiple extension code execution attempt Sourcefire detected a SERVER-IIS multiple extension code execution attempt event and captured a packet. It originated from a Chinese IP, AbuseIPDB has several records about its malicious activity. Some of the logs included a user-agent string mentioning Googlebot2.0, but doing a reverse IP lookup, the IP doesn't resolve to anything, so I'm guessing it is spoofed.

Now the question is, is this exploit visible in the packet (.asp +.jpg), or Sourcefire captured just one of the execution attempts? Can someone explain the anatomy of this attack?

Packet:

.PV..4.
I.....`#..E..s.f@....2.!%.
 .....P.**..l..P..<._..HEAD /Ac2.asp;.jpg HTTP/1.1
User-Agent: IE 10.0
Host: www.*****.com

What you see is an attempt to exploit a Microsoft IIS vulnerability (a pretty old one, in fact). I found this blog entry with documentation and more details about it:

https://soroush.secproject.com/blog/2009/12/microsoft-iis-semi-colon-vulnerability/

The code name for this vulnerability is CVE-2009-4444.

This event doesn't identify whether the attacker succeeded or not, it just shows that they attempted to exploit it.


How would one crack a weak but unknown encryption protocol? I was reading this interesting question:

Is my developer's home-brew password security right or wrong, and why?

It shows a weak home-brew algorithm developed by "Dave", and the answers discuss why this is a bad idea. (Actually hashing algorithm rather than encryption, but my question applies to both.)

It makes sense to me that a home-brew algorithm is a very bad idea, but there's one thing I'm not understanding.

Assume I'm an attacker, and I am faced with an weak-but-unknown encryption algorithm developed by "Dave". How would I crack it? I wouldn't even know where to begin. It would be a seemingly meaningless string of characters.

For example, say that the home-brew algorithm is like this:

Use a weak well-known encryption algorithm on the original data, then:
Do a bitwise-negative on any byte whose serial number in the file has a repeated digit sum which is prime. (Or any other such mathematical manipulation, this is just an example.)

How would one hack a file produced by such an algorithm without knowing it in advance?

Edit: Everybody, please don't try to convince me of how hard it is to keep an algorithm secret. Please answer this question on the assumption that the algorithm is kept completely secret, despite of how difficult that is to achieve in real life.

Also, assume that I have no access at all to the algorithm, only to the resulting data.

Assume I'm an attacker, and I am faced with an weak-but-unknown encryption algorithm developed by "Dave". How would I crack it? I wouldn't even know where to begin. It would be a seemingly meaningless string of characters.

That's correct, you wouldn't. Here's some encrypted data (4587556841584465455874588). Got a clue what that means? Absolutely not.

However, you're missing the core, fundamental most integrally important central pillar key to the universe that holds cryptography together. The idea is simple:

the key is everything

That's it. That's the bit you have to protect. The bit you must guard with your life and hope nobody is going to hit you with a hammer until you tell them what it is.

On this basis, you must assume that your algorithim can be read by the attacker. They know how it works. They can document its process. If there are any weaknesses, they'll find them. And they'll exploit them. Like that angry CIA Dad from Taken.

This, it turns out, is less of an assumption and more of the practical case in use. Dave, the home brew cryptographer, wants to include an encryption algorithm in his program. Deciding to eschew all the testing and design work cryptographers have done for him for free over the years, he writes something involving the odd xor, compiles his program and helpfully gives it to friends.

That algorithm is now in their hands. Game over.

Now, you might ask "can't I just keep the algorithm secret? That'll work, right?" Oh Dave, plz stop. Nonono. The problem with secret algorithms is that they're much more likely to be stolen . After all, the key is different for each user (actually, this is not a requirement, but, let's just assume it is for simplicity) but the algorithm remains unchanged. So you only need one of your implementations to be exposed to an attacker and it is game over again.

Edit: Ok, in response to the OP's updated question. Let us assume for a moment that the algorithm is totally unknown. Each of the two participants in an encrypted conversation have perfect security of their algorithm implementation.

In this case, you've got data to analyse. You could do any one of the following:

Analyze for frequently known letters. This is how you'd break a typical caesar-shift cipher.
Attempt to guess the length of the key. With this information, you can move into looking for repeated ciphertext blocks which may correspond to the same plaintext.
Attempt index of coincidence and other such measures used to break the vigenere cipher, since many polyalphabetic ciphers are (possibly) just variants of this.
Watch for patterns. Any pattern might give you the key.
Look for any other clues. Do the lengths correspond to a certain measure, are they for example multiples of a certain value such as a byte boundary and so are (possibly) padded?
Attempt to analyze with one of the symmetric cipher cryptanalysis techniques. These rely on knowing the algorithm in many cases, so may not apply here.
If you believe the the data in question represents a key exchange, you can try one of the many techniques for breaking public key algorithms.

The fact is that a short piece of data from an unknown algorithm could well be undecryptable. However, this does not mean you should rely on this being the case. The more data a cryptanalyst can recover, the more likely they are to break your algorithm. You probably don't know without serious cryptanalysis what that boundary is - for example, it is reasonable to assume that one could bruteforce a caeser-cipher algorithm for three letter words, since there are few that make sense.

You are up against re-use problems too. In WWII, the Engima overcame this problem by having programmable settings for their secret algorithm, but this was broken too.

There is also the human element of cryptography to consider. I realise the label on the tin says "use once, do not digest" etc, but humans are humans and will likely use twice, three times etc. Any such behaviour plays into the hands of the cryptanalyst.


Flash Drive: Is it possible to figure out what/when files were added? Recently left my flash drive on the university computers and someone found it. He said he looked through the flash drive to find my resume and contact me. I want to leave this situation in good faith, but I was wondering if it is possible to find out when files were added to the flash drive.

I initially thought you could just look at date modified, but for my intent, that won't help me.

Note: my flash drive is big enough to not be able to find any file I don't recognize.

No. The flash drive itself does not have its own concept of time and has to rely on the time being given to it by the host computer. This link has good information on how to detect some date forgery but a sufficiently skilled attacker would be able to plan for this (Note: the link refers specifically to NTFS, so if your flash drive is a different format your mileage may vary).

If you believe the device could have been tampered with the absolute safest thing to do is either format your existing one, or throw it away and get a new one.