SQL injection vulnerability in browse.php in Accessories Me PHP Affiliate Script 1.4 allows remote attackers to execute arbitrary SQL commands via the Go parameter.

Multiple cross-site scripting (XSS) vulnerabilities in Accessories Me PHP Affiliate Script 1.4 allow remote attackers to inject arbitrary web script or HTML via the (1) Keywords parameter to search.php and (2) SearchIndex parameter to browse.php.

Multiple cross-site scripting (XSS) vulnerabilities in Silurus Classifieds 1.0 allow remote attackers to inject arbitrary web script or HTML via the ID parameter to (1) category.php and (2) wcategory.php, and the (3) keywords parameter to search.php.

SQL injection vulnerability in the select function in Irokez CMS 0.7.1, when magic_quotes_gpc is disabled, allows remote attackers to execute arbitrary SQL commands via the PATH_INFO to the default URI.

Multiple cross-site request forgery (CSRF) vulnerabilities in Photokorn Gallery 1.81 allow remote attackers to hijack the authentication of administrators.

Multiple cross-site scripting (XSS) vulnerabilities in Photokorn Gallery 1.81 and earlier allow remote attackers to inject arbitrary web script or HTML via the (1) where[] parameter to search.php and (2) qc parameter to admin.php.

Multiple SQL injection vulnerabilities in search.php in Photokorn Gallery 1.81 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) where[], (2) sort, (3) order, and (4) Match parameters.

Directory traversal vulnerability in down.php in MyBackup 1.4.0 allows remote attackers to read arbitrary files via a .. (dot dot) in the filename parameter.

PHP remote file inclusion vulnerability in index.php in MyBackup 1.4.0 allows remote authenticated users to execute arbitrary PHP code via a URL in the main_content parameter.

The biggest news out of this presentation is that requirement 6.5 will now apply to all in-scope applications, not just Internet-facing or browser-based applications. Based on all of the breach research that has been conducted, they have finally realized that any application in the cardholder data environment (CDE) is a potential hazard, not just those [...]compliancesoftware06202448387744872480

Dinis Cruz came to town to talk about the O2 Project and some of the many OWASP projects. This is the second part of the talk explaining the O2 platform.

Cast: David Bryan

David Bryan

We are starting a new blog post series here on the ModSecurity site called "Advanced Feature of the Week" where we will be highlighting many of ModSecurity's really cool capabilities.  These are the features that seldom used or fully understood by the average ModSecurity user however can provide detection of sophisticated attacks if used properly.  It is our goal with these blog posts to help shed light on these unique features and to provide some real-world, in-the-trenches gotchas for successful usage of these features.

This blog post series will have the following major topic sections -

1) ModSecurity Reference Manual Information

Provide reference manual data.

2) Use Within the OWASP Core Rule Set (CRS)

Outline if/when/how the CRS is utilizing this feature.

3) So What?

Will provide some context as to why you as a user should even care about this capability.  What advanced attack/vulnerability is this attempting to catch.

This week's feature is on the use of the @validateByteRange operator.

Reference Manual

validateByteRange

Description: Validates the byte range used in the variable falls into the specified range.

Example:

SecRule ARGS:text "@validateByteRange 10, 13, 32-126"

Note

You can force requests to consist only of bytes from a certain byte range. This can be useful to avoid stack overflow attacks (since they usually contain "random" binary content). Default range values are 0 and 255, i.e. all byte values are allowed. This directive does not check byte range in a POST payload when multipart/form-data encoding (file upload) is used. Doing so would prevent binary files from being uploaded. However, after the parameters are extracted from such request they are checked for a valid range.

validateByteRange is similar to the ModSecurity 1.X SecFilterForceByteRange Directive however since it works in a rule context, it has the following differences:

• You can specify a different range for different variables.

• It has an "event" context (id, msg....)

• It is executed in the flow of rules rather than being a built in pre-check.

ASCII Byte Range Chart

æ







backspace
tab
linefeed


c return


















space
!
"
#
$
%
&
'
(
)
*
+
,
-
.
/
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~

€

‚
ƒ
„
…
†
‡
ˆ
‰
Š
‹
Œ

Ž

96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143

‘
’
“
”
•
–
—
˜
™
š
›
œ

ž
Ÿ

¡
¢
£

¥
|
§
¨
©
ª
«
¬
¯
®
¯
°
±
²
³
´
µ
¶
·
¸
¹
º
»
¼
½
¾
¿
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
À
Á
Â
Ã
Ä
Å
Æ
Ç
È
É
Ê
Ë
Ì
Í
Î
Ï
Ð
Ñ
Ò
Ó
Ô
Õ
Ö

Ø
Ù
Ú
Û
Ü
Ý
Þ
ß
à
á
â
ã
ä
å
æ
ç
è
é
ê
ë
ì
í
î
ï
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
ð
ñ
ò
ó
ô
õ
ö
÷
ø
ù
ú
û
ü
ý
þ
ÿ

240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255

OWASP ModSecurity CRS

Use of @validateByteRange in the OWASP ModSecurity CRS (from the end of the modsecurity_crs_20_protocol_violations.conf file) -

# # Restrict type of characters sent # NOTE In order to be broad and support localized applications this rule # only validates that NULL Is not used. # # The strict policy version also validates that protocol and application # generated fields are limited to printable ASCII. # # -=[ Rule Logic ]=- # This rule uses the @validateByteRange operator to look for Nul Bytes. # If you set Paranoid Mode - it will check if your application use the range 32-126 for parameters. # # -=[ References ]=- # http://i-technica.com/whitestuff/asciichart.html # SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "@validateByteRange 1-255" \ "phase:2,rev:'2.0.8',pass,nolog,auditlog,msg:'Invalid character in request',id:'960901',tag:'PROTOCOL_VIOLATION/EVASION',tag:'WASCTC/WASC-28',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE3',tag:'PCI/6.5.2',severity:'4',t:none,t:urlDecodeUni,setvar:'tx.msg=%{rule.msg}',tag:'http://i-technica.com/whitestuff/asciichart.html',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/EVASION-%{matched_var_name}=%{matched_var}" SecRule TX:PARANOID_MODE "@eq 1" "chain,phase:2,rev:'2.0.8',pass,nolog,auditlog,msg:'Invalid character in request',id:'960018',tag:'PROTOCOL_VIOLATION/EVASION',tag:'WASCTC/WASC-28',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE3',tag:'PCI/6.5.2',severity:'4',t:none,t:urlDecodeUni,tag:'http://i-technica.com/whitestuff/asciichart.html'" SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer|TX:HPP_DATA \ "@validateByteRange 32-126" \ "t:none,t:urlDecodeUni,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/EVASION-%{matched_var_name}=%{matched_var}"

As you can see, the CRS is, by default, only restricting the existence of Nul Bytes.  If the user initiates the PARANOID_MODE variable, however, the CRS will restrict down the allowed byte range to only allow 32-126 which are the normal printable characters for US ASCII (space character through the tilde character).

So What?

Why would you need to use @validateByteRange to restrict anything more than Nul Bytes?  The short answer is because of the potential of Impedance Mismatches between a security inspection system (IDS, IPS or WAF) and the target web application.  The process of data normalization or canonicalization and how the destination web application handles best-fit mappings can cause issues with bypasses.  Here is a great recent references for this issue.

• Lost In Translation - Giorgia Maone (of the NoScript FF extension fame) outlines how ASP classic web apps attempt to do best-fit mappings of non-ASCII Unicode characters.  One example issue is the following XSS payload

%u3008scr%u0131pt%u3009%u212fval(%uFF07al%u212Frt(%22XSS%22)%u02C8)%u2329/scr%u0131pt%u2AThis payload should be correctly decoded to this -

〈scrıpt〉ℯval(＇alℯrt(”XSS”)ˈ)〈/scrıpt〉

ASP classic, however, will try and do best-fit mapping and actually will normalize the data into working JS code -

<script>eval('alert("XSS")')</script>
The issue that this raises, for security inspection, is that the inbound payload will most likely not match most XSS regular expression payloads however the application itself will modify it into executable code!

So, this brings us to today's advanced ModSecurity feature - @validateByteRange.  By restricting the allowed character byte ranges, you can help to identify when unexpected character code points are used.  If the payload above is sent, you should receive an alert message similar to the following -

Message: Found 3 byte(s) in REQUEST_URI outside range: 32-126. [file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_20_protocol_violations.conf"] [line "251"] [id "960018"] [rev "2.0.6"] [msg "Invalid character in request"] [severity "WARNING"] [tag "PROTOCOL_VIOLATION/EVASION"] [tag "WASCTC/WASC-28"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE3"] [tag "PCI/6.5.2"] [tag "http://i-technica.com/whitestuff/asciichart.html"]

CEOs must make secure coding a priority in their organization by budgeting in for process changes, says Ryan Berg, a senior architect of security research for IBM. Berg discusses why some companies lack direction when it comes to secure software development.

Three years after the United Nations' website was defaced by activist hackers using a SQL injection attack, the site still contains multiple instances of these vulnerabilities. Read the full article. [Dark Reading]

Shorten URL: . Click to copy to clipboard or post to Twitter Donald Sears

SAMM and the financial services industry:

 I have conducted, sold and project managed SAMM engagements to financial service (FS) organisations throughout Europe over the past years. It is obvious the demand is growing for such services. The rise in demand of  “security@source” be it via code review, secure development or grey box penetration testing and a supporting framework to tie it all together and understandably so as SAMM is one of the first pragmatic benchmarking and assessment frameworks for the somewhat ancient “Security in the SDLC” challenge.  

The financial services industry is the perfect work stream for frameworks like SAMM. Financial services are widely known as the an area which invests heavily in areas such as information security, it’s heavily regulated (some say not heavily enough) and  a daily challenge to FS is to maintain leading edge security but manage costs and usability whilst also being compliant with industry regulations,  corporate governance and local/regional/global  legislation.

SAMM covers four domains which in turn have sub domains. These four “pillars” attempt to examine all aspects of software development, all external catalysts which may result in either making security more robust or result in weakness.

The beauty of SAMM is its simplicity:

It would be naive to assume SAMM is a “silver bullet” in terms of SDLC assessment but it is a very pragmatic solution to a rather complex ecosystem.

The questionnaire is simple and effective assuming knowledge of secure application development as it can sometimes be open to misinterpretation.  One of the key challenges in developing SAMM was delivery/authoring of the questionnaire. The risk being that individuals being questioned may misunderstand the questions.

The key to an accurate SAMM effort is [in audit speak] to procure a decent “sample space”.  Sample space is a function of the amount and the diversity [roles within the SDLC] of the individuals interviewed by the SAMM reviewer. Accuracy of the answers given is also important as you shall get divergence based on role within the organisation.

Road map definition is also a challenge and knowledge of what are the  focus points for the organisation being assessed are very important to develop the roadmap. [E.g. A financial services organisation may focus on regulatory and compliance issues but a software development house may not so much.] A principal benefit of SAMM is the ability to define a high level roadmap and drilling down into each activity in order to define what is required to reach the required SAMM level for a given domain.

When you're designing your site for the mobile web, the secret is simplicity.

In just three years, entrepreneurs like Adam Bernhard have created a new retail niche--private sample-sale websites--that has grown into a $1 billion business and changed the way America shops.

Joab Jackson wrote an article detailing some of the potential vulnerabilities of the HTML5 standard set. Will security be the Achilles' heel of HTML5? By Jean-Jacques DubrayJean-Jacques Dubray06202448387744872480

Multiple integer overflows in libgdiplus 2.6.7, as used in Mono, allow attackers to execute arbitrary code via (1) a crafted TIFF file, related to the gdip_load_tiff_image function in tiffcodec.c; (2) a crafted JPEG file, related to the gdip_load_jpeg_image_internal function in jpegcodec.c; or (3) a crafted BMP file, related to the gdip_read_bmp_image function in bmpcodec.c, leading to heap-based buffer overflows.

Google Chrome before 5.0.375.127 does not properly implement the Geolocation feature, which allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via unknown vectors.